Re: Architectural implications of locate mode I/O

On Wed, 03 Jul 2024 13:08:31 +0100
Bill Findlay <findlaybill@blueyonder.co.uk>  wrote:
>

On 2 Jul 2024, MitchAlsup1 wrote
(in article<8bfe4d34bae396114050ad1000f4f31c@www.novabbs.org>):
>

Once you recognize that I/O is eating up your precious CPU, and you
get to the point you are willing to expend another fixed programmed
device to make the I/O burden manageable, then you basically have
CDC 6600 Peripheral Processors, programmed in code or microcode.

>
The EE KDF9 (~1960) allowed up to 16 connected devices at a time.
They all did DMA, interrupting only at the end of the transfer.
Slow devices accessed the core store for each character,
fast devices did so for each word.
>
This was mediated by one of the KDF9's many state machines,
I/O Control, which multiplexed core requests from devices
and interrupted the CPU at the end of a transfer
if the transfer had been initiated by a program
of higherCPU priority than the one currently running,
or if there was a possibility of priority inversion.
>
I/O Control also autonomously re-issued an I/O command
to a device that reported a parity error
if that device was capable of retrying the transfer
(e.g. MT controllers could backspace a block and re-read).

>
That sounds quite advanced.
But when I try to compare with contemporaries, like S/360 Model 65, it
appears that despite advances KDF9 was not competitive to maximally
configured 65 because of shortage of main memory.