Mail Archives: djgpp-workers/2000/05/23/05:07:25
On Mon, 22 May 2000, Pierre Muller wrote:
> >> 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
This is simply a ripped-out and slightly reformatted version of
Appendix E to the Intel Pentium manual. But I read it again anyway, to
refresh memory ;-)
However, I don't see the recommendation that you mentioned above (to
clear the FPU before accessing the port 0F0h). As far as I understand,
they recommend to do it the other way around: write to the port first, to
deactivate the interrupt request that triggers Int 75h, and then clear
the FPU before IRET.
> >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 !
Intel docs doesn't seem to explain the case where you get 2 or more
interrupts for a single FP exception; at least I cannot find this
explanation anywhere in this document. What they do explain is how can
an interrupt arrive at the ``wrong'' time (when the program doesn't
expect it). But this doesn't double the interrupt, it just makes it
appear at another point in time.
In summary, I don't understand why does Intel recommend to reset the FPU
exceptions before IRET. Our interrupt handler does write to port 0F0h,
and it also sends EOI to the master and slave PICs. I don't see why it
would need to do anything else, and how could the fact that we don't
clear the exceptions cause another Int 75h.
Btw, this was discussed in preparation for v2.03, and I asked whether it
made sense to clear the FPU inside the handler. We didn't do that
because it was too close to release (or so we thought ;-), but perhaps we
could do that now.
Did you try to add FNCLEX inside the NPX handler in exceptn.S, and if so,
did it eliminate the double-interrupt problem on Windows?
- Raw text -