Re: Architectural implications of locate mode I/O

Scott Lurndal wrote:

Michael S <already5chosen@yahoo.com> writes:

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.

 
The contemporaneous Burroughs B3500 I/O subsystem
fully supported asynchronous DMA transfers with no
CPU intervention.

snipped description

Yes, that is an example of the kind of thing to which I was referring
in my response to Mitch's post.  A question.  Was all of this pure
hardware, or was it microcoded?



--
 - Stephen Fuld
(e-mail address disguised to prevent spam)