Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Architectural implications of locate mode I/O
Date: Tue, 2 Jul 2024 22:17:20 +0000
Organization: Rocksolid Light
Message-ID: <8bfe4d34bae396114050ad1000f4f31c@www.novabbs.org>
References: <v61jeh$k6d$1@gal.iecc.com> <v61oc8$1pf3p$1@dont-email.me> <HYZgO.719$xA%e.597@fx17.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1952855"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$RNNJW6FSm2xtQhX1SzA78OVJLDRpCXBFfoENegDzLJ5/ziquXCqnu
Bytes: 2429
Lines: 29

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.