Since this conversation has petered out, I'd just like to add closure (ie add the muddy water).
The z/OS change that would be required to support negative indexing (which, while fairly uncommon, can't really be avoided - it's a fundamental part of how things work), would be to map the 4-8 GiB region onto 0-4 GiB (DAT/virtual storage). This has already been proven to work with z/PDOS. Note that it took me years to realize this, and it was Joe Monk (who posts here) who told me the problem could be solved with DAT. BFN. Paul. On Thu, 2 Feb 2023 18:55:41 -0600, Paul Edwards <mutazi...@gmail.com> wrote: >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
