another comp.arch posting on IEEE 754 history

[Jon L White]

re: Aside from Sun C and Fortran products, and Apple programming systems 
    providing access to SANE, IEEE 754 arithmetic environments are extremely 
    rare.  

You might count Sun Common Lisp in the category of Sun C and Fortran too.

The IEEE "environment" for Lisp includes user-accessible facilities which,
at runtime, selectively enable or disable the following Lisp CONDITIONs:

      FLOATING-POINT-INEXACT
      FLOATING-POINT-OVERFLOW
      FLOATING-POINT-UNDERFLOW
      FLOATING-POINT-INVALID-OPERATION
      DIVISION-BY-ZERO

And in addition it includes functions to alter the rounding-mode and
rounding precision, with symbolic names drawn from the 1986 version of
the Sun FP Programmer's Guide:

   SYS:FLOATING-POINT-ROUNDING-MODE				[Function]
   -------------------------------------
      :FP-RD-NEAREST  		IEEE Round-to-nearest mode
      :FP-RD-ZERO			"Chop", i.e., round towards zero
      :FP-RD-MINUS		Round towards negative infinity
      :FP-RD-PLUS			Round towards positive infinity

   SYS:FLOATING-POINT-ROUNDING-PRECISION			[Function]
   -------------------------------------
      :FP-RP-EXTENDED	64-bit mantissa, 15-bit exponent
      :FP-RP-SINGLE	24-bit mantissa,  8-bit exponent (1 hidden bit)
      :FP-RP-DOUBLE	53-bit mantissa, 11-bit exponent (1 hidden bit)


Admittedly, numerical analysts who *ought* to be sensitive to the 
concerns presented by these IEEE capabilities are much more likely to
be using Fortran than Lisp.  But the presence of "bignums" as standard
in Lisp has always made it a choice environment for experiements in
combined numerical/symbolic computing.  Indeed, the kinds of remarks
and investigations made on this email list by Tim Peters regarding the 
worst cases for "Perfect Floating-Point Printout" algorithms are just
so much easier to investigate in a Lisp that has all these capabilities
(in addition to indefinite-precision integers.)


The above parameters, of course, correspond to actual hardware state in 
the floating-point processor (uh, that is, when there is one; there are 
still extant models of the Sun3 that have no attached MC6881, and so have 
only software support for floating point.)  As such, there are all the 
problems previously discussed on this email list about global hardware 
state in the presence of user-level multitasking (which Sun Common Lisp 
supports.)  In addition, there are problems of incompatible assumptions
about the global state when one uses a "mix-and-match" approach to building
a system.  Usually this manifests itself when Lisp's default settings for
the above parameters are at variance with the expectations of some compiled
Fortran program that is "mixed" in with Lisp via the Foreign Function 
Interface; but it also arises when such a C or Fortran program desires to 
grab control of the exception signals, in competition with Lisp's default
management thereof.  And there have been some allegations that the signals
arising because of the need for "re-computation" in a non-IEEE compliant
FP Accelerator board don't always work right in this "mix-and-mismatch"
world; but we haven't been able to see a reproducible case.


On the Sun3, and other MC68xxx platforms on which Lucid's Lisp runs, 
there is a bit of refinement of the InvalidOperation signal; it makes 
distinctions which the MC68881 makes about Nan's, arguments out of the 
domain of the function, unordered comparisons, 0/0 as NaN, and so on,
which I believe are valid extensions of the IEEE specification.



-- JonL --