The English Electric KDF9 Computer

See:

The English Electric (EE) KDF9 was one of the most successful products of the early UK computer industry, and it continues to inspire great affection in former users. Developed as a second-generation successor to the DEUCE, and announced in 1960, KDF9 came into service in 1964 and was still in use in 1980 at the National Physical Laboratory. KDF9 offered about a third of the power of a Ferranti Atlas for about an eighth of the cost. (So much for “Grosch’s Law” !) It was also much more successful than Atlas in the marketplace, selling about 30 systems against a mere handful of the more famous Ferranti machines. A small KDF9 configuration was priced around £250,000— the equivalent of £5,000,000 nowadays— and was about 100,000 times slower than a £1000 computer of today. This increase in cost-effectiveness by a factor of 500,000,000 is the cumulative result of the exponential improvements that the semiconductor industry has delivered since 1964, and represents a halving of the computer price/performance ratio roughly every 2 years.

This paper: The English Electric KDF9 gives a wide–ranging overview of the KDF9; this: The Hardware of the KDF9 is an extended account of the hardware, with tables defining the instruction set and order code; and this: The Software of the KDF9 is an extended account of the programming languages and operating systems it engendered. The KDF9 and Benchmarking is a short review of the work done by Brian Wichmann and his collaborators, initially based on the KDF9, towards objective measurement of various aspects of computer performance. This KDF9 Bibliography consolidates all the references relevant to the KDF9 of which I am aware.

There are links to various primary source documents in this page. Most are available in PDF format, but the largest are provided only in the much more space-efficient DjVu format. You can browse them here.

The absent PDF versions are too large to host on this website, as they attract obsessive attention by webcrawler bots, which leads to a breach of the site’s ISP-imposed traffic limit. If you must have a PDF of one those documents, drop me an email and I will send it back to you.

A film made in 1968 by UKAEA Culham, the UK’s fusion power research laboratory, contains several clips of their KDF9 in operation, running the EGDON operating system and producing graphical output using their GHOST software.

Other valuable KDF9 websites include those operated by David Holdsworth and by Brian Wichmann at the Computer Conservation Society. In particular, Brian Randell had preserved a treasure trove of KDF9 engineering documents, which he has donated to the project; they have been scanned and put online by Brian Wichmann.

Several images of KDF9 are available from former KDF9-owning sites, including Newcastle University and Birmingham University. The Flexowriter console is shown here, and in this picture. It is just possible to see that it is logging a session run under EGDON. This is a photograph of the original, pre-EGDON, installation that replaced the DEUCE at Glasgow University, and this picture gives a good impression of the scale of the disc drive.

If you have any corrections or additions to the KDF9 information in these pages, I would be grateful if you got in touch with me (Bill Findlay) by emailing to the address obtained by replacing "www." in the URL of this web page by "kdf9@".

The EE Timesharing Director

The KDF9 was one of the earliest fully hardware-secured multiprogramming systems. The Timesharing Director, its elegantly simple operating system, could run up to four programs concurrently, each being confined to its own core area by hardware relocation. A program had its own sets of working registers, among them an expression-evaluation stack, or NEST, and a subroutine-link stack, or SJNS, which were activated when that program was dispatched, so that context switching was efficient. A program could drive hardware I/O devices directly, but was limited by hardware checks to those that the Director had allocated to it. Any attempt to use an unallocated device, or to access unallocated core store, caused an error interrupt.

There was hardware-enforced mutual exclusion of access to I/O buffers. When a program blocked for that reason, or by voluntarily waiting for an I/O transfer to terminate, it was interrupted and Director switched to the program of highest priority that was not itself blocked. When a blockage cleared, and the I/O Control unit recognised that the newly unblocked program was of higher priority than the program currently running, it interrupted to allow an immediate context switch. There was even provision in the hardware to deal with priority inversion, whereby a high-priority program, say H, is forced to wait by a program of lower priority which has control of an I/O device that H needs to use.

Some later KDF9 operating systems included multi-access features, usually with PDP-8 front ends to handle the interactive terminals. They included Eldon 2, at the University of Leeds; an innovative, highly modular system, written at the National Physical Laboratories (NPL); EGDON, developed primarily by English Electric with help from the UK Atomic Energy Authority (UKAEA); and EGDON3/COTAN, developed primarily at UKAEA Culham Laboratories (the UK’s principal centre for fusion reactor research), with help from several KDF9-owning Universities.

