KDF10 — a pipe dream
David Holdsworth
When I learnt sometime around 1970 that our KDF9 was to be replaced by a new machine,
I at first looked forward to progress, and heard rumours of the ICT 1900.
First impressions of the architecture of the 1900 were of a mini-computer,
24-bit words, 8 accumulators of which only 3 were index registers, and a 15-bit address space,
an address space only half that of KDF9 when measured in bytes.
In order to grow out out of the minicomputer league, ICT expanded the address space to 22-bits both
for data for and for instructions, with a bit of tweaking of the order code for indexed counting, and
a 48-bit floating point unit was added on the side, with an extra accumulator or two.
Meanwhile, IBM had the 360, which was a “proper” 32-bit computer with 32-bit words, but measured
in bytes to make the memory seem bigger, and the add-on floating point unit actually had 4 accumulators,
but it was only 32-bit and used a rather unwise number format.
So how would English Electric - Leo - Marconi (EELM) face the callenge.
Clearly KDF9 was a better starting point than the 1900 mini computer, so KDF10 should be a really good machine.
What it needed was a bigger address space, and more than 4 sets of time-sharing registers (multiple Q-stores, Nest and SJNS, say 18 or 16).
The key question is how to modify the order code to accommocate this with minimum disruption to
existing software.
The extra register sets are easily accommodated by trivial mods to =K3 and K7,
director-only instructions and then only used in a very few places.
What they actually did was introduce System 4, a copy of the IBM architecture.
Other manufacturers had taken a similar route in order to take advantage(?) of
IBM software which was available without having to buy an IBM machine.
Curiously, EELM then decided to replace the software and write their own.
What I would have liked them to do was make the KDF10
(in today’s language it would have been KDF9++, or perhaps in KDF9-speak it would be KDF10),
with its 16 register sets and a 23- or 24-bit address space.
I recall that I had a design at the time, but was far too junior to have a way of pressing it.
The order code would stay the same, but the Q-store format would split 16/8/24 for C/I/M.
It was extremely rare to need an increment bigger than 255, and it never seemed to me worthwhile forbidding the top bit
to be an address bit (so 24 not 23).
The only times that the Q-store increment needed to have 16-bits was in peripheral instructions, with
the start address in the increment field and the end address in the modifier.
The device number in the counter only needed 4 bits, except for the disc drive (again director-only).
So my KDF10 peripheral instruction had the start address in the modifier, the transfer count in the counter,
and the device number in the increment, allowing up to 256 devices.
I never designed the disc drive’s PMAQq instruction.
A little tweaking of our own FORTRAN compiler would be able to produce short loops.
Just think what LINPAC performace figures we could have achieved.
What about the depth of the nesting store?
We wrote our FORTRAN compiler as though the nest were infinite, and agreed that we would see
how it turned out in practice.
We had only one program that failed on an over-full nest, and advised the user to split an
assignment to a big long arithmetic expression
into two or three statements.
On the question of the 8Kword code size limit, the KDF10 would have almost all jumps relative, and a wider SJNS.
Long jumps would have been: FETCH-big-address; =LINK; EXIT;.
This is a bit like the IBM360 where big long jumps need multiple instructions.
A standard word (say E8) would contain the sequence =LINK; EXIT;, to which
one could do JSE8; with the destination address in the nest.
This would need a special absolute JS instruction.
All conditional jumps exist in pairs with initial syllables 200 and 220.
There is a thus a hole in the order code for the unconditional jumps J and JS,
which we can use for absolute jumps to locations in the first 8K words.
There are various advantages to relative jumps, especially position independence,
which comes in very handy for implementing multi-access systems, and TP systems in general.
We were already moving into an era where most binary programs came from compilers of FORTRAN,
Algol and the like, and to limit subroutines to 48 Kbytes would not have hurt much,
and in any case the compiler writers could hide it from the punters.
The equivalent limit on the IBM360 was 4Kbytes.
I envisaged that most binary programs would have a vector of entry addresses in low store,
and could dynamically load library packages into memory at load time.
We did a mod on KALGOL to generate code starting at an address around 2000, and program execution
started with an OUT1 to load the library.
We then discovered that most of the compile time of KALGOL à la EE was in assembling the Usercode library.
On our system, this was now only a stub of jump instructions into the indirection vector at the
start of the library module.
With position-independent code the library loading would be able to have several independent components.
It was a pipe dream and as the reality of George3 MOP system dawned,
and it became clear that the Eldon2 system on our KDF9 was at least as good as George3 Mk5.
George did get better.
The clair-voyants at Newcastle got and IBM360/67 and ran MTS.
We at Leeds installed an Amdahl 470/V7 in the last days of 1979.