Manchester Baby: The Instructions Were in Memory

Find the largest number smaller than 12 that divides 12 exactly. A person can answer 6 without much ceremony. A machine with subtraction and a way to choose its next instruction can find it too, though it may take a rather scenic route.

The important part of Manchester’s first successful stored-program run wasn’t the usefulness of its factor. It was where the instructions lived. They occupied electronic memory alongside the numbers being processed.

A different computation could therefore begin with different stored contents. The arithmetic circuits didn’t need a new arrangement for every new sequence of operations. Instructions had become material that could be entered, retrieved and changed.

That sounds ordinary because it became a central habit of computing. In 1948 it was something a small experimental machine had to demonstrate while its memory was still an engineering question.

A program that tested a machine

The Small-Scale Experimental Machine, nicknamed the Baby, successfully ran its first program at Manchester on June 21, 1948. Tom Kilburn wrote the factor routine; Freddie Williams, Kilburn and Geoff Tootill were central to the machine and its development.¹

Williams and Kilburn’s September 1948 letter to Nature describes a deliberately small experimental computer built to test its storage principle. They report a factor search using repeated subtraction, with 17 instruction entries, and a later demanding run on $2^{18}$ taking 52 minutes.²

The university’s program history distinguishes that large test from the smaller first input. It also identifies the surviving notebook version as revised, rather than the exact lost initial listing.³

Those boundaries matter. This article explains the stored-program idea and an original small factor example. It doesn’t pretend to recover the precise June 21 input or reproduce a photograph of the original program.

Memory needs more than a number

Imagine an arithmetic machine that can subtract one number from another. The hardware knows how to perform that primitive operation, but an interesting calculation needs a sequence: take this value, subtract that one, inspect the result, repeat or stop.

An instruction supplies one step of that sequence. It describes an operation and, when needed, where the relevant value is stored. A control mechanism chooses which instruction to fetch next.

Put the instructions into the same kind of read-write store as the working numbers, and the machine can obtain both through its storage system. The programmer provides the arrangement. Hardware retrieves and obeys it.

This doesn’t mean a word of memory announces its own purpose. The bits become an instruction when the control mechanism fetches and decodes them as one. The same stored pattern can be treated as a number in an arithmetic operation.

A useful analogy is a numbered collection of pigeonholes, with the caveat that this machine reads them electronically. Some holes hold instructions; others hold inputs or intermediate values. Their meanings depend on how the program uses them. The pigeonholes haven’t acquired separate departments for arithmetic and management.

The 1997 conservation reference describes the original machine’s store as 32 lines of 32 bits. It also documents load-negative, subtract, store, conditional skip, jumps and stop. Its instruction names are convenient modern labels for the early operations, not a claim that users typed an assembly listing into a contemporary terminal.⁴

The available space was shared. Adding more instructions meant leaving less room for inputs and working state. “Just add another variable” had a physical consequence that an author could count without opening a memory profiler.

Adding with a subtractor

Our first original demonstration fits in a few symbolic instructions. Store −7 in line 20 and −5 in line 21. Leave line 22 available for the result.

Line 1: LDN 20    load the negative of the value in line 20
Line 2: SUB 21    subtract the value in line 21
Line 3: STO 22    store the accumulator in line 22
Line 4: STOP      halt

The accumulator is the machine’s working arithmetic value. Loading the negative of −7 gives 7. Subtracting −5 then gives $7 - (-5) = 12$. Storing it places 12 into the designated result line.

These symbolic operations follow the documented semantics, but this is an invented example. The checker encodes them as words and decodes them in a small modern model. No original hardware or historical simulator is being claimed.

The representation of the inputs is doing useful work. The hardware subtractor can contribute to addition when the stored operand is negative. More elaborate routines can arrange intermediate negations when positive inputs are required.

Original explanatory SVG, created in 2026. Symbolic memory locations belong to this article’s invented addition example; this is not a historical monitor image.

Keep the instruction words unchanged and replace line 21’s value with −9. The result becomes 16. That’s a data change: the same operations act on another input.

Replace the instruction in line 2 with a different operation and the sequence itself changes. That’s a program change. Both changes are stored contents, but they play different roles in the computation.

The stored-program idea makes that relationship concrete. It also makes it possible to damage a program by writing a result over an instruction. Shared storage provides flexibility without promising that every use of it is sensible.

Division without a divider

The factor routine gives the machine a larger task assembled from small operations. We can inspect the underlying arithmetic with the number 12.

