Cross-posted to IBM-MAIN, VMESA-L, and VSE-L.
IBM has accomplished a great deal in recent years in extending the instruction set. One of the most useful enhancements, IMHO, is the immediate-and-relative-instruction facility. However, there is one area which I feel remains a weakness. That area is storage key handling. With virtually unlimited memory (please forgive the pun), we are still limited to a 4-bit storage key. It is obviously unreasonable to simply expand the storage key. I have a better idea. (I hope). There are three privileged instruction which are used to manipulate storage keys. The ISKE (Insert Storage Key Extended) instruction permits the invoker to obtain the storage key of a designated page of real storage. The IVSK (Insert Virtual Storage Key) instruction permits the invoker to obtain the storage key of a designated page of virtual storage. The SSKE (Set Storage Key Extended) instruction permits the invoker to set the storage key of a designated page of real storage. Now, these instructions actually manipulate a byte, of which one is assigned to each page of real memory, and of which: * Bits 0-3 Storage Key * Bit 4 Fetch * Bit 5 Reference * Bit 6 Change * Bit 7 Reserved I propose to extend the functionality of these instructions by making use of Bit 7 of this byte. When set, this bit would indicate that there is associated with the designated page of real memory an extended storage key, which would consist of a byte (bits 16-23 in 31-bit mode or bits 48-55 in 64-bit mode) which would be located in the same register as the non-extended storage key. When a page is referenced and Bit 7 of the non-extended storage key is set to zero (0), everything would continue to operate as it does today. When a page is referenced and Bit 7 of the non-extended storage key is set to one (1), an additional extended storage key access check would be performed. The extended storage key access check would consist of using the extended storage key as an index into an extended storage key mask, which will consist of 256 2-bit entries, or a total of 64 bytes. In each 2-bit entry, the first bit will indicate that read access is permitted, and the second bit will indicate that write access is permitted. Let me emphasize that the extended storage key access check would NOT be performed unless the PSW-key access check was successful. The extended storage key access check would NOT be performed when the PSW key is zero (0). I propose that a new instruction be introduced which will permit the invoker to set the extended storage key mask and to extract the current extended storage key mask. Finally, I propose that the Entry Table be extended such that one of the unused words can be used to point to an extended storage key mask which would be loaded automatically during Program Call (PC) processing. Now, what would this enhancement buy us? I see it being principally used for storage subpools. We can establish far greater storage access granularity than is now possible. Please let me know what you think. John P Baker Software Engineer ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
