The ICL 7502 - The Mill (Processor)
The ICL 7502 changed but little over the years, and its processor board never changed in its basic implementation. To a generation used to a new Intel CPU chip every couple of years this may seem surprising, but if the system was properly specified at the outset there would be no advantage in making it go faster. It didn't do work for the user who sat at one of its VDUs, it only forwarded their messages and collected a response.
The processor board was known as the P001, and the name suggests that it was the first in a series of boards produced by a new PCB fabrication plant. The design originated in 1975-6 at Kidsgrove, around the time the first 2900 'New Range' mainframes were going into production, and it is certain that the boards were of similar technology to those being assembled into the 2956 systems by the end of the seventies. The boards were quite advanced, with multiple layer construction, through-plated component positions and medium-scale integration TTL chips.
The processor was implemented as a microcoded, bit-slice engine with 4 x 4-bit ALUs. It was clocked at 10.752MHz, which gave a basic instruction cycle of around 4 microseconds. I say basic because some instructions were designed to operate on blocks of memory and were interruptible, making them not unlike a software loop implemented in hardware. There were duplicated SCRATCHPADS of 16 x 16-bit registers X0 - XF which were all available for arithmetic, and only one with a special purpose - XF was the programme counter. There was no reason why XF could not appear as the destination of an arithmetic operation, but it might have been difficult to keep track of what would be a 16-bit computed JUMP instruction. Under normal circumstances the microcode would fetch register operands from either SCRATCHPAD, but the result would be written to both sets.
This is a good point to mention a quirk of the programme counter XF. It was only 14 bits long, and its top two bits were used to indicate the MILL STATUS:
INTERRUPTS from I/O devices caused modification of the way that the CPU operated, and so we must consider the MACHINE-STATES which allowed protection for special processes and gave rise to some interesting possibilities. Five STATES were possible, and only STATES 1 - 3 were interruptible. STATES 0 and 4 were non-interruptible, but STATE 4 was only entered after an interrupt and in STATE 4 one SCRATCHPAD register set was frozen. This had the effect of preserving the point of operation where the interrupt occurred, so at the end of the interrupt processing it was only necessary to reload BOTH SCRATCHPADS from the frozen set for processing to resume as if nothing had happened. The complication was that in STATE 4, certain instructions were unavailable, or at least redefined. STATE 3 was fully interruptible and was regarded as the normal state for non-critical code to be executed. The switches between machine STATES were executed as part of the instruction to DUMP or RECOVER SCRATCHPAD, and as there were only two bits available for the new STATE it was not possible for the user to switch to STATE 4.
One I/O device was potentially lethal: the WATCHDOG TIMER. If an interrupt from this device was not answered within 50% of its normal period (3.3 millisecond) the CPU would be forced through word ONE, which was the same as a power-up reset. Experimental bit twiddlers soon encountered this hurdle! Under normal circumstances, this interrupt worked as a sanity check to ensure that no process was looping hopelessly in a non-interruptible machine state - now show me a microprocessor that has that level of protection!
As a machine code primer we will decode the first four words of the ROM, which was cleverly overlaid into the bottom of the store
range and directed the programme counter to the coded interrupt handler:
Interrupts are not only caused by devices seeking attention, but by an attempt to access memory which is not installed or an attempt to do I/O when the system is not operating in a PRIVILEGED STATE. So there is protection against violating memory as well. The interrupt caused by I/O in STATE 3 (normal processing) was used to implement a series of functions such as software stack calls as part of the KERNEL system. The beginnings of a fairly powerful EXECUTIVE, in fact. And bear in mind that Kidsgrove-designed KDF-9 computers were still earning a crust when this system was visualised...........
As a diagnostic aid the CPU could be plugged in piggy-backed on an extender card which had interfaces to a suitcase-sized test unit. This could be used to do all kinds of diagnostic work, single stepping the CPU or the microcode. The Mark II unit had a cassette tape unit which could load diagnostic software. The unit added to the 7502 all the hand switches that you would normally find on a 'real' CPU of the day. I am told that this unit, which was rather like the In-Circuit Emulation of later years, was developed by Eric Hotine and proved to be absolutely indispensable in developing the KERNEL system which handled the interrupts and core facilities.