Interrupts
1. Introduction
At certain times during system operation, internal or external events may require the execution of pieces of software outside of explicit flow of control.
Some of these events are relevant to the currently executing process, and normally invoke software in the context of the current process. The notification of these events is termed an exception.
Other events are relevant to other processes, or to the system as a whole, and are serviced in a system-wide context. The notification process for these events is termed an interrupt.
Some interrupts are so urgent that they require high priority service. To meet these needs, the VAX-11 has priority logic that grants interrupt service to the highest priority event at any point in time. The priority associated with an interrupt is termed its interrupt priority level (IPL).
The processor arbitrates interrupt requests according to priority. Only when the priority of an interrupt request is higher than the current IPL (bits<20:16> of the Processor Status Longword) does the processor raise the IPL and service the interrupt request. The interrupt service routine is entered at the IPL of the interrupt request and does not usually change the IPL set by the processor.
Interrupt requests can come from devices, controllers, or the processor itself. Software executing in kernel mode can raise and lower the priority of the processor by executing "MTPR src, IPL" where src contains the new priority desired.
Most service routines for software-generated exceptions execute at IPL 0. However, if a serious system failure occurs, the processor raises the IPL to the highest level (1F to prevent interruption until the problem is corrected. Exception service routines are usually coded to avoid exceptions; however, nested exceptions may rarely occur in the case of an access control violation, reserved operand, or reserved addressing mode fault.
2. Processor Interrupt Priority Levels (IPLs)
The processor has 31 interrupt
priority levels (IPLs), divided into 15 software
levels (numbered 1 to F) and 16 hardware levels (
to 
). User applications, system calls, and system services all
run at IPL 0, which may be thought of as process level. Higher numbered IPLs have higher priority; that is to say, any requests at
an interrupt level higher than the processor’s current IPL interrupt
immediately, but requests at a lower or equal level are deferred.
Interrupt levels 1 through F exist
entirely for use by software. No device can request interrupts on those levels,
but software can force an interrupt by executing
"MTPR src, SIRR" (Software Interrupt Request Register). Once a
software interrupt request is made, it is cleared by hardware when the
interrupt is taken.
Interrupt levels to 
are
for use by devices and controllers.
Interrupt levels 
to are
used by urgent conditions, including the interval clock, serious errors, and
power fail.
Some known IPLs:
- System Clock:
- Terminal:
3. Contrast between Exceptions and Interrupts
Generally, exceptions and interrupts are very similar. When either is initiated, both the Processor Status Longword (PSL) and the Program Counter (PC) are pushed onto a stack. However, there are some differences:
- An exception condition is caused by the execution of the current instruction, while an interrupt is caused by some activity in the computing system that usually is independent of the current in struction.
- An exception condition usually is serviced in the context of the process that produced the exception condition, while an interrupt is serviced independently from the current process.
- The IPL of the processor usually is not changed when the processor initiates an exception, while the IPL always is raised when an interrupt is serviced.
- Enabled exceptions are initiated immediately, independent of the processor IPL. Interrupts, however, are delayed until the processor IPL drops below the IPL of the requesting interrupt.
- Most exceptions cannot be disabled. However, if an exception-causing event occurs while that exception is disabled, no exception is initiated for that event, even when enabled subsequently. This includes overflow, which is the only exception whose occurrence is indicated by a condition code (V). If an interrupt condition occurs while that interrupt is disabled, or the processor is at the same or higher IPL, the condition eventually initiates an interrupt when the proper enabling conditions are met (if the condition is still present).
- The previous mode field in the PSL is always set to kernel on an interrupt, but on an exception it indicates the mode in which the exception occurred.
4. Software Interrupt Summary Register
The Software Interrupt Summary Register (SISR) is a privileged register which records pending software interrupts. The SISR contains 1s in the bit positions corresponding to levels on which software interrupts are pending. All such levels must be lower than the current processor IPL, or the processor would have taken the requested interrupt.
At bootstrap time, the contents of SISR are cleared.
The mechanism for accessing it is:
|
"MFPR SISR, dst" |
Reads the Software Interrupt Summary Register. |
|
"MTPR src, SISR" |
Loads it, but this is not the normal way of making software interrupt requests. It is useful for clearing the software interrupt system and for reloading it after a power failure, for example. |
5. Software Interrupt Request Register
The Software Interrupt Request Register (SIRR) is a write-only 4-bit privileged register used for making software interrupt requests.
Executing "MTPR src, SIRR" requests an interrupt at the level specified by src<3:0>. Once a software interrupt request is made, the corresponding bit in the SISR is set. The hardware then clears the bit in the SISR when the interrupt is taken. If src<3:0> is greater than the current IPL, the interrupt occurs before execution of the following instruction, If src<3:0> is less than or equal to the current IPL, the interrupt is deferred until the IPL is lowered to less than src<3:0>, with no higher interrupt level pending. The IPL is lowered by either REI or by "MTPR X, IPL". If src<3:0> is 0, no interrupt will occur or be requested.
No indication is given if there is already a request at the selected level, therefore, the service routine must not assume a one-to-one correspondence of interrupts generated and requests made.
6. Interrupt Priority Level Register
Writing to the IPLR with the MTPR instruction will load the processor priority field in the Processor Status Longword (PSL). That is, bits<20:16> of the PSL are loaded from IPLR<4:0>. Reading from IPLR with the MFPR instruction will read the processor priority field from the PSL. On writing IPLR, bits<31:5> are ignored, and on reading IPLR, bits <31:5> are returned zero.
At boot time, the IPL is initialized to 1F.
Interrupt service routines must follow the discipline of not lowering the IPL below their initial level. If they do, an interrupt at an intermediate level could cause the stack nesting to be improper. This would result in REI faulting. Actually, a service routine could lower the IPL if it ensured that no intermediate levels could interrupt. However, this would result in unreliable code.
7. SYSTEM CONTROL BLOCK (SCB)
The System Control Block is a page containing the vectors by which exceptions and interrupts are dispatched to the appropriate service routines.
The interrupt vectors that our simulator supports are as follows:
Interrupt vectors:
|
Vector's Address |
Interrupt Type |
Priority |
Extra Registers |
|
SCBB+0x18 |
Reserved Operand Fault |
31 |
None |
|
SCBB+0x28 |
Trace |
31 |
None |
|
SCBB+0x34 |
Arithmetic |
31 |
None |
|
SCBB+0x84 |
Software 1 |
1 |
SIRR, SISR |
|
SCBB+0x88 |
Software 2 |
2 |
SIRR, SISR |
|
SCBB+0x8C |
Software 3 |
3 |
SIRR, SISR |
|
SCBB+0x90 |
Software 4 |
4 |
SIRR, SISR |
|
SCBB+0x94 |
Software 5 |
5 |
SIRR, SISR |
|
SCBB+0x98 |
Software 6 |
6 |
SIRR, SISR |
|
SCBB+0x9C |
Software 7 |
7 |
SIRR, SISR |
|
SCBB+0xA0 |
Software 8 |
8 |
SIRR, SISR |
|
SCBB+0xA4 |
Software 9 |
9 |
SIRR, SISR |
|
SCBB+0xA8 |
Software 10 |
10 |
SIRR, SISR |
|
SCBB+0xAC |
Software 11 |
11 |
SIRR, SISR |
|
SCBB+0xB0 |
Software 12 |
12 |
SIRR, SISR |
|
SCBB+0xB4 |
Software 13 |
13 |
SIRR, SISR |
|
SCBB+0xB8 |
Software 14 |
14 |
SIRR, SISR |
|
SCBB+0xBC |
Software 15 |
15 |
SIRR, SISR |
|
SCBB+0xC0 |
Clock |
24 |
ICCS, NICR, ICR |
|
SCBB+0xF8 |
Terminal Input |
20 |
RXCS, RXDB |
|
SCBB+0xFC |
Terminal Output |
20 |
TXCS, TXDB |
8. System Control Block Base (SCBB)
The SCBB is a privileged register containing the physical address of the System Control Block
At boot time, the contents of SCBB are UNPREDICTABLE. SCBB must specify a valid address in physical memory or the processor operation is UNDEFINED.
9. Privileged Registers
VAX-11 contains several special registers.
Below is list of these registers, and some information about it.
|
Number |
Register Name |
I/O |
Description |
|
17 18 |
SCBB IPL |
RO RW |
System Control Block Base Interrupt Priority Level (Default = 0) |
|
20 21 |
SIRR SISR |
WO RW |
Software Interrupt Request Software Interrupt Summery |
|
24
25 26 |
ICCS
NICR ICR |
RW
WO RO |
Interval Clock Control/Status bit0=1 Run - Increase ICR every microsecond. bit4=1 Xfr - Load the ICR Clock from NICR bit5=1 Sgl Manual Incresing the clock. For use when bit0 is 0. bit6=1 Ie - Interrupt Enabled bit7=1 Int Next Interval Count Register Interval Count Register |
|
32
33 |
RXCS
RXDB |
RW
RO |
Console Receive Control/Status bit6=1 Ie - Interrupt Enabled bit7=1 Rdy - There is waiting key on the buffer Console Receive Data Buffer |
|
34
35 |
TXCS
TXDB |
RW
WO |
Console Transmit Control/Status bit6=1 Ie - Interrupt Enabled bit7=1 Rdy - Ready for sending new key Console Transmit Data Buffer |
9.1.Console Terminal Registers
The console terminal is accessed through four internal registers. Two are associated with receiving from the terminal and two with writing to the terminal. In each direction there is a control/status register and a data buffer register.
9.2.Interval Clock
The interval clock provides an
interrupt at IPL 24 at programmed intervals. The counter is incremented at 1
interval. The clock interface consists of three registers in
the privileged register space: the read-only interval count register, the
write-only next interval count register and the interval clock control/status
register.
9.2.1. Interval Count Register
The interval register is read-only register incremented once every microsecond. It is automatically loaded from NICR upon a carry out from bit 31 which also interrupts at IPL 24 if the interrupt is enabled.
9.2.2. Next Interval Count Register
The reload register is a write-only register that holds the value to be loaded into ICR when it overflows. The value is retains when ICR is loaded. NICR is capable of begin loaded regardless of the current values of ICS and ICCS.
9.2.3. Interval Clock Control/Status Register
The ICCS register contains control and status information for the interval clock.
Bit 31 - ERR
Whenever ICR overflows, if INT is already set, then ERR set. Thus. ERR indicates a missed clock tick. Attempts to set this bit via MTPR clears ERR.
Bit 30:8
Must Be Zero
Bit 7 - INT
Set by hardware every time ICR overflows. If IE is set, then an interrupt is also generated. Attempts to set this bit via MTPR clears INT, thereby re-enabling the clock tick interrupt (if IE is set).
Bit 6 - IE
When set, an interrupt request at IPL 24 is generated every time ICR overflows. (INT is set). When clear, no interrupt is requested. Similarly, if INT is already set and the software sets IE, an interrupt is generated.
Bit 5 - SGL
A write-only bit. If RUN is clear, each time this bit is set, ICR is incremented by one.
Bit 4 - XFR
A write-only bit. Each time this bit is set, NICR is transferred to ICR.
Bit 3:1
Must be zero.
Bit 0 - Run
When set, ICR increments each microsecond. When clear ICR doesn't increment automatically. At boot time, RUN is clears.