Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Architectural implications of locate mode I/O
Date: Wed, 3 Jul 2024 19:32:20 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <v64903$2b182$1@dont-email.me>
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> <DlhhO.1222$rF4c.905@fx04.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 03 Jul 2024 21:32:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b5497bf9fd0a6643e02995398e6baa21";
	logging-data="2458882"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+RlXszmTNX0sySrLjpF+vWKKCK+yEZiaY="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:ajJHaACyPHRp4YECSyMsrnPfmqE=
Bytes: 3325

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)