On Thu, Oct 30, 2008 at 4:24 PM, Daryle Walker <darylew@hotmail.com> wrote:
Is there a macro and/or typedef that will tell me bit-length used for a processor and/or the best integer type for said processor? The "int" type is supposed to be that type, and it was in the 16- and 32-bit eras. (I learned C programming with the former in the... early 1990s!) However, the powers-that-be decided, for "backwards compatibility," to freeze "int" and "long" at 32 bits and use a new type, "long long," for 64 bits, which should be the optimized integer type for 64-bit processors. (If they kept to the plan, "int" would be 64 bits, "long" either 64 or 128, "short" up to 32, and the new type will be "short short" at 16.) I want to know the best type so, when I build multi-integer arrays for various purposes, I don't pick an element type that causes a slow down, whether to focus on a fraction of a register (if the chosen type is too small) to handle two registers at once (if the chosen type is too large).
A 32 bit integer *is* the best integer type for practically all 64 bit processor. At least for x86-64, there is no penalty for performing 32 bit arithmetic instead of 64 bit. In fact 64 bit arithmetic requires a REX prefix which will slightly enlarge the code footprint. There is a large cache saving advantage in using smaller integer size. Finally, having smaller integers means that you can fit more of them in SIMD registers. Long is a bit different as I think most programmers have always expected 'long' to be big enough to cover all offsets in the address space (most 64 bit unices have 64 bit longs. I think that Win64 is the exception). Anyways, correct code should always use size_t for sizes and ptrdiff_t for offsets. -- gpd