Stan Poley and SOAP: Symbolic Assembly for the IBM 650
Stan Poley's SOAP assembler let IBM 650 programmers use symbolic addresses while the software assigned drum locations intended to reduce rotational delays, combining readability with machine-specific optimization.
The IBM 650 made programming a timing problem as well as a coding problem
IBM announced the 650 in 1953, and the machine became one of the most widely deployed computers of its generation. Its main memory was a rotating magnetic drum. IBM’s history explains that a requested word could be accessed only when its physical position on the drum passed under the read/write heads.[1]
That architecture meant instruction placement affected performance dramatically. A programmer could write the correct operations and still waste much of the machine’s time waiting for the drum to rotate to the next instruction.
Memory addresses encoded physical timing
On random-access semiconductor memory, two nearby instruction addresses may have similar access cost. On the 650’s drum, the best address depended on where the drum would be when the previous instruction finished.
Manual optimum programming was difficult and error-prone
The 650 used two-address instructions, including an address that could identify the next instruction. Skilled programmers learned to place instructions around the drum so that the next one would arrive under a read head at approximately the right moment.
Columbia University’s IBM 650 history describes this optimization problem and explains that SOAP—the Symbolic Optimal Assembly Program—could choose a drum location automatically when a programmer left the location blank.[2]
Optimization and assembly were combined
A conventional assembler replaces symbolic notation with machine addresses. SOAP also tried to decide where instructions should live so that the assembled program reduced rotational waiting.
Stan Poley developed SOAP inside IBM’s early software culture
Historical accounts of IBM 650 software identify Stan Poley as a central developer of SOAP in 1955. Donald Knuth’s survey of early programming languages cites Stanley Poley and Grace Mitchell’s 1955 IBM programming bulletin on Symbolic Optimum Assembly Programming.[5]
The software let programmers use symbolic operation codes and symbolic addresses rather than requiring every final location to be calculated manually before the program could be assembled.
Symbolic addresses separated meaning from final placement
A name could represent the target of a branch or the location of data while the assembler resolved that name to an actual drum address. This is a foundational assembler service that later programmers would take for granted.
SOAP’s ‘optimal’ claim was specific to drum placement
The Smithsonian’s SOAP II manual describes symbolic addresses being assigned optimum drum equivalents and documents rules by which blank addresses could be filled by the assembly program.[3]
“Optimal” should therefore not be read in the modern sense of global compiler optimization. SOAP was solving a hardware-specific scheduling problem: choose drum positions intended to reduce access delay as the instruction stream progressed.
Automatic placement captured a specialized programming skill
An expert human could sometimes exploit detailed knowledge of loops and timing more aggressively than a general heuristic. SOAP’s value was consistency and productivity: it automated much of the placement work for ordinary programs.
SOAP became infrastructure around which other 650 software accumulated
IBM’s program-library catalog lists SOAP-related utilities, variants and systems that describe themselves in relation to SOAP II.[4] The catalog shows how an assembler could become infrastructure for debugging tools, library routines and local extensions.
Once many installations used similar symbolic conventions, exchanging programs became easier than when every site relied on private absolute-address coding practices.
The popularity of the IBM 650 amplified the software’s influence
IBM describes the 650 as its first mass-produced computer and a major commercial success.[1] Universities and businesses acquired enough machines to create communities of programmers who shared routines, teaching material and tools.
A software system on a widely installed machine can matter historically even if its language is narrow. SOAP exposed many programmers to the expectation that symbolic source and automated translation were normal parts of using a computer.
SOAP became a foundation for further assembler experimentation
The Columbia history notes that later IBM 650 programmers built variants and successors, including Donald Knuth’s SuperSoap, while FOR TRANSIT used SOAP as part of a translation path from FORTRAN source toward executable 650 code.[2]
This layering is important. An assembler did not have to disappear when higher-level compilers arrived. It could become an intermediate target and a foundation for more advanced programming systems.
Why SOAP belongs in the origins of programming
SOAP combined three important programming ideas in one practical system: symbolic operation codes, symbolic addresses and automated placement of instructions for a difficult memory architecture. It reduced both clerical translation work and a form of machine-specific performance engineering.
The system also shows why early assemblers were more than cosmetic conveniences. On the IBM 650, software could make decisions about physical instruction placement that previously demanded expert manual planning.[3][4] By turning specialist timing knowledge into a reusable tool, Poley’s work helped shift programming toward the modern expectation that mechanical symbol resolution and routine optimization belong in software rather than in the programmer’s head.
The drum made the benefit unusually concrete. If an instruction finished just after the desired next word had passed the read head, the processor could wait almost a full revolution before continuing. SOAP’s automatic placement rules tried to turn knowledge of instruction timing into a repeatable software service. The assembler therefore captured a form of performance expertise that otherwise had to be relearned by every new 650 programmer.
This episode also demonstrates a recurring pattern in early programming history: the most consequential software innovations often automated bookkeeping that expert programmers had previously performed by hand. Once that bookkeeping moved into tools, the same machine could serve a broader population and programming knowledge could be expressed in reusable conventions rather than private craft practice.
Works Cited
- 01IBM — The IBM 650 ibm.com
- 02Columbia University Computing History — The IBM 650 columbia.edu
- 03Smithsonian National Museum of American History — SOAP II Reference Manual americanhistory.si.edu
- 04IBM 650 Library Program Abstracts — Bitsavers bitsavers.org
- 05Donald E. Knuth — The Early Development of Programming Languages club.cc.cmu.edu
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead