English Electric KDF8
From Wikipedia, the free encyclopedia
KDF8 was an early British computer designed and built by English Electric, later English Electric Leo Marconi, EELM, later still incorporated into ICL.
Contents |
[edit] Background
During the late 1950s, as a result of a long-standing technical arrangement with the RCA company of America, English Electric built a version of the RCA 501 computer which was known as the KDP10. The KDP10 was first delivered in 1961, after which it was upgraded and re-designated in 1964 as the KDF8. These machines were aimed entirely at the emerging commercial marketplace.
[edit] Basic features
[edit] Processor/main store
KDF8 was a transistor based machine with magnetic core memory. The core memory of the machine I programmed at Kidsgrove for several years from late 1964 was considered large for its time, having been upgraded from 64k to 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. 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 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) running in parallel. A system of hardware “gates” set and checked at machine code level allowed the programmer to control the degree of synchronous operation.
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.
[edit] 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 across, holding a maximum of 2400 feet 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 were like 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. (I have not been able to find a photograph of the KDF8, but the KDF9 entry here has a photograph of the externally very similar KDP10)
Eight was I believe the working maximum number of tape units for any actual KDF8 configuration (although I was only familiar with the Kidsgrove machine). I understand 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 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 communicate with 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.
[edit] 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) and BBB 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 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.
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 the (variable length) numbers, one end of each of which was stored at the “A” and “B” addresses of the instruction. A “Sector Compare” instruction (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” and TC 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. I never found out why this might be useful!)
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!
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)
<IAN●TAYLOR●41●HIGH STREET●KIDSGROVE●STAFFS>
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.
[edit] 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 maually 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 I believe 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 suite of programs I worked on 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 we in our ignorance initially called ease-code, until we realized the American pronunciation of easy-code!). This was not used when I joined, 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 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. Naturally, Tape Control was written in Assembler……..
A COBOL compiler. This was very rarely used at all, 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, used (I understand) to help design the hardware for later computers. (Another oddity was a decision table per-processor for COBOL programs, itself written in COBOL. This was of some interest, since we were at the time experimenting with using decision tables as an alternative to flowcharts. However, while we 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.
[edit] 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.
