EARLY PROGRAMMING ACTIVITY

AT THE UNIVERSITY OF CAMBRIDGE

(FIRST DRAFT)

M. Campbell-Kelly March, 1978 Department of Maths.and Computer Studies Sundetland Polytechnic England

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk EARLY PROGRAMMING ACTIVITY AT THE UNIVERSITY OF CAMBRIDGE

1. INTRODUCTION

1.1 The EDSAC 1.2 People 1. 3 Sources.

2. DEVELOPMENT OF PROGRAMMING TECHNIQUES

2.1 The EDSAC order code and numbers 2.2 The initial orders - first form 2.3 The co-ordinating orders 2.4 The initial orders - second form 2.5 Sub-routines 2.6 The sub-routine library.

3. A TUTORIAL ON ED SAC PROGRAMMING

3.1 The TPK algorithm 3.2 The TPK algorithm for EDSAC 3.3 Punching and running 3.4 Getting programmes right (part one).

4. FURTHER DEVELOPMENT OF PROGRAMMING TECHNIQUES

4 .1 Getting programmes right (part two) 4.2 Sub-routine assembly, floating addresses and synthetic orders 4.3 Interpretive schemes.

5. CONCLUSIONS

Acknowledgements (omitted)

References

Figures

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, -1- Centre for Computing History, Cambridge www.computinghistory.org.uk 1. INTRODUCTION

In the spring of 1949 the first two practical stored program computers came into operation : the EDSAC at Cambridge and MADM at Manchester University. The approach to the problem of programming differed considerably at the two centres. The subject of this paper is early programning activity at Cambridge; an account of progranming activity at Manchester will be the subject of a future paper.

From the outset, M.V. Wilkes at Cambridge saw that the only acceptable way to write programs was in a form using mnemonic codes and decimal addresses which could easily be used by the human programmer. On the other hand A.M. Turing at Manchester saw no need to make such concessions and forced MADM progra.mners to write each computer instruction as a sequence of four teleprinter characters in base-32-backwards.

In the early fifties John W. Carr III aptly characterised the prevailing attitudes to program:ning by dividing programmers into two groups : first the 'primitives' who believed programs should' be written in octal or hexadecimal or even base-32-backwards; second were the 'space cadets' who believed in human oriented codes and letting the machine do the translating. (Wilkes, 1967}.

There is no question that in 1949 the Manchester school were the primitives and the Cambridge group the space cadets.

CMLEO/DC/RC/197803

David Caminer Papers -2- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 1, I The EDSAC

The background to EDSAC has been entertainingly described in Wilkes 75, Mutch 69 and elsewhere, so that only a brief summary will be given here.

EDSAC was patterned very directly on the EDVAC first described in von Neumann's 'First Draft of a Report on the EDVAC', June 1945. In July and August of 1946 an influential series of lectures on EDVAC were held at the Moore School of Electrical Engineering in the University of Pennsylvania, the latter part of which was attended by M,V. Wilkes, Director of the University Mathematical Laboratory (now Computer Laboratory) at Cambridge.

Wilkes began work on the design of EDSAC in late 1946 and construction began in early 1947. EDSAC performed its first fully automatic computation on the 6th May 1949, although it was not capable of serious work until sometime later. EDSAC made its debut to the outside world at the Cambridge computer conference held in June 1949,

EDSAC provided a regular computing service from early 1950 and was remarkable for the extent to which it was used by other departments in the University from a very early date. By the mid­ fifties literally dozens of papers had been published based on results obtained using EDSAC, some of them authored by Cambridge's leading men of science. EDSAC prOvided a regular computing service, apart from occasional periods of shut down for re-engineering, until it was dismantled in July 1958.

CMLEO/DC/RC/197803

David Caminer Papers -3- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 1.2 People

The most eminent of the people associated with EDSAC was D-.R. Hartree, Plummer Professor of Mathematical Physics. However, his role was mainly one of encouragement and lending his prestige to the project.

The driving force behind EDSAC, and its principal designer, was M. V. Wilkes. Prior to the outbreak of war, Wilkes had been involved with the differential analyser in the University Mathematical Laboratory and his war years were spent working on radar and operational research. Thus, on his return to Cambridge in 1945, Wilkes was well versed in the twin disciplines of mathematics and electronics. Wilkes built up a talented team of people to work under his direction; indeed, a list of the names of the people who began their early careers with EDSAC would account for a sizeable proportion of the top level of the British academic h~ rarchy in computer science.

A list of the people associated with the early programming activity at Cambridge appears in the preface of Wilkes, Wheeler and Gill, 1951. Unfortunately it is not possible to single out everyone's individual contribution at this distance in time, although wherever possible this will be done. Unquestionably though, apart from Wilkes, the two leading spirits in the programning activity were D.J. Wheeler and S. Gill.

D.J. Wheeler became a research student under the supervision of Wilkes in October 1948. Wheeler did brilliant work and was responsible for the input routine on EDSAC, developing the nucleus of the sub-routine library and much besides. He left Cambridge in 1951 to become Visiting Assistant Professor at the University of Illinois for a period of two years, subsequently returning to spend the remainder of his career to date at Cambridge.

CMLEO/DC/RC/197803

David Caminer Papers -4- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk S. Gill became a research student under Wilkes in October 1949, coming from the National Physical Laboratory where he had worked under Turing. Gill was responsible for developing checking (trace) subroutines, an interpretive floating point scheme and made important contributions to the subroutine library. Gill left Cambridge in 1954 to follow Wheeler as Visiting Assistant Professor at the University of Illinois, and did not subsequently return to Cambridge.

An early contributor to 'the programming effort was R.A. Brooker who originally joined the University Mathematical Laboratory to work on the differential analyser in October 1949, but transferred his interest to EDSAC early in 1950 with the encouragement of Wilkes. Brooker' s most important contribution was an impressive interpretive floating point scheme developed in collaboration with Wheeler. Brooker left Cambridge in Sept 1951 to join Manchester University.

J.M. Bennett, an engineering research student under Wilkes, did early work on interpretive sub-routines. K.N. Dodd and A. E. Glennie were seconded from the Armaments Research Establishment from December 1949 for a period of several months and made substantial contributions to the early development of the sub-routine library. Other names mentioned in the preface of Wilkes, Wheeler and Gill were : B. Noble, J.P. Stanley, B,H. Worsley, L.A.G. Dresel, E.E.C. McKee and C.M. Munford. Perhaps to this list we should add the names of the slightly later contributors : A.S. Douglas, B. Hazelgrove and P. Naur.

Another important figure was E.N. Mutch who was little concerned with progrannning directly, but was responsible for documentation of the sub-routine library, the preparation of programming bulletins and th~ day to day operation of EDSAC. Mutch' s careful documentation has been one of the most useful sources of information in preparing this account.

CMLEO/DC/RC/197803

David Caminer Papers -5- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 1.3 ~

In addition to the open literature (see references) a number of unpublished or little known sources have been used in preparing this paper.

Probably the earliest extant document on EDSAC is a report produced in May 1948 (UML, 1948). This report gives the logical design of EDSAC as it was seen at that time, and is somewhat different in detail to the machine which was eventually constructed. The report was not circulated outside the laboratory.

An important e•rly publication is the Proceedings of the first European computer conference held at Cambridge in June 1949 (UML, 1949). These proceedings give an interesting glimpse of the period imnediately after the construction of EDSAC but before the programming techniques had been finalised. This publication has been difficult to obtain but is presently being reprinted by the Computer Laboratory at Cambridge.

The earliest systematic account of the progranming techniques developed at Cambridge is a spirit duplicated "Report on the preparation of programmes for the EDSAC and the use of the library of sub-routines" dated September 1950 (UML, 1950). The report had a limited private circulation outside Cambridge. In due course Wilkes arranged with Addison-Wesley to publish the report in book form.

The book, 'The Preparation of Programmes for an Electronic Digital Computer', (Wilkes, Wheeler and Gill, 1951) as far as is known was the first text book on programming. The book was essentially the same as the September 1950 report with the addition of a preface (dated March 1951) and a foreword by Hartree. The book was very influential and did much to spread the gospel of symbolic coding and the sub-routine library as the basis of programming. Over half of Wilkes, Wheeler and Gill consists of specifications and programmes of specimen sub-routines from the library.

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 'l'o

A supplement to Wilkes, Wheeler and Gill was issued in September 1954 and again in September 1955 to keep programmers abreast of the engineering enhancements to EDSAC (eg, the addition of an index register) and additions to the order code; the supplement also contained programming examples given at the annual sunmer schools in Progranme Design held from July 1951 onwards.

A second edition of Wilkes, Wheeler and Gill was published late in 1957 (preface dated August 1957). However it added little to the first edition and lacked its punch. In a review R.W. Hamming seemed to regard the book as a little anachronistic (Hamming, 1958), although C. Strachey was more enthusiastic in his review (Strachey, 1959),

Under the editorship of Mutch a series of spirit duplicated Programming Bulletins were issued periodically from March 1950; after issue 5 the title was changed to Operating Memorandum. There is an incomplete set of these in the Computer Laboratory library, and they give details and dates of new programming techniques, machine operations and engineering enhancements to EDSAC. Mutch was also responsible for documentation of the sub-routine library, almost all of which survives in the Computing Laboratory library.

-7-

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk Wheeler and Gill both prepared Ph.D. theses (Wheeler, 1951 and Gill, 1952) on their work with EDSAC which gave a little of the background to their activities. A report was prepared by Dodd and Glennie following theiJperiod of secondment to Cambridge which describes programning on EDSAC, particularly for the solution of partial differential equations (Dodd and Glennie, 1951); however, their work, which was connected with atomic weapons research was very hush-hush, and so the report is a little vague on specific details of problems solved .

The author has also interviewed Wheeler, Brooker and Glennie at length concerning their early program:ning activity, which has proved most helpful in preparing this paper.

An unusual and revealing source is a short colour film of EDSAC made in 1951 for the Joint Computer Conference, December 1951. The film shows the various stages in preparing a problem for EDSAC and includes shots of the programme actually running on the machine. The film, probably the first of a stored program computer, was originally silent but has recently been re-issued by the Computer Laboratory with an added commentary by Wilkes. A number of stills from the film are reproduced in Wilkes, 1975.

-8-

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 2, DEVELOPMENT OF PROGRAMMING TECHNIQUES

As soon as EDSAC became operational in May 1949, work began in earnest on the development of an input routine and the sub-routine library. The work was undertaken with remarkable speed and decisiveness so that by the end of 1949 the foundations had been laid for a system of programming which served EDSAC throughout its life.

CMLEO/DC/RC/197803

David Caminer Papers -9- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 2.1 The EDSAC order code and numbers

