Most efficient data length?

[Lars Beiderbecke]

Posted on January 06, 2018 at 17:38

I'm still new to the Cortex M architecture, but I was wondering which is the most performing data type for integers smaller than 256 if space is abundant? Is it uint8_t, uint16_t, or uint32_t, or are they all the same?

[Tesla DeLorean · Accepted solution]

Posted on January 06, 2018 at 18:24

Depends what you're doing with the data, manipulating it as 32-bit is generally the most efficient, ie using 8-bit or 16-bit isn't faster, and might require masking or shifting. The compiler's default 'int' size is 32-bit, and you should use this for loop iterators rather than the smallest thing you can fit it in.

If you have large tables/arrays of constants use the 8, 16 or 32-bit form the data fits into.

In assembler immediate loads have a format that goes beyond 8-bit (8-bit pattern shifted across 16 positions), things that can't be represented with the scheme are placed in a literal pool usually at the end of the function, and a PC relative load. The assembler/compiler can choose how to represent values in the most efficient fashion.

[Lars Beiderbecke]

Posted on January 06, 2018 at 18:47

Yes, I was referring to loop iterators, global flags, counters, function parameters, constants, and such things. I take it now that I should use uint32_t for everything for best performance, unless space matters.

[Tesla DeLorean]

Posted on January 06, 2018 at 19:22

The registers are 32-bit, the compiler will try to keep everything in registers as long as possible. The first four parameters to a function are passed in registers. So int32_t or uint32_t would be optimal. Using int or unsigned tends to be the most portable.

[Lars Beiderbecke]

Posted on January 07, 2018 at 13:26

I like uint<n>_t, because you know exactly how large it is. You're right about int being more portable, but only if you're staying within the bounds of the smallest int you're possibly porting to.

[Pavel A.]

Posted on January 08, 2018 at 00:22

Such a type is defined in the same stdint.h file, where all the int_8/16/32_t are defined.

It's name is int_fast8_t. Or u

int_fast8_t for unsigned.

-- pa

[Lars Beiderbecke]

Posted on January 08, 2018 at 19:38

 ,

 ,

Interesting. , I looked at the definition:

♯ ifdef __INT_FAST8_TYPE__

 ,

typedef __INT_FAST8_TYPE__ int_fast8_t,

 ,

typedef __UINT_FAST8_TYPE__ uint_fast8_t,

 ,

♯ define __int_fast8_t_defined 1

 ,

♯ elif __STDINT_EXP(INT_MAX) >,= 0x7f

 ,

typedef signed int int_fast8_t,

 ,

typedef unsigned int uint_fast8_t,

 ,

♯ define __int_fast8_t_defined 1

 ,

♯ endif

I can understand the second case, where uint_fast8_t is just an alias for unsigned int (and without bounds check, it seems). But what does the first case mean? What is __INT_FAST8_TYPE__, and is it set for STM32?

[Tesla DeLorean]

Posted on January 08, 2018 at 19:51

One could benchmark, but I suspect it is about as 'fast' in performance terms as painting a line down the center of your car.

[Lars Beiderbecke]

Posted on January 08, 2018 at 19:58

Well said.  :)