Date: Sun, 6 Sep 1998 23:41:54 +0200 From: Martin Cracauer <cracauer@cons.org> To: Bruce Evans <bde@zeta.org.au>, cracauer@cons.org, current@FreeBSD.ORG Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops Message-ID: <19980906234154.A18413@cons.org> In-Reply-To: <199809010132.LAA14077@godzilla.zeta.org.au>; from Bruce Evans on Tue, Sep 01, 1998 at 11:32:44AM %2B1000 References: <199809010132.LAA14077@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199809010132.LAA14077@godzilla.zeta.org.au>, Bruce Evans wrote:
> >OK, I had another look and Linux and Solaris both have
> >#define FPE_INTDIV 1 /* integer divide by zero */
> >#define FPE_INTOVF 2 /* integer overflow */
> >#define FPE_FLTDIV 3 /* floating point divide by zero */
> >#define FPE_FLTOVF 4 /* floating point overflow */
> >#define FPE_FLTUND 5 /* floating point underflow */
> >#define FPE_FLTRES 6 /* floating point inexact result */
> >#define FPE_FLTINV 7 /* invalid floating point operation */
> >#define FPE_FLTSUB 8 /* subscript out of range */
> >
> >I think that's the way to go for the code to pass as the second
> >argument to the signal handler.
>
> Yes. Add FPE_FLTSTK (floating point stack overflow). <machine/ieeefp.h>
> is missing this too. Delete FPE_FLTSUB (does it mean bounds check
> exception? In any case, it shouldn't have FLT in its name).
As I understand, FPE_FLTSUB is meant to be a architecture-independent
"whatever can go wrong with addressing in the FPU" respectivly errors
caused by code a valid compiler shouldn't have produced. Thus it would
make sense to map stack under/overflow to it.
I didn't find hard documentation on these values, but everybody (see
below) supports them :-)
> Add
> FPE_FLT_DNM[L] (floating point denormal operand). Actually, I prefer
> the current naming scheme, and glibc uses one close to it, at least in
> its manual:
>
> FPE_INTOVF_TRAP this and following ones have same name as ours
> FPE_INTDIV_TRAP
> FPE_SUBRNG_TRAP
> FPE_FLTOVF_TRAP
> FPE_FLTDIV_TRAP
> FPE_FLTUND_TRAP
> FPE_FLTDECOVF_TRAP floating point decimal overflow trap
> [same names with s/TRAP/FAULT/]
linux-kernel-2.1.x has the FPE_...... names from above, newer glibc
has them as well, but these FPE_......_{TRAP,FAULT} seem to be
hurd-only. The FPE_...... values seem more attractive to me.
Digital Unix 4.0 and Irix 5.3 specify them in their siginfo(5)
manpage, as well as HPUX in signal(5).
Regarding the decision which bits to ignore when multiple unmasked
bits are set, I found something in an Intel document. Wording is
mine.
/*
* Table with FPE_ values for every possible combination of exception bits.
* The precedence is based upon Intel Document "Numerical Applications",
* Chapter "Special Computational Situations". That means when the user
* process enters with more than one unmasked exception bit (can happen
* when it modified the control word), we ignore bits as would the FPU
* if one instruction would cause more than one exception to be raised.
*
* Precisly, it is:
* 1) Invalid operation (FP_X_INV)
* 1a) Stack underflow
* 1b) Stack overflow
* 1c) Operand of unsupported format
* 1d) SNaN operand.
* 2) QNaN operand (not an exception, irrelavant here)
* 3) Any other invalid-operation not mentioned above or zero divide
* (FP_X_INV)
* 4) Denormal operand (FP_X_DNML)
* 5) Numeric over/underflow (FP_X_OFL, FP_X_UFL)
* 6) Inexact result (FP_X_IMP)
*/
I think using the same scheme as the FPU makes sense. If the user
messes with the control word while using FPU instructions while having
an exception handler for SIGFPE set, we could as well define the
behaviour as undefined. But we need the table you suggested in any
case, since we need to look at multiple bits for stack over/underflow
at least, so we can implement something halfway reasonable.
I could also imagine extending struct sigcontext with fields for
control and status word so that the user can get the unmodified status
if the one-bit trap code isn't sufficient (either because multiple
bits may have been set or if the FPE_...... values aren't precise
enough, for example if the user needs to tell under- from overflow).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980906234154.A18413>