G.O.L.D.—Glasgow On-Line Desks— was an experimental CRJE (Conversational Remote Job Entry) facility, based on the EE Timesharing Director, and developed during 1966-67 at Glasgow University. Never put into production, it was quickly superseded by COTAN. In some ways it can be seen as a primitive application of ideas more successfully used by Eldon 2. The G.O.L.D. manual is a mish-mash of user guide, reference manual, and implementation description: the concept of levels of abstraction had yet to make its mark. It is amusing to see that a chapter entitled “FOR BEGINNERS” starts with a quotation from the ancient Greek poet Alcman that present-day Athenians struggle to construe—it means something like: experience creates wisdom. And they claim that Universities have not dumbed down!

G.O.L.D. casts light on some of the difficulties that the designers of KDF9 software had to overcome. Chapter 6 of the manual describes the conventions used for representing the KDF9 character set in terms of the ASCII-based KSR-33 Teletype. It’s not a pretty picture—see the “simple” example on pages 2-1 and 2-2. Chapter 10 is very valuable for its account of how to use PROMPT, the disc-oriented program development system provided by English Electric, upon which Eldon 2 also was based.

The EGDON and COTAN Systems

The two KDF9s operated by the UKAEA did not have the timesharing hardware described above (it was an extra-cost option that nearly all KDF9s had), and so a more basic approach to efficient machine utilisation was adopted. EGDON was a classical FORTRAN job-stream system, of the same general type as IBSYS for the IBM 7090. Many of its features reflected a desire for some compatibility with the FORTRAN compilers written by the Atomic Weapons Research Establishment at Aldermaston for their IBM 7030 “Stretch” computer.

In its final form EGDON 3 supported the COTAN 3 interactive subsystem. COTAN —the Culham Online Task Activation Network— provided an effective and usable environment for software development and interactive computation, on a very modest computer. EGDON and COTAN documentation can be found here; including that for earlier EGDON and COTAN versions. Reading the manual sections devoted to system generation procedures, I am struck by the thought that the implementors of EGDON/COTAN achieved Iron Age results with Stone Age tools.

A paper describing the original version of EGDON has been anthologised by Per Brinch Hansen in his book: Classic Operating Systems: From Batch Processing to Distributed Systems, Springer, 2001 ( also available for download). It presents EGDON essentially as an automated program development system. COTAN was one of the earliest fully-interactive multi-access systems. Its prototype, COSEC —the Culham Online Single Experimental Console— is described in a paper available for download.)

High-Level Languages

The KDF9 Whetstone and Kidsgrove compilers were pioneering implementations of Algol 60.

Brian Wichmann, at NPL, modified the Whetstone interpreter to gather byte code execution-frequency statistics for a large number of programs. This data was used to synthesise the famous Whetstone Benchmark, a program that reproduces these statistics in a single run, permitting its use as a simple tool for estimating computer performance in scientific applications.

A variant of FORTRAN IV, called EGTRAN, was implemented on the EGDON system. Its most unusual feature was that a FUNCTION or SUBROUTINE subprogram could be declared RECURSIVE. In that case its local variables were held in a stack rather than static storage, permitting the subprogram to be invoked while it was already active.

FORTRAN was also available under Eldon 2, with a compiler written at Leeds University; and there were compilers for various “autocodes”: simple languages derived from compilers written by Tony Brooker for the Ferranti Pegasus, Sirius, Mercury and Atlas computers. A later version of autocode on the KDF9, known as IMP, and written at the Edinburgh Regional Computer Centre (ERCC), was a very capable language used for system programming. COBOL never made it to the KDF9, but EE supplied a Report Program Generator (RPG). Bill Waite implemented his STAGE2 macroprocessor, the basis for the Mobile Programming System, on KDF9. The KDF9 STAGE2 manual contains an example of an EGDON job deck, and a short COTAN interactive dialogue.

Usercode

This simple program gives a flavour of Usercode, the rather eccentric assembly language of the KDF9; it calculates Ackermann’s function and types the result on the Flexowriter. This runs 800 times faster in emulation than it would have done on the KDF9 hardware. To get an idea of how that compares with modern hardware and software, see these recent results.

A major engineering application program was written in Usercode by Phil Runciman.

The KDF9 (Usercode) Programming Manual is the best available guide to programming the KDF9. (An earlier, much less comprehensive version of the Usercode manual is available elsewhere on the WWW. The present version is believed to be definitive.)

