Message-Id: <200005171510.LAA28895@delorie.com>
From: "Dieter Buerssner" <buers AT gmx DOT de>
To: djgpp-workers AT delorie DOT com
Date: Wed, 17 May 2000 17:16:36 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: Re: Math functions
In-reply-to: <200005162122.RAA20137@indy.delorie.com>
References: <200005161320 DOT JAA11285 AT delorie DOT com> (buers AT gmx DOT de)
X-mailer: Pegasus Mail for Win32 (v3.12b)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by delorie.com id LAA28897
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

On 16 May 00, at 17:22, Eli Zaretskii wrote:

Eli, I think we came to an agreement. I also think, that this is not 
of general interest anymore, so I'm not posting this to the mailing 
list.

> > Loading a NaN into a FPU register seems not to be an invalid 
> > operation (which makes sense to me).
> 
> Intel's text is limited to a QNaN, the one which is produced as
> invalid operations' masked response.  If you tried that with an SNaN,
> perhaps the behavior is different. 

Yes. But there is no signalling Infinity.

> > after silent inf   x = Inf, sw = 0x00
> > after trapping inf x = Inf, sw = 0x04
> > after silent NaN   x = NaN, sw = 0x00
> > after trapping NaN x = NaN, sw = 0x01
> 
> I get the same, but we were talking about a NaN that resulted from an
> invalid operation, like sqrt(-1).  Loading a NaN forcibly is hardly an
> interesting case, right?

I thought it was an interesting case. The forcibly loading of NaNs 
and Infs is the method used by Eric.

Also, earlier in the threat you have written

> I don't think we should rely on exceptions being masked.  Someone
> could unmask them to debug their application code, without expecting
> the library functions to trigger exceptions.

This seems, that you prefered the "silent return method". My code 
snippet has shown, that this won't even be indicated in the status 
word. The "silent return method" currently is used by Eric's code. I 
have used the silent return method as well, but recently came to the 
conclusion, that it is wrong, and started to change.

One other point, I have more or less solved the inline assembly 
issues, I noted in this thread. I made an embarassing error. When 
rereading the gcc manual sections, I somehow managed to read the dvi 
file of an old manual. No idea, why it came in my mind to read the 
dvi. Useually I use info, which would have found the correct version. 
In the newer manual most of the points I raised, are described. 

Regards,
Dieter Bürßner