aglew@mcdurb.Urbana.Gould.COM (04/09/89)
> Elxsi has 32 bit pointers but 64-bit registers. We originally made >ints 32 and longs 64, and did manage to port sys V, but it was a real >pain. Customers screamed, and we changed to 32 bit longs and 64 bit >long longs. Networking code -- both ATT & third party -- is full of >the 16/32/32 short/int/long assumption. Sorry, I can't resist this - things like this reinforce my belief that the people who put networking into the kernel hacked and kluged (I was going to say "Were a bunch of XXXX hackers", but that might be unfair. They don't even have the excuse of being the first - there were several preceding implementations, both user and kernel. But I guess they thought that any dirty trick that might get them a bit faster was worthwhile. > HP had a pre-Spectrum project called Beta which had 64 bit registers >and 64-bit pointers, with 16 bits of segment and 48 bits of offset. The >idea was that even the largest databases could be made directly byte >addressable. I don't know how they were going to deal with it in C. Doesn't C require that a pointer fit into a long?
guy@auspex.auspex.com (Guy Harris) (04/11/89)
>Doesn't C require that a pointer fit into a long?
The (d)pANS has nuked the notion that you can stuff pointers into
objects of any particular integral type, or stuff an integral value into
a pointer (no, "p = 0" doesn't stuff the integral value 0 into "p", it
stuffs a null pointer value of the appropriate type into "p") - and,
according to the Rationale, has done so since some architectures don't
"feature uniform pointers which are the size of some integer type". An
architecture with pointers bigger than any integral type - even if those
pointers are "uniform" - is such an architecture.
The developer of such an architecture might want to worry about the
problem anyway, if they're concerned with supporting applications that
assume you *can* stuff pointers into integers. Then again, they might
just see how many of them can use "void *" instead....