Exceptions at basic block boundaries 543
in much the same way that cp67 had to maintain "shadow" virtual keys for virtual machines ... cp67 also had to maintain "shadow" segment & pagetables.
virtual machine would have "virtual" segment and page tables that mapped 2nd level virtual addresses to address of the virtual machine. cp67 would use virtual memory hardware to have virtual machine pagess at arbitrary real addresses.
when emulating a virtual machine operating system that supported its own virtual memory ... cp67 would build a shadow set of segment and page tables ... and use the DAT look-aside buffer hardware rules for managing the entries in the segment and page tables. Effectively, the shadow tables started with all the invalid bits set. the operating system in the virtual machine would load pointers to its memory translation tables and start end ... which would immediately result in a fault that was fielded by the cp67 operating system. It would emulate the operation of TLB hardware for fetching the entry from the table in the virtual machine ... and then run it thru the "1st level" tables that mapped virtual machine addressed to real machine addresses (akin to the process that hardware TLBs use for loading entries).
Any time there was a 1st level virtual memory page replaced ... and the corresponding "real" PTE invalidated ... then all the shadow PTEs also got invalidated (since there wasn't a reverse mapping between individual first level tables and shadow PTEs). The emulation had quite a bit more reasons for invalidating shadow PTEs that possibly real hardware TLB might have ... akin to previous discussion where 168 had to replace a STO entry in the STO-stack and then all corresponding TLB entries that had been buttociated with the previous STO-stack entry.
the process was made recursive. there was a joint project between the science center
and endicott to produce a virtual machine implementating 370 virtual memory architecture definition (some of the bits in the tables were different from that defined in 360-67, as well as control register useage, and some of the instruction definition).
This was before 370 virtual memory hardware was available and-or even virtual memory feature had been announced publicly.
The cambridge machine offered somewhat open time-sharing service
Exceptions at basic block boundaries 544
360-67 and 370 had hirrarchical tables ... slightly different ... enuf to make virtual machine implementations of the different tables something of a pain. 370 architecture...
that included various univ. students in the cambridge area (BU, MIT, Harvard, etc). the possibility of virtual memory for 370 was considered an extremely confidential corporate secret.
Exceptions at basic block boundaries 546
Eric P. working set tended to buttign a task a set number of real pages. when a task faulted, local LRU replacement would select one of the...
There are a number of places in the world where the rich and poor world meet at some sharp borders. The US has...
so there was the normal cp67 (cp67-l) running on the bare 360-67 hardware.
Exceptions at basic block boundaries 545
360-67 & 370 used shared segments for sharing of pages ... i.e. implicit only one PTE per page frame (multiple different...
there was a modified version of cp67 (cp67-h) that ran in a 360-67 virtual machine ... and emulated the rules of 370 architecture definition ... rather than emulating the rules of 360-67 architecture definition .... however it mapped the 370 virtual machine formated PTEs into "shadow" tables that were in 360-67 format.
there was a highly modified version of cp67 (cp67-i) that ran in a 370 virtual machine ... that used 370 control instructions and 370 virtual memory architecture tables.
finally there was a cms that ran in a 370 virtual machine ... so the scenario was:
360-67 real hardware with real virtual memory support cp67-l ran on the 360-67 providing 360 & 360-67 virtual machines cp67-h ran in a 360-67 virtual machine providing 370 virtual machines cp67-i ran in 370 virtual machine providing 370 virtual machine cms ran in a 370 virtual machine
Hi, We have frequently discussed outsourcing here, and I thought you might be interested in the following which appeared in a mailing list I subscribe to. I...
Outsourcing" - which has become synonymous with sending American jobs to India or China ... +--------------- (*sigh*) Yes, sadly, it has -- a terrible case of vocabulary drift. "Outsourcing" *used* to mean simply farming out some of the work...
the above was operation and in regular use a year before the first 370 engineering machines were available with virtual memory hardware support.
360-67 didn't have a specific instruction for invalidating the hardware look-aside buffer. reloading the control register that was used for the virtual memory table pointer ... did flush all the entries in the look-aside buffer.
360-67 also didn't have separate instructions that allowed testing-changing page reference and-or changed bits. The bits were attached to the storage protection key array ... and so the standard isk & ssk instructions had to be used for accessing and manipulating the reference and change bits.
the original 370 virtual memory architecture defined PTLB (purge look-aside buffer), ISTE (invalidate segment table entry), and IPTE (invalidate page table entry). All three instructions were defined to also operate consistently on all hardware look-aside tables in a multi-processor configuration.
the low-end and mid-range 370s were primarily microcode. The 155 & 165 required extensive hardware for virtual memory support. Since 370s started shipping before virtual memory hardware was either announced or available. At one point the 165 engineers noted that they could ship basic virtual memory hardware support six months before they could have the "full" 370 virtual memory architecture supported. A business decision was made that all the extra features would be dropped from the 370 virtual memory announcement (for all 370 models ... even those models that had the extra features already implemented). PTLB was retained but ISTE and IPTE instructions were dropped. At least w-PTLB the flushing of the look-aside buffer was divorced from the instruction that changed the active virtual address apace (which was combined in the one instruction on 360-67).
370 also introduced the RRB instruction which tested the reference and change bits ... set the instruction condition code appropriately and zero'ed the reference bit. This was more efficient than retrieving the full key (w-isk), checking the specific bits, and resetting the key (w-ssk). the deficiency of the isk-ssk scenario was that it could miss bit state in multiprocessor environment ... where the RRB was defined as being multiprocessor consistent.