4 ms·

You have to be very careful using floating point on embedded processors not only for the reasons in this website, but for speed too! Unless you have a separate

You have to be very careful using floating point on embedded processors not only for the reasons in this website, but for speed too! Unless you have a separate floating-point core (ARM Cortex M4s have one, M3s do not) it can take 1,000's of clock cycles to perform any floating point math like addition, multiplication, etc. Even with a floating point processor you need to be careful when switching into and out of interrupts! The floating point core has it's own set of registers you need to keep track of. Doubles are even worse! Basically it is almost always better to use integers when you can, and be aware of what types you are using (always important in C anyways).

petermcneeley 7y ago
Something seems off about your numbers given that you can emulate fp with integer ops in much less than 1000 instructions.
- gpderetta 7y ago
  probably because on cpu without fp units, fp instructions cause invalid instruction exceptions to be raised that need to handled by the kernel, and that can be very expensive (that used to be a thing on x86 in the past).
  - Symmetry 7y ago
    Kernel? What kernel? You probably aren't using a separate kernel with an M3, though you might have an RTOS. You'll, as a rule, have the compiler putting the floating point emulations in directly. I think the performance hit is only around a factor of 100 or so for an M3 though.
- brandmeyer 7y ago
  It is way off. GCC has had optimized assembly routines for performing software floating point on ARM that run in dozens of cycles. IIRC, the license is liberal enough that LLVM could copy them by-value into their compiler support libraries without difficulty, so I would just assume that they were until proven otherwise.
- roland35 7y ago
  I am referring to gcc on an ARM Cortex M3/4 processor (Tiva TM4C123). I measured this using Texas Instrument's code composer studio a few years ago, with no optimizations (just with some basic test like 1.3 * 3.5 = ?) without the FPU enabled. Maybe there are better ways to do it, I could be wrong!
gnode 7y ago
A related issue is that software floating point must be used in the Linux kernel. Because floating point is rarely needed in kernel programming, FPU registers are not swapped when execution switches between kernel and user code. Instead, they're only switched when context switching between different processes using the FPU, and initially processes run with floating point instructions disabled. > Basically it is almost always better to use integers when you can I'd say: understand the limitations of FP, but it's almost always better to use them unless you have some particular precision or performance requirement. Then again, my experience of FP is mostly in graphics, where IEEE 754 single precision is good enough for almost anything you'd want, and hardware FP is commonplace.
Symmetry 7y ago
And in most cases your "floating point" calculations are tied to sensor values with known precision. If you have a pressure value from a sensor with a precision of 2 mBar then it often make sense to just do calculations in fixed point in those terms. But make sure you document your structs for units!
- roland35 7y ago
  yes fixed point is a good alternative. Floating point can get you in trouble if you are testing for equality too, i.e. pressure == 2 mBar. I've seem people always put a threshold around it, so something like pressure <= 2.1 mbar AND pressure >= 1.9 mbar
brandmeyer 7y ago
When targeting machines like Cortex-M4, be sure to add -Wdouble-promotion. Single-precision floats are executed in hardware, but double-precision floats are executed in software. Called cos() when you meant cosf()? Done in software. Multiplied by 2.25 when you meant 2.25f? Done in software. -Wdouble-promotion will help you find those performance bugs.

petermcneeley 7y ago

Something seems off about your numbers given that you can emulate fp with integer ops in much less than 1000 instructions.

gpderetta 7y ago
probably because on cpu without fp units, fp instructions cause invalid instruction exceptions to be raised that need to handled by the kernel, and that can be very expensive (that used to be a thing on x86 in the past).
- Symmetry 7y ago
  Kernel? What kernel? You probably aren't using a separate kernel with an M3, though you might have an RTOS. You'll, as a rule, have the compiler putting the floating point emulations in directly. I think the performance hit is only around a factor of 100 or so for an M3 though.
brandmeyer 7y ago
It is way off. GCC has had optimized assembly routines for performing software floating point on ARM that run in dozens of cycles. IIRC, the license is liberal enough that LLVM could copy them by-value into their compiler support libraries without difficulty, so I would just assume that they were until proven otherwise.
roland35 7y ago
I am referring to gcc on an ARM Cortex M3/4 processor (Tiva TM4C123). I measured this using Texas Instrument's code composer studio a few years ago, with no optimizations (just with some basic test like 1.3 * 3.5 = ?) without the FPU enabled. Maybe there are better ways to do it, I could be wrong!

gnode 7y ago

A related issue is that software floating point must be used in the Linux kernel. Because floating point is rarely needed in kernel programming, FPU registers are not swapped when execution switches between kernel and user code. Instead, they're only switched when context switching between different processes using the FPU, and initially processes run with floating point instructions disabled. > Basically it is almost always better to use integers when you can I'd say: understand the limitations of FP, but it's almost always better to use them unless you have some particular precision or performance requirement. Then again, my experience of FP is mostly in graphics, where IEEE 754 single precision is good enough for almost anything you'd want, and hardware FP is commonplace.

Symmetry 7y ago

And in most cases your "floating point" calculations are tied to sensor values with known precision. If you have a pressure value from a sensor with a precision of 2 mBar then it often make sense to just do calculations in fixed point in those terms. But make sure you document your structs for units!

roland35 7y ago
yes fixed point is a good alternative. Floating point can get you in trouble if you are testing for equality too, i.e. pressure == 2 mBar. I've seem people always put a threshold around it, so something like pressure <= 2.1 mbar AND pressure >= 1.9 mbar

brandmeyer 7y ago

When targeting machines like Cortex-M4, be sure to add -Wdouble-promotion. Single-precision floats are executed in hardware, but double-precision floats are executed in software. Called cos() when you meant cosf()? Done in software. Multiplied by 2.25 when you meant 2.25f? Done in software. -Wdouble-promotion will help you find those performance bugs.