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.
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!
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.
References
- [1]
-
D M Yates, Turing's Legacy. Science Museum. 1997. ISBN 09018-05947