Re: enabling x87 interrupts


"Alexei A. Frounze" <spamtrap@xxxxxxxxxx> wrote in message
news:9tGdnYy8o5tcxnPZnZ2dnUVZ_sadnZ2d@xxxxxxxxxxxxxx
Wendy E. McCaughrin wrote:
Is the 8259A (PIC) still used to enable interrupts? I unmasked bit #2
in the master PIC and bit #5 (a.k.a. #13) in the slave PIC it cascades
with, to enable FPU interrupts. I have unmasked all 6 exceptions in
the FPU's control-word and use STI. Yet, INT 75h is never accessed.

Nowadays, there's no external FPU chip that would assert interrupts on the
PIC. The CPU itself handles all the FP instructions. And my bet is that
it's
configured in such a way that you should get exceptions, not interrupts.


What Alexei is refering to is the NE flag in CR0. If you didn't clear NE
when switching to protected mode (recommended, set later if necessary), then
you may not be getting Int 0x75. If the CR0 NE flag is 0, then an IRQ13
(Int 0x75) is (or should be) generated, otherwise a CPU exception 10h (Int
0x10) is (or should be) generated.

"While CR0.NE is 0, the processor is in what is called "MS-DOS compatibility
mode"; here the South Bridge is expected to generate an IRQ13 in response to
the FERR# assertion, to signal the FPU exception back to the processor.

While CR0.NE is 1, the processor is in what is called "native mode"; here
the #MF exception is used to signal the FPU exception; software is expected
to either disable the IRQ13 generation in the South Bridge, or mask off
IRQ13 via the interrupt controller, or ignore any INTRs caused by IRQ13.
Waiting FPU instructions and MMX instructions do generate the #MF exception;
no-wait FPU instructions, FXSAVE, and FXRSTOR don't (i.e. execution
continues)."

FERR# information:
http://www.sandpile.org/ia32/legacy.htm


The following Intel document, which I haven't read, seems to cover this
issue.
"Software and Hardware Considerations for FPU Exception Handlers for Intel
Architecture Processors" Intel AP-578
http://www.intel.com/design/intarch/applnots/243291.htm



Rod Pemberton

.

Relevant Pages

  • Re: nasm segment directive
    ... To determine what the "native" behavior of the FPU is, we could design a bootsector to test the behavior. ... There's a thread on clax about "Floating Point Exception" - a guy did an ordinary "div cl" without clearing ah. ... I rebuilt the library with "DEBUG" defined, it informed me that the interrupt routine wasn't in ROM... ... Maybe dos is hooking int 10h. ...
    (alt.lang.asm)
  • Re: GetPC code (was: Shellcode from ASCII)
    ... I've been looking into FPU stuff a bit lately and decided to look into ... you can do a GetPC procedure without simulating any exception. ... the data stored by fnstenv isn't influenced by the exception nor ... using fstenv/fnstenv is to have previously executed an FP instruction. ...
    (Vuln-Dev)
  • Re: [patch 2.6.13-rc3a] i386: inline restore_fpu
    ... >>If this patch makes a difference, could you do me a favour and check ... > That lazy FPU is a huge optimization on 99.9% of all loads, ... > big hit on doing the FP restore exception (an exception is a lot more ... why the code got lazy. ...
    (Linux-Kernel)
  • Re: weirdness with Pentium FPU
    ... >>Some algorithms seem to be prone to underflow whereas others ... there is an exception of some kind. ... The FPU has both a two byte "control word" which contains bits ...
    (comp.lang.asm.x86)