strange floating point exception interrupt behavior

[Bron Campbell Nelson]

In article <9007260022.AA03729 at chem.chem.ucsd.edu>, sdempsey at UCSD.EDU (Steve Dempsey) writes:
> The shock came from the interrupt rate, which went from a background level
> of 200-400 per second up to ~20K per second (35K on the 340VGX!)
> 
> Ultimately, I discovered that the extra interrupts were occuring whenever
> floating point operations resulted in underflow.  This behavior can be
> demonstrated by compiling and running this code:
[deleted]

The MIPS R3010 floating point hardware does not handle the "exceptional"
conditions of IEEE floating point, including underflow.  Whenever an f.p.
operation would result in underflow, the chip generates an interrupt, and
the f.p. operation is done in software, correctly dealing with all the
obscure conventions of IEEE arithmetic.  This is one of the reasons that
the chip is (normally) so fast: all that silicon that would normally be
devoted to this stuff is removed and is instead invested in making the
normal case go faster.

Of course, this is also the reason why it is so slow in your particular
case.  The reason why underflow is particularly bad is that once you
get an IEEE denorm, subsequent operations on that denorm will also cause
interrupts, et cetera.

You say that you have 3.3; if you are not too worried about exact IEEE
semantics for your f.p. operations, then you can use the "sigfpe(3C)"
package (or "fsigfpe(3F)" for the Fortran interface).  This allows you to
specify what you want done when these sorts of exceptions occur.  The
fast simple thing to do is that when an underflow (_UNDERFL) exception
occurs, instead of computing the correct denorm value, just use zero
as the result value (note that non-IEEE machines typically do just that).
You will still take an interrupt when a denorm value is *first* generated,
but by replacing it with zero, you prevent that denorm interrupt from
propagating into subsequent calculations.  This normally gets rid of
the vast majority of these interrupts.

Sadly, if you *really* need the exact correct IEEE denormalized values,
you are stuck.  As I said, the R3010 does not have hardware support for
denorms, and so operations on denorms must be done in software.

--
Bron Campbell Nelson
bron at sgi.com  or possibly  ..!ames!sgi!bron
These statements are my own, not those of Silicon Graphics.