The STAGE2 macroprocessor has an unusual format for macro templates, mixing keywords and parameters arbitrarily. I hypothesized that this derives from the structure of Usercode, as Waite actually wrote a Usercode assembler that ran much faster than EE’s original (Note on rapid instruction analysis by table lookup, M. O’Halloran and W.M. Waite; The Computer Journal, 1966, pp.248-249). However, he has since informed me that it actually derives from the SNOBOL string-manipulation language.

For use with the GNU KDF9 emulator, ee9, there is now kal3, a modern Usercode assembler written by David Holdsworth. It runs natively on your own computer and generates a KDF9 machine code program that ee9 can load and run. An executable of kal3 is included with the download package for ee9. The original source code can be found some way down this page.

ee9, a KDF9 emulator has been developed with the ultimate objective of being able to run KDF9 object programs under the control of an original operating system. It is also intended as lasting and accessible documentation of the KDF9 architecture.

The touchstone of its success has been to run the Whetstone Benchmark on its original platform: the Whetstone Algol programming system. Brian Wichmann measured 417 CPU seconds on an actual KDF9 in 1972. The real CPU time used by the emulator on my 2011 MacBook Pro was less than 1.7 seconds, so ee9 was about 250 times faster than the original hardware. (On my 2019 MacBook Pro, programs run between 400 and 700 times faster under ee9 than they did on KDF9.)

Running the Whetstone Benchmark natively on the old MacBook Pro took less than 400 microseconds! This ratio of 1.7s (for an emulated KDF9 running an interpretive language) to 400µs (for native Mac compiled code) —about 4250 to 1— reflects a slowdown by a factor of about 75 for Whetstone interpretation by the KDF9 and by a further factor of about 55 for KDF9 emulation on the Intel Mac. Since the Whetstone interpreter was skilfully programmed in Usercode, this speaks well for the efficiency of ee9, which was written in a wide-spectrum language, and with pedagogical clarity as a more important objective than performance. It is also testament to the quality of GNAT, the magnificent GNU Ada compiler.

KDF9 and Algol 60

KDF9 was one of the first computers to support Algol 60, the international algorithmic language that is the common ancestor of many of today’s most widely used programming languages. In fact, KDF9 was supplied with two Algol 60 compilers that ran under the Timesharing Director: the Kidsgrove (KAlgol) and Whetstone (WAlgol) systems, which were named after the EE installations where they were written. The KDF9 Algol Manual describes the common features of the WAlgol and KAlgol implementations.

KAlgol aimed at efficient machine code and included an optional global optimisation pass. The compiler had an unfortunate reputation for being slow and the optimiser was accused of generating unreliable object code. Its ambition for efficient machine code was not fully realised, among the problems being poor handling of the KDF9’s unique complement of registers, which admittedly are difficult to manage in the face of Algol features such as name parameters. In particular, to avoid overfilling the nest, KAlgol took a conservative approach to nest management, which nullified some of its advantages.

But this can be exaggerated; KAlgol was capable of compiling some expressions very well indeed. Here is a real example, taken from a program that uses Zeller’s Congruence to calculate the date of Easter Sunday. For the assignment:

integer a, c, h; h := h + c - 7 × ((a + 11×h + 19×c) ÷ 433) KAlgol generates: with effect: Y12M1; N1: h Y11M1; N1: h, N2: c +; N1: h+c SET7; N1: h+c, N2: 7 Y9M1; N1: h+c, N2: 7, N3: a SET11; N1: h+c, N2: 7, N3: a, N4: 11 Y12M1; N1: h+c, N2: 7, N3: a, N4: 11, N5: h ×D; CONT; N1: h+c, N2: 7, N3: a, N4: 11h +; N1: h+c, N2: 7, N3: a+11h SET19; N1: h+c, N2: 7, N3: a+11h, N4: 19 Y11M1; N1: h+c, N2: 7, N3: a+11h, N4: 19, N5: c ×D; CONT; N1: h+c, N2: 7, N3: a+11h, N4: 19c +; N1: h+c, N2: 7, N3: a+11h+19c SET433; N1: h+c, N2: 7, N3: a+11h+19c, N4: 433 JSP204; N1: h+c, N2: 7, N3: (a+11h+19c) ÷ 433 ×D; CONT; N1: h+c, N2: 7×((a+11h+19c) ÷ 433) -; N1: h+c-7×((a+11h+19c) ÷ 433) =Y12M1; h := h+c-7×((a+11h+19c) ÷ 433)