The order code and storage of numbers for EDSAC are completely described in Wilkes, Wheeler and Gill, 1951, but a partial account is given here to make the paper self-contained.

So far as possible terminology and spelling will be the same as that used at Cambridge during the period of interest, although this is not always possible where meanings have changed or where it would seem pedantic not to use a good modern alternative (for example, bits will be used instead of binary digits). However, the spelling of 'programme' and the hyphen in sub-routine will be retained in order to be in keeping with the period.

An EDSAC ~• or instruction. occupied 17 bits as in Figure 1. The 5-bit function code specified one of (in 1949) eighteen operations; this number was later increased as new orders were added to the repetoire of EDSAC. The 10-bit address allowed addressing of 1024 words of storage, although only 512 words were provided initially which was increased to 864 words during 1952. The choice of a single address instruction code was primarily made to minimize the logical complexity of EDSAC. Most orders could operate on short numbers (occupying one storage location) or long numbers (occupying two locations); the length indicator digit specified which. A long number could hold a fraction to a precision of about eleven decimal digits. The spare digit was not used at first, although very much later, from 1955 when an index register was added to EDSAC, it was used to specify modification of the address.

The operation codes were represented by letters of the alphabet, some of which suggested the function they denoted. Table 1 gives a selection of the orders which will be used in this paper; other orders included left and right shift orders, collate (logical AND), input and so on. The instruction set of the EDSAC was very sparse by todays standards. For example, while there was an E-order to transfer control if the accumulator was positive or zero and a G-order to transfer control if negative, at first there was no CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk unconditional transfer instruction nor a zero-test instruction. This meant that it was always necessary to know the sign of the accumulator if an unconditional transfer was required (or use an E-order and a G-order). Similarly, to test two numbers for equality required seven orders: in practice, however, this caused little real hardship for it was usually possible to avoid comparing numbers for equality. Unconditional and zero-test transfer orders were eventually provided, but the initial choice of the E and G orders was a good one.

Average order times for EDSAC were about l.4ms and 5.4ms for multiply. In commom with most early computers EDSAC did not have a divide order, and programmed division took about 200ms. Input and output order times were determined by the speeds of the input­ output devices themselves, initially an electro-mechanical tape reader and a teleprinter both operating at 62 / characters per 3 second. The tape reader was replaced by an improved version operating at about 16 eh/sec in October 1949, and that in turn was replaced by a photo-electric device operating_at about 50ch/sec early in 1950. An output tape punch operating at 16ch/sec was provided as an alternative to the teleprinter in 1951, and the latter was eventually removed altogether as it was rarely used, output tapes being printed off-line.

There was a complication of EDSAC which needs to be explained here. The true word length of EDSAC was actually 18 bits, but it simplified the engineering if the leading bit was ignored in orders and short numbers. However when dealing with long numbers, which occupied t"'10 consecutive storage locations, the extra bit lying between the two halves of the number was used and became known as the sandwich digit.

-11- CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 2,2 The initial orders - first form

The method of getting a program into EDSAC was circum1cribed somewhat by the choice of paper tape as an input medium and the fact that one order read one character. This meant that a small input routine had to be available inside the machine to read in a progranme. (This problem riid not arise on other machines, such as the Pilot ACE, which had Hollerith card input; here by bootstrapping one card into the machine several instructions could be placed in the store.)

The need for an input routine is stated explicitly in May 1948 (UML, 1948), where it is proposed that the input process be carried out in two stages, because the number of orders is seen as being rather large. First a set of 'initial input' orders pre-wired on uniselectors (telephone stepping switches) would automatically be placed in store by pressing the start button. Control would then pass to the initial input orders which would read in the second part of the input routine, known as the 'synthesis orders'. It is even recognised that programners might wish to adapt the synthesis orders to their own needs, thus providing for a variety of symbolic input routines.

Although no specific details of the input routine are given in this document it is quite clear from the complication of the input arra~gements that translation from a symbolic external form to the internal binary form is envisaged. It is also clear that the initial input orders themselves would be fairly sophisticated s ince the same document specifies that two uniselector banks each capable of holding 25 orders would be needed, a single bank being insufficient for the purpose. (An input routine to read in a binary programme could have been acconmodated in nine instructions.)

-12-

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk A set of initial orders were written by Wilkes probably in the summer of 1948. Wheeler joined the EDSAC team in October 1948, and his memory is that these initial orders would not have actually worked due to a programming error and that he rewrote them. In February 1949 some fairly specific details of the form of symbolic instructions are given in Wilkes, 1949: namely the use of a single letter to represent the function code and a decimal number for the address.

Wheeler's initial orders were used from the earliest days of the machine, including during its commissioning. The initial orders were certainly used on tµe 6th May 1949 to input the programme when EDSAC performed its first fully automatic computation. The printout from this historic programme, written by Wheeler, is preserved in the Science Museum, London. For a 'first' programne it is unusually sophisticated in that the output of the programme, a table of squares, is in decimal and neatly tabulated. This added considerably to the complexity of the programme. The same initial orders were also in use on the 22nd June 1949 when EDSAC made its debut at the computer conference held at Cambridge. Two demonstration programmes were written by Wheeler for the occassion: the· first printed a table of squares and first differences and the second printed a table of prime numbers. The latter programme was designed to show how EDSAC slowed down as the interval between printing successive primes lengthened. The complete demonstration ia described in Worsley, 1949.

The initial orders consisted of thirty-two instructions wired onto the uniselectors. Theseinstructions were placed in locations 0-31 when the start button was pressed; th~y them proceeded to load the programme into location 32 onwards, at the rate of about li orders per second. Figure 2 shows how a fragment of programme for the first form of the initial orders might have looked: it replaces the long number in location 8 by its absolute value; it is assumed that the orders occupy location 100 onwards.

CMLEO/DC/RC/197803

David Caminer Papers -13- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk At a fir ■ t glance this looks strikingly like an assembly program for a muoh later period, although this is slightly misleading for this is the written form of the programme rather than the form in which it was punched. In particular there was no provision for comments in EDSAC so that only the parts between the vertical rules were punched. In fact comments were never thought of, and even if they had, they would have been dismissed out of hand when the tape 2 there reader only operated at 6 / 3 characters per second. Similarly were no layout characters and so the fragment of program in Figure 2 would have been punched TLA8LE106SS8LS8LT8L. This made programme tapes physically extremely short but it was not possible to list them (although a utility was provided for this purpose much later, but was rarely used as it was rather extravagant in machine time due to the slowness of the output).

The symbolic instruction consisted of a single letter for the function code, a decimal address (omitted if zero) and Sor L depending on whether the operation was performed Qn a short or a long number. The letter for the function code was not actually translated by the initial orders; the keypunch had been modified so that striking the A-key, for example, produced a 5~bit teleprinter code having the same bit pattern as the function code for the Add instruction, and similarly for the other instructions. Not every function code letter could be mnemonic, for example Z was used for the 'stop' instruction. The translation of the decimal address involved a routine decimal to binary conversion. Wilkes described the use of decimal addresses as being an innovation which was "superficial rather than fundamental" (Wilkes, 1956, was p. 87). No doubt this was so, but the gain in progrrumner convenience very great.

It is interesting to note that the input process was not slowed down at all by the use of symbolic instructions; if programnes had been written in pure binary, four teleprinter charactersper instruction would have been needed, which was much the same as the average number of characters per instruction in the symbolic form. (However, the position changed somewhat when a high-speed photo-electric reader was added to EDSAC which meant that input was no longer the dominant factor in the input process. Two subroutines, ~16 and Ml7, were written by Wheeler in 1954 CMLEO/DC/RC/197803 the high-speed to punch and load binary programmes to take advantage of David Caminer Papersreader.) LEO Computers Society Archive, Centre for Computing History, Cambridge -14- www.computinghistory.org.uk 2.3 The co-ordinating orders

It was understood by all the early groups developing stored program computers that the sub-routine library would be the key idea in preparing programmes. The idea of a sub-routine library is one of the most fundamental in automatic computation. For example, Wilkes notes that -r the term library was f¾st used in this connection by Babbage (Wilkes, 1956 p. 86). The concept of the sub-routine as a basic building block in constructing complex programmes was well understood and used on pre-stored program computers such as the Harvard Mark I and the ENIAC. Certainly the use of sub-routines in stored program computers would have been one of the topics discussed at the Moore School lectures in 1946. J.W. Mauchly, one of the chief instructors at the Moore School lecture series, was the author of what is probably the first published paper on programming (Mauchly, 1947). In this paper, in which the word 'sub-routine' probably appears in print for the first time, the ideas and terminology of the sub-routine library and parameters are explicitly stated. These ideas are given more substance in volume 3 of Goldstine and von Neumann's reports on 'Planning and coding problems for an electronic computing instrument' (Goldstine and von Neumann, 1948). However, Wheeler believes that neither of these publications had any influence whatsoever on the work at Cambridge where the details of sub-routines and the preparation of program:nes were evolved independently.

The principle problem in incorporating sub-routines from a library into a progrannne is what we would now call relocation. (In fact the term relocation was not used at Cambridge and the process is generally referred to as the 'adjusting process'.) To illustrate, suppose we wanted to use the code in Figure 2 as a sub-routine in another programme; then if the orders were placed in location n onwards, it would be necessary to adjust the address in the third order so that it referred to location n+6.

CMLEO/DC/RC/197803

David Caminer Papers -15- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk A second point is that in order to make a sub-routine of greater generality, the storage locations from which the sub-routine obtains its arguments and to which it delivers its results should be parameters of the sub-routine. For example, if we wanted to use the code in Figure 2 as a sub-routine it should be possible for a progranme using it to form the absolute value of~ location, rather than always using location 8.

A set of synthesis orders were written by Wheeler to achieve relocation and parameterisation of a sub-routine taken from a sub-routine library as it was placed in the store. These became known as the co-ordinating orders and were described in a paper read by Wheeler at the June 1949 conference (Wheeler, 1949) and a longer account is given in his thesis (Wheeler, 1951). The co-ordinating orders, which were about (?) in number, were input by the initial orders in the usual way and occupied lo·cation 32 onwards. Once read in, the co-ordinating orders assumed the task of inputting the progranme and sub-routines.

Figure 3 shows how the code in Figure 2 might have been written as a sub-routine to fonn the absolute value of a location specified as a parameter. Orders are written in the usual way with the addition of a code letter at the end of each instruction. The use of the code letters caused the co-ordinating orders to relocate the sub-routine and to parameterise it. In the example of Figure 3, the instruction T L would be placed in the next free location and the effect of the code letter D would be to record the address of this location (n, say} in the 6-parameter for use later. The next instruction is tagged with the code letter H, which is an additive parameter,so the current value of the H-parameter (h, say) is added to the address.

