Date: Tue, 1 Sep 1998 00:00:19 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, cracauer@cons.org, current@FreeBSD.ORG Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops Message-ID: <199808311400.AAA03763@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >> 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_*.
>> >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-).
>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.
Bruce
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?199808311400.AAA03763>