ELI(ID:65/eli001)Equitable Life 705 autocodefor Equitable LIfe Autocoder Autocoder developed by Equitable Life Assurance to do actuarial calculations on the IBM 705 and IBM 650 (Operational May, 1957) Hardware: References: With optimizing being both tedious and valuable, it was only natural to ask "Can the 650 be programmed to optimize its own programs?" The answer to this is: Yes—-but certain compromises are necessary. One approach restricts the size of the program which can be optimized, e.g. a limit of 500 words (one-fourth of the machine's memory capacity). Another approach calls for the writing of programs with pseudo-addresses (unintelligible to the 650 itself) by means of which all cross-referencing is done by the programmer. We are thus led to a second question, "How much will we demand of an optimizing program, and where are we willing to compromise?" A general answer is: With a minimum of help from the programmer, an optimizing program should substantially reduce the latency of any program the 650 can execute. Specifically: 1. The latency reduction had to be substantial, but not necessarily the best possible, or even competitive witt: the work of a programmer; 2. All programs up to 2000 words had to be handled, and in the same way; 3. All cross-referencing lind to be done automatically by the machine; 4. Actual 650 instructions had to be input and output, so that programs could be debugged, optimized, and modified any number of times and in any order. These requirements have been met by the optimizing program now in use at the Equitable Life Assurance Society. DOI in [ACM] JACM 2(1) (Jan 1955) view details General Description The Equitable Life Interpreter, which will be referred to as ELI, is a three-address, 20-digit fixed-decimal interpretive routine intended for use on low-frequency computing jobs. Some of the features of the system will depend upon the particular machine on which the system is used; however, most of the system will remain the same regardless of the actual machine involved. Therefore, ELI will be considered as a new computer, and will be discussed as such. ELI is a stored program machine in which a word consists of 20 decimal digits and an algebraic sign. Words will, in general, represent quantities to be operated upon or the instructions for operating upon these quantities. Quantities will have a centrally located decimal point and positive or negative sign; that is, quantities will have an integral portion (I) and a decimal portion (D), each of ten digit For certain purposes, words may be thought of as consisting of 10- digit halves, five-digit quarters, or four-digit fifths (still, however, with only one algebraic sign per word, pertaining to all portions): Extract: Input and Output Input and Output The primary input and output medium for ELI is the IBM card. (Other types of input and output will depend upon the particular machine actually being used -- See appendix notes on Input and Output.) Either one, two, three or four words may be read from each input card; either one, two, three or four words may be punched into each output card; the four words will occupy, respectively, columns 1 through 20, columns 21 through 40 if required, columns 41 through 60 if required, and columns 61 through 80 if required. All words which are to be read in must be fully punched; card columns which are not read may contain anything. Unused fields on output cards will be left blank. A minus sign will be punched as an X or 11 over the units position of the word, i.e. columns 20, 40, 60, 80; the absence of this punch will be interpreted as a plus sign. Extract: Addresses Addresses ELI will read data and store it in its memory section, do computations and make decisions using the data in memory, store computed results in memory, and write out data from memory. ELI's memory consists of a fixed number of locations (see Appendix notes on memory), each of which will store one word. The word stored at a location is referred to as the contents of that location. Each memory location is assigned an address, starting with 0001 for the first location and running consecutively to N (four digits) for the Nth location. By convention each instruction containing three addresses (A,B,C,) will generally specify three memory locations. The contents of these locations will be utilized by the operation called for. Where a, b, and c are zero, the addresses A, B and C will be used as written. If a is not zero, A will not be changed in the instruction as written. However, the instruction will be executed as though A had been replaced by the sum of A and the four low-order digits of the integral portion of the contents of location 000a, the same is true of b and B. and c and C. The addresses actually used will be designated by A*, B* and C*. The following examples illustrate this address-indexing feature of the machine. in [ACM] JACM 2(1) (Jan 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 in [ACM] CACM 6(03) (Mar 1963) view details The last really fun thing we did was ELI, the Equitable Life Interpreter. It was our attempt to make the 650 more accessible to the end user, although, once again, it wasn't put in those terms at that time. Our intended users were our actuaries. We believed that if they had a machine somewhat simpler than the 650, they could write many programs for themselves -- improving their productivity and decreasing our programming backlog. Despite the passage of nearly three decades, in certain respects our field hasn't changed all that much. We defined such a machine and christened it ELI. It had a memory of 699 words, each of 20 digits. The standard data word had a central decimal point, and all decimal alignment was totally automatic. The instruction word had an operation code and three addresses, each with an (optional) index register designation for any of the nine index registers -- which were merely the first nine memory locations. ELI had six arithmetic instructions and six comparisons, including two for absolute values. It had three move instructions, the first of which moved a block of consecutive words from one location to another. The other two move instructions accomplished the packing of n words into one end and the unpacking of one word into n, where n could be either 2, 4, or 5. Input and output added two more operation codes, and so did a "no operation" and a stop -- two instructions that have since become somewhat unfashionable, but that were both quite standard at the time. The last two instructions were a table lookup operation and a subroutine call, bringing the total to 21 operation codes. Of these, f1ve had one-to-one counterparts in the 650 itself: read a card, punch a card, no op, stop, and table lookup. Much of ELI grew out of what I had learned while working in the 701 installation prior to joining the Equitable. For example, interpreters were the standard way of operating in the early days of the 701, and many of them (including the one I'd worked with) provided the address- indexing capability that the hardware lacked. Other parts of ELI were a response to what we considered limitations in the 650; the word packing and unpacking instructions obviously grew out of our early experience with all of those actuarial data tables. Finally, some things just seemed appealing, like the elimination of special index register instructions by using the low-end memory locations for indexing -- an architectural device that was to appear years later in IBM's 7070. ELT went into use in 1956, and turned out to be gratifyingly popular with its intended users. Response was so good that a source-code- compatible version was written for the 705 when that machine was installed a year or so later. This gave our users a truly machine- independent facility; they really didn't know or care -- except for a 20:1 execution time difference -- whether any particular run would be on the 650 or the 705 during the period when we had both installed. As it must, there came a time when the Equitable 650 was no more. Then, in its turn, the 705 was replaced by a 7080 -- which ran 705 programs using a conversion aid called INT580. With the advent of System/360, Equitable installed a 360/65 -- with 7080 emulation, which often ran INT580. ELI, the interpreter and the programs it interpreted, ran on all of them -- a tool, created with and for the 650, with a useful life of almost two decades. Punched-card limitations, vacuum-tube failures, drum latency, and all, the 650 managed to transcend its humble hardware and cover itself with glory. Three decades of conversations with my colleagues have convinced me that it has earned a special place in the hearts of more of us than has any other machine, before or since. in Annals of the History of Computing, 08(1) January 1986 (IBM 650 Issue) view details Resources
|