WAlgol was a checkout compiler: aimed at fast compilation and comprehensively checked execution, it generated byte code for an abstract machine that bears a remarkable resemblance to the machine code of the (later) Burroughs B6500. Native to the paper tape oriented EE Timesharing system, WAlgol was adapted to card input by John Patterson (JWP) et al., in the guise of Incore Algol, which served as a batch compiler for large numbers of short student jobs under EGDON. Transplanted to COTAN, WAlgol provided a facility for online compilation and interactive execution.

WAlgol was so well documented in ALGOL 60 Implementation, B. Randell and L.J. Russell, Academic Press; 1964—a groundbreaking book (also in OCRed DjVu format) —that it engendered Algol 60 implementations on many other computers, including the EE DEUCE, the Ferranti Pegasus, the NPL ACE, the EE KDF6, the Soviet Minsk range, the EE System 4/50, the IBM System 360/25, the Phillips PRS8000, the Elliott 903, and the Indian ECIL TDC-316. The Elliott 903 version, running on a real 903, has been used by Andrew Herbert to cross check the ee9 implementation of an example program from the KDF9 Algol Manual!

Until very recently, the influence of the Whetstone system on the Burroughs large-systems architecture had remained plausible, but conjectural. The B5500 had 12-bit instructions and no up-level addressing (so it could not fully implement Algol 60 non-locals and closures). Its successor, the B6500, had variable-length instructions consisting of 1 or more 8-bit syllables, and implemented a hardware display for addressing non-locals, just like the Whetstone virtual machine. Bill McKeeman has now given first-hand evidence that these similarities are no coincidence. He writes: “I ended up consulting for Burroughs Pasadena on the B6500 design. Ben Dent was struggling with generalising the B5500 stack to handle up-level addressing. So I told him how. During each weekly visit we discussed the problem until he asked ‘How do you know all of this?’ So I said, it is in a book—ALGOL 60 Implementation. He was irritated at not knowing sooner, got the book, and did not need to talk to me about it again. So I think it is fair to say that whatever he needed, he got from the book.”

The EGDON operating system eventually gained a third Algol 60 compiler, written by the implementers of KAlgol with the benefit of hindsight. It eschewed global optimisation, but included a very good peephole optimiser, and combined respectable compilation speed with reasonably fast object code and decent run-time checking. Unlike WAlgol and KAlgol, it generated relocatable object files that could be be linked with the output of the EGTRAN (EGDON‘s somewhat extended FORTRAN IV) and UCA3 (EGDON Usercode) compilers.

A multi-language EGDON program (in fact the code I wrote for my Junior year CS project) can be found here, in a sadly incomplete state. It is an interactive Turing machine simulator, intended for use in a course on formal languages and automata, and consists of an Algol 60 main program, augmented by a set of subroutines in Usercode, and a single RECURSIVE SUBROUTINE in EGTRAN. Unfortunately, the first page of Algol (about 60 lines of code), a couple of pages of Usercode (about as much), and the EGTRAN SUBROUTINE (about the same) have been lost. It is not entirely infeasible that they might be recreated from the surviving documentation (namely, part of my 3rd year dissertation).

This is one of the most semantically complex examples from ALGOL 60 Implementation, namely Knuth’s GPS procedure. It is deployed, following an example published by Knuth and Merner in the CACM issue of June 1961, to compute the i-th prime number. It achieves this by insanely devious use of name parameters and side effects: "Jensen’s Device", pushed to the limit.

In this emulation run, operator input is requested by the Whetstone system, not the Director. The Translator asks for the “stream” number of a spooled output file for the compilation listing. This is given either as N, to suppress the listing, or as 30, the stream number for output to be spooled to the lineprinter (LP0). The Algol source program is read from a paper tape reader. The object code is kept in core, ready to be run by the Controller, the Whetstone abstract machine object code interpreter, which the compiler overlays on itself at the end of a successful compilation.

Running a problem program in fast mode (without diagnostics). – i.e. the Whetstone Translator ________________________________________________________________________ OUT ;N.| – No compilation listing wanted ee9: OUT 5: requests a device of type #02; gets TR1. – the compiler reads the source program from TR1 on buffer #2 GPSPRIMES| RAN/EL/000M02S/000M04S SIZE 155 – the compilation took 2s of CPU time and 4s elapsed – the Whetstone virtual object code was 155 8-bit syllables long ee9: OUT 8: closes stream #10. ee9: OUT 6: releases TR1. ee9: OUT 1: ICR = 265418; RAN/EL = 1629103 / 9509513 KDF9 us. – so typing the Flexowriter messages at the end of compilation took about 5s more elapsed time! ee9: OUT 1: the Whetstone Controller overlays the Translator. Running a problem program in fast mode (without diagnostics). – i.e. the Whetstone Controller ________________________________________________________________________ STREAM ;30.| – stream spooled output to LP0 AD - S AD - S ee9: OUT 8: closes stream #10. AD 10 CLOSED ee9: OUT 8: closes stream #30. AD 30 CLOSED RAN/EL/021M36S/021M40S – end of run of the Algol object program ee9: OUT 1: ee9 will not return to the Whetstone Translator. ________________________________________________________________________

