I/o systems

 Interrupts

• Interrupts allow devices to notify the CPU when they have data to transfer or when an operation is complete, allowing the CPU to perform other duties when no I/O transfers need its immediate attention.
• The CPU has an interrupt-request line that is sensed after every instruction.
• A device's controller raises an interrupt by asserting a signal on the interrupt request line.
• The CPU then performs a state save, and transfers control to the interrupt handler routine at a fixed address in memory. ( The CPU catches the interrupt and dispatches the interrupt handler. )
• The interrupt handler determines the cause of the interrupt, performs the necessary processing, performs a state restore, and executes a return from interrupt instruction to return control to the CPU. ( The interrupt handler clears the interrupt by servicing the device. )
• ( Note that the state restored does not need to be the same state as the one that was saved when the interrupt went off. See below for an example involving time-slicing. )

The above description is adequate for simple interrupt-driven I/O, but there are three needs in modern computing which complicate the picture:

• The above description is adequate for simple interrupt-driven I/O, but there are three needs in modern computing which complicate the picture:
• The need to defer interrupt handling during critical processing,
• The need to determine which interrupt handler to invoke, without having to poll all devices to see which one needs attention, and
• The need for multi-level interrupts, so the system can differentiate between high- and low-priority interrupts for proper response.
• These issues are handled in modern computer architectures with interrupt-controller hardware.
• Most CPUs now have two interrupt-request lines: One that is non-maskable for critical error conditions and one that is maskable, that the CPU can temporarily ignore during critical processing.
• The interrupt mechanism accepts an address, which is usually one of a small set of numbers for an offset into a table called the interrupt vector. This table ( usually located at physical address zero ? ) holds the addresses of routines prepared to process specific interrupts.
• The number of possible interrupt handlers still exceeds the range of defined interrupt numbers, so multiple handlers can be interrupt chained. Effectively the addresses held in the interrupt vectors are the head pointers for linked-lists of interrupt handlers.
• Figure 13.4 shows the Intel Pentium interrupt vector. Interrupts 0 to 31 are non-maskable and reserved for serious hardware and other errors. Maskable interrupts, including normal device I/O interrupts begin at interrupt 32.
• Modern interrupt hardware also supports interrupt priority levels, allowing systems to mask off only lower-priority interrupts while servicing a high-priority interrupt, or conversely to allow a high-priority signal to interrupt the processing of a low-priority one.