On Thu, 2 Feb 2023 17:48:21 -0600, Joe Monk <joemon...@gmail.com> wrote:
>"And >getting a caller to preserve their own registers instead of >trusting the called program is something under my control - >I don't need a z/OS change." > >It doesnt work that way, because R14 will change between caller and called >program. R14 to the called program will not be the same as R14 just before >the call, because the CALL itself is an instruction... > >That is why the called program restores the registers, because R14 will >point to the next instruction after the call. My comment was with regard to undefined registers. E.g. R3 has no meaning. Under my proposal, R3 would be cleared by the called program using LA, which, in AM64 would clear the entire 64 bits. Only the lower 32 bits would have been preserved by a traditional STM. R14 is well-defined. And the higher 32 bits will be set to 0 by the caller (since the program will be located in RM24, RM31 or potentially one day RM32 space), so doesn't need to be preserved (it is defacto preseved/unchanged). BFN. Paul. >On Thu, Feb 2, 2023 at 5:42 PM Paul Edwards <mutazi...@gmail.com> wrote: > >> On Thu, 2 Feb 2023 23:33:17 +0000, Seymour J Metz <sme...@gmu.edu> wrote: >> >> >I now of no IBM documentation to justify an expectation that the high >> halves will be zero on entry. >> >> Correct. Which is why my opening message was to add a series of LA >> instructions to force that to be the case myself. >> >> The main thing I was documenting was that LA was all that was needed. >> Previously I thought I either needed a change to the above documentation >> or I needed to use the non-S/370 LMH. >> >> >Chapter 2. Linkage conventions in the Assembler Services Guide is pretty >> clear that the caller expects bits 0-31 of GPRs 2-13 to be unchanged. >> >> Within a single program, bits 0-31 will indeed be unchanged, >> since only 32-bit instructions like LM will be used. >> >> If called by an external program, it is probably wise for the >> external program to not be dependent on the called program >> to "do the right thing". >> >> But regardless, this is up to the user to decide what they >> would like to do. >> >> If you insist that the called program must restore the high >> halves of registers and insist to be dependent on the >> correct behavior of the called program, then the called >> program must be marked AM31 at most. >> >> That's fine ... for your site and your program. >> >> I wish to have the option of doing something different. And >> getting a caller to preserve their own registers instead of >> trusting the called program is something under my control - >> I don't need a z/OS change. >> >> But I am interested in confirming that I haven't missed anything, >> before going to the effort of making sure the caller protects >> itself ... on my site. >> >> Note that the effort isn't very much, because it will be for use >> by C programs, so there is just a single C library to do the >> self-protection and then all C programs benefit. >> >> BFN. Paul. >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
