Path: utzoo!utgpu!watmath!clyde!mcdchg!chinet!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: 64 bit ints
Message-ID: <225800084@uxe.cso.uiuc.edu>
Date: 29 Oct 88 15:48:00 GMT
References: <6264@june.cs.washington.edu>
Lines: 25
Nf-ID: #R:june.cs.washington.edu:6264:uxe.cso.uiuc.edu:225800084:000:933
Nf-From: uxe.cso.uiuc.edu!mcdonald    Oct 29 10:48:00 1988



>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.

>How long should an "int" be (32 or 64)? 
>How about a "short int" (16/32)?
>How is this decision altered if partial word accesses 
>are more expensive than full word accesses?
The answer here should be very clear:
     Make the compiler so that it can handle the general case of
           char    8 bits
           short int 16 bits
           int        32 bits
           long int    64 bits.

Then allow the user to specify, either by an "install" program,
by command line switches, by a "config" file, or by (gasp) pragmas,
whatever combination of shorts, ints and longs he wants, so
long as they fit the usual rules of C. Some people will use 
short = int = long int = 64 while others will put short = int = 16
and long int = 64 (to match pointers) or whatever.

Doug McDonald