intel's Vanderpool and virtualization in general 1670

almost. the 370 virtual memory architecture came out long before there was actually hardware built for it ... and it had numerous differences (table formats, instruction op code, etc) from the implementation in the 370-67. so a joint project was started between endicott (building 370-145) and science center (originated cp67) to create a special kind of virtual machine under cp67 that simulated 370 virtual memory virtual machines (as opposed to simulated 360 virtual machines).

so this was one of the first major production uses of the internal network software ... also developed at the science center.

after there was cp67 kernel that had the support for 370 virtual machines, then another set of modifications were made to cp67 ... so that it the kernel would conform to 370 relocate tables and instructions (rather than 360).

now science center had a problem ... it was providing semi-open time-sharing access to non-corporate employees (mit, bu, harvard, etc students). it was also hosting some extended APL access by people from corporate hdqtrs that had loaded the most sensitive and most highly clbuttified corporate data on the machine for doing business modeling and what-ifs (in the era, apl was used for a lot of the stuff that spreadsheets are now used for).

in any case there was an issue if the cp67 kernel that provided virtual 370 machines was run on the bare hardware ... there might be some of the area students stumble across the features (and they were trying to fairly tightly control the secret of virtual memory for 370). in any case,

cp67-l kernel was run on bare hardware providing general computing access cp67-h kernel was run in a 360-67 virtual machine and it provided 370 virtual machines cp67-i kernel was run in a 370 (virutal memory) virtual machine cms was run in a 370 virtual machine

so that has been running for something like a year. endicott engineers finally claim that they have an 370-145 with engineering changes to support virtual memory and it is ready for some testing.

some people go to endicott and install a cp67-i kernel and attempt to boot ... and it fails. so some amount of investigation ... and it turns out that the kernel is correct ... but the engineers had reversed the implementation of the "B2" opcodes for PTLB (purge lookaside table) and RRB (reset reference bit). so some quick patches in a couple places ... and the kernel boots and runs fine. also software designed to the architecture spec runs correctly in virtual machines ... since the virtual machine emulation of the "B2" opcodes conform to the official architecture ... it is only the real kernel use of the functions that has been changed to conform to the real machine.

current description of PTLB

you have to settle for current description of RRB-extended:

part of the difference was that 370 supported both 2kbyte pages and 4kbyte pages ... so RRB operated on 2k blocks of storage. support for 2k byte pages has since been dropped.

--