Date: Mon, 31 Aug 1998 18:24:46 +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: <19980831182446.A26258@cons.org> In-Reply-To: <199808311400.AAA03763@godzilla.zeta.org.au>; from Bruce Evans on Tue, Sep 01, 1998 at 12:00:19AM %2B1000 References: <199808311400.AAA03763@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199808311400.AAA03763@godzilla.zeta.org.au>, Bruce Evans wrote:
> >> >> code = translation_table[ffs(status_word & control_word & 0x3F)];
> >> >
> >> >But the values of the symbols the application tests against
> >> >("FP_X_...") are chosen so that no translation is needed.
> >>
> >> Sorry, I thought that you didn't change the codes that much.
> >
> >I didn't. The FP_X_ value have always been the hardware bit
> >values. They are on Solaris (SPARC and x86) as well, so I thought
> >people agreed to use the hardware bit values to make the kernel code
> >more efficient.
>
> I thought Sun normally uses machine-independent codes like our FPE_*.
They have both. I don't known what is commonly used.
> >> >npx.c:npxintr() ?
> >>
> >> Just translate the code there. You do need to store the control word
> >> somewhere.
> >
> >Store it for use outside of npxintr()? Why that?
>
> Outside of the CFU 8-).
I'm afraid I'm out of reach for the smily. What's CFU? :-/
> >If I implement XXX_ENCODE, I get the trap code I want and have no need
> >for the control word (or the status word, for that matter) outside
> >this function.
>
> There's no trap code except possibly for one generated from the FPU state.
> XXX_ENCODE currently takes only the status word as an arg. Your idea of
> throwing away the masked bits is good. I think the point of FPE_* is
> that that they give a simple semi-portable interface for applications
> that don't want to know about the status word, the control word and
> where they may be found.
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.
I will think over a priority scheme for the case that multiple
unmasked bits are set. Some Intel document I have talks about this,
maybe IEEE has something as well.
Which header file should I put the FPE_...... macros in? Should I
replace the FPE_......_TRAP macros in trap.h? That way, I can add our
FPE_FPU_NP_TRAP to the set above.
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?19980831182446.A26258>