Binyamin Dissen wrote:
A key change caused a slowdown? Interesting.
Yes. And PoP gives no clue as to why that would be the case. I *assumed* it was because instructions executed later in the pipeline must be re-processed using the new key.
I have lots of code where it switches to key0 for a few instructions.
I used to do that for accessing fetch protected storage in other keys. I now use MVCSK/MVCDK for all such accesses.
With respect to AMODE changes, the outcome of pointer-defined linkage (e.g., BSM) will not be known until the final stage of execution. However, it seems to me that the outcome of a SAM31 or SAM64 instruction should be known at instruction decode time. That would lead me to believe that the pipeline *might* require flushing only when the old, in-line BSM technique -- used since XA days -- is employed. Or, maybe the current processor generations don't _yet_ distinguish between the two approaches in terms of how the pipeline is managed.
-- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- 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
