On 4/19/2011 0:24, Lars R. wrote:
> Well, the C language does not specify that pointers to objects ("data
> pointer", incl. void*) can be converted to function pointers nor vice v
ersa.

As I said a while back, C (and C++) has a harvard architecture.

> http://roker.spamt.net/c++/datatypes_c55x.png

The Xerox 560 (aka Sigma 9, the computer that sent people to the moon) ha
d a 
different size pointer for each thing you could point to. A char* was 19 

bits, a long* was 17 bits, etc.  You could cast them all to integers and 

back, especially if you shifted the long* to the left, so you could still
 
come up with something not too dissimilar from what C programmers expect.
 
You couldn't union a long* and a char* and expect not to get faults if yo
u 
did it wrong.

The Burroughs B series tagged the actual hardware data, so all you had wa
s 
"pointer", and whatever it pointed to determined what the operation was. 
In 
other words, there was only an "add" instruction, and the contents of the
 
memory that the index registers pointed to determined whether you were 
adding ints, floats, array indexes, or whatever. Plus, all the array boun
ds 
were checked in hardware.  I don't think they ever ported C to that.

I worked on an HP machine where each allocation was in its own address 
space. I don't remember the details because I only actually used HLLs the
re, 
but again, it's one of those things that in theory C would be able to 
support but in practice most programs wouldn't.

> So don't blame (the inventors of) C, but blame the UNIX/POSIX guys who
> "invented" the flat memory model and seduced legions of C programmers t
o
> expect that "pointers are integers" and so on…

I think the equally flawed abstraction is having the stack and the heap i
n 
the same address space. That makes it really hard to implement on somethi
ng 
where accessing those are separate sets of operations.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message