Output from GPSprimes

Here is the program’s stream 10 output on TP0. It begins with a final message from the Translator, and continues with the output from the Controller:

RAN/EL/000M02S/000M04S SIZE 155 The 1st prime is 2 The 2nd prime is 3 The 3rd prime is 5 The 4th prime is 7 The 5th prime is 11 The 6th prime is 13 The 7th prime is 17 The 8th prime is 19 The 9th prime is 23 The 10th prime is 29 The 11th prime is 31 The 12th prime is 37 The 13th prime is 41 The 14th prime is 43 The 15th prime is 47 The 16th prime is 53 The 17th prime is 59 The 18th prime is 61 The 19th prime is 67 The 20th prime is 71 The 21st prime is 73 The 22nd prime is 79 The 23rd prime is 83 The 24th prime is 89 The 25th prime is 97 The 26th prime is 101 The 27th prime is 103 The 28th prime is 107 The 29th prime is 109 The 30th prime is 113

Source text of GPSprimes

Here is the Algol 60 test program itself. The Flexowriter had a “non-escaping” underline character, which did not advance the typewriter carriage, so that it overstruck the following character. Underlining was used to distinguish an identifier such as “begin” from the unrelated Algol basic symbol word “begin”. In the KDF9 hardware representation of Algol 60 “_[” and “_]” are string quotes and “*” is the visible-space symbol; “×” is multiplication, “÷” is integer division, and “±” represents “≠”, which is not in the Latin-1 character set used by the emulator.

Although GPS is not intrinsically recursive, in this application it is invoked recursively through its fourth parameter, which is re-evaluated each time around the loop, and which thereby entails a call of GPS from within itself (with different parameters from the top-level call).

This gives a good impression of what an Algol source program looked like, as typed on an offline Flexowriter to prepare a paper tape for input to the Algol compiler.

Here is a run of the famous Whetstone Algol Benchmark, under its original Whetstone Algol system. For amusement, the actual CPU time used on my 2017-model iMac is shown at the end of the run.

Reading-in the Whetstone Translator and Controller programs from paper tape would have taken nearly 51 wallclock seconds. This time was not included in the Director’s (or ee9’s) measurement of the elapsed time, but was attributed to system overhead.

Running the KDF9 problem program Binary/KMW0201--UPU in fast mode. – the Whetstone Translator (compiler) ________________________________________________________________________ OUT ;N.| ee9: OUT 5: requested a device of type #02 and got TR1 using Latin-1 code. – the compiler reads the source program from TR1 on buffer #2 WHETSTONEBMK| RAN/EL/000M05S/000M15S SIZE 603 – the compilation took 5s of CPU time and 15s elapsed – the Whetstone virtual object code was 603 8-bit syllables long ee9: OUT 6: released TR1 ee9: OUT 1: ICR = 812988; RAN/EL = 4825962 / 20250623 KDF9 us. Running the KDF9 problem program Binary/KMW0301--UPU in fast mode. – the Whetstone Controller (interpreter) ________________________________________________________________________ STREAM ;30.| AD - S AD 30 CLOSED RAN/EL/006M57S/006M58S – end of run of the Algol object program ee9: OUT 1: ee9 will not return to the Whetstone Translator. _______________________________________________________ Final State: ... ORDERS: 74907209 executed (ICR) CPU TIME: 421554691 KDF9 us. (RAN) about 422 sec – CPU time CLOCK TIME: 446429204 KDF9 us. (EL) about 446 sec – elapsed time ... FW0 on buffer #00 transferred 141 characters. TR1 on buffer #02 read 5416 characters in Latin-1 code. TP0 on buffer #04 punched 552 characters in Latin-1 code. LP0 on buffer #05 printed 66 lines. real 0m0.962s user 0m0.954s sys 0m0.004s

