Mail Archives: djgpp-workers/2000/05/23/06:55:18
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
- Raw text -