APPENDIX D ]
INTERRUPT HANDLING
Whenever the Interface Processor detects an event that may require attention from the IP controller, it records the nature of the event in the current IP processor data segment and e.mi ts a pulse on 1.ts interrupt line. There are several different types of events which may be sources of interrupts, and their occurrence and timing is not necessar ilv predictable. In this sense IP interrupts are similar to several I/O devices that are
Thus, the IP controller must resoond to an interrupt by "polling" the l?Qssible intet'rupt sources to 0etermine which event has actually occurred. It may do this by examining fielos of the IP processor
nata segment through the control windON (window 4). The IP controller (and related· hardware, such as latches and Intel 8259A intert'upt ~ontrollers) must also accommodate the ?Ossibility that the IP may detect a second event at any time, including while the IP controller is handling a previous interrupt. The IP responds to a.ll such events identically, notinq the event in the IP processor data segment and emitting an interrupt pulse. Again, this is analagous to tying mUltiple independent I/O devices to one interrupt line.
The principal requirement of IP interrupt handling hardware and software, then, is to field interrupt requests that may be
Fiqure
IP's interrupt request pulse. As soon as it is invoked, the interrupt handler masks further IP interrupt requests and resets the hardware latch. This insures that a secord request is unlikelY to be missed, and prevents the inter rupt handler from be inq reentered. Then the environment of the interrupted routine is saved and
