Message-Id: <200005231107.NAA06048@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: Tue, 23 May 2000 12:49:02 +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 At 12:04 23/05/00 +0300, Eli Zaretskii wrote: > >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. But this is before the IRET in exceptn.S file !! So this is not done in present DJGPP code ! >> >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. We do not read these docs in the same spirit I fear ! I really understood that you could have a generation of a second int 0x75 while the fnclex code is executed ! >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? The changes are quite limited : As I already said, the problem would be code that uses assembler to retrieve the status in the signal handler ! But this change to the libc source is enough to remove all spurious exceptions ! Index: go32/exceptn.S =================================================================== RCS file: /cvs/djgpp/djgpp/src/libc/go32/exceptn.S,v retrieving revision 1.4 diff -b -c -r1.4 exceptn.S *** exceptn.S 1999/07/11 09:09:06 1.4 --- exceptn.S 2000/05/23 10:46:53 *************** *** 285,290 **** --- 285,292 ---- ___djgpp_old_kbd: .long 0,0 .global ___djgpp_old_timer ___djgpp_old_timer: .long 0,0 + .global ___djgpp_fpu_status + ___djgpp_fpu_status : .word 0 .global ___djgpp_exception_state_ptr ___djgpp_exception_state_ptr: .long 0 exception_state: .space 64 *************** *** 295,300 **** --- 297,304 ---- .global ___djgpp_npx_hdlr ___djgpp_npx_hdlr: pushl %eax + fnstsw ___djgpp_fpu_status + fnclex xorl %eax,%eax outb %al,$0x0f0 movb $0x20,%al Index: pc_hw/fpu/clear87.S =================================================================== RCS file: /cvs/djgpp/djgpp/src/libc/pc_hw/fpu/clear87.S,v retrieving revision 1.1 diff -b -c -r1.1 clear87.S *** clear87.S 1995/02/25 04:33:10 1.1 --- clear87.S 2000/05/23 10:46:53 *************** *** 4,12 **** .text FUNC(__clear87) ! fstsw %ax movzwl %ax, %eax fclex ret --- 4,17 ---- .text FUNC(__clear87) ! xorl %eax, %eax ! xchgw ___djgpp_fpu_status,%ax ! movzwl %ax, %eax ! cmpl %eax,%eax ! jne L__clear87_end fstsw %ax movzwl %ax, %eax fclex + L__clear87_end: ret 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