Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!spool.mu.edu!munnari.oz.au!bunyip.cc.uq.oz.au!marlin.jcu.edu.au!csrdh From: csrdh@marlin.jcu.edu.au (Rowan Hughes) Newsgroups: comp.unix.aix Subject: Re: Help catching floating point exceptions Message-ID: <1991May31.071822.9206@marlin.jcu.edu.au> Date: 31 May 91 07:18:22 GMT References: <1991May27.213751.24223@murdoch.acc.Virginia.EDU> <91149.150333AER7101@TECHNION.BITNET> Organization: James Cook University Lines: 28 In sdl@adagio.austin.ibm.com (sdl) writes: >In article <91149.150333AER7101@TECHNION.BITNET> AER7101@TECHNION.BITNET (Zvika Bar-Deroma) writes: >Zvika> I've been told by my IBM rep. that as IEEE didn't require that division >Zvika> by zero be trapped and signalled, then (some/many/most) RISC machines >Zvika> don't, and he thinks, that unless there's such a requirement from IEEE, >Zvika> they won't also in the forseeable future. >Your rep. is correct. From IEEE 854-1987: "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". >Moreover, IEEE requires that if you implement IEEE trapping, that >"A trap handler should have the capabilities of a subroutine that can 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. There is an option for the job to continue after a fault, and the user is notified at the end of execution. Integer overflow can be trapped also. It can be done easily on RISC, with no loss in performance. -- Rowan Hughes James Cook University Marine Modelling Unit Townsville, Australia. Dept. Civil and Systems Engineering csrdh@marlin.jcu.edu.au