Re: Faster code for IEEE arithmetic.

[Brad Lucier <lucier at math dot purdue dot edu>]

> From geoffk@geoffk.org  Thu Dec 14 17:19:34 2000
> > From lucier@math.purdue.edu
> > The 754 IEEE standard says the following, which I can interpret to mean
> > only one thing---either a trap handler is not invoked when an
> > exceptional event is signalled, or it is invoked immediately when an
> > exceptional event is signalled;  see the wording in Chapter 8.  So trap
> > handlers are never given information about multiple exceptional events
> > at one time, so specifically, they are not given information about
> > which multiple exceptional events occured or in what order they
> > occured.  Note also that exceptional events cannot be counted by the
> > flags; see the wording of Section 7.
> 
> A signal handler can keep arbitrary state between calls, so it can
> determine which exceptions were issued and in which order.  (Note that
> the paragraph from IEEE754 below implies that you should be able to
> specify a different handler for each kind of exception, which is
> equivalent to having one handler that knows what kind of exception was
> passed.)

Let's put the wording from Chapter 7 back into this discussion:

7. Exceptions
There are five types of exceptions that shall be signaled when detected.
The signal entails setting a status flag, taking a trap, or possibly
doing both. ... The default response to an exception shall be to
proceed without a trap.  This standard specifies results to be delivered
in both trapping and nontrapping situations.

For each type of exception the implementation shall provide a status
flag that shall be set on any occurence of the corresponding exception
when no corresponding trap occurs.  It shall be reset only at the user's
request.

<More information about when "exceptions are signalled", and, in some
cases, what information shall be "delivered to the trap handler">

> > 8. Traps
> > A user should be able to request a trap on any of the five exceptions
> > by specifying a handler for it. ... When an exception whose trap
> > is enabled is signaled, the execution of the program in which the exception
> > occurred shall be suspended, the trap handler previously specified by
> > the user shall be activated, and a result, if specified in Section 7,
> > shall be delivered to it.
> > 
> > <More information about what a trap can do.>

I think we may be talking at cross purposes ...

What I would like to establish is whether a trap handler has to be able
to know whether exceptional condition A occured before exceptional
condition B in the situations below, or how many times A or B happened:

no trap handlers are enabled
A happens
A happens
A happens
B happens
trap handler for event C is enabled
C happens

or 

no trap handlers are enabled
B happens
A happens
B happens
A happens
B happens
A happens
trap handler for event C is enabled
C happens

My reading of the standard says no.  If no trap handlers are enabled,
then flags are set whenever a specific exceptional event is signalled,
but no record of the number of times those flags are set, or in what
order those flags were set, is kept.  The standard says that if trap
handlers are enabled, they are activated on single specific exceptional
events, and they don't know what previous exceptions were signalled but
not handled by trap handlers.

In other words, if no trap handlers are enabled for a block of code
wherein exception flags are not examined, then the IEEE standard does
not prohibit the code in that block being rearranged, simplified,
whatever, as long as at the end of the block the variables have the
right values, and the right flags have been set at least once.

Brad