From owner-freebsd-current Mon Aug 31 05:48:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA13706 for freebsd-current-outgoing; Mon, 31 Aug 1998 05:48:05 -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 FAA13644 for ; Mon, 31 Aug 1998 05:47:59 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id OAA26031; Mon, 31 Aug 1998 14:46:48 +0200 (CEST) Message-ID: <19980831144648.A25916@cons.org> Date: Mon, 31 Aug 1998 14:46:48 +0200 From: Martin Cracauer To: Bruce Evans , cracauer@cons.org, current@FreeBSD.ORG Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops References: <199808311127.VAA25654@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <199808311127.VAA25654@godzilla.zeta.org.au>; from Bruce Evans on Mon, Aug 31, 1998 at 09:27:36PM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <199808311127.VAA25654@godzilla.zeta.org.au>, Bruce Evans wrote: > >> Er, no. The exception status word is a bitmap. Code to map it to a > >> machine_dependent exception code should look something like: > > ^^ > > independent? > -independent :-) > > The 6 standard IEEE exceptions can be mapped to the same binary code for > all machines. Probably not very useful, but easy to do. i386's also have > an FP stack overflow exception. This gets reported as a invalid operand > exception and a stack fault exception (bit 0x40 for the latter). This > should probably be reported as a stack fault exception only. OK. > >> 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. The Linux folks do different, they have FPU- and non-FPU FPE reasons all in their FPE_...... macros in siginfo.h, not oriented on the hardware values. The set is the same for all platforms, they implement nothing to check for x86-only exceptions. Passing the codes seems to be implementend on m86k only, and they deliver integer divisions by zero as FPE just as on x86. I doubt that is what 68K normally does... Anyway, your following explanations make the need for a translation table obvious, since my code doesn't ensure that only one bit is set. [...] > npx.c has its own fnstcw() macro. It also has a pseudocode macro named > XXX_ENCODE() which needs to be completed to fix this problem. Ah! Should have read all the XXX in there, first :-) > >> The FPU can't be used here if there was a context switch between the > >> FPU trap and here. > > > >So I have to treat it like curpcb->pcb_savefpu.sv_ex_sw, that means I > >store it into a new field curpcb->pcb_savefpu.sv_ex_cw in > >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? 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. That's suffiicient for the current infrastructure. If I want to make the control/status words available to the exception handler, it would require extending 'struct sigcontext'. Both would still require my changes to the FPE_......_TRAP values to keep them off the FP_X_ range. 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