[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: a question about formatOf operations
"Malcolm Cohen" <malcolm@xxxxxxxxxxx> wrote:
The "literal meaning" is what programs get, full stop.
Barring software and hardware faults of course.
I think that the confusion here is that David Hough is assuming that
the "literal meaning" is what would happen if the code were interpreted
by a C-style, machine-code-level abstract machine. I.e. the semantics
of the language are specified in such terms. That is why I said that
it makes some sense in C.
I have been unable to find any trace of such a machine-code-level model
in any Fortran specification, from Fortran II to the present day :-)
Fortran doesn't standardise computer arithmetic and its properties at all.
As far as Fortran is concerned, it is outwith the scope of the standard.
It is not defined by the language or by the processor: it is not defined
at all.
That's an interesting position for a language oriented toward floating-point
computation!
And the correct position.
I believe that one person implemented a Fortran 77 compiler that used
fixed-slash arithmetic for reals, but I never tracked down whether it
had actually been done (and, if so, finished). There was certainly
no reason why not, because that is an equally good approximation to the
mathematical reals, and there are some very good reasons to prefer it.
A few Fortran 90 functions would have trouble with it.
There were definitely compilers that produced code for IBM PCs that
ran with a variety of coprocessors, and they mostly had differences in
their arithmetic. They were Fortran 77, but I don't think that anything
in Fortran 90 and beyond makes that impossible. Note that means the
same executable running with different arithmetic units in different
runs.
It is also a very practical matter in HPC. Parallel arithmetic units
(vector, SIMD and MIMD) often have subtly different arithmetic properties
from serial, and when and how is best to flip between them depends on
the data and even other current workloads on your system! Fortran
permits this, which is one reason it is holding its own in HPC. Yes,
it confuses users - but any user that can't adapt will never learn
to program in parallel efficiently.
There was an incredibly unproductive debate about this in SC22WG14,
and nobody knows whether C allows it or not. Most C++ people don't
program at that level, so I am not sure about that.
Even within a local
scope, there's nothing novel about using funny comments in Fortran or
pragmas in C to control compilation. The novelty here is asking
the language standard to better integrate the control of compilation into
the language so that control of semantics is portable too.
This may be impossible as you say, but only because of the dynamics of
standardization committees.
Nonsense. Good people have tried *and failed utterly* at producing work
acceptable at a technical level. Maybe this problem will prove tractable
at sometime in the future, but from where I am sitting it looks to be
getting worse, not better.
The OpenMP people would disagree with you, but your colleagues that use
it (and I) would not! OpenMP is pretty bad, hard to use (and EXTREMELY
hard to debug, tune and support), and is the BEST of the bunch.
And the reason has little to do with the political process, but because
OpenMP (and this proposal) require major changes to the basic language
model. Failure to consider that is why POSIX threads are so unreliable
and non-portable for high-performance programming in C. At least OpenMP
makes some gesture at defining the language model changes.
To a certain extent we are talking about machine-independent specification
of optimisations; well, to quote Bill Wulf,
"There is no such thing as a "machine-independent" optimization!
Not one! People who use the phrase don't understand the problem!"
Of course that was 20 years ago but there is still a lot of truth in it.
Another good reason why there is little traction in standardising compiler
directives.
I think that overstates things a little. Using such directives to
indicate static scope variations in the language's model is feasible.
Using the to turn the languages semantic model upside down is another.
Unfortunately, the IEEE 754R proposals do the latter.
And please note that I am NOT just talking about Fortran here - the
same applies to at least C and C++.
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