KOMPILER 3(ID:2682/kom003)Livermore AutocodeKOMPILER 3 for IBM 704 K3 compiler group at Livermore - Some records say March 1958, but discussed by Bemer November 1957 featured a three line (ie 2-dimensional) input "This program, for the 704, is being written to serve the special needs of the University of California Radiation Laboratory at Livermore. It is FORTRAN-like, but it implies a sharp criticism of the lack of sufficient mathematical characters in today's computers by coding each algebraic statement in three lines (or punched cards). Thus the superscripts and subscripts stand out from the main statement. This eliminates a great deal of the otherwise necessary parentheses and special notation, although the total effect is an increase in card volume for a given program." 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. Extract: KOMPILER 3 This program, for the 704, is being written to serve the special needs of the University of California Radiation Laboratory at Livermore. It is FORTRAN-like, but it implies a sharp criticism of the lack of sufficient mathematical characters in today's computers by coding each algebraic statement in three lines (or punched cards). Thus the superscripts and subscripts stand out from the main statement. This eliminates a great deal of the otherwise necessary parentheses and special notation, although the total effect is an increase in card volume for a given program. 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 in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 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 in Belzer, J. ; A. G. Holzman, A. Kent, (eds) Encyclopedia of Computer Science and Technology, Marcel Dekker, Inc., New York. 1979 view details GAM: So, when you came back, having worked through this development of FORTRAN and stuff like that, were you the Lab's missionary for FORTRAN then, or did you just go back to writing Applied Physics Codes? BH: No, that got me into the language game. When I got back, there was a lot of excitement. I got into a Language Group with Kent Elsworth and Dorothy Monk. With my experience in FORTRAN, they formed the K3 Compiler Group. We had the three-line input, whereby you could put the variable on the middle line and the superscripts and subscripts on the line above and the line below to make it look more like a mathematical language. Believe it or not, after a year and a half or so, we actually got the thing running, but I don't think anyone ever used it. GAM: It was very hard, I tried to use it for my code. You had to get everything in the right column all the time. That is what was wrong. BH: Yes, you had to worry about getting everything exactly aligned, and that was a losing proposition from the start. For a while, there was fear that mathematicians would not accept standard FORTRAN. For example, A**B means A to the B power because we didn't have any way to keypunch AB. GAM: That's a big concession to the IBM keypunch symbol table. They didn't even have anything like a square root. BH: Yes, this was all invented. GAM: Invented to get around the IBM keypunch? BH: But there were a lot of efforts. GAM: So, you worked with Kent on what he called the Kompiler. BH: Right, we called it the K-O-M-P-I-L-E-R, Kompiler. But it became the world's second "Spruce Goose". GAM: How do you mean "Spruce Goose"? BH: It taxied well, but it never took off. GAM: Well, we tried to use it, but that input deck was so voluminous. Basically it was three times the size it should be. BH: Oh yes, in those days. Yes, it took three cards per line. That was another problem. If we¹d had display tubes, or something like that, where you didn't have to worry about punch card data, it may have run. Extract: Anecdote BH: But then we really got to going strong. We got to the point where we were all LRLTRAN/FORTRAN and had our own compiler group set up. But I've worked on just about every compiler after they came along from the time I started at the Laboratory. Let's see, Sam Mendicino and George Sutherland did the first bootstrap. You know FORTRAN/FORTRAN. They used FORTRAN to write a FORTRAN file. And that was a Godsend. The program meant that there were no more single language programs. GAM: It grew into LRLTRAN eventually, didn't it? BH: Yes. That's what I mentioned, at that point around 1965 onward we were sort of on our own. We had our own language, our own version of FORTRAN. We were compatible with standard FORTRAN and still had special features for the Lab. GAM: I don't remember that. I remember for instance, you guys had something about the Divide that you rounded before it was completed or you didn't put it in the hierarchy of operations in the right place or something. BH: Well, you'll probably find that in all the conversion estimates, whether or not you round or not. You probably will find that that's a problem that won't go away. In one part of the country they are rounding in some instance, in another part of the country they are not rounding in this case. That's just an incompatibility in the numbering base. For one thing, that's in the binary and when you chop a binary bit that's one-fourth of a decimal digit maybe. in Belzer, J. ; A. G. Holzman, A. Kent, (eds) Encyclopedia of Computer Science and Technology, Marcel Dekker, Inc., New York. 1979 view details |