> the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format.
Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Tuesday, November 30, 2021 7:54 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros 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.
