ALTAC(ID:364/alt001)
Algorithms on TAC
for ALGebraic translator into TAC
Rosen, PHILCO April 1960
Clone of FORTRAN II with extensions, written for Philco 2000, and built on TAC
Interesting to compare Steel and Rosen on how good a solution it was.
Evolved over time into the TUG Algol.
People: Hardware:
- Philco 2000 Philco
Related languages
| FORTRAN II | => | ALTAC | Extension of | |
| TAC | => | ALTAC | Written using | |
| ALTAC | => | ALTRAN | Translator for | |
| ALTAC | => | TUG Algol | Evolution of |
References:
ALTAC is the translation phase of an algebraic language compiler on the TRANSAC S-2000 computer.
The language used is an extension of the FORTRAN language in use on the 704 and other computers. Existing programs in FORTRAN language can be compiled into TRANSAC code regardless of the computer for which they were originally written.
The principal extensions of the language include the use of four dimensional arrays and the removal of restrictions on the nature of subscripts. Any fixed point expression may be a subscript and subscripts may themselves have subscripts. ALTAC permits the use of compound expressions and permits
quite general compound conditional statements in addition to the IF statement in FORTRAN. An example of a compound IF statement is
IF(X)LTE(M)~GO TO 3; if ( R ) E ( S ) , I = I + ] ; J=J+]; IF(X)GT(Z),X=Y; R=S$
NEXT STATEMENTS
This statement means: if X < Y jump to the statement with statement number 3. In this case the rest of the statement is ignored. If X > Y, find out if R = S. If so, replace I by I + ] and J by J+] and go on to the next statement in the program (NEXT STATEMENT). If - and only if - the first two conditions were not satisfied, test whether X > Z. If so, replace X by Y and R by S and continue to NEXT STATEMENT. If not, simply continue to NEXT STATEMENT.
Statement identifiers need not be numbers. They may also be any symbol acceptable to TAC. ALTAC produces a TRANSAC program by first producing a TAC program which then goes through the standard TAC processing. Much of the work of compilation is performed by TAC which is described in another paper. The rather complicated input and output statements are handled by producing calls on TAC generators, also described elsewhere. Because ALTAC operates through TAC, it is quite simple to include TAC coding at will within an ALTAC program. The statement START TAC may be followed by as much TAC coding as desired, The statement END TAC indicates the resumption of ALTAC language.
The translation of algebraic expressions starts with a scan of the expression until the first right parenthesis is encountered, The coding for the expression between this parenthesis and i t s mate is generated at this point. The coding generated attempts to make use wherever possible of instructions like FMAD (Multiply and Add) and FMSU (Multiply and Subtract) and FAMS (Add Memory and Store),
The compiler coding makes use of very general subroutines which produce a very concise and integrated program. Much of the work is done by general table look-up subroutines which take advantage of the RPT (Repeat) instruction which permits a table to be scanned in roughly the memory access time of its elements. As an example of the very general subroutines used, the card generator subroutine takes coding stored in memory and produces output cards which are in TAC input card format. For every ALTAC input card a TAC remarks card is generated so that a listing of the resulting TAC program will contain the ALTAC program as well.
One of the most complex parts of the compiler is the assignment of storage and the related problem of assignment of index registers. Let us define two arrays to be subscript equivalent if they are of the same number of dimensions and if their size in each dimension, except possibly the last, is the same. Thus, the statement
DIMENSION A(10,20,9),
B(lO,20,8)
defines subscript equivalent arrays. The ALTAC program will, in general, place subscript equivalent arrays in adjacent storage areas to permit the user wherever possible, of a single index register to represent equivalent subscript combinations.
Since a TRANSAC system will contain at least 8 index registers, the index register assignment problem is not expected to be critical. However, there is a possibility that a complicated do nest will require more index registers than there are available. In this case, all but two of the index registers will be assigned to subscript combinations chosen on the basis of level and frequency of occurrence and the other two index registers will be shared by the remaining subscript combinations.
in SESSION: Automatic programming: from the manufacturers view details
Initial Programming Activities
TAC (Translator-Assembler-Compiler), which was specified by Philco in early 1958, was designed to be a powerful system that would include library features and would provide compilation of machinelanguage running programs from the symbolic-language output of a variety of problem-oriented language translators. The first version of TAC was written in TAP (TRANSAC Assembly Program) language and assembled in early 1959 on the IBM 704 computer at United Aircraft's Research Department in Hartford, Connecticut.
In July 1958, a conference between United Aircraft and Bettis personnel on programming requirements for preliminary testing of the Philco machine had established that the following items should be prepared:
1. Common-need items:
TAP (704 assembler for TRANSAC-running programs, using TRANSAC mnemonics).
TRANSAC data-loader from paper tape.
TRANSAC output routine to its on-line printer (for use on Serial-l machine only).
704 output routine to column binary TRANSAC machine-language cards, punched on-line.
704 output to the 704's off-line printer in TRANSAC format.
IBM 063 card-to-paper-tape converter control panel. TRANSAC operational-check programs.
Routine to print contents of TRANSAC console on-line.
2. Primarily of interest to United Aircraft:
Peaceman-Rachford solution, two-dimensional heat-flow problem (to demonstrate effect of greater word length).
Systems and Standards Preparations for a New Computer 103
3. Primarily of interest to Bettis:
PDQ (relaxation solution of large diffusion problem) one-group iteration routine only (to demonstrate effective arithmetic speed for large matric problems) .
TAP 1 was essentially a rewritten version of SAP 3-7 (SHARE Assembly Program) ; it uses the variable length mnemonics originally proposed for TAC, but has the basic logical structure of SAP. It was originally created for the purpose of producing TRANSAC test programs, prior to United Aircraft and Bettis decisions to acquire machines. At that time, Philco had not yet completed the prototype TRANSAC punched-card equipment, and thus the usual input medium for programs was punched paper tape. Therefore, TAP was designed to produce, on-line from the 704 computer, punched cards in a meta-code which could be transliterated by the IBM 063 device into punched paper tape, which could then, in turn, be read by the Philco computer. Extract: ALTAC
ALTAC (Algebraic TAC for the Philco 2000)
On April 13-14, 1959, in New York City, the membership of TUG met for the first time. The membership had had a considerable amount of contact with Philco programming effort which was being applied to the TAC compiler. One of the first acts of TUG was to adopt TAC as its official assembly language. Continuing development of TAC has proceeded in an atmosphere of close liaison between Philco programming research personnel and the membership of TUG.
The first of the translators for TAC was named ALTAC (ALgebraic TAC) . This routine accepts FORTRAN II, a widely used algebraic language designed for engineering and scientific problems, as a subset ' of its source language. In addition to the basic FORTRAN algebraic language and TAC symbolic language, ALTAC accepts a number of extensions, including symbolic statement numbers, provision for the writing of compound statements (several short statements separated by semicolons rather than by the restriction that each statement must start on a fresh card), subscripting of subscripts to arbitrary depth, increase of array dimensionality from three to four, and ability to handle mixed statements (statements containing both fixed- and floating-point variables) .
Use of the FORTRAN language provides a publication vehicle by which information can be exchanged between Bettis (and other Philco 2000 installations) and users of other large-scale computers for which the FORTRAN language is available. While more advanced languages intended to be common to many machines have been under development for some time, it is apparent that FORTRAN has become the de facto common scientific programming language. This was underscored recently by the announcement that a FORTRAN I1 compiler is being written for the Univac Larc computer.
If Bettis people were to make use of the full ALTAC language, their work could not be utilized directly by other organizations who are equipped to handle only the basic FORTRAN language; hence, this means of technical communication would be operable in only one direction. After careful consideration, it was concluded that the value of two-way communicability of programs across machine boundaries was a consideration which would be of greater value to Bettis and to Bettis technical professionals than the ALTAC language extensions. For this reason, initial Bettis use of the ALTAC compiler on the Philco 2000 computer was limited to that part of the ALTAC language which constituted FORTRAN 11. It was resolved that efforts would be made through technical societies to obtain general agreement on, and widespread ability to apply, FORTRAN language extensions. Extract: TAPTAC
TAPTAC (704 Assembler for TAC-Language Programs)
Serious TRANSAC programming work by key Bettis progammers was undertaken during April 1959, approximately one year before the Philco 2000 was available at Bettis. Most of the initial program library was to be written in TAC symbolic language.
It was decided that, as a programmer convenience, TAP (the original 704 assembler) should be rewritten entirely to permit use of all of the TAC language, except its library features. The first purpose of this work was merely to obtain assembly listings, in order to permit some program checking prior to the time that the programs (and, in some cases, the programmers) would travel to Philadelphia for assembly and debugging work on the Philco machine. Thus, the error-detection and indication facilities of the assembler were made extensive and convenient, and the routine was released, for internal use, without output facilities.
As the work progressed, it became evident that there would be further convenience in completing the assembly process at Bettis. Thus, the punch-out routine of TAP was rewritten to produce column binary program cards in the format already agreed upon by the membership of TUG. This work was completed about the same time as Philco had made punched-card equipment available for customer use. Thus, the column binary punched card, containing machine-language programs, became the common program communication medium between the two computers. This modified version of TAP became known as TAPTAC.
TAPTAC was certainly not the first assembler which was used to prepare programs for one machine through use of an earlier machine for the assembly process. It may be unique, however, in that a serious effort was made to assure that the source (symbolic) languages for TAPTAC and TAC were really compatible. It was the intention that early symbolic programs, assembled on the 704 after the symbolic decks had been corrected in the debugging process, could be reassembled at a later date using TAC running on the 2000. In order to protect this compatibility, it was necessary to exercise stern control over extensions of TAC language which might otherwise have slipped into TAPTAC. When, as happened on several occasions, experience indicated that extensions to the basic language were desirable, these were carefully negotiated with the membership of TUG and the members of the Philco Programming Research and Development Section. Language changes which were acceptable to all parties were then planned for inclusion into both assemblers. A few subtle incompatibilities did appear. For those which represented significant incompatibility between the two compilers, an effort was made to bring one or both into line with the specifications. In a few cases, which were of minor importance, but which would have required considerable effort to correct, the incompatibilities were permitted to remain. Extract: System Programming Philosophy
System Programming Philosophy
Mindful of difficulties which had been encountered by older user groups in connection with (1) language incompatibilities between parts of different systems, (2) maintaining rectitude with respect to specifications for systems on the part of people working on very large systems, and (3) getting very large systems into operation at all, TUG and Philco resolved to attempt to avoid these troubles.
The means chosen were (1) to unify the language structure around a common symbolic language, TAC, (2) to maintain close liaison between relatively small working groups of programmers, and (3) to make individual sections of large systems independently operable before establishing the connections between sections.
Initial results have been encouraging, in that several of the compound systems planned are now in successful operation (in some cases, only a few months behind schedule!), and that others appear to be going together without prohibitive difficulty. A typical structure is the one now under development at Bettis.
TAC has been in use as a simple assembler for several months. Its library features are used significantly only when TAC assembles for the FORTRAN algebraic translator, ALTAC. Since ALTAC generates many macro and generator calls, in addition to machine-instruction mnemonics, TAC is exercised thoroughly during FORTRAN compilation. For several months, TAC has been producing TUG-format column binary for input to the BKS operator system, but assembly and compilation have been performed under manual control. Within a short time Bettis will be assembling and compiling within BKS? achieving for those processes the efficiency and convenience which are already being enjoyed during production computation and program-debugging runs, thanks to symbolic tape assignment and other features of BKS.
in Proceedings of the 1960 Computer Applications Symposium, Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois view details
in Proceedings of the 1960 Computer Applications Symposium, Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois view details
One of the major aims in the development of universal or common problem-oriented languages has been to permit a user to make the transition from one computer to another without the necessity of a complete reprogramming job.
The ALTAC compiler, compatible with FORTRAN II, has been used to implement such a transition from the IBM 704 to the PHILCO 2000 at a number of installations. To the best of my knowledge this is the first time that a compiler has assumed the major burden of transition from a large scale computer of one manufacturer to an even lar get scale computer of another manufacturer.
The ALTAC compiler has been in operation for over a year now. Although some minor changes in source language programs have been needed, I think it is fair to say that all 704 FORTRAN programs seriously attempted have been run using ALTAC on the PHILCO 2000, In general there is an improvement in speed which is consistent with the extent to which the 2000 is faster than the 704.
There have of course been a number of difficulties encountered in moving programs from 704 to the 2000. Some of these difficulties are of a temporary nature, having to do with the usual problems encountered in introducing a new compiler, and these are not worth mentioning here. Other problems encountered point up the general problem of transition to a new computer by the use of a problem. oriented language. They are discussed here in the hope that they will throw some light on the problems to be faced when other languages such as COBOL and ALGOL are used in similar transitions frome one type of computer to another.
Whenever a compiler has been in use for some time, characteristics of the translator become known to many of the users, and these become in effect part of the language even though they have no official sanction in the language, One example of this is the handling of negative integers in FORTRAN. The language does not actually permit negative integers but something does happen when integer arithmetic is called for in 704 FORTRAN and the result is negative. Something different happens in the same case in ALTAC. ALTAC could have been made compatible in this respects but this would have resulted in slowing down the running of all programs, not just the negligible few that might use this feature.
If compatibility had been the sole object, the slowing down might have been reasonable. However, the stated objective was first to provide a compiler suitable for use with the PHILCO 2000 and its programming systems, and, consistent with this primary objective, to seek as high a degree of compatibility as possible with FORTRAN as it already existed.
ALTAC was designed to make use of the computer-oriented language, TAC, as an intermediate language. In particular both ALTAC and TAC make use of the same subroutine library, and this has proved embarrassing to compatibility in a number of cases. TAC subroutines produce an alarm condition in case of attempts to find the logarithm or a non-integral power of a negative number. FORTRAN on the other hand simply takes the logarithm or the power of the absolute value, Here compatibility can easily be restored, and some customers have done so. Others have indicated that they prefer a more precise mathematical approach even at some sacrifice in the degree of compatibility, A similar situation occurred in relation to division by zero, Here FORTRAN gives the answer zeros and ALTAC, at least in its non-compatible version, gives the largest number that the computer can handle.
ALTAC makes use of a generative input-output system while FORTRAN uses an interpretive system. There are advantages to both, and they are compatible except in connection with extra features that have developed outside the original language. Thus the recently added FORTRAN feature that permits FORMAT statements to be entered at run time depends on the fact that the FORMAT statements are interpreted at run time, In a generative system they are interpreted at compile time. If this one feature proves sufficiently attractive an optional interpretive input-output package may be developed for ALTAC.
Although high speed on-line peripheral equipment is available on the Philco 2000, the organization and speed of the system is such as to make it very inefficient to use an en-line card reader and an on-line printer as they are used in many 704 installations. ALTAC from the beginning has used off-line card to tape for input and off-printing for output. Slight modification has been required in progra which assumed the on-line system, and which, for example, used the fact that the reader had run out of cards as an indication that the end of a data deck had been reached.
The larger range of exponents in the 2000 makes it necessary to provide space for a three digit exponent in printouts using the E conversion. This requires the changing of some FORMAT statementse Here again compatibility can be regained by limiting the range of numbers actually used on the 200Op but most users have preferred to use the full range of exponents available even if some slight changes in source programs were necessary.
The experience with ALTAC leads to the conclusion that it is practical to achieve a very high level of compatibility between two computers by the use of an algebraic compiler. It is to be expected that those who are attempting to provide compatibility with much more complicated data-processing languages between radically different machines will find much greater difficulties
in Proceedings of the 16th ACM National Conference, January 1961 view details
in [ACM] CACM 4(01) (Jan 1961) view details
in [ACM] CACM 4(01) (Jan 1961) view details
in [ACM] CACM 4(01) (Jan 1961) view details
in [ACM] CACM 11(08) (August 1968) view details
in [ACM] CACM 11(08) (August 1968) view details
in [ACM] CACM 15(06) (June 1972) view details
in Computers & Automation 21(6B), 30 Aug 1972 view details