The IEEE 754R committee met March 21, 2002 at Network Appliance. In attendance were:
Mike Cowlishaw has a proposal for decimal arithmetic. Dan Zuras suggested we turn to this in April, when Cowlishaw will be in town.
Cowlishaw briefly covered some background for his proposal. IBM has observed increasing customer use of decimal arithmetic in recent years. Decimal is used in banking to compute interests, by telecommunications companies to compute taxes on individual accounts, and so forth. Until now, a variety of implementations have been used. In the past couple years, there has been some industry agreement about how to do decimal arithmetic, with Sun, Microsoft, and IBM all involved. All the implementations are software packages, and all are slow -- 100 to 1000 times slower than binary arithmetic in the very best cases. In some applications, the decimal calculations make up 25 to 30 percent of the computing time; Cowlishaw mentioned one example that is 89 percent decimal computations. Because of the large fraction of time spent in decimal calculation, IBM is actively investigating putting decimal support into their hardware.
The existing 854 standard specifies the mathematics of decimal arithmetic, but not the representation. The lack of a common format is a gap in the current standardization. In order to integrate 854 into 754, we will need to specify the layouts. This makes the standard relevant not only to mathematicians and scientists, but to a vastly broader audience. IBM could propose its own decimal format, but then they would run the risk that a different format might be come the standard (de facto or official). IBM has put together a proposal they feel embodies their requirements. That proposal has been around for a couple years, and so there has been time for feedback. IBM plans to make a formal proposal some time later this year, and would like to preview the proposal to the committee in order to review the background and get initial reactions. In particular, IBM would like to know whether they are on the right track, and whether there is any hope of making a standard by next year.
Dan Zuras asked whether the arithmetic was compatible with 854 as currently implemented, and whether the proposal is primarily a proposal for format specification. Mike Cowlishaw replied that this is primarily a format proposal, and, with a few discrepancies that he thinks can be worked out, the proposal is compatible with 854.
Kahan commented that he saw two parts to the IBM proposal. One part is a compact encoding for decimal numbers of various widths; that would make it easier to share decimal numerical data among machines, a point which is key to 754 and which 854 omits entirely. The other part is about guiding widths of precision; but this discussion also applies to fixed point arithmetic. Since it is not clear that fixed point and floating point arithmetics should be treated in the same manner, the latter proposal could lead to many long discussions. Cowlishaw responded that the plan was to initially concentrate on formats, and deal with recommendations guiding choice of precision later. He also noted that this really is not fixed point in a traditional sense. In particular, redundant encodings are allowed in which zeros are explicitly preserved. Kahan replied that he thinks the preservations of explicit zeros will be an important part of our debates.
Cowlishaw stated that IBM will not come out with hardware without at least some initial feedback from the committee. He hopes people will keep the requirements of decimal in mind while dealing with other issues. Primarily, he wants to ascertain that there are no major objections to the inclusions of decimal formats into the standard work. Kahan repeated that he foresees some objections.
The recommended reading before the April meeting is the encoding paper, which is first on the list of papers linked from IBM's decimal page. There is also a link from the 754R web page.
Jim Thomas spoke about the goal of compatibility between 754 and 754R. His presentations slides are available from the links under the past meetings section on the 754R web page. The discussion is summarized below; when others are not explicitly cited, the words paraphrase Thomas's presentation.
In the minutes from the first several meetings, there was a boilerplate that seemed to suggest that upward compatibility was a central goal, and that existing implementations will remain conforming. What does "upward compatible" mean? Thomas proposed that this means that 754 can be upgraded to 754R, without invalidating correct programs, in a manner that is technically and commercially feasible. Thomas then proposed two items which he felt were almost (but not quite) implications of this meaning:
There were several objections to these two items. Jason Riedy asked which languages were meant: just C and Fortran, or Ada, Lisp, Java, APL, Forth, etc? Kahan asked whether Thomas meant "correct programs that could have been written" or "correct programs that have been written?" Dan Zuras also observed that there is a question about what is meant by a "correct" program under 754. Zuras further pointed out that one of our ongoing goals has been to remove ambiguity from the standard, which, by definition, opens the possibility that some implementations may not conform to the new, stricter, standard. Our choice to prohibit one oddball rounding in underflow, for instance, did not seem particularly egregious at the time. In each case, it will take a lot of work to upgrade to 754R (if an implementation fails to conform to our choice of disambiguation); but the work is not terrible.
Thomas stated that an implementation conforms to the 754 specification, a program requires the spec, and 754R requires changes that would break the program, then that would break compatibility. David Hough objected that this wording is too vague, and suggested it would be more productive to look at specific examples. For instance, if a program depends on one type of underflow, would that program be correct in 754R? Zuras responded that such an example would not be correct even in 754; David Scott pointed out that the program would not be portable, but that correctness was a separate issue.
Thomas noted that there are few programs which would be portable across any 754 implementation; if nothing else, such programs could only use single precision. Kahan suggested that what is meant by a "correct program" must be conditioned on the statement that required capabilities are available.
Zuras stated that one consequence of the acceptance of 754 was that programs people would never even have considered porting between machines could now be conceivably written portably. The situation now is much better than it was prior to 754. Much of what we are now trying to do with this standard is to tighten the specification further to ensure that we can port NaNs, standardize binary-to-decimal conversion, and a variety of other niggling things.
Hough recalled that someone once suggested the first sentence of the standard grandfather in implementations conforming to 754. Thomas replied that something is wrong if programs cannot run on both systems.
Kahan thought Jim Thomas had a strong point when he said we should not break perfectly good existing programs. At the very least, we should try not to do so intentionally. A conversion to integer operation that relies on the inexact signal is an example. Kahan thought nobody other than writers of test programs ever relied on that particular feature, but those test programmers might be unhappy if the feature was taken away. David Scott retorted that those who try to write portable test programs may be thrilled.
We then moved to the next slide, and Jim Thomas suggested that hardware implementers be formally protected by grandfathering. He would like the grandfathering to extend to future versions of existing processor lines as well as to current implementations. Hough objected that all we specify in the standard is the programming environment. Zuras responded that we sometimes implicitly assume fast support, or at the very least specify policies that favor one style of implementation over another. Kahan thought that favoring particular implementation strategies would be a good idea, as long as others were not outlawed.
Thomas noted that different hardware vendors have different meanings of "commercially feasible."e; Some things might be perfectly reasonable for HP and Sun, but not for smaller processors. Kahan suggested that the opposite might be true, since embedded processors typically implement much of their floating point support in microcode, which may be easier to extend. David Scott and David Hough both also pointed out that embedded processor designers have a smaller installation base to worry about (someone else countered that there are a lot of cell phones in the world).
Jim Thomas replied that people do write floating point programs for embedded processors, and we should keep that in mind. Kahan asked whether the companies even claimed these processors support the standards. He noted that most languages also provide little support for the standard; take any pre-C99 C compiler, for instance.
Chris Hinds said that ARM does claim compliance with 754, with the appropriate support code. But they have to look ahead from a commercial standpoint to what customers will want. Hinds thought Thomas had a good point, and stated that a truly terrible outcome would be if vendors were forced to support two distinct versions of 754. Hinds also expressed the opinion that the FMA in 754R is one of the hardest things to swallow. Debjit Das Sarma agreed, and said he wanted FMA as a "should" rather than a "shall."
Kahan said that if FMA runs too slowly on some machines, people will have to worry about whether to do FMA or not on different platforms. That already exists for division, for instance. For FMA, there are a few places you really want FMA; a few places you really don't; and in most places you don't care. The speed of the FMA will be determined by market conditions. Zuras replied that Kahan was pointing out just what we feared. We are trying to create a situation where everyone moves over to the new standard, eventually. We don't want to go so far out in the weeds that everyone stays with 754.
Thomas noted that, though software support does allow hardware implementors leeway, the slowness of software can be a competitive disadvantage. Also, what if government contracts specify that the new floating point standard be used, perhaps unnecessarily? Upward compatibility also matters in programming environments: compilers and their supporting libraries. The same question exists of what constitutes "commercially feasible" changes -- feasible for whom? Support for existing user code, even existing binary code, is essential. Zuras noted that HP even went to the point once of deliberately retaining a bug because a big enough customer made use of it.
Kahan stated that claims of compatibility even in the existing environment are often illusory. Intel claims upward compatibility. So does Windows. But Kahan has programs that work fine on Windows NT, NT4, 98, and then fail under Windows 2K. Placing the full onus of compatibility on ourselves is too much to bear -- there are too many factors out of our control. All we can do is try not to derail a program that should have worked.
Dan Zuras thought that, as a practical matter, should (and in case of FMA did not) create a situation in which existing implementations can easily move to the new standard in all cases.
Jim Thomas restated his point: companies who support specific programming environments care greatly about compatibility for their existing code base (and do not necessarily care that their code should be universally portable). Chris Hinds phrased it as wanting vertical compatibility (within a company) rather than horizontal compatibility. We should be wary of creating a situation in which incompatibilities are forced by the new specification (e.g. forcing a new meaning for the same opcode).
Debjit San Das worried about the competitive disadvantage a few years from now when codes use the features of the new standard. That's why he wants "should" instead of "shall" for FMA. Jason Riedy objected that there is already a "shall" in C99 -- and while the C99 spec is admittedly a software standard, so is 754R.
This discussion lead Jim Thomas to his last point: support for language standards might impede or drive the change from 754 to 754R. C99 and Unix 2000 support 754, but it takes a 5-10 year lead time to make a substantial change in such standards. Even if we are not breaking upward compatibility, adding similar but different features may burden implementors, confound programmers, and weaken the standard.
The Fortran, C++, and Java floating point models are evolving. Language committees are not floating point committees (and vice-versa!). They really do need floating point advice, though they may not know it. A floating point standard carries weight with these committees; on the other hand, if the floating point standard is in flux, that can undermine the work in the language committees.
Application developers are also affected. People dislike platform diversity. Use of 754 has been limited by slow addition of language support. If it seems like 754 is going to change a lot, that will make programmers even more wary of using the 754 features. End users at "top of food chain" need the applications, the programming languages, and the hardware all to have support in order to benefit.
What does the upward compatibility goal imply for 754R? We should not break upward compatibility unless benefit is compelling (and "compelling" is too low a bar according to some in HP). Each proposal should include consideration of compatibility impact. Proposals that would change language standards should show a feasible upward compatible extension to the relevant standard. Don't add similar but different features (even if they are legally upward compatible) unless benefit is compelling.
Kahan thought the goal sounded reasonable, even if we disagreed with some of the reasoning. Several others concurred.
Besides FMA, the quiet NaN specification has serious impact on PA-RISC; the first fraction bit flags quiet versus signalling, but the sense is different on Intel and HP (Itanium is a different story). The compatibility impact of ilogb is harder to evaluate; it is very similar to the C99 ilogb be, but we have proposed returns for special values in an incompatible way.
Since so many points were repeated during the meeting, the following draft review minutes are a substantial abbreviation of the actual discussion. Nevertheless, they are sufficiently long that I will start with the summary:
David Hough proposed more names for table 4; for a few operations, there were several suggestions. Objectors to the proposed names noted that they were difficult to decipher and were unlikely to be adopted by implementors. We decided to spell out the predicates in ordinary English (e.g. as "quiet greater than or equal to") and let language implementors decide on appropriate names for their environments.
We discussed why the table specifies all the predicates it does, even though many of them rarely have language bindings and are infrequently used. Several people noted that the table plays an educational purpose: it makes the point that floating point numbers are not a fully ordered set, and so do not obey the law of trichotomy. Kahan suggested that all the operations in the table should be required, but some might be implemented in software. Thomas objected that including a full list imposes an additional burden on the programmer, who might feel compelled to figure out what all the options mean. We decided that the first six operations in the table will be "shall," the next seven "should," and the status of the remainder will be subject to further debate.
Having finished our monthly discussion of table 4, we turned to the question of what information a trap handler should receive when a gross over/underflow occurs during a scaling or conversion operation. Hough proposed that either the original operands or a normalized result and the base-2 log of the normalizing factor be returned. In the latter case, the scaled operand would be returned in the destination format, while the exponent adjust could be returned in an integer or floating-point format.
Riedy asked whether the above choice introduces a new ambiguity that we should avoid. Kahan thought it is unnecessary to rule out the possibility of returning the normalized operand and corresponding exponent. Most of the rest of those present thought that delivering the source operand seemed the most reasonable implementation. Chris Hinds thought it regrettable from the perspective of future out-of-order issue and retirement processor designers that any result (either the operands or normalized result and exponent) be required by the trap handler. Others asked whether this issue should be delayed until after the discussion of whether the philosophy of trap handling as a whole should change. Several people thought that gross range exceptions posed a special challenge regardless of what we do to trap handling. Despite Zuras's comment that "Flexible is ambiguous with a suit on," we eventually decided to let Hough's wording stand for the present.
We next turned to the nextdown and nextup functions. Jim Thomas asked whether nextdown and nextup were just nextafter(x, -INF) and nextafter(x, INF). If so, why not define nextup and nextdown in terms of nextafter? Kahan noted that, while nextafter used to signal on overflow and underflow, it does not do so in our current wording. This is a case where Jim Thomas might worry about a program (which Kahan thinks probably does not exist in practice) that uses those signals. We also need to worry about language standards. We eventually decided to defer discussion of nextup and nextdown until after revisiting the discussion of nextafter's signalling behavior.
The function formerly known as "conv" is now known by the less vague name "stringtofloating." Otherwise, our discussion of nextdown and nextup concluded the draft review.
Jim Thomas agreed to explore contact with the XJ311 folks. Nobody was sure who to contact in X3J3.
Mike Cowlishaw will talk at the April meeting. We propose to turn to alternatives to trap handling in May; Hough and Kahan both have ideas on the subject.
Upcoming meetings information: