70's computers
Paul Koning
paulkoning at comcast.net
Wed Oct 24 07:36:39 CDT 2018
> 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
More information about the cctalk
mailing list