From mboxrd@z Thu Jan  1 00:00:00 1970
From: tlaronde@polynum.com
Date: Thu, 26 Jul 2007 00:52:17 +0200
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Arithmetic on Plan 9
Message-ID: <20070725225216.GA735@polynum.com>
References: <20070725155155.GA2324@polynum.com>
	<14ec7b180707250925r27e6b8f1vdc53a2dc4430432f@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <14ec7b180707250925r27e6b8f1vdc53a2dc4430432f@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 977128d0-ead2-11e9-9d60-3106f5b1d025

On Wed, Jul 25, 2007 at 10:25:28AM -0600, andrey mirtchovski wrote:
>[...]=20
> 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, =A74.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 (=A74.8.3.6):

------quote
=B7 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.

=B7 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.

=B7 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).
--=20
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C