Thanks for the clarification. I seem to be a slow learner. > It's perfectly fine to use high halves in AMODE 31
People seem to conflate AMODE 64 with the usage of high halves. Writing in AMODE 64 is kind of a big deal (been there, etc.). Using the high halves for arithmetic and such is a piece of cake. > Having a unique entry point for each AMODE can be a good approach Seems like a perfect approach. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Wednesday, December 1, 2021 7:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: <snip> 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. </snip> This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote <snip> CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. </snip> Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote <snip> > 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. </snip> Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
