number.
3. The CPU responds with another INTA# pulse (S0-S2 low) to indicate its readiness to
receive the vector number.
4. The 8259A sends the preprogrammed vector number to the CPU on the data bus
5. The CPU latches the vector number and completes the exception processing state.
Motorola chips use both vectored and autovectored devices. If a device is autovectored, this
means that it uses a default vector number which depends on the priority level of the interrupt. A
special section of the Exception vector table contains the starting addresses of handlers for
autovectored devices (vector numbers 25-31). When a hardware interrupt occurs, the MC680x0
also executes an . Unlike the Intel interrupt acknowledge cycle, the Motorola chip will also need
to determine which sort of interrupt is occurring and thus how it should obtain the vector
number. This cycle consists of the following steps:
1. The CPU first sets the function code lines, FC0-FC2, high to indicate what is called a
"CPU space cycle", i.e., a special function CPU cycle, as opposed to a normal instruction
execution. These lines are the counterpart to Intel's S0-S2 lines.
2. The CPU sets the address lines A16-A19 high to indicate that this space cycle is more
specifically an interrupt acknowledge cycle. The function code lines alone are not enough
to determine the exact type of bus cycle, as they are on the Intel chip.
3. The CPU places : : on lines A1-A3 of the address bus and sets the remaining
address lines high
4. The CPU asserts , and ( is not actually used, since vector numbers are one
byte, but it is set for consistency with other types of CPU cycles (review the Motorola
read and write bus cycle description in Machine Overview if you have forgotten the
meaning of these signals).
5. The CPU sets the R/ signal to read
a. If the interrupt is vectored, the device places the vector number on the data bus and
asserts
b. If the device is autovectored, the device asserts (Valid Peripheral Address). This
signals the CPU to calculate the vector number from the priority level of the device
(that is, the current value of : : ).
Context Switches and Interrupt Latency
It should be clear that processing interrupts takes time away from processing the instructions of
user programs. Conversely, we might also contend that processing user programs takes time
away from attending to peripheral devices! In either case, it is to our best interest to make
interrupt processing as fast as possible. We also would like to have peripheral device requests to
receive service as promptly as possible. This latter goal leads us to examine what factors affect
the amount of time it will take for a peripheral device to receive the attention of the CPU and
thus affect the performance characteristics of I/O operations. We learned about context switches
when we talked about multi-user or multitasking systems. At that time, we learned that context
switches entail saving the current CPU register values and restoring a set of values that belonged
to the process that was gaining access to the CPU. When we discuss context switches in terms of
interrupt processing, we are talking about a similar process. Context switches are again the action
of saving a state. This time, however, we are not changing from one user or program to another,
but from a normal execution state (typically a user program running in user mode) to another
To Next Page
Loading...