Where we are: the wires nobody draws
The previous guide made the honest case that I/O — not the CPU — is often the real bottleneck, and gave you three rulers to judge any device: throughput, latency, and dependability. But it left one question hanging. The processor sits on one chip; the disk, the network card, and the keyboard sit somewhere else entirely. Bits do not teleport. Something physical must carry them, and that something has its own throughput and latency that quietly cap what every device behind it can ever achieve. This guide is about those wires and the rules they obey.
Picture the whole machine as a building. The CPU and main DRAM share a fast private hallway near the centre. Everything else — drives, network adapters, the GPU — lives in rooms further out, connected by corridors of varying width and length. A bus or interconnect is one of those corridors: a bundle of wires plus a protocol that says whose turn it is to speak, how an address is sent, and how data and acknowledgements come back. The art of system design is matching each corridor's width and length to the traffic that flows through it.
The shared bus: one corridor, everyone takes turns
The oldest design is the shared bus: a single set of wires that many devices all tap onto in parallel, like one telephone party line. It is wonderfully cheap — adding a new device just means clipping it onto the existing wires — and it makes broadcast natural, which is exactly why the snooping cache-coherence schemes from the multiprocessor rung leaned on a shared bus so they could overhear every transaction. A bus usually carries three logical groups of wires: address lines saying where, data lines carrying what, and control lines carrying when and what kind (read or write).
But a party line has a fatal weakness: only one speaker at a time, or the messages collide into noise. So a shared bus needs an arbiter — a referee that grants the wires to exactly one device per turn — and every other device waits. Worse, the physics fights you. A long set of wires with many devices hanging off it acts like a heavily loaded antenna: signals reflect, skew, and smear, so the longer and busier the bus, the lower the clock rate it can safely run. This is why you cannot simply widen and speed up a shared bus forever; bandwidth and clean signalling pull in opposite directions.
Point-to-point and PCIe: many private corridors
The modern answer is to abandon the shared party line for point-to-point links: each device gets its own dedicated wires straight to a central switch, so two devices can talk at the same time without an arbiter rationing one corridor. PCI Express, or PCIe, is the dominant example inside today's computers. Crucially, a PCIe link is not one fat parallel bus but a set of narrow lanes, each lane being a single pair of wires that sends bits one after another (serially). A slot is described as x1, x4, x8, or x16 — the number of lanes — and the link's bandwidth scales with that count.
This serial-and-narrow choice surprises beginners, because intuition says a wide parallel bus should beat a thin serial one. The honest reason serial won is the physics of section two. In a wide parallel bus, the bits of one word race down many wires that must all arrive at the same instant; at high speed they drift out of step (skew), and that limits the clock. A single serial lane has nothing to stay in step with, so it can be clocked far faster, and you recover width by simply running many independent lanes in parallel. Fewer wires, each going much faster, beats many wires forced to march in lockstep.
How the CPU actually talks to a device
Wires carry bits, but how does a program address a disk? It cannot — a CPU's instruction set only knows how to load from and store to memory addresses. The trick is to make the device pretend to be memory. Every real device is fronted by a device controller: a little chip on the device side that exposes a handful of registers — a command register, a status register, a data register. With memory-mapped I/O, those registers are wired to live at specific physical addresses. Storing to address 0x1F0 might mean 'controller, here is a byte to write'; loading from 0x1F7 might mean 'controller, what is your status?'.
This is beautifully economical: no new instructions are needed at all. The same load and store you learned in the ISA rung, the same address translation hardware, reach the controller. The operating system simply marks those addresses as off-limits to user programs — a protection matter — so only the kernel's driver can poke them. The CPU writes a command into the command register, and the controller does the slow physical work of moving the head, charging the flash, or driving the network wire.
Memory-mapped I/O: the controller's registers ARE addresses
physical address meaning when accessed
---------------- ---------------------------------------
0x1F0 data store -> byte to send; load -> byte read
0x1F2 count how many blocks to transfer
0x1F3..6 sector which disk block (the address on disk)
0x1F7 cmd/status store -> issue command;
load -> bit7 BUSY, bit3 DRQ, bit0 ERR
driver: store sector + count, store READ into 0x1F7,
then watch the status register for 'ready'...
(HOW it watches is the next guide: poll? interrupt? DMA?)Notice the cliffhanger in that last line. The CPU has issued the command; now it must find out when the device is done, because a disk read takes millions of CPU cycles. Spinning in a loop reading the status register, firing off an interrupt when finished, or handing the whole transfer to a DMA engine are the three strategies — and they are exactly what the next guide is about. Buses and memory-mapped registers are the stage; polling, interrupts, and DMA are the play performed on it.
Honest caveats and where this leads
A few truths worth holding onto. First, a faster device behind a slow interconnect is wasted money — the corridor caps the room. An NVMe SSD on a single PCIe lane will badly underperform the same drive on four lanes, with no other change. Second, bandwidth and latency are independent virtues: PCIe gives you enormous throughput, but each individual transaction still pays a real round-trip delay, which is why bundling many small requests into one big transfer almost always wins. Third, a shared corridor under contention quietly inflates tail latency — most requests are fast, but the unlucky ones that arrive while the bus is busy wait far longer than average, and in a datacenter those slow tails are what users feel.
The bigger picture is that the same idea recurs at every scale. Inside the chip, cores reach memory through memory channels and a memory controller; across a board, devices reach each other through PCIe; across a building, machines reach each other through a datacenter network and a top-of-rack switch. At each level the question is identical — shared medium or point-to-point? how do we arbitrate? what is the throughput and the latency? — and the trend is everywhere the same: away from one shared bus, toward many switched point-to-point links. You have now seen the wires. The next guide brings them to life by answering how the CPU and a device coordinate without the CPU wasting its life waiting.