-16-

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk Hence the instruction Ah Sis placed in the next location. There were a number of parameters designated e, H, N, M etc. which could be set before the sub-routine was placed in the store; for example if the H-parameter had been set to 8, then the sub-routine would have the same effect as in Figure 2. The next instruction E 6 S8 demonstrates relocation; the contents of the a-parameter, n, is added to the address so that the instruction E n+6 Sis placed in the next free location. Finally the instructions S h L, S h Land Th L are placed in the next three free locations.

CMLEO/DC/RC/197803 -17- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 2.4 The initial orders - second form

Wilkes was satisfied with the properties of Wheeler's co-ordinating orders, and it was decided to replace the existing initial orders wired on the uniselectors and the co-ordinating orders with a new set of initial orders which would combine the properties of both. This would eliminate the need for the co-ordinating orders and hence speed up the input process.

The new initial orders were announced in a memorandum dated August 1949 (UML, 1949). Wheeler's new initial orders were a tour-de-force of programming which perhaps remains unequalled; C. Adams of MIT described them as "the leading example of programming virtuosity" (Adams, 1955) and Wilkes has described Wheeler's achievement as "programming genius" (Pel tu, 1977).

Wheeler's task in writing the second form of the initial orders was to compress the first form of the initial orders plus the co-ordinating orders into 41 orders, the maximum which could be wired onto the uniselectors. The new initial orders were an extraordinary and convoluted piece of programming which is full of prograrmning tricks to save space; anyone trying to figure out how the orders work by tracing through them will find it pretty heavy going. The degree of code compression achieved is illustrated by the fact that Wilkes found it necessary to use more instructions for a simplified input routine in a didactic description of the initial orders (Wilkes, 1956, pp93-97) .

The initial orders originally used only 40 of the 41 available orders and Wheeler remarks in his thesis "it was found that there was one extra storage location available which could not be used to provide extra facilities, for any re-arrangement required at least two extra order locations. The opportunity was taken to use this spare J.ocation for a constant which is used in nearly all sub-routines".

CMLEO/DC/RC/197803

David Caminer Papers -18- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk Figure 4 shows how the sub-routine developed in §2.3 would have been written for the new initial orders. The main notational change is that the length indicator (Sor L) is no longer used, so that a code letter is used on its own if the order refers to a short number and it is pre-fixed by w if it refers to a long number. Where an order refers to an absolute storage location the code letters F and D (unpre-fixed) are used for long and short numbers respectively, The top line of the sub-routine, GK, is very important. It is not an order, but a 'control combination' which is interpreted directly by the initial orders. The effect of this control combination is Co set the a-parameter to the address of the next free location in store so that the addresses in subsequent orders tagged with the code letter 8 are relocated with respect to the zeroth order in the sub-routine.

There were a number of different types of control combination which could be used for setting additive parameters, relocation, altering the programme loading point and entering the programme at a specified entry point. All these were achieved with great economy by the second form of the initial orders. Because of the space limitations imposed by the uniselectors certain desirable features could not be incorporated in the second form of the initial orders. The most important of these omissions were the ability to set up progranme constants and jlub-routine assembly (see §4,2),

The inability to set up programme constants was an annoyance which EDSAC users had to put up with throughout the life of the machine, and it was caused solely by the lack of a bank of uniselectors at the appropriate time. However, once the second form of the initial orders came into operation any substantial change was out of the question for the existing investment in the sub-routine library was too great. The initial orders could only input instructions, so that to set up a programme constant it was necessary to fabricate a 'pseudo-:-order 1 which had the same bit pattern as the desired constant. For example, to set up a short f;ctional constant such as~~ the pseudo-order J F was used, which wasn't too difficult. On the other hand, a long fraction such as -0.3 had to be represented by the pair of pseudo-orders, S 1638 D and G 409 D; but the constant +0,3 could not be represented at all because it required a sandwich digit of 1 which could not be set by the initial not trivial to work out CMLEO/DC/RC/197803orders. Pseudo-order pairs like this were

David Caminer Papers LEO Computers Society Archive, -19- Centre for Computing History, Cambridge www.computinghistory.org.uk and pseudo-orders for useful ·constants were issued in the early EDSAC Programming Bulletins. Finally a detailed account, occupying over two sides, was issued in October 1953 in Operating Memorandum number 28 which explained how pseudo-order pairs for fractions could be calculated with a Brunsviga desk calculator. An alternative way of setting up programme constants was to use an 'interlude' to read in decimal numbers from the programme tape and place the binary equivalent in the store. (An 'interlude' was the term given to the execution of a piece of programme during progranme input, as opposed to during execution proper. Once obeyed, the interlude was overwritten by the orders which followed it on the programme tape.)

The business of setting up progranme constants has only been described at length here because it was the one real drawback with the initial orders. In machines which were progranmed in octal or hex etc. it was trivially easy to set up programme constants by performing a conversion from decimal to the base concerned.

-20- CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 2.5 Sub-routines

Two types of sub-routine were recognised at Cambridge: the first type of sub-routine was incorporated at each point in the programme where it was needed whilst the second appeared only once in a programme and was called by a special transfer of control sequence at each point in the programne where it was needed. Casting around for names for the two types of sub-routine, Hartree came up with 'open' for the former and 'closed' for the latter; an alternative to closed, 'reflexive', was also suggested but not widely used. (An example of an open sub-routine was given ll1 Figure 4.)

There was no special order for calling a closed sub-routine in EDSAC and a number of methods were evaluated for transferring control to the sub-routine and planting the return link. One of the first methods, Figure Sa, was to arrange for the calling sequence to pick up a return transfer of control instruction and plant it as the last order of the sub-routine. This was improved slightly, Figure Sb, by putting the plant order in the sub-routine rather than in calling sequence; this was the method in use with the co-ordinating orders. Finally a very neat method was devised by Wheeler, Figure Sc; the instruction Am F loads itself into the accumulator and G n F transfers control to the sub-routine; in the sub-routine a special constant (in fact U 2 F) permanently kept in location 3 is added to the accumulaor, this fabricates the order E m+2 F which is planted as the last order of the sub-routine by the order T p F. (The constant U 2 F kept in location 3 is of course the spare location in the initial orders referred to in §2.4. The use of an E or a Gorder to transfer control to a sub-routine depends on whether the contents of the accumulator is positive or negative at the time.) This method used one more order in the sub-routine but saved one instruction for each call. The device became known as the 'Wheeler jump' and there are some references to it in the early literature;

CMLEO/DC/RC/197803

David Caminer Papers -21- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk Wheeler thinks the term 'Wheeler jump' emanated from IBJ.I who adopted the method for an early machine. Wheeler also recalls showing the idea to von Neumann and that it was not an idea that had occured to the Princeton group. The Wheeler jump became the standard method of sub-routine call used with the EDSAC sub-routine library.

Two types of parameters were associated with sub-routines: pre set parameters and programme parameters. (In Wheeler, 1949, these were called internal and external parameters.) The two types of parameter worked in different ways.

When a preset parameter was used, the actual addresses in orders used in the sub-routine were adjusted by the initial orders as they were placed in the store. The sub-routine in Figure 4 shows an example of the use of a preset parameter: when the H-parameter has been set to a value hall the orders tagged with the letter H have the value h added to them. Another example is the library sub-routines Pl4, used in §3.2, which requires a rounding order to be specified as a pre-set parameter. The effect of a pre-set parameter was thUs to tailor a sub-routine for use in a particular progrannne.

On the other hand, programme parameters were used to specify the numbers to be used in a particular call of the sub-routine within a programme, and where the results were to be placed. A common method was to work on a specific location: for example the library sub-routine S2 (also used in §3,2) replaces location 4 with its square root. (Other machines would have used the accumulator for the parameter, but in EDSAC the accumulator was already used to transfer the return link.) In other sub-routines it was conventient to place the parameter after the calling sequence; for example the library sub-routine Rl, which inputs numbers into the store, is called by

CMLEO/DC/RC/197803

David Caminer Papers -22- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk .J m A m F calls in Rl, which starts in location n m + 1 G n F m + 2 T X jj programme parameter.

The programme parameter T x D specifies that numbers are to be placed in location x onwards. The sub-routine returns control to location in+3 so that it skips over the paramete.r, This method of parameter passing is of course still widely used.

CMLEO/DC/RC/197803

David Caminer Papers -23- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 2.6 The sub-routine library

The sub-routine library was made the basis of the programming system at Cambridge for the same reasons that it is still the basis of most programming systems. Firstly, library sub-routines could be written once and for all, so saving programning effort. Secondly, progrannnes which consisted of library sub-routines and just a short master progrannne would contain far fewer errors. There is even a suggestion of structured programming in embryo in this quotation from Wheeler, 1952: "When a programme has been made from a set of sub-routines the breakdown of the code is more complete than it would otherwise be. This allows the coder to concentrate on one section of a progranme at a time without the overall detailed programme continually intruding. When the entire programme has to be tested it is with the foreknowledge that the incidence of mistakes in the sub-routines is zero (or at least one order of magnitude below that of the untested portions of the progrmmne!)"

Once the second form of the initial orders were in operation work began on constructing the library of subroutines. Closed sub-routines were generally adopted at Cambridge, mainly because of the small amount of main storage. The first sub-routines to be constructed were for division (there was no hardware divider), square-root and the transendental functions. Later sub-routines for input and output and more complex mathematical procedures were added. Thus the nucleus of the sub-routine library was built­ up during the first nine-months of operation of EDSAC.

CMLEO/DC/RC/197803 -24-

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk The man-power available for constructing the aub-routine library gradually built up with the arrival of Gill aa a reaearch student in 0dtober 1949; Dodd and Glennie arrived in December 1949, and Brooker began to take an active interest in early 1950. By the end of 1950 the library contrained some eighty sub-routines and by the end of 1952 there were around one hundred and fifty items in the library. Many of the later sub-routines were contributed by users.

The writing of sub-routines for the library was no simple matter for the coding had to be compact and as error free as humanly possible. Brooker recalls that whenever he submitted a sub-routine, Wheeler could be relied upon to come up with a trick to shorten it by two Of three instructions! There was also the chore of writing a specification for the sub-routine for people not acquainted with its detailed coding; this could sometimes be the most difficult part. E.N. Mutch was responsible for documentation of the sub-routine library; for each sub-routine there was a specification sheet expl&ining how to use it and a programne sheet giving the detailed coding. The sub-routine documentation was probably instituted in late 1949: sub-routines developed prior to this appear to have been documented retrospectively and sub-routines developed after this generally bear the date of issue on the documentation. The sub-routine specifications and prograJillles in Wilkes, Wheeler and Gill are mostly taken directly from this documentation.