Start with a trial divisor of 11, the largest possible proper factor. Repeatedly subtract it from a remainder initially set to 12:

12 − 11 = 1
 1 − 11 = −10

The remainder has crossed below zero without landing on zero, so 11 doesn’t divide 12 exactly. Reset the remainder to 12, reduce the trial divisor and try again.

The intermediate negative result is useful information. It tells the routine that another subtraction has gone too far. It isn’t the same as an exact division, which reaches zero.

Here is our complete small search:

Trial divisor	Remainders after successive subtractions	Result
11	1, −10	fails
10	2, −8	fails
9	3, −6	fails
8	4, −4	fails
7	5, −2	fails
6	6, 0	succeeds

Because the trials descend, the first exact divisor is the largest proper factor. The zero remainder supplies the divisibility test; the order of the search supplies the “largest” part.

Neither property can be removed casually. If the routine tested candidates in an arbitrary order, an early success wouldn’t establish the greatest factor. If it treated every nonpositive result as success, 11 would pass on its second subtraction. The branch conditions are part of the mathematics.

Original explanatory SVG, created in 2026. The small trace explains repeated subtraction and descending candidates; it is not the historical instruction listing.

Repetition needs a decision

A loop combines repetition with a condition for continuing. The historical machine’s negative test could skip an instruction, while a jump could change the flow of control.⁴ Small pieces like those let a program revisit its subtraction work or move on to another candidate.

Our teaching version expresses the algorithm more freely than the machine’s minimal instructions:

for candidate from n − 1 down to 1:
    remainder = n
    while remainder > 0:
        remainder = remainder − candidate
    if remainder == 0:
        return candidate

This is explanatory pseudocode, not Baby assembly. The equality and loop notation organize the reasoning for a reader; a real instruction sequence must construct its decisions from the available operations.

The initial value of the remainder is significant. Forget to reset it after a failed divisor, and the next test starts from somebody else’s partial calculation. The candidate value matters too. A zero divisor would never change the remainder, so the loop would fail to make progress.

For integers greater than 1, descending to candidate 1 guarantees eventual success: subtracting 1 repeatedly reaches zero. Our checker restricts inputs accordingly. It doesn’t quietly assign this routine a sensible answer for every possible signed machine word.

Slow can be a test objective

For a practical factor search, repeatedly trying large divisors this way is expensive. A mathematician can exploit the relationships between factor pairs; a more elaborate division routine can use fewer elementary steps.

The original letter explicitly says that the long routine was chosen to test the machine thoroughly, and that quicker routines were possible.² Its slowness therefore belongs to the experiment’s purpose.

The modern checker runs our small search across a range of integers and compares it with direct divisibility calculations. It also verifies $2^{18} = 262,144$ and the expected highest proper factor, 131,072. That comparison checks arithmetic; the modern execution time says nothing about the historic 52-minute run.

A program can be an instrument for testing the hardware that executes it. Repeated reads, writes, arithmetic and branches exercise behavior that a single stored number would leave untouched. A correct answer after a long run gives the builders something definite to compare, even though it cannot prove that every possible computation will succeed.

The result outgrew the problem

The largest proper factor is a deliberately narrow answer. The larger consequence was a machine that could retrieve its instructions from electronic memory and follow them through a changing sequence of operations.

I find the tiny addition example useful here. Four operations and two negative numbers are enough to distinguish an input change from an instruction change, expose the shared store and show why an explicit stop matters. The factor search then adds the conditional repetition that turns those elementary steps into a larger procedure.

The programmer’s task is already recognizable: arrange representations, preserve working values, choose the correct branches and establish when the work is finished.

The Baby made that arrangement executable. The memory held a plan as well as the numbers, and the machine could act on the plan.

Footnotes

1. University of Manchester, “The Manchester Small Scale Experimental Machine — The Baby”, read for the June 21 milestone and contributor context. ↩

2. F. C. Williams and T. Kilburn, “Electronic Digital Computers”, Nature 162, 487, September 25, 1948; complete letter preserved by Manchester. It states the experimental purpose, elementary operations and long factor test. Its word-length misprint is corrected in the university’s document guide. ↩ ↩²

3. University of Manchester, “The First Program”, distinguishing the smaller initial test, later large test and revised surviving notebook program. ↩

4. Chris P. Burton, Computer Conservation Society, SSEM Programmer’s Reference Manual, August 20, 1997, sections 2 and appendices 1–2. This is conservation documentation of the original minimal machine, not a 1948 published manual. The article’s programs and data are original teaching examples. ↩ ↩²