Re: Floating-point exception handling
Re: Floating-point exception handling
- Subject: Re: Floating-point exception handling
- From: "David N. Williams" <email@hidden>
- Date: Wed, 23 Sep 2009 11:50:19 -0400
- Organization: University of Michigan
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-example.c
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden