2

Problem

I am working with flash memory optimization of STM32F051. It's revealed, that conversion between floatand int types consumes a lot of flash.

Digging into this, it turned out that the conversion to int takes around 200 bytes of flash memory; while the conversion to unsigned int takes around 1500 bytes!

It’s known, that both int and unsigned int differ only by the interpretation of the ‘sign’ bit, so such behavior – is a great mystery for me.

Note: Performing the 2-stage conversion float -> int -> unsigned int also consumes only around 200 bytes.

Questions

Analyzing that, I have such questions:

1) What is a mechanism of the conversion of float to unsigned int. Why it takes so many memory space, when in the same time conversion float->int->unsigned int takes so little memory? Maybe it’s connected with IEEE 754 standard?

2) Are there any problems expected when the conversion float->int->unsigned int is used instead of a direct float ->int?

3) Are there any methods to wrap float -> unsigned int conversion keeping the low memory footprint?

Note: The familiar question has been already asked here (Trying to understand how the casting/conversion is done by compiler,e.g., when cast from float to int), but still there is no clear answer and my question is about the memory usage.

Technical data

  • Compiler: ARM-NONE-EABI-GCC (gcc version 4.9.3 20141119 (release))
  • MCU: STM32F051
  • MCU's core: 32 bit ARM CORTEX-M0

Code example

  1. float -> int (~200 bytes of flash)

    int main() {
volatile float f;
volatile int i;
i = f;
return 0;
}

  2. float -> unsigned int (~1500 bytes! of flash)

    int main() {
volatile float f;
volatile unsigned int ui;
ui = f;
return 0;
}

  3. float ->int-> unsigned int (~200 bytes of flash)

    int main() {
volatile float f;
volatile int i;
volatile unsigned int ui;
i = f;    
ui = i;
return 0;
}
protango
  • 1,072
  • 12
  • 21
drkr
  • 186
  • 2
  • 7

1 Answers1

1

There is no fundamental reason for the conversion from float to unsigned int should be larger than the conversion from float to signed int, in practice the float to unsigned int conversion can be made smaller than the float to signed int conversion.

I did some investigations using the GNU Arm Embedded Toolchain (Version 7-2018-q2) and as far as I can see the size problem is due to a flaw in the gcc runtime library. For some reason this library does not provide an specialized version of the __aeabi_f2uiz function for Arm V6m, instead it falls back on a much larger general version.

Johan
  • 3,667
  • 6
  • 20
  • 25
  • Thank you, it gives me some clue. Note, I've made all flash size measurements with optimization disabled. – drkr Aug 22 '18 at 15:59
  • @drkr The use of "optimized" in my answer is not related to the compiler settings you use when compiling your code but to the content of the compiler runtime library. I changed the answer to say "specialized" instead. I think this is more correct and less misleading. – Johan Aug 23 '18 at 09:01
  • @drkr even if in this particular case it seems like the answer would be the same, the quality of unoptimized code is not something worth worrying about, you should only care about the quality (size, perf, whatever) of optimized code. – Marc Glisse Aug 23 '18 at 09:06