the datapath/control split

Step back and look at the whole processor, and you see it cleanly divided in two. One half — the datapath — is the set of components that hold and transform data (registers, ALU, memories, muxes, the wires between them). The other half — the control — is the logic that, for each instruction, decides which operations the datapath should perform by setting its control signals. This division into 'the stuff that does work' and 'the stuff that decides what work to do' is the datapath/control split, and it is one of the most reusable ideas in all of computer design.

The split is powerful because the two halves can be designed, reasoned about, and changed almost independently. The datapath is mostly fixed plumbing: lay down good wires, a capable ALU, fast register access. The control is a table that says, per instruction, which switches to flip. Want to add a new instruction whose data movement already exists in the datapath? Often you just add a row to the control table — no rewiring. Want a faster datapath? You can reorganize the plumbing while keeping the same control intent. This is exactly the seam that the single-cycle, multi-cycle, and pipelined organizations all rearrange differently while keeping the same ISA.

And this seam is where the next big chapter begins. Pipelining keeps the datapath/control split but stretches the datapath into stages with registers between them, and replicates control so each stage carries its own signals. The honest framing: this textbook split is a teaching model. Real processors blur it — control may be distributed, predicted, or speculative, and datapaths are vastly wider — but every real design still rests on this same fundamental idea that 'where data flows' and 'what steers it' are separable concerns.