Los Alamos Macro-assembler for IBM 701 

Los Alamos improvement of the SO2 system for the IBM 701, also drew on the Rochester assembler, hence DUAL (both systems) Used as the basis for REG-SYMBOLIC

(Also "Regional Assembly Program 607" and "607"). Operational September 1953

Places Hardware:
Related languages
ASSEMBLY => DUAL-607   Based on
SO 2 => DUAL-607   Based on
DUAL-607 => DUAL   Written using
DUAL-607 => REG-SYMBOLIC   Built on

  • Sweeney, Dura W. "Los Alamos Coding System and Assembly Program for the IBM 701" view details Extract: The nature of the task
    The process of coding, coding assembly, and check-out of the assembled code is the most demanding upon the coder's attention and, in many cases, his time. Therefore, it is necessary to furnish the coder with a simple but highly versatile coding system and assembly program, and a variety of utility programs to aid him in the detection and correction of coding errors.
    As a result of our self-service system at Los Alamos, many people with virtually no experience with internally programmed machines have undertaken the coding of large problems for the 701.
    The first such coders are now quite adept, but more people are still starting to learn to code. This has required a versatile coding system with as few restrictions and conventions outside of the use of the 32 operations as possible, because of two reasons: first, that both the new and experienced coder use a system based as closely as possible upon the machine language, and second that the new coder be unhampered by restrictions so that he may be free to devise new coding techniques. Another requirement is that the assembly program for this system must be easily usable and virtually foolproof.
    Extract: Regional Programming
    Regional Programming
    Regional programming is one of the coding systems that fits these requirements and is used almost exclusively at Los Alamos. A brief description of the system follows. The coder uses three main divisions of electrostatic storage. They are storage for problem constants, storage for numbers calculated by the code, and storage occupied by the code itself. Any or all of these divisions may be subdivided. For example, the storage for numbers calculated by the code may be subdivided into erasable storage used in certain coding loops and storage used to contain numbers for later printing. Using regional programming, the coder assigns a letter to distinguish each variety of storage. These letters are in the range from A to H and from J to Q. The letters A, B, E, and F are the most commonly used and denote storage for universal constants, storage for problem constants, erasable storage, and storage for code, respectively.
    The coder makes a flow diagram or breaks the problem into small logical calculations. Then each block of the flow diagram or logical part of the problem is assigned a number in the range from 0 to 99.
    This number and letter are combined and called the regional index, and the coder may distinguish at a glance the part of the problem and type of storage referred to. Each regional index is followed by a regional location in the range from 0000 to 4095. Coding proceeds with the coder fiiing these various blocks of storage starting from regional location 0.
    The coding form used is divided into columns that correspond to card columns. One column contains a digit to designate whether this is a control card or a card containing coding. The next seven columns contain the regional location index and regional location. The next three columns contain the sign and operation parts of the address. The next seven columns contain the regional address index and regional address. Then, 20 columns are allowed for comments about the code followed by eight columns which contain the alphabetic abbreviation of the operation. Each line of the coding form contains one half-word instruction and corresponds to one punched card.
    When the coding is finished, the coder prepares a control card for each regional index. This control card indicates the absolute location in electrostatic storage that the assembly program will assign to the regional location. The coder may assign these locations so that there are no gaps in his code or may locate different regions with gaps between them to be fied with other sections of code. In the course of coding, it is necessary to use operations whose address parts do not refer to electrostatic memory, such as shift orders. This type of address is characterized by the regional index, OOR, and no control card is necessary for this index, because the address is already absolute and does not need to be located. After the control cards are prepared, the coder is ready to use the assembly program.
    Extract: Regional Assembly Program
    Regional Assembly Program
    Regional assembly program 607 has been written at Los Alamos to replace a similar program, called S02, written by IBM.
    The 607 program uses the card reader, printer, punch, and electrostatic storage only. Normally, all control cards are read into the 701 prior to the reading of the cards containing the regional code. Each card is read, assembled, checked, and stored in electrostatic storage before the next card is read. After each card is assembled, its location is checked against the previous card's location. If the locations are in consecutive order, card reading is resumed until 44 cards (43 cards in the case of regional binary punching) are assembled. If nonconsecutive locations are encountered or if 44 cards have been read, card reading stops, one binary card is punched, and a page is printed showing the original code and the assembled code in both decimal and octal notation. Then card reading is resumed.
    The 607 program allows three types of control cards. One type is used to assign absolute locations to regional locations and regional addresses, one type is used to expand or contract regional locations and addresses, and one type is used to change one regional index to another. Up to 200 control cards may be entered.
    The 607 program also allows one other type of card that is used to introduce half-word or full-word constants into regional locations before assembly. This type of card contains the usual regional location index and regional location, but the operation and regional address are zero, and the regional address index is OOR. The sign of the operation specifies whether the information punched in the comments columns is to be converted to a half-word or a full word. The constant is considered a fractional number consisting of 12 digits and a sign. It is followed by a two-digit decimal scaling factor and a two-digit binary scaling factor. The decimal scale factor is in the range 00 to 11 to indicate the number of integers in the constant. The binary scale factor is in the range 00 to 35 to indicate the number of binary integers in the converted constant. In the case of a half-word constant, the constant is converted to binary and stored in the operation and address part of this card's location. In the case of a full-word constant, the left half-word is stored in this card's operation and address part, then another card image is formed in electrostatic storage with location one greater than the previous location, and the right half-word is stored in this card image's operation and address part.
    The 607 program checks each card for double punching and blank columns. It checks each original regional location index, regional location, operation, regional address index, and regional address to see if they are within the prescribed ranges. It checks each assembled regional location index, location, regional address index, and address to see that they are still within the prescribed ranges. It also checks that there is a control card giving an absolute location for each regional location and address. 607 also checks each constant for double punching or blank columns and checks that the binary scaling is large enough to accommodate the decimal scaling, and that the rounding of the converted 12-digit number to 35 bits (or 17 bits) does not overflow.
    All printing and punching are controlled by sense switches. 607 contains one print program and three different punch programs. The first punch program punches binary cards containing up to 44 half words in the 8 through the 12 row of the card. The 9 row contains the check sum, the halfword count, and the location of the first word. The second punch program punches new regional decimal cards. The third program punches what we term regional binary cards. Let me digress here, briefly, to explain regional binary cards and their importance to the 701 user.
  • Bemer, R. W. "The Status of Automatic Programming for Scientific Problems" view details Abstract: A catalogue of automatic coding systems that are either operational or in the process of development together with brief descriptions of some of the more important ones Extract: Summary
    Let me elaborate these points with examples. UNICODE is expected to require about fifteen man-years. Most modern assembly systems must take from six to ten man-years. SCAT expects to absorb twelve people for most of a year. The initial writing of the 704 FORTRAN required about twenty-five man-years. Split among many different machines, IBM's Applied Programming Department has over a hundred and twenty programmers. Sperry Rand probably has more than this, and for utility and automatic coding systems only! Add to these the number of customer programmers also engaged in writing similar systems, and you will see that the total is overwhelming.
    Perhaps five to six man-years are being expended to write the Alodel 2 FORTRAN for the 704, trimming bugs and getting better documentation for incorporation into the even larger supervisory systems of various installations. If available, more could undoubtedly be expended to bring the original system up to the limit of what we can now conceive. Maintenance is a very sizable portion of the entire effort going into a system.
    Certainly, all of us have a few skeletons in the closet when it comes to adapting old systems to new machines. Hardly anything more than the flow charts is reusable in writing 709 FORTRAN; changes in the characteristics of instructions, and tricky coding, have done for the rest. This is true of every effort I am familiar with, not just IBM's.
    What am I leading up to? Simply that the day of diverse development of automatic coding systems is either out or, if not, should be. The list of systems collected here illustrates a vast amount of duplication and incomplete conception. A computer manufacturer should produce both the product and the means to use the product, but this should be done with the full co-operation of responsible users. There is a gratifying trend toward such unification in such organizations as SHARE, USE, GUIDE, DUO, etc. The PACT group was a shining example in its day. Many other coding systems, such as FLAIR, PRINT, FORTRAN, and USE, have been done as the result of partial co-operation. FORTRAN for the 705 seems to me to be an ideally balanced project, the burden being carried equally by IBM and its customers.
    Finally, let me make a recommendation to all computer installations. There seems to be a reasonably sharp distinction between people who program and use computers as a tool and those who are programmers and live to make things easy for the other people. If you have the latter at your installation, do not waste them on production and do not waste them on a private effort in automatic coding in a day when that type of project is so complex. Offer them in a cooperative venture with your manufacturer (they still remain your employees) and give him the benefit of the practical experience in your problems. You will get your investment back many times over in ease of programming and the guarantee that your problems have been considered.
    The IT language is also showing up in future plans for many different computers. Case Institute, having just completed an intermediate symbolic assembly to accept IT output, is starting to write an IT processor for UNIVAC. This is expected to be working by late summer of 1958. One of the original programmers at Carnegie Tech spent the last summer at Ramo-Wooldridge to write IT for the 1103A. This project is complete except for input-output and may be expected to be operational by December, 1957. IT is also being done for the IBM 705-1, 2 by Standard Oil of Ohio, with no expected completion date known yet. It is interesting to note that Sohio is also participating in the 705 FORTRAN effort and will undoubtedly serve as the basic source of FORTRAN-to- IT-to-FORTRAN translational information. A graduate student at the University of Michigan is producing SAP output for IT (rather than SOAP) so that IT will run on the 704; this, however, is only for experience; it would be much more profitable to write a pre-processor from IT to FORTRAN (the reverse of FOR TRANSIT) and utilize the power of FORTRAN for free.
          in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details
  • [Bemer, RW] [State of ACM automatic coding library August 1958] view details
          in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details
  • [Bemer, RW] [State of ACM automatic coding library May 1959] view details Extract: Obiter Dicta
    Bob Bemer states that this table (which appeared sporadically in CACM) was partly used as a space filler. The last version was enshrined in Sammet (1969) and the attribution there is normally misquoted.
          in [ACM] CACM 2(05) May 1959 view details
  • Carr, John W III; "Computer Programming" volume 2, chapter 2, pp115-121 view details
          in E. M. Crabbe, S. Ramo, and D. E. Wooldridge (eds.) "Handbook of Automation, Computation, and Control," John Wiley & Sons, Inc., New York, 1959. view details
  • Voorhees, Edward A. "Recollections of the 701 at Los Alamos" pp177-178 view details
          in Annals of the History of Computing, 05(2) April-June 1983 IEEE (IBM 701 Issue) view details