From owner-freebsd-current Sun Sep 6 14:43:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA01572 for freebsd-current-outgoing; Sun, 6 Sep 1998 14:43:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cons.org (knight.cons.org [194.233.237.86]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA01562 for ; Sun, 6 Sep 1998 14:43:08 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id XAA18503; Sun, 6 Sep 1998 23:41:55 +0200 (CEST) Message-ID: <19980906234154.A18413@cons.org> Date: Sun, 6 Sep 1998 23:41:54 +0200 From: Martin Cracauer To: Bruce Evans , cracauer@cons.org, current@FreeBSD.ORG Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops References: <199809010132.LAA14077@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <199809010132.LAA14077@godzilla.zeta.org.au>; from Bruce Evans on Tue, Sep 01, 1998 at 11:32:44AM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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). > 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 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