Library sub-routines were classified by a letter (occasionally mnemonic) indicating the group to which the sub-routine belonged, eg. A for floating point arithmetic, B for complex arithmetic, C for checking, D for division and so on. Within a group sub-routines were numbered, eg. Al, A2, A3, A4 and so on; by and large the number only indicated the chronological order in which the sub-routines were issued.

CMLEO/DC/RC/197803 -25- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 3. A TUTORIAL ON ED SAC PROGRAMMING

In this section of the paper a complete programme will be prepared for EDSAC as it might have been done in late 1949 or early 1950. The progrannne developed makes use of the second form of the initial orders and several library sub-routines, all of which are listed in Wilkes, Wheeler and Gill, 1951.

The programme has actually been run on an EDSAC simulator program so that the output from the programme and the timings given may be taken as accurate. (In case any reader wants to repeat the experiment , a sufficient description of EDSAC is entirely contained in Wilkes, Wheeler and Gill, 1951, except for input and output device timings which are given in this paper in §2.1).

CMLEO/DC/RC/197803 -26- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 3.1 The TPK algorithm

The TPK algorithm has been devised by Trab Pardo and Knuth for a comparative study of early programming languages (Trab Pardo and Knuth, 1976), The TPK algorithm is a short program which demonstrates many of the charateristic features of a program; by coding TPK in a variety of languages Trab Pardo and Knuth have been able to contrast a number of historic prog~amming languages in a most succinct yet informative fashion.

A version of the TPK algorithm written in Algol 60 is given in Figure 6a. Figure 6b shows the output from the program for a given set of test data (when run on an ICL 1903A computer), The TPK algorithm demonstrates the following poi_nts : the use of variables, cona:tants and a vector; a program loop proceeding by positive increments and another by negative increments; acc~ssing successive vector elements; a conditional statement; built-in functions, viz. square-root and absolute value; input-output procedures; a user written procedure. The program is quite short in duration and would probably have taken between one and five minutes to run on a first generation computer, depending on how fast the computer was and how effective the language and its translator.

Of course TPK does not actually do anything useful, but it would be difficult to devise a more illustrative program using less statements. For this reason we will use it here to bring out the various points in coding a problem for EDSAC,

CMLEO/DC/RC/197803 -27- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 3. 2 The TPK algorithm for EDSAC

Like most first generation computers and certainly all the earliest ones, EDSAC was a fixed point machine. Thus usually the first thing that had to be done when preparing a programme was to scale the numbers so that they would fit in the machine. EDSAC used fixed point fractions in the range -1 ~ x < 1, again like most fixed point machines.

In the TPK algorithm, for each element, t, in the vector we have to calculate • (1)

If we make the assumption that all elements of the vector are less than about 10 in magnitude we can rewrite (1) as

where y' • z-13 • y and t' • 2-4 • t. Now all the numbers handled are less than unity.

Often, the scaling of numbers in a problem was- by far the IOO~t difficult part of preparing a programme for EDSAC, comp-ared with which the coding of the actual instructions was almost trivial.

Scaling was usually done in powers of two which made constants easy to set up and scaling within the problem could be achieved by left and right shift orders. Often numbers not only had to be scaled at the outset when preparing the problem, but also had to be rescaled dynamically within the running programme so that the maximum precision was always obtained; dynamic scaling was made particularly difficult by the fact that it was not possible to detect arithmetic overflow on EDSAC at this time. The problem of scaling could be obviated by floating point interpretive routines which were developed later, but at a cost of considerably increased processing time (see §4.3.)

CMLEO/DC/RC/197803

David Caminer Papers -28- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk Next we have to allocate storage for the variables. The

vector will be stored as follows : a0 in 2OD, a1 in 22D ••• and a10 in 4OD . (The notation nD means the long location consisting of locations n and n+l.) These locations are infact occupied by the initial orders during progrannne inPut, but are overwritten when the progranme -preper assumes control . This was quite a usual practice in order to make the most of the storage, (Incidentally although EDSAC had a nominal 512 words of storage of this time, often less than this was available. The main store delay lines were housed in a thermstatically controlled oven, but temperature variations could still cause one ot 1110re delay lines to develop 'dig&t ' dropout'. In this case it was necessary to reconfigure the delay lines to give a workable store of amaller capacity.)

The next job is to choose the necessary sub-routines from the library. There was usually more than one version of a given sub-routine, depending on the speed and accuracy needed or the amount of storage available, Making a suitable choice was largely a matter of knowing one's way around the library. Here are the sub-routines for this problem:

Rl Input a sequence of signed decimal fractions P7 Print positive integer Pl4 Print signed fraction S2 Square root

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk The number of storage locations occupied by each sub-routine is given in its specification, and this information enables us to allocate storage for the programme. By convention the first sub-routine is placed in location 56 onwards, locations Oto 55 being occupied by the initial orders and their working storage. Figure 7a shows the allocation of storige for the TPK problem. This has to be done because we need to know the starting location of each sub-routine when it comes to coding the sub-routine calls in the master-routine and the auxiliart subt routine. The auxiliary subt routine corresponds to the procedure f in the Algal 60 version of the TPK algorithm; its job is the evaluate equation (2). The coding for the auxiliary is given in Figure 7b, and its operation should be reasonably clear from the notes accompanying it; the prograume notes are intended to be in a style suggestive of that used for programmes in the EDSAC library. Some general points to note about the auxiliary sub-routine are as follows. Location 8D is used for the argument of the sub-routine, t', and for the result, y'. The top line, GK, is the control combination to set the 8t parameter for relocation. Lines 0-1 plant the link for the Wheeler jump; notice that line 22 is filled with a stop instruction, Z F; this is so that the programme will come to a halt if the return link is put in the wrong place due to a coding error. The coding for 'absolute value' is spelled out in full; the operation was too short to justify inclusion in the EDSAC subrroutine library. Multiplica~ion by powers of two is achieved by left (L) and right (R) shift orders.

The master routine is shown in Figure 7c, and this corresponds to the main body of the Algal 60 version of the TPK algorithm. Again its operation should be reasonably clear from the accompanying conments, but some further points to note are as follows. As before, the top line, GK sets the a-parameter for subsequent relocation. The next three lines are used to set the M-param~ter so that all constants used in the programme are addressed relative to location m, where m is the value of the M-parameter. The advantage of this is that if the code for the master routine changes in length during the programme development process, only the M-parameter has to be changed, and the instructions in the progranme which refer to constants do not have to be altered.

CMLEO/DC/RC/197803

David Caminer Papers -30- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk The control combinations used to set the M-parameter are rather complicated and we will have to skip over the details in order ~ot to get too bogged down with minutea. Lines 29 - 31 are particularly interesting: they modify the array accessing order in line 14 by subtracting 2 from the address so that next time round the loop the array element immediately to the left of the current one is used. This sort of technique had to be used in most rearly machines until index registers, first used on the Manchester Mk m, were adopted. Incidentally, the programme might be improved slightly if were made self-initialising; as it is, if it was desired to process another set of data, the programne would have to ber re-loaded to restore the array accessing order to its original state.

The coding for the sub-routine and master routine would normally now have been written out onto coding sheets. Very handsome coding sheets were used at Cambridge from an early date. They were printed in feint grey ink, and Wilkes recalls that he considered them fer superior to the Ones used at Manchester which were printed in haavy black ink! There were quite a few notational conventions for writing programmes, a list of which was publiehed in Programming Bulletin Number 2 in May 1950. · some of the conventions were : orders which could be reached by a transfer of control from another order, or a sub-routine, were marked on the left hand side with a small arrow and the number of the order or the name of the sub-routine; ciders which caused an unconditional transfer of control were underlined; pseudo-orders had a double vertical rule to the left of theijl; orders which were modified or overwritten were put in brackets. Of course when it came to punching the programme all such material was omitted.

CMLEO/DC/RC/197803

David Caminer Papers -31- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk The complete TPK programme is shown in Figure 7d, and the number sequence for the input data is shown in Figure 7e. The programme would have taken about two minutes to run: roughly one minute to read in the programne and another minute to produce the answers. The output from the programme is shown in Figure 7£. Notice that a single space has been left between the fourth and fifth digits of the righthand column of the tabulation; this is where the decimal point would go when the answers are scaled up by 104 • Notice lllso that the zero on the last line of the tabulation is missing; this is probably due to a programning error in the zero suppression coding of the library sub-routine P7.

CMLEO/DC/RC/197803 -32- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 3.3 Punching and running

A punching service was provided on an occasional basis, but it was mainly used for preparing large volumes of n\DD.erical data. For the most part, progran:mers punched their own programmes but this was little real hardship since programme tapes were very short anyway.

The punching process generally proceeded in two stages. In the first stage separate tapes were punched for the master-routine, the auxiliar~ sub-routines and the number sequences in the progra.n:me. Tapes were blind punched using one of several keyboard perforators which were provided. Tapes could not be interpreted, so that it was reconnended practice (not always adhered to) to punch each tape twice and verify with a purpose built comparator.

In the second stage of punching the tape duplicator was used; this enabled the separate tapes to be copied and merged into a single programme tape. During this process it was also possible to make corrections and to punch the control combinations for preset parameters at the head of individual routines. The tapes for library sub-routines were kept in a set of storage drawers; there were multiple copies of each sub-routine, each kept in a small cardboard box. Once a sub-routine had been copied the original was re-wound and returned to the storage drawers. Sub-routine tapes were rather easily damaged, and the multiple copies of each sub-routine provided a back-up; the master copy of each sub-routine was kept separately under lock and key.

CMLEO/DC/RC/197803 -33- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk EDSAC was operated by a full-time operator from March 1950 and a system of 'job tickets' was instituted in about May 1950. To run a progranme, first a job ticket was completed and the pr~gramme was placed in the 'job queue'. The job queue in fact consisted of a horizontal wire onto which tapes were clipped; programnes were run on a first come first served basis. (Rather later there were three job queues, with the length of the job indicated by the colour of the tape. There was a queue for short jobs (under two minutes), medium jobs (under ten minutes) and longer jobs,) However, programners often ran there own jobs especially during the testing stage. A period of EDSAC's time was set aside each day for short development runs, users reserving a place by signing their name on a blackboard beforehand.

The actual process of running a programne was as follows. First the programme tape was placed in the paper tape reader. At this time program:nes were expected to be self-initialising and not to assume that the store was clear. In case of doubt, the main store could be cleared by earthing the delay line terminals with a wet finger! The refinement of a store clear button was added in May 1950. When the start button was pressed, the initial orders were automatically placed in the memory; this took about a second. The initial orders then read in the programne.

When the job was finished the printed output (if any) was put in a rack for collection by the user and any unusual occurences were recorded on the job ticket by the operator.

CMLEO/DC/RC/197803 -34- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 3.4 Getting progrB.IQllles right (part one)

Of course programmes didn't usually work first time they were tried. The 'checking' of progran:mes was a topic that was taken very seriously at Cambridge, (Debugging was not a term in use at that time, and bugs were called 'slips' or 'blunders'.) Wilkes recalled in 1975: "Somehow, at the Moore School and afterwards, one had always assumed that there would be no particular difficulty in getting programs right. I can remember the exact instant in time at which it dawned on me that a great part of my future life W'Oul4 be spent in finding mistakes in my own programs," (Wilkes, 1975) ::_

One of the most important checking aids on EDSAC was a monitor tube on which the 32-words in one of the sixteen main store delay lines, or 'tanks', could be displayed in binary. It was thus possible to watch the progress of a programme during its execution. This practice was known as 'peeping'. Programmers often arranged to store all the interesting numbers in a programne in the same tank so that peeping would yield as much information as possible, EDSAC was of course a very slow machine by later standards, obeying around 600 orders per second, and so it was quite possible to gain a reasonable impression of what was happening in a progr anme by observing the monitor tube when the programme ran at full speed. If necessary the programme could be obeyed one order at a time by using the 'Single E,P, I button. In addition the particular_;ank displayed on the monitor tube could be swapped by means of a sixteen position rotary switch. However manual execution was discouraged as it was rather wasteful of machine time.

Another useful device was a loudspeaker whose output was modulated by the contents of the accumulator. Apparently the practised ear could tell quite a lot about the behaviour of a programne in this way, because the ear is particularly sensitive at detecting small changes in rhythm.

CMLEO/DC/RC/197803 -35- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk Often a programmer was not present when his progrmmne went wrong, or might have been discinclined to peep or listen, In this case there were a series of 'post mortem' tapes available. (There is probably no connection between the term post-mortem and the fact that EDSAC was housed in the old anatomy school,) The post-mortem tapes were written by Wheeler and were in use by about March 1950, A post-mortem tape was loaded the same as any other progranme, except that store was not cleared, and it printed out the function letter of each word in the store from a given starting point until it was stopped by the operator. A number of tapes were provided to print out from different starting points. More sophisticated post­ mortem arrangements were provided when Wheeler returned to Cambridge in 1953; a new set of tapes were provided which could print out function codes or numbers and the starting point was entered means of the telephone dial input which had been added to EDSAC during . 1952,

A fortunate property of EDSAC was that there was a fair amount of redundancy in the order coae, only eighteen-of the thirty-two possible codes being used, and non-existent codes caused the. machine to stop. Thus if an error caused programme control to attempt to execute data as instructions, the programme very quickly came to a stop and a post-mortem could be taken. On some machines aontemporary with EDSAC this was not the case and in the same circumstances control would run riot through the store seriously mangling the programae and making a post-mortem of little use.

When the blunder was eventually found, it was necessary to correct the progranmie. Rather than prepare a new programme tape, often a 'jiffy' tape was punched, which was input after the programme had been loaded, to overwrite the incorrect instructions. In fact it became standard practice in programmes for the first instruction to be a atop order to allow a jiffy to be inserted if necessary.

CMLEO/DC/RC/197803

David Caminer Papers -36- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 4. FURTHER DEVELOPMENT OF PROGRAMMING I:ECHNIQIJE S

In Section 2 the development of programming techniques upto about the end of 1949 was described and these ideas were illustrated by developing the TPK programme in Section 3. In this section some of the important ideas developed during 1950 to 1952 will be described and where possible applied to TPK.

CMLEO/DC/RC/197803

David Caminer Papers -37- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 4. l Getting programes right (part two)

One of the programe checking techniques used with EDSAC was to insert extra print orders in a programme to print intermediate results or the function codes of individual instructions. The drawback with this technique was that it was necessary at some stage to remove the extra instructions. Gill devised a set of cheeking sub-routines which made all this unnecessary.

The checking sub-routines were probably mostly developed during the first quarter of 1950 and a full account appears in Gill, 1950, There were two basic types of checking sub-routine, the most interesting of which were those using the 'step-by-step' technique, probably the first interpretive trace routine anywhere.

The step-by-step checking routines printed out monitoring information as each order of the programme was 'obeyed'. The reason that this technique is called 'step-by-step' rather than 'interpretive' appears to be because the sub-routines were in use before the word interpretive had been coined (Gill, 1952 pp, 78 - 79). It also seems possible that there is a tenuous connection here with 4.H. Turing, for Gill refers to unpublished work on interpretive routines having been carried out by Turing at the National Physical Laboratory in 1946, (0pCit, pp • . 80 - 81).

The earliest step-by-step sub-routine printed out the location numbers from and to which transfers of control were made. However, this was quickly superceded by a new version which printed out the function letter of every order as it was obeyed. This proved to be much more useful than the former method because the programmer was not generally familiar with the absolute location numbers in which orders lay whereas the function letters were very easy to follow in the written form of the programe. (It is a great pity that this useful and compact form of trace appears to have fallen into disuse.}

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, -38- Centre for Computing History, Cambridge www.computinghistory.org.uk The trace tended to be rather slow, the dominating factor being the 62/ characters per second teleprinter which slowed down 3 the speed of tracing to about 5 orders per second. By aupressing the printout, orders could be obeyed 'silently' at about 30 orders per second. For this reason a number of sub-routines were developed which only printed from selected areas of memory so that library sub-routines, which could be assumed to be correct, were obeyed silently.

Figure Ba shows how the selective checking sub-routine C7 could have been incorporated in the TPK programme. The preset parameters for C7 specify the areas of memory from which function letters are to be printed. Figure 8b shows the first few lines of the printed output in which function letters and normal output are intermingled. Some points to note here are that C7 outputs a newline after each transfer of control and a clear line whenever orders are obeyed silently (unless the silent orders themselves produce a newline); the 'O' on line 2 of the trace is infact two O's overprinted. because the first one is the function letter of the order which outputs a carriage return. The complete trace for TPK would have taken about eight minutes and produced about 130 lines of output. (It is well worthwhile spending a minute or two here using Figure Sb to trace through the progrume in Figures 7c and b, to see how very effective this type of trace was.)

The second type of checking sub-routine was devised slightly later than the step-b}"cstep kind and used what Gill called the blocking order technique. Here the sub-routine printed the value of the operand of a particular order every time that order was obeyed.

