Work in Progress: Lecture Notes on the Status of IEEE 754 October 1, 1997 3:36 am
Page 6
Exceptions in General.
Designers of operating systems tend to incorporate all trap-handling into their handiwork, thereby burdening
floating-point exception-handling with unnecessary and intolerable overheads. Better designs should incorporate
all floating-point trap-handling into a run-time math. library, along with logarithms and cosines, which the
operating system merely loads. To this end, the operating system has only to provide default handlers ( in case the
loaded library neglects trap-handling ) and secure trap re-vectoring functions for libraries that take up that duty and
later, at the end of a task, relinquish it.
To Disable an exception's trap is to let the numeric (co)processor respond to every instance of that exception by
raising its Flag and delivering the result specified as its “ Default ” in IEEE 754. For example, the default result
for 3.0/0.0 is ∞ with the same sign as that 0.0 . The raised flag stays raised until later set down by the program,
perhaps after it has been sensed. IEEE 754 allows for the possibility that raised flags be non-null pointers, but
most microprocessors keep one or two bits per flag in a Status register whose sensing and clearing fall outside the
scope of these notes. The same goes for bits in a Control register that Enable/Disable traps; see manuals for your
chip and for the programming environment ( e.g. compiler ) that concerns you.
+-------------------------------------------------------------------+
| CAUTION: Do not change ( enable or disable ) exception traps |
| in a way contrary to what is expected by your programming |
| environment or application program, lest unpredictable |
| consequences ensue for lack of a handler or its action. |
+-------------------------------------------------------------------+
Disputes over exceptions are unavoidable. In fact, one definition for “ Exception ” is ...
“ Event for which any policy chosen in advance will subsequently
give some reasonable person cause to take exception.”
A common mistake is to treat exceptions as errors and punish the presumed perpetrators; usually punishment falls
not upon deserving perpetrators but upon whatever interested parties happen to be in attendance later when
exceptions arise from what was perpetrated, error or not.
+-------------------------------------------------------------------+
| Exceptions that reveal errors are merely messengers. What |
| turns an exception into an error is bad exception-handling. |
+-------------------------------------------------------------------+
Attempts to cope decently with all exceptions inevitably run into unresolved dilemmas sooner or later unless the
computing environment provides what I call “ Retrospective Diagnostics.”. These exist in a rudimentary form in
Sun Microsystems' operating system on SPARCs. The idea is to log ( in the sense of a ship's log ) every
suspicious event that is noticed during a computation. These events are logged not by time of occurrence ( which
could fill a disk very soon ) but by site in a program. A hashing scheme ensures that events repeated at the same
site will perhaps update but certainly not add entries to the log. Neither need an exception that occurs while its flag
is still raised by a previous exception of the same kind add a new entry to the log. After a program finishes ( if it
ever does ), its user may be notified discreetly if a dangerous flag like INVALID is still raised; then that flag can
serve as a pointer to its entry in the log. The log cannot grow intolerably long, so unusual entries stand out and
point to whatever software module put them there. The user of that software can then identify the module in
question and ask its supplier whether an entry is something to worry about.