#29192 - mr_square - Sat Nov 13, 2004 1:14 pm
All the GBA header files define types like u16, u8, s16, s8 etc. to represent various unsigned and signed integers.
I'm using a lot of 'ints' in my code, but other examples I've looked at don't seem to be - is my way alright, or is there a reason I should be sticking to using u16, u8 etc (and which is equivalent to int??)
thanks
#29193 - keldon - Sat Nov 13, 2004 1:22 pm
You'd stick to the u32s and s16s if you want a specific feature of one. For example you might define some data as u8 because it maps numbers from 0-255. But in your loop you might use s16 because it loops from -2505 to 30000.
#29195 - identitycrisisuk - Sat Nov 13, 2004 1:47 pm
As to which is equivalent to an int I think it is a s32 even though that is defined as a signed long. longs have the same amount of bits as ints I think, not quite sure why. It's all about saving memory and helping you to understand the range of values in the end really.
#29197 - poslundc - Sat Nov 13, 2004 3:46 pm
int == long == s32 on the ARM processor.
short == s16
char == u8
"long long" - which you may see from time to time in the forums - is a special 64-bit datatype that can be useful for fixed-point multiplications, but it follows its own set of rules that can be hard to manage, and shouldn't be used for general-purpose calculations.
My general rule of thumb is to use the shorthand datatypes (u32, s16, etc.) when I care about the size of the type (most often in structs and array declarations) and use "int" everywhere else for general-purpose variables.
Dan.
#29203 - sajiimori - Sat Nov 13, 2004 6:05 pm
I've seen people use a u8 or whatever as a loop iterator to "save memory", but the stack gets 4-byte aligned anyway and it often produces extremely slow code. If the compiler can't prove that the number never goes over 255, it has to repeatedly mask out the high bits in order to emulate a u8 despite the fact that a 32 bit register is being used.
#29211 - Miked0801 - Sat Nov 13, 2004 9:25 pm
Agreed. Always use processor word sizes unless you have a good reason not to. There could be an argument for using u16/s16s in ROM because of bus, but I still stick with u32/s32s anyways. Cleaner code, easier to read adn smarter assmebler.