Volume 1 Basic Architecture (794100), страница 89
Текст из файла (страница 89)
Operating systems that use FXSAVE to save the x87 FPU statebefore making it available for another thread (e.g., during thread switch time)should take precautions not to pass a “dirty” x87 FPU to another application.D.4DIFFERENCES FOR HANDLERS USING NATIVE MODEThe 8087 has an INT pin which it asserts when an unmasked exception occurs. Butthere is no interrupt input pin in the 8086 or 8088 dedicated to its attachment, nor aninterrupt vector number in the 8086 or 8088 specific for an x87 FPU error assertion.Beginning with the Intel 286 and Intel 287 hardware, a connection was dedicated tosupport the x87 FPU exception and interrupt vector 16 was assigned to it.D.4.1Origin with the Intel 286 and Intel 287, and Intel386and Intel 387 ProcessorsThe Intel 286 and Intel 287, and Intel386 and Intel 387 processor/coprocessor pairsare each provided with ERROR# pins that are recommended to be connectedbetween the processor and x87 FPU.
If this is done, when an unmasked x87 FPUexception occurs, the x87 FPU records the exception, and asserts its ERROR# pin.The processor recognizes this active condition of the ERROR# status line immediatelybefore execution of the next WAIT or x87 FPU instruction (except for the no-waittype) in its instruction stream, and branches to the routine at interrupt vector 16.Thus an x87 FPU exception will be handled before any other x87 FPU instruction(after the one causing the error) is executed (except for no-wait instructions, whichwill be executed without triggering the x87 FPU exception interrupt, but it will remainpending).Vol.
1 D-29GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERSUsing the dedicated INT 16 for x87 FPU exception handling is referred to as thenative mode. It is the simplest approach, and the one recommended most highly byIntel.D.4.2Changes with Intel486, Pentium and Pentium ProProcessors with CR0.NE[bit 5] = 1With these latest three generations of the IA-32 architecture, more enhancementsand speedup features have been added to the corresponding x87 FPUs.
Also, the x87FPU is now built into the same chip as the processor, which allows further increasesin the speed at which the x87 FPU can operate as part of the integrated system. Thisalso means that the native mode of x87 FPU exception handling, selected by settingbit NE of register CR0 to 1, is now entirely internal.If an unmasked exception occurs during an x87 FPU instruction, the x87 FPU recordsthe exception internally, and triggers the exception handler through interrupt 16immediately before execution of the next WAIT or x87 FPU instruction (except forno-wait instructions, which will be executed as described in Section D.4.1, “Originwith the Intel 286 and Intel 287, and Intel386 and Intel 387 Processors”).An unmasked numerical exception causes the FERR# output to be activated evenwith NE = 1, and at exactly the same point in the program flow as it would have beenasserted if NE were zero.
However, the system would not connect FERR# to a PIC togenerate INTR when operating in the native, internal mode. (If the hardware of asystem has FERR# connected to trigger IRQ13 in order to support MS-DOS, but anoperating system using the native mode is actually running the system, it is the operating system’s responsibility to make sure that IRQ13 is not enabled in the slavePIC.) With this configuration a system is immune to the problem discussed in SectionD.2.1.3, “No-Wait x87 FPU Instructions Can Get x87 FPU Interrupt in Window,” wherefor Intel486 and Pentium processors a no-wait x87 FPU instruction can get an x87FPU exception.D.4.3Considerations When x87 FPU Shared Between Tasks UsingNative ModeThe protocols recommended in Section D.3.6, “Considerations When x87 FPU SharedBetween Tasks,” for MS-DOS compatibility x87 FPU exception handlers that areshared between tasks may be used without change with the native mode.
However,the protocols for a handler written specifically for native mode can be simplified,because the problem of a spurious floating-point exception interrupt occurring whilethe kernel is executing cannot happen in native mode.The problem as actually found in practical code in a MS-DOS compatibility systemhappens when the DNA handler uses FNSAVE to switch x87 FPU contexts. If an x87FPU exception is active, then FNSAVE triggers FERR# briefly, which usually will causethe x87 FPU exception handler to be invoked inside the DNA handler.
In native mode,neither FNSAVE nor any other no-wait instructions can trigger interrupt 16. (AsD-30 Vol. 1GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERSdiscussed above, FERR# gets asserted independent of the value of the NE bit, butwhen NE = 1, the operating system should not enable its path through the PIC.)Another possible (very rare) way a floating-point exception interrupt could occurwhile the kernel is executing is by an x87 FPU immediate exception case having itsinterrupt delayed by the external hardware until execution has switched to thekernel.
This also cannot happen in native mode because there is no delay throughexternal hardware.Thus the native mode x87 FPU exception handler can omit the test to see if the kernelis the x87 FPU owner, and the DNA handler for a native mode system can omit thestep of setting the kernel as the x87 FPU owner at the handler’s beginning. Sincehowever these simplifications are minor and save little code, it would be a reasonableand conservative habit (as long as the MS-DOS compatibility mode is widely used) toinclude these steps in all systems.Note that the special DP (Dual Processing) mode for Pentium processors, and alsothe more general Intel MultiProcessor Specification for systems with multiplePentium, P6 family, or Pentium 4 processors, support x87 FPU exception handlingonly in the native mode.
Intel does not recommend using the MS-DOS compatibilitymode for systems using more than one processor.Vol. 1 D-31GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERSD-32 Vol. 1APPENDIX EGUIDELINES FOR WRITING SIMD FLOATING-POINTEXCEPTION HANDLERSSee Section 11.5, “SSE, SSE2, and SSE3 Exceptions,” for a detailed discussion ofSIMD floating-point exceptions.This appendix considers only SSE/SSE2/SSE3 instructions that can generate numeric(SIMD floating-point) exceptions, and gives an overview of the necessary support forhandling such exceptions. This appendix does not address instructions that do notgenerate floating-point exceptions (such as RSQRTSS, RSQRTPS, RCPSS, or RCPPS),any x87 instructions, or any unlisted instruction.For detailed information on which instructions generate numeric exceptions, and alisting of those exceptions, refer to Appendix C, “Floating-Point ExceptionsSummary.” Non-numeric exceptions are handled in a way similar to that for the standard IA-32 instructions.E.1TWO OPTIONS FOR HANDLING FLOATING-POINTEXCEPTIONSJust as for x87 FPU floating-point exceptions, the processor takes one of two possiblecourses of action when an SSE/SSE2/SSE3 instruction raises a floating-point exception:•If the exception being raised is masked (by setting the corresponding mask bit inthe MXCSR to 1), then a default result is produced which is acceptable in mostsituations.
No external indication of the exception is given, but the correspondingexception flags in the MXCSR are set and may be examined later. Note thoughthat for packed operations, an exception flag that is set in the MXCSR will not tellwhich of the sub-operands caused the event to occur.•If the exception being raised is not masked (by setting the corresponding maskbit in the MXCSR to 0), a software exception handler previously registered by theuser with operating system support will be invoked through the SIMD floatingpoint exception (#XM, vector 19). This case is discussed below in Section E.2,“Software Exception Handling.”E.2SOFTWARE EXCEPTION HANDLINGThe exception handling routine reached via interrupt vector 19 is usually part of thesystem software (the operating system kernel). Note that an interrupt descriptortable (IDT) entry must have been previously set up for this vector (refer to ChapterVol.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
