Re: Use of Long and Long Long

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 long
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)
Now look at a 32 bit DSP which cannot deal with anything below 32
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.
--
Flash Gordon
.

Relevant Pages

  • Re: right padding
    ... Using gcc in mingw on a windows machine.. ... helpful things a compiler can do if you are writing library code like ... int num = 123; ... area of memory freed is the area that was allocated in the subroutine. ...
    (comp.lang.c)
  • Re: data types
    ... Usually short is smaller than an int. ... memory per dms structure if they are 32-bit integers. ... current compiler system. ... recommend either a version of gcc,, or Visual Studio ...
    (comp.lang.c)
  • Re: vrp bitfield miscompilation (WAS: [Regression] snd_emu10k1 doesnt work after GCC 4.2 upgrade)
    ... snd_emu10k1 doesn't work after GCC ... (these are signed single-bit variables): ... With int these flags have values of, ... I've seen that the compile will round the memory size of a bit-fields down to the nearest byte, ...
    (freebsd-current)
  • Re: weird behaviour by gcc
    ... The compiler can align memory as it chooses. ... > int main ... profit) when I noticed this behaviour by gcc. ...
    (comp.lang.c)
  • new gcc 4.10 behaviour
    ... After suspecting that something around the clock() ... int Ack{ ... but it seems to work as it did with gcc 4.01. ... Every optimisation level from -O to -O3 gives various problems, ...
    (comp.os.msdos.djgpp)