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

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:

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.

More likely it was just polling between instructions to switch between
the CPU code and the channel code. The 360/30 was a very small machine
by modern standards.

The DEC 12 and 18 bit machines offered DMA in two flavors called
one-cycle and three-cycle data break. The one-cycle would be familiar
now, the device grabbed the bus, provided the address and control bits
and then read or wrote a word. But in that era flip flops and counters
were expensive, so they had three-cycle. The device sent a fixed
address to the CPU, which then decremented the word at that address
and sent the device a "done" signal if the result was zero, otherwise
incremented the word at the next address and used its contents as the
address to read or write the data provided from or to the device.

It was like a very primitive channel that only knew how to do block
transfers. Three cycle was of course three times as slow, but for most
of the devices at the time, it was adequate.

The PDP-6 and KA10 had their own version of three cycle data break
which was too ugly to describe here.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly