From owner-freebsd-current Mon Aug 31 09:26:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12420 for freebsd-current-outgoing; Mon, 31 Aug 1998 09:26:01 -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 JAA12387 for ; Mon, 31 Aug 1998 09:25:58 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id SAA26370; Mon, 31 Aug 1998 18:24:46 +0200 (CEST) Message-ID: <19980831182446.A26258@cons.org> Date: Mon, 31 Aug 1998 18:24:46 +0200 From: Martin Cracauer To: Bruce Evans , cracauer@cons.org, current@FreeBSD.ORG Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops References: <199808311400.AAA03763@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <199808311400.AAA03763@godzilla.zeta.org.au>; from Bruce Evans on Tue, Sep 01, 1998 at 12:00:19AM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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