12.1 Why Interrupts and Exceptions Matter

Chapter 11 made software repeatedly read a status port until a device became ready. That polling loop is easy to understand, but the CPU spends time asking “ready yet?” even when nothing has changed. An interrupt is an event that asks the CPU to temporarily leave its current program, run an event-specific handler, and then resume the interrupted work.

Replace repeated checking with event-driven service

Imagine a keyboard that produces one byte every few thousand instructions. A tight polling loop notices a key quickly, but nearly all of its port reads return “not ready.” A slower polling loop saves CPU time but increases the delay before the key is serviced.

With interrupt-driven I/O, the CPU performs useful foreground work. When the interface has data, it asserts an interrupt request. The processor completes its current instruction, saves enough return state, transfers control to an interrupt service routine (ISR), services the device, restores the saved state, and resumes.

Interrupts remove repeated checks; they do not make service free. Entry, state saving, handler execution, and return all cost time. For very frequent events, interrupt overhead can dominate. The design question is therefore not “interrupts or polling are always better,” but which method meets latency and CPU-use requirements for the event rate.

Classify where the control transfer came from

Not every interrupt-like control transfer has the same source or timing:

• A hardware interrupt arrives from outside the CPU. On the 8086, INTR is a maskable request and NMI is a non-maskable request reserved for urgent events.

• A software interrupt is requested deliberately by an instruction such as INT 21H.

• An exception is generated by the CPU because of the instruction being executed, such as divide error.

An external device event is usually asynchronous: it is not caused by the current instruction, and the CPU accepts it at a defined instruction boundary. A divide error is synchronous: repeating the same instruction with the same operands reproduces the event at the same point.

The 8086 Interrupt Flag (IF) controls acceptance of maskable INTR. Clearing IF delays INTR; it does not block NMI, a software INT, or a processor-detected exception. This distinction matters when software enters a critical sequence and believes “interrupts are disabled.”

Section 12.1 established why control can leave the foreground program and which events can cause that transfer. Section 12.2 locates the exact handler address and traces the saved machine state.