Re: [Stds-754] motion: update exception and flag operations for

[David Hough 754R work <754r@xxxxxxxxxxx>]

> I was thinking of glue code that encapsulates a runtime's exception
> handling.  This would save the current flags and modes, set defaults
> (which corresponds to traps disabled, summary flags clear), and invoke
> the function that produces a result and indicates exception conditions
> in the summary flags.  On return, the glue code would do what it takes
> to pretend the function was a primitive:  it will look at the saved
> modes and flags (before restoring them), signal those exceptions that
> are new and enabled, and merge the summary flags for those that were
> not enabled.

You're assuming a conventional hardware implementation with global modes
and status and a conventional language definition which doesn't provide
any support.      One could just as well define an implementation 
in which the defaults were in force from function entry
until locally specified otherwise, and none of the above would be 
necessary, but it would still be necessary to have to "locally specified
otherwise" primitives.

Anyway the current draft has these primitives:

        saveModes
        defaultModes
        restoreModes

which seem to be what you're asking for, and motion #20 proposes these
primitives:

        saveFlags
        lowerFlags
        restoreFlags

as well as the primitives to signal specific exceptions
and the primitives to raise specific flags for default exception handling.
A function intending to implement a 754R operation in software only needs
to signal one exception at a time, if relying on external exception handling
code, and only needs to raise one or two flags, if providing
its own default exception handling.

In general, if a function's going to all this trouble to save/restore flags, 
it's because it does not want to propagate the flags generated by default
exception handling of its own internal implementation, 
and so there will have to be some logic to sort those
out and decide which exceptions to signal/flags to raise.    And it will
therefore have to get down to the specific flags, which are why the
operations proposed in motion #20 are for signaling specific exceptions
and raising specific flags.

> Now it is true that this can be done with the restricted primitives
> you now suggest, by looking at each flag in turn.  If the environment
> supports a signal-group operation (not mandatory anymore), the glue
> can of course use this, but a portable glue would have to check this.

There is no use anywhere for a signal-group operation when it comes to
implementing 754R primitives.     One doesn't signal inexact until one
has signaled overflow/underflow and obtained default exception handling
for overflow/underflow.    It's one signal at a time, though the upshot
may appear to be two flags at a time.

> What I really miss in the revised proposal is the paragraph that gives
> guidance to the handling of multiple signalled exceptions for the case
> where this is supposed to invoke a declared trap handler.

What's missing in the current draft's section 9.1 or motion #20?
It seems very clear and very upward compatible with existing practice.

Traps are an implementation mechanism for alternate exception handling
that implementations can exploit if they choose.    But the 754 experience
confirms that traps are useless as a feature for portable application
programming.

> I am very
> unhappy with the way alternate exception handling is currently defined,
 ...
> There is also the fact that multiprocessing
> concerns need to be addressed

I've labored for years to define alternate exception handling in a way
that was compatible with multithreading AND restored the functionality
taken for granted by programmers 40 years ago.
My proposals were briefly incorporated into the normative text, then
demoted to a non-normative annex, the further demoted relative to the
expression evaluation non-normative annexes.

Lots of people voted against alternative exception handling at various times,
but none of them offered any proposals for a definition relevant to
programmers of portable applications.    That's a pretty good reflection
of the preponderance of hardware implementers active in the working group
vs. application programmers.

It would be helpful in these discussions if any people, who have actually
tried to program applications (as opposed to system libraries)
using 754 modes/flags/exceptions, would share their experience.