Mail Archives: djgpp-workers/2000/05/22/06:27:32
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 -