RELATIVE(ID:109/rel003)
Interpretive autocode at GM Allison
Interpretive autocode at GM Allison developed on IBM 650, operational Aug 1955
Places
- GM Allison us I
- IBM 650 IBM
References:
A third class of problems will be scheduled also for the 650. These will be the smaller engineering problems of the type now handled on the CPCs as described previously. At this time a system is being prepared for the 650 Computer which is supposed to make programming on the computer easy for engineers. In fact, we call it the EASE System (Engineering Automatic System of Solving Equations).
The EASE System actually consists of a method of symbolic coding in
which a compiling system and elementary generators are used to prepare a program in the 650 language. The engineer, however, need not be aware of all the detail which is used to prepare the actual computer program, instead, he breaks down his equations into a sequence of logical computing steps. The EASE System then assigns computer locations for all instructions and data and generates the appropriate computer instructions. Soon after this system is developed
and checked (within the next month) we expect to have all smaller
engineering problems programmed by this system. It is anticipated that these procedures will cause a large drop in present CPC loading. As an example of an EASE problem, consider the following equation:
Y = A + BCosZ * e X
The EASE solution to this equation is entered on an EASE program sheet as shown in FIGURE 1.
Extract: RelativeThe IBM 650 was installed in June of this year. At that time the general system of programming this computer was prepared and checked out. Two types of problems were scheduled for this computer, data reduction problems and small engineering problems which were, however, sufficiently large to make handling on the CPCs awkward or not practical. These problems are largely prepared by engineering calculations using the Allison Relative System. A representative list of these problems is:
Data reduction problems.
Optimum time decline path for aircraft-engine matching.
Stream filament calculation of flow path through blading.
Turbine velocity diagrams.
Solution of sets of 10 to 24 simultaneous equations for thermocouple harness analysis.
Engine calibration calculation.
Noise level study.
in Armour Research Foundation Second Annual Computer Applications Symposium 1955 view details
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
Resources
- The IBM 650
external link