Intel 253668-032US User Manual
Vol. 3 19-15
ARCHITECTURE COMPATIBILITY
the 8087 interrupt, both exception vectors should call the floating-point-error excep-
tion handler. Some instructions in a floating-point-error exception handler may need
to be deleted if they use the interrupt controller. The P6 family, Pentium, and Intel486
processors have signals that, with the addition of external logic, support reporting for
emulation of the interrupt mechanism used in many personal computers.
On the P6 family, Pentium, and Intel486 processors, an undefined floating-point
opcode will cause an invalid-opcode exception (#UD, interrupt vector 6). Undefined
floating-point opcodes, like legal floating-point opcodes, cause a device not available
exception (#NM, interrupt vector 7) when either the TS or EM flag in control register
CR0 is set. The P6 family, Pentium, and Intel486 processors do not check for floating-
point error conditions on encountering an undefined floating-point opcode.
tion handler. Some instructions in a floating-point-error exception handler may need
to be deleted if they use the interrupt controller. The P6 family, Pentium, and Intel486
processors have signals that, with the addition of external logic, support reporting for
emulation of the interrupt mechanism used in many personal computers.
On the P6 family, Pentium, and Intel486 processors, an undefined floating-point
opcode will cause an invalid-opcode exception (#UD, interrupt vector 6). Undefined
floating-point opcodes, like legal floating-point opcodes, cause a device not available
exception (#NM, interrupt vector 7) when either the TS or EM flag in control register
CR0 is set. The P6 family, Pentium, and Intel486 processors do not check for floating-
point error conditions on encountering an undefined floating-point opcode.
19.18.6.7 Assertion of the FERR# Pin
When using the MS-DOS compatibility mode for handing floating-point exceptions,
the FERR# pin must be connected to an input to an external interrupt controller. An
external interrupt is then generated when the FERR# output drives the input to the
interrupt controller and the interrupt controller in turn drives the INTR pin on the
processor.
For the P6 family and Intel386 processors, an unmasked floating-point exception
always causes the FERR# pin to be asserted upon completion of the instruction that
caused the exception. For the Pentium and Intel486 processors, an unmasked
floating-point exception may cause the FERR# pin to be asserted either at the end of
the instruction causing the exception or immediately before execution of the next
floating-point instruction. (Note that the next floating-point instruction would not be
executed until the pending unmasked exception has been handled.) See Appendix D,
“Guidelines for Writing x87 FPU Extension Handlers,” in the Intel® 64 and IA-32
Architectures Software Developer’s Manual, Volume 1, for a complete description of
the required mechanism for handling floating-point exceptions using the MS-DOS
compatibility mode.
Using FERR# and IGNNE# to handle floating-point exception is deprecated by
modern operating systems; this approach also limits newer processors to operate
with one logical processor active.
the FERR# pin must be connected to an input to an external interrupt controller. An
external interrupt is then generated when the FERR# output drives the input to the
interrupt controller and the interrupt controller in turn drives the INTR pin on the
processor.
For the P6 family and Intel386 processors, an unmasked floating-point exception
always causes the FERR# pin to be asserted upon completion of the instruction that
caused the exception. For the Pentium and Intel486 processors, an unmasked
floating-point exception may cause the FERR# pin to be asserted either at the end of
the instruction causing the exception or immediately before execution of the next
floating-point instruction. (Note that the next floating-point instruction would not be
executed until the pending unmasked exception has been handled.) See Appendix D,
“Guidelines for Writing x87 FPU Extension Handlers,” in the Intel® 64 and IA-32
Architectures Software Developer’s Manual, Volume 1, for a complete description of
the required mechanism for handling floating-point exceptions using the MS-DOS
compatibility mode.
Using FERR# and IGNNE# to handle floating-point exception is deprecated by
modern operating systems; this approach also limits newer processors to operate
with one logical processor active.
19.18.6.8 Invalid Operation Exception On Denormals
An invalid-operation exception is not generated on the 32-bit x87 FPUs upon encoun-
tering a denormal value when executing a FSQRT, FDIV, or FPREM instruction or upon
conversion to BCD or to integer. The operation proceeds by first normalizing the
value. On the 16-bit IA-32 math coprocessors, upon encountering this situation, the
invalid-operation exception is generated. This difference has no impact on existing
software. Software running on the 32-bit x87 FPUs continues to execute in cases
where the 16-bit IA-32 math coprocessors trap. The reason for this change was to
eliminate an exception from being raised.
tering a denormal value when executing a FSQRT, FDIV, or FPREM instruction or upon
conversion to BCD or to integer. The operation proceeds by first normalizing the
value. On the 16-bit IA-32 math coprocessors, upon encountering this situation, the
invalid-operation exception is generated. This difference has no impact on existing
software. Software running on the 32-bit x87 FPUs continues to execute in cases
where the 16-bit IA-32 math coprocessors trap. The reason for this change was to
eliminate an exception from being raised.