A-0: Let the Computer Arrange the Routines

A useful routine already exists. It computes the operation you need, has been tested, and sits in a library. Unfortunately, putting it into your new program still requires arranging its inputs, locating its instructions and ensuring that its branches land in the right places.

Reuse has saved you from inventing the arithmetic. It hasn’t saved you from bookkeeping.

Grace Hopper’s early compiling work asked the computer to do more of that construction. A request for suitable routines could become an arranged program, with the mechanical details handled by software before the calculation ran.

The interesting step is that instructions can themselves be processed as information. A machine needn’t only execute the final calculation. It can help prepare the instructions that will execute it.

A period meaning of “compiler”

Hopper’s 1955 account states that A-0 first ran in May 1952 and places it among the UNIVAC A-series compilers. That account distinguishes assembling library routines into a program for later execution from looking up routines as a computation proceeds.¹

Her 1952 paper, written at Remington Rand, describes a catalogue-driven compiling routine: select subroutines, arrange their addresses, supply arguments, direct exits and transfer results. It also describes metadata that identifies constants which must remain unchanged when a routine is positioned.²

Calling this a compiler respects the historical terminology. Its demonstrated library-assembly role is closer to parts of modern linking and loading than to a present-day compiler translating an entire general programming language. The mechanism deserves a clear description before anyone awards it an all-purpose “first compiler” trophy.

This article concentrates on that early assembly task. Hopper’s later A-2 performance and library claims are not automatically A-0 features. Nor does the article turn the 1952 discussion of additional symbolic-processing levels into a verified A-0 facility.¹²

A library is a promise with details

For an original teaching model, invent two library operations. COMBINE adds two inputs and a fixed adjustment of 4. SCALE multiplies an input by a factor.

Our requested calculation is:

$$\text{output} = (x + y + 4) \times \text{factor}$$

Choose x = 7, y = 5 and factor = 3. The intermediate value is 16; the final result is 48.

These names, the arithmetic and the notation are invented for this article. They are not A-0 call codes or source syntax. We use them because the arithmetic is small enough that the reader can spend attention on program construction.

The request might be expressed symbolically as:

Operation 1: COMBINE inputs x, y; produce temporary t
Operation 2: SCALE inputs t, factor; produce output

A builder needs to know more than the names. It needs the available routine bodies, their lengths, where they receive inputs, where results go and how execution continues. The library’s contract supplies those details.

If the routine’s first argument means one quantity and the caller supplies another, automatic assembly doesn’t rescue the calculation. A well-organized program can still perform exactly the wrong job. Reuse transfers responsibility for the routine’s mechanics; choosing and connecting it still matters.

Allocate the pieces

Suppose our invented COMBINE body occupies six instruction slots and SCALE occupies four. We choose code location 100 as the start of the assembled program.

The first body goes into locations 100 through 105. The second goes into 106 through 109. These ranges contain six and four slots respectively: counting inclusive endpoints requires adding one, a small detail with an unusually reliable ability to become a bug.

The builder records both placements. A reference to operation 2 can then resolve to its entry at 106. If the first body later grows by two slots, the builder can place the second at 108 instead and resolve references from the updated record.

This is an original zero-based address model. It is deliberately simpler than Hopper’s described routine organization, whose relative entrance convention begins at 001.² We aren’t claiming these locations are an original UNIVAC memory map.

Original explanatory SVG, created in 2026. COMBINE, SCALE, their sizes and addresses belong to the invented teaching model, not an A-0 listing.

Placement is a preparatory decision. The number x can change from 7 to 10 without changing the six-slot length of COMBINE. The calculation then gives $(10 + 5 + 4) \times 3 = 57$, while the code ranges stay the same.

That separation gives the assembled program a life beyond one set of input values. The builder constructs a sequence; the sequence acts on data when executed.

Moving a routine changes some numbers

Consider an instruction inside COMBINE that branches to its local offset 4. Local offset means a position relative to the beginning of this routine, rather than an already settled absolute location.

At base 100, the target is $100 + 4 = 104$. At base 200, it becomes 204. Moving the routine requires adjusting this reference so that it still lands on the same step within the body.

This adjustment is relocation. The invariant is the position within the routine: target minus base remains 4.

Our routine also contains the fixed arithmetic quantity 4. That value means four units, not the fourth instruction. Relocating the code to base 200 must not turn the adjustment into 204 units.

