Message-Id: <200005220902.LAA17459@cerbere.u-strasbg.fr> X-Sender: muller AT ics DOT u-strasbg DOT fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 22 May 2000 10:42:40 +0200 To: djgpp-workers AT delorie DOT com From: Pierre Muller Subject: Re: Simple C program showing FPU problem ! Cc: Eli Zaretskii References: <200005181522 DOT RAA01200 AT cerbere DOT u-strasbg DOT fr> <200005181208 DOT OAA08131 AT lws256 DOT lu DOT erisoft DOT se> <200005181522 DOT RAA01200 AT cerbere DOT u-strasbg DOT fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: djgpp-workers AT delorie DOT com At 16:38 20/05/00 -0400, you wrote: >> Date: Thu, 18 May 2000 17:04:04 +0200 >> From: Pierre Muller >> >> 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