EGTRAN(ID:3778/egt001)


for EGdon forTRAN, Dialect of FORTRAN II for the KDF9 system.

Hardware:
  • KDF9 English Electric-Leo-Marconi

Related languages
EGDON => EGTRAN   Subsystem
FORTRAN II => EGTRAN   Dialect of
RLB => EGTRAN   Target language for

References:
  • Burns, D; Hawkins, EN; Judd, DR and Venn, JL "The Egdon system for the KDF9" view details Abstract: The Egdon system for the KDF9
    D Burns, EN Hawkins, DR Judd and JL Venn

    English Electric-Leo-Marconi Computers Ltd., Kidsgrove, Stoke-on-Trent, UK


    An operating system based on the use of high-level languages and on the use of a discfile for program storage is described. The use of the discfile and the fact that only a small fraction of a program has to be recompiled when an error is corrected means that a very quick turnround is provided to users.
    Extract: General information
    The system is of a general type which though common in the U.S., is almost unknown to British manufacturers. Its main features may be summarized as follows:
    1.  Its unit of compilation is not the complete program but the routine.
    2.  It deals with a mixture of source languages.
    3.  It makes extensive use of a discfile for program storage.
    4.  Although it does not use conventional time-sharing it buffers input and output by the use of "pseudo-off-line" card reading, card punching, and printing.

    The first of these features, the independent compilation of routines, is of great value in handling large programs. Each individual routine is compiled, not to its final "absolute binary" form but to "relocatable binary" (RLE), a partially compiled form in which the addresses of core locations have not yet been filled in and which can therefore be adapted to be obeyed from any position in the core store. Before a program is executed, the routines which compose it are assembled together and "relocated," i.e. their absolute addresses are filled in. The advantage of doing things this way is that if a small amendment is to be made to a program, only the routine which is to be amended has to be recompiled from the source language. The routines which have not changed are merely "relocated" as usual, which is much quicker than compilation.

    Independent compilation is intimately associated with card input because if paper tape is the basic input medium, it is almost essential (because of the difficulty of amending paper tape) to hold a copy of the program in the system so that it can be updated regularly. Since it is undesirable to hold a program in both source language and RLE, the RLB is usually omitted and programs are compiled completely from source language each time they are executed. With cards no such difficulty exists. It is a simple matter to amend card packs, so the source language exists only on cards and the system merely holds the RLB form of a program. When an amendment is made a complete routine is input afresh from cards.

    With regard to point 2, the mixing of source languages, these are at the moment EGTRAN (a dialect of FORTRAN II) and KDF9 User-code. ALGOL may be added later. Any given routine must be written in one and only one of the source languages, but EGTRAN routines may be freely interspersed with User-code routines. Both source languages are compiled to RLB, which serves as an interface language.
    Extract: The compilers
    The compilers
    Two compilers were written specially for the Egdon system, a FORTRAN (EGTRAN) compiler and a User-code compiler. Both operate entirely in the core store, i.e. they are one-pass compilers, and both compile one routine at a time. The routines are subsequently read back and bound into a complete program by a system program called the Relocator. Relocator also carries out some optimization of FORTRAN routines in the light of extra information which is available at relocate time which was not available at compile time.

    The FORTRAN compiler compiles from a dialect of FORTRAN II called EGTRAN which is not appropriate to discuss at length here. All the usual facilities of FORTRAN II are included, together with certain additional facilities peculiar to EGTRAN. In particular the following may be noted:
    (1)  A facility for varying the dimensions of arrays at run time without sacrificing the optimization of subscripts.
    (2)  Recursive functions and subroutines, with preservation of the values of variables between recursions if required.
    (3)  Some additional statements for transferring whole arrays to or from disc or magnetic tape, rather than the normal FORTRAN "list" of variables. This makes it possible to make transfers proceed simultaneously with each other and with central processor calculations, which cannot be done (except to a very limited extent) with "list" type statements because of the need for store protection.
    The User-code compiler or assembler accepts a punched card version of ordinary KDF9 User-code. Its output takes the form of relocatable binary routines which are completely interchangeable with those produced by the EGTRAN compiler.

          in The Computer Journal 8(4) 1965 view details
    Resources
    • Paul Mather: a USENET memory of EGTRAN
      I remember using what I think must have been the first British Fortran
      compiler back in the mid 1960s (Egtran, from the Atomic Energy Authority at
      Winfrith, Dorset). It was Fortran II basically. I also remember spending
      days trying to work out why a KDF9 thought that 1+1=99. I had done exactly
      what you have done here, and I discovered rule number one: always store
      scalar subroutine arguments within the subroutine as local scalars, unless
      you explicitly wish to modify them. Rule number 2 is: there are no rules.

      Paul Mather
      external link