Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcnc!rti!xyzzy!throopw
From: throopw@xyzzy.UUCP (Wayne A. Throop)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: pointer alignment when int != char *
Message-ID: <161@xyzzy.UUCP>
Date: Tue, 28-Jul-87 16:54:17 EDT
Article-I.D.: xyzzy.161
Posted: Tue Jul 28 16:54:17 1987
Date-Received: Thu, 30-Jul-87 04:28:52 EDT
References: <493@its63b.ed.ac.uk> <6061@brl-smoke.ARPA> <3812@spool.WISC.EDU> <688@haddock.UUCP> <13218@topaz.rutgers.edu>
Organization: Data General, RTP NC.
Lines: 40
Xref: mnetor comp.lang.c:3350 comp.unix.wizards:3464

> karl@haddock.UUCP (Karl Heuer)
>> lm@cottage.WISC.EDU (Larry McVoy)
>>> gwyn@brl.arpa (Doug Gwyn)
>>>(long) is appropriate for portable code.  (If a (char *) won't fit into a
>>>(long), you have real problems!)

I am aware of a seriously developed architecture where "long" was 64
bits, and pointers were 128 bits.  That is, arithmetic could be
performed on binary integers up to 64 bits long by the CPU, but pointers
had considerable extra information beyond offset information.  In
particular, there was a universal, shared, access-protected, segmented
address space.  It would have been natural to make shorts either 16 bits
or 32 bits, ints 32 bits, and longs 64 bits, which is quite vanilla.
The odd thing would have been that pointers wouldn't fit into any of
those.  But all in all, a very lovely machine.

And yes, much C code would have been hard to port to this machine, or
the compiler would have had to stand on its head and spin about 48
hula-hoops on its toes to make the usual assumptions that many C
programmers make about the underlying hardware seem to be true.  Sadly,
it is unlikely that this architecture will haunt C implementors or
programmers.  The current fashion in computer architecture has moved
away from many of the concepts it embodied.  Sigh.

>> Don't some supercomputers make longs 32 bits, long longs 64 bits, and
>> have addresses > 32 bits and < 64 bits?
>>I seem to remember that someone said something like that recently.
> Probably my article, which was hypothetical.  I was less concerned with the
> cast of pointer to int, which is nonportable anyway, than with the kosherness
> of having size_t and ptrdiff_t be larger than unsigned long.

Ah.  The architecture I had in mind does not have these problems.  Of
course, many C programmers assume that any two non-null poiners of the
same type can be subtracted, which isn't the case for this architecture.

--
What!!??  What is it!!??  
Did they find Jimmy Hoffa under Tammy Bakker's makeup?
                                --- from Bloom County
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw