DOUGLAS(ID:56/dou002)Douglas SM Macro-assemblerMacro-assembler for IBM 701 by Douglas Aircraft Company, Santa Monica, May 1953 Used extensively for airflight simulations and design, and considered much faster than "inefficient" FORTRAN Places 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 On January 4, 1952, Jack Middlekauff issued "Report SM-14248 on Defense Calculator," a 70-page document that could (and probably did) serve as our comprehensive hardware and software manual for the machine. Following a general introduction to what we would now call the architecture of the 701, each of the 32 operation codes ("orders") was described in detail, with many excellent programming examples, including, among others, card input while converting from decimal to binary between Copy instructions. The beginnings of what was to become known as the "Douglas System" can be seen in this document. Extract: The library A principal concern was the creation and use of a library of well-designed subprograms to be used whenever and as often as needed. The subprograms can be stored on tape [and] transferred to memory as part of the procedure for setting up a problem. This is exactly what was eventually done, and Middlekauff's report discusses in detail the extension of "basic linkage" ("a Reset Add a, Transfer b," is engraved forever in every 701 coder's deepest memory!) to include the various possibilities for call-by-name, call-by-value, etc. Further recognition is made that "A large variety of problems involve . . . elements that cannot be haning dled directly by the Defense Calculator. Problems which involve numbers expressed in floating decimal form, complex numbers, vectors, or matrices are of this type." Here the notion of using "abstract instructions" is introduced; today we would use the term interpretation, although as implemented at Douglas two features stand out: the interpreted language (i.e., instruction set) is nearly identical to the native instruction set both in syntax and semantics (today's terminology), and the coder could easily switch from mabegun chine instructions to abstract instructions and back again. Indeed, one of the first such subroutines that I wrote for the 701 was the "tracing abstraction" in which instructions were interpreted exactly as by the 701, but with the added feature of instruction-by-instruction printout (in octal) between designated breakers, points. The discussion of subprograms leads directly to the problems of "Relocation and Assembly." Here, "IBM is working on an assembly program which will take care of some of the details of programming," but, of course, our own was ready long before IBM's Extract: The heart of the DOuglas System The heart of the "Douglas System" was the Douglas Assembly Program. Touted as "the solution to the problem of symbolic coding," only with charity could the term austere be applied to the resources it provided for program preparation. The central idea was "regional programming," a region, in essence, being a unit of code that could be relocated relative to any given base address. Regional names were purely numeric, with strict interpretation. Region numbers 10 and above were reserved for subroutines, which were concatenated and relocated starting at absolute memory location 0. Regions 1 and 2 were reserved for "temporary" and "data" storage, respectively, and, in effect, made up two one-dimensional arrays of machine words that fiied the memory locations unassigned to program instructions. References within these two regions were strictly relative. The only facility resembling symbolic reference was to instructions within a given subroutine, and these were required to be numbered sequentially, but not necessarily consecutively. (One of the six error conditions detected by the assembly program was an out-of-sequence instruction.) Region 0 was an artifact; it allowed the absolute addresses that were required in certain 701 instructions. It's hard to believe, but essentially that was it. There wasn't even any form of conversion (even from octal to binary) provided for program constants; this led to the concept of "instructional constants" in which the desired binary constant was expressed as one or two decimal instructions. The programming manual dutifully records that r, for example, should be coded as "Read Backwards 543+, Store Address 1297-"! (There is perhaps only a single significant innovative feature of the Douglas assembler. After the original source cards had been read, but before assembly was begun, a deck of cards known as the "ABC deck" was produced. These contained the source instructions in a compact binary format that provided a 151 reduction in card volume. A "reassembly" program was provided that allowed the original "ABC deck" to be updated "symbolically," before assembly, so that a crude form of source-language editing was provided. This was an important consideration for an expensive computer that read input at 150 cards per minute.) in Annals of the History of Computing, 05(2) April-June 1983 IEEE (IBM 701 Issue) view details Different installations were producing their own software. China Lake, through the courtesy of John Lowe at Douglas, was given what we came to know as the ?Douglas System.? It was a godsend, and although we had used other systems as well, many of our people thought it was the best they could ever expect to have. The point is that the software-hardware separation has been with us a long time, and the hardware in the 701 era seemed to be quite a bit ahead of the software. in Annals of the History of Computing, 05(2) April-June 1983 IEEE (IBM 701 Issue) view details |