On Thu, 27 Jun 2013 08:24:53 -0500, John McKown wrote: >A hardware PUSHR and POPR (R suffix to avoid conflict >with existing PUSH & POP) which can PUSH and POP the general and access >registers onto a stack. This would require a hardware stack, similar to the >Linkage Stack used by PC/PR/BAKR, but one which can be dynamically expanded >(cause a PIC which the OS, z/OS in my case, would trap and then get a new >area and chain it to the old area).
I think that's what z/OS does with the linkage stack. >The PUSH and POP could only use this >stack, which I guess would be pointed to my a CR? So the stack itself could >be in key 0 (or maybe other non-key 8/9 storage), AMODE(64) storage. >Perhaps LSQA. AFAICT, the linkage stack is located in ELSQA. >Why did I bring this up, beyond my usual liking for talk? Mainly because it >would help "clean up" all the problems with the current linkage convention. >I.e. what format is the caller's save area? The called program does not determine the format of the caller's save area. The caller's save area does not have a format until a called program uses it, and it is the caller's responsibility to provide a save area that is suitable for called program to save what it needs to save. The documentation of the linkage conventions in Chapter 2 of the Assembler Services Guide were extensively revised for z/OS release 1.12 to make this clear. >Is there one? Is it big enough >to store all the grande registers plus access registers? As above, it is the caller's responsibility to provide a save area that is big enough. If it doesn't, something bad will happen. This is really no different than any other requirements that the called program might have, such as the number of parameters passed. The only difference is that the called program has no way to validate the save area before it needs to use it. >This latter is >important to me because I write code which uses those and I need somewhere >to store the caller's. You may be under some of the same misconceptions that I was a few years ago when I asked Peter Relson several questions that led him to revise the Linkage Conventions documentation. You might want to read it again. >Yes, I guess that I could save the minimal number of >registers and do a STORAGE OBTAIN to get the "real" save area. You could save your caller's registers in F5SA or F8SA format, depending on whether programs that you call need a 144-byte or a 216-byte save area. Both of these save the low halves if the registers in the caller's 72-byte save area and the high halves in your save area. Then, if necessary, you could save the access registers somewhere else. >But then I >don't have a way to communicate to the dump format routine where the >caller's registers really are. If you are using the access registers and that is your primary concern, your initial entry could use F8SA, then call another entry point that would use F7SA. What dump format routine are you using? >Am I off in la-la land again? Do I need more caffeine? Or less? That's not for me to say.... -- Tom Marchant
