Charles Mills wrote:
I'm not sure I would ask for stack support in hardware - that tends
to be more expensive than you really want.
I was thinking of hardware support for stack over/underflow
detection/diagnosis. A lot easier (in my hardware ignorance <g>) to have
that detection with some sort of "fence register" in hardware than having to
have compare logic at the front of every subroutine, right at the moment
when the subroutine is shortest on registers and diagnostic resources.
We do this in our infrastructure by page protecting the page(s) before
and after the acquired stack area. If you use storage acquired with
IARV64 for your stack, you can establish a "guard" area.
FWIW, when I last implemented the sort of "vendor framework" that others
have referred to, I know I solved the "how to diagnose" issue by having a
stack error at the front of a subroutine branch to some specific odd address
in low memory: C stackptr,stackfence BL X'BAD' as I recall. Low overhead,
foolproof diagnosis.
With relative branch, we have converted all such "should not occur"
branches to "Jxx *+2". The 0C1 abend PSW points right past the offending
branch instruction. Much better than branching into page zero.
--
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
