Mail Archives: djgpp-workers/2000/05/22/06:43:24
>> 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
- Raw text -