Hardware Interrupt Generation and Acknowledgement - Points Raised

The preceeding pages raise a few points that need addressing here.

• First - the kind of I/O referred to in our keyboard example using interrupts to inform the CPU of the need for service, is called interrupt-driven I/O. The alternative, called polled I/O, has the CPU executing a continuous loop probing the device to determine whether it needs service.

Polled I/O tends not to be used much these days except in application-specific situations because it means that the CPU spends a lot of time (and in the worst implementation - all of its time and is stuck) awaiting notification from a device that it needs service.

• Note that the ISR uses the stack of the interrupted process. Another possibility would be to use a separate stack for ISR routines only.
• Why is there a PS in the interrupt vector table entry?

Because one field in the PS defines whether (or which level of) interrupts are allowed. Usually ISRs run with interrupts disabled so as not to be interrupted while doing their job. Think of the implications of allowing interrupts to interrupt the servicing of other interrupts. By placing a PS in the table with its bits set to turn off interrupts effectively turns off interrupts until the ISR is done. In XINU there is also a second reason to have a PS loaded on interrupt, but we will cover that in a later chapter (look ahead if you are keen!).