CMLEO/DC/RC/197803

David Caminer Papers -39- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk This was achieved by the checking sub-routine overwriting the selected order with a transfer of control instruction (the blocking order) to the sub-routine which obeyed the original order and printed monitoring information before returning control to the program:ne. The advantage of this technique was that the programne ran at full speed in between printing the monitoring information. However, these sub-routines were less used than the step-by-step type as they required rather ioore forethought to use them.

The idea of checking sub-routines was entirely due to Gill, (OpCit p.106), but Wheeler, Glennie and Dodd wrote some of the sub-routines. Wilkes also developed a special assembly sub-routine (M4) to insert extra print statements at the start of each sub-routine in a progranme. Checking sub-routines were unfortunately rather time consuming and were only ever used as a last resort when other methods failed.

CMLEO/DC/RC/197803 -40- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 4.2 Sub-routine assembly, floating addresses and synthetic orders

Wilkes devised two techniques, sub-routine assembly and floating addresses, which are now universal in symbolic assemblers. The origin of these ideas is not widely known. A third technique, synthetic orders, has a modern counter-part in the form of the macro-instruction; however it seems likely that macro-instructions were re-invented independently in America some years later.

The purpose of sub-routine assembly was to permit the symbolic coding of sub-routine calls (albeit in a rather rudimentary fashion) so that the programmer was relieved of the necessity of knowing the absolute starting location of each sub-routine in the progranme. The term sub-routine assembly is infact the origin of the present day terms assembler and assembly language. The idea of a floating address corresponds to what, in a present day assembler, would be called a symbolic label. To illustrate these two techniques, TPK has been recoded and appears in Figure 9. It seems unlikely that sub-routine assembly and floating addresses were ever used together in a single programme in this way, and it has been done here mainly for economy of exposition. (In fact, the two schemes interacted slightly and required certain control combinations, at points x and yin Figure 9a, to get the programme to run on the EDSAC simulator.)

The ideas of sub-routine assembly, floating addresses and synthetic orders were never integrated into a single system, probably because the resulting input routine would have occupied far too much of the main store; however there were plans for such a scheme when magnetic tape became available (see §5).

CMLEO/DC/RC/197803

David Caminer Papers -41- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 4,2,1, The assembly sub-routines

Sub-routine assembly was used very much earlier than ia apparent from the literature and ~was incorporated in the co-ordinating orders used with the first form of the initial orders, Unfortunately sub-routine assembly had to be dropped from the second form of the initial orders because of the strict limitation on the number of orders they could contain. Wilkes devised two assembly sub-routines Ml and M2 which were placed in the sub-routine library in May and June of 1950, The assembly sub-routines supplemented the initial orders in the same manner as the co-ordinating orders extended the first form of the initial orders.

The use of Ml and M2 is described at length in Wilkes, Wheeler and Gill, 1951, Ml was the more difficult to use and could assemble a master routine, sub-routines and number sequences. M2 was rather simpler to use but assembled only a master-routine and sub-routinea.

Figure 9a illustrates the use of .M2 to assemble TPK, The master routine has to be placed first followed by the sub-routines; these are numbered 0,1,2 ••. and so on. As the programme is input, the assembly sub-routine automatically counts the master routine and sub-routines, the count being triggered by a control combination ending with the code letter S, (The floating address sub-routine may be ignored for the moment.) As this is done, a jump order ~o the first line of sub-routine n is placed in the nth line of a directory. Figure 9b shows how sub-routines can now be called symbolically: an order of the form G n 0 transfers control to the nth word of the directory which in turn transfers control to the nth sub-routine.

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk The assembly sub-routines,although making a substantial improvement in programne organisation, were actually little used for a number of reasons. To begin with, storage was restricted on EDSAC and the assembly sub-routine used valuable apace; although this space could be overwritten by the last sub-routine in the programne or used as working storage during programme execution this was not easy to achieve in practice and of course the directory itself was present throughout the programme. Also much the same effect as the assembly sub-routine could be achieved by using the preset parameter facility of the initial orders, but this was rarely considered worthwhile for, with only 512 words of storage, progrmmners tended to keep a pretty close eye on storage anyway. Perhaps another contributory factor was that once .people got used to the second form of the initial orders they were reluctant to change t~eir working methods. Probably if space had permitted sub-routine assembly to be included in the initial orders, the idea would have made a much greater contribution than it did. As it was the assembly sub-routines fell into disuse and they are not mentioned at all in the second· edition of Wilkes, Wheeler and Gill, although there is a general discussion of the topic in the text.

