[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
RE: rogue comment: IEEE 754R and Reproducibility
I still disagree about the effects of obsolete hardware: that does not help
with the repercussions of the previous *architecture*, which remains fixed
forever.
This is indeed a concern of system vendors, and providing compatibility with
the past is one way system vendors earn their keep. That keeps the
pile of ISV applications that run on their current hardware larger.
ISV's, however, once they decide to produce a new version, are more
interested in having it work on as many current platforms as possible
with as little effort as possible.
way. This is ALSO a reproducibility feature that some people care about.
(Of course, if the standard is "ok as long as only experts can tell the
difference", the bar is much lower.)
Some things (underflow definition, fma invalid) could be changed and
nobody would ever be likely to notice except when looking intentionally.
Other things like the decimal interchange format encoding are indeed
expensive to change while maintaining compatibility.
My other comment is that this takes us even further in the direction where
everything is stated in terms of a "Language". It seems to me that it should
be possible to offer a 754R implementation for a particular platform that is
complete and conforming, but with no intended application language in sight.
Precisely because of language standard and compiler implementation inertia,
my low-level approach makes it possible to offer a conforming implementation
on much shorter notice at that level: basically, as soon as the hardware is
ready. It would be fully exploitable by assembler-language programmers, and
thus help compiler implementers do their job faster too.
However, 754(2007) seems not to recognise this level, unlike 754(1985).
This is sad.
No, this is intentional. Too much of 754 was specified at a level
that could not be used by the intended target, which is developers of PORTABLE
libraries and applications,
rather than developers of machine-specific software, including
compiler implementers. The latter class is indeed important to system
vendors, who are well advised to provide all the low-level elements needed
to build a conforming implementation... for the benefit of their compiler
implementers and systems software people.
but they shouldn't expect ISV's
to be much interested. It's hard enough to get ISV's to modify their
Makefiles to use varying compiler options on different platforms.
754R has done well to get into specifying portably useful features and
out of specifying implementation mechanisms.