The Kidsgrove Algol system, which generates native KDF9 object programs, was recently resurrected by a team including David Huxtable, one of its original authors. Here is a much faster run of the Whetstone Benchmark, conducted by the Kidsgrove system. Note the difference in execution times: translation took 4.8 KDF9 CPU seconds for the Whetstone compiler but nearly 2 minutes for the Kidsgrove compiler, whereas running the object program took 417 seconds for Whetstone byte code and 21.7 seconds for Kidsgrove native code. ee9 runs the Kidsgrove object program so quickly that it is all over before my finger has lifted off the RETURN key!

Running the KDF9 problem program Binary/KAB00DH--USU in fast mode. – the Kidsgrove compiler ________________________________________________________________________________ ee9: OUT 4: requested a tape labelled 'SYSTAPE9' and got MT4 with TSN '-01-0105'. ee9: OUT 4: requested a tape labelled ' ' and got MT0 with TSN '-01-0101'. ee9: OUT 4: requested a tape labelled ' ' and got MT1 with TSN '-01-0102'. ee9: OUT 4: requested a tape labelled ' ' and got MT2 with TSN '-01-0103'. ee9: OUT 4: requested a tape labelled ' ' and got MT3 with TSN '-01-0104'. ee9: OUT 5: requested a device of type #02 and got TR1 using Latin-1 code. ee9: OUT 6: released TR1. ee9: OUT 5: requested a device of type #11 and got TP0 using KDF9 code. ee9: OUT 6: released TP0. ee9: OUT 5: requested a device of type #03 and got LP0. ee9: OUT 6: released LP0. ee9: OUT 6: released MT0. ee9: OUT 0: end of run. ________________________________________________________________________________ Final State: Normal end of run. ... ORDERS: 19598604 executed (ICR) CPU TIME: 110433546 KDF9 us. (RAN) about 110 sec – CPU time CLOCK TIME: 1165797914 KDF9 us. (EL) about 1166 sec – elapsed time ... FW0 on buffer #00 transferred 8516 characters. TR1 on buffer #02 read 17893 characters in Latin-1 code. TP0 on buffer #04 punched 20632 characters in KDF9 code. LP0 on buffer #05 printed 336 lines. MT0 on buffer #10 transferred 183856 characters, and is now at BTW. MT1 on buffer #11 transferred 94752 characters. MT2 on buffer #12 transferred 112672 characters. MT3 on buffer #13 transferred 266272 characters. MT4 on buffer #14 transferred 194576 characters. ... Running the KDF9 problem program Binary/WHETSTONE in fast mode. ________________________________________________________________________________ FINISHED ENDS 00 ee9: OUT 0: end of run. ________________________________________________________________________________ Final State: Normal end of run. ... ORDERS: 3438705 executed (ICR) CPU TIME: 21723928 KDF9 us. (RAN) about 22 sec CLOCK TIME: 24280412 KDF9 us. (EL) about 24 sec ... FW0 on buffer #00 transferred 17 characters. LP0 on buffer #05 printed 13 lines.

Output from WHETSTONEBMK

This is the Benchmark output on LP0 from the Kidsgrove system. It has been verified by running it, in Pascal as well as Algol 60, both natively on Macs and in emulation on two ICL 1900 series models (with thanks to Bill Gallacher, Brian Spoor and David Holdsworth).

N= 0 J= 0 K= 0 X1=+1.00000000 X2=-1.00000000 X3=-1.00000000 X4=-1.00000000 N= 120 J= 140 K= 120 X1=-0.06834220 X2=-0.46263766 X3=-0.72971839 X4=-1.12397907 N= 140 J= 120 K= 120 X1=-0.05533645 X2=-0.44743656 X3=-0.71097339 X4=-1.10309806 N=3450 J= 1 K= 1 X1=+1.00000000 X2=-1.00000000 X3=-1.00000000 X4=-1.00000000 N=2100 J= 1 K= 2 X1=+6.00000000 X2=+6.00000000 X3=-0.71097339 X4=-1.10309806 N= 320 J= 1 K= 2 X1=+0.49040732 X2=+0.49040732 X3=+0.49039250 X4=+0.49039250 N=8990 J= 1 K= 2 X1=+1.00000000 X2=+1.00000000 X3=+0.99993750 X4=+0.99993750 N=6160 J= 1 K= 2 X1=+3.00000000 X2=+2.00000000 X3=+3.00000000 X4=-1.10309806 N= 0 J= 2 K= 3 X1=+1.00000000 X2=-1.00000000 X3=-1.00000000 X4=-1.00000000 N= 930 J= 2 K= 3 X1=+0.83466552 X2=+0.83466552 X3=+0.83466552 X4=+0.83466552 THAT TOOK 21.7 SECONDS, FOR 46.1 KWIPS FINISHED ENDS 0

