On Wed, 15 Mar 2023 at 14:48, Chris P Fried < 000004a1f5bf8721-dmarc-requ...@listserv.ua.edu> wrote:
> Regarding: > > AGAIN TIMEUSED ... > JNZ Again > > Versus > AGAIN TIMEUSED .. > CFI R15,8 > BE AGAIN > > > I used CFI because it is an immediate instruction. That instruction is > not going to need the literal pool. Nothing wrong with CFI, though CHI is two bytes shorter and does the same thing in this context. > I also used that instruction because it is my understanding that TIMEUSED > set the Return Code. Yes... The service it calls with that PC does set a return code. The macro generates code to test that and not store R0-R1 in your area. I used the CFI to trigger a condition code that could be checked. Looking > at the expansion of the TIMEUSED macro below, will the condition code set > by the LTR at address 1E still be in effect? Yes - the BNZ does not change the CC. (To my knowledge no branch instructions of any kind change the CC, but certainly Branch on Condition, whether Relative or not, does not.) > Is that why you suggested just JNZ after the TIMEUSED macro? > That wasn't me, of course. But I'm not sure why it would be a good idea to branch back and reissue the TIMEUSED if it fails. Seems to me that might loop. But I'm not highly familiar with this service. > I created the base register out of habit. That is what I was taught to > do 30 plus years ago. However, in this situation it is required. > As suggested by someone else, SYSSTATE ARCHLVL=2 will fix that.That is, this macro is explicitly checking for that setting and will generate a JNZ instead of the BNZ. Not all macros check, so IEABRCX as also suggested can fix many of them, though at the cost of generating super hard to read listings. But nobody reads listings these days anyway, right...? I am very interested in the BAKR and PR instructions. I am seen them > mentioned but I have not researched them. > They are kind of heavy weight - slow to execute, and do way more than you typically need. But in their place... Certainly none of the compilers generates them. However when I ran a version of the program using BAKR and PR, the program > abended with S0E0 Reason=30 > > Which means: "A stacking instruction was issued when the linkage stack > was full." > This is telling you you almost certainly have more BAKRs than PRs. I mean dynamically - one way or another you have issued more BAKRs than you have issued PRs. Is it possible that this error occurs because the TIMEUSED macro uses the > PC instruction? > It's very unlikely. The PC stack entry will be unstacked by the PR the TIMEUSED routine uses to return to you. Only if your linkage stack was almost full already might the PC fail. You can see in a dump what the failing instruction is, and where all the previous stack entries were obtained. I'm betting it'll be your BAKR, and that many of the recent entries will be that same BAKR, i.e. you are somehow taking a path that avoids doing your PR. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
