Filter
Top Products
INTERRlJPI'
HANDLING
The
central
logic
of
this
approach
assumes
that
there
is
a
"list"
of
poosible
interrupt
sources
to
be
scanned,
and
that
passing
through
this
list
may
uncover one
(the
usual
case),
multiple,
or
zero
events
that
require
responses.
To
illustrate
the
second two
cases,
assume
that
the
possible
events
are
labelled
A
through
K,
and
that
the
interrupt
handler
tests
for
A,
then
B, and
so
on.
Assume
also
that
event
B
occurs
follCMed
quickly
by
event
J.
The
interrupt
handler
is
invoked
for
event
B ,
shortly
thereafter
the
IP
updates
J'
s
indicator
and
emits
a
second
interrupt
pulse,
which
is
latched.
The
handler
scans
its
list
of
event
indicators,
finds
that
both
B and J
have
occurred
and
responds
to
them
both.
Reaching
the
end
of
the
list,
the
interrupt
handler
enables
the
IP
interrupt
and
returns.
Imnediately,
J's
latched
interrupt
request
is
recognized
and
the
handler
is
invoked
again.
This
time,
however,
it
will
find
no
events
indicated
in
the
IP
processor
data
segment,
since
it
responded
to
both
B and J
in
the
previous
invocation.
It
will
simply
clear
the
interrupt
latch,
pass
through
the
list,
unmask
the
IP
interrupt,
and
return,
effectively
making a
null
response.
Table
0-1
lists
the
IP
processor
data
segment
subfields
that
the
IP
interrupt
handler
must examine
to
determine
the
source
of
an
interrupt.
Note
that
as
soon
as
the
handler
recx:>gnizes
that
an
event
indicator
is
"on",
it
should
turn
it
"off"
by
indivisibly
zeroing
the
field
using
the
INDIVISmLE
INSERr
SHORr
ORDINAL
function.
This
is
necessary
to
prevent
the
interrupt
handler
from
being
misled
in
its
next
invocation.
0-3