[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: flags and modes in 754R
David Hough 754R work <754r@xxxxxxxxxxx> wrote:
Well, as this was probably prompted as a response to what I sent, I
had better respond. The problem here is a lack of communication,
again. For example, in the context of languages and compilers
"global flags" don't mean just a single set for the whole program,
but anything that has a scope or effect not localised to precisely
where and when the action takes place.
Let's start with the specific points.
754R tried to make it as explicit as possible that a global set of flags
is not a required implementation. It wasn't in 754 either, but because
everybody implemented flags as global hardware, many people supposed it
was mandatory.
That is true, I agree.
In 754R, nothing guarantees that you can "look at the flags" in places
where you haven't said "I'm going to look at the flags" in advance.
Those places where you said you might look at the flags might well run
the normal case slower.
That is true, but so partial and misleading as to be effectively
false.
Firstly, it isn't just "looking at the flags" - "honouring dynamic
rounding or exception modes" and "producing reproducible results"
bring in almost exactly the same problems.
Secondly, and more seriously, "the places where you said you might
look at the flags" is a MAJOR conflict with many programming
languages. What you are assuming is a design where all control flow
constructs have a well-defined, static scope and where all expression
evaluation is subsidiary to that (i.e. an expression is just such a
construct). In such a language, at least that statement makes sense.
However, not all language use that model (try SNOBOL or Prolog for
fairly alien ones) and, as Malcolm Cohen and I have pointed out,
there are important aspects of both Fortran and C++ that don't fit
into that model. I shall return to this later.
The actual implementation might be distributed with flags accompanying
data and only OR'ed together to satisfy an explicit inquiry in the
source code. In particular asynchronous events like debugger inquiries
might not have a single set of global flags to look at.
Been there - done that :-( Yes, that's always been possible, and
is the most obvious way to shoehorn IEEE 754 into most programming
languages while still allowing some code movement and sharing.
Likewise the scope of mode declarations is language-defined and might
not be discernible by looking at a global mode bit, except where a
program says in advance that it's going to look at the mode.
That is an improvement in IEEE 754R, I agree. There was considerable
debate about whether it was allowed in IEEE 754, and C99 decided not.
But you might like to think why almost all programming languages have
regarded dynamic and non-universal (non-global in your sense) mode
declarations as anathema for 50 years - they are at BEST foully
complex to specify, implement and use, and correspondingly harmful to
implementation and coding cost, optimisation and even robustness.
Having taken these steps to uninhibit future architectures, it remains
true that the installed-base momentum will probably continue to
encourage global flags and modes implementations that will continue to
threaten to impede optimization of the normal cases.
Er, no - that's not the reason. As I said, I know of no language
that has even usable support for IEEE 754's flags and modes, and my
previous messages failed to prompt anyone to come up with a
counter-example; or, if they did, I missed it. If C99 is the best
example that anyone can bring up, then there is NO "installed base"
that a standard need bother about.
Note that I am not saying that a particular IMPLEMENTATION might not
have support for them - I am talking about portable, and preferably
standardised, languages.
Now, let's describe some of the language and implementation issues.
Any 'section of code' that is moved or shared must have its modes and
flags carried with it. So far, so good. But let's start thinking
about the details.
a) The language has to define the 'scope' of all sections of
code, even if (like Fortran, C and C++) there are constructs that are
not associated with any specific location in the text or where their
evaluation is associated with TWO locations (e.g. many static and
macro-like constructs). In some cases, it could say that they must
not use floating-point, but that considerably reduces the usefulness
and orthogonality of the language, possibly enough to make IEEE 754R
support pointless.
b) Implementing such environmental closure isn't hard to do, if
efficiency isn't a major concern, but is a right pig when it is. The
only SIMPLE implementation is that every code fragment comes with its
own modes, and every object imported into or exported from that code
fragment has its own set of flags. Not pretty and DEFINITELY not
efficient.
c) But you need to do that only if the code fragment or even
whole function is declared to set or test flags, right? Wrong. You
need to do it if you can't PROVE that its 'caller' WON'T do so - a
MUCH stronger statement. And remember that, in the case of such code
fragments or functions, it can be undefined where they ARE called
from (e.g. C++ initializers and destructors) - or even where they
were defined (e.g. C or C++ inline functions).
d) Interrupt handling is a nightmare beyond belief. And this
isn't just when IEEE 754 exceptions cause interrupts but asynchronous
ones like SIGHUP. Saving and restoring the modes and flags may not
be possible without kernel hacking and, even when it is, it involves
arcane techniques beyond almost everyone still working in the IT
industry. You think that I am exaggerating? Look at the evidence,
in the form of how many implementations support that properly.
e) Oh, heck, let's stop there. I could go on all night - and
it's only 11 am here :-)
I have given some examples of the problem in (a), and could give
more. Anyone who disagrees should start by drafting some specific
wording for Fortran or C++ and putting it up to be shot down. Let's
give an initial challenge:
I defy anyone to produce wording that specifies how this
can be done for C and C++ inline functions, or Fortran
functions, without major changes to the existing standard's
wording and without major constraints on optimisation.
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