Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!fernwood!dumbcat!marc
From: marc@dumbcat.sf.ca.us (Marco S Hyman)
Newsgroups: comp.lang.c++
Subject: Re: 64 bit architectures and C/C++
Message-ID: <295@dumbcat.sf.ca.us>
Date: 28 Apr 91 18:33:13 GMT
References: <168@shasta.Stanford.EDU> <224@tdatirv.UUCP>
Organization: MH Software, Hayward, CA.
Lines: 36

In article <224@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes:
 > In article <168@shasta.Stanford.EDU> shap@shasta.Stanford.EDU (shap) writes:
 > >	short	16 bits
 > >	int	32 bits
 > >	long	64 bits
 > >	void *	64 bits
 >  
 > OR:
 > 	short	32 bits
 > 	int	64 bits
 > 	long	64 bits
 > 
 > OR:
 > 	short	32 bits
 > 	int	32 bits
 > 	long	64 bits

I hope not -- at least not without some other way of describing a 16-bit
value.  64-bit architecture machines will still have to communicate with other
machines that do support 16-bit values.  Swapping bytes between big and little
endian machines is bad enough. Think about the overhead of converting a pair
of bytes to a 16-bit value.  

 > Any one of the above may be the most appropriate depending on the
 > instruction set.  If there are no instructions for 16 bit quantities
 > then using 16 bit short's is a big loss.

Hmmm.  How would such a processor communicate with hardware devices requiring
16-bit I/O?  How would a structure that maps an external device's registers be
coded if the registers are 16-bits wide?  If there is a way to do these things
then a 16-bit wide data type is probably necessary.

-- 
// marc
// home: marc@dumbcat.sf.ca.us		pacbell!dumbcat!marc
// work: marc@ascend.com		uunet!aria!marc