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
