rcj@burl.UUCP (R. Curtis Jackson) (04/06/84)
Here are some guidelines on using int/short/long direct from both past experience and the AT&T Technologies Unix/C interfacing course I took a while back: GUIDELINE #1: DON'T EVER USE int. GUIDELINE #2: THERE IS NO GUIDELINE #2. It is very simple -- don't worry about which type is involved; just worry about how many bits you need. If you are doing heavy math, you may want to watch out for automatic conversions; they are explained in great detail in R&K p. 184 section 6.6. As for the reason not to use int, here is a rundown on three computers that I can be sure of my info on right off the bat: Number of bits short int long 3B20S 16 32 32 VAX 16 32 32 PDP 16 16 32 One excellent way to do things is to head each program or major header file (if a big software package is involved) with the following: typedef EIGHT char; typedef SIXTEEN short; typedef THIRTY2 long; or something similar. Then just tell the person porting the software to go in and do a 30-second customization of your program(s); you will have used your EIGHT, SIXTEEN, and THIRTY2 throughout so all she has to change is those three lines. I would love to see some good portability guidelines for 'C', because I get REAL tired of people who write code without (apparently) knowing about cpp(1), typedef statements, make(1), header files, etc. etc. Who, me? Throw the first stone? I must be a saint!! :-) -- The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ floyd clyde ihnp4 mhuxv ]!burl!rcj
kvm@basser.SUN (Karlos Mauvtaque) (04/09/84)
You say don't use "int", ever. Nonsense. Here are my rules: Use "long" if you really mean "long", (i.e. at least 32 bits, argue if you like that "long" does not have to be at least 32 bits but any implementation with less will be very lonely, nothing will work). Use "short" only in data structures where you are concerned about how much space you are using. In other cases "int" is always better because it is at least as big and "the natural size suggested by the host machine architecture", i.e. faster. Try changing your: register short i; loop variables to register int i; and you may not need that n-th VAX.
ptw@vaxine.UUCP (P. T. Withington) (04/13/84)
...int is the natural size suggested by the machine architecture, i.e., faster.
Not on the 68000 it ain't. ('Cept if you get the ATTT package and configure it
so).
...vaxine!ptw
(soon to be ...trope!ptw)minow@decvax.UUCP (Martin Minow) (04/14/84)
Here are the int/short/long guidelines that we used in a fairly large product (DECtalk): Storage allocation (globals and statics) always uses the following quantities: char 8-bit maximum, contains a value. FLAG Contains only TRUE/FALSE (#defined as char) INT_16 int that can be stored in a pdp-11 short INT_32 int that reqires more than a pdp-11 short Function formal parameters and auto's may use "int" if the argument was passed as char, int, or INT_16 and the value is expressable as a pdp-11 short. This allows the compiler to generate efficient code for "normal" situations. The definition of INT_16 and INT_32 is set by architecture-specific typedef's in a header file. Martin Minow decvax!minow
ed@unisoft.UUCP (Ed Gould) (04/17/84)
Actually, there are times that you do want to use int. On some machines, int is faster than short, even though you may need only 16 bits. Int represents the "natural" integer size for the hardware, but it's only guranteed to be at least 16 bits. Use int, therefore, when you don't care about the space consumed and 16 bits is enough (e.g., not in a struct that will be written to a file). As an example of where int might be faster than short, consider a machine with 32-bit registers, but where the 16-bit operations don't clear the upper bits of the register. Usually, the compiler will have to do the manipulation of the upper bits in a separate instruction. -- Ed Gould ucbvax!mtxinu!ed
jc@inmet.UUCP (04/19/84)
#R:burl:-43000:inmet:10300013:000:995
inmet!jc Apr 18 14:20:00 1984
...int is the natural size suggested by the machine architecture, i.e., faster.
Not on the VAX it ain't. I recently did a bunch of timing tests on an 11,
a VAX, and a 68000. On the latter machines, replacing short with int caused
the times to increase, sometimes dramatically (50% or more). Furthermore,
storing a boolean as a short was consistently slower than as a char, even
on the so-called 32-bit machines.
My suggestion (for what it's worth) is to use pseudo-types for all globals,
and for all params and locals that aren't registers. Registers are usually
coerced to int or long anyway, so I don't bother with them. Incidentally,
some of my tests (especially on a 4341 running Amdahl's UTS) ran faster if
I didn't use registers, but let the compiler do its own allocation. One the
other hand, on the 11 and VAX, the version with registers was usually faster.
Maybe you should use a pseudo-type even for register variables.
...jc!inmet
----------