TAC(ID:2550/tac001)
TRANSAC Assembler Compiler
TRANSAC Assembler Compiler. For Philco 2000.
Hardware:
- Philco 2000 Philco
Related languages
| TAP | => | TAC | Targetting | |
| TAC | => | ALTAC | Written using | |
| TAC | => | ALTRAN | Translator for | |
| TAC | => | TALL | Written using |
References:
One of the traditional deficiencies of an assembly program has been the necessity to write in a language similar to that used for machine instructions. There are large areas of programming that use standard routines with different parameters and linkages. The use of a computer-instruction format makes the expression of these parameters and ]inkages more or less inconvenient, hence prone to error. The incorporation of macro-instructions and generators into the TRANSAC Assembler-Compiler (TAC) System provides the ability to use a language that is more problem-oriented.
Input to the generators may be any type of pseudo-code within very broad limits. Output in the form of generated coding may be any type acceptable to TAC, Usually it will be symbolic computer languages but it may contain macro-instruction calls, subroutine calls, and even more generator pseudo-codeo There is no limit to the leve]s of nesting of generators. The handling of macro-instructions will be described elsewhere so that we will discuss generators only. Generators may be added, removed, or changed at the option of the using installation. Certain basic ones are supplied with the TAC system, but a primary goal of design for TAC has been flexibility. For this reason, a general system of handling generators has been developed.
The pseudo-code used by the generator can be of whatever form the generator writer wishes, except that the command field must be a unique identification. The purpose of this identification is to enable TAC to recognize that this is a generator statement and hence to handle it as such. The information actually used by the generator is in the rest of the card and succeeding cards if needed, This allows the development and use of problem-oriented languages. Because of the flexibility of generators, the power of TAC can be increased as needed,
During the first phase of TAC, an examination is made of the command field. If it contains a machine command, macro-instructions subroutine call, or error, appropriate action is taken. If it is a generator call, however, control is turned over to a separate section of TAC, which collects the pseudo, code and stores it upon an intermediate tape, Various other pieces of control information are also appended to the pseudo-code, These are for the use of either the Executive Generator or the using generator, The Executive Generator is that section of TAC which controls the using generators, handles their input/outputs and provides the linkage back to TAC, A decision is made whether to produce a restricted amount of coding at this point and control is turned back to TAC after such coding, if any, has been processed.
During the first pass of TAC an indicator is set if any generators are used. At the end of the first pass this indicator is examined by TAC, and if it has been set, the Executive Generator is called in. Control is then turned over to the Executive Generator which sorts the pseudo-code statements from the intermediate tape so that all statements referring to a specific generator are available together. All generation is done after the first pass has examined the input coding and before the second passe a system known as deferred generation.
After sorting the pseudo-code, the proper using generator is read-in. The Executive Generator handles all input/output including overlays occurring in the using generator itself . The Executive Generator supplies pseudo-code and accepts generated coding. This coding is stored upon an intermediate tape. After all the statements have been converted to generated coding, control is returned to the first pass of TAC. This now accepts the intermediate tape containing generated code as an input tape for an extension of the first pass. This means that any coding acceptable to the original first pass can be handled by this extension. This permits generators to use generators or any other feature of TAC.
The Input/Output Programming System (IOPS) is an example of the type of generator accepted by TAC. IOPS provides for the complete statement of input, outputs conversions, and controls in pseudo-code. Traditionally, this has been one of the most complex programming areas. The use of statements rather than machine language to describe the problem makes the system much easier to learn and handle. IOPS is intended to handle all inputs output, and conversions for paper tapes punched cards, printer, and magnetic tape used off-line. Magnetic tape used only for intermediate results, with no conversions desired, can be handled also. However, it is more efficient to handle intermediate magnetic tape with macro-instructions. IOPS is the input/output system used by the TRANSAC Algebraic Language Compiler (ALTAC). Thus, the same input/output system is used on both the assembler and compiler levels. Input to IOPS consists of three types of statements - control, orders and format. Control statements specify information to IOPS and execute instructions based upon the TRANSAC hardware configuration, Order statements execute instructions based upon the logic of the program but are independent of the hardware. Format statements specify information concerning the arrangement of data and the types, of conversions desired, An example of a control statement is IOUNITS which describes necessary information about every input/output unit used by I@PS. READ is an example of an order statement. It specifies what unit to read and where the data is stored in main memory, FORMIN is an example of a format statement. It specifies the form of input data. We want to make clear that IOUNITS, READ, and FORMIN are the identification in the command field only, There is a comp]ete pseudo-code statement accompanying each.
There are several advantages to be gained by using generators. First, it permits the use of more descriptive language. By describing the problem in terms more natural to the users fewer errors are introduced. Seconds generators supply only the coding actually needed. There is no need to handle coding that is never executed, Thirds the ratio of coding produced in relation to the amount of input is quite large. This means that standard pieces of coding are being produced by the generators rather than by the programmer recoding the same job over and over again with different parameters. These facto s combine to make check-out much faster and easier . Generators have proved very useful as an integral part of TAC,
in SESSION: Automatic programming: from the manufacturers view details
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
TRANSAC S-2000 digital computer.
The TRANSAC Assembler-Compiler, called TAC, was written for the TRANSAC characteristics which affect the Binary computer compiler are:
48-bits per word.
Two instructions per word.
Single address instruction.
Magnetic core from 4096 to 32768 words in size.
Eight to 32 index registers available.
Parallel input-output and processing.
0n-line or off-line high speed printing.
Two's complement arithmetic.
TAC is a machine-oriented compiler and has all of the standard assembly features. In addition; it has many compiling features; and it was designed to be an intermediate language for problem-oriented compilers and generators. TAC is a "two-pass" compiler. It has a library of subroutines available for automatic call, and the user can supply auxiliary libraries if desired, TAC language consists of one instruction or constant per line of coding. Instructions may be machine commands; subroutine, macro; or generator calls; or control instructions. A line of coding is divided into five columns: identity and sequence; label; location; command; and address. The first four columns are fixed in size. The address column is variable in length.
A TAC constant consists of one to 48 fields. Each field is tagged by its designator 9 and a constant is compi]ed by converting the fie]ds from ]eft to right. Fie]d size is determined by the right boundary of the previous field and by a termination indicator, which is written with the field. There is no field overflow. Field designations available are: decimal floating point and fixed point; decima] integer; two types of a]phanumeric; octal; hexadecimal; binary; and three types of floating address fields, The decimal and floating point fields are full word in length.
Constants may be stored in the body of the compiled program by writing the constant starting in the command column at the point it is to be stored relative to the rest of the program, Constants may also be collected and stored automatically by TAC in a constant pool. Any constant which is written starting in the address colum% or which is written in the cbmmand column with the label "P" in the label colum; is stored in the constant pool. In general~ constants are not duplicated in the constant pool. This feature of pool constants in TAC permits easy writing of instructions involving constants as operands or parameters.
In order to combine programs easily, TAC requires each program to be named. This name is appended to each floating address appearing in the program. Reference to any location in the program from outside must be by name as well as by flqating address. Floating addresses may thus be duplicated in programs which are to be combined without causing double assignment. A location may also bo made common to several combined program% by labeling the location with the letter "C".
Pre-set parameters can be assigned values by use of a special control instruct±on~ and a floating address can be made equal to another by use of another control instruction. These values may not only be fixed for the entire range of the program: but also for a limited range by designating in the label column the start and end of the range.
Automatic assignment of blocks of data storage is made by TAC when it encounters the proper control instruction. A!so~ floating addresses which are never specifically assigned values by the programmer are considered to be temporaries and are automatically assigned values by TAC.
TAC provides for the automatic call of subroutines. The programmer writes the name of the subroutine in the command column and the parameters in the address column. The necessary instructions to store the parameters and transfer controT to the subroutine are generated. The subroutine is automatically stored J~off-side '~ and is not duplicated. Macros may be called by the TAC programmer. Macros are short series of instructions which are inserted in the body of the program where called.
The parameters of the macro are automatically imbedded in the macro at the time of compilation. Generators may also be called, and the call produces a transfer-of-control order at the point of call. The generated instructions are stored off-side ; each call on a generator produces coding. The first pass of the compiler produces an intermediate output called the "relative code", and the floating address directory. The second pass performs the final assembly and produces a running program in absolute machine language. A parallel listing of the original and final program is also put out by the second pass.
The system used for operating on the Running program has been called the "TRANSAC Operational-Programming Systmem" or "TOPS". TOPS contains several debugging features and service routines, The progrmmer may insert any of the standard debugging routines available into his program. This is accomplished by the use of "input control words", interpreted at the time of input of the running program.
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
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 6(03) (Mar 1963) view details
in [ACM] CACM 6(03) (Mar 1963) view details
An important step in artificial language development centered around the
idea that i t is desirable to be able to exchange computer programs between
different computer labs or at least between programmers on a universal level.
In 1958, after much work, a committee representing an active European computer
organization, GAMM, and a United States computer organization, ACNI,
published a report (updated two years later) on an algebraic language called
ALGOL. The language was designed to be a vehicle for expressing the processes
of scientific and engineering calculations of numerical analysis. Equal stress was
placed on man-to-man and man-to-machine communication. It attempts to
specify a language which included those features of algebraic languages on
which it was reasonable to expect a wide range of agreement, and to obtain a
language that is technically sound. In this respect, ALGOL Set an important
precedent in language definition by presenting a rigorous definition of its syntax.
ALGOL compilers have also been written for many different computers.
It is very popular among university and mathematically oriented computer
people especially in Western Europe. For some time in the United States, it will
remain second to FORTRAN, with FORTRAN becoming more and more like
ALGOL.
The largest user of data-processing equipment is the United States Government.
Prodded in Part by a recognition of the tremendous programming investment
and in part by the suggestion that a common language would result only
if an active Sponsor supported it, the Defense Department brought together
representatives of the major manufacturers and Users of data-processing equipment
to discuss the problems associated with the lack of standard programming
languages in the data processing area. This was the start of the conference on
Data Systems Languages that went on to produce COBOL, the common business-
oriented language. COBOL is a subset of normal English suitable for expressing
the solution to business data processing problems. The language is
now implemented in various forms on every commercial computer.
In addition to popular languages like FORTRAN and ALGOL, we have
some languages used perhaps by only one computing group such as FLOCO,
IVY, MADCAP and COLASL; languages intended for student problems, a
sophisticated one like MAD, others like BALGOL, CORC, PUFFT and various
versions of university implemented ALGOL compilers; business languages in addition
to COBOL like FACT, COMTRAN and UNICODE; assembly (machine)
languages for every computer such as FAP, TAC, USE, COMPASS; languages to simplify problem solving in "artificial intelligence," such as the so-called list
processing languages IPL V, LISP 1.5, SLIP and a more recent one NU SPEAK;
string manipulation languages to simplify the manipulation of symbols rather
than numeric data like COMIT, SHADOW and SNOBOL; languages for
command and control problems like JOVIAL and NELIAC; languages to simplify
doing symbolic algebra by computer such as ALPAK and FORMAC;
a proposed new programming language tentatively titled NPL; and many,
many, more. A veritable tower of BABEL!
in [ACM] CACM 6(03) (Mar 1963) view details
in [ACM] CACM 15(06) (June 1972) view details