Re: Motion P1788/0024.01: Rounding Mode as Operation -- discussion period begins
Dear 1788 members,
The proposal of Prof. Kulisch has two points:
1. "that every future processor shall provide the 16 operations"
2. "dictate names for the corresponding assembler instructions "
As someone teaching about processor designs and specifically computer arithmetic, I see that the first point is much easier to standardize (but with different wording, see below) than the second. The first point is the more important to the interval community and if present it will enable compiler writers to generate efficient code to the target processor.
We cannot dictate instructions names on so many different implementations in the present and the future. The nomenclature of the various instruction sets of processors is quite different and we will be practically asking the HW vendors to avoid supporting 1788 if we ask for unnecessary requirements. So, I propose that we only stick to the first point.
The wording I propose for the first point is:
"every 1788 compliant system shall provide the ...."
I say "1788 compliant" because we obviously cannot control processors that choose to stay away from 1788 compliance.
I say "system" because we chose 1788 to be on top of 754. The latter speaks about a complete system that might be either SW only, or a combination of SW and HW. I understand that a SW only system will be slow but shall we deny compliance from such an implementation? What if a programmer wants to provide the functionality of 1788 on a current processor family that does not have the required HW support, shall we tell such a person: "No your implementation is not conformant because it does not have HW"?
If we want to encourage the HW implmentation we can say
"and should be implemented directly in hardware for efficiency reasons"
but I do not recommend that we demand that the implementation must be in hardware.
The last issue I would like to bring in this email is the specification of only 16 operations.
Prof. Kulisch specifies
+ - * / Round to Nearest ties to Even (RNE)
+> -> *> /> Round toward Plus Infinitiy (RPI)
+< -< *< /< Round toward Minus Infinity (RMI)
+| -| *| /| Round toward zero (RTZ)
This seems to imply only a binary floating point implementation. To accomodate decimal floating point implementations, the Round to Nearest ties Away from Zero must also be supplied (this rounding direction is a requirement for decimal and is optional for binary in 754). So, we should have at least an additional row of four more operations with this fifth rounding direction to get 20 operations. Moreover, if implemented in real HW the decimal operations will be distinct from the binary operations, that makes a total of 40. Furthermore, most probably each operand size (binary32, binary64, binary128, decimal64, decimal128) also has a distinct set of operations in real HW so if 1788 wants to explicitly specify them all, it becomes 20*5=100 operations at least. I think that we cannot practially list all these *explicitly* in the body of 1788. We may need to think of a way to present the idea in less space.
Dan, Michel, and other folks from 754 please correct me on the above if I erred.
Another wrinkle that I would like to add is what we discussed several times in the 754 list regarding dynamic rounding (the most recent being on 25 May 2010 as far as I can tell). Would it be better to specify a row with "an inherited" rounding as follows?
+e -e *e /e Round to Nearest ties to Even (RNE)
+a -a *a /a Round to Nearest ties to Away (RNA)
+> -> *> /> Round toward Plus Infinitiy (RPI)
+< -< *< /< Round toward Minus Infinity (RMI)
+| -| *| /| Round toward zero (RTZ)
+ - * / Round to whatever is the current "dynamic/global" direction
The last row specifies operations that take whatever global rounding direction there is from their environment. If used within a function, such operations "inherit" the rounding direction of the caller. Will such a scheme enable an easy implementation of both the static (clause 4.1 of 754) and dynamic (clause 4.2 of 754) modes as well as interval work?
Finally, why stop at those four basic operations only? In many of the examples exchanged on the 1788 list we spoke about sqrt for example. Both sqrt and fma are required operations in 754. Shall we include them and make each row consist of 6 columns? Shall we also include other functions mentioned as recommended in clause 9 of 754? Definitely if we include everything I mentioned in this message we will not list the variants explicitly in 1788 but need to think of a way to present concisely.
I guess that I gave you all enough food for thought. I will appreciate any corrections to my ideas so that we all reach a much better 1788.
Thanks
--
Hossam A. H. Fahmy
Associate Professor
Electronics and Communications Department
Cairo University
Egypt