Re: Use of Long and Long Long
- From: Flash Gordon <spam@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 10 Jan 2008 11:39:08 +0000
Bart C wrote, On 10/01/08 01:16:
Flash Gordon wrote:Bart C wrote, On 09/01/08 20:33:
Integer widths that obey the rule short < int < long int <long longNow look at a 32 bit DSP which cannot deal with anything below 32
int (instead of short<=int<=long int or whatever) would be far more
intuitive and much more useful (as it is now, changing int x to long
int x is not guaranteed to change anything, so is pointless)
bits. Given your definition it would have to do at least
sizeof(char) == 1 - 32 bits
sizeof(short) == 2 - 64 bits
sizeof(int) == 3 - 96 bits
sizeof(long) == 4 - 128 bits
sizeof(long long) == 5 - 156 bits [160?]
Yes in this example it sort of makes sense, if the compiler does not try too hard to impose anything else.
However it's not impossible either for the compiler to impose 8, 16, 32, 64-bit word sizes (don't know how capable DSPs are or whether this is even desirable). So a 128K array of 8-bit data for example could take 128KB instead of 512KB.
It is not impossible, but on a significant number of main stream DSP processors using anything less than the size the processor understands (16 bits, 24 bits, 32 bits and 48 being common) you would make the smaller types very inefficient since it would have to keep masking etc. So to write an 8 bit char to memory it would have to on one of the processors...
shift accumulator left 16 bits (1 clock)
load memory location shifting data left 8 bits (1 clock)
save shifting right 8 bits (1 clock)
So you have turned a common 1 clock cycle operation in to a 4 clock cycles which also change the contents of the accumulator. Do you really think a 400% increase in the time to save a char is worth the cost?
A lot of other operations would also be slowed down.
On such processors it really does not make sense to use smaller data types than the processor understands so why introduce the additional complexity to the compiler just to make it extremely inefficient if some code does use a short or a char?
If those are your minimum requirements then you use
char - at least 8 bits
short - at least 16 bits
int - at least 16 bits (but likely to be larger)
long - at least 32 bits
long long - at least 64 bits
At first this seems the way to go: char, short, long, long long giving at least 8, 16, 32, 64-bits respectively.
Except my test showed the long int was 32-bits on one compiler and 64-bits in another -- for the same processor. This just seems plain wrong.
No, it is NOT wrong. At least, not necessarily. If one implementation supports things which require a 64 bit integer type to perform certain operations (e.g. supporting fseek on large files) then selecting a 64 bit long makes perfect sense. Another implementation might have decided that supporting legacy broken code that assumes int and long are the same is more important. These are both valid trade-offs.
It means my program that needs 32-bit data runs happily using long int under dev-cpp, but takes maybe twice as long under gcc because long int now takes twice the memory and the processor unnecessarily emulates 64-bit arithmetic.
Hmm. Did you realise that you are saying that gcc produces code that uses twice the memory of gcc? dev-cpp uses either gcc, the MinGW port of gcc or the Cygwin port of gcc as the compiler.
Alternatively, use the types defined in stdint.h (or inttypes.h) which
have been added in C99. These headers provide you exact width types
OK looks like this is what I will have to do.
Using the fast types would make more sense than the fixed width ones unless you *really* need fixed-width types (most people don't, although I do) or to save memory (in which case the least types maximise portability).
vippstar@xxxxxxxxx wrote:printf("LD = %3d bits\n",sizeof(ld)*CHAR_BIT);The proper format specifier for size_t is '%zu'
I would never have guessed! Although the results (on one rerun anyway) were the same.
Undefined behaviour is like that. It can hide itself by doing exactly what you expect, or it can cause your computer to come alive and eat all the food in your fridge.
- Prev by Date: Re: How to make local variable's address is 8 byte alignment?
- Next by Date: Re: sizeof and structure
- Previous by thread: Re: Use of Long and Long Long
- Next by thread: Re: Use of Long and Long Long