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
