site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Organization: University of Michigan User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Okay, I'm still a signals newbie, but I do know more than I did a few days ago about how to enable IEEE 754 nondefault exception handling, for three systems, OS X Leopard ppc and intel, and a GNU/Linux. New example code is here: http://www-personal.umich.edu/~williams/archive/computation/fe-handling-exam... There are two things: 1) enabling nondefault handling 2) what the handler does The Apple ppc legacy example I was following before did 1) by explicitly changing bits in the FPSCR register with the assembly language op mtfsf. The method in the above file is to use the GNU/Linux functions feenableexcept(), fedisableexcept(), and fegetexcept(), implemented for OS X. The key was the comments in /usr/include/architecture/i386/fenv.h, which points out that the fenv_t structure has fields for the intel x87 control and status registers, and the SSE MXCSR register, and encourages manipulating the bits there. The comments in /usr/include/architecture/ppc/fenv.h are silent about that, but I verified that the same thing works for ppc. There typedef unsigned int fenv_t; corresponds directly to FPSCR. So it's a question, how likely is this approach to be invalidated by a future Apple release? If that happens, I hope Apple supplies an implementation of the above three functions. As for 2), the new example does nothing about restoring state, and just aborts with a diagnostic message. Terry Lambert pointed out the imprecision of the interrupts, even when the hardware is precise, as it is with ppc and intel SSE(2). But without ruling anything out, it does seem natural that an alternative to IEEE 754 default (nonstopping) behavior should stop. Even so, I still have a problem. When the example is run on OS X intel, the only signal code supplied to the handler in the si_code field of the siginfo_t structure, when it's invoked on SIGFPE, is FPE_NOOP. OS X ppc and GNU/Linux both supply at least FPE_FLTDIV and FPE_FLTINV -- other codes not tested yet. I thought I could work around that by having the handler get the information from the exception status flags via fetestexcept(), or by directly reading the register, but I find that the status flags for intel are cleared, with OS X and Linux both. They are not cleared with OS X ppc. So am I doing something wrong? -- David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com