Re: Architectural implications of locate mode I/O

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)