English Electric KDF8

KDF8 was an early British computer designed and built by English Electric, later English Electric Leo Marconi, EELM, later still incorporated into ICL.

Background

During the late 1950s English Electric embarked on two major computer projects. Firstly, as a result of a long-standing technical arrangement with the RCA company of America, English Electric built a version of the RCA501 computer which was known as the KDPI0 (KDP for Kidsgrove Data Processing). This was a machine intended for commercial data processing applications, with fixed length instructions, but powerful capabilities for processing variable-length numeric and alpha-numeric data. The KDP10 was first delivered in 1961, after which it was upgraded and re-designated in 1964 as the KDF8; about ten machines were sold.

The second large computer to emerge from development work at Kidsgrove was the KDF9, primarily designed for scientific work.

One KDF8 was installed at the Kidsgrove (Staffordshire) site of The English Electric Company's computer bureau. Over the years, and a succession of mergers, this organisation became English Electric Leo Marconi, {EELM}, International Computing Services Limited {ICSL}, and finally under a joint arrangement between ICL and Barclay's Bank, Baric). The description following describes this machine and its use.

Basic features

Processor/main store

KDF8 was a transistor based machine with magnetic core memory. The core memory of the machine installed at the Kidsgrove (Staffordshire) site of the The English Electric Company's computer bureau was considered large for its time having been upgraded from 64k to the then maximum of 96k (NOT meg!) of core memory. KDF8 used an octal (base eight) addressing system. A machine-code instruction was fixed length, ten octal characters long and the instruction set was specifically designed for ease of commercial use. It had machine-code level instructions for all four of the decimal arithmetic functions, operating on variable length numbers AND for efficient manipulation of variable-length numeric and alpha-numeric data-strings. Not all instructions required all ten characters. Given the minimal core memory available, programmers frequently used “spare” characters in instructions for storage of constants and similar storage-saving tricks.

KDF8 was strictly a batch processing computer, running one program at a time. Only one compute instruction could be processed at one time, but it was also possible to have one read and/or one write instruction (typically from and to magnetic tape) executing in parallel. A system of hardware “gates” set and checked at machine code level were used to control the degree of synchronous operation. However, since there was NO operating system of any kind, this was - and had to be - controlled entirely at the individual program level.

The level of programmer skill to control full read/write/compute overlap, especially if data records were “batched” several to the “real” block of data on magnetic tape, was considerable, since ALL simultaneity checks had to be hand-coded into the program. Automatic error-detection was essentially limited to hardware parity checks at the character level, and there were no processor hardware checks on what the programmer could do. For example, the computer would simply stop if instructed to access a memory location beyond physical memory.

Peripherals

There were no magnetic disks, drums or other similar temporary backing-storage devices. Bulk storage was limited to replaceable/dismountable magnetic tapes, on open reels, each reel of which was about one inch thick and nine inches (229 mm) across, holding a maximum of convert|2400|ft|m of tape. Data and programs were kept on these tapes. Peripheral error-checking was again limited to parity checks on all reads and writes and the use of write permit rings. These resembled large plastic rings, and one had to be attached by the operator behind any reel of tape where writing was to be allowed before it was mounted on the tape-deck (the write permit ring obviously depressed a micro-switch on the deck). The Kidsgrove KDF8 had eight magnetic tape units on-line, each rated at a theoretical maximum 40k characters per second read/write speed. Each tape unit was about six foot tall and two foot wide, and the processor and memory cabinets were about the same in size and number. So the Kidsgrove configuration required a large and of course air-conditioned room.

Eight was considered the working maximum number of tape units, one per channel, for any actual KDF8 configuration (the Kidsgrove machine had this number). It was theoretically possible - and certainly the addressing structure allowed for it - for each tape channel to be split through additional hardware units into a sub-group of eight tape decks, giving a theoretical maximum of 64 on-line tape units. (In fact, the absolute maximum would have been slightly less, since at least three uniquely-coded I/O channel identifiers were required for other devices.)

Other tape unit/printer pairs were available, able to operate independently of the mainframe. These provided an off-line printing facility for volume output, freeing the KDF8 to run other work.

Other peripherals included:
* a paper-tape reader (1000cps) for data and (initial) program input,
* an operator’s teletype-like device (with a rarely used associated slow paper tape punch built-in) permitting programs to display information to the operator, and the operator to use the keyboard to punch up short program or data items on paper-tape. (NB This teletype could NOT be used by the operator to input data directly to the computer – all operator commands had to be input through the operator’s console - see below.)
* an on-line printer, used mainly for core dumps of failed programs.

