4-12
PROCEDURE CALLS, INTERRUPTS, AND EXCEPTIONS
rupt descriptor table (IDT). When the handler has completed handling the interrupt or exception,
program control is returned to the interrupted program or task.
The operating system, executive, and/or device drivers normally handle interrupts and excep-
tions independently from application programs or tasks. Application programs can, however,
access the interrupt and exception handlers incorporated in an operating system or executive
through assembly-language calls. The remainder of this section gives a brief overview of the
processors interrupt and exception handling mechanism. Refer to Chapter 5, Interrupt and
Exception Handling of the Intel Architecture Software Developers Manual, Volume 3, for a
detailed description of this mechanism.
The IA defines 17 predefined interrupts and exceptions and 224 user defined interrupts, which
are associated with entries in the IDT. Each interrupt and exception in the IDT is identified with
a number, called a vector. Table 4-1 lists the interrupts and exceptions with entries in the IDT
and their respective vector numbers. Vectors 0 through 8, 10 through 14, and 16 through 19 are
the predefined interrupts and exceptions, and vectors 32 through 255 are the user-defined inter-
rupts, called maskable interrupts.
Note that the processor defines several additional interrupts that do not point to entries in the
IDT; the most notable of these interrupts is the SMI interrupt. Refer to Chapter 5, Interrupt and
Exception Handling of the Intel Architecture Software Developers Manual, Volume 3, for more
information about the interrupts and exceptions that the IA supports.
When the processor detects an interrupt or exception, it does one of the following things:
Executes an implicit call to a handler procedure.
Executes an implicit call to a handler task.
The Pentium
®
III processor can generate two types of exceptions:
Numeric exceptions
Non-numeric exceptions
When numeric exceptions occur, a processor supporting Streaming SIMD Extensions takes one
of two possible courses of action:
The processor can handle the exception by itself, producing the most reasonable result and
allowing numeric program execution to continue undisturbed (i.e., masked exception
response).
A software exception handler can be invoked to handle the exception (i.e., unmasked
exception response).
Each of the numeric exception conditions has corresponding flag and mask bits in the MXCSR
(Streaming SIMD Extensions control status register). If an exception is masked (the corre-
sponding mask bit in MXCSR = 1), the processor takes an appropriate default action and
continues with the computation. If the exception is unmasked (mask bit = 0) and the OS supports
SIMD floating-point exceptions (i.e. CR4.OSXMMEXCPT = 1), a software exception handler
is invoked immediately through SIMD floating-point exception interrupt vector 19. If the excep-
tion is unmasked (mask bit = 0) and the OS does not support SIMD floating-point exceptions
(i.e. CR4.OSXMMEXCPT = 0), an invalid opcode exception is signaled instead of a SIMD
