[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Languages, languages ... (was: 754R and Reproducibility)
Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx> wrote:
[ Much snipped, for simplicity. ]
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?
As you imply, the FIRST requirement for doing that is to have a
clean, realistic model for the various layers. Neither IEEE 754
nor 754R have one, and it is that defect that causes much of the
trouble.
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.
In this case, IEEE 754 and 754R have quite simply got it wrong.
The objections to making LIA trap-diagnose-and-terminate mandatory
are dogmatic, and it is the ONLY exception handling mode that is
even reasonably easy to fit into most existing languages.
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.
As I and others have said, repeatedly, it is a Bad Idea to provide
conformance requirements on languages that conflict with the target
languages's abstract models. And I assert that IEEE 754R does, with
this ridiculous demand for reproducibility.
I don't apologise for using the word 'ridiculous' as it is about
the politest accurate one. Before IEEE 754R goes ahead, some of
the proponents of reproducibility should at least produce a DRAFT
of the changes needed to insert it into the main programming
languages - such as C, C++ and Fortran. My assertion is that they
have underestimated the effort and impact by a factor of at least
a hundred. I don't believe that such a change would be accepted
or even feasible.
[ Inter alia, note that reproducibility forces a single, canonical
execution order, including for operands, arguments and destructors.
All of those can change the exception flags, which then become
visible to other parts of the code. That isn't the only issue,
but is a bad enough one to cause the trouble I refer to. ]
As far as parallelism is concerned, the same should be done for
at least OpenMP Fortran (probably the most widespread shared-memory
paradigm, and certainly one of the best defined). While I believe
that it might be feasible, I believe that the effect would be to
eliminate the usefulness of many OpenMP facilities.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@xxxxxxxxx
Tel.: +44 1223 334761 Fax: +44 1223 334679