70's computers

Chuck Guzis cclist at sydex.com
Wed Oct 24 11:38:46 CDT 2018


On 10/24/18 5:36 AM, Paul Koning wrote:
> 
> 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.  

You obviously haven't spent much time in SSD (Special Systems).  I
recall working on a transaction-oriented multiple-CPU system (tied
together with ECS) where the PPs were little more than I/O processors.
*None* of the main operating system code was in the PPUs, save, perhaps
for DSD.

The reason for this was quite simple--PPs are terrible when it comes to
block ECS transfers and having the PPs switch their attention between
tasks whose CM lifetime was measured in milliseconds was impossible.  We
had several PPUs dedicated to servicing disk requests for oceans of 844
drives, but they communicated directly with the CM resident OS, not
individual user tasks--no "stack processor"; requests were sorted and
prioritized by the CM OS.    We could run traditional batch jobs, but
that was essentially a hack of some SCOPE 3.1.6 code and it did not play
well with the major business of the system.  PP0, MTR's resident code
occupied about one printed page--it kept the time of day.

Communications were again handled with a PPU, but even that was
connected to several 1700s.

All of this was an outgrowth of TCM (Time Critical Monitor), done by a
fellow associated with the ROVER project.  You needed the CEJ feature
for this all to work.  None of this "stick a request in RA+1 and wait
around" stuff--far too slow.

Some of this was evolutionary--Greg and Dave's MACE was considerably
more CPU-oriented than was SCOPE.

You can see the same influence in 7600 SCOPE--there the PPUs are very
different, communicating via fixed memory areas in SCM.  There, they
really are nothing more than I/O processors.

Interestingly, when STAR came along, the Twin Cities crowd tried to play
the same game as the old SCOPE people did--put most of the OS into the
stations.  LRL didn't agree on that and moved most of the OS to a
message-passing resident CPU based scheme, and it was that system that
became the standard OS--and it was implemented in a variety of LRLTran,
not assembly code.

--Chuck





More information about the cctech mailing list