Re: Architectural implications of locate mode I/O and channels

John Levine <johnl@taugh.com> writes:

On the smallest
360s, the channel was implemented in CPU microcode. When running fast
devices like disks the channel used so much of the CPU that the
program stalled, but it was worth it to be compatible with faster
machines. Even then, disk seeks or tape rewinds or reading cards or
printing on printers let the CPU do useful work while the channel and
device did its thing.

This sounds very much like hardware multi-threading to me: The CPU had
separate state for the channel and used its hardware for doing the
channel stuff when there was I/O to do, while running the non-channel
stuff the rest of the time, all without OS-level context switching.

The barrel processors implemented in the CDC 6600's PPs are another
variant of the same principle from around the same time, but using the
same hardware for such different tasks is a new twist.

Interestingly, this is one development that has not been repeated in
microprocessors AFAIK.  If they did not want to spend hardware on a
separate DMA device, they just let the software use polling of the I/O
device.  For the 8086 and 68000, I guess that patents may have
discouraged adopting this idea; when the patents ran out, they had
established an ecosystem with separate DMA devices.  And of course for
the early RISCs there was no way to do that in microcode.

IIRC some microcomputers (IBM PC I think) had dedicated central DMA
processors (but not on the CPU chip at first IIRC), but these fell
into disuse soon when the I/O devices that do lots of I/O (like disk
controllers) included their own DMA circuits.  Having the DMA on the
I/O device wliminates the overhead of first requiring the bus for
getting the data from the I/O device, and then another bus cycle for
storing it into memory (or the other way round).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>