Filter
Top Products
SYSTEM ARCHITECTURE
allowed to call the service procedures but not the
kernel; service procedures can, however, call the
kernel. Accordingly, the operating system has
provided a gate for the service procedures; the
privilege
level
of
this gate
is
3
so
user code can
call through
it.
By assigning the kernel gate
privilege
level
I , the operating system permits the
service procedures
to
call the kernel, but denies
access to the user code, which
is
less-privileged
than the kernel gate. Thus, an operating system
can
use
gates to precisely define
its
entry points,
including the privilege
level
required to use
an
entry point.
In
order
to
make system services
callable from all tasks, operating systems nor-
mally place their call gate(s) in the Global
Descriptor Table.
To
call through a trap gate, a task issues an
Interrupt instruction; to call through a call gate,
a task issues
an
ordinary intersegment Call
instruction. Both instructions change the task's
privilege
level
and change
to
the stack defined (in
the task's TSS) for the higher privilege
level.
(The
operating system must have its own stack in
order to guarantee that
it
has enough stack space
t PERMITIEO
CALL
DR
~
PROHIBITED
CALL
DR
INTERRUPT
INSTRUCTION 0 INTERRUPT INSTRUCITDN
Figure
3-10.
Gates
as
Protected
Entry
Points
to run; application tasks cannot safely be trusted
to have left sufficient stack space.)
Before calling through a call gate, a task can
push parameters on its stack as it would before
calling another procedure. The
80386 auto-
matically copies the parameters to the more-
privileged stack (the Dword Count
field
in the
call gate tells the
80386 how many dwords of
parameters
to
copy). Systems that call through
trap gates can pass parameters in registers.
3.6 Interrupts and Exceptions
Devices generate
interrupts
when they require
attention, while instructions may incur exceptions
when their execution encounters a special condi-
tion, such as a not-present page. A typical
interrupt
or
exception requires rapid invocation
of
a software handler that responds
to
the
interrupt
or
exception. When the handler returns,
the
80386 resumes execution
of
the instruction
stream that was interrupted
or
incurred the
exception. Because
of
their underlying similarity,
the
80386
treats interrupts and exceptions in a
unified manner.
Each interrupt source and each exception type
has an identifying number in the range
0-255; the
80386 uses this number to invoke the handler
associated with the interrupt
or
exception. Since
exceptions are detected by the
80386,
it
defines
the exception numbers shown in Table
3-1.
Interrupt numbers are defined by the operating
system. The operating system initializes an 8259A
Programmable Interrupt Controller
so
that each
interrupt source
is
associated with a number.
When an interrupt occurs, the 8259A supplies
the
80386 with the number
of
the interrupt.
Interrupt instructions supply their numbers in
their operands. Note that for compatibility
with
current and future Intel products, interrupti
exception numbers
0-31
must not be used except
as defined in Table
3-1.
All other numbers may be
used
freely.
3-14