SOAP II Coding form, 1957

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.[1] 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,[2] which supported additional hardware features such as index registers and magnetic core memory, then SOAP IIA in 1958,[3] SOAP 2L, SOAP 2L Tape, SOAP 4000, and SOAP 42 in 1961.[4] SOAP was used as a backend to the FOR TRANSIT compiler in 1957.[1]

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]

Optimization

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."[1]

SOAP features

Pseudo-operations

SOAP II supports the following pseudo-operations (assembly directives):[2]

SOAP II Pseudo-operations
OPNameDescription
HEDHeadingSeparates 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.
RELRelocatable Library ProgramDefines 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.
RBRRelocatable Block ReservationReserves a range of drum locations as "erasable blocks within the routine," to avoid using a number of cards to specify a data area.
REQRelocatable EquivalenceEquates a symbol to the address of a relocatable subroutine, and optionally specifies a relocation amount.
BLRBlock ReservationMarks a range of drum addresses as unavailable for assignment by SOAP.
BLABlock AvailabilityMarks a range of drum addresses as available for assignment.
REGRegional SpecificationDefines 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.
ALFAlphabetic DataSpecifies up to five alphabetic characters to be assembled at the specified location.
PATPunch Assembly TableTells 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."
BOPBeginning of ProgramIndicates the start of a new program to be assembled separately from previous programs in the same card deck.
EQUEquivalenceEquates a symbol to an absolute, regional, or symbolic value.
SYNSynonymEquates a symbol to an absolute drum address. The address is marked unavailable for assignment

Comments

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

References

  1. 1 2 3 Lorenzo, Mark Jones (2019). The History of the Fortran Programming Language. p. 162. ISBN 9781082395949. Retrieved Sep 28, 2020.
  2. 1 2 IBM Corporation (1957). SOAP II for the IBM 650 Data Processing System (PDF). Retrieved Sep 27, 2020.
  3. ↑ IBM Corporation (1958). IBM 650 Data Processing System Bulletin. Retrieved Sep 27, 2020.}
  4. ↑ IBM Corporation (1961). SOAP 2L, SOAP 2L Tape, SOAP 4000, and SOAP 42 (PDF). Retrieved Sep 27, 2020.
  5. ↑ "SOAP III". Online Historical Encyclopaedia of Programming Languages. Retrieved Sep 27, 2020.
  6. ↑ Knuth, Donald E. (1959). SUPERSOAP Assembly System for the Augmented 650 (PDF). Retrieved Sep 27, 2020.
  7. ↑ Howe, Herbert. ISOPAR: a new and improved symbolic optimizing assembly routine for the IBM 650 (PDF). Retrieved Sep 28, 2020.
  8. ↑ Kugel, Herb (October 22, 2001). "The IBM 650". Dr. Dobb's. Retrieved Sep 28, 2020.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.