A third field could refer to an independently allocated data location numbered 4. If our model keeps the data layout unchanged while moving the code, that reference remains 4 as well. Its treatment differs from the local branch even though both began with the same small integer.

Field’s meaning	Stored model value	At code base 100	At code base 200
Local branch offset	4	target 104	target 204
Literal arithmetic quantity	4	quantity 4	quantity 4
External data location	4	location 4	location 4

A rule that adds the base to every number corrupts the literal and the data reference. A rule that adds nothing leaves the local branch pointing outside the placed routine.

The correct choice follows meaning. The library needs information about which fields represent local addresses, literal quantities or other references. The builder uses that information when it prepares the body.

Original explanatory SVG, created in 2026. The equal numerical values make the different reference roles visible; this is not a reconstruction of an A-0 record.

Connecting inputs and results

Our data locations are chosen separately from the code: location 30 contains x, 31 contains y, 32 is temporary t, 33 contains the factor, and 34 receives the output.

The library template’s abstract first input must resolve to the appropriate location for that use. For COMBINE, the first two input references become 30 and 31, and the result reference becomes 32. For SCALE, its input and factor references become 32 and 33, with output at 34.

The value 16 therefore travels through the shared temporary location. The second routine reads the first routine’s result.

Our checker implements a deliberately tiny teaching instruction vocabulary: load, add, add a literal, multiply, store, local jump and continue. The builder replaces abstract arguments with concrete data references and local jump offsets with placed targets. The resulting model then executes those resolved instructions.

At base 100, the local jump in the first body resolves to 104. At base 200, it resolves to 204. Both versions write 16 into t and 48 into output. The relocated program’s arithmetic hasn’t changed merely because its instructions occupy another region.

The checking environment is modern Python, not UNIVAC or recovered A-0 software. The test verifies the invented construction rule and its result. It doesn’t prove an original binary’s behavior, reproduce its tape format or measure historical speed.

Construction errors and problem errors

Automation is especially useful when a detail can be described precisely and repeated. The builder can compute a placement, resolve an argument slot and distinguish a marked constant without relying on someone to copy each reference by hand.

It also has to reject requests it cannot satisfy. In our model, an unknown library identifier raises an error rather than quietly selecting a similarly named routine. An incorrect number of supplied arguments is likewise a construction error. The builder should identify it before producing a program that reads whatever happens to be in an unrelated location.

These failures differ from a bad problem specification. Supply factor 30 when the intended factor is 3 and the arranged program can produce 480 perfectly faithfully. The library selection, relocation and argument connections may all be correct. The chosen input is wrong.

A serious test therefore asks two questions separately: did the builder construct the requested computation, and was that computation the intended one? Successful automation of the first question doesn’t dispose of the second.

The distinction keeps the accomplishment understandable. The computer can take over defined construction work without becoming an independent judge of what a scientific or business result ought to mean.

Reuse has a preparation cost

The routine library needs maintenance. Its entries must make dependable promises, and the construction tool must understand those promises. Extending the catalogue creates more combinations to check.

A general routine can also carry work unnecessary for one particular caller. In our example, COMBINE always applies its adjustment of 4 because that is the routine we defined. A user wanting plain addition must choose another entry or change the library’s contract. Renaming the requested operation doesn’t change its body.

I find this tradeoff more revealing than the terminology dispute. The programmer gains reusable pieces and a repeatable construction process. In exchange, those pieces need explicit interfaces and sufficiently clear descriptions that software can arrange them.

A-0 belongs to the early effort to make that arrangement executable. Its contribution is visible in the bookkeeping: the program’s instructions cease to be only something the computer obeys, and become something another program can help prepare.

Footnotes

1. Grace Murray Hopper, Automatic Coding for Digital Computers, talk of February 16, 1955, especially printed pages 3–4. Her account explicitly dates A-0’s first run to May 1952 and distinguishes compiling for later running from interpretation. Its A-2 discussion describes later work. ↩ ↩²

2. Grace Murray Hopper, “The Education of a Computer”, 1952 ACM meeting, pages 243–249, particularly the catalogue, relative routine organization and Type A services. The original symbolic operations and address model in this article illustrate the principles without claiming exact A-0 syntax or record formats. ↩ ↩² ↩³