Source text of WHETSTONEBMK

Here is the source code for the Whetstone Benchmark program.

Here is the (slightly redacted) log of an emulation run in hardware boot mode, showing the bootstrap of a Director, its initialisation dialogue with the operator, and its response to some operator commands. Because the Director is internally multi-threaded, messages from separate internal activities are interleaved in the monitor typewriter (Flexowriter) log output. This run shows the execution of the Whetstone Benchmark, as compiled to KDF9 machine code by the Kidsgrove Algol compiler.

Text in blue is a running activity log from the emulator itself. Material in green italics is explanatory commentary that I have added. Text in bold red is KDF9 console Flexowriter output. A semicolon in such a message turns the write operation to a read operation (this is a hardware feature of the KDF9 Flexowriter buffer), so what precedes the semicolon is output and what follows the semicolon is the computer operator’s input, shown in bold black—the Flexowriter had another hardware feature, whereby the red part of its two-colour typewriter ribbon was used for output and the black part for input, the switch being made (strangely) before the semicolon. In this case, the computer operator inputs commands (“TINTs”) to Director. “|” represents the KDF9 End Message character, which was actually typed as “→” by the Friden Flexowriter.

Loading and execution of the Whetstone object program starts at the line:

TINT ;T0/30000.|

Flexowriter output from Director that is relevant to slot P is indented by one tab stop. (Output concerning a program running at level Q would be indented two tab stops, for level R by three, and so on; Director’s own activities are logged with no preceding tab.)

Booting the KDF9 Director Binary/KKT40E007UPU in fast mode. – the original Time Sharing Director (TSD) ________________________________________________________________________________ P KKT40E007UPU TIME SHARING DIRECTOR 2464 WDS| 02U01 02U02 05U03 01U04 03U05 10U07 10U10 10U11 10U12 10U13 10U14 CORE MODULES ;8.| OUT 8 REEL NO ;23001C.| A-PROGRAM DETAILS| LEVELS ;N.| DATE D/M/Y ;23/9/69.| TIME ON 24-HOUR CLOCK HOURS/MINS ;10/29.| TINT ;15/10.| – tell TSD that buffer 15 is a tape deck 10L14 /Iden<+KOUTPUT/0023004>,TSN -00-2339 10L13 /Iden<MS-DUMP.>,TSN 10L12 /Iden<EFPBEAAG>,TSN -00-0552 10L11 /Iden<EXAMTIME>,TSN -66-1909 10L10 /Iden< ZERO >,TSN -00-1478 10L15 TINT ;T0/30000.| 10L15 /Iden<PRINTEND>,TSN 0-00-929 0 BPIU 02P 0º23/09 1029 0ºP P WHETSTONEUPU – the program is in multiprogramming slot P, priority 0 10C10D – TSD claims the work ( ZERO ) tape on MT0 for OUT 8 spooling 0/FINISHED ENDS 0| – the program writes its termination message to FW0 via OUT 8 0 OUT 8 P0000001/0023001 – TSD identifies the spooling session 0 WHETSTONEUPU ENDS 0 0ºRAN/EL/000M22S/000M22S/000M00S TINT ;J10.| – the operator closes the spooling session on MT0 10L10 /Iden,TSN -00-1478 – TSD renames the spool tape on MT0 for retention ... FW0 on buffer #00 transferred 892 characters. TR0 on buffer #01 read 22398 characters in KDF9 code. TR1 on buffer #02 read 19584 characters in KDF9 code. MT0 on buffer #10 transferred 1888 characters, and is now at BTW. MT1 on buffer #11 transferred 16 characters, and is now at BTW. MT2 on buffer #12 transferred 16 characters, and is now at BTW. MT3 on buffer #13 transferred 16 characters, and is now at BTW. MT4 on buffer #14 transferred 24 characters, and is now at BTW. MT5 on buffer #15 transferred 16 characters, and is now at BTW. ... ________________________________________________________________________________

Now the OUT 8 spooled output on stream 30 can be printed down.

