Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven.umd.edu!uvaarpa!murdoch!astsun.astro.Virginia.EDU!gl8f From: gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) Newsgroups: comp.unix.aix Subject: Re: Help catching floating point exceptions Message-ID: <1991Jun6.182926.6040@murdoch.acc.Virginia.EDU> Date: 6 Jun 91 18:29:26 GMT References: <1991May31.071822.9206@marlin.jcu.edu.au> <1991Jun6.032233.10629@ibmpa.awdpa.ibm.com> Sender: usenet@murdoch.acc.Virginia.EDU Organization: Department of Astronomy, University of Virginia Lines: 14 In article <1991Jun6.032233.10629@ibmpa.awdpa.ibm.com> jsalter@slo.awdpa.ibm.com (Jim Salter) writes: >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. This is known as a design flaw. If it was too expensive to give a trap on the "correct" instruction, then give me a trap that happens sometime after the fault happens. That way I can run full-speed, and have the code crash *near* the offending instruction. Or I could run slower and be exact. Crays have done this for years. If you can't give the best environment, second-best is much better than nothing.