the control table
Once you accept that the control unit's job is 'opcode in, control signals out', the most natural way to specify it is a table: one row per instruction type, one column per control signal, and each cell filled with the 0 or 1 that signal should have. That grid is the control table — it is the complete recipe book that says, for every kind of instruction, exactly which datapath switches to throw.
Reading a row is reading an instruction's personality. An R-type row might read ALUSrc = 0, MemRead = 0, MemWrite = 0, MemToReg = 0, RegWrite = 1, Branch = 0. A load row reads ALUSrc = 1, MemRead = 1, MemWrite = 0, MemToReg = 1, RegWrite = 1, Branch = 0. A store row reads ALUSrc = 1, MemRead = 0, MemWrite = 1, RegWrite = 0, Branch = 0 (and MemToReg is a don't-care because nothing is written back). A branch row reads ALUSrc = 0, RegWrite = 0, MemRead = 0, MemWrite = 0, Branch = 1. The table IS the control unit's specification.
From this table the actual hardware is generated. Because each output column is just a boolean function of the opcode bits, you can implement it directly as logic gates (hardwired control), or compactly as a programmable logic array (PLA) or a small lookup memory whose contents are the table rows (closer to microprogrammed control). The honest note: don't-care entries (written 'X') are not laziness — they let the logic minimizer build smaller, faster gates, because the value genuinely doesn't matter for that instruction.
Store vs load share ALUSrc = 1 (both add base + offset) but differ in three columns: load has MemRead = 1, MemToReg = 1, RegWrite = 1; store has MemWrite = 1, RegWrite = 0. Two table rows, and the datapath behaves completely differently.
One row per instruction type, one column per signal — the table fully specifies the control unit.
A don't-care 'X' means the signal's value cannot affect a correct outcome for that instruction (e.g. MemToReg in a store, since nothing is written back). It is a deliberate optimization hint, not an oversight.