Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!ncrlnk!ncrcae!ece-csc!mcnc!uvaarpa!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: 64 bit ints Message-ID: <8790@smoke.BRL.MIL> Date: 28 Oct 88 16:44:21 GMT Article-I.D.: smoke.8790 References: <6264@june.cs.washington.edu> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 30 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.