EDSAC

9-inch tubes used for monitoring

William Renwick with 5-hole tape reader and Creed teleprinter

As soon as EDSAC was operational, it began serving the university's research needs. It used mercury delay lines for memory and derated vacuum tubes for logic. Power consumption was 11 kW of electricity.[8][9] Cycle time was 1.5 ms for all ordinary instructions, 6 ms for multiplication. Input was via five-hole punched tape, and output was via a teleprinter.

Initially registers were limited to an accumulator and a multiplier register. In 1953, David Wheeler, returning from a stay at the University of Illinois, designed an index register as an extension to the original EDSAC hardware.

A magnetic-tape drive was added in 1952 but never worked sufficiently well to be of real use.[10]

Until 1952, the available main memory (instructions and data) was only 512 18-bit words, and there was no backing store.[11] The delay lines (or "tanks") were arranged in two batteries providing 512 words each. The second battery came into operation in 1952.[10]

The full 1024-word delay-line store was not available until 1955 or early 1956,[12] limiting programs to about 800 words until then.

John Lindley (diploma student 1958–1959) mentioned "the incredible difficulty we had ever to produce a single correct piece of paper tape with the crude and unreliable home-made punching, printing and verifying gear available in the late 50s".[13]

Maurice Wilkes inspecting the mercury delay line of the EDSAC in construction

Maurice Wilkes and Bill Renwick in front of the complete EDSAC

The EDSAC's main memory consisted of 1024 locations, though only 512 locations were initially installed. Each contained 18 bits, but the topmost bit was always unavailable due to timing problems, so only 17 bits were used. An instruction consisted of a 5-bit instruction code, 1 spare bit, a 10-bit operand (usually a memory address), and 1 length bit to control whether the instruction used a 17-bit or a 35-bit operand (two consecutive words, little-endian). All instruction codes were by design represented by one mnemonic letter, so that the Add instruction, for example, used the EDSAC character code for the letter A.

Internally, the EDSAC used two's complement binary numbers. Numbers were either 17 bits (one word) or 35 bits (two words) long. Unusually, the multiplier was designed to treat numbers as fixed-point fractions in the range −1 ≤ x < 1, i.e. the binary point was immediately to the right of the sign. The accumulator could hold 71 bits, including the sign, allowing two long (35-bit) numbers to be multiplied without losing any precision.

The instructions available were:

• Add
• Subtract
• Multiply-and-add
• AND-and-add (called "Collate")
• Shift left
• Arithmetic shift right
• Load multiplier register
• Store (and optionally clear) accumulator
• Conditional goto
• Read input tape
• Print character
• Round accumulator
• No-op
• Stop

There was no division instruction (but various division subroutines were supplied) and no way to directly load a number into the accumulator (a "sTore and zero accumulator" instruction followed by an "Add" instruction were necessary for this). There was no unconditional jump instruction, nor was there a procedure call instruction – it had not yet been invented.

Maurice Wilkes discussed relative addressing modes for the EDSAC in a paper published in 1953. He was making the proposals to facilitate the use of subroutines.[14]

The initial orders were hard-wired on a set of uniselector switches and loaded into the low words of memory at startup. By May 1949, the initial orders provided a primitive relocating assembler taking advantage of the mnemonic design described above, all in 31 words. This was the world's first assembler, and arguably the start of the global software industry. There is a simulation of EDSAC available, and a full description of the initial orders and first programs.[15]

The first calculation done by EDSAC was a square-number program run on 6 May 1949.[16] The program was written by Beatrice Worsley, who had travelled from Canada to study the machine.[17][16]

The machine was used by other members of the university to solve real problems, and many early techniques were developed that are now included in operating systems.

