Date: Mon, 31 Aug 1998 14:46:48 +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: <19980831144648.A25916@cons.org> In-Reply-To: <199808311127.VAA25654@godzilla.zeta.org.au>; from Bruce Evans on Mon, Aug 31, 1998 at 09:27:36PM %2B1000 References: <199808311127.VAA25654@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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?19980831144648.A25916>