Microprocessors: The Evolution of Stored‑Program Computing

In the early days of computing, pioneers such as Alan Turing and John von Neumann recognized that a truly useful machine must do more than merely execute a list of commands—it must be able to store, retrieve, and modify data within the same memory pool. This insight led to the concept of the stored‑program computer.

Turing’s theoretical machine relied on a sequential‑access tape to hold both program instructions and data. A control circuit read the tape, performed operations, and rewrote results back to the tape or moved the tape to read new data. Modern systems replace that tape with random‑access memory (RAM), achieving the same purpose with far greater speed and flexibility.

A useful analogy comes from early automatic machine‑tool control. Open‑loop or numerical‑control (NC) systems guided a lathe or mill by following instructions encoded as holes in paper tape. The machine moved blindly, following the tape without awareness of the workpiece’s state.

Because the device was “blind” to its environment, it could not compensate for changes such as metal expansion or tool wear. The programmer also had to anticipate every possible instruction sequence, since the tape was read‑only and the machine had no internal memory to track its state.

Upgrading to a finite‑state machine (FSM) gave the tool a rudimentary memory: by feeding some data bits back into the address logic, the system could remember simple states like “coolant on” or “tool in‑position.” Yet this still fell short of true flexibility.

The breakthrough came with closed‑loop numerical control (CNC), where the program could write new data to writable memory (RAM). The control system could then record what it had done and adapt to sensor‑detected changes—much like a machinist jotting notes on a scratch‑pad for later reference.

Computer scientists have long dreamed of machines that can modify their own code, mirroring how the human brain strengthens synapses through experience. For such self‑modifying programs to be feasible, the executable code must reside in the same writable memory that stores data—a notion that remains at the frontier of research today.

Most software still follows fixed instruction sequences, altering only a separate data field. To truly support the stored‑program model, we need more than an FSM; we need a read/write memory, a data‑processing unit, and a sophisticated controller.

Read/write memory is readily provided by static or dynamic RAM chips—affordable and fast. Logical operations are handled by an Arithmetic Logic Unit (ALU), which can perform arithmetic and Boolean functions.

The Control Unit orchestrates data movement between memory, the ALU, and external devices. It uses tri‑state buffers to route data on buses and decoding logic to translate binary instruction codes into actions.

Example instructions might be: “Add the value at address 0010 to the value at address 1101,” or “Compute the parity of the byte at address 0111.” The mapping from binary codes to operations is arbitrary, much like the early ASCII standard, though instruction sets are typically manufacturer‑specific.

When read/write memory, an ALU, and a Control Unit are integrated—often on a single chip—they form a processor. A processor with minimal external memory is a microprocessor; coupled with bus‑control circuitry, it becomes a Central Processing Unit (CPU).

The CPU’s operation is encapsulated in the fetch/execute cycle. The program counter holds the address of the next instruction. The Control Unit reads that address into the memory address bus, retrieves the instruction from RAM, and stores it in a temporary register.

If the instruction requires operands, the Control Unit issues additional memory accesses, routing the fetched data to ALU registers. The ALU then performs the requested operation, placing the result in the accumulator. Finally, the program counter increments, and the cycle repeats.

 Microprocessor (CPU)

--------------------------------------
|       ** Program counter **        |
|  (increments address value sent to |
|  external memory chip(s) to fetch  |==========> Address bus
|  the next instruction)             |          (to RAM memory)
--------------------------------------
|        ** Control Unit **          |<=========> Control Bus
|  (decodes instructions read from   | (to all devices sharing
|  program in memory, enables flow   | address and/or data busses;
|  of data to and from ALU, internal | arbitrates all bus communi- 
|  registers, and external devices)  | cations)
-------------------------------------- 
| ** Arithmetic Logic Unit (ALU) **  |
|    (performs all mathematical      |
|     calculations and Boolean       |
|     functions)                     |
--------------------------------------
|          ** Registers **           |
|    (small read/write memories for  |<=========> Data Bus
|     holding instruction codes,     | (from RAM memory and other
|     error codes, ALU data, etc;    |  external devices)
|     includes the "accumulator")    |
--------------------------------------

Even the simplest operations require many micro‑steps. Complex arithmetic like exponentiation involves repeated iterations of basic functions. Consider the thousands of cycles a flight‑simulator’s graphics engine must perform to refresh the display every frame.

The sheer speed of the fetch/execute cycle makes this feasible. Some designs embed a small program—called microcode—in an internal ROM. Microcode handles the sub‑steps of complex operations, allowing the programmer to issue a single high‑level instruction instead of writing every detail.

In this way, a processor contains a processor: a program running inside a program that simplifies development while preserving performance.