Prologue

Why computers can be universal

This series starts from a single NAND gate and builds, in HDL, all the way to a computer that runs programs. But before that, answer the question in the title: why can a machine be universal? No parts are built here — only the three preconditions: what computation is (the Turing machine), what universal means (programs are data), and where instructions and data live (von Neumann vs Harvard).

0.1The Turing machine: three things

In 1936, Turing abstracted computation into a machine with only three things:

Thing	What it is
Tape	An endless sequence of cells, each holding one symbol; the head sits on one of them
Head	Reads the current symbol, may rewrite it, and moves one cell left or right
State table	A rule table: given the current state and the symbol read, it decides what to write, where to move, and which state comes next

So one step is five things: read the cell → look it up → write → move → change state.

Note: a Turing machine has no clock. A step is a logical unit, not a time unit — each step is assumed to be instantaneous.

0.2What "universal" means

An ordinary Turing machine does one thing: its state table is designed for one task. A different task needs a different machine.

A universal Turing machine is different: encode another machine's state table as a string on the tape, and it can read that description and simulate the machine.

This is the first rigorous definition of a general-purpose computer: not a machine that adds, but a machine that can read how someone else computes.

It also turns programs into data for the first time: a new algorithm needs a new tape, not new hardware.

But this is still theory: the universal machine is an interpreter, re-reading the description at every step, far too slow to be useful — and its tape is infinite.

Turning it into a machine you can build took another decade.

0.3The von Neumann architecture: from idea to blueprint

In June 1945 a document titled First Draft of a Report on the EDVAC circulated at the Moore School. It turned Turing's idea into something that could be built.

The report offered two things: five parts, and one rule.

The five parts	What they do
Arithmetic unit	Arithmetic and logic
Control unit	Fetch, decode, issue commands
Memory	Holds the program, and the data
Input / output	Exchange with the outside world

The rule: program and data live in the same memory, addressed the same way. The control unit can then fetch instructions the way it fetches data — that is the stored program.

Hence the loop: fetch → decode → execute. The control unit reads an instruction from memory, decodes it into control signals, and drives the arithmetic unit.

One cycle: how information moves

Press Next or Play to see what moves at each step, and along which path. Everything entering or leaving memory travels the system bus — address, data and control lines.

① FetchPC puts out the address; the instruction is read from instruction memory into IR.

A register is a small 16-bit box that plays two roles: it is a source of ALU operands and the place results land.So one operation needs only two operands — one in a register, one in memory. Early machines had a single such register, which is exactly why instructions could be short. Where the result goes is decided by the instruction: arithmetic writes back to the register, a store writes into memory.The instruction register (IR) holds the fetched instruction. If fetch and decode happen in different cycles, you need it.

It has three consequences:

No rewiring to change programs: load a new program instead — on ENIAC a new task meant days of rewiring.
Programs can modify programs: loaders, compilers and self-modifying code all rest on this.
Instructions need a fixed encoding: they share memory with data, so they must be distinguishable and readable by the fetch unit.

Stored program = programs become data.

The five EDVAC parts	Our machine
Arithmetic unit	ALU
Control unit	PC + decoder
Memory	ROM (instructions) + RAM (data)
Input / output	Input register / display

The name is a little misleading: the "von Neumann architecture" summarises discussions in the Moore School team (Eckert, Mauchly, von Neumann and others), but the report carried only von Neumann's name.

Timeline: the 1945 report → 1948, the Manchester Baby runs a stored program → 1949, EDSAC makes it practical.

0.4von Neumann vs Harvard

After the stored program, one question remains: do instructions and data share one memory? Both answers have names.

	von Neumann	Harvard
Memory	One, holding instructions and data together	Two, kept apart
Bus	One set	Two sets
Fetch and load	Cannot overlap — they share one path	Can overlap
Programs modifiable?	Yes, instructions are writable	Instructions are read-only; no self-modification
Typical	General CPUs, the instruction path of GPUs	Microcontrollers, DSPs, most embedded processors

The von Neumann bottleneck: fetch and load share one bus, so a faster CPU still queues. Harvard splits that path with two memories — the price is read-only instructions, so a program cannot change itself.

Which one is Hack? The Hack we build later is Harvard: ROM32K holds only instructions, RAM16K holds only data, and two 15-bit address lines run separately. That lets it fetch and access memory in the same cycle, at the cost of not modifying itself.

von Neumann: one memory for two things. Harvard: two memories, one thing each.