How big is my int?

hiya,

I'm coding a project for Amiga AGA (030 minimum) using GCC v2.95. It has a compiler option to set the size of int to either 16 or 32 bits. I don't think it will actually effect my program as it defines it's own datatypes like this:

[code]
typedef unsigned char byte;

typedef unsigned char uint8;
typedef signed char int8;

typedef unsigned short uint16;
typedef signed short int16;

typedef unsigned int uint32;
typedef signed int int32;
typedef unsigned int uint;
[/code]

But I wondered if there was a standard for classic coding on 030? Also would there be a performance benefit from using a 16 bit int vs a 32 bit int?

Thanx :)

NovaCoder

@NovaCoder
There was a speed advantage to using 16 bit integers in many cases on the 68000. The 68020-68040 mostly don't care whether the data is 16 bits or 32 bits although there are a few cases where 32 bits are faster. The 68060 very much prefers 32 bits. It is piped for 32 bits and will be able to use both integer units more often with them. Aztec C used to have 16 bit integers as default with the biggest result being more problems. I would strongly advise leaving integers as 32 bits.

Cool, 32bits it is then :)

Thanks :)

Well put :-) The problem with 16 bit integers was that at the time Aztec 'C' implemented the K&R standard, which did not have function prototypes. Hence, you had to cast function parameters to 32 bit integer values if you knew that the respective function expected this (typical example: all AmigaOS operating system functions).

But if you failed to do that for some reason (oversight, typo, etc.), the code crashed very quickly, as the parameters passed over the stack didn't match what the respective function expected to pick up. Just like with assembly language, you had to be extremely careful to get your code written correctly, or you'd have been in for an extended debugging session.

If you use integers smaller than 32 bits today with an ISO 'C' compliant compiler and proper prototypes, the worst that can happen is loss of performance, as the compiler may be forced emit code which promotes smaller integers to larger types before they could be used.

It would indeed affect your program. If you are using 16-bit ints then your uint32, int32 and uint types would actually be only 16 bits wide.

Hiya,

The port has the followind define (commented out by default)

// - Define this if your port needs to use 'long' for the int32 datatype
// (i.e. an integer with exactly 32 bits).
#define SCUMMVM_USE_LONG_INT

Which is used like this:

#ifdef SCUMMVM_USE_LONG_INT
typedef unsigned long uint32;
typedef signed long int32;
typedef unsigned long uint;
#else
typedef unsigned int uint32;
typedef signed int int32;
typedef unsigned int uint;
#endif

Which seems to suggest that the port can run with 16bit precession for supposedly 32bit numbers.

That's risky, but then again you never know what kind of compiler environment ScummVM was designed for.

To be absolutely sure about the size of your scalar data types you have to use the compiler's provided definition of uint32_t, etc., which for an ISO 'C' compliant compiler would be found in the "stdint.h" header file. If you're stuck with an old ANSI 'C' compliant compiler, you're on your own, though.

NovaCoder

You could test the width with a sizeof().


I notice all these dayatypes seems to assume 32-bits for either long or int. Could it just specify to use an int as a long where both are 32-bits anyway?