[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Languages, languages ... (was: 754R and Reproducibility)
On 6 Jul 2007 David Hough replied to my concern that 754R expressed
conformance only with reference to a language environment:
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.
On the contrary, system vendors (by which assume we mean vertically
integrated vendors that produce hardware as well as the software that
runs on it) benefit from the bundling, assuming they are not interested
in selling the hardware unbundled. (Please note that this is a personal
comment and may not reflect IBM's position.) That's because it offers
flexibility about where to provide the support for conformance.
Personally I prefer a situation where there are clear boundaries between
levels, between hardware and software as well as between different levels
of software (operating system, run-time environment, etc.).
I agree that the standard should provide clear guidance for ISVs -- that
is an important boundary between programming levels. The problem I see
is that David H seems to assume that this level is supported by a single
entity.
I would like to encourage independent support of the various layers. In
fact, this may well apply to ISVs too, which after all operate on many
different levels as well: some provide operating systems (and depend on
the properties of the hardware), and some provide compilers and run-time
environments (and depend, in addition, on the underlying OS). These are
vendors that *provide* IEEE 754R support at the language level. What can
they assume from the underlying levels on which they depend?
It may not be smart, but in principle it would be possible to implement
floating-point primitives that are functionally incomplete, and not bother
to document those details. The in-house compiler developers would know
the full story and could offer compliance at the language level, but ISV
compiler developers would be stymied. The IEEE 754(1985) standard had the
effect that vendors *did* supply the programming details necessary to do a
complete 754-conforming job, and I gave some examples of how IBM did this
nine years ago.
754R has done well to get into specifying portably useful features and
out of specifying implementation mechanisms.
I agree. I would like to point out however that 754(1985) did not do what
is being implied here, although -- unfortunately -- many interpreted it as
having done that, especially with regard to exception handling. This was
probably because it was the easiest way to satisfy the requirements, and
there was no strong-enough demand to look beyond that.
So -- what do I mean by a language-independent specification?
For most operations, the standard specifies a certain function that is to
be performed. An implementation would be conforming if it documented the
means of achieving this: it could be a single instruction, or recipe for
combining instructions into a function that performs the complete job.
In cases where the standard now says "language-specified", one or more
choices may be offered. If the choice is too narrow, some languages may
well face a difficult implementation on that platform, but sometimes the
choice is easy (IBM offers two sets of comparison and copy instructions,
differing in how NaNs are handled), and other times the choice is fixed
by the hardware (fma behaviour, underflow details, decimal encoding), and
it would be unreasonable to offer a choice at that level. In all cases
the choices would be fully documented; IBM's Principles of Operation even
provide background tying those choices to the standard, explaining the
reasoning.
It is true that a specification at the level I just described is not what
most programmers want (basically, an assembly-language level), but I claim
that it is necessary to enable a small group of programmers to provide the
conformance at the higher levels (basically, compiler writers). So I am
not at all opposed to providing clear conformance requirements at the
language level (which was missing in 754(1985)) -- what I'm complaining
about is dropping conformance discussions at the lower levels altogether.
Michel.
Sent: 2007-07-11 08:58:10 UTC