IEEE 754 is the dominant standard defining formats and rounding rules for binary (and decimal) floating-point arithmetic, covering 32-bit single-precision, 64-bit double-precision, and several other widths. It specifies representation, the four rounding modes, five exceptions (overflow, underflow, division by zero, invalid operation, inexact), and special values such as infinity, negative zero, and NaN.
In practice
In embedded C and C++, `float` maps to IEEE 754 single-precision (32-bit: 1 sign bit, 8 exponent bits, 23 mantissa bits) and `double` maps to double-precision (64-bit: 1 sign, 11 exponent, 52 mantissa) on most toolchains targeting ARM Cortex-M, RISC-V, and x86-class MCUs. Smaller cores such as 8-bit AVRs and many PIC variants have no hardware FPU; on those targets the compiler emits software floating-point routines that are functionally IEEE 754 compliant but carry a significant code-size and cycle-count penalty compared to integer operations.
Hardware FPU support varies widely. Cortex-M4F cores include a single-precision FPU; Cortex-M7 cores include a single-precision FPU and optionally a double-precision FPU, depending on the specific implementation chosen by the silicon vendor. Cortex-M0/M0+/M3 cores have no FPU. Enabling the FPU in startup code (setting CPACR bits, using `-mfpu=fpv4-sp-d16 -mfloat-abi=hard` on ARM GCC) is a common bring-up task; if the FPU is present but not correctly enabled, the resulting behavior depends on the ABI and fault configuration and may not simply fall back silently to software emulation. On resource-constrained targets, the blog post "Data Types for Control & DSP" and "Never use Float or Integer" both discuss when fixed-point arithmetic is a practical alternative.
A recurring pitfall is assuming floating-point results are exact. IEEE 754 guarantees that each individual operation is rounded to the nearest representable value (in the default round-to-nearest-even mode), but accumulated rounding error across a sequence of operations can grow. Comparisons like `if (x == 0.1f)` are almost always wrong. Compilers may also perform expression contraction (such as fused multiply-add) when permitted by compiler options, target hardware, and language mode, which can change results relative to strictly sequential rounding. "Understanding and Preventing Overflow" covers related issues with numeric representation limits.
Another embedded-specific concern is that some DSP cores and older FPUs implement a "flush-to-zero" (FTZ) or "denormals-are-zero" (DAZ) mode for performance. When enabled, denormalized numbers (values smaller than ~1.18e-38 for single precision) are silently treated as zero, which is technically non-compliant with full IEEE 754 but acceptable in many signal-processing contexts. Developers should check FPU control register settings (e.g., FPSCR on ARM) if reproducibility across platforms matters.
Frequently asked
Does every embedded processor support IEEE 754 in hardware?
No. Many 8-bit and 16-bit cores (AVR, PIC16/18, MSP430) have no hardware
FPU at all; IEEE 754 operations are handled by software libraries. Among 32-bit Cortex-M devices, cores such as the M4F, M7, M33 (with FPU option), and M55 can include a hardware FPU, but FPU presence and configuration ultimately depend on the specific silicon implementation. Always check your specific silicon's data sheet and confirm your
toolchain is configured to use the hardware unit.
What is the precision limit of a 32-bit IEEE 754 float, and why does it matter?
A single-precision float has a 23-bit significand, giving about 7 significant decimal digits. This means integers larger than 16,777,216 (2^24) cannot all be represented exactly. For embedded control loops accumulating timestamps,
encoder counts, or large integer sensor values in a float, this can introduce silent truncation errors. Using a 64-bit double extends the significand to 52 bits (~15 significant digits), but doubles are expensive or unsupported in hardware on many MCUs.
What are NaN and infinity in IEEE 754, and can they cause problems in firmware?
NaN (Not a Number) is produced by operations such as 0.0/0.0 or sqrt(-1.0); infinity results from overflow or division of a finite number by zero. Both propagate silently through subsequent calculations unless explicitly checked. In safety-critical firmware, undetected NaN propagation can corrupt control outputs for many cycles before a fault becomes visible. Enabling the
FPU's invalid-operation exception trap (if the hardware supports it) or adding explicit range checks at
DSP boundaries helps catch these early.
Should I use float or fixed-point arithmetic on a Cortex-M0 target?
For a Cortex-M0 or M0+ (no
FPU), software
floating-point routines typically cost dozens to hundreds of cycles per operation and add several kilobytes of library code.
Fixed-point arithmetic using integer instructions is usually faster and smaller. The trade-off is added complexity in scaling and saturation logic. The blog posts 'Data Types for Control &
DSP' and 'Never use Float or Integer' discuss this decision in detail. For an M4F or M7 with the FPU enabled, single-precision float is often the pragmatic default.
What does 'flush-to-zero' mode do, and when should I enable it?
Flush-to-zero (FTZ) makes the
FPU treat denormalized results as zero instead of computing the gradual-underflow value required by full IEEE 754. This avoids the large performance penalty some FPUs incur when handling denormals. On ARM Cortex-M FPUs, FTZ is controlled by the FZ bit in the FPSCR register. Enable it when maximum throughput matters and you are confident denormalized values will not occur in normal operation, or when their presence would indicate a signal-chain fault anyway. Disable it if you need strict IEEE 754 compliance or cross-platform reproducibility.
Differentiators vs similar concepts
IEEE 754 is sometimes conflated with the C-language types `float` and `double`. The C standard (
C99 and later) does not mandate IEEE 754; it allows but does not require conforming implementations to use it. In practice, essentially all desktop and most embedded
toolchains targeting hardware with an IEEE 754
FPU do use it, and compilers may define `__STDC_IEC_559__` to signal full conformance. Separately, IEEE 754-2008 (and its 2019 revision) added decimal
floating-point formats (decimal32, decimal64, decimal128) aimed at financial computing; these are rarely relevant in embedded contexts and are distinct from the binary formats that `float` and `double` use.