4,2.2, The floating address sub-routine

Wilkes first announced the idea of floating addresses, then called free-addresses, during a discussion at the Joint Computer Conference held in Pittsburg, December 1951. A report of the discussion states "Dr. Wilkes proposed a ''free-address' system of coding in which only those words which are actually referred to by instructions in the program would be numbered, •• addresses assigned to the numbered words being 11 inserted as needed , (JCC, 1951)., However, no specific details are given.

CMLEO/DC/RC/197803

David Caminer Papers -43- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk A detailed accowit of floating addresses is given in Wilkes, 1953 (received June 1952) and a floating address sub-routine is listed there, Figure 9b shows how the master-routine and auxiliary sub-routine for TPK could have been written using this floating address sub•routine. Orders are given labels of the form G n K and are referred to by addresses of the form n8; labels do not have to be written in numerical order. As the floating address sub-routine encounters: each label of the form G n K, an entry is made in position n of a directory. Orders having an address of the form n8, are 'marked' by setting the spare digit to al. ' When the code using floating addresses has been input, all the marked instructions have their addresses replaced by the corresponding entry in the directory. Incidentally, although Wilkes, 195~ claims that floating addresses can be used for pseudo-orders, in practice this leads to problems because constants hawing a 1 in the sixth bit position are mistaken for marked orders and become seriously mangled. For this reason, the constants in the TPK programme have been set up as a separate number sequence. Wilkes, Wheeler and Gill, 1957, gives a nruch more elegant chaining technique due to Wheeler which does not suffer from this disadvantage.

The main point of floating addresses of course was that it relieved the progranmer from having to know the location nuDlBer of each order within a routine. Also it was then possible to modify a programne without having to undertake extensiqe re-numbering of the orders.

Floating addresses were also described by Wilkes at the Joint Computer Conference in Toronto, September 1952, (Wilkes, 1952), In this paper the notation is tidied up slightly so that labels take the form n* instead of G n K.

The floating address sub-routine appears to have been mainly experimental, and whilst it achieved a restricted use, it was never included in the sub-routine library.

CMLEO/DC/RC/197803 -44- David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 4,2,3. Synthetic Orders

Wilkes advocated the use of floating addreases with synthe.tic: orders, which were a primi tive form of macro-instruction. They were first announced along with floating addresses at the Pittsburg Conference in December 1951, and were then called artificial instructions. Again, no specific details are given. Wilkes, 1952 and 1953, both describe an e~perimental scheme of synthetic orders then in use at Cambridge. Typical synthetic orders were

An S] increase address of order in storage location n by m P m F (used for instruction modification)

Cn S] transfer control to location n, the first m times Pm F this order is encountered, thereafter proceed serially (used to repeat a loop m times)

When used with synthetic orders, floating addresites relieved the programmer from needing to know the number of orders which :~eplaced each synthetic order in the programme. No specific details of the mechanism by which synthetic orders were translated is given in these papers, but there would appear to have been no mechanism for the user to define his own synthetic orders. So far as is known, the experimental scheme for synthetic orders is no longer extant.

CMLEO/DC/RC/197803

David Caminer Papers -45- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 4.3. Interpretive schemes

The interpretive techniques (sometimes called interpretative) developed at Cambridge were basically an extension of the use of progrannne parameters with closed sub-routines. Gill credits J.M. Bennett with coining the term interpretive (Gill.' 1952, p. 78). Bennett used the technique for the packing Of more than on-e order into a word (see Wilkes, Wheeler and Gill, 1951, Appendix D).

Interpretive routines were developed for floating decimal, complex and double precision arithmetic. Early complex and floating decimal interpretive sub-routines are described in UML, 1950. The idea behind interpretive arithmetic sub~routines was that instead of performing individual arithmetic operations each by a sub-routine call, a single sub-routine call could be made and the individual arithmetic operations each specified by a programme parameter. For example,to use the floating decimal sub~routine All (dated December, 1950) to evaluate (20D + 22D) (24D + 26D) and place the result in 50D, the-·code in Figure 10 could be used. All shows a nice economy of concept by using interpretive 'orders' si~ilar to the normal EDSAC machine orders, so that the normal initial orders could be used to read in the interpretfVe orders.

The floating decimal interpretive schemes were taken to a much greater degree of development than the other schemes and will be described here. The sub-routine All was supplemented with a number of sub-routines, Al2 - A29, over the period December 1950 to May 1951, which enabled such operations on square-root and logarithm to be performed. Eventually the somewhat ad hoe collection of All and its auxiliary sub-routines were systematised into a c6WJ)rehensive scheme in an 'informal collaboration' between Brooker and Wheeler. The floating decimal scheme was completed before Brooker and Wheeler left Cambridge in the summer of 1951 and a paper describing the scheme was submitted to M.T.A.C. at that time although it was not published until quite some time later (Brooker and Wheeler, 1953). The scheme is also described in Wheeler, 1951 and an application is described in Brooker, 1952.

CMLEO/DC/RC/197803

David Caminer Papers -46- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk The floating decimal scheme contained a number of interesting features but unfortunately, so far as can be ascertained, the actual coding is no longer extant. However, Brooker and Wheeler, 1953 gives a reasonably full account from which the programne for TPK in Figure 11 has been constructed. Where apecific entry points etc. in the sub-routine are unknown, question-marks have been used. In this example floating point numbers are each stored in Dne long location.

Figure lla shows the master routine. Lines O and 1 use the special interpretive order /J. to read in the constants and the vector. Lines 2 and 26 are particularly interesting : the interpretive orders P m F and F n F enclose a cycle of instructions which are obeyed repeatedly with a parameter taking values -m, -(m-n), -(m-2n},,, -n, In the present example the parameter takes values -24, -22 ••• -2. Using the parameter, the addresses of interpretive orders could be modified by using the code letters n6 (eg, line 15), thus having a similar effect to the Manchester B-register. Nesting to a depth of three was permissible and the parameters were accessible by ordinary machine instructions if required. It was always possible to revert to ordinary machine orders and this is done in lines 3 - 12 which output the P-F parameter in a suitably modified form. Lines 13 and 14 resume the interpretive mode by recalling the interpretive sub-routine. Lines 15 - 25 evaluate and print t1tT + St3, using the auxiliary sub~routine in Figure llh in the process. Finally lines 27 - 28 revert to machine orders and stop. Figure llc shows the form the printed output would have taken.

Two types of sub-routine were supplied : C-auxiliaries which were coded in ordinary machine instructions and called in the normal way, and X-auxiliaries which were coded using interpretive orders and were called by an X-order. The interpretive routine kept a 'list of links' for calls on X-auxiliary sub-routines and recursion was possible. (A similar idea appears in Wheeler, 1951, pp, 115 - 119 which describes a central control system for sub-routines.) Sub-routines assembly facilities were also included using a directory as described in §4.2.1.

CMLEO/DC/RC/197803

David Caminer Papers -47- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk A substantial time penalty was of course incurred and most interpretive orders took about lOOms. However ordinary machine orders accounted for a large part of any programme, and input and output was mnch the same whether interpretation was used or not, so that Brooker and Wheeler claimed programmes ran between 4 and 20 times slower, but that 11 the reduction in the time taken to code a problem has to be experienced to be believed!" (Brooker and Wheeler, 1953, p.46). In the case of TPK, the problem probably would have taken about an extra minute to run, say three minutes in all.

When Brooker and Wheeler left Cambridge in the summer of 1951 the interpretive scheme was not yet in a sufficiently poliShed state to be placed in the sub-routine library. The scheme was entirely rewritten by Gill and was eventually included in the library in May 1952 as sub-routine A30. The main innovation intrOduced by Gill was to use direct links instead of a directory in the sub-routine assembly and to drop the facility for recursion, The documentation for A30 was very comprehensive occupying some 13 pages, with another 12 pages to describe the auxiliaries.

CMLEO/DC/RC/197803

David Caminer Papers -48- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 5. CONCLUSIONS

Even with the benefit of hindsight·, it is difficult to make an objective assessment of programming activity that took place nearly three decades ago. For example, prograuming was not then the bona fide occupation it is today; to a considerable extent, whilst numerical analysis was regarded as academically respectable, the development of progrannning systems was something of a frill. Indeed in the early fifties it was difficult to find a learned journal which would accept a paper on program:ning at all.

