Hello!
Inspired by an older post, New IEEE 754 Floating point standard, I started thinking about what I'd like to see in a future IEEE 754 standard, so I wrote this blog post: IEEE 754 suggestion: A “core” subset.
In essence, I'd like to see a more light weight core subset without denormals, configurable rounding modes, exceptions and signalling NaN:s. This would be a huge benefit for both software and hardware developers, IMO.
Agner, what are your thoughts on the matter?
Suggestion: An IEEE 754 core subset
Re: Suggestion: An IEEE 754 core subset
Yes, I agree that there is a trade-off between efficiency and strict adherence to the IEEE-754 floating point standard.
Subnormal numbers are expensive to support in hardware, and rarely needed.
The features of out-of-order execution and SIMD or vector processing were not well known when the IEEE-754 standard was first designed. Two aspects of the standard are particularly problematic for these new technological developments: Exception trapping and a global status register. The standard assumes that the computer is doing one operation at a time. When an error occurs, it is supposed to trap an exception or set a status register. This concept breaks down when the CPU is doing multiple things at the same time and out of order. I have been discussing these problems elsewhere. The best solution I can think of is to produce a NAN with a payload that tells the kind of error. This NAN can then propagate through a chain of calculations to be detected at the end.
See also my disucssion at https://www.forwardcom.info/forum/viewt ... ?f=1&t=124 and https://www.agner.org/optimize/nan_propagation.pdf.
The trapping of floating point exceptions is rarely used nowadays, and many programming languages don't even support it. Signaling NANs, too, are rarely used except for NAN boxing.
Subnormal numbers are expensive to support in hardware, and rarely needed.
The features of out-of-order execution and SIMD or vector processing were not well known when the IEEE-754 standard was first designed. Two aspects of the standard are particularly problematic for these new technological developments: Exception trapping and a global status register. The standard assumes that the computer is doing one operation at a time. When an error occurs, it is supposed to trap an exception or set a status register. This concept breaks down when the CPU is doing multiple things at the same time and out of order. I have been discussing these problems elsewhere. The best solution I can think of is to produce a NAN with a payload that tells the kind of error. This NAN can then propagate through a chain of calculations to be detected at the end.
See also my disucssion at https://www.forwardcom.info/forum/viewt ... ?f=1&t=124 and https://www.agner.org/optimize/nan_propagation.pdf.
The trapping of floating point exceptions is rarely used nowadays, and many programming languages don't even support it. Signaling NANs, too, are rarely used except for NAN boxing.
-
mathygreen
- Posts: 1
- Joined: 2021-05-31, 18:10:37
Re: Suggestion: An IEEE 754 core subset
I think that it would be great if the IEEE 754 standard could be split into a light weight “core” subset, and a “full” feature set (the latter being more or less identical to the current standard).
Compared to the full version, the core subset would have the following properties:
No denormalized numbers. All denormalized numbers are treated as zero, and any result that would be a denormalized number will be turned into zero (a.k.a. “flush-to-zero”).
Only a single rounding mode: Round to nearest, ties to even (the default rounding mode in IEEE 754).
No exceptions. Any operation that would throw an exception will silently produce a well defined result (e.g. sqrt(-1) will return NaN).
All NaN:s are treated as quiet NaN:s. There are no signalling NaN:s.
Compared to the full version, the core subset would have the following properties:
No denormalized numbers. All denormalized numbers are treated as zero, and any result that would be a denormalized number will be turned into zero (a.k.a. “flush-to-zero”).
Only a single rounding mode: Round to nearest, ties to even (the default rounding mode in IEEE 754).
No exceptions. Any operation that would throw an exception will silently produce a well defined result (e.g. sqrt(-1) will return NaN).
All NaN:s are treated as quiet NaN:s. There are no signalling NaN:s.
Re: Suggestion: An IEEE 754 core subset
I am in contact with the IEEE 754 working group. Most of these issues have been discussed.
The different rounding modes are required by the standard, even though they are rarely used outside of conversion to integer.
It is unclear whether subnormal (denormal) numbers must be supported. The latest standard says:
I agree that signaling NANs should not be required. I have never seen signaling NANs used for the intended purpose.
Exception trapping is rarely used today. Most compilers will refuse to use vector instructions when exception trapping is enabled. This should be degraded to an optional feature.
In addition to the binary floating point format, there are two decimal floating point formats. The motivation is to make exact financial calculations, such as adding monetary amounts with two decimals without rounding errors. I am against the decimal floating point format because it is making the standard very kludgy, and the same precision can easily be obtained in other ways. However, there are commercial interests promoting the decimal floating point format, so I don't think we can get rid of it.
My plans for ForwardCom are as follows:
The ForwardCom standard prescribes ways of specifying rounding modes. Different rounding modes are supported for conversion from floating point to integer. Arithmetic instructions such as addition and multiplication may or may not support all the rounding modes.
Subnormal numbers will be supported for half precision floating point. Support for subnormal numbers in single and double precision is optional.
Signaling NANs are not supported. They will behave as quiet NANs.
It is not recommended to support exception trapping in ForwardCom. Information about floating point exceptions can be propagated through NAN payloads instead. I am trying to convince the IEEE 754 working group to allow this solution.
The different rounding modes are required by the standard, even though they are rarely used outside of conversion to integer.
It is unclear whether subnormal (denormal) numbers must be supported. The latest standard says:
I think this can be interpreted so that it is allowed to say subnormal = tiny = underflow.The implementer shall choose how tininess is detected
I agree that signaling NANs should not be required. I have never seen signaling NANs used for the intended purpose.
Exception trapping is rarely used today. Most compilers will refuse to use vector instructions when exception trapping is enabled. This should be degraded to an optional feature.
In addition to the binary floating point format, there are two decimal floating point formats. The motivation is to make exact financial calculations, such as adding monetary amounts with two decimals without rounding errors. I am against the decimal floating point format because it is making the standard very kludgy, and the same precision can easily be obtained in other ways. However, there are commercial interests promoting the decimal floating point format, so I don't think we can get rid of it.
My plans for ForwardCom are as follows:
The ForwardCom standard prescribes ways of specifying rounding modes. Different rounding modes are supported for conversion from floating point to integer. Arithmetic instructions such as addition and multiplication may or may not support all the rounding modes.
Subnormal numbers will be supported for half precision floating point. Support for subnormal numbers in single and double precision is optional.
Signaling NANs are not supported. They will behave as quiet NANs.
It is not recommended to support exception trapping in ForwardCom. Information about floating point exceptions can be propagated through NAN payloads instead. I am trying to convince the IEEE 754 working group to allow this solution.