Re: [9fans] Arithmetic on Plan 9

[tlaronde@polynum.com]

On Wed, Jul 25, 2007 at 10:25:28AM -0600, andrey mirtchovski wrote:
>[...] 
> in my particular case the code I was porting defined NaN as a constant
> and threw an exception whenever it ran. one particular quirk that i
> observed was that an exception was thrown regardless of whether I
> defined a silent or a non-silent NaN... my "solution" was simply to
> turn off FPINVAL via setfcr(). if you're porting via ape, as i was
> doing, the best solution is to get the little bits of assembly that
> constitute the *fcr routines, compile them with 8a and link them
> against the

Perhaps a hint on this. In The Intel documentation (Intel64 and IA32
Architectures Software Developer's Manual, Volume 1, §4.8.3.4):

------quote
SNaNs are typically used to trap or invoke an exception handler.
They must be inserted by software; that is, the processor never
generates an SNaN as a result of a loating-point operation.
------endquote

As a result, on x87, the invalid operations all cause an exception, and
it is the responsability of software to create/insert NaNs, whether
sNaN or qNAN.

And furthermore (§4.8.3.6):

------quote
· If one of the source operands is an SNaN and the floating-point
invalid-operating exception is not masked (see Section 4.9.1.1,
"Invalid Operation Exception (#I)"), the a floating-point
invalid-operation exception is signaled and no result is stored in
the destination operand.

· If either or both of the source operands are NaNs and floating-point
invalid- operation exception is masked, the result is as shown in
Table 4-7. When an SNaN is converted to a QNaN, the conversion is
handled by setting the most- significant fraction bit of the SNaN
to 1. Also, when one of the source operands is an SNaN, the
floating-point invalid-operation exception flag it set. Note that
for some combinations of source operands, the result is different
for x87 FPU operations and for SSE/SSE2/SSE3 operations.

· When neither of the source operands is a NaN, but the operation
generates a floating-point invalid-operation exception (see Tables
8-10 and 11-1), the result is commonly an SNaN source operand
converted to a QNaN or the QNaN floating- point indefinite value.
------endquote

So masking the floating-point invalid-operation, even in case of QNaN,
if I understand correctly, was indeed required to shut up the exception.


Note: I have the documentation for Plan 9 in hardcopy (from Vita Nuova),
and I just found some information about IEEE support in the paper called:
"The Various Ports".

To summarize: for Motorola MC68020 and x86, there is IEEE754 hardware
support and there is full IEEE support.

For chips where there is a FPU but only a partial support, in hardware,
for IEEE754, there is emulation, but not a complete one: "we implement
non trapping-underflow as truncation to zero and do nothing about
denormalized numbers and not-a-numbers."

There is also notes about transcendantal functions (built-in or emulated
in library).
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C