Again we looked at the picture of the system with the bus connecting devices, PIC, and CPU, and also memory. The interrupting devices are connected by IRQ lines to the PIC, and the PIC has one line to, and one line from, the CPU.
It is very important to understand that the registers in the i/o devices and PIC can hold data over time, completely independently from the CPU. The devices, PIC, and CPU interact with each other in very specific ways, something like people coordinating work via phone calls.
The
interrupt cycle in the CPU
The
CPU composes an instruction “int $nn” using the nn
interrupt vector number, and
jams it into its instruction pipeline.
That helps us understand how it can keep track of behavior
logically before
and after the interrupt. See
Slide 10
for details.
The
interrupt cycle (but not the system call exception cycle that is so
similar)
sets IF=0 in EFLAGS, but this is not an extraordinary setting. It just means that
interrupt handlers start
off running with interrupts off, to ensure they have complete control
of the
system. Our simple
interrupt handlers
leave IF=0 for their whole execution, and depend on the final IRET
instruction
to restore the old EFLAGS, which must have IF=1.
The IRET also restores the old EIP, to resume
the interrupted execution. (The
fact
that the interrupt location can be boiled down to a single old-EIP
value, so it
happened between two certain instructions, is a major achievement of
pipelined
CPU design.)
Look
at the slides. Some
notes—
Slide
6 “CPU
Interrupt Handling” CPU
checks for interrupts between
instructions. See
Tan. pp 281-282 for
discussion about how difficult this simple idea is for a pipelined CPU,
but
that the Pentium does all this work, making the job of writing
OS’s much easier
for us than it might be.
pic_end_int(),
pic_enable_irq(int irqn), pic_disable_irq(int irqn) are functions
implemented
in the SAPC library, in directory $pclibsrc.
They are special to UMB’s SAPC environment,
although historically based
on Linux sources. The
code could be
ported to a Windows environment, but could not run there because user
code is
not allowed to interact directly with hardware (in Windows or UNIX.) It needs a kernel-like
environment to run in,
running in kernel mode on the CPU.
The
SAPC/Tutor setup provides this kernel-like environment.
(You could run Tutor off a floppy on your
home PC, but it’s not easy to set up mtip for downloading to
go with it.)
Slides
15-18: The UART is two devices in one package: receiver + transmitter. They share one IRQ line,
however, so have
only one interrupt handler (that is, one for COM1, another one for
COM2.) These
slides only cover receiver interrupts.
Note
that COM1 and COM2 are already in active use (or ready for it) when we
start
using them in a program on the SAPC.
COM2 is the console line, so the Tutor prompt is output on
COM2 and our
“go 100100” is input on that line.
COM1
is used for the remote gdb protocol.
Both these activities use only programmed i/o, i.e., no
interrupts.