Message-Id: <200005221056.MAA19766@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 12:36:13 +0200 To: Eli Zaretskii From: Pierre Muller Subject: Re: Simple C program showing FPU problem ! Cc: djgpp-workers AT delorie DOT com References: <200005220902 DOT LAA17459 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 >> 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. I don't think that the FPU exceptions in the status word are cleared when interrupt of the primary running Make is called by the OS ! The error is aredirection error, not a resetting error. >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? The Intel docs above even explicitly say that the only safe way is to reset the exceptions inside the int 0x75 handler ! >> 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. But if you want to simulate a FPU exception in C, you should use _raise(SIGFPE), not a call to interrupt 0x75 ! INT 75 ---- - IRQ13 - MATH COPROCESSOR EXCEPTION (AT and up) callout or callback (usually hooked rather than called) >> I don't think that normal code should call this interrupt at all ! Category: H - hardware Inp.: Desc: redirected to INT 02 by the BIOS, for compatibility with the PC Notes: may be masked by setting bit 5 on I/O port A1h not all clones wire the coprocessor to generate this IRQ; some systems generate an NMI (see INT 02) or assert the -ERROR pin on the CPU (see INT 10"COPROCESSOR") under DESQview, only the INT 15h vector and BASIC segment address (the word at 0000h:0510h) may be assumed to be valid for the handler's process SeeAlso: INT 10"COPROCESSOR",INT 5D"IRQ13",MEM 0040h:006Bh INT 75 Copied from Ralf Brown's Interrupt List 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