The Symbolic Optimal Assembly Program (SOAP) is an assembler for the IBM 650 Magnetic Drum Data-Processing Machine, an early computer first used in 1954. It was developed by Stan Poley at the IBM Thomas J. Watson Research Center. SOAP is called "Optimal" (or "Optimum") because it attempts to store generated instructions on the storage drum to minimize the access time from one instruction to the next. SOAP is a multi-pass assembler, that is, it processes the source program more than once in order to generate the object program.
The first version of SOAP was succeeded by SOAP II in 1957,[1] which supported additional hardware features such as index registers and magnetic core memory, then SOAP IIA in 1958,[2] SOAP 2L, SOAP 2L Tape, SOAP 4000, and SOAP 42 in 1961.[3] SOAP was used as a backend to the FOR TRANSIT compiler in 1957.[4]
Donald Knuth independently produced versions named SOAP III in 1958[5] and SUPERSOAP in 1959[6] at Case Institute of Technology, now part of Case Western Reserve University in Cleveland, Ohio. The US National Bureau of Standards, under the direction of Herbert Howe, also wrote a version of SOAP, called ISOPAR, said to significantly improve optimization.[7]
The IBM 650 uses a magnetic drum as main storage. The drum holds up to 4,000 words and rotates at 12,500 revolutions per minute (RPM), 4.8 msec per rotation, or average access time of 2.4 msec. "If you placed your instructions sequentially onto the drum, you would have to wait for a complete rotation of the drum before the CPU could obtain the next instruction. Since many instructions on the 650 could execute in around 3 milliseconds, you would try to optimize your code by placing the instructions on the drum in such a way that it would not take the drum a full revolution to access your next instruction."[8] Each instruction contains the address of the next instruction to execute; instead of a sequential array of instructions the memory appears to be a linked list. SOAP optimizes by placing instructions to be executed sequentially in locations around the drum such that the next instruction is available as soon as possible after the current instruction finishes. This optimization was said to make the assembled programs "run as much as six or seven times faster."
SOAP II supports the following pseudo-operations (assembly directives):
| OP | Name | Description |
|---|---|---|
| HED | Heading | Separates programs, possibly written separately, which are being assembled together. It can specify a character to be appended to symbol names in this section to avoid naming conflicts. |
| REL | Relocatable Library Program | Defines the start of a relocatable library program being assembled ahead of the main program. It specifies the amounts by which assembled addresses should be relocated. |
| RBR | Relocatable Block Reservation | Reserves a range of drum locations as "erasable blocks within the routine," to avoid using a number of cards to specify a data area. |
| REQ | Relocatable Equivalence | Equates a symbol to the address of a relocatable subroutine, and optionally specifies a relocation amount. |
| BLR | Block Reservation | Marks a range of drum addresses as unavailable for assignment by SOAP. |
| BLA | Block Availability | Marks a range of drum addresses as available for assignment. |
| REG | Regional Specification | Defines a range of drum addresses as a "region", identified by a one-character region id. Locations within the region are specified as <region id>nnnn where nnnn is a number from 1 to the number of locations specified for the region. |
| ALF | Alphabetic Data | Specifies up to five alphabetic characters to be assembled at the specified location. |
| PAT | Punch Assembly Table | Tells SOAP to punch a deck of fifty Type Y cards listing used and available drum locations at any point during assembly. This table can be examined manually and fed back into SOAP on a subsequent assembly to restore "the availability status which existed at some point of a prior assembly." |
| BOP | Beginning of Program | Indicates the start of a new program to be assembled separately from previous programs in the same card deck. |
| EQU | Equivalence | Equates a symbol to an absolute, regional, or symbolic value. |
| SYN | Synonym | Equates a symbol to an absolute drum address. The address is marked unavailable for assignment |
Each source card can contain up to ten characters of comments in columns 63–72. For longer comments, up to thirty characters may be entered on a Comments Card (Type 1, '1' in column 41) in columns 43–72