What ever happened to Tandem and NonStop OS 1977
cp67 had to do this with 360 privilege instructions for virtual machine support (so that the privilege operation followed virtual machine rules ... rather than real machine rules).
What ever happened to Tandem and NonStop OS 1983
Which, IME, dooms it because there is no long range plan for extending the feature included in the design. However, this is how we used to work and...
for most environments, end-users aren't directly focused on kernel overhead. on cp-67 was constantly out front ... with processor utilization constantly tracked and broken out by time in the kernel and not-in-the kernel. this was further highlighted ... that end-users could see the difference between running on the "real" hardware and running in a virtual machine (i've periodically commented about other environments where end-users hardly give a second thot to why can't they run the same application w-o the kernel). in any case, very early on as an undergraudate ... i rewrote significant portions of the cp67 kernel to reduce such overhead. this is an old posting giving part of a report I gave at the aug. '68 SHARE meeting in boston
where i had reduced the total time spent in the kernel from 534 seconds to 113 seconds
early in development of 370 ... there was joint project between cambridge
and endicott to create 370 virtual machines under cp67 (on real 360-67). the architectures were similar ... but 370 had some new instructions ... and the virtual memory tables had some differences. the new instructions (both privileged and non-privileged) had to be simulated and some number of things also operated differently (like the virtual memory table format).
complicating the implementation was that the cambridge system also provided time-sharing services to some number of students in the boston area ... and 370 hadn't been announced (and all information about it had to be kept strictly confidential).
the implementation of 370 virtual machines had to be done on the cambridge system ... w-o allowing any hint of 370 to leak out.
as a result ... the modified cp67 kernel supporting 370 virtual machines ... didn't actually run on the real hardware (which might have it exposed to non-employees) ... but ran in its own 360-67 virtual machine. this modified cp67 kernel provided 360 w-o dat (dynamic address translation ... aka virtual memory), 360 w-dat (i.e. 360-67), 370 w-o dat, and 370 w-dat ... depending on the options selected.
once that was running ... then a cp67 kernel was modified to run on 370 w-dat machine (using new privilege instructions and the 370 flavor of virtual memory tables rather than 360-67 version).
the resulting (recursive virtual machine) environment was then
* 360-67 real hardware * cp67-l kernel providing virtual machines and time-sharing service * cp67-h kernel running in 360-67 virtual machine and providing both 360 and 370 virtual machines * cp67-i kernel running in 370 virtual machine and providing 370 virtual machines * cms running in 370 virtual machine
the above environment was operational a year before the first engineering 370 with hardware dat support was operational (a 370-145 in endicott). in fact, the cp67-i kernel was brought in as sort of software validation of the machine.
when cp67-i was first booted on this engineering 370-145, it failed. after some diagnostics, it turned out that the engineers had implemented two of the new 370 DAT instructions reversed (b2xx opcodes, RRB and PTLB instructions had op-codes reversed). The cp67-i kernel was patched to correspond to the (incorrect) hardware organization and rebooted (and everything ran fine after that).
later in the vm370 time-frame starting with 370-158 ... sthe hardware for ome of the 370 privilege instructions were modified so that it could operate in two-modes ... 1) real machine mode and 2) virtual machine mode. the vm370 kernel ran all virtual machines in problem mode ... which resulted in exception interrupts into the kernel whenever a privilege-supervisor state instruction was encountered. The kernel would then have to emulate the instruction and return control to the virtual machine. The 370-158 introduced a new machine state flag ... which indicated that things were running in virtual machine supervisor mode. The hardware for some number of privilege instructions was then modified so that the instruction would be directly executed (according to virtual machine architecture, rather than real machine architecture) rather then exception interrupt into the kernel.
The ECPS work for 370 138-148 expanded on that work in two ways 1) added virtual machine mode support for additional privilege instructions (not done in the 370-158 effort) and 2) new privilege instructions to speed up vm370 kernel operation.
The low and mid-range 360s-370s were vertical microcoded machines ... instructions looked very much like simplified machine language. THe technology avg. about ten microcode instructions executed for every 370 instruction. A kernel microcode performance buttist was to take high-use code paths in the vm370 kernel and recode them directly in microcode (getting approx. 10:1 performance boots). Each code sequence in the vm370 kernel would then be replaced with a single new instruction (that effectively invoked the new microcode implementation). Analysis for this first involved a frequency analysis of kernel paths ... and then sorted by aggregate time ... picking out the most highly used 6k bytes of kernel paths.
A summary of the initial analysis is given here
where the highest used 6k bytes of kernel path ... accounted for 79.33 percent of total kernel end time (giving about a 10:1 elapsed time Debt Reduction when moved directly into microcode). misc. past posts on this topic:
... an anecdote about 370 dat information leaking out.
the first 370s were announced and shipped w-o virtual memory even being mentioned. however there was a news article that appeared giving some details about 370 dat. there was also speculation about 370-145. the 145 had several rows of lights given various processor state indications. the label for one of these lights was "xlate" ... even before dat was announced (given rise to speculation that xlate stood for dynamic address translation).
What ever happened to Tandem and NonStop OS 1978
Andrew Swallow SNIP I'd really like to know what that 6 x 8086 box was, I am interested in Frankenstein hardware. :) Sigh, there...
investigation into the basis for the news article turned up that they had obtained a copy of a confidential document discussing various details about 370 dynamic address translation facility. as an outgrowth of the investigation, all copying machines in the corporation were retrofitted with small serial number glued underneath the glbutt ... so that it showed up on all copied pages (you might not be able to tell who made the copies ... but you could identify which machine the copies were made at).
What ever happened to Tandem and NonStop OS 1980
Well, tend to, but are by no means guaranteed to ... I've used multiprocessing (as in, 2 to 8-way SMP RISC UNIX) systems that weren't at...