Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!munnari!otc!softway!chris
From: chris@softway.oz (Chris Maltby)
Newsgroups: comp.arch
Subject: Re: looking for >32-bit address space [and how will C handle it]
Message-ID: <1326@softway.oz>
Date: 10 Apr 89 12:35:49 GMT
References: <1032@myrias.UUCP> <12289@reed.UUCP> <16568@winchester.mips.COM>
Organization: Softway Pty Ltd, Sydney, Australia
Lines: 33

In article <16568@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
> 	What's the C programming model for machines with 64-bit pointers?
> 		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
> 		Is there any chance of standardization?

The Elxsi has 64 bit registers but 32 bit addressing. When porting PCC
it seemed clean at first to make char, short, int and long be 8, 16, 32
and 64 respectively. We learn't the error of our ways very early.
There is just so much code which assumes:

	sizeof (int) == sizeof(long) or possibly (sizeof short)
	sizeof (void *) == sizeof(long) or sizeof(short)

It was relatively easy to make the kernel understand this assignment.
But although this arrangement is perfectly legal according to K&R it
isn't according to most suppliers of commercial UNIX software.

I agree with John's hopes. Before 64 bit machines become common, we'd
better have worked out a standard representation for the basic types
so that we have some hope of getting the writhing mass of ugly software
working again. Being realistic - I don't think we have a chance...
Still - it might send some "Dodgy-Brothers" software houses to the wall!
-- 
Chris Maltby - Softway Pty Ltd	(chris@softway.oz)

PHONE:	+61-2-698-2322		UUCP:		uunet!softway.oz!chris
FAX:	+61-2-699-9174		INTERNET:	chris@softway.oz.au