In the previous chapter, we studied buses as the shared pathways that let the CPU, memory, and other components communicate with each other. One of the most important groups of components that rely on these buses are input-output devices, commonly shortened to I/O devices, such as keyboards, monitors, storage drives, and network adapters. Input-output organization is the branch of Computer Organization that explains exactly how the CPU communicates with these external devices.
Unlike main memory, which is generally fast and predictable, I/O devices vary enormously in speed and behavior. A keyboard produces data only occasionally, whenever a key is pressed, while a storage drive might need to transfer a large block of data all at once. Because of this wide variation, computer systems have developed several different strategies for managing communication between the CPU and I/O devices, each suited to different situations.
In this tutorial, you will learn about the three major approaches to input-output organization: programmed I/O, interrupt-driven I/O, and Direct Memory Access, commonly abbreviated as DMA, along with the specific strengths and trade-offs each approach offers.
The CPU operates at extremely high speeds, performing billions of instruction cycles every second, while many I/O devices operate at dramatically slower speeds by comparison. A keyboard, for example, might go for several seconds or longer between individual key presses, an eternity from the CPU's perspective. If the CPU handled every I/O interaction the exact same way it handles memory access, enormous amounts of processing time would be wasted simply waiting around for slow devices to respond.
This mismatch in speed is exactly why several distinct I/O organization strategies exist, each offering a different way of balancing CPU involvement against overall system efficiency.
In programmed I/O, the CPU is directly responsible for managing every single step of a data transfer to or from an I/O device. The CPU repeatedly checks, or polls, the status of the device to determine whether it is ready to send or receive data, and only proceeds with the actual transfer once the device signals that it is ready.
CS Engineering Gyan's simulated CPU wants to read a value typed on the keyboard Step 1: CPU checks the keyboard's status register Step 2: Status shows "not ready", meaning no key has been pressed yet Step 3: CPU checks again... and again... repeatedly, in a tight loop, until the status finally changes Step 4: Status changes to "ready", indicating a key has been pressed Step 5: CPU reads the character value from the keyboard's data register
The biggest drawback of programmed I/O is immediately visible in this example: the CPU wastes a significant amount of processing time repeatedly checking the device's status, unable to do any other useful work while it waits. This constant checking is often referred to as busy waiting.
Interrupt-driven I/O solves the busy waiting problem of programmed I/O by allowing the CPU to continue working on other tasks entirely, rather than repeatedly checking a device's status. Instead, the I/O device itself sends an interrupt signal to the CPU whenever it becomes ready, prompting the CPU to briefly pause its current work and handle the I/O operation at that exact moment.
CPU is currently busy processing an unrelated calculation Step 1: CPU continues working normally, without checking the keyboard at all Step 2: A key is pressed on the keyboard Step 3: Keyboard sends an interrupt signal to the CPU Step 4: CPU pauses its current calculation, saving its progress Step 5: CPU executes a special interrupt handling routine, reading the character value from the keyboard Step 6: CPU resumes its original calculation exactly where it left off
This approach directly connects back to the interrupt check we briefly introduced during the instruction cycle chapter, since interrupt-driven I/O is precisely the kind of event that interrupt check is designed to detect and respond to between instruction cycles.
| Characteristic | Programmed I/O | Interrupt-Driven I/O |
|---|---|---|
| CPU Involvement | Continuously checks device status | Only responds when notified by an interrupt |
| Wasted CPU Time | High, due to repeated status checking | Low, since the CPU can work on other tasks meanwhile |
| Suitability | Simple systems or predictable, fast devices | Systems needing efficient use of CPU time |
Even interrupt-driven I/O still requires the CPU to personally handle the actual transfer of every single piece of data between an I/O device and memory. For large data transfers, such as reading a large file from a storage drive, this can still consume a significant amount of CPU time, even if the CPU is no longer wasting time on busy waiting. Direct Memory Access, commonly abbreviated as DMA, solves this remaining problem by allowing data to be transferred directly between an I/O device and main memory, almost entirely bypassing the CPU.
A DMA controller is a specialized piece of hardware responsible for managing these direct transfers. The CPU simply provides the DMA controller with the necessary details at the start, such as the memory address to use and the amount of data to transfer, and then the DMA controller handles the entire transfer independently, only notifying the CPU with an interrupt once the transfer is fully complete.
CS Engineering Gyan's simulated system needs to load a large video file from a storage drive into memory Step 1: CPU instructs the DMA controller: transfer this file from the storage drive, into memory starting at address 9000 Step 2: CPU moves on to perform other, unrelated work Step 3: DMA controller manages the entire transfer directly between the storage drive and memory, without involving the CPU at all during the actual transfer Step 4: Once the transfer is fully complete, the DMA controller sends an interrupt to notify the CPU Step 5: CPU briefly pauses to acknowledge the completed transfer, then continues as needed
This approach is dramatically more efficient for large data transfers, since the CPU is only involved briefly at the very beginning and very end of the process, remaining completely free to perform other work throughout the actual data transfer itself.
| Approach | CPU Role During Transfer | Best Suited For |
|---|---|---|
| Programmed I/O | Actively checks status and manages every step | Simple systems with minimal performance requirements |
| Interrupt-Driven I/O | Handles other tasks, responds only when interrupted | Devices producing data occasionally or unpredictably |
| DMA | Minimal involvement, only at start and end of transfer | Large, high-volume data transfers |
I/O devices generally fall into a few broad categories based on how they interact with the computer system: input devices like keyboards and mice, which send data into the system; output devices like monitors and printers, which receive data from the system to display or produce results; and storage devices like hard drives and solid-state drives, which can both send and receive large amounts of data over time.
CS Engineering Gyan's simulated system includes: Input device: keyboard, sending typed characters into the system Output device: monitor, receiving video frame data to display on screen Storage device: solid-state drive, both sending saved files into memory and receiving new files to be saved
Regardless of the specific device category, all of these devices ultimately rely on one of the three I/O organization strategies covered in this chapter to actually exchange data with the CPU and main memory.
No single I/O organization strategy is universally the best choice for every situation. Programmed I/O remains useful in very simple systems where minimal hardware complexity is more important than raw performance. Interrupt-driven I/O offers a strong balance for devices that produce data unpredictably, such as keyboards and mice. DMA becomes essential for high-volume transfers, such as loading large files or streaming video data, where involving the CPU directly in every single data movement would create a significant performance bottleneck.
| Advantages | Limitations |
|---|---|
| Multiple strategies allow systems to match I/O handling to each device's specific needs. | Programmed I/O wastes significant CPU time through busy waiting. |
| Interrupt-driven I/O frees the CPU to perform other work between I/O events. | Interrupt handling still introduces some overhead each time an interrupt occurs. |
| DMA dramatically reduces CPU involvement during large data transfers. | DMA requires additional, specialized hardware in the form of a DMA controller. |
| Mistake | Correct Practice |
|---|---|
| Assuming interrupt-driven I/O eliminates all CPU involvement in a transfer. | Remember that the CPU still personally handles the actual data transfer in interrupt-driven I/O, just not the constant status checking. |
| Confusing DMA with interrupt-driven I/O. | Remember that DMA transfers data directly between the device and memory, largely bypassing the CPU entirely during the transfer itself. |
| Believing programmed I/O is always a poor choice in every situation. | Understand that programmed I/O can still be reasonable for very simple systems with minimal performance demands. |
| Forgetting that a DMA controller is a separate piece of hardware, not just a CPU feature. | Remember that DMA relies on a dedicated DMA controller to manage transfers independently of the CPU. |
Input-output organization explains how the CPU manages communication with external devices that vary enormously in speed and behavior compared to fast, predictable main memory. Programmed I/O keeps the CPU directly and constantly involved through busy waiting, interrupt-driven I/O frees the CPU to perform other work until the device signals readiness, and DMA goes a step further by allowing large transfers to happen directly between a device and memory, almost entirely bypassing the CPU.
Each of these three strategies represents a different trade-off between hardware simplicity and overall system efficiency, and real computer systems often use a combination of all three, chosen based on the specific characteristics of each individual I/O device involved. Understanding these approaches ties directly back to earlier chapters on the instruction cycle and buses, since I/O organization is really just those same underlying concepts applied specifically to external devices.
With input-output organization covered, you are now ready to explore interrupts in much greater depth, examining hardware and software interrupts, interrupt handling procedures, and how interrupt priorities are managed when multiple interrupt signals occur close together.