However, then as now, the early work done by Wilkes and Wheeler stood out as a model of excellence. Wheeler's second form of the initial orders have much the same sort of aesthetic appeal as a particularly elegant proof in Mathematics. The example of EDSAC, probably more than any other machine, made a systematic sub-routine library the key idea in programming systems. Wilkes even describes the EDSAC film as being almost a commercial for the sub-routine, (Wilkes, 1975). The early work at Cambridge very directly influenced the prograuming systems on several other machines. For example LEO and TREAC both used Wheeler's second form of the initial orders and the input routines for ILLIAC and WHIRLWIND were directly influenced by ideas and personnel­ from Cambridge. The publication of Wilkes, Wheeler and Gill, 1951, was a programming event of the first importance whose influence was felt everywhere. Wegner puts the publication of this classi; .text as milestone number 2 in the development of programming systems (von Neumann's First Draft of a Report on the EDVAC was milestone number 1), (Wegner, 1973).

-49- CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk Once the second form of the initial orders had become established, the programming system was effectively frozen, A much more refined input routine could have been implemented using the ideas of floating addresses, synthetic orders, sub-routine assembly and so on, but it would have been contrary to Wilkes policy of stability of the programming system to have done so. For this reason, and because of the limited storage and slow input-output speeds, the scope for developing new programming systems was soon exhaus~ed. The prospect of a magnetic tape store with fast input-output speeds gave a new impetus in 1953. Gill and Mutch, the latter recently returned from MIT, announced plans at the NPL symposium in March 1953 (Mutch and Gill, 1953) for a powerful conversion routine [symbolic assembler] along the lines of that already developed for the MIT Whirlwind, However, Gill shortly left Cambridge and the magnetic tape backing store had a difficult and prolonged gestation, so this conversion routine got no further than the planning stage.

Cambridge did apparently have one blind spot which ought to be mentioned. This was their resistance to use of algebraic translators. Gill was probably speaking not just for himself when he said of formula translation at the March 1953 NPL symposium (NPL, 1953 p.79) : "It seems advisable to concentrate less on the ability to write, say +a+b+ab-+c as it is relatively easy for the programmer to write A a A b H a V b

T C

-so-

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk Even as late as 1957, a similarly unenthusiastic view was taken in the second edition of Wilkes, Wheeler and Gill where the topic of programning languages was dismissed in under two pages. Very recently, Wheeler was reported as saying 11 In 1957 I was not nruch in favour of high level languages. For one thing they were mostly a cover-Up for horrible machine codes and the second most important function was to give a library of sub-routines, And the third thing they did was to give reasonable input­ output facilities. But the thing they did not do was to give any reasonable error diagnostics. All right, the errors may have been fewer, but they were almost impossible to find." (Anon, 1978).

With hindsight we can see this attitUde was part right and part wrong. It was probably correct to condemn the great deal of misplaced ingenuity that went into formula translation in the early fifties, but it was unfortunate not to have seen the importance of the role played by data structures and control structures which proved decisive in the eventual ascendancy of programming languages. In the event it was not until 1961 that a high level language was used at Cambridge, on EDSAC's successor, EDSAC 2 (Hartley, 1961).

To finish on a more positive note, the aspect of the early development which strikes one most forcibly is the extreme rapidity with wfiich the early programming activity was accomplished. Within a few months of EDSAC first operating, the second form of the initial orders and the nucleus of the sub-routine library had been developed, which served EDSAC throughout its life. Today when progranmdng system development is measured in man-decades, and sometimes man-millenia, we really ought to pause and reflect.

CMLEO/DC/RC/197803

David Caminer Papers -51- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk References

ADAMS, C.W. (1955) Developments in Programming Research. Proc. Eastern Joint Computer Conference, pp. 75 - 79, December 1955.

ANON. (1978) Wheeler turns up in Cambridge. Computing (UK) 6 4 p. 68, 26th January 1978.

BROOKER, R.A. (1952) The solution of algebraic equations on the EDSAC. Proc. Camb. Phil. Soc. 48 pp. 255 - 270.

BROOKER, R.A. (1952) The adventures of a blunder. M.T.A.C. 6 pp. 112 - 113.

BROOKER, R.A. and WHEELER, D.J. (1953) Floating Operations on the EDSAC. M.T.A.C. I PP• 37 - 47.

DODD, K.N. and GLENNIE, A.E. (1951) An Introduction to the Use of High-speed Automatic Digital Computing Machines. ARE Memo No. 7/51, ARE Fort Halstead, Sevenoaks, Kent, July 1951,

GILL, S. (1951) The diagnosis of mistakes in programmes on the EDSAC. Proc. Roy. Soc. (A)~ pp. 538 - 554.

GILL, S. (1952) The Application of an Electronic Digital Computer to Problems in Mathematics and Physics. Ph.D. Thesis, University of Cambridge, November 1952.

GILL, S. (1953) Getting programs right. NPL 1953, pp. 80 - 83.

GOLDSTINE, H.H. and VON NEUMANN, J. (1947 and 1948) Planning and coding problems for an electronic computing instrument, Part 2, 1 (April 1947), ~ (April 1948), ~ (August 1948). Institute for Advanced Study, Princetown. (Reprinted in John von Neumann : Collected Works, , ed. A.H. Taub, 1 pp. 80 - 235, Pergammon 1963.)

HAMMING, , R.W. (1958) Review of Wilkes, Wheeler and Gill, 1957. J.ACM 5 3 p. 302.

HARTLEY, D.F. (1961) EDSAC 2 Autocode Manual. University Mathematical Laboratory, Cambridge, September 1961.

JGC (1951) Discussion. Review of Electronic Digital Co1"J)uters. Joint Computer Conference, Pittsburg, p. 114, December 1951.

KNUTH, D.E. and TRABB PARDO, L. (1976) The Early Development of Programming Languages. Computer Science Department, STAN-CS-76-562, Stanford University, August 1976.

CMLEO/DC/RC/197803

David Caminer Papers -52- LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk MAUCHLY, J.W. (1947) Preparation of Problems for EDVAC-type machines. Proceedings of a Symposium on Large Scale Digital Calculating Machinery, 7 - 10 January, 1947. In: Annals of the Computation Laboratory of Harvard University ~. pp. 203 - 207, 1948. (Reprinted in Randell, 1973;)

MUTCH, E.N. and GILL, S. (1953) Conversion Routines. NPL 1953, pp. 74 - 80.

MUTCH, E. (1969) The do-it-yourself days of EDSAC. Computer Weekly pp. 12 - 13, 6th February-·1969.

NPL (1953) Automatic Digital Computation. Proc. of a symposium held at the National Physical Laboratory on March 25, 26, 27 and 28, 1953. HMSO 1954.

PELTU, M. (1977) The debt that DP owes to the pioneers of Edsac. Computer Weekly, p. 14, 17th February 1977.

RANDELL, B. (ed) (1973) The Origins of Digital Computers. Springer-Verlag, 1973.

REINERS, C.A. (1953) Survey of Computing Facilities in the UK. Ministry of Supply, UK, September 1953.

STRACHEY, C. (1959) Review of Wilkes, Wheeler and Gill, 1957. Computer Bulletin 3, 6 pp. 98 - 99.

TURING, A.M. (1951) Progrannner's Handbook for the Manchester Electronic Computer Mark II. University of Manchester, March (7) 1951.

UML (1948) The EDSAC. University Mathematical Laboratory, Cambridge, May, 1948.

UML (1949) Report of a Conference on High Speed Automatic Calculating Machines, 22 - 25 June, University Mathematical Laboratory, Cambridge, January 1950.

UML (1949') The New Initial Input Orders (August 1949). (Spirit duplicated memorandum, 4pp.)

UML (1950) Report on the Preparation of Programmes for the EDSAC and the use of the Library of Subroutines. University Mathematical Laboratory, Cambridge, September 1950. CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, -53- Centre for Computing History, Cambridge www.computinghistory.org.uk UML (1954 and 1955) Introduction to programming for the EDSAC, University Mathell8tical Laboratory, Cambridge, September 1954 (1st ed), September 1955 (2nd ed).

VON NEUMANN, J. (1945) First Draft of a Report on the EDSAC, Moore School of Electrical Engineering, University of Pennsylvania, June 30th, 1945,

WEGNER, P. (1976) Programming Languages - the first 25 years, IEEE Trans. on Computers 25 pp. 1207 - 1225.

WHEELER, D,J, (1949) Planning the use of a paper library. UML, 1949, pp. 36 - 40.

WHEELER, D.J. (1950) Program organisation and initial orders for the EDSAC, Proc. Roy, Soc. (A) 202 pp. 573 - 589,

WHEELER, D,J. (1951) Automatic computing with EDSAC, Ph.D. thesis, University of Cambridge, August 1951,

WHEELER, D.J. (1952) The use of sub~routines in programmes. Proc. ACM Nat, Cont, Pittsburg, pp. 235 - 236, May 1952,

WHEELER, D.J. (1976) The TPK algorithm for EDSAC 2 (about 1958), (Letter and notes to D.E. Knuth dated 8th July, 1976, 9pp,)

WILKES, M. V, (1949) Programme design for a high speed automatic calculating machine. J, Sci. Instr, ~ pp. 217 - 220,

WILKES, M,V. (1950) The use of EDSAC for mathematical computation, Appl. sci. Res. Bl pp. 429 - 438.

WILKES, M.V. (1952) Pure and applied programming, Proc. ACM Nat. Cinf., Toronto, i,. 121 - 124, September 1952,

WILKES, M.V. (1953) The use of a 'floating-address' system for orders in an automatic digital computer. Proc. Camb. Phil , Soc. 49 pp . 84 - 89, WILKES, M.V. (1953) The EDSAC , NPL, 1953, PP• 16 - 18.

WILKES, M.V. (1956) Automatic Digital Computers. Methuen, 1956.

WILKES, M,V, (1967) Computers then and now. (1967 ACM Turing Lecture). J.ACYa 15 pp. 1 - 7, 1968 .

WILKES, M. V. (1975) Early computer developments at Cambridge The EDSAC, Radio and Elect; Eng. 45 7 pp. 332 - 335.

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, -54- Centre for Computing History, Cambridge www.computinghistory.org.uk WILKES, M,V., WHEELER, D.J. and GILL, S. (1951 , and 1957) . The Preparation of Programs for an Electronic Digital Computer. Addison-Wesley 1951 (1st ed), 1957 (2nd ed).

WORSLEY, B.H. (1949) The EDSAC demonstration. UML, 1949 pp. 12 - 16, (Reprinted in ~ndell, 1973.)

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, -55- Centre for Computing History, Cambridge www.computinghistory.org.uk 5 I I 10 I 1 I function not address length code used indicator

Fi,!!!!re 1. EDSAC order

An Add number in location n into accumulator Sn Subtract number in location n from accumulator

H n Load multiplier register with number in location n V n Multiply number in location n and multiplier register and add into accumulator

T n Transfer accumulator to location n and clear accumulator

U n '!'ransfer accumulator to location n. Do not clear accumulator

E n Transfer control to loea tion n if accumulator~ 0 ·

G n Transfer control to location n if accumulator < 0

0 n Output character in location n Z Stop and ring warning bell

Table 1. Some EDSAC orders

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk ~ ~ !!£!!!. 100 T L clear accumulator ueing location 0 ao a rubbish bin 101 A 8 L add location 8 into accumulator 102 E 106 S transfer control to location 106 if acCUlllulator > 0 103 s 8 L subtract location 8 from acCU11ulator 104 s 8 L 105 T 8 L e tore accumulator in location 8

Figure 2. Example of code for the first form of the initial orders

relative ~ order !!£!!!. 0 T LD clear accumulator ueing location 0 as a rubbish bin A LH add location h in to accumulator 2 E 6 so transfer control to relative location 6 if accumulator> 0 3 s LH subtract location h from accumulator 4 s LH 5 T LH etore accumulator in location h

Figure 3. Absolute value sub-routine coded for use with co-ordinating ordera

G K _control combination 0 T D clear accumulator A ,rH add location h into accumulator 2 E 6 0 transfer control to location 6o if accumulator ~ 0 3 s 11H subtract location h from accumulator 4 s 11H 5 T 11H store accumulator in location h

Figure 4. Absolute value sub-routine coded for second form of initial orders

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk II A m+3 F pick-up return link m+1 T P F plant in sub-routine m+2 E nF jump to sub-routine master routine m+3 E m+4 F return link j m+4 control returns here

n

sub-roil~ine

p return link planted here ]

(a)

• A m+2 F pick-up return link m+1 E n F jump to sub-routine master routine m+2 E m+3 F return link m+3 control returns here ]

n T p F plant return link sub-routine

p return link ] planted here

(b)

Figure 5. 14ethods of "!'·1.~ closed sub-'l'OutbP.a on EDSAC

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk m A m F pick-up self ] a+1 G n F jump to sub-routine master routine m+2 control returns here

