TAP(ID:3249/tap002)

TRANSAC symbolic assembler 

for TRANSAC Assembly Programming

Symbolic assembler for the TRANSAC, based on SHARE's SAP and was written by Roy Nutt of United Aircraft and then subsequently was debugged by UA and Bettis personnel.

It was the target language for ALTAC (Philco enhanced FORTRAN II) and TAC

Significantly, TAP, TAC and ALTAC were a product of the TUG (TRANSAC Users' Group)
Related languages
SAP II => TAP   Implementation of
TAP => TAC   Targetting
TAP => TAPTAC   Evolution of
References:
  • Bright, Herbert S. "Systems and Standards Preparations for a New Computer (Philco 2000)" view details Extract: Initial Programming Activities
    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