Link: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvsstart.asm#l94
On Thu, 2 Feb 2023 19:04:05 -0600, Paul Edwards <mutazi...@gmail.com> wrote: >Here is my code: > >* First save away the R1 in case it is needed because it is >* a TSO environment and this is the CPPL > LR R9,R1 Alter R9 instead of R1 > N R9,=X'00FFFFFF' Clean potential garbage in high byte > > >I'm open to correction. > > > >On Fri, 3 Feb 2023 00:58:54 +0000, Seymour J Metz <sme...@gmu.edu> wrote: > >>What happens when the AM31 caller passes the PLIST address in R1? Who clears >>bits 9031, and how? > >________________________________________ >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of >Paul Edwards <mutazi...@gmail.com> >Sent: Thursday, February 2, 2023 7:55 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >Why is the first thing a concern? > >The second thing is indeed a concern, and that's the thing I >alluded to when I said I didn't want to muddy the waters. >There is a solution to that, but it requires a z/OS change. > >BFN. Paul. > > > > >On Fri, 3 Feb 2023 00:51:08 +0000, Seymour J Metz <sme...@gmu.edu> wrote: > >>My concern is that in no case does LA clear bits 0-31 while leaving the lower >>bits intact. A secondary concern is indexing with negative index values. > >________________________________________ >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of >Paul Edwards <mutazi...@gmail.com> >Sent: Thursday, February 2, 2023 7:33 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >No. Marking the load module as AM64 causes that to happen. > >What's the point of having documentation for what happens in >the different AMODEs if you think I have no control over the >AMODE? > >And if I instead mark the module as AM31, I will not be able to >clear the upper 32 bits with an LA. But I don't need to in that >case. > >Perhaps it would be good if you could restate your concern >in a simple sentence in case I'm misunderstanding. > >BFN. Paul. > > > > >On Fri, 3 Feb 2023 00:26:36 +0000, Seymour J Metz <sme...@gmu.edu> wrote: > >>The LA instructions do *not* force that to be the case. >> >> >>-- >>Shmuel (Seymour J.) Metz >>http://mason.gmu.edu/~smetz3 >> >>________________________________________ >>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >>Paul Edwards [mutazi...@gmail.com] >>Sent: Thursday, February 2, 2023 6:42 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>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 > >>---------------------------------------------------------------------- >>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 > >---------------------------------------------------------------------- >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