n A 3 F form return link n+1 T p F plant return link J sub-routine

p return link planted here

(c)

Figure 5. llethods of calling closed sub-routines on EDSAC (continued)

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk begin integer i; !'.!!!_ y; real array a[0: 10] ; real procedure f( t); value t; real t; f : • sqrt(abs(t))+5*tf3; for i :• 0 ~ 1 :!!!lfil 10 !!-2_ a[i] :• read; ~ i ,. 10 ~ -1 until O do begin pewline(i ) ; print(i,2,0); i :• f(a[i})-J · ,:. if y > 400 then print( 999,4, 5) else print(y,4,5); ~ end of TPK algorithm;

(a) Algol 60 program

Test data: 8 -6 9.5 2.3 2.1 -2.1 6 0.001 -0.002

Printed output: 10 0.04472 9 0.03162 8 999.00000 7 -44.85586 6 47.75414 5 999.00000 4 62.35158 3 999.00000 2 -1077.55051 1 999.00000 o 18.09974

(b) test data and results

Figure '. The TPK &lgori thlll in Algol 60

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk Location of Number of storage Sub-routines, etc. first order locations occuEied R1 (read fractions) 56 55 P7 (print integer) 112* 35 P14 (print frsct ~on) 147 46 S2 (square root) 193 22 auxiliary sub-routine 215 23 master routine 238

* first order must be in an even location

(a). allocation of storage

G K 0 A 3 F ] plants link T 22 Q 2 A 8 D 3 E 6 Q s 8 D 4 l•'I '°'" calculates ~ 5 s 8 D l 3->6 T 4D 7 A 7 Q ] calls in 112 to 8 G 1 3 F calculate ,/4D S2-->9 H 8 D 10 V 8 D 11 T D 12 V D 13 R D calculates 5,2-1, t' 3 14 u D using add and shift orders 15 L 1 F 16 A D 17 T D 18 A 4 D 19 R 512 F calculates 2-1r + 5.2-1.t.3 20 A D and stores in 21 T 8 D 22 (Z l F) return order planted here

CMLEO/DC/RC/197803 (b) auxili!J:1: sub-routine

David Caminer Papers Fi§!!!:e 7, The...'.rl'K al~rithm for EDSAC LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk G K T K 47 control combinations p 38 Q ] T z 0 A Q calls in R1 to read vector G 56 F ] a0, a 1 ••• a10 into 20D, 22D ••• 40D 2 T 20 D parameter 0 10 14 R1 ,35-->3 newline 4 0 11 14 ] 5 T D 6 T D 7 A 7 14 copies count i into OD and prints it using P7 8 T F 9 A 9 F 10 G 112 F 0 12 M P7-->11 outputs two spaces 12 0 12 M ] 13 H 4 M scales ai by 10/16 14 V 40 D ] 15 T 8 D calls in auxiliary sub-routine using 8D 16 A 16 Q for argument t• and result y• 17 G 21~ F H I ,iliary--)18 8 D 19 A 8 D sets multiplier regist, to Y' 20 s 1,1 3 1 5 if y' lees than 400.2- , otherwise 999.2- 3 21 G 23 Q j 22 H 6 14 21-:-->23 T D 24 V 211.ltl 25 T D scales multiplier register by 10-4.213, transfers to OD and prints 26 A 26 Q it using P14 27 G 147 F 28 I P3104 F

(c) master routine

CMLEO/DC/RC/197803 Figure 7. The TPK algorithm for EDSAC (continued) David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk P14->29 A 14 0 30 s 9 Iii ]modify order 14 31 T 14 0 32 A 7 1,1 33 s _8 Iii decrement count and branch to 34 u 7 M order 3 if positive or zero 35 E 3 0 J 36 z F stop 37 p F filler, to make next location even p Iii 0 4 D ½, 10-9 p F ] 7 2 T1714 F 10-4.2-13 3 Z 219 D J 4 J F 10/16 5 P16oo D 400.2-13 6 P3996 F 999.2-13 7 p 5 F count i (+10) 8 p D decrement (+1) 9 p 2 F modifier 10 0 F carriage retum 11 l!. F line feed 12 ~ F space

(c) master routine ( continued)

FiEe Z• The TPK al1:12rithm for EDSAC ( continued)

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk T 56 K control combination - places programme in location 56 onwards [:J

p F extra pseudo-order to make firat location of P7 even [:J

GK T 45 KA 276 D preset parameters for P14

[:J

auxiliary aub-rou tine

111&eter routine

E Z P F control combination - enter programme at first order of master routine

(d) make up of programme tape

Figure 7. The TPK algorithm for EDSAC ( continued)

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk 15+8+6-95+23+ J Numbers are punched as decimal 99+21+21-6+0001+ fractions followed by- a sign, 0002-F F ie a data teminator.

(e) number eeguenoe for input data

10 0000 04472 9 0000 03162 8 0999 00000 7 -0044 85586 6 0047 15414 5 0999 00000 4 0062 35157 3 0999 00000 ..2 -1077 55051 1 0999 00000 0018 09974

(f) printed output

Figure 7. The TPK algorithm for EJEAC ( continued) .

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk (as in Figure 7d) AG

0 (n.b. two 0's overprinted) TTATAG 10 master 0 0 HVTAG routine ATAE5STAG

HVTVRULATARATE HASG GK T 45 K P 289 F preset parameters TVTAG 0000 04472 P 222 F for C7 ASTASUE t:,.O 0 (two 0's overprinted) P 238 F TTATAG 9 0 0 HVTAG ATAE TAG

HVTVRULATARATE etc. etc.

(a) make-up of programme tape (b) printed output

Fi.gure 8. Checking sub-routine C7 applied to TPK programme

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk T 56 K

T 82 K G K T 47 K P Q T Z

l!-number sequence

x [ G K T 62 K E 63 F patch M2 T 45 K P 400 F preset parameter for floating address sub-routine

floating address eub-routin, routine ~ 0 B

I auxiliacy I

E 25 K EH P F enter floating addr subr _to process floating addresses

[T62KU42F restore M2 y T 400 K A 432 F E 24 F ] restore initial orders E 400 K P F GS 2 [:] G 1 S

3 [:] G S T 45 K A 11'11 preset parameter for P14

4 EJ (a) make up of tape GS

CMLEO/DC/RC/197803 5 David Caminer [:]Papers Figure 9, TPK using sub-routine LEO Computers Society Archive, assembly and floating addreaees Centre for Computing History, Cambridge E 25 K E f{J P F enter master www.computinghistory.org.uk E S A g G 2 ~ ] reads vector using R1 (routine no. 2) T 20 D

G 6 K 0 10 1,1 ]new line 0 1~ M T D T D A 7 M prints count using P7 (routine no. 3) T F G 1 K A g G 3 ~ 0 12 M ] two spaces 0 12 M

H 4 1,1 ]scales ai by 10/16 G 5 K V 40 D T G 2 K A BD]2 g calls auxiliary (routine no, 1) to evaluate y' G 1 ~ H 8 D A 8 D

s 5 1,1 G 3 g

H 6 1,1 G 3 K T D outputs y' (or 999) using P14 (routine no. 4) V 2wM T D G4K A 40 G 4 ~ II P 64 F A 5 g s 9 M ] modifies order labelled G 5 K T 5 g A 7 M s BM count and jump to order G 6 K if positive or zero u 7 M E 6 g z F ,,top master routine

Figure 9, TPK using sub-routine assembly and floating addresses (continued)

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk G s A F 3 ] plants link in G 10 K T 10 0 A 8 D E 11 0 s 8 D j ,,,, to 4D s 8 D G 11 K T 4 D G 12 K A 12 0 ] calls S2 (routine no. 5) to evaluate ~4D G 5 ~ H 8 D V 8 D T D V D R D 5.2-1.t•3 to OD u D L F A D T D A 4 D

R 512 F 5.2-1.t• 3 to 81) A D }-" fa" • T 8 D G 10 K (Z F)

aux~lia!:.1: sub-routine

Figure 9. TPK using sub-routine assembly and floating addresses (continued)

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk m A m:P ] calls A11 G n F A 20 D A 22 D ] (20Dt22D) to 50D T 50 D interpretive A 24 D 'orders' A 26 D 'I 50 D ] ,.,.,.,).( '°" "' "' T 50 D

Figure 10, Use of interpreti:v:e floating decimal sub-routine A11

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk G K 0 I:::, 14 D read constants: 5 into 14D, 400 into 12D, 999 into 10D 6 40 D read vector: a0 ,a1 ••• a 10 into 40D,3BD ••• 20D 2 P 24 F open cycle 3 C 4 0 revert to machine orders 4 0 30 O J new line 5 0 6 S ? F 7 S 32 o 8 R D print P-F parameter, x, 9 T F in the form -x-2 using P7 10 T F P7 is auxili~ry no. 2 11 A 11 0 ? is address of P-F parameter) 12 G 2 L 13 A 13 0 ] resume interpretive orders main P-F cycle 14 G ? F (? is entry point if f.d. sub-routine) 15 A 42..-LI. ai to f .d.a. 16 X 1 L call auxiliary sub-routine 17 S, 16 D Jcopy y into 16D 18 A 16 D 19 B 12 D subtract 400 20 JI 240 transfer control to 24 if positive 21 D J y to f.d.a. 22 16 D 23 G 26 0 transfer control to 26 24 D ] 999 to f .d.a. 25 10 D 26 L D print f .d.a. 27 F 2 F close cycle revert to machine orders F and atop F carriage return F line feed F +2 (a) master routine

Figure 11. TPK coded for Brooker/Wheeler floating decimal interpretive acheme

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk G K Note f.d.a. is used for argument t and result y 0 il 16 D J copy t into 16D A 16 D 2 M 3 0 ronn ltl 3 C 3 L form,fiTT (i.e. call auxiliary no. 3) 4 ~ 18 D save in 18D 5 H 16 D 6 V 16 D 7 il 16 D 8 V 16 D form 5t3 9 il 16 D 10 H 1, D 11 V 14 D 12 A 18 D ../Ttf+5t3 in f.d.a. 13 C ? F return(? is special entry point of f.d. sub-routine)

(b) auxiliary sub-routine

------exponent 10 -01 4472~1-32-0---mantiasa 9 -01 31622782 8 04 99900000 7 02 -44855862 6 02 47754138 5 04 99900000 4 02 62351575 3 04 99900000 2 04 -10775505 1 04 99900000 0 02 18099745

(c) probable fonn of output

Figure 11. TPK coded for Brooker/Wheeler floating decimal scheme (continued)

CMLEO/DC/RC/197803

David Caminer Papers LEO Computers Society Archive, Centre for Computing History, Cambridge www.computinghistory.org.uk