Symbolic Optimal Assembly Program
| Company type | Software |
|---|---|
| Industry | Computer software |
| Founded | 1954 |
| Founder | Stan Poley |
| Headquarters | United States |
| Products | Assembler software for IBM 650 |
The Symbolic Optimal Assembly Program (SOAP) is an assembler designed for the IBM 650 Magnetic Drum Data-Processing Machine, an early computer that was initially deployed in 1954.
History
Created by Stan Poley at IBM's Thomas J. Watson Research Center, SOAP earned the label "Optimal" due to its ability to organize instructions on the storage drum in a way that reduces the access delay between instructions. This assembler operates as a multi-pass system, reading the source code several times to produce the final object code.
Following the original release, SOAP II appeared in 1957,[1] introducing capabilities for hardware elements such as index registers and magnetic core memory. Later iterations included SOAP IIA (1958), SOAP 2L, SOAP 2L Tape, SOAP 4000, and SOAP 42 (1961). Additionally, SOAP functioned as the backend for the FOR TRANSIT compiler in 1957.[2]
In 1958, Donald Knuth independently developed SOAP III,[3] followed by SUPERSOAP in 1959 at the Case Institute of Technology (now part of Case Western Reserve University). Moreover, the US National Bureau of Standards, under Herbert Howe’s leadership, produced ISOPAR, a variant of SOAP recognized for its advanced optimization techniques.[4]
Optimization
The IBM 650’s primary storage is a magnetic drum capable of holding up to 4,000 words and spinning at 12,500 revolutions per minute (equivalent to one rotation every 4.8 milliseconds), resulting in an average access time near 2.4 milliseconds. If instructions were placed sequentially on the drum, each subsequent instruction would require waiting for a full rotation before it could be accessed. Given that many instructions complete execution in roughly three milliseconds, performance was enhanced by strategically positioning instructions on the drum to minimize these delays. Each instruction contains a pointer to the address of the following instruction, effectively creating a linked list structure within memory. SOAP’s optimization arranges instructions so that once one finishes executing, the next is immediately accessible, thereby accelerating execution speed by a factor of six or seven.
Pseudo-operations
SOAP II provides support for numerous pseudo-operations (assembly directives) designed to assist with program assembly and memory allocation:
| OP | Name | Description |
|---|---|---|
| HED | Heading | Divides multiple programs assembled together; can append characters to symbol names to prevent naming conflicts. |
| REL | Relocatable Library Program | Indicates the beginning of a relocatable library program and specifies relocation parameters. |
| RBR | Relocatable Block Reservation | Allocates erasable blocks within routines on the drum, reducing reliance on punched cards for data storage. |
| REQ | Relocatable Equivalence | Associates a symbol with a relocatable subroutine address, optionally including relocation adjustments. |
| BLR | Block Reservation | Designates specific drum address ranges as off-limits for assignment. |
| BLA | Block Availability | Marks certain drum address ranges as available for allocation. |
| REG | Regional Specification | Defines a drum address range as a "region," identified by a single-character region ID. |
| ALF | Alphabetic Data | Allows up to five alphabetic characters to be assembled at a specified location. |
| PAT | Punch Assembly Table | Instructs SOAP to punch a deck of fifty Type Y cards listing used and free drum locations during assembly, facilitating restoration of availability status in later assemblies. |
| BOP | Beginning of Program | Signals the start of a new program assembled separately within the same card deck. |
| EQU | Equivalence | Assigns a symbol an absolute, regional, or symbolic value equivalence. |
| SYN | Synonym | Links a symbol to an absolute drum address and marks that address as unavailable for assignment. |
Comments
Source cards provide space for comments of up to ten characters within columns 63 to 72. When additional commentary is necessary, a Comments Card (designated as Type 1, indicated by '1' in column 41) allows for remarks extending to thirty characters between columns 43 and 72.
External links
- ↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).
- ↑ Cite error: Invalid
<ref>tag; no text was provided for refs namedLorenzo - ↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).
- ↑ Lua error in Module:Citation/CS1/Configuration at line 2123: attempt to index field '?' (a nil value).