Both on and off-line printers were impact printers, capable of printing a line of either 120 or 160 characters, depending on the model (and of course the width of the paper loaded!). They were single type-face, no lower case. Paper for the printers was continuous, and supplied in boxes of many pages, each page a maximum of about 16 inches wide by 11 deep, with perforations between the pages, and sprocket-holes at each side of the paper for the paper-feed mechanism. Custom paper sizes, with pre-printed lines/text/colours etc were common, especially for applications like payroll, and small paper-tape control loops were needed to match page-throw size to each paper type.

Instruction Set

Each KDF8 machine-code instruction took the format

OO AAA RR BBB

In this representation

OO represents a two-(octal) character operation code, identifying the instruction to be performed, in the range 00 to 77,AAA represents a six-(octal) character “A” core address ranging from 000000 to 777777. (A theoretical ¼ Meg directly-addressable main store, an actual 96K!)RR represents a two-character Register setting (one character for each of two possible registers numbered 1 to 7 used to modify the “A” and “B” addresses, with 0 indicating no register modification) andBBB represents the “B” address, the same as the “A” address in format.

Instructions were read in turn from main store into registers, then executed.

Example. An instruction to read data from the on-line paper-tape reader to locations starting at store location (octal) 200000 would look like

14 200000 00 770000 (spaces for clarity only)

