Binyamin Dissen wrote:
A SAM** should not require extra cycles and should not cause problems in the
predictive execution.
How can you be so sure???
Chip "real estate" is at a premium right now. Many instructions that
used to run fast (e.g., TR/TRT) have been moved into millicode because
there just simply isn't room for them any more. Now they run relatively
slowly. Such trade-offs are increasingly common.
It would take considerable extra programming in the hardware to be able
to handle more than one AMODE state in the pipeline simultaneously. And,
as infrequently as AMODE changes are normally expected to occur, if it
were *my* design -- which it most certainly isn't -- I would *not* be
inclined to waste valuable "real estate" on the chip trying to support this.
The easy/cheap thing to do is to start over when any PSW change
affecting address translation occurs. That's what I would do.
When you ran into delays, was it between 24 & 31 using BSM (which is not
predictive) or was it with the SAM** instructions?
Mostly SAMxx. But, once again, I encourage you to run your own
benchmark. Empirical evidence is the best kind.
--
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
