Help catching floating point exceptions

Robert A Beddini beddini at uxh.cso.uiuc.edu
Wed Jun 5 13:00:43 AEST 1991


 requested info on this from IBM a year ago, and voiced my opinions about the lack of FPP traps at that time to our local IBM tech rep. He, in turn , requested further info internally.  The response at that time was along the lines of "here's the way the FPP can be checked,... why do you need to trap?"

We eventually purchased a 530 and are pleased with its speed on *PRODUCTION* calculations. However it is still not being used for major code development, and its use in this capacity will be limited until IBM recognizes the need for user conveniences (necessities) such as FPP traps as a compiler options/defaults.

While we are on the subject, (sub)program addresses and line #'s should also be loaded into a register and a stack maintained as a compiler option. The cost is far less expensive than the simplest floating point operation. This would enable line info from traps with  traceback - another very helpful feature which has been available on more user-oriented workstations. This compiler option could also be used to help gmon pin down CPU-intensive portions of a large subprogram.


A
It is regretable that the subject of the need for FPP traps continues to be discussed at length without IBM recognizing that this capability should be a priority. Once a code under development begins to work properly, it is an easy matter to enable all the compiler optimization options.



More information about the Comp.unix.aix mailing list