Path: ...!feeds.phibee-telecom.net!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 17:41:26 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <v642g5$29pie$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 03 Jul 2024 19:41:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b5497bf9fd0a6643e02995398e6baa21";
	logging-data="2418254"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18vUkY6bUg6QjfRaV9zE8YiiJpYnXudPSc="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:G11RLdLYB+g82sani++L1PP4Upo=
Bytes: 3473

MitchAlsup1 wrote:

> Scott Lurndal wrote:
> 
> >Thomas Koenig <tkoenig@netcologne.de> writes:
> >>John Levine <johnl@taugh.com> schrieb:
> > > 
> > > > The 709 introduced data channels in 1958 which allowed the CPU
> > > > to do other stuff while the channel did the I/O. Wikipedia says
> > > > the first I/O interrupt was on the NBS DYSEAC in 1954 but it's
> > > > hard to see how an I/O interrupt would be of much use before
> > > > channels. Once you had a channel, I/O buffering made sense,
> > > > have the channel read or write one area while you're working on
> > > > the other.
> > > 
> > > Not sure what you mean by "channel" in this context - hardware
> > > channels like the /360 had, or any asynchronous I/O in general,
> > > even without hardware support?
> > > 
> > > Sending the next character to a teletype after the user program
> > > fills a buffer and waiting for the next interrupt to tell you it's
> > > ready makes sense, without a busy loop, makes sense anyway.
> > 
> > Although in the mainframe era, most terminals were block-mode
> > rather than character-by-character, which reduced the interrupt
> > frequency on the host (often via a front-end data communications
> > processor) at the expense of more logic in the terminal device.
> 
> 
> 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.


There is a lot of design space between having the CPU do the I/O itself
and having a separate programmable processor.  Since the minimum
requirements are a DMA, a way to request memory access, and a little
logic to differentiate peripheral commands and status from normal data,
and a way to indicate I/O completion (e.g. generate an interrupt), you
could do all this in a fairly small amount of dedicated hardware.

While the PPs were an elegant solution, they were more than what was
required. Similarly, the IBM S/360 channels were way overkill for
pretty much all I/O except for using CKD disks.  In the day, different
mainframes used various implementations of this idea to do I/O.



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