Implementation is model dependent. The hardware has to preserve enough information to comply with the architecture. I know of no reason for MVS to purge the i-cache under normal circumstances.
If the I-cache includes key and STO then I know of no reason not to share it. There is no need to validate the key in the cache after SPKA; what is necessary is to vallidate if prior to final execution. Consider code that sets the key to 8, does something, then sets the key to 9. Do you really want to invalidate and refetch the second block of code after the first SPKA. Now, the designers have to make tradeoffs between circuit complexity and performance, so there might be purges that are not logically necessary. But, again, such matters are model dependent. If there is speculative execution and an instruction is not in the right key, then it has to be rolled back. But it's only the last key change before the instruction that matters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Binyamin Dissen [bdis...@dissensoftware.com] Sent: Tuesday, February 2, 2021 7:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE KEY of loaded executable On Mon, 1 Feb 2021 13:45:45 +0000 Seymour J Metz <sme...@gmu.edu> wrote: :>There's no reason to flush the cache, and doing so would be a major performance hit. With luck there an IBM Systems Journal article or redbook on the I-unit of current processors; if not, there should be. How does the cache work? Does MVS preserve the I-cache if a different thread is executing the same address (or share the I-cache between different CPUs)? Does it validate that the source of the cache is accessible whenever the SPKA is issued, i.e., does the cache have key and fetch protect bits? Any pre-executed instructions will have to be rolled back, correct? -- Binyamin Dissen <bdis...@dissensoftware.com> http://secure-web.cisco.com/1g-7fia0NcdlvAUroS_CZ7R2AV8DyMZE3b1LPPPJTzH79cOlOAeTaBWLpdK2p0t96V4ZtMYCXOScGlyngDF2ZCOcp37oXfcQ0DvM7CZE2DFnVQVu8OpKrEDMF_0adlAYM4D1vkL4UDIECC4TVpSFHAtakw5toKlh_6kp0QNMiP98Vzt-5RUhWDlhSGp2PhvtrpMXZKOGvIp_v5GYPGcUoZOMgFCb2tSNheQPRnw4--qvNLzW3owJLyusoxUr12y3ShiwjXHPKX93BdEvFHgG2jn7H-HOPaqTZSHGPJ9it92SaHFGlfQoavXI5kbLm3XYX7hpsvr7aIVeroAui8xPzsnHh0ZYB7LksDt0p5E4kJQ8E6gAukjDTWMCYbVOwv-G3Ltle8YBZjLt-NqDaENkcTAwg0Xuv9-utb8O_dL8o-pkecpsQhf2YV-MRZGOX3LoT/http%3A%2F%2Fwww.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
