64 bit architectures and C/C++

Ken "Turk" Turkowski turk at Apple.COM
Tue Apr 30 05:40:50 AEST 1991


shap at shasta.Stanford.EDU (shap) writes:

>3. If conformance to the standard is important, then the obvious
>choices are

>	short	16 bits
>	int	32 bits
>	long	64 bits
>	void *	64 bits

>4. Would it be better not to have a 32-bit data type and to make int
>be 64 bits?  If so, how would 32- and 64- bit programs interact?

It is necessary to have 8, 16, and 32-bit data types, in order to be able
to read data from files.  I would suggest NOT specifying a size for the int
data type; this is supposed to be the most efficient integral data type
for a particular machine and compiler.

A lot of programs rely on the fact that nearly all C implementations
have a 32-bit long int.

I would suggest:

short	16 bits
long	32 bits
long long	64 bits
int	UNSPECIFIED
void *	UNSPECIFIED

This is patterned after ANSI floating-point extensions to accommodate
an extended format (i.e. "long double").

How about "double long", because it really is two longs?  (Donning flame
retardent suit).

What then would 128-bit ingeter be?  long long long?  double double long?
long double long?  quadruple long?  How about the Fortran method: int*8?

Another proposal would be to invent a new word, like "big", "large",
"whopper", "humongous", "giant", "extra", "super", "grand", "huge",
"jumbo", "broad", "vast", "wide", "fat", "hefty", etc.

Whatever chaice is made, there should be ready extensions to 128 and 256
bit integers, as well as 128 and 256-bit floating point numbers.

P.S. By the way is there an analagous word for floating-point numbers as
int does for integers?
-- 
Ken Turkowski @ Apple Computer, Inc., Cupertino, CA
Internet: turk at apple.com
Applelink: TURK
UUCP: sun!apple!turk



More information about the Comp.lang.c mailing list