70's computers

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