Path: ...!eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Bill Findlay <findlaybill@blueyonder.co.uk>
Newsgroups: comp.arch
Subject: Re: Architectural implications of locate mode I/O
Date: Wed, 03 Jul 2024 15:02:58 +0100
Organization: none
Lines: 41
Message-ID: <0001HW.2C359192001A9DBC3060E538F@news.individual.net>
References: <v61jeh$k6d$1@gal.iecc.com> <v61oc8$1pf3p$1@dont-email.me> <HYZgO.719$xA%e.597@fx17.iad> <8bfe4d34bae396114050ad1000f4f31c@www.novabbs.org> <0001HW.2C3576BF001454603060E538F@news.individual.net> <20240703153406.00006ebe@yahoo.com>
Reply-To: findlaybill@blueyonder.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: individual.net 2eK1Xg6oOL8KDT2uN/ku4Q/4Z5UiUUaEvt5RBLvaNfJx8iu1WM
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:Jev+LAETnKZf2/o/1zfE43FJM0g= sha256:aOFxQO8iogwMlq/mxTlqMa5h9dVYdsvNve8eRP186AI=
User-Agent: Hogwasher/5.24
Bytes: 2733

On 3 Jul 2024, Michael S wrote
(in article <20240703153406.00006ebe@yahoo.com>):

> 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.

Yup.

-- 
Bill Findlay