64 bit architectures and C/C++

Tim Roberts timr at gssc.UUCP
Thu May 23 03:59:41 AEST 1991


In article <313 at orac.UUCP> bret at orac.UUCP (Bret Indrelee) writes:
>In article <1991May9.192156.19291 at nightowl.MN.ORG> det at nightowl.MN.ORG (Derek E. Terveer) writes:
>>
>>What is wrong with simply implementing the following in a compiler?
>>
>>	char	=	 8 bits
>>	short	=	16 bits
>>	int	=	32 bits
>>	long	=	64 bits
>
>I agree, this is the best of many choices.  

Wrong!  This is NOT necessarily the best of many choices.  THINK about this
for a minute!  We've had a lot of entirely useless philisophical discussion
on this issue.

What if your 64 bit architecture doesn't have any instructions to deal with
16 bit units?  You certainly aren't going to include something as a fundamental
type when your architecture can't easily deal with it, are you?  What if, going
further, you can't manipulate 32 bit objects either?  On such a machine, you
would probably create short=int=long=64 bits.

The point is this:  C data types are intended to map into the fundamental
operating units of the underlying hardware.  Discussing the correctness of
C data type sizing on 64-bit machines in the general case is a pointless waste 
of network bandwidth.

-- 
timr at gssc.gss.com	Tim N Roberts, CCP	Graphic Software Systems
						Beaverton, OR

This is a very long palindrome. .emordnilap gnol yrev a si sihT



More information about the Comp.lang.c mailing list