Although debuggers and post-mortem traces will not love you for it, right? Charles
-----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Thigpen Sent: Tuesday, November 30, 2021 9:58 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros You don't have to always save ALL the registers. No matter what the caller provides, you can always do a STMG 14,4,8(13) STG 13,64(13) because it fits in the standard 72 byte minimal save area. After the STMG, you can then decide if the caller passed a larger area or you can just acquire a larger save area yourself and store everything "correctly" in it. Of course, if your routine can be written to only use R13-R4, you can just do your work and return back. After processing is done, you can then restore everything from the larger area, then restore 14-5 from the original save are, then return back. (Just don't use the RETURN macro.) Tony Thigpen Mark Hammack wrote on 11/30/21 10:53 AM: > In our case, the caller doesn't "know" whether the called subroutine is > base 31 or base 64. So it is up to the called subroutine to "figure out" > whether the caller used a 72 byte save area or a 144 byte save area. > Parameters to the macro set addressing mode, RSA size, etc. This allows > for a 31 bit module to call a 64 bit subroutine and vice versa. That's > what I really mean by "switches between". The one caveat is that the > caller must provide a large enough area to allow for the 144 byte area. > > Since some subroutines accept arguments in R0 and/or R1 (and unfortunately > assume other registers are pre-loaded) those can't be touched before being > saved. Likewise, if the routine is called from another 64 bit subroutine, > the high halves of registers are (potentially) in use. However, since > (currently) all of our programs run below the bar, using the high half of > R14 may be an option. I need to look into using a FPR or AR but the 4 byte > literal pool works for now. Storing R14 in 8(R13) is not a bad idea either. > > Thanks! > > > > *Mark* > > > On Tue, Nov 30, 2021 at 8:37 AM Charles Mills <charl...@mcn.org> wrote: > >> Ah! I have not been clear on the convention. As I read it now, the called >> program puts one of the FnSA strings in its *new* save area to indicate how >> *it* previously stored the registers in its entry save area. >> >> So the OP's premise is incorrect. A program cannot learn the length or >> format of the incoming save area by examining it (although an FnSA string >> there would give you a clue of what the caller was up to in general). >> >> I am inferring that there is no way for a called program to determine >> programmatically the length or expected format of the incoming save area. >> It >> must be agreed upon by the two programs, or phrasing it differently, the >> called program's save area expectations must be documented and respected by >> the caller. >> >> Am I right, or off (pardon the pun) base? >> >> Charles >> >> >> -----Original Message----- >> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU >> ] >> On Behalf Of Peter Relson >> Sent: Tuesday, November 30, 2021 5:39 AM >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Subject: Re: Base-less macros >> >> Steve Smith wrote: >>> And there are other bizarre ways to return without >>> restoring R14, which is not actually required by documented conventions. >> >> Only restoring of AR14 and the high half of R14 are required (for >> non-AMODE 64 cases), in general. >> (Although I would guess that there are many violations of preserving the >> high half of R14). >> Some interfaces might define that they preserve R14 completely. Most do >> not. >> >> Mark Hammack wrote >>> I have a macro that switches between a regular (24/31 bit style) >>> save area and an extended (64 bit "F4SA") save area. >> >> What do you mean by "switches between"? It is fine to use a different >> style than the style your caller was using (as long as the savearea >> provided is big enough to accommodate your needs), without having any care >> about what was being used by your caller. The string at +4 identifies how >> you saved your caller's registers. >> >> Peter Relson >> z/OS Core Technology Design >>
