| |||
| Home > Floating-point support > Exception types recognized by the ARM floating-point environment | |||
The ARM floating-point environment recognizes the following types of exception:
The Invalid Operation exception. This occurs when there is no sensible result for an operation. This can happen for any of the following reasons:
performing any operation on a signaling NaN, except the simplest operations (copying and changing the sign)
adding plus infinity to minus infinity, or subtracting an infinity from itself
multiplying infinity by zero
dividing 0 by 0, or dividing infinity by infinity
taking the remainder from dividing anything by 0, or infinity by anything
taking the square root of a negative number (not including minus zero)
converting a floating-point number to an integer if the result does not fit
comparing two numbers if one of them is a NaN.
If the Invalid Operation exception is not trapped, these operations return a quiet NaN. The exception is conversion to an integer. This returns zero because there are no quiet NaNs in integers.
The Divide by Zero exception. This occurs if you divide a finite nonzero number by zero. Be aware that:
dividing zero by zero gives an Invalid Operation exception
dividing infinity by zero is valid and returns infinity.
If Divide by Zero is not trapped, the operation returns infinity.
The Overflow exception. This occurs when the result
of an operation is too big to fit into the format. This happens,
for example, if you add the largest representable number to itself.
The largest float value is 0x7F7FFFFF.
If Overflow is not trapped, the operation returns infinity, or the largest finite number, depending on the rounding mode.
The Underflow exception. This can occur when the
result of an operation is too small to be represented as a normalized
number (with Exp at least 1).
The situations that cause Underflow depend on whether it is trapped or not:
If Underflow is trapped, it occurs whenever a result is too small to be represented as a normalized number.
If Underflow is not trapped, it only occurs if the
result requires rounding. So, for example, dividing the float number 0x00800000 by
2 does not signal Underflow, because the result 0x00400000 is
exact. However, trying to multiply the float number 0x00000001 by
1.5 does signal Underflow.
For readers familiar with the IEEE 754 specification, the chosen implementation options in the ARM compiler are to detect tininess before rounding, and to detect loss of accuracy as an inexact result.
If Underflow is not trapped, the result is rounded to one of the two nearest representable denormal numbers, according to the current rounding mode. The loss of precision is ignored and the system returns the best result it can.
The Inexact Result exception happens whenever the result of an operation requires rounding. This would cause significant loss of speed if it had to be detected on every operation in software, so the ordinary floating-point libraries do not support the Inexact Result exception. The enhanced floating-point libraries, and hardware floating-point systems, all support Inexact Result.
If Inexact Result is not trapped, the system rounds the result in the usual way.
The flag for Inexact Result is also set by Overflow and Underflow if either one of those is not trapped.
All exceptions are untrapped by default.
IEEE Standard for Floating-Point Arithmetic (IEEE 754), 1985 version