Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Architectural implications of locate mode I/O
Date: Tue, 2 Jul 2024 20:36:24 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <v61oc8$1pf3p$1@dont-email.me>
References: <v61jeh$k6d$1@gal.iecc.com>
Injection-Date: Tue, 02 Jul 2024 22:36:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4994c64232c7863e8ce44f84cc33492a";
	logging-data="1883257"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/8xyfyB6KjCL8/8p6hlJreC5A0U8Z5BlQ="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:yRCddAbIfDJX8hIAW4P3slyNQck=
Bytes: 1664

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.