Usercode(ID:2934/use003)

Autocode for the KDF9  


Autocode for the KDF9

Also one of the EGDON programming system, with the RLB as a target language.

Hardware:
  • KDF9 English Electric-Leo-Marconi

Related languages
GEORGE => Usercode   Strong, Influence
Mercury Autocode => Usercode   Evolution of
RLB => Usercode   Target language for
Usercode => IMP   Strong Influence

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
  • [ICL] KDF9 programming manual 1970 view details
          in The Computer Journal 8(4) 1965 view details
  • Stock, Karl F. "A listing of some programming languages and their users" in RZ-Informationen. Graz: Rechenzentrum Graz 1971 275 view details Abstract: 321 Programmiersprachen mit Angabe der Computer-Hersteller, auf deren Anlagen die entsprechenden Sprachen verwendet werden kennen. Register der 74 Computer-Firmen; Reihenfolge der Programmiersprachen nach der Anzahl der Herstellerfirmen, auf deren Anlagen die Sprache implementiert ist; Reihenfolge der Herstellerfirmen nach der Anzahl der verwendeten Programmiersprachen.

    [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know.  Register of the 74 computer companies;  Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented;  Sequence of the manufacturing firms after the number of used programming languages.]
          in The Computer Journal 8(4) 1965 view details
  • Wells, M., Holdsworth, D. and McCann, A. P., "The Eldon 2 operating system for KDF9." pp21 - 24. view details Extract: Compilers for KDF9
    The compilers available were for Usercode and ALGOL.
    Usercode is an assembly language with good mnemonics
    for operations, but very limited addressing techniques. For
    ALGOL two compatible compilers were available. The
    'Whetstone' system (Randell and Russell, 1964) offers
    excellent diagnostic facilities; compilation is extremely fast,
    but the subsequent interpretation is slow. The 'Kidsgrove'
    system (Hawkins and Huxtable, 1963) is an optimising
    compiler, with long compilation times, and rather limited
    diagnostics, but producing a fairly efficient object code.
    No compiler allowed library insertion at compile time;
    instead each text file contained a copy of any library
    material, inserted when the file was created.
          in The Computer Journal 14(1) 1971 view details
  • Stock, Marylene and Stock, Karl F. "Bibliography of Programming Languages: Books, User Manuals and Articles from PLANKALKUL to PL/I" Verlag Dokumentation, Pullach/Munchen 1973 639 view details Abstract: PREFACE  AND  INTRODUCTION
    The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one.

    There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages.

    The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM.

    Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) .

    It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers.

    The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA).
    As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found.

    It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel.

    We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work.

    Graz / Austria, May, 1973
          in The Computer Journal 14(1) 1971 view details
    Resources
    • Atlas Autocode Compiler for KDF9 - Version K - Syntax
      external link
    • Technology in Australia 1788-1988 - Concentration on large-scale systems, 1958 to 1963 (continued) page 593
      On two occasions Australian developments had impact upon overseas computer design. The first was the idea of the 'recursive stack' which developed from the proposal for a machine made by C. L. Hamblin (Hamblin, C. L., 1957a, 1957b) on the basis of the Reverse Polish notation of Lukasiewicz (1920) and first implemented on the UTECOM as the GEORGE programming system (Hamblin, C. L., 1960). This was to be taken up by the English Electric Company in its multi-programmed KDF9 system, which was given two hardware register stacks. The second was the apparent effect that the Cirrus design had upon the Canadian Ferranti FP 6000 and its carry-over into the ICL 1900 series (when Ferranti and ICT merged to form ICL). external link