Data types on the Teensy 3.1 (32bit vs 16bit)

Status
Not open for further replies.
Experimentalist

Experimentalist

Well-known member
Hi

Is there any point in using 16 bit data types on code that is only ever intended to run on a 32 bit platform, that is code intended for the Teensy 3.0 / 3.1?

Further to this does the use of 16 bit data types on the T3/T3.1 actually create an overhead?

One last question, is it considered best practice to use int32_t over int if programming for a 32 bit platform?

Ex
 
It is common and wise to, in C/C++ use the types given in stdint.h, such as
uint16_t
int16_t

uint32_t
int32_t or long
uint8_t
int8_t signed char is rare

don't us just "int" as a rule. It's ambiguous

using int16_t or uint16_t on a 32 bit machine sometimes adds a tiny bit more overhead. But not enough to think about.
 
Well if you have a lot of structures, using 32-bit types when 16-bit would work fine, you will use more memory, and you could run out of memory. For normal Teensy 3.1 code, its not likely to happen, since you have 64k os SRAM. It is an issue for AVR processors, which have a lot less memory (512 bytes in the ATtiny85 for instance). There are a few special cases that need the truncation that 16 bits bring, but in general it probably doesn't matter.
 
Experimentalist said:
Is there any point in using 16 bit data types on code that is only ever intended to run on a 32 bit platform, that is code intended for the Teensy 3.0 / 3.1?
Click to expand...

No, there no advantage to fewer bits. In fact, sometimes 16 is slower than 32 bits.

Internally, all the registers are only 32 bits. Then the CPU reads data in from memory, it automatically converts 8 or 16 up to 32, and when it writes back to memory, 32 is automatically truncated properly (even if signed) to 16 or 8 bits. These cases have no extra overhead.

But in some cases, like when a function returns 8 or 16 bits without writing it back out to RAM, the compiler is forced to add an extra logical AND instruction to mask off the upper bits. Usually this is such a minor thing that it rarely makes much difference. But with native 32 bit numbers, such extra overhead isn't needed.

One last question, is it considered best practice to use int32_t over int if programming for a 32 bit platform?
Click to expand...

I believe this is mostly a matter of personal preference. I'm sure others would feel differently.

But when your code absolutely does depend on 32 bits, uint32_t and int32_t are a good idea. Likewise, if you're playing tricks with 8 or 16 bit rollover, or your code really does depend on a variable being exactly 16 bits (like when taking 2 I2C bytes from a motion sensor and packing them into a signed integer), you should always use the types that explicitly specify the number of bits.
 
Status
Not open for further replies.
Back
Top