Where 14 was the operation code for this type of read, 200000 was the lowest store location the data would be read to, 00 indicates that no register modification was to be done to the A or B addresses of the instruction, and 77 was the (fixed) device identifier of the paper tape reader. (Note - 77 used as a device id for a write operation would direct the write to the operator's teletype. Embarrassing if this was due to a program error, and it was a large data block intended for mag tape.....) The last four octal characters (0000) were not required in this instruction, and would be ignored when the instruction was processed. Such "spare" characters were frequently, given the extremely limited main store available used by programmers to store constants.

Some aspects of the instruction set were advanced, and greatly eased programming of commercial systems.

The operation codes 51-54 did DECIMAL arithmetic Add, Subtract, Multiply and Divide on variable length numbers, stored as decimal characters. One end of each operand was stored at the “A” and “B” addresses of the instruction. The other end was identified by an ISS (Item Separator Symbol), octal 74. Thus numbers could be literally any length.A “Sector Compare” instruction (Octal 43) permitted three-way conditional branching of program control depending on whether the data stored in the range from the “A” address to the “B” address was greater, less than, or equal to, the value of the same number of characters stored at locations to the left of the (previously set) “T” register, as the following Assembler language version attempts to demonstrate.

Tag Op A-Address RR B-Address

COMPARE SET £T SALARY,R SC TAXLIMIT TAXLIMIT,R CTC BELOWTAXLIMIT ABOVETAXLIMIT EQUAL TC EQUALTAXLIMIT

In this example, we are comparing a salary with a tax limit, and jumping to one of three program locations depending on the respective values. The “,R” Assembler convention represents the rightmost character of the named field.CTC stood for “Conditional Transfer of Control” andTC for (unconditional) Transfer of Control

(In fact, a rarely if ever used feature of this very common instruction group was that if a line advance was in progress on the on-line printer at the time of making the comparison, program control would jump to NONE of these three addresses, but to core address 000200. Presumably the instructions set designers understood the need for this!)

Disclaimer – it’s been 40 years since I programmed for this computer, so yes, I may have got the > and < jumps the wrong way round! [Note on disclaimer: A completed EE KDP10 Data Processing System WorkBook DPCS(T)6 confirms that the original author is right. As a former EE KDP10/KDF8 programmer I would add that the original article gives an excellent account of this amazing machine]

In the above “compare” code, the original (KDP10?) instruction set compared from right to left, requiring the whole length of the data strings to be compared, a character at a time. KDP8 was enhanced to compare from left to right, so the comparison could stop as soon as the relative values were clear, speeding up processing of such instructions considerably.

Variable length data was handled with the aid of specially-designated characters. The ISS or Item Separator Symbol, octal 74, usually represented as “●” was used to separate variable length data fields. Octal 75 “<” and 76 “>” identified the start and end of a data message, Octal 777777 was by custom and practice used to identify End of File. So data such as names and addresses could be punched onto paper tape for data input as (for example)

Various instructions could operate directly on this variable length data, and records could be batched say ten to the batch onto magnetic tape, for efficient storage. Given the relatively slow (by today's standards) of both the processor and I/O rates, a significant aspect of the programmer's task was to balance the batching of data on tape, with the computing needed per record and organise the simultaneous I/O and compute operations with the aim of maximising overlap of computing with I/O and avoiding the tape-decks stopping between batch reads.

Software

There was essentially NO operating system. Programs were initiated by an on-line operator, via an operator’s console (see later). Operators were also responsible for manually clearing memory and re-setting the computer between programs, mounting and changing tapes, controlling off-line printing and the like.

Some standard software packages were available, or became available, all written in the USA by the RCA organisation. These included the following.

An excellent parameter-driven sort-merge program, capable of handling very large volumes of data. Sort parameters could either be read in from the paper-tape reader, for one-off sorts, or “compiled” in (really just stored in the program). There were extensive user “hooks” where user-supplied code could be put in at various stages of the sort/merge process. (More or less as an experiment, one commercial suite of programs written at Kidsgrove was done entirely as own-code additions to the sort program, rather than the typical vet/sort/update/sort/update/print program sequence.) The sort was exceptionally well-written, fast and reliable, with optional re-start check-points built in. However, a very high level of operator skill was required should the volume of data to be sorted exceed the combined capacity of all the tape-decks available, since numerous tape changes were then required.

An assembler-language compiler, again written in the States, called EZ-Code. (which was in ignorance initially called ease-code, by the English, until it was realized the American pronunciation was easy-code!). This was not used commercially for some time, since compilation time was then seen as a heavy overhead, but became increasingly used in later years. To save on computer time, typically a programmer would do an initial compile, dry-check the program manually, re-compile, and then test and de-bug the compiled machine-code version of the program, building up a reel of paper-tape machine-code patches to the program as each correction was made. Once a fairly robust copy was available, the changes would be replicated (hopefully accurately!) in Assembler and the program re-compiled and re-tested. Frequently, the last stage was never quite completed, and it was not unknown for production programs to require machine code-patches to be loaded from paper tape for each run. Also, a number of major commercial packages for payroll, accounts and share registration were written by Bureau staff before the Assembler compiler was accepted, and remained entirely in machine code. A further quirk was that the I/O generation routines of the assembler were not used by one programming section, who had written their own generalized I/O package, called Tape Control, based on the COBOL file description table formats, and automating many of the error-prone programming of batching/unbatching of records and controls of simultaneous read/write operations and end-of-file xonditions. Naturally, Tape Control was written in Assembler……..

A COBOL compiler. This was very rarely used, early experiences not having been entirely favourable. (Including the attempted compilation of a small program of only about 200 lines of code, which ran for over an hour, then failed with an error message indicating that there were insufficient tape units on the computer to finish the compilation.) One notable exception was a wiring design program called "WRS1", used to help design the hardware for the later English Electric "KDF9 and System 4" range of Mainframe computers. Another oddity was a decision table pre-processor for COBOL programs, itself written in COBOL. This was of some interest, since bureau programming staff were at the time experimenting with using decision tables as an alternative to flowcharts. However, while these programmers continued to hand-code in assembler from the hand-written decision tables with some success, the compilation overheads prevented the use of the pre-processor.

To optimize throughput of production programs, standard packages of software were produced by bureau programmers for payroll, sales and purchase ledgers, share registration, stock control and the like, and some applications – notably payroll – supported the processing of data from many bureau customers in one computer run, with individual parameter settings managing individual customer’s requirements. More complex client requirements were met by custom-built programs.

Computer Operation

The KDF8 operator interface could with hindsight fairly be described as both asymmetrical and challenging. It required a very high level of skill, perhaps not often recognized appropriately at the time. As has been stated, there was essentially NO operating system. A very small (about 20 instructions) bootstrap loader could be held at the front of each program tape, but even this approach was not always used. Tape labels were (with the exception of COBOL and Tape Control managed applications) almost non-existent. A grandfather/father/son cycle of tape rotation protected production tapes from major disasters, but required careful manual controls. Programmers (or for operational suites Production Control staff) gave the operator written instructions on which program tape and data tapes to load, on which devices, and a written summary of how to load and initiate each program. The operator would then load the tapes, and load and initiate each program in turn manually from the console.

The console consisting of a vertical display panel about ten inches high by about five foot long with a similarly-sized slightly angled control panel below it. Each of these two parts was filled with labeled buttons and illuminated indicators each (roughly) one inch square. The display section was made up of indicators which when illuminated showed, in binary (grouped as octal) characters, the machine’s current running (or static) status at the individual machine core address and register level, for the compute, read and write operations then in progress. When a program was running, this display was a kaleidoscope of quickly-changing, flashing, multi-colored lights. The control panel section consisted of press-buttons to select the next register to be set and a central part that mirrored the lay-out of a single machine core address. Other buttons accessed more complex(!) operations. Use of these buttons enabled the operator to select and then directly input to the machine’s core storage locations and registers the octal pattern he/she keyed in manually. For an operator to input a single machine instruction, each of up to ten octal characters of the instruction had to be selected and keyed in as its binary pattern – each with the correct (odd) parity bit! A skilled operator would “play” the console like a pianist, entering codes faster than the uninitiated observer could follow.