Despooling OUT 8 stream 30 for slot P from MT0 TAPE LABEL TSN '-00-1478', IDENTIFIER '+KOUTPUT/0023001' SESSION P000001 WHETSTONEUPU 23/09/69 STR30 N= 0 J= 0 K= 0 X1=+1.00000000 X2=-1.00000000 X3=-1.00000000 X4=-1.00000000 N= 120 J= 140 K= 120 X1=-0.06834220 X2=-0.46263766 X3=-0.72971839 X4=-1.12397907 N= 140 J= 120 K= 120 X1=-0.05533645 X2=-0.44743656 X3=-0.71097339 X4=-1.10309806 N=3450 J= 1 K= 1 X1=+1.00000000 X2=-1.00000000 X3=-1.00000000 X4=-1.00000000 N=2100 J= 1 K= 2 X1=+6.00000000 X2=+6.00000000 X3=-0.71097339 X4=-1.10309806 N= 320 J= 1 K= 2 X1=+0.49040732 X2=+0.49040732 X3=+0.49039250 X4=+0.49039250 N=8990 J= 1 K= 2 X1=+1.00000000 X2=+1.00000000 X3=+0.99993750 X4=+0.99993750 N=6160 J= 1 K= 2 X1=+3.00000000 X2=+2.00000000 X3=+3.00000000 X4=-1.10309806 N= 0 J= 2 K= 3 X1=+1.00000000 X2=-1.00000000 X3=-1.00000000 X4=-1.00000000 N= 930 J= 2 K= 3 X1=+0.83466552 X2=+0.83466552 X3=+0.83466552 X4=+0.83466552 THAT TOOK 21.5 SECONDS, FOR 46.5 KWIPS FINISHED ENDS 0

You might like to compare the beginning of this emulation output with an actual Flexowriter log, preserved by David Holdsworth, of a session on the 23rd of September 1969, booting the later and considerably more taciturn Eldon 2 Director. The assignment of devices to buffers was slightly different, so the deck numbers associated with each magnetic tape file are not all the same:

One of the mathematical epics of the 20th century was the effort to discover and characterise all of the finite simple groups. Contributing to this struggle, it was useful to be able to find out whether a simple group of a specific size could exist. Counting the cosets of a group was often a useful step in solving this latter problem.

John Leech, who was then in the Computing Laboratory at Glasgow University, wrote a coset enumeration program based on the Todd-Coxeter Algorithm, with refinements by Leech and by Brian Haselgrove. The HLT algorithm was programmed in KDF9 Usercode and ran on the Glasgow machine. But the Glasgow KDF9 had only 16KW of core store at the time, and this proved insufficient for some of the groups Leech wanted to investigate. Brian Wichmann, who had a doctorate in group theory, and who knew Leech, was working at the National Physical Laboratory (NPL). He was asked to run Leech’s program on the KDF9 at NPL, which had a 32KW store.

(During this work, Leech discovered the 24-dimensional lattice that bears his name. The Leech lattice is closely related to the Monster, the largest of the finite simple (!) groups: a truly gigantic structure that represents the culmination of the group classification project. The Monster, and the Leech lattice, are intimately related to the reason why bosonic string theory only works in 26 dimensions! Cohn, Kumar, Miller, Radchenko, and Viazovska proved in 2016 that the Leech lattice is the unique densest periodic packing of unit spheres in 24 dimensions.)

Fortunately, Wichmann has preserved his correspondence with Leech, including program and data listings, and recently typed them up. So Leech’s program has now been run, probably for the first time since 1965, under ee9.

Running the KDF9 problem program Binary/LEECH in fast mode. ________________________________________________________________________________ ee9: OUT 5: requested a device of type #02 and got TR1 using Latin-1 code. ee9: OUT 5: requested a device of type #01 and got TP0 using Latin-1 code. ee9: OUT 6: released TP0 ee9: OUT 0: end of run. ________________________________________________________________________________ ... End of Run. TR1 on buffer #02 read 118 characters in Latin-1 code. TP0 on buffer #04 punched 726 characters in Latin-1 code. real 0m3.936s user 0m3.887s sys 0m0.026s

Here is the output. The program first copies its data from a tape reader (TR1) to a tape punch (TP0) and then, after a long calculation, it appends the number of cosets it has found (in this case, 1045).

AEFDBC – This line means AA=1, BE=1, CF=1, DD=1, EB=1, FC=1 | A – These lines ask for the cosets of A, B and C B C | – A finite presentation of the group follows ... CCC – ... i.e., CCC = 1, FACA = 1, and so on. FACA DFDC DBDB FBCEE BBBBBBB AEABAEAB AEEAEABBB ADADADADAD ABCDEABCDEABCDEABCDEABCDEABCDEABCDE | 1045| – This is the number of cosets found.

At one point in the testing of ee9 I suspected that it was evaluating the Algol arctan function wrongly, so I looked carefully at the Usercode routine that implements it. That turned out to be the start of a fascinating mathematical journey, described here.