64 bit ints

Doug Gwyn gwyn at smoke.BRL.MIL
Sat Oct 29 02:44:21 AEST 1988


In article <6264 at june.cs.washington.edu> david at uw-june.UUCP (David Callahan) writes:
>Suppose I am designing a C compiler for a machine with 64bit
>words. "Char" should be 8bits of course and "long int" 64 since
>pointers will be.

Those are okay.  If the machine is not inherently 8-bit byte-addressable,
you might consider making char 16 bits to better support oriental languages.

>How long should an "int" be (32 or 64)? 

Assuming that 64-bit word instructions are more efficiently used,
int should be 64 bits.

>How about a "short int" (16/32)?

If there is an efficiency loss of more than about 50% using integer
operands shorter than 64 bits (what you call "partial word accesses"),
then make short int 64 bits also.  Otherwise, short int should be
larger than char and smaller than int.  With a 16-bit char this would
make short int 32 bits.  With an 8-bit char either 16 or 32 bits is
possible.  My personal preference is for 16-bit shorts, i.e. the
smallest permitted size, because I think anyone who is using short
probably wants the smallest size he can get (that is at least 16 bits).

One additional consideration is just how important it is to import
code written with nonportable notions of integer size, e.g. older
code found on many VAXes.  If this is highly important, you might
use the exact VAX word sizes regardless of the fact that this would
slow the applications down.  Otherwise, let the ANSI C requirements,
efficiency considerations, and probable use of the types be your guide.



More information about the Comp.lang.c mailing list