Exceptions at basic block boundaries 542

Michel Hack physical the "table" (Set Lynn industry-standard it

on older machines ... there tended to be special key array ... in part because the feature was optional and orderable separately. except for 360-67, the 360s didn't have virtual memory support ... but you could order the optional storage protection feature ... which included the storage protection key array. this was basically 4bits per 2k bytes of real storage.

the ssk & isk instructions were privilege and available ... and i suspect that if the feature wasn't installed, ssk didn't do anything ... and isk just forced a zero value.

you could also optionally order storage protection feature with or w-o fetch protection. the default was just store protect. if you had the optional fetch protect ... it was a fifth bit in the storage key array ... which turned on-off fetch protection (using the same key value rules as store protect).

basically if storage protection feature was installed and a non-zero value was loaded into the PSW key field (a preivilege operation) ... then the non-zero PSW key field value had to match the storage (2k) area ptoection key.

360-67 required the storage protection feature be installed ... and they defined two addition bits per storage key (per 2k area of storage); one bit indicating storage area had been modified and the other bit indicate the storage area had been referenced. Bits could be reset using the same ssk instruction that set the storage key ... and interrogated using the isk instruction.

cp67 running on 360-67 provided virtual machine support ... including virtual 360-67 operation ... as a result it had to have private tables that shadowed the values the real machine values (for the virtual machine). cp67 for each 4k page location had an 8byte swaptable entry; basically two bytes of flags, two bytes that represented the virtual storage key values for the two 2k area keys, and a four byte field that gave the location of the page on disk (when it wasn't in memory). this was in addition to the 2byte PTE value.

any time cp67 would reset a change or reference bit ... it would first have to interrogate the current value(s) ... and save them to the virtual machines shadow in the coresponding "swaptable" entry. Anytime the virtual machine interrogated virtual storage keys (i.e. "isk" instruction) ... cp67 had to interrogate the real-value and OR it with the virtual machine backup value from the corresponding swaptable entry.

any time a virtual machine reset their virtual storage key change &-or reference values ... cp67 would have to first interrogate the real hardware value and OR the current hardware values with the saved cp67 values in the corresponding swaptable flag fields. it would then zero the hardware change &-or reference values ... and set the value specified by the virtual machine in the shadow key fields in the corresponding swaptable entries.

in effect, there were different change and reference shadow bits in a swaptable entry ... one pair for cp67 and one pair for the virtual machine. Anytime the virtual machine reset their bits ... the real hardware bits would be or'ed with the cp67 shadow bits and the real bits and the virtual machine shadows bits were zero. anytime cp67 reset changed &-or reference bits ... the real bits had to be interrogated and OR'ed with the virtual machine shadow bits before zeroing cp67's shadow bits and the real hardware bits.

If either cp67 or the virtual machien interrogated the bits ... the real hardware bits had to be OR'ed with the corresponding shadow bits.