Date:	Mon, 22 May 2000 13:27:11 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Simple C program showing FPU problem !
In-Reply-To:	<200005220902.LAA17459@cerbere.u-strasbg.fr>
Message-ID:	<Pine.SUN.3.91.1000522131831.26547B-100000@is>
MIME-Version:	1.0
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

On Mon, 22 May 2000, Pierre Muller wrote:

> >I can confirm these symptoms: on Windows 98, I get about 0.01% of
> >signals inside the signal handler.
> 
>   What type of processor do you have on this system ?

Intel Celeron 400MHz.

> See
> http://developer.intel.com/design/intarch/techinfo/Pentium/fpuhandl.htm
> Section 
>                         No-Wait FPU Instructions Can Get FPU Interrupt in
> Window
> 
> http://developer.intel.com/design/intarch/techinfo/Pentium/fpuhandl.htm#2195

Thanks for the pointers, I will look them up.

>   OK, if indeed the exceptions are allways resetted before the second 
> sporadic exception occurs then we could simply ignore them at the
> djgpp_exception_processor function !
>   But this could give problems if someone uses explicit calls to interrupt
> 0x75
> (even if I don't really know if this is acceptable !)

Yes, for this and other good reasons, I think it is not a good idea to 
ignore these exceptions without passing them to the application.  For one 
thing, it would prevent Make from reporting that the program aborted due 
to SIGFPE (recall our previous discussions about SIGFPE in nested 
programs on Windows).  I introduced a small change in Make which cause it 
to print a nice "*** Floating-point exception" message when that 
happens.  If we ignore these signals, you will see that the program 
seemingly exited normally, when in fact it was aborted.

We could always document this quirk of Windows and advise programmers to 
look at the FPU status word before they decide what to do with the 
signal.  I think this is sufficient to cover this problem.

>   The other fix method is a bit more complicated :
>   - reset the FPU exceptions inside the inteerupt 0x75 handler in exceptn.S

Is it at all safe to issue FP instructions inside a handler for Int 75h?

> file but after having saved the exceptions with a fnstsw instruction 
> (lets say to a locked global data address label  _djgpp_fpu_exception_status
>  
>  - change the _clear87 code so that it checks
> if _dgjpp_fpu_exception_status is sets (non zero)
> if non zero, use that value and reset it to zero,
> otherwise use the fnstsw instruction !

This has the same drawback as ignoring the exception: signals that 
have their exception bits reset will not be reported to the application, 
since they look like no-exception condition.

- Raw text -