Date: Mon, 22 May 2000 13:27:11 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Pierre Muller 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.