Xref: utzoo comp.arch:9175 comp.lang.c:17485
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!aeras!elxsi!beatnix!rw
From: rw@beatnix.UUCP (Russell Williams)
Newsgroups: comp.arch,comp.lang.c
Subject: Re: looking for >32-bit address space [and how will C handle it]
Message-ID: <2569@elxsi.UUCP>
Date: 6 Apr 89 21:15:57 GMT
References: <1032@myrias.UUCP> <12289@reed.UUCP> <16568@winchester.mips.COM>
Sender: news@elxsi.UUCP
Reply-To: rw@beatnix.UUCP (Russell Williams)
Organization: ELXSI Super Computers, San Jose
Lines: 27

In article <16568@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>One interesting issue, for some ways out, is what the 64-bit model ought
>to be be: maybe some of the mini-super and supercomputer folks can give us
>some hints here:
>		how do you say 8-, 16-, 32, and 64-bit ints?
>		(char and short are fine.  Now, are 64s long-longs,
>		or just longs?  are 32s longs?  which one is int?
>		how much code breaks under these various cases?
>			user code
>			operating system code
>			networking code

   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.  

   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.


Russell Williams
..uunet!elxsi!rw
..ucbvax!sun!elxsi!rw