Interrupt Processing

There are two mechanisms for interrupting an instruction stream to start executing the appropriate MCP routines; Interrupt Procedures and Hardware Call Procedures.

Interrupt Procedure

An Interrupt Procedure is executed as a response to certain Instruction Interrupts or Condition Interrupts to transfer control of the processor to the MCP kernel.

The Instructions that may cause an Interrupt Procedure to be executed are Kernel Request, Lock, failed Branch Reinstate Virtual and failed Hardware Call Procedure.

The Conditions that may cause an Interrupt Procedure to be executed are: Alarm Time Reached, Task Time Limit Reached, Real-Time I/O completed, Normal I/O completed and External Interrupt detected.

All the Condition Interrupts are maskable. This means that for each individual condition, there exists a mask bit that works as follows. A Condition Interrupt will cause the Interrupt Procedure to be executed if and only if its corresponding mask bit is set. Note that Instruction Interrupts are non-maskable.

The Condition Interrupt(s) will be reset during the execution of the Interrupt Procedure only if the corresponding mask bit is set.

The Interrupts (Instruction or Condition) are gathered in a two digit field as described in the following table:

Condition Digit Bit Information
Reserved MSD=X 3 Must Be Zero
Instruction 2 Instruction-related Interrupt
External 1 Overtemp, IPC and MP
Task Timer 0 Task Timer MSD = 0
Reserved MSD=Y 3 Must Be Zero
Real Time I/O 2 I/O Complete, Real-Time Device
Alarm Timer 1 Alarm Timer reached.
Normal I/O 0 I/O Complete, Normal Device

The Interrupt Mask doesn't allow the Instruction Interrupt to be masked.

The interrupts are reported to the MCP Kernel (Task #1) via the Interrupt Descriptor which is located in the Kernel Data Area (Task #1, Environment #0). The Interrupt Descriptor format is C1000XY01) where XY is the two digit interrupt field as described above. Except for the Instruction Interrupt bit, all the bits in XY are the result of the logical AND of the pending interrupt conditions and the associated interrupt mask bits.

The External Interrupt, MSD bit 1 in the Interrupt Descriptor is used to report up to three different conditions, which can be active simulataneously. They are Overtemperature, Interprocessor Communicate, and Maintenance Processor (MP). To differentiate between the three possible conditions, and External Interrupt Descriptor is written in the Kernel Data Area along with the reporting of the External Interrupt bit in the Interrupt Descriptor.

The External Interrupt Descriptor is a two digit field which is described as follows:

Condition Digit Bit
Reserved MSD 3
Reserved 2
Reserved 1
Reserved 0
Reserved LSD 3
MP Interrupt 2
IPC Interrupt 1
Overtemp 0

Note that there is only one global mask bit for up to three External Interrupts.

The IPC interrupt is set only if the External mask bit is set at the time the IPC signal is active. The IPC interrupt is not set or saved at any other time.

After detection of an Overtemperature condition, a processor-dependent time-delay occurs before the system is powered off.

If any Condition Interrupt is active, the Interrupt Procedure is initiated at the end of the current instruction whereas if an Instruction Interrupt is active, the Interrupt Procedure is initiated immediately.

The Instruction Interrupt bit, digit X bit 2 in the Interrupt Descriptor, is used to report an interrupt that can be cause by up to four different instructions. They are Kernel Request, Lock, failed Branch Reinstate Virtual and failed hcl_procedure. In the case of the Lock instruction, up to four different variants can cause an interrupt.

If an Instruction Interrupt is active, an Instruction Interrupt Cause Descriptor is written in the Kernel Data Area along with the reporting of the Instruction bit in the Interrupt Descriptor.

The Instruction Interrupt Cause Descriptor is an eight digit field which format is C1000XY002). The XY field is described as follows:

XY Value Cause
08-FF Reserved
07 Failed Branch Reinstate Virtual
06 Executed Kernel Request instruction
05 Failed Hardware Call Procedure
04 Released Event
03 Released Lock
02 Failed Event
01 Failed Lock
00 Reserved

In the case of a Lock or Kernel Request instruction, an additional information is provided by another descriptor: the Instruction Interrupt Cause Extension Descriptor. For the Lock instruction this descriptor carries the Reinstate List Entry base pointer of a task linked to the task that is executing the Lock instruction. The format of the descriptor is C7AAAAAA. For the Kernel Request instruction, the descriptor carries the kernel request code provided by the BF field of the instruction. The format of the descriptor is C1000BF0.

The state of the task is saved by the Interrupt Procedure. It is stored in the Interrupt Frame field of the Reinstate List entry for the task that was running on the processor.

The instruction address of the first instruction to be executed when the interrupted task is reinstated is included in the state. That field may either be the address of the interrupted instruction or the address of the next instruction, which can be either in the current Environment or another Environment.

The current instruction address is reported in the following cases:

  1. Failed BRV

The next instruction address is reported in the following cases:

  1. All Condition Interrupts

An interrupt caused by a failed Hardware Call Procedure may store inconsistent values depending upon the cause of the failure.

Hardware Call Procedure

A Hardware Call procedure is executed as a response to certain processor detected faults. A Hardware Call Procedure changes the system environment and transfers control to a software error handling routine.

The Hardware Call Procedure stores the state of the stack in a Hardware Call Stack Frame on the stack that is associated with the called routine. See Compatibility Notes A.27.

The instruction address of the failing instruction is included in the state that is stored as a result of the following faults:

  • Address Error
  • Invalid Instruction
  • Invalid Arithmetic Data
  • Invalid Alter Table Entry
  • Accumulator Trap
  • Uncorrectable Memory Errors
  • Instruction Timeout
  • Certain Memory Area Faults.

The instruction address of the next instruction to be executed (unless one of the faults that require that the address of the failing instruction be stored is also present) is included in the state that is stored as a result of the following faults:

  • Trace
  • Programatic Soft Fault
  • other Memory Area Faults

If an interrupt condition and a hardware call condition exist at the same time, the following algorithm is applied:

  1. If an Instruction Interrupt condition and an instruction-related hardware call error condition (Invalid Arithmetic Data, Instruction Timeout, Address Error, Uncorrectable Memory Parity Error, Invalid Instruction) occur at the same time, then the Instruction Interrupt condition is ignored as the instruction did not actually execute correctly.
  2. If the Instruction Interrupt condition is a failed lock and the only Hardware Call condition is a Trace Fault, then the Trace Fault condition is ignored.
  3. If any other fault conditions still remain, then a Hardware Call Procedure is performed.
  4. If any Instruction Interrupt conditions remain or any maskable interrupt conditions are enabled by the Interrupt Mask (which may have just been loaded by a Hardware Call Procedure), then an Interrupt Procedure is performed.

An attempt to execute a Hardware Call Procedure while in KERNEL Mode will cause the processor in KERNEL mode to halt, after storing the fault indicators in the R/D Storage Area field in the Kernel Data Area.

When the processor halts, a SNAP picture is taken (if enabled). The processor cannot continue from this point since the error that caused the halt is in a non-recovarable portion of the system. The error must be cured and the system restarted manually. Note that since this processor halted while owning the lock required for access to KERNEL mode, all other processors on the system will, in a very short time, become dormant waiting for Kernel Mode access.

1) This is a 7SN pointer relative to the code base, base #1 and can be used directly to index a branch to the correct interrupt handling routine
2) Another 7SN code base relative pointer
procedures/interrupt_processing.txt · Last modified: 2009/05/06 06:37 by scott
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki