On those ECUs which support floating-point arithmetic, some ECUs provide status information relating to floating-point operations. Given pmax as the most positive normalized value (farthest from zero), pmin the smallest positive normalized value (closest to zero), nmax the most negative normalized value (farthest from zero) and nmin the smallest normalized negative value (closest to zero), floating-point conditions are reflected in the automatic ASAP2 variables in the following table.
Table 5.23. Automatic ASAP2 entries for floating point conditions
| ASAP2 name | Description | Units |
|---|---|---|
| mpl_flp_overflow | Set if floating-point overflow has occurred since the last reset, clear otherwise. An overflow is said to have occurred if the numerically correct result is such that result > pmax, or result < nmax. See the processor's reference manual for more. | flag |
| mpl_flp_underflow | Set if floating-point underflow has occurred since the last reset, clear otherwise. An underflow is said to have occurred if the numerically correct result is such that 0 < result < pmin, or nmin < result < 0. See the processor's reference manual for more. | flag |
| mpl_flp_div_by_zero | Set if floating-point division by zero has occurred since the last reset, clear otherwise. A divide by zero condition arises when the floating-point operation is executed with a +/-0 divisor value and a finite normalized nonzero dividend value. | flag |
| mpl_flp_inexact | Set if an inexact floating-point result has occurred since the last reset, clear otherwise. An inexact condition arises when the result of a floating-point operation requires rounding (is inexact), or if an overflow or underflow condition arises. | flag |
| mpl_flp_invalid | Set if an invalid floating-point result has occurred since the last reset, clear otherwise. An invalid condition arises when an operand in a floating-point operation contains a denormalized value, infinitity or NaN, or if both operands in a floating-point divide operation are +/-0. | flag |
The platform is likely to cause the inexact condition to occur due to rounding. While the platform has been written to avoid other conditions (such as divide by zero), extreme values passed by the application to the platform may result in the platform causing other conditions to occur.