Help catching floating point exceptions

[jsalter at ibmpa.awdpa.ibm.com]

In article <1991May31.071822.9206 at marlin.jcu.edu.au> csrdh at marlin.jcu.edu.au (Rowan Hughes) writes:
>In <SDL.91May29181249 at adagio.austin.ibm.com> sdl at adagio.austin.ibm.com (sdl) writes:
>DEC have released their new f77v3.0 compiler for the DECStations
>(=R3000) and it traps all floating exceptions; the job aborts
>with a core dump. I've done some benchmarking between the new and old
>compilers (with and without fpe) and the performance has dropped by
>less than 1/2%.  Fpe is enabled ALL the time, irrelevent of
>compiler options. [...]
>It can be done easily on RISC, with no loss in performance.

True, it *can* be done on RISC architectures.  That's not the point.
The point is whether it should be done on the POWER architecture the
'6000s employ.  I don't believe the R3000 is super-scalar, thereby
limiting the effects of trapping.  Since the '6000 is, instructions are
scheduled out-of-order by the compilers to ensure the pipeline remains
full for as long as possible.

What trapping does is *serialize* the execution, forcing the instructions
to be in-order, thus greatly limiting the performance by, as been noted
many times, an order-of-magnitude.  This is not a trivial performance hit.

The first-generation SPARC may be only 2-3 MFLOPS, but to bring the '6000
down to 2-3 MFLOPS really hurts.  I think everyone would agree that the
FP performance of the '6000 is one of it's best points.  To turn trapping
on all the time would be marketing suicide.

>Rowan Hughes                                James Cook University
>Marine Modelling Unit                       Townsville, Australia.
>Dept. Civil and Systems Engineering         csrdh at marlin.jcu.edu.au

jim/jsalter  IBM PSP, Palo Alto  T465/(415)855-4427  VNET: JSALTER at AUSVMQ
Internet: jsalter at slo.awdpa.ibm.com         UUCP: ..!uunet!ibmsupt!jsalter 
"IBM part #23521, aka Lt. Commander Data"    The stuff above is on my own.