Date: Wed, 03 Sep 2003 09:12:41 -0500
From: Eric Rudd <rudd AT cyberoptics DOT com>
Subject: Re: Arithmetic Exceptions in C99
In-reply-to: <3405-Wed03Sep2003002328+0300-eliz@elta.co.il>
To: djgpp-workers AT delorie DOT com
Message-id: <3F55F6D9.4060509@cyberoptics.com>
Organization: CyberOptics
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
X-Accept-Language: en,pdf
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312
References: <200308292046 DOT h7TKkAEJ012781 AT speedy DOT ludd DOT luth DOT se>
 <3F4FC482 DOT A71D96A1 AT phekda DOT freeserve DOT co DOT uk> <3F4FCD2D DOT 5070204 AT cyberoptics DOT com>
 <2593-Sat30Aug2003120721+0300-eliz AT elta DOT co DOT il>
 <3F54E076 DOT 8030807 AT cyberoptics DOT com>
 <3405-Wed03Sep2003002328+0300-eliz AT elta DOT co DOT il>
X-MailScanner-Information: Please contact the ISP for more information
X-MailScanner: Found to be clean
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Eli Zaretskii wrote:

>I feel uneasy with setting bits in the x87 status word (assuming it's
>at all possible, which I'm not certain about).  I'd say let the
>hardware do its thing as well as it can, and let's mirror its status
>in a separate variable.
>
The two ways I know to set the x87 status word are either to use the 
FLDENV (which loads the complete FPU environment), or to carry out an 
arithmetic operation that sets the appropriate bits in the status word.  
For instance, loading an SNaN will set the "invalid" bit.

You can copy the status word to memory or the AX register with the FSTSW 
instruction, but I don't see what advantages this mirror scheme has over 
simply testing and setting the bits of the status register.  One 
potential pitfall with the direct approach is a math library routine 
might do something that sets an exception bit in the course of normal 
(unexceptional) computation.  I'm trying in vain to think of an example 
where this could actually occur.  OK, here's one: hypotl(3.E4000L, 
4.E4000L).  The interesting thing here is that even though the result 
doesn't overflow, the obvious implementation by sqrt(x*x + y*y) will 
overflow in the computation of x*x + y*y.  It might actually be most 
efficient to implement it this way, and test for over/underflow.  If 
over/underflow occurred, one would then go to a more complicated scaled 
computation.  This approach might be faster than testing each argument, 
or using the scaled computation for all arguments.  However, doing it 
this way would result in the overflow bit being set, because of the 
initial failed attempt, even if the result did not overflow.

By the way, I didn't have to worry about this in the hypot routine I 
wrote, because the dynamic range of doubles is so much smaller than the 
long doubles inside the coprocessor that such an over/underflow can't occur.

If we are thinking about using the exception mechanism, we should 
consider how it will affect the "builtin" math functions.  For instance, 
if you invoke sqrt() in a C program, and don't compile with 
-fno-builtin, the compiler will first try to compute the square root by 
simply using the fsqrt instruction.  If something goes wrong (for 
instance, for a negative argument), the library routine is called, 
because it presumably has the particular error handling that is 
appropriate.  We need to make sure that this mechanism still works.

>>In some ways, Annex F makes it easy for the library programmer, since 
>>one can often dispense with the argument tests and simply depend on the 
>>processor to issue the appropriate exceptions.
>>    
>>
>Except that feraiseexception requires us to be able to ``generate''
>such exceptions.
>  
>
(see above)

-Eric Rudd
rudd AT cyberoptics DOT com