I/O, Interrupts and DMA

Devices are slow and varied, so the CPU talks to them through I/O interfaces (controllers) that have data, status and control registers. There are two ways to address those registers:

• Memory-mapped I/O: device registers occupy memory addresses; ordinary load and store instructions access them.
• Isolated (port-mapped) I/O: a separate I/O address space with special instructions (IN, OUT on x86).

The question is then how the CPU knows when a device is ready. There are three methods.

Programmed I/O (polling)

The CPU repeatedly reads the device's status register until it shows "ready", then transfers one word. Simple, but the CPU does nothing useful while waiting (busy waiting), and slow devices waste enormous numbers of cycles.

Interrupt-driven I/O

The device signals the CPU with an interrupt when it is ready. The CPU then:

1. finishes the current instruction,
2. saves the PC and status (and disables or masks interrupts as needed),
3. finds the interrupt service routine (ISR) and runs it,
4. restores the saved state and returns to the interrupted program.

Finding the ISR:

• Vectored interrupts: the device supplies a number (vector) that indexes a table of ISR addresses.
• Non-vectored: the CPU jumps to a fixed address and polls the devices in software to find which one interrupted.

When several devices interrupt at once, priority decides:

• Daisy chaining: the interrupt-acknowledge signal passes from device to device in a chain; the first requesting device in the chain takes it. Priority is fixed by position, and devices at the end can starve.
• Priority interrupt controller: a dedicated chip ranks the request lines and gives the highest-priority vector.
• Nested interrupts: a higher-priority interrupt may interrupt a lower-priority ISR.

Interrupts free the CPU while the device works, but every transfer still costs an interrupt (saving and restoring state, running the ISR). For fast devices transferring many words, that overhead is too high.

Direct memory access (DMA)

A DMA controller moves a whole block between the device and memory without the CPU. The CPU only:

1. programs the controller (memory address, word count, direction),
2. goes on with other work,
3. receives one interrupt when the whole block is done.

The DMA controller needs the memory bus, which it takes from the CPU:

How much CPU time does each method cost?

Consider a device that transfers 1 MB (2²⁰ bytes) per second to a 1 GHz CPU:

cpu_hz, rate = 1e9, 2 ** 20                     # bytes per second

interrupt_cycles = 200                           # one interrupt per byte
print(f"interrupt per byte: {rate * interrupt_cycles / cpu_hz:.2%} of the CPU")

block, dma_overhead = 4 * 1024, 1000 + 500       # set-up + completion interrupt per block
blocks = rate / block
print(f"DMA with 4 KB blocks: {blocks:.0f} blocks/s, {blocks * dma_overhead / cpu_hz:.4%} of the CPU")

steal_time, byte_interval = 50e-9, 2e-6          # cycle stealing: 50 ns per byte, a byte every 2 us
print(f"cycle stealing: CPU blocked {steal_time / byte_interval:.1%} of the time")

interrupt per byte: 20.97% of the CPU
DMA with 4 KB blocks: 256 blocks/s, 0.0384% of the CPU
cycle stealing: CPU blocked 2.5% of the time

A fifth of the CPU goes to handling one interrupt per byte, but DMA costs only a few hundredths of a percent, because the overhead is paid once per 4 KB block.

The general recipe:

• Fraction of CPU time = (overhead per event × events per second) / (CPU cycles per second).
• For cycle stealing, the fraction of time the CPU is blocked = (time DMA holds the bus per word) / (time between words).
• For burst mode, the CPU is blocked for the whole transfer time of the block (block size / transfer rate).

Practice questions