> >A SAM** should not require extra cycles and should not cause problems in > the predictive execution. > > Still, it's hard for me to imagine that a few extra cycles for a SAM* > instruction would have a measurable performance impact unless there were > millions of them issued in a short time. Even then, the effects of cache > misses would likely be far greater.
Play computer for a moment. Imagine you have a pipeline where you're fetching instructions, decoding them, fetching operands and routing them to execution units, all in parallel. You end up with a whole lot of stuff in the pipeline at any time. Now think about where the parts come from. You have to translate the next instruction address from the PSW before you can fetch the instruction. Then you have to translate the instruction operand addresses before you can fetch the operands... every time you translate an address the amode (and asc mode) has a material effect on the interpretation of the address. It equally validly be interpreted as a 24, 31 or 64 bit value. If you change the amode then any addresses (opcodes or operands) that had already been translated ahead of the actual PSW location might no longer be valid. The same applies to a change of ASC mode, or PSW key. They each impact where the operands are fetched from and whether they could even be fetched (or completed results could be stored) so the machine's reaction is to stall that whole pipeline process until the answers are known. There isn't any magic. But a lot of the machine's overall performance comes from the overlap in the pipeline. The more often you stall/flush that pipe, the less overall throughput you're going to have. Hence the perception that certain operations (like SAM, SAC, or SPKA) are "slow". CC ---------------------------------------------------------------------- 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
