Mail Archives: djgpp-workers/2000/05/22/04:48:04
At 16:38 20/05/00 -0400, you wrote:
>> Date: Thu, 18 May 2000 17:04:04 +0200
>> From: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
>>
>> I send the source code of a very simple C program that should this bug
>>
>> The source follows Eli's restriction's that the FPU must be reset
>> inside the signal handler but when run on a Pentium II 200 MHz (non MMX)
>> under Win95 I still get a nonzero overridecount meaning that a
>> second exception is sometimes raised inside the signal handler itself.
>
>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 ?
>> This behavior is documented in the Intel docs, that say the
>> the FPU status word should be reset before resetting the IO port.
>
>Please tell where exactly do you see this in the Intel docs, I'm not
>sure I understand the issue from this single sentence.
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
>Right now, it looks like the signals you get inside the signal handler
>come from outside the program. I'm guessing that they happen because
>some other piece of Windows software that works in parallel to your
>program issues FP instructions, and your program gets Int 75h that it
>didn't deserve.
No I really believe that its the program itself that creates those
spurious signals as explained in the Intel docs referenced above !
But having lots of other programs running enhances the rate of these fake
exceptions !
>Note that the low-order byte of the FPU status word is zero when these
>extra signals are delivered. This alone should tell that those are
>fake signals, not originating from your program that divides by zero.
>
>I changed your signal handler as shown below, and the extra signals
>seem to be effectively ignored, they do not cause any abnormal
>behavior outside the handler. Perhaps you could do something similar
>in your Pascal support routines. For example, you could ignore those
>signals.
>
> void
> fpesig (i)
> int i;
> {
> void (*oldFPE)(int) = signal (SIGFPE, SIG_IGN);
> fpustate=_clear87();
> if ((fpustate & 0xff) != 0)
> level++;
> signal (SIGFPE, oldFPE);
> longjmp(t,1);
> }
>
>The two lines which set SIGFPE to SIG_IGN are just due to paranoia:
>the trick with ignoring signals whose exception bits are all reset
>works even if I remove those two lines.
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 !)
The other fix method is a bit more complicated :
- reset the FPU exceptions inside the inteerupt 0x75 handler in exceptn.S
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 !
The problem with this second method would be code using direct assembler
to retrieve the FPU exception ! So this could break existing code !!
Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller AT ics DOT u-strasbg DOT fr
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
- Raw text -