On Oct 23, 2018, at 9:47 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
On 10/23/18 6:10 PM, ben via cctalk wrote:
The 10 or so PPU units.
Ben.
Early SCOPE and COS also put the operating system in those, leaving the
CPU for real work. But for I/O, not that much different from IBM
"channels", no?
Very different. PPUs are real computers, vaguely like a PDP-8 in fact but quite fast. The
PPUs have major roles in the OS throughout the 6000 series, not just in early versions.
And not always just the OS. Consider PLATO, which in a sense is an application... with a
set of PPU programs to help it. It would drive 1000 terminals (600 logged in
concurrently) running highly interactive text and graphics applications including early
multi-user games, on a pair of 6500 machines. Those are, on good days, roughly 1 MIPS per
CPU. Feeding data to and from the 1000 terminal lines was the job of just a single PPU.
IBM channels are (from the programmer point of view at least) merely hardwired controllers
no different from a DEC UDA50 or for that matter a CDC 7054 disk controller.
The fact that PPUs are general purpose computers means a smart programmer can make the I/O
system do things the manufacturer did not believe possible. CDC used 2 to 1 sector
interleave on its disk drives (844, which is like the DEC RP04) because the PPU could not
keep up with sector data arriving at full speed. But Don Lee at University of Illinois
made that work in the PLATO system by deploying a pair of PPUs controlling the disks
together ("ping" and "pong").
That said, I think Ben is overestimating the impact of the PPUs on the overall system
performance. A lot more comes from the CPU architecture. The instruction set, of course
(arguably the first RISC). And especially the multiple functional unit highly overlapped
design, with some very clever tricks in it. Consider that a 6000 would do a process
context switch with a single instruction, in about 4 microseconds -- in 1964. Part of the
reason that works is that it takes advantage of the properties of core memory in a way
that few other machines do.
paul