RBK> As it stands now, we wouldn't base things STRICTLY on 754, since motion 3 passed, and since 754 treats
RBK> Infinity as a number. Since motion 3 states that we are only dealing with reals, we would be interpreting
RBK> the symbol Infinity the same as overflow, n'est pas?
Of course you're right about the standard and the decisions that have been made.
I look at things like this from the implementer's point of view, and from my personal assumption that the only implementations for five to ten years will be software without custom hardware, and that any hardware will be incrementally different from now, not entirely redesigned.
That could be very wrong, but from that perspective, the questions become "How can 1788 be implemented with available hardware?" and "What simple hardware changes would handle 1788 and still handle 754 as efficiently as now?"
(Obviously I also assume that 754 will still be around; in fact, I think it will stay dominant. In fact, decisions which have been and will be made by our committee will help ensure that. Lest that be misunderstood, I mean that the committee's objective is to produce the best (we just don't all agree what best is) standard for Interval Arithmetic. It is not to produce something that supersedes 754, because that would require more compatibility with 754 than we're willing to accept.)
When I think about those two implementation questions, and look at the Real operations necessary to implement Intervals, I see complications. One is that a multiply of 0 times infinity must produce 0 instead of NaNQ. As you say, "we would be interpreting the symbol Infinity the same as overflow". The problem is that today's hardware won't be.
An alternate multiply instruction would solve that, but I'm assuming that won't exist at least for a long time.
So would a mode bit, but you can execute dozens of other instructions in the time it takes to save the mode, change it, and later restore it, so you don't want to mix 1788 and 754 in the same program, and in any case I'm assuming a mode bit won't exist either.
Or you can use software. For each Real multiply, one could do a 754 multiply and fix it up afterwards. If it produced a NaN, and assuming neither input was a NaN, then change it to a zero. It's way too expensive to allow a trap to happen, and too expensive to call a function for every multiply, so that would be done by inline code. A multiply plus detecting and rewriting the NaN would take 2 to 10 times as long as just a multiply depending on the CPU, for scalars. It would prohibit pipelining and SIMD vectors, so the net cost would be up to 100 times slower than a standard floating point multiply (10 to 25 cycles per result, versus 4 results per cycle on today's hardware.)
You could use an interrupt to a trap handler to do the fixup. You'd need to set the 754 mode correctly (maybe with saves and restores) and initialize the trap handling and deal with this architecture's instruction set and this operating system's handling, then to handle 0 * Infinity pay maybe five thousand cycles to get in and out, but in typical cases you'd avoid that.
Another alternative would be if the same instruction just automatically produced the right answer without changing modes, for either 754 or 1788. Since the problem is distinguishing the 1788 "limit value" which is finite from the 754 "limit value" which is infinity, my natural question was whether there could be two different limit values. My conclusion was that **IF** 754 had been defined with separate Overflow and Infinity, (1) 754 would have been better, and (2) 1788 could be implemented with the same multiply as that hypothetical 754++. If overflows produced Overflow and operations on it were reasonably defined, then 754++ would make just a little more sense than 754 does, and 1788 could use Overflow as its limit value, refrain from using Infinity, and be just as well off as planned. The benefit in this hypothetical situation would have been that a 1788 interval multiply could be implemented using the standard 754++ multiply (plus some decoration handling which wouldn't harm 754).
Another simplification comes from the meaning of the inf-sup interval end points. The current 1788 approach is that whether that end is open or closed depends on whether the limit value is infinite or not. A bound of 5 is included in the set, but a bound of infinity is excluded. That complicates comparisons. Using Overflow instead of Infinity avoids the complication.
At the risk of frightening everybody, you might even find that the 754++ Infinity was a reasonable representation for what you get when you divide a non-zero by zero, or similar operations. Just think of it as a form of empty interval with built in decoration saying how it was created, produced for free by 754-based hardware. Or forget I mentioned it.
I mostly skipped over decorations. Maintaining those without custom hardware also has challenges. It's an area for which hardware support might be more feasible, though, because it doesn't need to break 754 compatibility. Also, separating Overflow from Infinity slightly simplifies the decorations one needs.
If you've either read this far or skipped to the end, please remember that I'm not pushing 1788 to adopt Overflow, or saying that it doesn't introduce new issues, just saying that hypothetically in my dream universe if 754 already had it then some things would have been simpler to implement and would have run much faster without new hardware. Other projects have shown that neither simplicity nor speed is essential to a standard.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
Ralph Baker Kearfott ---09/21/2010 06:45:08 PM---Ian, 1788: On 9/20/2010 10:03, Ian McIntosh wrote: