Tom Schmidt wrote:
My reaction is similar to yours, Ed. I had been wondering about the need for some kind of "come from" display when IBM brought branch relative long instructions to the architecture. The R15/R14 game seems like it falls apart if the arrival at location 0 (or just arbitrary low storage) came about because of a branch relative (jump) or worse, a BR-long.
I'm glad you agree with me, Tom. But, I honestly don't see how the advent of relative branch has compounded this long-standing issue in any way. I consider the possibility of a relative branch becoming "wild" to be quite remote. (One of their chief benefits!) Remember, they don't depend on a GPR being loaded correctly and/or an associated USING being properly specified. They are always relative to the current PSW.
For example, ,'BC 15,0(0,0)' will definitely go to location zero and leave no linkage trail in a register. How would you even code (on purpose or by accident) a BRC or BRCL to branch to location zero? Likewise, 'BAS xx,0(0,0)' will definitely go to location zero, but there will be a linkage register trail. Again, I don't see how you would even code the equivalent relative instructions BRAS or BRASL to branch there.
Having the last successful branch displayed in dumps will help (as long as the "branch from on high" isn't followed by a random branch down low before the abend strikes; then all bets are off without an itrace).
Agreed re: a wild branch to a branch. In my experience, that's quite rare. Having the processor remember one branch instead of the last 'n' branches will probably help with 99% of the hard-to-diagnose wild branch cases. For the others, you could say we're still one branch closer to knowing what happened. :-\
BTW, what is itrace? Do you mean system trace with branch tracing enabled? That won't trace the above instructions anyway. It traces only BALR, BASR, BASSM, BSA, BAKR (when 'r2' is non-zero), BSG, and RP ... not BC, BRC, BRCL, BAL, BAS, BRAS, or BRASL.
Frequent culprits are the access method GET/PUT routines not being filled in (due to OPEN failures that went unchecked) and those cases seem like they'll be covered by the 'wild branch' display. (Oh, joy!)
Excellent example! -- ----------------------------------------------------------------- | Edward E. Jaffe | | | Mgr, Research & Development | [EMAIL PROTECTED] | | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 | | Los Angeles, CA 90045 | 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
