Reminiscences of KDF9

The intention here is to collect reflections of the KDF9 computer by those who worked with the machines. The list of contributions is in alphabetical order.

Alan Freke

I worked on KDF9s from 1964 until 1977. I joined English Electric at Kidsgrove in October 1964 as a peripheral test engineer. I had no previous computer experience, but had just completed an electrical engineering apprenticeship with the Bristol Aeroplane Company where I had a slight acquaintance with their DEUCE.
Beside KDF9 peripherals, I also worked on those of the KDP10, KDF7(?), and KDN2. After about a year I was transferred to peripheral design and development working on the soon to be launched System4 peripherals. I was in a very junior capacity there, but it taught me a lot.
In September of 1966 I saw an advertisement for a job at Bristol Siddley Engines in Bristol for someone to design a special purpose interface for their KDF9. I applied and got the job.
The plan was to link their KDF9 to a newly acquired Digital Equipment Corp. PDP8 to speed up job entry. All input was via the paper tape reader on the KDF9, and the plan was to have the data prep done online using the PDP8 with Teletype 33s, and then the PDP8 scheduling the work and feeding it to the KDF9 instead of the paper tape reader.
Work had already started when I arrived, and the plan was to use an "standard" interface being promoted by Derek Barber at the NPL, but adapted to suit our purpose. In particular rather than 8 data bits we wanted to use 12 data bits in parallel on data transfers (PDP8 12 bit word, KDF9 48-bit word, and KDF9 paper tape code 6 bit). Also NPL wanted to use +/- 12 volts for interface signals, we just wanted to use integrated circuit logic levels of +5 volts nominal and zero. In this we were support by the folk at Cullam Labs. of the AEA who were also keen to use the interface. (Eventually, in its NPL form, it became a British Standard - but I don't think that very many people used it)
The PDP8/KDF9 project was successful, and I was then asked to link engine testbed data gathering equipment to the PDP8, so that data could be transferred directly to the KDF9 for analysis. This was again done successfully.
A new ambitious plan was hatched to use a DEC PDP10 (with a large amount of disk storage) as an online facility for programmers, and then link that to the KDF9 to run jobs. The system was known as AMOS, and presented several problems on the engineering level, as well as software problems. The PDP10 had a 36-bit word length, thus confirming our view that 12 bits was the optimum size for parallel data transfer. However, we didn't use 12 bits for the PDP10-KDF9 link, but 144. (4 x 36bit PDP10 words to 3 x 48 bit KDF9 words) This 144 bit ring buffer was filled and emptied by the respective machines on a DMA basis allowing high speed data transfers.
The programmers lives were transformed, as instead of two POST runs a day for debugging their code, they keyed in KDF9 code on their Teletype 33s attached to the PDP10, then posted it into the KDF9 entry, and almost immediately had a 1 minute run slot on the KDF9, with results back to them via the PDP10. If their job took more than the minute allowed the whole task was swapped out of the KDF9 to the PDP10's disks, and then put back in the queue at a lower priority, so it would take a lot longer.
The system was successful, and we acquired a second KDF9 from BAC at Filton to add more power, as well as another PDP10. The need for more KDF9 power arose from the Rolls Royce take-over. Their DP people confidently thought that they could convert all our advanced KDF9 software to run on IBM hardware (it was their preferred computer), but it was soon apparent that they couldn't. So advanced was our application software, that the development engineers at Derby wanted access to it, and so a special dedicated line was installed from Derby to Bristol to allow their engineers to access our system.
About this time DEC launched the PDP11 which was 8-bit byte based, and which we consequently viewed as an oddity. However, we did add many PDP11s to the ever-growing network of computers linking testbeds, laboratories etc. The NPL-like interface was used for all sorts of peripherals, including high speed printers, plotters, paper tape equipment of all kinds, A-D converters etc.
The final addition to the system came in 1975 with the acquisition of a CDC Cyber74 mainframe to the system. Having a 60 bit word length this confirmed our 12 bit view of the world - how wrong we were!. The Cyber74 was ordered with no peripherals but CDC insisted on a tape drive and printer, or their engineers couldn't run diagnostics. Again, CDC programmers worked on the Teletypes - keying Cyber programs, which were posted across to the Cyber for running, and results returned to the PDP10s in the same manner as with the KDF9.
DEC produced a nice colour brochure about the system, as they saw their PDP10s as the heart of it. I wish I'd kept a copy!
In 1977 I was offered a job with a small Canadian company called Geac, and I left what was then Rolls Royce, thus ending my involvement with the KDF9.

Brian Wichmann


Fortunately, there is an authoritative history of computing at NPL [1], which covers the period of the KDF9s. Hence in this note, I cover some aspects from a personal perspective.

Coset enumeration

The NPL KDF9 installed in 1964 was a full size of 32K words (192K bytes). At Oxford, I studied group theory prior to coming the NPL. The major problem being faced in group theory was to enumerate all the finite simple groups. A tricky issue was to establish the existence of a group of a specific order. One technique to do this was coset enumeration. John Leech at Glasgow University had written a machine code program to do this, but their machine had insufficient memory to undertake the critical case. I was able to use the NPL machine to do the enumeration. I have to say that I could not understand John Leech's program, in spite of my training!

The two Algols

Effective use of the KDF9's at NPL depended upon the use of both the Whetstone and Kidsgrove compilers. The Flowers report was very negative about the execution speed of the Whetstone interpreter. However, the Whetstone system turned out to be very useful for on-line systems when they were developed in the later years of the machine. Moreover, it has always been my view that computing depends upon understanding algorithms, and this could be undertaken quite reasonably with the combination of the Whetstone and Kidsgrove compilers.
As far as I was concerned, the Whetstone interpreter was vital in collecting statistics of language usage which resulted in the Whetstone benchmark. Some of these statistics were from Oxford University with the help of Dr Chris Phelps.
It is worth noting that the KDF9 machine, being word-based with little in the way of part-word extraction facilities, makes a byte-based interpreter inherently slow. I think that the only significant change I made to the Whetstone system at NPL was to add a (cheap) check for unassigned values. Using the statistics gained, I was able to make a 20% speed-up in the Kidsgrove system using peep-hole optimization.


The first machine only had a non-time sharing Director when delivered, but relatively quickly, the time-sharing Director was provided. This allowed for the concurrent running of up to four programs (as well as the Director). This made very effective use of the hardware, but was relatively inflexible.
David Martin at NPL designed a core system for the basic software which was potentially very much more flexible. I was involved in providing the disc storage module for this system. Unfortunately, the idea came too late in the history of the machine, since re-writing the available software to work effectively in the new system (Democrat) would have taken too long (as well as being too expensive). One of the interesting jobs I did was to produce a post-mortem after an operating system failure (all the memory is saved, including Q stores).
Although the alternative operating system, Egdon, had many advantages, switching to that would have been difficult for NPL. Fortunately, the Eldon operating system, written at Leeds, came to the rescue.


One particular KDF9 project was very successful, which was bootstrapping a compiler for an Algol-like language (PL516) for the Honeywell 516 mini-computer.
The language was based upon the idea of PL360 designed by Niklaus Wirth, but for a mini-computer rather than a main-frame. The initial compiler was written in a subset of Algol 60 which could be transliterated into its own language. PL516 became the main programming language of the Network development undertaken at NPL.


KDF9 was a very interesting machine. It had a stack for speed, unlike the B5500 which had a stack for executing Algol. One problem to be faced today is to explain how one could do anything with only 192K bytes of storage - everything has changed so much, both in storage and speed.
Technical reports describing most of this work are available electronically from me, if required.


D M Yates, Turing's Legacy. Science Museum. 1997. ISBN 09018-05947