david@june.cs.washington.edu (David Callahan) (10/28/88)
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? What have other 64bit vendors done (assuming I'd like to be compatible with someone)? David Callahan Tera Computer Co. Seattle Washington
gwyn@smoke.BRL.MIL (Doug Gwyn ) (10/28/88)
In article <6264@june.cs.washington.edu> david@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.
mcdonald@uxe.cso.uiuc.edu (10/29/88)
>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
jerry@starfish.Convergent.COM (Gerald Hawkins) (10/30/88)
From article <6264@june.cs.washington.edu>, by david@june.cs.washington.edu (David Callahan): > > 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? > - I'm no expert, but I understand that the language standard allows short, int, and long to all be the same length if that is convenient. Of course, if you do that, you cut off an easy way for people who have to make machine dependant stuff work; ie, if someone was silly enough to depend on int being 16 bits for variables, and you had to port the application to this machine, it may be nice to have a short be 16 bits so the code could easily be modified to say 'short' instead of 'int'. Obviously, no-one reading this ever creates machine dependant code, though. We know that already. Rainy Days and Automatic Weapons Fire Alway Get Me Down. These opinions are mine. Jerry. (jerry@Starfish.Convergent.COM) -----
guido@cwi.nl (Guido van Rossum) (10/30/88)
One argument for making int = long = 64 bits is that function call arguments smaller than int are widened to int; if 64 is your machine's word size you probably don't want to push partial words on the stack as parameters. This is even more true when part-word accesses are more expensive. On the other hand, if the machine is equally versatile in handling 8, 16, 32 and 64 bit quantities, *and* you care about porting software written for 32-bit architectures, you may choose to add a 'long long' type for 64 bits, and use short=16, int=long=32 bits. You may still get into trouble with programs that (illegally!) assume a pointer fits in a long... -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@piring.cwi.nl or mcvax!piring!guido or guido%piring.cwi.nl@uunet.uu.net
scjones@sdrc.UUCP (Larry Jones) (10/30/88)
In article <225800084@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes:
< [without attribution]
< >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.
The answer may be clear, but it's also wrong (at least by some
standards). The draft ANSI standard requires that int
be the same size as either short or long; it may not be a third,
distinct, size of integer.
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC scjones@sdrc.uucp
2000 Eastman Dr. BIX: ltl
Milford, OH 45150 AT&T: (513) 576-2070
"Save the Quayles" - Mark Russellgwyn@smoke.BRL.MIL (Doug Gwyn ) (10/31/88)
In article <225800084@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
-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.
This is unworkable. The application code has to interface with the
C library and other libraries. It is unrealistic to expect there to
be umpteen variants of each library to support all the permutations
of data sizes.
It is also a BAD idea to make int handling slower than necessary
by an inappropriate choice. int has always been intended to be the
integer type "most convenient for the machine".gwyn@smoke.BRL.MIL (Doug Gwyn ) (10/31/88)
In article <418@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes: >The draft ANSI standard requires that int >be the same size as either short or long; it may not be a third, >distinct, size of integer. Where do you see that? Section 3.1.2.5 requires that an int be able to hold all integers in the range INT_MIN to INT_MAX and that its range be no less than that of short int and no more than that of long int. Nowhere do I find a requirement that sizeof(int)==sizeof(short)||sizeof(int)==sizeof(long).
ok@quintus.uucp (Richard A. O'Keefe) (10/31/88)
In article <8803@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <225800084@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >-Then allow the user to specify, either ... by command line switches ... >-whatever combination of shorts, ints and longs he wants >This is unworkable. The application code has to interface with the >C library and other libraries. It is unrealistic to expect there to >be umpteen variants of each library to support all the permutations >of data sizes. It may be unworkable, but there are a lot of Fortran compilers that do it. (UNIX "f77" compilers use the flags "-i2" (int=short) "-i4" (int=long).) What you do is introduce some implementation-specific types: __s8 __s16 __s32 __s64 (signed) __u8 __u16 __u32 __u64 (unsigned) 8-bit 16-bit 32-bit 64-bit Then the library headers include prototypes using the implementation- specific types. The *printf family can be handled by ensuring that integral arguments passed to that function are widened to __s8 or __u8 or whatever. The *scanf family is tricky, but I can think of several solutions. While it would be workable, it probably wouldn't be a good idea. Probably the best thing to do would be to pick an "efficient" value for 'int', and offer two system-dependent macros _SIGNED(N), _UNSIGNED(N) expanding to the smallest integral types capable of holding N-bit integers; the expansions needn't be available any other way. _SIGNED(N) is similar to a current proposal for Fortran 8X, and the concept is sufficiently system-independent that other compiler-writers might pick it up.
peter@ficc.uu.net (Peter da Silva) (10/31/88)
In article <8803@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > It is also a BAD idea to make int handling slower than necessary > by an inappropriate choice. int has always been intended to be the > integer type "most convenient for the machine". What is the most convenient type for a 68000? 16-bit ints are much faster (twice as fast for loads and stores) but 32-bit ints fit the register architecture better. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
crossgl@ingr.UUCP (Gordon Cross) (11/01/88)
In article <6264@june.cs.washington.edu>, david@june.cs.washington.edu (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. > > 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? As I recall the proposed ANSI standard states that the type "int" should be the size which is most "natural" or efficient on the target machine. This has been 32-bits on all 64-bit machines I've seen. If your machine has a 64-bit word size and a halfword (32 bits) access is more expensive then perhaps a 64-bit "int" is appropiate. Seems like that if your machine has support for 8, 16, 32, AND 64 bit integers then your only choice would have to be char 8 bits short 16 bits int 32 bits long 64 bits unless someone wants to introduce "short short int" and/or "long long int"!!!! Gordon Cross Intergraph Corp. Huntsville, AL
mguyott@mirror.TMC.COM (Marc Guyott) (11/01/88)
In article <225800084@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > > >>Suppose I am designing a C compiler for a machine with 64bit >>words. >>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 > int 32 bits Didn't K&R define an "int" as being the natural word size of the hardware that you are running on? So for an 80286 an int should be 16 bits, for a machine with a 32 bit word an int should be 32 bits, and for the machine described above an int should be 64 bits. Comments? Marc ---- ... I never saw the morning until I stayed up all night ... Tom Waits Marc Guyott mguyott@mirror.TMC.COM {mit-eddie, pyramid, harvard!wjh12, xait, datacube}!mirror!mguyott Mirror Systems Cambridge, MA 02140 617/661-0777
scjones@sdrc.UUCP (Larry Jones) (11/02/88)
In article <8811@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <418@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones [me]) writes: > >The draft ANSI standard requires that int > >be the same size as either short or long; it may not be a third, > >distinct, size of integer. > > Where do you see that? Section 3.1.2.5 requires that an int be able to > hold all integers in the range INT_MIN to INT_MAX and that its range > be no less than that of short int and no more than that of long int. > Nowhere do I find a requirement that > sizeof(int)==sizeof(short)||sizeof(int)==sizeof(long). Well, shucks. I swear I remember a vote to that effect, but I'll be darned if I can find any trace of the requirement in the Draft either. Either I imagined it or it got lost somewhere -- the first seems most likely, I'm afraid. Sorry for any confusion I caused. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@sdrc.uucp 2000 Eastman Dr. BIX: ltl Milford, OH 45150 AT&T: (513) 576-2070 "Save the Quayles" - Mark Russell
henry@utzoo.uucp (Henry Spencer) (11/05/88)
In article <2074@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >> ... int has always been intended to be the >> integer type "most convenient for the machine". > >What is the most convenient type for a 68000? 16-bit ints are much faster >(twice as fast for loads and stores) but 32-bit ints fit the register >architecture better. You have just discovered Excedrin Headache number 68000 for compiler implementors. Which is why some 68000 C compilers go one way and some the other. The 68000 actually does pretty well at supporting 16-bit ints, so I don't think "not fitting the register architecture" is a big problem. The hard part is that it supports 32 bits well enough to be tempting (especially since sizeof(int)==sizeof(char*) reduces breakage of poorly- written programs) but not well enough for it to be the clear choice. It sort of depends on whether you view the 68000 as a cut-down 68020 (in the same way the 8088 is a cut-down 8086 -- all the 8088 compilers that I know of use 16-bit ints even though 8 would be faster!) or as a machine in its own right. -- The Earth is our mother. | Henry Spencer at U of Toronto Zoology Our nine months are up. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu
peter@ficc.uu.net (Peter da Silva) (11/06/88)
In article <1988Nov4.183818.21555@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <2074@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >What is the most convenient type for a 68000? > You have just discovered Excedrin Headache number 68000 for compiler > implementors.... > It sort of depends on whether you view the 68000 as a cut-down 68020 > or as a > machine in its own right. I thought of the 68000 as a cut down 11/780 back before the 68020 was even thought of, so a cut down 68020 is just fine. For me, if the compiler doesn't at least give me the option of using 32-bit integers I don't want to know about it. Luckily the 68000 compilers I have to deal with or consider give me the option. Actually, 16-bit ints isn't so bad... it does speed up your code, and you can generally intermix the models (try doing that on your 8086). What bugs me is the compilers that use 16-bit offset pointers. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
dan@srs.UUCP (Dan Kegel) (11/07/88)
Here's an interesting bit of trivia: the number of human beings living on the Earth cannot be represented in 32 bits. Kinda scary, eh? -- Dan Kegel I saw a bufferfly yesterday for the first time in years... srs!dan@cs.rochester.edu rochester!srs!dan dan%srs.uucp@harvard.harvard.edu
cramer@optilink.UUCP (Clayton Cramer) (11/09/88)
In article <1002@srs.UUCP>, dan@srs.UUCP (Dan Kegel) writes: > Here's an interesting bit of trivia: the number of human beings living on > the Earth cannot be represented in 32 bits. > Kinda scary, eh? > -- > Dan Kegel I saw a bufferfly yesterday for the first time in years... Only if you need a unique identifier to keep dossiers on all of them. :-) -- Clayton E. Cramer ..!ames!pyramid!kontron!optilin!cramer
mcdonald@uxe.cso.uiuc.edu (11/09/88)
>Here's an interesting bit of trivia: the number of human beings living on >the Earth cannot be represented in 32 bits. >Kinda scary, eh? Uh- I thought that only those who know C matter ... :-)