Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Architectural implications of locate mode I/O
Date: Wed, 3 Jul 2024 15:34:06 +0300
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <20240703153406.00006ebe@yahoo.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 03 Jul 2024 14:34:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="97472cbdcdeeff421cb8fb1c89ea1198";
	logging-data="2302000"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+cUSryFEnmbIcYStgY4HH3wrq3C7Ed93E="
Cancel-Lock: sha1:8LwU+jFaFc5kb1icgXzC0CUl5fU=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 2645

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.