Date: Tue, 23 May 2000 12:04:21 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Pierre Muller cc: djgpp-workers AT delorie DOT com Subject: Re: Simple C program showing FPU problem ! In-Reply-To: <200005220902.LAA17459@cerbere.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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?