SO 2(ID:120/so:001)Symbolic assembler for IBM 701Also SO2 Symbolic assembler for the IBM 701 developed internally by McLelland and Rochester (initially when it was still called the Defence Calculator), based on their experiences with the SSAC. It began with a theoretical approach to coding, so by the time the first 701 was delivered to IBM Poughkeepsie Dec. 20, 1952 it only took 4 months to implement. (in use April 1953) Used a library system developed by McLelland based on that of Wilkes called Regional Assembly, hence the assembler was also called the Regional Assembly Lanugage or RAL. RAL was used to teach the IBM classes in New York City. People: Hardware:
Related languages
References: 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. Extract: IT, FORTRANSIT, SAP, SOAP, SOHIO 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 in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details 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 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 Most applications however, were programmed in SPEEDCODE or ACOM — two programming systems that transformed the single-address fixed-point arithmetic machine into a streamlined three-address floating-point system, SPEEDCODE was authored by Walter A. Ramshaw and his people at the United Aircraft Corporation. ACOM was written by Jack Horner and others at the Allison Division of GM. Both of these systems used subroutines to perform the floating-point arithmetic, which in turn slowed the 701 from its basic speed of 15,000 single-address fixed-point instructions per second to about 150 three-address floating-point instructions per second. in Annals of the History of Computing, 05(2) April-June 1983 IEEE (IBM 701 Issue) view details Rochester switched to this system early in 1950, when detailed TPM planning began. A page of a TPM program written by W. Buchholz, his planning colleague, is shown in figure 9.2; the IAS numbering scheme for instructions is evident, except that the unwieldy Roman numerals are not used.25 Rochester's subroutine-relocating program for the Test Assembly, written in September, is shown in figure 9.3.26 Note that a decimal point has replaced the comma in instruction labels and that letters are used for data areas. Labels with two decimal points were being used, although none appear in the programs of figures 9.2 and 9.3. "Operation" is written as an abbreviated descriptive word. The "comment" area of the coding form, a feature important to enhanced comprehensibility, also had been anticipated by Goldstine and von Neumann, who called it the "explanatory column."27 Until they had a machine to test their programs on, Rochester and Buchholz did not bother to translate from "preliminary enumeration" to "final enumeration." When the Test Assembly began operating in the autumn of 1950, translation became necessary; they did it by a clerical process in which actual operation codes and memory addresses were substituted for the preliminary ones, as Goldstine and von Neumann had done to make their examples complete (see figure 9.3). With the advent of the Defense Calculator project in early 1951, Rochester joined McClelland in studying the feasibility of automatic assembly but clung to the style of programming he had found most useful. Referring to his decimal and alphabetic-decimal labels as "symbolic addresses," he asserted, "It is possible for a machine to convert a program which is written in symbolic addresses into a program with actual address [sic]. This process will require a program which is fairly lengthy, but which would be fully manageable for either the Tape Processing Machine or the new proposed computer." His outline for the conversion process contemplated several machine-passes over a programmer's "symbolic program." First, transfer instructions from cards to tape, forming one record per instruction; next, sort the tape records into ascending order of labels, an order presumed to be the intended sequence for the assembled program (although there was provision for rearrangement of major blocks); next, append location numbers, sequentially assigned, to the records, thereby establishing for each label an equivalent actual memory address. After a second file consisting only of instructions was created, the symbolic address pails were replaced by actual addresses; this requited soiling on address purls and then collating with the main file, copying equivalent actual addresses. Final sort-collate operations created records with actual instructions and constants in correct sequence ready for compressing into a tape that could be used to load the assembled program. By the end of April, Rochester had flowcharted and written a 750-instruction Defense Calculator program to perform assembly. A label contained one, two, or three numbers, in the range 1-99, separated by one or two decimal points. Instead of the unwieldy, multiple-run sort-collate process, all instructions and data complete with symbolic labels and assigned actual addresses were held in memory, and the actual equivalents of symbolic address parts were obtained simply by searching a "symbol table" for the appropriate "symbolic: actual" entry. Although the task had been reduced to table setup and lookup operations, the improvement brought the disadvantage that the amount of needed memory grew with length of program being assembled, the Defense Calculator memory accommodating a program of no more than 300 or 400 instructions. So Rochester added a provision that permitted larger programs to be processed in segments, the intermediate results for successive segments being stored on tape. A subsidiary table provided for symbolic address parts that had to be finally specified by reference to segments out on tape.29 A second improvement dropped the notion of a relationship between labels and the sequence in which instructions and data would reside in memory at execution time. Instead, the programmer established storage sequence simply by ordering the program cards prior to assembly. Although labels still followed a decimal format, this change enhanced the programmer's freedom to choose labels that matched his concept of program structure. Most assembly programs written later provided this freedom. Another contribution was made in 1951 when Wilkes proposed that only those instructions referred to by other instructions need be labeled. This led to less clutter in written programs, to smaller symbol tables, and to faster assembly processing. When an assembly program was used, there were conspicuous differences between the source document that a programmer wrote in assembly language and the counterpart machine-language program that a 701 could execute. The programmer could use relative or symbolic addresses and alphabetic abbreviations for operations, while the executable program consisted of binary numbers and codes. In testing a program, as a result, the programmer could be faced with the problem of matching two dissimilar representations. The problem was mitigated by having assembly programs produce a printed list wherein (lie two representations weie exhibited side by side. in C.J. Bashe, L.R. Johnson, J.H. Palmer, and E.W. Pugh "IBM's Early Computers" MIT Press, 1986 (Vol. 3 in the History of Computing series) view details |