Users prepared their programs by punching them (in assembler) onto a paper tape. They soon became good at being able to hold the paper tape up to the light and read back the codes. When a program was ready, it was hung on a length of line strung up near the paper-tape reader. The machine operators, who were present during the day, selected the next tape from the line and loaded it into EDSAC. This is of course well known today as job queues. If it printed something, then the tape and the printout were returned to the user, otherwise they were informed at which memory location it had stopped. Debuggers were some time away, but a cathode-ray tube screen could be set to display the contents of a particular piece of memory. This was used to see whether a number was converging, for example. A loudspeaker was connected to the accumulator's sign bit; experienced users knew healthy and unhealthy sounds of programs, particularly programs "hung" in a loop.

After office hours certain "authorised users" were allowed to run the machine for themselves, which went on late into the night until a valve blew – which usually happened according to one such user.[18] This is alluded to by Fred Hoyle in his novel The Black Cloud

EDSAC monitoring desk[19]

The early programmers had to make use of techniques frowned upon today—in particular, the use of self-modifying code. As there was no index register until much later, the only way of accessing an array was to alter which memory location a particular instruction was referencing.

David Wheeler, who earned the world's first Computer Science PhD working on the project, is credited with inventing the concept of a subroutine. Users wrote programs that called a routine by jumping to the start of the subroutine with the return address (i.e. the location-plus-one of the jump itself) in the accumulator (a Wheeler Jump). By convention the subroutine expected this, and the first thing it did was to modify its concluding jump instruction to that return address. Multiple and nested subroutines could be called so long as the user knew the length of each one in order to calculate the location to jump to; recursive calls were forbidden. The user then copied the code for the subroutine from a master tape onto their own tape following the end of their own program. (However, Alan Turing discussed subroutines in a paper of 1945 on design proposals for the NPL ACE, going so far as to invent the concept of a return-address stack, which would have allowed recursion.[20])

The lack of an index register also posed a problem to the writer of a subroutine in that they could not know in advance where in memory the subroutine would be loaded, and therefore they could not know how to address any regions of the code that were used for storage of data (so-called "pseudo-orders"). This was solved by use of an initial input routine, which was responsible for loading subroutines from punched tape into memory. On loading a subroutine, it would note the start location and increment internal memory references as required. Thus, as Wilkes wrote, "the code used to represent orders outside the machine differs from that used inside, the differences being dictated by the different requirements of the programmer on the one hand, and of the control circuits of the machine on the other".[21]

EDSAC's programmers used special techniques to make best use of the limited available memory. For example, at the point of loading a subroutine from punched tape into memory, it might happen that a particular constant would have to be calculated, a constant that would not subsequently need recalculation. In this situation, the constant would be calculated in an "interlude". The code required to calculate the constant would be supplied along with the full subroutine. After the initial input routine had loaded the calculation-code, it would transfer control to this code. Once the constant had been calculated and written into memory, control would return to the initial input routine, which would continue to write the remainder of the subroutine into memory, but first adjusting its starting point so as to overwrite the code that had calculated the constant. This allowed quite complicated adjustments to be made to a general-purpose subroutine without making its final footprint in memory any larger than had it been tailored to a specific circumstance.[22]

The subroutine concept led to the availability of a substantial subroutine library. By 1951, 87 subroutines in the following categories were available for general use: floating-point arithmetic; arithmetic operations on complex numbers; checking; division; exponentiation; routines relating to functions; differential equations; special functions; power series; logarithms; miscellaneous; print and layout; quadrature; read (input); nth root; trigonometric functions; counting operations (simulating repeat until loops, while loops and for loops); vectors; and matrices.

The first assembly language appeared for the EDSAC, and inspired several other assembly languages:

In 1952, Sandy Douglas developed OXO, a version of noughts and crosses (tic-tac-toe) for the EDSAC, with graphical output to a VCR97 6" cathode-ray tube. This may well have been the world's first video game.[27][28]

Another video game was created by Stanley Gill and involved a dot (termed a sheep) approaching a line in which one of two gates could be opened.[29] The Stanley Gill game was controlled via the lightbeam of the EDSAC's paper-tape reader.[29] Interrupting it (such as by the player placing their hand in it) would open the upper gate.[29] Leaving the beam unbroken would result in the lower gate opening.[29]