Re: GETMAIN LOC=32
Yeah, not everyone wants double the amount of memory available to properly-written 32-bit (ie using "L" etc, not "LG" etc) programs for no cost. Some people are perfectly happy with 2 GiB. The only business application I've been made aware of that reaches the 2 GiB bar is the IBM C compiler doing optimization. BFN. Paul. On Tue, 7 Feb 2023 15:33:38 -0600, Tom Marchant wrote: >Is that all you want? > > > >"I want it because I think it would be cool" is not a business justification. > >-- >Tom Marchant > >On Tue, 7 Feb 2023 12:15:57 -0600, Paul Edwards wrote: > >>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). > >-- >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
Re: GETMAIN LOC=32
While I appreciate the *honorable mention*, IBM gets all the credit. Joe On Tue, Feb 7, 2023 at 12:16 PM Paul Edwards wrote: > 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 > 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 +, Seymour J Metz 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 on behalf > of Paul Edwards > >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 +, Seymour J Metz 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 +, Seymour J Metz > 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 ...
Re: GETMAIN LOC=32
Is that all you want? "I want it because I think it would be cool" is not a business justification. -- Tom Marchant On Tue, 7 Feb 2023 12:15:57 -0600, Paul Edwards wrote: >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). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
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 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 +, Seymour J Metz 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 on behalf of >Paul Edwards >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 +, Seymour J Metz 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 +, Seymour J Metz 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...@lists
Re: GETMAIN LOC=32
Actually, you might be right. I might need different code. How about: LA R2,0 LR R2,R1 N R2,=X'00FF' ? This is basically my question - regardless of whether or not IBM changes z/OS, I would like my S/370 code to be "properly written" (32-bit clean). So my applications are "ready" for a z/OS change - even if that never happens. Or if it only happens on some other OS. What code do you suggest for both program entry and for calling z/OS services? Thanks. Paul. On Thu, 2 Feb 2023 19:06:21 -0600, Paul Edwards wrote: >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 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 >> LRR9,R1 Alter R9 instead of R1 >> N R9,=X'00FF' Clean potential garbage in high byte >> >> >>I'm open to correction. >> >> >> >>On Fri, 3 Feb 2023 00:58:54 +, Seymour J Metz wrote: >> >>>What happens when the AM31 caller passes the PLIST address in R1? Who clears >>>bits 9031, and how? >> >> >>From: IBM Mainframe Discussion List on behalf of >>Paul Edwards >>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 +, Seymour J Metz 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 on behalf of >>Paul Edwards >>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 +, Seymour J Metz 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 +, Seymour J Metz 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
Re: GETMAIN LOC=32
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 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 > LRR9,R1 Alter R9 instead of R1 > N R9,=X'00FF' Clean potential garbage in high byte > > >I'm open to correction. > > > >On Fri, 3 Feb 2023 00:58:54 +, Seymour J Metz wrote: > >>What happens when the AM31 caller passes the PLIST address in R1? Who clears >>bits 9031, and how? > > >From: IBM Mainframe Discussion List on behalf of >Paul Edwards >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 +, Seymour J Metz 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 on behalf of >Paul Edwards >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 +, Seymour J Metz 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 +, Seymour J Metz 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
Re: GETMAIN LOC=32
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 LRR9,R1 Alter R9 instead of R1 N R9,=X'00FF' Clean potential garbage in high byte I'm open to correction. On Fri, 3 Feb 2023 00:58:54 +, Seymour J Metz wrote: >What happens when the AM31 caller passes the PLIST address in R1? Who clears >bits 9031, and how? From: IBM Mainframe Discussion List on behalf of Paul Edwards 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 +, Seymour J Metz 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 on behalf of Paul Edwards 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 +, Seymour J Metz 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 +, Seymour J Metz 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, &g
Re: GETMAIN LOC=32
What happens when the AM31 caller passes the PLIST address in R1? Who clears bits 9031, and how? From: IBM Mainframe Discussion List on behalf of Paul Edwards 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 +, Seymour J Metz 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 on behalf of Paul Edwards 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 +, Seymour J Metz 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 +, Seymour J Metz 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
Re: GETMAIN LOC=32
Yes, the caller needs to provide a valid 64-bit R1 prior to calling an AM64 program with an address in R1. That's normal isn't? I believe it is normal for R1 to point to memory allocated in RM24 space. If it isn't, that would indeed need to be part of the "convention". BFN. Paul. On Fri, 3 Feb 2023 00:54:15 +, Seymour J Metz wrote: >Program entry? Sorry, I missed that. I thought that you were addressing >clearing only bits 0-31. But that leaves the caller responsible for clearing >bits 0-31 of, e.g., R1. > > >From: IBM Mainframe Discussion List on behalf of >Paul Edwards >Sent: Thursday, February 2, 2023 7:50 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >We're in agreement then. > >So what's the issue? > >In my first message I proposed doing: > >LA R3,0 > >etc > >for all undefined registers, at progrmm entry. > >So that when running as AM64 the top 32 bits would be cleared. > >That's all. > >BFN. Paul. > > > > >On Fri, 3 Feb 2023 00:47:35 +, Seymour J Metz wrote: > >>No, I'm claiming that LA R1,0(,R1) doesn't clear bits 0-31. Specifying base >>and index as 0 is a special case and clears all but the 12 bits of the >>displacement. >> >> >>From: IBM Mainframe Discussion List on behalf of >>Paul Edwards >>Sent: Thursday, February 2, 2023 7:36 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>Are you claiming that: >> >>LA R3,0 >> >>in M664 >> >>does not clear bits 0-31? >> >>What are you looking at in the POP (which I quoted)? >> >>Are you able to run a test program that demonstrates that? >> >>ie: >> >>LG R3,=X'' >>LGR R4,R3 >>LA R3,0 >> >>DC H'0' >> >>and show me the regiseers? >> >>I can't easily do that myself. >> >>Thanks. Paul. >> >> >> >> >>On Fi,, 3 Feb 2023 00:30:11 +, Seymour J Metz wrote: >> >>>Yes, I know that the wording is different depending on the mode. The point >>>isd that in no addressing mode does LA clear bits 0-31 to zero. >>> >>> >>>-- >>>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 7:26 PM >>>To: IBM-MAIN@LISTSERV.UA.EDU >>>Subject: Re: GETMAIN LOC=32 >>> >>>Those words are not used for AM64. >>> >>>I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64. >>> >>>BFN. Paul. >>> >>> >>> >>> >>>On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz wrote: >>> >>>>"and bits 0-31 remain unchanged" does not mean set to zero. >>>> >>>> >>>>-- >>>>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:47 PM >>>>To: IBM-MAIN@LISTSERV.UA.EDU >>>>Subject: Re: GETMAIN LOC=32 >>>> >>>>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: >>>> >>>>>The semantics of LA are that it doesn't clear the top half in AM64. >>>> >>>>LOAD ADDRESS >>>> >>>>LA R�,D�(X�,B�) [RX] >>>> >>>>In the 24-bit addressing mode, the address is >>>>placed in bit positions 40-63, bits 32-39 are set to >>>>zeros, and bits 0-31 remain unchanged.. In the >>>>31-bit addressing mode, the address is placed in >>>>bit positions 33-63, bit 32 is set to zero, and bits >>>>0-31 remain unchanged. In the 64-bit addressing >>>>mode, the address is placed in bit positions 0-63. >>>> >>>> >>>>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0. >>>> >>>>Which is all I need. >>>> >>>>And a S/370 instruction. >>>> >>>>> Even if you clear the top halves yourself, there are still coding >>>>> issues for 31-bit addresses in AM64. >>>> >>>>Fix t
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 +, Seymour J Metz 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 on behalf of Paul Edwards 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 +, Seymour J Metz 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 +, Seymour J Metz 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
Re: GETMAIN LOC=32
Program entry? Sorry, I missed that. I thought that you were addressing clearing only bits 0-31. But that leaves the caller responsible for clearing bits 0-31 of, e.g., R1. From: IBM Mainframe Discussion List on behalf of Paul Edwards Sent: Thursday, February 2, 2023 7:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 We're in agreement then. So what's the issue? In my first message I proposed doing: LA R3,0 etc for all undefined registers, at program entry. So that when running as AM64 the top 32 bits would be cleared. That's all. BFN. Paul. On Fri, 3 Feb 2023 00:47:35 +, Seymour J Metz wrote: >No, I'm claiming that LA R1,0(,R1) doesn't clear bits 0-31. Specifying base >and index as 0 is a special case and clears all but the 12 bits of the >displacement. > > >From: IBM Mainframe Discussion List on behalf of >Paul Edwards >Sent: Thursday, February 2, 2023 7:36 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >Are you claiming that: > >LA R3,0 > >in M664 > >does not clear bits 0-31? > >What are you looking at in the POP (which I quoted)? > >Are you able to run a test program that demonstrates that? > >ie: > >LG R3,=X'' >LGR R4,R3 >LA R3,0 > >DC H'0' > >and show me the regiseers? > >I can't easily do that myself. > >Thanks. Paul. > > > > >On Fi,, 3 Feb 2023 00:30:11 +, Seymour J Metz wrote: > >>Yes, I know that the wording is different depending on the mode. The point >>isd that in no addressing mode does LA clear bits 0-31 to zero. >> >> >>-- >>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 7:26 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>Those words are not used for AM64. >> >>I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64. >> >>BFN. Paul. >> >> >> >> >>On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz wrote: >> >>>"and bits 0-31 remain unchanged" does not mean set to zero. >>> >>> >>>-- >>>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:47 PM >>>To: IBM-MAIN@LISTSERV.UA.EDU >>>Subject: Re: GETMAIN LOC=32 >>> >>>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: >>> >>>>The semantics of LA are that it doesn't clear the top half in AM64. >>> >>>LOAD ADDRESS >>> >>>LA R�,D�(X�,B�) [RX] >>> >>>In the 24-bit addressing mode, the address is >>>placed in bit positions 40-63, bits 32-39 are set to >>>zeros, and bits 0-31 remain unchanged.. In the >>>31-bit addressing mode, the address is placed in >>>bit positions 33-63, bit 32 is set to zero, and bits >>>0-31 remain unchanged. In the 64-bit addressing >>>mode, the address is placed in bit positions 0-63. >>> >>> >>>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0. >>> >>>Which is all I need. >>> >>>And a S/370 instruction. >>> >>>> Even if you clear the top halves yourself, there are still coding >>>> issues for 31-bit addresses in AM64. >>> >>>Fix the coding issues so that they are AM32/64-clean? >>> >>>Also they aren't really 31-bit addresses. If an "L" instruction >>>is used to load an address, it is a 32-bit address, which will >>>suddenly be visible when running in AM64 (or a restored >>>360/67 running as AM32). >>> >>>BFN. Paul. >>> >>> >>> >>>>-- >>>>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:24 PM >>>>To: IBM-MAIN@LISTSERV.UA.EDU >>>>Subject: Re: GETMAIN LOC=32 &
Re: GETMAIN LOC=32
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 on behalf of Paul Edwards 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 +, Seymour J Metz 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 +, Seymour J Metz 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
Re: GETMAIN LOC=32
We're in agreement then. So what's the issue? In my first message I proposed doing: LA R3,0 etc for all undefined registers, at program entry. So that when running as AM64 the top 32 bits would be cleared. That's all. BFN. Paul. On Fri, 3 Feb 2023 00:47:35 +, Seymour J Metz wrote: >No, I'm claiming that LA R1,0(,R1) doesn't clear bits 0-31. Specifying base >and index as 0 is a special case and clears all but the 12 bits of the >displacement. > > >From: IBM Mainframe Discussion List on behalf of >Paul Edwards >Sent: Thursday, February 2, 2023 7:36 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >Are you claiming that: > >LA R3,0 > >in M664 > >does not clear bits 0-31? > >What are you looking at in the POP (which I quoted)? > >Are you able to run a test program that demonstrates that? > >ie: > >LG R3,=X'' >LGR R4,R3 >LA R3,0 > >DC H'0' > >and show me the regiseers? > >I can't easily do that myself. > >Thanks. Paul. > > > > >On Fi,, 3 Feb 2023 00:30:11 +, Seymour J Metz wrote: > >>Yes, I know that the wording is different depending on the mode. The point >>isd that in no addressing mode does LA clear bits 0-31 to zero. >> >> >>-- >>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 7:26 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>Those words are not used for AM64. >> >>I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64. >> >>BFN. Paul. >> >> >> >> >>On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz wrote: >> >>>"and bits 0-31 remain unchanged" does not mean set to zero. >>> >>> >>>-- >>>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:47 PM >>>To: IBM-MAIN@LISTSERV.UA.EDU >>>Subject: Re: GETMAIN LOC=32 >>> >>>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: >>> >>>>The semantics of LA are that it doesn't clear the top half in AM64. >>> >>>LOAD ADDRESS >>> >>>LA R�,D�(X�,B�) [RX] >>> >>>In the 24-bit addressing mode, the address is >>>placed in bit positions 40-63, bits 32-39 are set to >>>zeros, and bits 0-31 remain unchanged.. In the >>>31-bit addressing mode, the address is placed in >>>bit positions 33-63, bit 32 is set to zero, and bits >>>0-31 remain unchanged. In the 64-bit addressing >>>mode, the address is placed in bit positions 0-63. >>> >>> >>>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0. >>> >>>Which is all I need. >>> >>>And a S/370 instruction. >>> >>>> Even if you clear the top halves yourself, there are still coding >>>> issues for 31-bit addresses in AM64. >>> >>>Fix the coding issues so that they are AM32/64-clean? >>> >>>Also they aren't really 31-bit addresses. If an "L" instruction >>>is used to load an address, it is a 32-bit address, which will >>>suddenly be visible when running in AM64 (or a restored >>>360/67 running as AM32). >>> >>>BFN. Paul. >>> >>> >>> >>>>-- >>>>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:24 PM >>>>To: IBM-MAIN@LISTSERV.UA.EDU >>>>Subject: Re: GETMAIN LOC=32 >>>> >>>>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: >>>> >>>>>> And given that the high 32 bits are required to be 0, by convention, >>>>> >>>>>Where do you see that? >>>> >>>>That was my first message in the last 24 hours. >>>> >>>>Do an LA on program entry, for all undefined registers. >
Re: GETMAIN LOC=32
No, I'm claiming that LA R1,0(,R1) doesn't clear bits 0-31. Specifying base and index as 0 is a special case and clears all but the 12 bits of the displacement. From: IBM Mainframe Discussion List on behalf of Paul Edwards Sent: Thursday, February 2, 2023 7:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 Are you claiming that: LA R3,0 in AM64 does not clear bits 0-31? What are you looking at in the POP (which I quoted)? Are you able to run a test program that demonstrates that? ie: LG R3,=X'' LGR R4,R3 LA R3,0 DC H'0' and show me the registers? I can't easily do that myself. Thanks. Paul. On Fri, 3 Feb 2023 00:30:11 +, Seymour J Metz wrote: >Yes, I know that the wording is different depending on the mode. The point isd >that in no addressing mode does LA clear bits 0-31 to zero. > > >-- >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 7:26 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >Those words are not used for AM64. > >I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64. > >BFN. Paul. > > > > >On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz wrote: > >>"and bits 0-31 remain unchanged" does not mean set to zero. >> >> >>-- >>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:47 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: >> >>>The semantics of LA are that it doesn't clear the top half in AM64. >> >>LOAD ADDRESS >> >>LA R�,D�(X�,B�) [RX] >> >>In the 24-bit addressing mode, the address is >>placed in bit positions 40-63, bits 32-39 are set to >>zeros, and bits 0-31 remain unchanged.. In the >>31-bit addressing mode, the address is placed in >>bit positions 33-63, bit 32 is set to zero, and bits >>0-31 remain unchanged. In the 64-bit addressing >>mode, the address is placed in bit positions 0-63. >> >> >>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0. >> >>Which is all I need. >> >>And a S/370 instruction. >> >>> Even if you clear the top halves yourself, there are still coding >>> issues for 31-bit addresses in AM64. >> >>Fix the coding issues so that they are AM32/64-clean? >> >>Also they aren't really 31-bit addresses. If an "L" instruction >>is used to load an address, it is a 32-bit address, which will >>suddenly be visible when running in AM64 (or a restored >>360/67 running as AM32). >> >>BFN. Paul. >> >> >> >>>-- >>>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:24 PM >>>To: IBM-MAIN@LISTSERV.UA.EDU >>>Subject: Re: GETMAIN LOC=32 >>> >>>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: >>> >>>>> And given that the high 32 bits are required to be 0, by convention, >>>> >>>>Where do you see that? >>> >>>That was my first message in the last 24 hours. >>> >>>Do an LA on program entry, for all undefined registers. >>> >>>Maybe I should have said "proposed convention". I'm happy >>>to switch semantics to whatever is less confusing. >>> >>>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
Re: GETMAIN LOC=32
Are you claiming that: LA R3,0 in AM64 does not clear bits 0-31? What are you looking at in the POP (which I quoted)? Are you able to run a test program that demonstrates that? ie: LG R3,=X'' LGR R4,R3 LA R3,0 DC H'0' and show me the registers? I can't easily do that myself. Thanks. Paul. On Fri, 3 Feb 2023 00:30:11 +, Seymour J Metz wrote: >Yes, I know that the wording is different depending on the mode. The point isd >that in no addressing mode does LA clear bits 0-31 to zero. > > >-- >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 7:26 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >Those words are not used for AM64. > >I am siscussing running 32-bit (L/LM/ST/etc) programs in AM64. > >BFN. Paul. > > > > >On Fri, 3 Feb 2023 00:24:11 +S Seymour J Metz wrote: > >>"and bits 0-31 remain unchanged" does not mean set to zero. >> >> >>-- >>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:47 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: >> >>>The semantics of LA are that it doesn't clear the top half in AM64. >> >>LOAD ADDRESS >> >>LA R�,D�(X�,B�) [RX] >> >>In the 24-bit addressing mode, the address is >>placed in bit positions 40-63, bits 32-39 are set to >>zeros, and bits 0-31 remain unchanged.. In the >>31-bit addressing mode, the address is placed in >>bit positions 33-63, bit 32 is set to zero, and bits >>0-31 remain unchanged. In the 64-bit addressing >>mode, the address is placed in bit positions 0-63. >> >> >>Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0. >> >>Which is all I need. >> >>And a S/370 instruction. >> >>> Even if you clear the top halves yourself, there are still coding >>> issues for 31-bit addresses in AM64. >> >>Fix the coding issues so that they are AM32/64-clean? >> >>Also they aren't really 31-bit addresses. If an "L" instruction >>is used to load an address, it is a 32-bit address, which will >>suddenly be visible when running in AM64 (or a restored >>360/67 running as AM32). >> >>BFN. Paul. >> >> >> >>>-- >>>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:24 PM >>>To: IBM-MAIN@LISTSERV.UA.EDU >>>Subject: Re: GETMAIN LOC=32 >>> >>>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: >>> >>>>> And given that the high 32 bits are required to be 0, by convention, >>>> >>>>Where do you see that? >>> >>>That was my first message in the last 24 hours. >>> >>>Do an LA on program entry, for all undefined registers. >>> >>>Maybe I should have said "proposed convention". I'm happy >>>to switch semantics to whatever is less confusing. >>> >>>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
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 +, Seymour J Metz 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 +, Seymour J Metz 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
Re: GETMAIN LOC=32
Yes, I know that the wording is different depending on the mode. The point isd that in no addressing mode does LA clear bits 0-31 to zero. -- 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 7:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 Those words are not used for AM64. I am discussing running 32-bit (L/LM/ST/etc) programs in AM64. BFN. Paul. On Fri, 3 Feb 2023 00:24:11 +, Seymour J Metz wrote: >"and bits 0-31 remain unchanged" does not mean set to zero. > > >-- >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:47 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: > >>The semantics of LA are that it doesn't clear the top half in AM64. > >LOAD ADDRESS > >LA R�,D�(X�,B�) [RX] > >In the 24-bit addressing mode, the address is >placed in bit positions 40-63, bits 32-39 are set to >zeros, and bits 0-31 remain unchanged.. In the >31-bit addressing mode, the address is placed in >bit positions 33-63, bit 32 is set to zero, and bits >0-31 remain unchanged. In the 64-bit addressing >mode, the address is placed in bit positions 0-63. > > >Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0. > >Which is all I need. > >And a S/370 instruction. > >> Even if you clear the top halves yourself, there are still coding >> issues for 31-bit addresses in AM64. > >Fix the coding issues so that they are AM32/64-clean? > >Also they aren't really 31-bit addresses. If an "L" instruction >is used to load an address, it is a 32-bit address, which will >suddenly be visible when running in AM64 (or a restored >360/67 running as AM32). > >BFN. Paul. > > > >>-- >>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:24 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: >> >>>> And given that the high 32 bits are required to be 0, by convention, >>> >>>Where do you see that? >> >>That was my first message in the last 24 hours. >> >>Do an LA on program entry, for all undefined registers. >> >>Maybe I should have said "proposed convention". I'm happy >>to switch semantics to whatever is less confusing. >> >>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
Re: GETMAIN LOC=32
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 +, Seymour J Metz 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
Re: GETMAIN LOC=32
Those words are not used for AM64. I am discussing running 32-bit (L/LM/ST/etc) programs in AM64. BFN. Paul. On Fri, 3 Feb 2023 00:24:11 +, Seymour J Metz wrote: >"and bits 0-31 remain unchanged" does not mean set to zero. > > >-- >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:47 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: > >>The semantics of LA are that it doesn't clear the top half in AM64. > >LOAD ADDRESS > >LA R�,D�(X�,B�) [RX] > >In the 24-bit addressing mode, the address is >placed in bit positions 40-63, bits 32-39 are set to >zeros, and bits 0-31 remain unchanged.. In the >31-bit addressing mode, the address is placed in >bit positions 33-63, bit 32 is set to zero, and bits >0-31 remain unchanged. In the 64-bit addressing >mode, the address is placed in bit positions 0-63. > > >Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0. > >Which is all I need. > >And a S/370 instruction. > >> Even if you clear the top halves yourself, there are still coding >> issues for 31-bit addresses in AM64. > >Fix the coding issues so that they are AM32/64-clean? > >Also they aren't really 31-bit addresses. If an "L" instruction >is used to load an address, it is a 32-bit address, which will >suddenly be visible when running in AM64 (or a restored >360/67 running as AM32). > >BFN. Paul. > > > >>-- >>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:24 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: GETMAIN LOC=32 >> >>On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: >> >>>> And given that the high 32 bits are required to be 0, by convention, >>> >>>Where do you see that? >> >>That was my first message in the last 24 hours. >> >>Do an LA on program entry, for all undefined registers. >> >>Maybe I should have said "proposed convention". I'm happy >>to switch semantics to whatever is less confusing. >> >>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
Re: GETMAIN LOC=32
"and bits 0-31 remain unchanged" does not mean set to zero. -- 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:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: >The semantics of LA are that it doesn't clear the top half in AM64. LOAD ADDRESS LA R±,D²(X²,B²) [RX] In the 24-bit addressing mode, the address is placed in bit positions 40-63, bits 32-39 are set to zeros, and bits 0-31 remain unchanged.. In the 31-bit addressing mode, the address is placed in bit positions 33-63, bit 32 is set to zero, and bits 0-31 remain unchanged. In the 64-bit addressing mode, the address is placed in bit positions 0-63. Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0. Which is all I need. And a S/370 instruction. > Even if you clear the top halves yourself, there are still coding > issues for 31-bit addresses in AM64. Fix the coding issues so that they are AM32/64-clean? Also they aren't really 31-bit addresses. If an "L" instruction is used to load an address, it is a 32-bit address, which will suddenly be visible when running in AM64 (or a restored 360/67 running as AM32). BFN. Paul. >-- >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:24 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: > >>> And given that the high 32 bits are required to be 0, by convention, >> >>Where do you see that? > >That was my first message in the last 24 hours. > >Do an LA on program entry, for all undefined registers. > >Maybe I should have said "proposed convention". I'm happy >to switch semantics to whatever is less confusing. > >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
Re: GETMAIN LOC=32
On Thu, 2 Feb 2023 17:48:21 -0600, Joe Monk 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 wrote: > >> On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz 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
Re: GETMAIN LOC=32
"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. Joe On Thu, Feb 2, 2023 at 5:42 PM Paul Edwards wrote: > On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz 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
Re: GETMAIN LOC=32
On Thu, 2 Feb 2023 23:37:16 +, Seymour J Metz wrote: >The semantics of LA are that it doesn't clear the top half in AM64. LOAD ADDRESS LA R±,D²(X²,B²) [RX] In the 24-bit addressing mode, the address is placed in bit positions 40-63, bits 32-39 are set to zeros, and bits 0-31 remain unchanged.. In the 31-bit addressing mode, the address is placed in bit positions 33-63, bit 32 is set to zero, and bits 0-31 remain unchanged. In the 64-bit addressing mode, the address is placed in bit positions 0-63. Ergo, LA R3,0 in AM64 will set the entire 64 bits of R3 to 0. Which is all I need. And a S/370 instruction. > Even if you clear the top halves yourself, there are still coding > issues for 31-bit addresses in AM64. Fix the coding issues so that they are AM32/64-clean? Also they aren't really 31-bit addresses. If an "L" instruction is used to load an address, it is a 32-bit address, which will suddenly be visible when running in AM64 (or a restored 360/67 running as AM32). BFN. Paul. >-- >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:24 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: > >>> And given that the high 32 bits are required to be 0, by convention, >> >>Where do you see that? > >That was my first message in the last 24 hours. > >Do an LA on program entry, for all undefined registers. > >Maybe I should have said "proposed convention". I'm happy >to switch semantics to whatever is less confusing. > >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
Re: GETMAIN LOC=32
On Thu, 2 Feb 2023 23:33:17 +, Seymour J Metz 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
Re: GETMAIN LOC=32
The semantics of LA are that it doesn't clear the top half in AM64. Even if you clear the top halves yourself, there are still coding issues for 31-bit addresses in AM64. -- 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:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: >> And given that the high 32 bits are required to be 0, by convention, > >Where do you see that? That was my first message in the last 24 hours. Do an LA on program entry, for all undefined registers. Maybe I should have said "proposed convention". I'm happy to switch semantics to whatever is less confusing. 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
Re: GETMAIN LOC=32
I now of no IBM documentation to justify an expectation that the high halves will be zero on entry. 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. -- 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:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 23:06:49 +, Seymour J Metz wrote: >With the exception of XL, the linkage conventions for main and subroutines are >the same. Of course, there are differences in the PLIST, but that's a separate >issue. > >Bottom line: expect bugs if you don't save the top halves as documented. Within a single "32-bit (L/LM/etc)" program, ie "program B", there is an expectation that on entry the high halves will be set to zero (and if it isn't, that's when the bugs will be expected), and from then on, those high halves will never be touched, so there is no issue with only using the traditional STM instruction to save registers in a subroutine. BFN. Paul. > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Paul Edwards [mutazi...@gmail.com] >Sent: Thursday, February 2, 2023 5:36 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 16:38:38 +, Peter Relson wrote: > >>I couldn't find the original post for this thread even in the archives, so I >>don't know what this has to do with GETMAIN, or where "LOC=32" came into >>things since the parameter is LOC=31. > >Here is the first post: > >https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.ua.edu%2Fcgi-bin%2Fwa%3FA2%3Dind1805%26L%3DIBM-MAIN%26P%3DR16285=05%7C01%7Csmetz3%40gmu.edu%7C718bd144b06548bf3cbf08db057306d4%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638109763809086697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0BKWo5q0IsRuj5Iw%2FrtDtH1oMEoGvQ1Ys5BYz8bM4XU%3D=0 > >>I am exactly executing in AMODE 64. >>And so I need the high halves to be clear at all times. >>Because I am using pure S/370 instructions. >> >>I'll bite. Why would you choose to run in AMODE 64 if you are trying to >>restrict yourself to S/370 instructions? > >So that I can potentially access the 2 GiB to 4 GiB region, >using a "properly-written" S/370 program (that runs >perfectly fine as AM24). > >>And why not even S/390 instructions, let alone z/Architecture instructions? > >You can choose whatever level you want, and the program will >be upwardly compatible. > >You can actually choose S/360 if you want, capable of running >as AM32 on a 360/67 and it will still run on AM64 on z/Arch. > >There are a few things the application needs to do itself, >and I was trying to identify them. > >>Further, "need the high halves to be clear at all times" is not true. You >>only would need the high halves (PLUS bit 32) to be zero for a register used >>to access data and only at that point. > >That's not correct. You can (randomly) get access to the >2 GiB to 4 GiB region by using IARV64 (with or without >a USE_2G... parameter). If you are lucky, >you will be in a position to set the high bit of the lower >32 bits to 1 as part of accessing that new memory. > >My original post was a suggestion to get rid of that >"randomly". > >But on top of that, I was looking for a z/OS change to >guarantee the high halves were zero. And the new >information is that I don't need that guarantee. I can >make my S/370 applications "more-properly-written" >by taking clear of clearing the high halves themselves, >without being dependent on z/OS. > >>At a minimum, you are surely violating linkage conventions by not preserving >>the high halves of any regs 2-14 that you might use. >>(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can >>conform to linkage conventions without needing to use a zArch instruction >>such as STMG or STMH) > > >There are two linkage conventions I believe: > >1. When one subroutine calls another subroutine. >2. When one program calls another program. > >I assume you are only concerned about (2). > >And I assume you're also not concerned about the >situation of EXEC PGM= > >Yes you are correct. > >If program A is 64-bit (e.g. lots of LG as opposed to >32-bit L like program B) and does a LINK EP= to program B, >and program B is using
Re: GETMAIN LOC=32
On Thu, 2 Feb 2023 23:22:00 +, Seymour J Metz wrote: >> And given that the high 32 bits are required to be 0, by convention, > >Where do you see that? That was my first message in the last 24 hours. Do an LA on program entry, for all undefined registers. Maybe I should have said "proposed convention". I'm happy to switch semantics to whatever is less confusing. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
> And given that the high 32 bits are required to be 0, by convention, Where do you see that? -- 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:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 Sure. And given that the high 32 bits are required to be 0, by convention, which is why I mentioned the use of LA on each undefined register on entry, the computation is: 0 + 0 = 0 Just what the doctor ordered. BFN. Paul. On Thu, 2 Feb 2023 23:10:47 +, Seymour J Metz wrote: >"The address computa- tion follows the rules for address arithmetic." > >In AM64 that means that the base and index are 64 bits. > > >-- >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 5:59 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe >wrote: > >>On 2/2/2023 2:36 PM, Paul Edwards wrote: >>> But on top of that, I was looking for a z/OS change to >>> guarantee the high halves were zero. And the new >>> information is that I don't need that guarantee. I can >>> make my S/370 applications "more-properly-written" >>> by taking clear of clearing the high halves themselves, >>> without being dependent on z/OS. >> >>We take exactly the opposite approach because we have been "burned." >> >>We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the >>operating system puts garbage in the ARs and the high halves. >> >>That way we won't accidentally develop code that depends on these >>registers being pre-initialized to zero. > >Ok, that sounds like a good idea, and again, LA (a S/370 >instruction) should cope with clearing that garbage, so that >a "properly-written" (or maybe "appropriately-written") S/370 >program can protect itself while running in AM64. > >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
Re: GETMAIN LOC=32
Sure. And given that the high 32 bits are required to be 0, by convention, which is why I mentioned the use of LA on each undefined register on entry, the computation is: 0 + 0 = 0 Just what the doctor ordered. BFN. Paul. On Thu, 2 Feb 2023 23:10:47 +, Seymour J Metz wrote: >"The address computa- tion follows the rules for address arithmetic." > >In AM64 that means that the base and index are 64 bits. > > >-- >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 5:59 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe >wrote: > >>On 2/2/2023 2:36 PM, Paul Edwards wrote: >>> But on top of that, I was looking for a z/OS change to >>> guarantee the high halves were zero. And the new >>> information is that I don't need that guarantee. I can >>> make my S/370 applications "more-properly-written" >>> by taking clear of clearing the high halves themselves, >>> without being dependent on z/OS. >> >>We take exactly the opposite approach because we have been "burned." >> >>We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the >>operating system puts garbage in the ARs and the high halves. >> >>That way we won't accidentally develop code that depends on these >>registers being pre-initialized to zero. > >Ok, that sounds like a good idea, and again, LA (a S/370 >instruction) should cope with clearing that garbage, so that >a "properly-written" (or maybe "appropriately-written") S/370 >program can protect itself while running in AM64. > >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
Re: GETMAIN LOC=32
On Thu, 2 Feb 2023 23:06:49 +, Seymour J Metz wrote: >With the exception of XL, the linkage conventions for main and subroutines are >the same. Of course, there are differences in the PLIST, but that's a separate >issue. > >Bottom line: expect bugs if you don't save the top halves as documented. Within a single "32-bit (L/LM/etc)" program, ie "program B", there is an expectation that on entry the high halves will be set to zero (and if it isn't, that's when the bugs will be expected), and from then on, those high halves will never be touched, so there is no issue with only using the traditional STM instruction to save registers in a subroutine. BFN. Paul. > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Paul Edwards [mutazi...@gmail.com] >Sent: Thursday, February 2, 2023 5:36 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Thu, 2 Feb 2023 16:38:38 +, Peter Relson wrote: > >>I couldn't find the original post for this thread even in the archives, so I >>don't know what this has to do with GETMAIN, or where "LOC=32" came into >>things since the parameter is LOC=31. > >Here is the first post: > >https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.ua.edu%2Fcgi-bin%2Fwa%3FA2%3Dind1805%26L%3DIBM-MAIN%26P%3DR16285=05%7C01%7Csmetz3%40gmu.edu%7C66e9a1f6c4904ab58d8c08db056de9aa%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638109741866545864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2BE71z9NlDsxXzNVbkcshmsdWNaMLOnO5VLWti%2FdzeSE%3D=0 > >>I am exactly executing in AMODE 64. >>And so I need the high halves to be clear at all times. >>Because I am using pure S/370 instructions. >> >>I'll bite. Why would you choose to run in AMODE 64 if you are trying to >>restrict yourself to S/370 instructions? > >So that I can potentially access the 2 GiB to 4 GiB region, >using a "properly-written" S/370 program (that runs >perfectly fine as AM24). > >>And why not even S/390 instructions, let alone z/Architecture instructions? > >You can choose whatever level you want, and the program will >be upwardly compatible. > >You can actually choose S/360 if you want, capable of running >as AM32 on a 360/67 and it will still run on AM64 on z/Arch. > >There are a few things the application needs to do itself, >and I was trying to identify them. > >>Further, "need the high halves to be clear at all times" is not true. You >>only would need the high halves (PLUS bit 32) to be zero for a register used >>to access data and only at that point. > >That's not correct. You can (randomly) get access to the >2 GiB to 4 GiB region by using IARV64 (with or without >a USE_2G... parameter). If you are lucky, >you will be in a position to set the high bit of the lower >32 bits to 1 as part of accessing that new memory. > >My original post was a suggestion to get rid of that >"randomly". > >But on top of that, I was looking for a z/OS change to >guarantee the high halves were zero. And the new >information is that I don't need that guarantee. I can >make my S/370 applications "more-properly-written" >by taking clear of clearing the high halves themselves, >without being dependent on z/OS. > >>At a minimum, you are surely violating linkage conventions by not preserving >>the high halves of any regs 2-14 that you might use. >>(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can >>conform to linkage conventions without needing to use a zArch instruction >>such as STMG or STMH) > > >There are two linkage conventions I believe: > >1. When one subroutine calls another subroutine. >2. When one program calls another program. > >I assume you are only concerned about (2). > >And I assume you're also not concerned about the >situation of EXEC PGM= > >Yes you are correct. > >If program A is 64-bit (e.g. lots of LG as opposed to >32-bit L like program B) and does a LINK EP= to program B, >and program B is using only 32-bit instructions, running >as AM64, and does a traditional STM to save the lower >halves, and then does LA instructions that wipe the higher >half of registers, and program A is dependent on those >being preserved, then it won't work. > >So a new convention would be needed that before doing a >LINK EP= or ATTACH, you need to save your own registers. > >If program A is unable or unwilling to do that, then program >B will need to be marked as AM31 instead. Once again, >assuming program B has been "properly-
Re: GETMAIN LOC=32
"The address computa- tion follows the rules for address arithmetic." In AM64 that means that the base and index are 64 bits. -- 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 5:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe wrote: >On 2/2/2023 2:36 PM, Paul Edwards wrote: >> But on top of that, I was looking for a z/OS change to >> guarantee the high halves were zero. And the new >> information is that I don't need that guarantee. I can >> make my S/370 applications "more-properly-written" >> by taking clear of clearing the high halves themselves, >> without being dependent on z/OS. > >We take exactly the opposite approach because we have been "burned." > >We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the >operating system puts garbage in the ARs and the high halves. > >That way we won't accidentally develop code that depends on these >registers being pre-initialized to zero. Ok, that sounds like a good idea, and again, LA (a S/370 instruction) should cope with clearing that garbage, so that a "properly-written" (or maybe "appropriately-written") S/370 program can protect itself while running in AM64. 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
Re: GETMAIN LOC=32
On Thu, 2 Feb 2023 16:58:32 -0600, Joe Monk wrote: >I dont understand the premise here. > >In AM64, LA loads 64 bits. > >All of this talk of 32 bits seems to be nonsense. If the registers in >z/Arch are 64 bits, then your program is 64 bits... no? Every machine >instruction in AM64 is a 64 bit instruction... or am I missing something? That appears to be a question of semantics. What would you like to call the "L" instruction, that loads 32 bits into a register? If you want to call that a "64 bit instruction", then ok, that can be a particular definition. I call a "properly-written S/370 program", that only uses "L", not a single LG, because that was unknown at the time, to be a "32 bit program using 32-bit instructions", regardless of whether that program (in the 1970s) ran only as AM24, or perhaps on the 360/67 ran as AM32, or in the 1990s was marked AM31 and happened to be 31-bit clean, so continued to work, and then in the 2000s someone marked it as AM64 and was surprised to see that it still worked, as it was 32/64-bit clean also. But the original program, using "L" everywhere, was distinctly 32-bit. I can replace "32-bit" with "L-etc-only-using" if you would prefer that semantics so that we don't lose the concept. >And the POPs for z/Arch says that all storage references are 64 bits >(absolute address). > >How is any of this a 32 bit program? The "L", "ST", "LM", "STM", "LR" etc etc (as opposed to G versions of those), make it operate on 32-bit values exclusively. Add one single "G" instruction and it becomes 64-bit, according to this semantics. Again, I'm happy to switch to different semantics if you can tell me what they are. The use of 32-bit vs 64-bit load/store/etc instructions is completely independent of whether EITHER of those (32 vs 64) program types is running as AMODE 24/31/32/64. BFN. Paul. >On Thu, Feb 2, 2023 at 4:36 PM Paul Edwards wrote: > >> On Thu, 2 Feb 2023 16:38:38 +, Peter Relson wrote: >> >> >I couldn't find the original post for this thread even in the archives, >> so I don't know what this has to do with GETMAIN, or where "LOC=32" came >> into things since the parameter is LOC=31. >> >> Here is the first post: >> >> https://listserv.ua.edu/cgi-bin/wa?A2=ind1805=IBM-MAIN=R16285 >> >> >I am exactly executing in AMODE 64. >> >And so I need the high halves to be clear at all times. >> >Because I am using pure S/370 instructions. >> > >> >I'll bite. Why would you choose to run in AMODE 64 if you are trying to >> restrict yourself to S/370 instructions? >> >> So that I can potentially access the 2 GiB to 4 GiB region, >> using a "properly-written" S/370 program (that runs >> perfectly fine as AM24). >> >> >And why not even S/390 instructions, let alone z/Architecture >> instructions? >> >> You can choose whatever level you want, and the program will >> be upwardly compatible. >> >> You can actually choose S/360 if you want, capable of running >> as AM32 on a 360/67 and it will still run on AM64 on z/Arch. >> >> There are a few things the application needs to do itself, >> and I was trying to identify them. >> >> >Further, "need the high halves to be clear at all times" is not true. You >> only would need the high halves (PLUS bit 32) to be zero for a register >> used to access data and only at that point. >> >> That's not correct. You can (randomly) get access to the >> 2 GiB to 4 GiB region by using IARV64 (with or without >> a USE_2G... parameter). If you are lucky, >> you will be in a position to set the high bit of the lower >> 32 bits to 1 as part of accessing that new memory. >> >> My original post was a suggestion to get rid of that >> "randomly". >> >> But on top of that, I was looking for a z/OS change to >> guarantee the high halves were zero. And the new >> information is that I don't need that guarantee. I can >> make my S/370 applications "more-properly-written" >> by taking clear of clearing the high halves themselves, >> without being dependent on z/OS. >> >> >At a minimum, you are surely violating linkage conventions by not >> preserving the high halves of any regs 2-14 that you might use. >> >(BAKR is not a S/370 instruction; if you allow for use of BAKR then you >> can conform to linkage conventions without needing to use a zArch >> instruction such as STMG or STMH) >> >> >> There are two linkage conventions I believe: >> >> 1. When one subroutine calls another subroutine. >> 2. When one program calls another program. >> >> I assume you are only concerned about (2). >> >> And I assume you're also not concerned about the >> situation of EXEC PGM= >> >> Yes you are correct. >> >> If program A is 64-bit (e.g. lots of LG as opposed to >> 32-bit L like program B) and does a LINK EP= to program B, >> and program B is using only 32-bit instructions, running >> as AM64, and does a traditional STM to save the lower >> halves, and then does LA instructions that wipe the higher >> half of registers, and program A is dependent on those >> being preserved,
Re: GETMAIN LOC=32
With the exception of XL, the linkage conventions for main and subroutines are the same. Of course, there are differences in the PLIST, but that's a separate issue. Bottom line: expect bugs if you don't save the top halves as documented. -- 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 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Thu, 2 Feb 2023 16:38:38 +, Peter Relson wrote: >I couldn't find the original post for this thread even in the archives, so I >don't know what this has to do with GETMAIN, or where "LOC=32" came into >things since the parameter is LOC=31. Here is the first post: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.ua.edu%2Fcgi-bin%2Fwa%3FA2%3Dind1805%26L%3DIBM-MAIN%26P%3DR16285=05%7C01%7Csmetz3%40gmu.edu%7C66e9a1f6c4904ab58d8c08db056de9aa%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638109741866545864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2BE71z9NlDsxXzNVbkcshmsdWNaMLOnO5VLWti%2FdzeSE%3D=0 >I am exactly executing in AMODE 64. >And so I need the high halves to be clear at all times. >Because I am using pure S/370 instructions. > >I'll bite. Why would you choose to run in AMODE 64 if you are trying to >restrict yourself to S/370 instructions? So that I can potentially access the 2 GiB to 4 GiB region, using a "properly-written" S/370 program (that runs perfectly fine as AM24). >And why not even S/390 instructions, let alone z/Architecture instructions? You can choose whatever level you want, and the program will be upwardly compatible. You can actually choose S/360 if you want, capable of running as AM32 on a 360/67 and it will still run on AM64 on z/Arch. There are a few things the application needs to do itself, and I was trying to identify them. >Further, "need the high halves to be clear at all times" is not true. You only >would need the high halves (PLUS bit 32) to be zero for a register used to >access data and only at that point. That's not correct. You can (randomly) get access to the 2 GiB to 4 GiB region by using IARV64 (with or without a USE_2G... parameter). If you are lucky, you will be in a position to set the high bit of the lower 32 bits to 1 as part of accessing that new memory. My original post was a suggestion to get rid of that "randomly". But on top of that, I was looking for a z/OS change to guarantee the high halves were zero. And the new information is that I don't need that guarantee. I can make my S/370 applications "more-properly-written" by taking clear of clearing the high halves themselves, without being dependent on z/OS. >At a minimum, you are surely violating linkage conventions by not preserving >the high halves of any regs 2-14 that you might use. >(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can >conform to linkage conventions without needing to use a zArch instruction such >as STMG or STMH) There are two linkage conventions I believe: 1. When one subroutine calls another subroutine. 2. When one program calls another program. I assume you are only concerned about (2). And I assume you're also not concerned about the situation of EXEC PGM= Yes you are correct. If program A is 64-bit (e.g. lots of LG as opposed to 32-bit L like program B) and does a LINK EP= to program B, and program B is using only 32-bit instructions, running as AM64, and does a traditional STM to save the lower halves, and then does LA instructions that wipe the higher half of registers, and program A is dependent on those being preserved, then it won't work. So a new convention would be needed that before doing a LINK EP= or ATTACH, you need to save your own registers. If program A is unable or unwilling to do that, then program B will need to be marked as AM31 instead. Once again, assuming program B has been "properly-written" such that it can run in AM24, 31, 32, 64. And yes, I'm aware that the 360/67 (AM32 capable) is no longer manufactured or sold. It still exists as a historical fact and as a concept, and if you are able to do AM64, AM32 will work anyway. I am identifying what is required from z/OS, and what is required from applications, in order to support making S/370 (or S/360) applications "fly" (work to the maximum theoretical limit - including potential theoretical changes to z/OS) on z/Arch. Note that there are other things of interest that I haven't mentioned in this thread, but I am reluctant to muddy the waters. BFN. Paul. -- For IBM-MA
Re: GETMAIN LOC=32
On Thu, 2 Feb 2023 14:45:31 -0800, Ed Jaffe wrote: >On 2/2/2023 2:36 PM, Paul Edwards wrote: >> But on top of that, I was looking for a z/OS change to >> guarantee the high halves were zero. And the new >> information is that I don't need that guarantee. I can >> make my S/370 applications "more-properly-written" >> by taking clear of clearing the high halves themselves, >> without being dependent on z/OS. > >We take exactly the opposite approach because we have been "burned." > >We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the >operating system puts garbage in the ARs and the high halves. > >That way we won't accidentally develop code that depends on these >registers being pre-initialized to zero. Ok, that sounds like a good idea, and again, LA (a S/370 instruction) should cope with clearing that garbage, so that a "properly-written" (or maybe "appropriately-written") S/370 program can protect itself while running in AM64. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
I dont understand the premise here. In AM64, LA loads 64 bits. All of this talk of 32 bits seems to be nonsense. If the registers in z/Arch are 64 bits, then your program is 64 bits... no? Every machine instruction in AM64 is a 64 bit instruction... or am I missing something? And the POPs for z/Arch says that all storage references are 64 bits (absolute address). How is any of this a 32 bit program? Joe On Thu, Feb 2, 2023 at 4:36 PM Paul Edwards wrote: > On Thu, 2 Feb 2023 16:38:38 +, Peter Relson wrote: > > >I couldn't find the original post for this thread even in the archives, > so I don't know what this has to do with GETMAIN, or where "LOC=32" came > into things since the parameter is LOC=31. > > Here is the first post: > > https://listserv.ua.edu/cgi-bin/wa?A2=ind1805=IBM-MAIN=R16285 > > >I am exactly executing in AMODE 64. > >And so I need the high halves to be clear at all times. > >Because I am using pure S/370 instructions. > > > >I'll bite. Why would you choose to run in AMODE 64 if you are trying to > restrict yourself to S/370 instructions? > > So that I can potentially access the 2 GiB to 4 GiB region, > using a "properly-written" S/370 program (that runs > perfectly fine as AM24). > > >And why not even S/390 instructions, let alone z/Architecture > instructions? > > You can choose whatever level you want, and the program will > be upwardly compatible. > > You can actually choose S/360 if you want, capable of running > as AM32 on a 360/67 and it will still run on AM64 on z/Arch. > > There are a few things the application needs to do itself, > and I was trying to identify them. > > >Further, "need the high halves to be clear at all times" is not true. You > only would need the high halves (PLUS bit 32) to be zero for a register > used to access data and only at that point. > > That's not correct. You can (randomly) get access to the > 2 GiB to 4 GiB region by using IARV64 (with or without > a USE_2G... parameter). If you are lucky, > you will be in a position to set the high bit of the lower > 32 bits to 1 as part of accessing that new memory. > > My original post was a suggestion to get rid of that > "randomly". > > But on top of that, I was looking for a z/OS change to > guarantee the high halves were zero. And the new > information is that I don't need that guarantee. I can > make my S/370 applications "more-properly-written" > by taking clear of clearing the high halves themselves, > without being dependent on z/OS. > > >At a minimum, you are surely violating linkage conventions by not > preserving the high halves of any regs 2-14 that you might use. > >(BAKR is not a S/370 instruction; if you allow for use of BAKR then you > can conform to linkage conventions without needing to use a zArch > instruction such as STMG or STMH) > > > There are two linkage conventions I believe: > > 1. When one subroutine calls another subroutine. > 2. When one program calls another program. > > I assume you are only concerned about (2). > > And I assume you're also not concerned about the > situation of EXEC PGM= > > Yes you are correct. > > If program A is 64-bit (e.g. lots of LG as opposed to > 32-bit L like program B) and does a LINK EP= to program B, > and program B is using only 32-bit instructions, running > as AM64, and does a traditional STM to save the lower > halves, and then does LA instructions that wipe the higher > half of registers, and program A is dependent on those > being preserved, then it won't work. > > So a new convention would be needed that before doing a > LINK EP= or ATTACH, you need to save your own registers. > > If program A is unable or unwilling to do that, then program > B will need to be marked as AM31 instead. Once again, > assuming program B has been "properly-written" such that > it can run in AM24, 31, 32, 64. And yes, I'm aware that the > 360/67 (AM32 capable) is no longer manufactured or sold. > It still exists as a historical fact and as a concept, and if you > are able to do AM64, AM32 will work anyway. > > I am identifying what is required from z/OS, and what is > required from applications, in order to support making > S/370 (or S/360) applications "fly" (work to the maximum > theoretical limit - including potential theoretical changes > to z/OS) on z/Arch. > > Note that there are other things of interest that I haven't > mentioned in this thread, but I am reluctant to muddy > the waters. > > 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
Re: GETMAIN LOC=32
On 2/2/2023 2:36 PM, Paul Edwards wrote: But on top of that, I was looking for a z/OS change to guarantee the high halves were zero. And the new information is that I don't need that guarantee. I can make my S/370 applications "more-properly-written" by taking clear of clearing the high halves themselves, without being dependent on z/OS. We take exactly the opposite approach because we have been "burned." We set Traps(IeaInitArSrb,IeaInitRegsTask) in DIAGxx to ensure the operating system puts garbage in the ARs and the high halves. That way we won't accidentally develop code that depends on these registers being pre-initialized to zero. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Thu, 2 Feb 2023 16:38:38 +, Peter Relson wrote: >I couldn't find the original post for this thread even in the archives, so I >don't know what this has to do with GETMAIN, or where "LOC=32" came into >things since the parameter is LOC=31. Here is the first post: https://listserv.ua.edu/cgi-bin/wa?A2=ind1805=IBM-MAIN=R16285 >I am exactly executing in AMODE 64. >And so I need the high halves to be clear at all times. >Because I am using pure S/370 instructions. > >I'll bite. Why would you choose to run in AMODE 64 if you are trying to >restrict yourself to S/370 instructions? So that I can potentially access the 2 GiB to 4 GiB region, using a "properly-written" S/370 program (that runs perfectly fine as AM24). >And why not even S/390 instructions, let alone z/Architecture instructions? You can choose whatever level you want, and the program will be upwardly compatible. You can actually choose S/360 if you want, capable of running as AM32 on a 360/67 and it will still run on AM64 on z/Arch. There are a few things the application needs to do itself, and I was trying to identify them. >Further, "need the high halves to be clear at all times" is not true. You only >would need the high halves (PLUS bit 32) to be zero for a register used to >access data and only at that point. That's not correct. You can (randomly) get access to the 2 GiB to 4 GiB region by using IARV64 (with or without a USE_2G... parameter). If you are lucky, you will be in a position to set the high bit of the lower 32 bits to 1 as part of accessing that new memory. My original post was a suggestion to get rid of that "randomly". But on top of that, I was looking for a z/OS change to guarantee the high halves were zero. And the new information is that I don't need that guarantee. I can make my S/370 applications "more-properly-written" by taking clear of clearing the high halves themselves, without being dependent on z/OS. >At a minimum, you are surely violating linkage conventions by not preserving >the high halves of any regs 2-14 that you might use. >(BAKR is not a S/370 instruction; if you allow for use of BAKR then you can >conform to linkage conventions without needing to use a zArch instruction such >as STMG or STMH) There are two linkage conventions I believe: 1. When one subroutine calls another subroutine. 2. When one program calls another program. I assume you are only concerned about (2). And I assume you're also not concerned about the situation of EXEC PGM= Yes you are correct. If program A is 64-bit (e.g. lots of LG as opposed to 32-bit L like program B) and does a LINK EP= to program B, and program B is using only 32-bit instructions, running as AM64, and does a traditional STM to save the lower halves, and then does LA instructions that wipe the higher half of registers, and program A is dependent on those being preserved, then it won't work. So a new convention would be needed that before doing a LINK EP= or ATTACH, you need to save your own registers. If program A is unable or unwilling to do that, then program B will need to be marked as AM31 instead. Once again, assuming program B has been "properly-written" such that it can run in AM24, 31, 32, 64. And yes, I'm aware that the 360/67 (AM32 capable) is no longer manufactured or sold. It still exists as a historical fact and as a concept, and if you are able to do AM64, AM32 will work anyway. I am identifying what is required from z/OS, and what is required from applications, in order to support making S/370 (or S/360) applications "fly" (work to the maximum theoretical limit - including potential theoretical changes to z/OS) on z/Arch. Note that there are other things of interest that I haven't mentioned in this thread, but I am reluctant to muddy the waters. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
BAKR (branch and stack) is an ESA/390 instruction. Joe On Thu, Feb 2, 2023 at 11:00 AM Seymour J Metz wrote: > > BAKR is not a S/370 instruction > > ? > > IBM Enterprise Systems Architecture/370 Principles of Operation, > SA22-7200-0, > < > http://bitsavers.org/pdf/ibm/370/princOps/SA22-7200-0_370-ESA_Principles_of_Operation_Aug88.pdf>, > p 10-5, has Branch and Stack. Or weren't you counting 370-ESA as 370? > > > From: IBM Mainframe Discussion List on behalf > of Peter Relson > Sent: Thursday, February 2, 2023 11:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: GETMAIN LOC=32 > > I couldn't find the original post for this thread even in the archives, so > I don't know what this has to do with GETMAIN, or where "LOC=32" came into > things since the parameter is LOC=31. > > > I am exactly executing in AMODE 64. > And so I need the high halves to be clear at all times. > Because I am using pure S/370 instructions. > > > I'll bite. Why would you choose to run in AMODE 64 if you are trying to > restrict yourself to S/370 instructions? > > And why not even S/390 instructions, let alone z/Architecture instructions? > > Further, "need the high halves to be clear at all times" is not true. You > only would need the high halves (PLUS bit 32) to be zero for a register > used to access data and only at that point. > > At a minimum, you are surely violating linkage conventions by not > preserving the high halves of any regs 2-14 that you might use. > (BAKR is not a S/370 instruction; if you allow for use of BAKR then you > can conform to linkage conventions without needing to use a zArch > instruction such as STMG or STMH) > > Peter Relson > z/OS Core Technology Deisgn > > > -- > 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
Re: GETMAIN LOC=32
> BAKR is not a S/370 instruction ? IBM Enterprise Systems Architecture/370 Principles of Operation, SA22-7200-0, <http://bitsavers.org/pdf/ibm/370/princOps/SA22-7200-0_370-ESA_Principles_of_Operation_Aug88.pdf>, p 10-5, has Branch and Stack. Or weren't you counting 370-ESA as 370? From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Thursday, February 2, 2023 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 I couldn't find the original post for this thread even in the archives, so I don't know what this has to do with GETMAIN, or where "LOC=32" came into things since the parameter is LOC=31. I am exactly executing in AMODE 64. And so I need the high halves to be clear at all times. Because I am using pure S/370 instructions. I'll bite. Why would you choose to run in AMODE 64 if you are trying to restrict yourself to S/370 instructions? And why not even S/390 instructions, let alone z/Architecture instructions? Further, "need the high halves to be clear at all times" is not true. You only would need the high halves (PLUS bit 32) to be zero for a register used to access data and only at that point. At a minimum, you are surely violating linkage conventions by not preserving the high halves of any regs 2-14 that you might use. (BAKR is not a S/370 instruction; if you allow for use of BAKR then you can conform to linkage conventions without needing to use a zArch instruction such as STMG or STMH) Peter Relson z/OS Core Technology Deisgn -- 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
Re: GETMAIN LOC=32
I couldn't find the original post for this thread even in the archives, so I don't know what this has to do with GETMAIN, or where "LOC=32" came into things since the parameter is LOC=31. I am exactly executing in AMODE 64. And so I need the high halves to be clear at all times. Because I am using pure S/370 instructions. I'll bite. Why would you choose to run in AMODE 64 if you are trying to restrict yourself to S/370 instructions? And why not even S/390 instructions, let alone z/Architecture instructions? Further, "need the high halves to be clear at all times" is not true. You only would need the high halves (PLUS bit 32) to be zero for a register used to access data and only at that point. At a minimum, you are surely violating linkage conventions by not preserving the high halves of any regs 2-14 that you might use. (BAKR is not a S/370 instruction; if you allow for use of BAKR then you can conform to linkage conventions without needing to use a zArch instruction such as STMG or STMH) Peter Relson z/OS Core Technology Deisgn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
I am exactly executing in AMODE 64. And so I need the high halves to be clear at all times. Because I am using pure S/370 instructions. Previously I was hoping that z/OS would be changed to give a guarantee that the high halves were clear. Because the only alternative I could see was doing an LMH myself to clear them. It is only in the last week or something that I realized there was a S/370 instruction that would do the trick - LA. BFN. Paul. On Wed, 1 Feb 2023 22:46:24 -0500, Steve Smith wrote: >No. LA (and all LA variations) are modal, in that LA will not affect the >high-half of the register, unless executing in AMODE 64. > >Anyway, what's the point of clearing registers unless or until you need to >use them? > >sas > > >On Wed, Feb 1, 2023 at 8:02 PM Paul Edwards wrote: > >> On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards >> wrote: >> >> Sorry for the necro ... >> >> >On Sun, 6 May 2018 16:11:57 -0700, Charles Mills >> wrote: >> > >> >>2. A 31/32-bit program cannot count on the high >> >> halves being zero in any event. There is no >> >> guarantee that you are entered with the high >> >> halves equal to zero, >> > >> >The 32-bit program can clear all registers with >> >LMH if IBM can't guarantee high halves of 0. >> >It can do that once at startup and the rest of >> >the program doesn't need to change. >> >> I recently realized that I should be able to use "LA Rx,0" >> to clear the high 32-bits of undefined registers. (a separate >> LA for each register). >> >> This only uses S/370 instructions and future-proofs the >> code for if IBM produces a machine with 128-bit or 256-bit >> registers. >> >> I'm thinking undefined registers on program entry need to >> be cleared with LA, and whenever you call a z/OS service, >> any register documented as being trashed needs to be >> cleared (with LA) on return. >> >> I think that is sufficient? >> >> 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
Re: GETMAIN LOC=32
No. LA (and all LA variations) are modal, in that LA will not affect the high-half of the register, unless executing in AMODE 64. Anyway, what's the point of clearing registers unless or until you need to use them? sas On Wed, Feb 1, 2023 at 8:02 PM Paul Edwards wrote: > On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards > wrote: > > Sorry for the necro ... > > >On Sun, 6 May 2018 16:11:57 -0700, Charles Mills > wrote: > > > >>2. A 31/32-bit program cannot count on the high > >> halves being zero in any event. There is no > >> guarantee that you are entered with the high > >> halves equal to zero, > > > >The 32-bit program can clear all registers with > >LMH if IBM can't guarantee high halves of 0. > >It can do that once at startup and the rest of > >the program doesn't need to change. > > I recently realized that I should be able to use "LA Rx,0" > to clear the high 32-bits of undefined registers. (a separate > LA for each register). > > This only uses S/370 instructions and future-proofs the > code for if IBM produces a machine with 128-bit or 256-bit > registers. > > I'm thinking undefined registers on program entry need to > be cleared with LA, and whenever you call a z/OS service, > any register documented as being trashed needs to be > cleared (with LA) on return. > > I think that is sufficient? > > 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
Re: GETMAIN LOC=32
On Sun, 6 May 2018 18:34:35 -0500, Paul Edwards wrote: Sorry for the necro ... >On Sun, 6 May 2018 16:11:57 -0700, Charles Mills wrote: > >>2. A 31/32-bit program cannot count on the high >> halves being zero in any event. There is no >> guarantee that you are entered with the high >> halves equal to zero, > >The 32-bit program can clear all registers with >LMH if IBM can't guarantee high halves of 0. >It can do that once at startup and the rest of >the program doesn't need to change. I recently realized that I should be able to use "LA Rx,0" to clear the high 32-bits of undefined registers. (a separate LA for each register). This only uses S/370 instructions and future-proofs the code for if IBM produces a machine with 128-bit or 256-bit registers. I'm thinking undefined registers on program entry need to be cleared with LA, and whenever you call a z/OS service, any register documented as being trashed needs to be cleared (with LA) on return. I think that is sufficient? BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MVCL (was Re: GETMAIN LOC=32)
You either want to make the lights dim or clear out a huge buffer pool or both. Jim On Thu, May 24, 2018 at 11:17 AM, Steve Smithwrote: > Yeah, and there's this new book called Principles of Operation you might > want to check out. Unless you'd rather it was just quoted piece-meal here. > > btw, MVCLE extends the maximum length, albeit not usefully. However, I > still have to believe that if you want to move 16mb, you're probably not > thinking things through very well. I'd love to hear why that would be > necessary. > > sas > > On Thu, May 24, 2018 at 1:03 PM, Mike Schwab > wrote: > > > For MVCL the fill byte is the same and maximum length is still 16 MiB, > > just like AM31. Uses 64 bit source and target address. > > -- > 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
MVCL (was Re: GETMAIN LOC=32)
Yeah, and there's this new book called Principles of Operation you might want to check out. Unless you'd rather it was just quoted piece-meal here. btw, MVCLE extends the maximum length, albeit not usefully. However, I still have to believe that if you want to move 16mb, you're probably not thinking things through very well. I'd love to hear why that would be necessary. sas On Thu, May 24, 2018 at 1:03 PM, Mike Schwabwrote: > For MVCL the fill byte is the same and maximum length is still 16 MiB, > just like AM31. Uses 64 bit source and target address. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
For MVCL the fill byte is the same and maximum length is still 16 MiB, just like AM31. Uses 64 bit source and target address. On Wed, May 23, 2018 at 10:41 PM, Ed Jaffewrote: > On 5/11/2018 2:24 PM, Bernd Oppolzer wrote: >> >> For example: I'm not really familiar with the new 64 bit instruction, >> but there must be an instruction similar to MVCL, involving two >> 64 bit address registers and two length registers. > > > Yes. It's called MVCL. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > http://www.phoenixsoftware.com/ > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On 5/11/2018 2:24 PM, Bernd Oppolzer wrote: For example: I'm not really familiar with the new 64 bit instruction, but there must be an instruction similar to MVCL, involving two 64 bit address registers and two length registers. Yes. It's called MVCL. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 17:21:56 -0500, John McKownwrote: >> And there's no downside. 32-bit programs get >> access to a full 32-bit virtual memory, and >> 64-bit programs get access to a full 64-bit >> virtual memory. > >I really think you would be impressed by the IBMi. The hardware is a >slightly modified Power8 processor. The IBMi has 128 bit addressing right >now. And there are no "lines" or "bars" in that anywhere. There are natural bars created by register size, so 32 and 64 seem fine to me. All I'm trying to do is get z/Arch operating systems to allow nature to bloom. :-) I'm wondering if it would be best to lobby the z/Linux people to switch to running in pure AM-infinity before trying again on z/OS. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, May 15, 2018 at 4:17 PM, Paul Edwardswrote: > A GETMAIN LOC=64 for 64-bit programs would be good. > I see absolutely no need for this. It would most likely just invoke the current IARV64 code, in a "crippled" mode (i.e. IBM decides things that the real IARV64 allows the programmer to choose at present). The programmer would either deliberately dual path the code for the LOC=64 needs, or use a macro which would do the dual path for them. > > > How are you planning to justify all this work to IBM? > > How much additional money in terms of hardware > > purchases or software purchases will the writers of > > AM(32) modules be spending with IBM, to justify all > > the development and testing resources that your > > growing list of changes will require? > > It's not AM32, it's AM-infinity, and it's the gold > standard of computing as far as I can tell. People > should migrate to z/Arch instead of x64 because > x64 is likely to be saddled by needing special > modes for 32 and 64 that don't exist on a pure > 64-bit z/Arch. > > And there's no downside. 32-bit programs get > access to a full 32-bit virtual memory, and > 64-bit programs get access to a full 64-bit > virtual memory. > I really think you would be impressed by the IBMi. The hardware is a slightly modified Power8 processor. The IBMi has 128 bit addressing right now. And there are no "lines" or "bars" in that anywhere. When I looked at it a few years ago, it was restricted to only actually using 48 of the 128 bits. But it has already planned for the future. I cannot see anyone, ever, being able to actually use an entire 128 bit address because there aren't that many atoms in our current universe. 2^128-1 = 3.4E+38. So it's impossible to build the hardware. > > BFN. Paul. > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
Evaluated purely on technical merit, I really like this idea. IMO it comes close to making some sort of elegant simplicity category. But if evaluated based on cost benefit, things seem extremely murky indeed. It also appears to be primarily championed by folks from the Hercules and OS380 developer community, folks that represent the wants and needs of IBM's bread and butter zSeries customer base. Right? With unlimited development resources, fantastic idea, otherwise I think digging a hole for the carcass is overdue. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, May 15, 2018 11:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 I should know better than to poke this thing again but I just do not see how it makes sense. - If the code runs AM=31 then 32-bit addresses will not work. - If the code runs AM=64 then the high words of the registers are significant. One cannot count on them being zero -- trust me on this, been there and got the S0C4 tee shirt* -- so you now have to at least be cognizant of high halves of registers, which defeats the OP's idea of pretending that bits 0-31 don't exist. You have to save those high halves (if you want to be well-behaved) and you have to zero or LLGF into them. And by running AM=64 aren't you getting away from this (silly IMHO) concept of portability back to s/370? Does that not make the case for this fall apart? The sole benefit is that programs could address > 2GB (and < 4GB) while still storing pointers in "traditional" single-word fields -- saving storage and saving having to re-work DSECTs. That's a lot of work on IBM's part to solve a very narrow need in the application world -- programs that need more than 2GB but will never need more than 4GB (or where the expansion to > 4GB cannot be justified). You want to do your RFE? Go for it. Follow @Jim's suggestion of requesting that STORAGE support asking for storage in the 2GB to 4GB range. That is your entire solution, right? *In fact at the last SHARE I learned a cool testing technique from @Ray Mullins. When testing an AM=64 subroutine, on entry do a LHM 0,15,=16F'-1'. That way you will pick up in testing any failures to properly initialize high register halves. Otherwise it will bite you now and then down the road. You can do the same thing with AR's when testing AR-mode code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, May 15, 2018 8:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Tue, May 15, 2018 at 10:03 AM, Paul Edwards <mutazi...@gmail.com> wrote: > On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe > <edja...@phoenixsoftware.com> > wrote: > > >On 5/12/2018 2:02 PM, Ed Jaffe wrote: > > >Of course, you might have to change numerous existing LLGT > >instructions into LLGF instructions, but that's only a fraction of > >the effort needed to widen all of your pointers. > > I'm not familiar with LLGT. All my code uses 32-bit instructions found > in S/370, so there is no LLGT to change. If you simply write your > 32-bit code sensibly (don't use the high bit or byte in addresses for > flags), it will run AM-infinity, including AM64. > I think what Ed is getting at is to load a "32 bit" pointer, you need to insure that the high word of the register being loaded (bits 0..31) are zero. You can do this simply by somehow being sure that it is and using an L, or the LLGF will load the 32 bits into the low word (32..63) of the register and zero out the high word automatically (bits 0..31). This is the safest way, rather than using an old fashioned L instruction. Of course, if you are absolutely certain that the high word will always be zero, then this is overkill. -- 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
Re: GETMAIN LOC=32
On Tue, 15 May 2018 15:56:45 -0500, Walt Farrellwrote: > You want GETMAIN updated (though the key z/OS > designers have already said that won't happen). > You probably want z/OS storage layout changed, > so you can acquire more storage. And now you > want LINK changed to manage registers differently. This is all in order to get a clean AM-infinity technology in place, that is something that rival architectures like x64 cannot match. 32-bit and 64-bit programs can co-exist in the exact same AM-infinity environment. I'm not familiar with z/Linux, but I assume 32-bit modules in z/Linux are currently run as AM31 instead of AM64 too. z/OS could lead the way to changing that. >What additional changes will you need next in > z/OS in order to support this addressing mode > that IBM hasn't seen a need for? A GETMAIN LOC=64 for 64-bit programs would be good. > How are you planning to justify all this work to IBM? > How much additional money in terms of hardware > purchases or software purchases will the writers of > AM(32) modules be spending with IBM, to justify all > the development and testing resources that your > growing list of changes will require? It's not AM32, it's AM-infinity, and it's the gold standard of computing as far as I can tell. People should migrate to z/Arch instead of x64 because x64 is likely to be saddled by needing special modes for 32 and 64 that don't exist on a pure 64-bit z/Arch. And there's no downside. 32-bit programs get access to a full 32-bit virtual memory, and 64-bit programs get access to a full 64-bit virtual memory. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 12:10:46 -0500, Paul Edwardswrote: >On Tue, 15 May 2018 11:57:55 -0500, Tom Marchant >wrote: > >>>There are multiple ways of guaranteeing 0. The >>>best is IBM guaranteeing it on entry to a program, >>>as another RFE. In the single test that I requested, >>>the high bits seem to be 0 already. I just want to >>>formalize that. >> >>IBM cannot guarantee that. A basic principle in MVS is that any program >>can be called by another program. You don't know how a program that >>calls you might use the 64-bit registers. > >I don't see anything wrong with "LINK" being >updated to save the high 32-bits (or more, >in future) of registers and then zeroing them so >that called 32-bit programs can run in AM64 or >AM128 or AM256. Who will be affected? "LINK" >can be updated to accept an AM64 caller at the >same time. And so it grows. You want GETMAIN updated (though the key z/OS designers have already said that won't happen). You probably want z/OS storage layout changed, so you can acquire more storage. And now you want LINK changed to manage registers differently. What additional changes will you need next in z/OS in order to support this addressing mode that IBM hasn't seen a need for? How are you planning to justify all this work to IBM? How much additional money in terms of hardware purchases or software purchases will the writers of AM(32) modules be spending with IBM, to justify all the development and testing resources that your growing list of changes will require? -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 13:07:10 -0500, Tom Marchantwrote: >>>any program can be called by another program. >> >>I don't see anything wrong with "LINK" being >>updated to save the high 32-bits > >"CALL" is not the same as "LINK". > >The operating system does not get involved in any way on a CALL. Oh sure. A 64-bit program doing a CALL to a 32-bit routine will be required to save and clear the high 32 bits of registers. Or do it the other way around and a 32-bit routine is able to protect itself from dirty upper bits. I would suggest that the first option is better as only a 64-bit program is required to have knowledge of and manipulate 64-bit registers. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 12:10:46 -0500, Paul Edwards wrote: >On Tue, 15 May 2018 11:57:55 -0500, Tom Marchant wrote: > >>any program can be called by another program. > >I don't see anything wrong with "LINK" being >updated to save the high 32-bits "CALL" is not the same as "LINK". The operating system does not get involved in any way on a CALL. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 11:57:55 -0500, Tom Marchantwrote: >>There are multiple ways of guaranteeing 0. The >>best is IBM guaranteeing it on entry to a program, >>as another RFE. In the single test that I requested, >>the high bits seem to be 0 already. I just want to >>formalize that. > >IBM cannot guarantee that. A basic principle in MVS is that any program >can be called by another program. You don't know how a program that >calls you might use the 64-bit registers. I don't see anything wrong with "LINK" being updated to save the high 32-bits (or more, in future) of registers and then zeroing them so that called 32-bit programs can run in AM64 or AM128 or AM256. Who will be affected? "LINK" can be updated to accept an AM64 caller at the same time. BTW, in another message I forgot to mention that to detect AM64, the "LA" instruction should be used so that it still works on S/370. That's for the solution where the 32-bit program needs a stub at entry to clear the high 32 bits itself with LMH so the rest of it can run AM64 without issue and without program change. The LMH would be bypassed if non-AM64 is detected. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 10:50:49 -0500, Paul Edwards wrote: >There are multiple ways of guaranteeing 0. The >best is IBM guaranteeing it on entry to a program, >as another RFE. In the single test that I requested, >the high bits seem to be 0 already. I just want to >formalize that. IBM cannot guarantee that. A basic principle in MVS is that any program can be called by another program. You don't know how a program that calls you might use the 64-bit registers. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 08:33:13 -0700, Charles Millswrote: >I should know better than to poke this thing again but I just do not see how >it makes sense. > >- If the code runs AM=31 then 32-bit addresses will not work. >- If the code runs AM=64 then the high words of the registers are significant. >One cannot count on them being zero -- trust me on this, been there and got >the S0C4 tee shirt* -- so you now have to at least be cognizant of high halves >of registers, which defeats the OP's idea of pretending that bits 0-31 don't >exist. You have to save those high halves (if you want to be well-behaved) and >you have to zero or LLGF into them. And by running AM=64 aren't you getting >away from this (silly IMHO) concept of portability back to s/370? > >Does that not make the case for this fall apart? If you assume nothing changes, then indeed can be no AM32 for the very reasons you cite. But if you make certain assumptions and restrictions, you can have it without too much effort. But those restrictions are a bummer. You can't reliably CALL a 31-bit interface with 32-bit storage addresses, even if it has a fixed number of parameters. The called code isn't going to be assured to be "AM32-clean". I remember when we had to XA-ize CMS and all of the AMODE switching internally to deal with new programs calling old interfaces. It wasn't free. But as an intellectual exercise on how to write "old" code in an AM64 environment and get some of the benefits for free, it's been interesting. As you point out, not worth IBM's effort to accommodate such a small group of beneficiaries, but interesting nonetheless. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 08:33:13 -0700, Charles Mills <charl...@mcn.org> wrote: >I should know better than to poke this thing again but I just do not see how >it makes sense. > >- If the code runs AM=31 then 32-bit addresses will not work. Doing a GETMAIN LOC=32 will still work if AM31 because GETMAIN is smart enough to check the current AMODE and if it is 24 you will only get LOC=24 storage and if it is 31 you will only get LOC=31 storage. >- If the code runs AM=64 then the high words of the > registers are significant. One cannot count on them > being zero -- trust me on this, been there and got > the S0C4 tee shirt* -- There are multiple ways of guaranteeing 0. The best is IBM guaranteeing it on entry to a program, as another RFE. In the single test that I requested, the high bits seem to be 0 already. I just want to formalize that. > so you now have to at least be cognizant of high > halves of registers, which defeats the OP's idea > of pretending that bits 0-31 don't exist. You have > to save those high halves (if you want to be > well-behaved) If IBM won't guarantee it, then startup code can conditionally check if it was invoked in AM64 and do a single F5SA save area, and from then on the normal 32-bit code can be run. > and you have to zero or LLGF into them. And by > running AM=64 aren't you getting away from this > (silly IMHO) concept of portability back to s/370? No. AM64 would be done on z/OS only. The code should be trimodal (24/31/64) and thus run happily in AM24 on S/370. The LOC=32 flags will be ignored on S/370. >Does that not make the case for this fall apart? I don't think so. > Follow @Jim's suggestion of requesting that STORAGE > support asking for storage in the 2GB to 4GB range. > That is your entire solution, right? I would prefer to have a GETMAIN LOC=32 that called IARV64 under the covers rather than my application needing to do that. >*In fact at the last SHARE I learned a cool testing > technique from @Ray Mullins. When testing an > AM=64 subroutine, on entry do a LHM 0,15,=16F'-1'. > That way you will pick up in testing any failures to > properly initialize high register halves. Otherwise > it will bite you now and then down the road. And a similar load (LMH) with F'0' will do the required initialization of everything. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
I should know better than to poke this thing again but I just do not see how it makes sense. - If the code runs AM=31 then 32-bit addresses will not work. - If the code runs AM=64 then the high words of the registers are significant. One cannot count on them being zero -- trust me on this, been there and got the S0C4 tee shirt* -- so you now have to at least be cognizant of high halves of registers, which defeats the OP's idea of pretending that bits 0-31 don't exist. You have to save those high halves (if you want to be well-behaved) and you have to zero or LLGF into them. And by running AM=64 aren't you getting away from this (silly IMHO) concept of portability back to s/370? Does that not make the case for this fall apart? The sole benefit is that programs could address > 2GB (and < 4GB) while still storing pointers in "traditional" single-word fields -- saving storage and saving having to re-work DSECTs. That's a lot of work on IBM's part to solve a very narrow need in the application world -- programs that need more than 2GB but will never need more than 4GB (or where the expansion to > 4GB cannot be justified). You want to do your RFE? Go for it. Follow @Jim's suggestion of requesting that STORAGE support asking for storage in the 2GB to 4GB range. That is your entire solution, right? *In fact at the last SHARE I learned a cool testing technique from @Ray Mullins. When testing an AM=64 subroutine, on entry do a LHM 0,15,=16F'-1'. That way you will pick up in testing any failures to properly initialize high register halves. Otherwise it will bite you now and then down the road. You can do the same thing with AR's when testing AR-mode code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, May 15, 2018 8:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Tue, May 15, 2018 at 10:03 AM, Paul Edwards <mutazi...@gmail.com> wrote: > On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe <edja...@phoenixsoftware.com> > wrote: > > >On 5/12/2018 2:02 PM, Ed Jaffe wrote: > > >Of course, you might have to change numerous existing LLGT instructions > >into LLGF instructions, but that's only a fraction of the effort needed > >to widen all of your pointers. > > I'm not familiar with LLGT. All my code uses > 32-bit instructions found in S/370, so there is > no LLGT to change. If you simply write your > 32-bit code sensibly (don't use the high bit > or byte in addresses for flags), it will run > AM-infinity, including AM64. > I think what Ed is getting at is to load a "32 bit" pointer, you need to insure that the high word of the register being loaded (bits 0..31) are zero. You can do this simply by somehow being sure that it is and using an L, or the LLGF will load the 32 bits into the low word (32..63) of the register and zero out the high word automatically (bits 0..31). This is the safest way, rather than using an old fashioned L instruction. Of course, if you are absolutely certain that the high word will always be zero, then this is overkill. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 10:13:05 -0500, John McKownwrote: >I think what Ed is getting at is to load a "32 bit" pointer, you need to >insure that the high word of the register being loaded (bits 0..31) are >zero. You can do this simply by somehow being sure that it is and using an >L, or the LLGF will load the 32 bits into the low word (32..63) of the >register and zero out the high word automatically (bits 0..31). This is the >safest way, rather than using an old fashioned L instruction. Of course, if >you are absolutely certain that the high word will always be zero, then >this is overkill. Oh I see. I wish to use "L", and assume that the high 32 bits are 0, so that existing 32-bit code works without change. So let's discuss how to ensure the high 32 bits are 0. Ideally IBM would guarantee that in the documentation. I only got one test case done on z/OS and it worked, which meant sufficient high bits in registers were zero. They just need to formalize that. Alternatively, we can use our own loader that zeroes out the top 32 bits using LMH prior to executing our 32-bit application. Another option is to have some startup code in the 32-bit application that manipulates the 64-bit registers by doing a LMH to zero them out. It only needs to be done once, because the rest of the 32-bit application will not disturb the top 32 bits. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, May 15, 2018 at 10:03 AM, Paul Edwardswrote: > On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe > wrote: > > >On 5/12/2018 2:02 PM, Ed Jaffe wrote: > > >Of course, you might have to change numerous existing LLGT instructions > >into LLGF instructions, but that's only a fraction of the effort needed > >to widen all of your pointers. > > I'm not familiar with LLGT. All my code uses > 32-bit instructions found in S/370, so there is > no LLGT to change. If you simply write your > 32-bit code sensibly (don't use the high bit > or byte in addresses for flags), it will run > AM-infinity, including AM64. > I think what Ed is getting at is to load a "32 bit" pointer, you need to insure that the high word of the register being loaded (bits 0..31) are zero. You can do this simply by somehow being sure that it is and using an L, or the LLGF will load the 32 bits into the low word (32..63) of the register and zero out the high word automatically (bits 0..31). This is the safest way, rather than using an old fashioned L instruction. Of course, if you are absolutely certain that the high word will always be zero, then this is overkill. > BFN. Paul. > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffewrote: >On 5/12/2018 2:02 PM, Ed Jaffe wrote: >> On 5/6/2018 11:51 AM, Paul Edwards wrote: >>> Hi. I would like to submit an RFE to IBM to >> Impossible. > >Sorry. I misread your request. Yeah, I didn't think it was impossible, but I didn't have the knowledge to answer your post. >I thought you were looking for -- in effect -- 32-bit addressing when >what you're really looking for is 64-bit addressing with storage >addresses that are guaranteed to fit into four bytes. Right. >IMHO, your idea has merit. Thankyou for your support. >Doubling the size of storage pointers from >four bytes to eight bytes (as we have done on many occasions) can >require significant programming effort and can use a lot more >storage/cache. Assuming your code is already running in 64-bit mode, it >would be nice to be able to more than double the amount of storage you >can acquire without having to go through all of that hassle. Exactly. Note that it would be unusual for a 32-bit program to already be physically running in AM64, but a clean 32-bit program would already be AM64-compliant. I believe we should be making sure 32-bit programs are "clean", ie don't use the top bit in a 32-bit address as a flag, expecting it to be ignored. So in future we can produce a pure AM64 site. I think that is something to aim for, and we should start now. >Of course, you might have to change numerous existing LLGT instructions >into LLGF instructions, but that's only a fraction of the effort needed >to widen all of your pointers. I'm not familiar with LLGT. All my code uses 32-bit instructions found in S/370, so there is no LLGT to change. If you simply write your 32-bit code sensibly (don't use the high bit or byte in addresses for flags), it will run AM-infinity, including AM64. >Java uses USE2GTO32G=YES and USE2GTO64G=YES, but they LLGF/SLLG every >such pointer before using it for addressing. Implementing that technique >would require a lot of programming effort as well. > >Your idea can be implemented nearly transparently. I like it... Thankyou! By the way, now that you're on board, I have another suggestion on load modules. I believe they have some logical independent attributes: pure24 can be located anywhere in 24-bit space, and run as AM24 pure31 can be located anywhere in 31-bit space, and run as AM31 31-with-RM24 must be located in 24-bit space, but run as AM31 pure32 can be located anywhere in 32-bit space, and run as AM32 32-with-RM24 must be located in 24-bit space, but run as AM32 pure64 can be located anywhere in 64-bit space, and run as AM64 64-with-RM24 64-bit program must be located in 24-bit space, but run as AM64 64-with-RM32 64-bit program must be located in 32-bit space, but run as AM64 has-stepdown when the OS loads the program in RM24/RM31 space, the application will do a BSM to switch to AM24/AM31 prior to calling OS functions am-anything application does not use negative indexes expecting an address wrap, and thus can run in AM64, AM128, AM256, AM-infinity So for example a module that is marked pure24 and pure31, but no stepdown, when run on MVS/XA (where I/O routines need to be executed in AM24), would let MVS/XA know that it can't actually be run as AM31, even though it has the "pure31" attribute, because there is no facility to step down to AM24. As such, the application must be run as AM24 rather than AM31. Even though it is too late to add all these flags, this is what a module logically is, and we need to translate these logical attributes into a specific AMODE and RMODE to match a particular operating system. A basic premise in all of this is that the application should be written in a way that it just passively accepts whatever AMODE and RMODE it was run in, rather than requiring a specific AMODE/RMODE. And AMODE switching to match the operating system should be in a "step-down" manner that you can see in function @@SETUP here: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On 5/12/2018 2:02 PM, Ed Jaffe wrote: On 5/6/2018 11:51 AM, Paul Edwards wrote: Hi. I would like to submit an RFE to IBM to Impossible. Sorry. I misread your request. I thought you were looking for -- in effect -- 32-bit addressing when what you're really looking for is 64-bit addressing with storage addresses that are guaranteed to fit into four bytes. IMHO, your idea has merit. Doubling the size of storage pointers from four bytes to eight bytes (as we have done on many occasions) can require significant programming effort and can use a lot more storage/cache. Assuming your code is already running in 64-bit mode, it would be nice to be able to more than double the amount of storage you can acquire without having to go through all of that hassle. Of course, you might have to change numerous existing LLGT instructions into LLGF instructions, but that's only a fraction of the effort needed to widen all of your pointers. Java uses USE2GTO32G=YES and USE2GTO64G=YES, but they LLGF/SLLG every such pointer before using it for addressing. Implementing that technique would require a lot of programming effort as well. Your idea can be implemented nearly transparently. I like it... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Mon, 14 May 2018 19:36:29 +, Seymour J Metzwrote: > At least one poster in this thread made reference > to the high 32 bits being altered. Are you saying > that he was in error? Here is a test of a 32-bit program running in AM64 on z/OS: welcome to pdptest main function is at 11913024 first byte of main is 47 running as amode 64 allocating 10 bytes m1 is 11915248 allocating 20 bytes m2 is 11915288 stack is around 7330 copying from file dd:in, mode text to file dd:out, mode text 16 bytes copied The source code can be found here: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/pdptest.c But of more interest is the assembler driver: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm Especially the GAMOS/GAMAPP macros and the @@SETUP routine that allows the 32-bit program to be quadmodal (AM24/31/32/64) and run on any environment (MVS/XA etc) thanks to the "step down" in GAMOS. Note that I am planning on changing the @@SETUP function so that it is defined not by ZSYS but instead a "STEPDOWN" variable. Note what Greg Price had to say - you CAN write quadmodal code, but up until now, no-one HAS, for no particular reason. quadmodal code paves the way for a pure 64-bit site, which is what I would like to see. ie both 32-bit and 64-bit programs running exclusively as AM64 on a z/OS site. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
At least one poster in this thread made reference to the high 32 bits being altered. Are you saying that he was in error? -- 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: Monday, May 14, 2018 3:31 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Mon, 14 May 2018 19:21:59 +, Seymour J Metz <sme...@gmu.edu> wrote: >>>In all of this, I don't remember the OP ever mentioning saving and restoring >>>the 64-bit registers. Without doing that the calling conventions are >>>violated, >>>and you are breaking any AMODE(64) caller. >>The intention was for this to be used by a 32-bit >>program, that only executes 32-bit instructions, >>that only ever change 32-bit registers, which >>means that you only need to save and restore >>32-bit registers. >So there was no intention to run under z/OS? I don't understand the comment. z/OS is indeed a target, and if you try running a 32-bit program in AM64 on z/OS you will find that it runs perfectly fine, and you only need to save the 32-bit registers. So long as you only use 32-bit instructions and don't disturb the upper 32 bits of registers. 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
Re: GETMAIN LOC=32
On Mon, 14 May 2018 19:21:59 +, Seymour J Metzwrote: >>>In all of this, I don't remember the OP ever mentioning saving and restoring >>>the 64-bit registers. Without doing that the calling conventions are >>>violated, >>>and you are breaking any AMODE(64) caller. >>The intention was for this to be used by a 32-bit >>program, that only executes 32-bit instructions, >>that only ever change 32-bit registers, which >>means that you only need to save and restore >>32-bit registers. >So there was no intention to run under z/OS? I don't understand the comment. z/OS is indeed a target, and if you try running a 32-bit program in AM64 on z/OS you will find that it runs perfectly fine, and you only need to save the 32-bit registers. So long as you only use 32-bit instructions and don't disturb the upper 32 bits of registers. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
So there was no intention to run under z/OS? -- 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: Monday, May 14, 2018 10:21 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: GETMAIN LOC=32 On Mon, 14 May 2018 07:14:40 -0500, Tom Marchant <m42tom-ibmm...@yahoo.com> wrote: >In all of this, I don't remember the OP ever mentioning saving and restoring >the 64-bit registers. Without doing that the calling conventions are violated, >and you are breaking any AMODE(64) caller. The intention was for this to be used by a 32-bit program, that only executes 32-bit instructions, that only ever change 32-bit registers, which means that you only need to save and restore 32-bit registers. 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
Re: GETMAIN LOC=32
On Mon, 14 May 2018 07:14:40 -0500, Tom Marchantwrote: >In all of this, I don't remember the OP ever mentioning saving and restoring >the 64-bit registers. Without doing that the calling conventions are violated, >and you are breaking any AMODE(64) caller. The intention was for this to be used by a 32-bit program, that only executes 32-bit instructions, that only ever change 32-bit registers, which means that you only need to save and restore 32-bit registers. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
In all of this, I don't remember the OP ever mentioning saving and restoring the 64-bit registers. Without doing that the calling conventions are violated, and you are breaking any AMODE(64) caller. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On 5/6/2018 11:51 AM, Paul Edwards wrote: Hi. I would like to submit an RFE to IBM to support a LOC=32 parameter to GETMAIN, giving 32-bit programs access to a full 4 GiB instead of the current 2 GiB provided by LOC=31. Impossible. That area is not mapped by an STE in any current IBM Z hardware. You need a RTE (3rd) to get to it. That makes it "above the bar" storage. Do what everyone else does. Use IARV64 REQUEST=GETSTOR with either USE2GTO32G=YES or USE2GTO64G=YES to acquire space in that area. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 16:45:38 -0500, Paul Edwardswrote: >Yes, I agree that it is possible to construct a >defacto AM64 32-bit program by making the >compiler generate an unusual z/OS-specific >module. I think you could call this a 32:32 segmented memory model. Especially if you are using multiple continents. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 23:42:14 +0200, Bernd Oppolzerwrote: >When a runtime function is called, this function will probably need a >service which implies AMODE/RMODE 24. If you are using z/OS, I think you will find all the services you require are AM31/RM31-clean, no need to dumb down to AM24/RM24. I recommend you passively accept whatever RMODE you are loaded as (ie just check whatever you are using as a base register), and use that to determine which AMODE to step down to. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 23:24:51 +0200, Bernd Oppolzer <bernd.oppol...@t-online.de> wrote: >> Note that he achieved this by allocating 4 GiB >> above the 4 GiB bar, in order to get 2 GiB. While >> this technique certainly has its merits, it would >> be easier to write the compiler if IBM simply >> provided an IARV64 GETSTOR USE2GBTO4GB. >> Although that wouldn't guarantee a full 2 GiB >> like he was able to get with his technique. > >I don't think that he gets only 2 GiB; He said that he allocated 4 GiB, with the purpose of getting a guaranteed 2 GiB that can be aligned in a manner that addresses with the high bit of a 32 bit register can actually point to valid addresses. You seem to be proposing a full 4 GiB continent. That should also work, and may be a superior way of doing things so long as, as you mentioned, you can change the compiler to do whatever you want. >Back to your original question: a program generated in this >compatible way could IMO grow up to 4 GB in size, when run in AMODE 64; >this way you have what you want: a program which can be up to 4 GB in size, >runs in AMODE 64 and has 4 byte pointers. But no change from IBM is needed. Yes, I agree that it is possible to construct a defacto AM64 32-bit program by making the compiler generate an unusual z/OS-specific module. But I am after compatibility with MVS 3.8j so would like a GETMAIN LOC=32 (the LOC=32 will be ignored on MVS 3.8j). BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
See my other post also; there should be a separation between the (address) registers that have continent information in the upper half and the other that have not. The compiler which generates the code takes care about this. When a runtime function is called, this function will probably need a service which implies AMODE/RMODE 24. This means that the (Pascal) code will call the runtime, which resides below 16 MB. The details of the parameter passing have to be designed; maybe the Pascal code must be able to access the LOC=24 storage before the runtime call by manipulating certain address registers. Or, it uses the remaining registers (3, 5, 7, 9, 11), which don't contain continent information in the upper half by default. Inside the runtime, the AMODE switch is done. Kind regards Bernd Am 11.05.2018 um 21:14 schrieb Paul Edwards: Good point. But note that if the application also uses LOC=24 or LOC=31 storage, that will need to be in an address register that has the upper 32 bits as 0. BFN. Paul. On Fri, 11 May 2018 14:09:59 -0500, Mike Schwabwrote: If you stick with 32 bit arithmatic instructions, it does not use the upper 32 bits. of each register, so having the upper 32 bits set like the address register does no harm. On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer wrote: What I found most interesting in this whole thread was a suggestion from (IIRC) a SAS guy some days before. He suggested, if I understood it correctly, that a large application should run in AM64, but store internally only 32 bit pointers; the left half of all registers used as address registers containing the same (nonzero) value all the time ... as long as the current "continent" (defined by this nonzero value in the left half) is not exited. This could be a pattern for compiler writers, too, IMO, and has some implications: you need a separation of address registers and arithmetic registers internally; that is: the compiler has to know all the time which one out of the 16 general registers is used for what, and it has to do some housekeeping on this. And: passing control to another "continent" is somehow complicated. But imagine what you get for this: no need to change all the pointer fields from 4 byte to 8 byte. I find this very promising. Every seperately compiled "unit" should fit into one continent, anyway ... As you might probably know, I am the maintainer of the New Stanford Pascal compiler; if I ever reach the point where generating 64 bit code gets interesting, I will think more about this option. At the moment, even 31 bit would be very nice, because I am still bound to AMODE 24. Stanford Pascal website: http://bernd-oppolzer.de/job9.htm on Facebook: https://www.facebook.com/StanfordPascal/ on GitHub: https://github.com/StanfordPascal/Pascal Kind regards Bernd Am 11.05.2018 um 17:48 schrieb John McKown: On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll < wdrisc...@rocketsoftware.com> wrote: Paul, Unlike Hercules, z/Architecture is part of a business, and, as such, a business value needs to be made in order to get support for changes, in particular radical changes like AM32. "it would be nice" and "but it's so cool" aren't business rationalizations for the amount of potentially broken customer code that would result from the change you propose. In order to not have to recompile all applications, or maintain strict bounds between 32 bit apps and 64 bit apps like most other 64 bit architectures, I will gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64 bit address space. If your mythical AM32 was invented, applications would still have to switch back to AM31 before calling other AM31 code that expects a variable length paramter list. I still fail to see any business value to IBM's customers in what you are proposing. The real solution is to go back to the 1960s and tell the OS/360 developers to not use bit 0 as an "end of list" indicator. If OS/360 had used either an initial half(or full) word which indicated how many addresses were in the list following or, similar to CMS, had indicated the end-of-list with a fullword of high values (x0), then when the architecture was extended to "beyond 24 bit addresses", they could have use AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, the direct result of this "problem" in the design of OS/360. Of course, the OS/360 design made finding the end-of-list "easier" and did not "waste" a fullword of storage. I guess back in the day, that was a very big consideration. Wayne Driscoll Rocket Software Note - All opinions are strictly my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all?
Re: GETMAIN LOC=32
Am 11.05.2018 um 19:34 schrieb Paul Edwards: On Fri, 11 May 2018 19:22:22 +0200, Bernd Oppolzerwrote: What I found most interesting in this whole thread was a suggestion >from (IIRC) a SAS guy some days before. He suggested, if I understood it correctly, that a large application should run in AM64, but store internally only 32 bit pointers; the left half of all registers used as address registers containing the same (nonzero) value all the time ... as long as the current "continent" (defined by this nonzero value in the left half) is not exited. This could be a pattern for compiler writers, too, IMO, and has some implications: Note that he achieved this by allocating 4 GiB above the 4 GiB bar, in order to get 2 GiB. While this technique certainly has its merits, it would be easier to write the compiler if IBM simply provided an IARV64 GETSTOR USE2GBTO4GB. Although that wouldn't guarantee a full 2 GiB like he was able to get with his technique. I don't think that he gets only 2 GiB; because the application uses AMODE 64, all 64 bits take part of the addressing, and that means that all 32 low bits are part of the address. Every L and ST of addresses loads only the lower part of the address from storage to register (or the other way round); the higher part is already there. You only have to take care if you do arithmetic with all 64 bits of a register, which changes the upper half, that you do this either with a register that is not used for addressing or that you restore the "continent" in the upper half after this arithmetic. A branch to another program unit which resided in another "continent" has to change all upper halfs of all registers that are used for addressing, accordingly. If there is a (sort of) convention that tells what registers are used for addressing, you can keep the places minimal where "continent information" needs to be saved, loaded or restored. For example: I'm not really familiar with the new 64 bit instruction, but there must be an instruction similar to MVCL, involving two 64 bit address registers and two length registers. In this case, the even registers (containing the addresses) should have the continent information, but the odd registers (containing the length) should not. Maybe this would be a simple convention: even register numbers have continent information in the left half by default, and odd registers don't have it. Exceptions for the registers 13, 15 and 1, which have continent information, too - due to their role in the linkage process. This would leave the registers 3, 5, 7, 9, 11 as pure "data" registers, where all 64 bits can be changed freely without thinking about the continent information in the left half. A compiler generated code for 31 bit using this sort of convention could maybe run with AMODE 64, too, if the runtime sets the continent information correctly before calling the generated code. So you could have the same code (using 4 byte pointers etc.) running with AMODE 31 and 64 ... using different initialization sequences in the two AMODEs. If I had enough time, it would be great fun to check out if this concept would really work. I would like to hear if someone sees any basic problem why this concept could not work ... As you might probably know, I am the maintainer of the New Stanford Pascal compiler; if I ever reach the point where generating 64 bit code gets interesting, I will think more about this option. If you're generating 64-bit code you may as well just use 64-bit pointers and produce a pure 64-bit application? Yes, but - see above - it would be interesting IMO to have the same code running in AMODE 31 and AMODE 64 and have only the runtime (or the initialization sequence) take care of the differences. (If I generate real 64 bit code, the offsets of structures containing pointers, for example, change, because all pointers now need 8 bytes ... so the code is completely different from the 31 bit code). I don't know yet if this is really possible. But if it is and if it is done correctly, it should not be slower than "normal" AMODE 64 using 8 byte pointers ... because there is no difference during execution, except that only the lower half of most pointers is stored and loaded and the higher half stays the same most of the time. BTW: even if you do static linkage, your resulting program object will probably fit into one "continent", so there will be no need to reload the continent parts of the registers when calling an external module. Maybe it is possible to limit "cross continent calls" to very special "dynamic" calls, which are special even at the source level of the programming language. Same goes for storage allocation; the normal allocation functions like malloc etc. should retrieve storage from inside the continent; only very special allocation functions should be able to allocate storage in new "continents". After all, 4 GB is large ... Back to your original question: a program
Re: GETMAIN LOC=32
Good point. But note that if the application also uses LOC=24 or LOC=31 storage, that will need to be in an address register that has the upper 32 bits as 0. BFN. Paul. On Fri, 11 May 2018 14:09:59 -0500, Mike Schwabwrote: >If you stick with 32 bit arithmatic instructions, it does not use the >upper 32 bits. of each register, so having the upper 32 bits set like >the address register does no harm. > >On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer > wrote: >> What I found most interesting in this whole thread was a suggestion >> from (IIRC) a SAS guy some days before. He suggested, if I understood >> it correctly, that a large application should run in AM64, but store >> internally >> only 32 bit pointers; the left half of all registers used as address >> registers >> containing the same (nonzero) value all the time ... as long as the current >> "continent" (defined by this nonzero value in the left half) is not exited. >> >> This could be a pattern for compiler writers, too, IMO, and has some >> implications: >> >> you need a separation of address registers and arithmetic registers >> internally; that is: the compiler has to know all the time which one >> out of the 16 general registers is used for what, and it has to do >> some housekeeping on this. And: passing control to another >> "continent" is somehow complicated. >> >> But imagine what you get for this: no need to change all the pointer >> fields from 4 byte to 8 byte. I find this very promising. Every seperately >> compiled "unit" should fit into one continent, anyway ... >> >> As you might probably know, I am the maintainer of the New Stanford >> Pascal compiler; if I ever reach the point where generating 64 bit code >> gets interesting, I will think more about this option. At the moment, >> even 31 bit would be very nice, because I am still bound to AMODE 24. >> >> Stanford Pascal website: http://bernd-oppolzer.de/job9.htm >> on Facebook: https://www.facebook.com/StanfordPascal/ >> on GitHub: https://github.com/StanfordPascal/Pascal >> >> Kind regards >> >> Bernd >> >> >> >> >> >> Am 11.05.2018 um 17:48 schrieb John McKown: >>> >>> On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll < >>> wdrisc...@rocketsoftware.com> wrote: >>> Paul, Unlike Hercules, z/Architecture is part of a business, and, as such, a business value needs to be made in order to get support for changes, in particular radical changes like AM32. "it would be nice" and "but it's so cool" aren't business rationalizations for the amount of potentially broken customer code that would result from the change you propose. In order to not have to recompile all applications, or maintain strict bounds between 32 bit apps and 64 bit apps like most other 64 bit architectures, I will gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64 bit address space. If your mythical AM32 was invented, applications would still have to switch back to AM31 before calling other AM31 code that expects a variable length paramter list. I still fail to see any business value to IBM's customers in what you are proposing. >>> The real solution is to go back to the 1960s and tell the OS/360 >>> developers to not use bit 0 as an "end of list" indicator. If OS/360 had >>> used either an initial half(or full) word which indicated how many >>> addresses were in the list following or, similar to CMS, had indicated the >>> end-of-list with a fullword of high values (x0), then when the >>> architecture was extended to "beyond 24 bit addresses", they could have >>> use >>> AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, >>> the >>> direct result of this "problem" in the design of OS/360. Of course, the >>> OS/360 design made finding the end-of-list "easier" and did not "waste" a >>> fullword of storage. I guess back in the day, that was a very big >>> consideration. >>> >>> >>> Wayne Driscoll Rocket Software Note - All opinions are strictly my own. >>> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > >-- >Mike A Schwab, Springfield IL USA >Where do Forest Rangers go to get away from it all? > >-- >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
Re: GETMAIN LOC=32
If you stick with 32 bit arithmatic instructions, it does not use the upper 32 bits. of each register, so having the upper 32 bits set like the address register does no harm. On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzerwrote: > What I found most interesting in this whole thread was a suggestion > from (IIRC) a SAS guy some days before. He suggested, if I understood > it correctly, that a large application should run in AM64, but store > internally > only 32 bit pointers; the left half of all registers used as address > registers > containing the same (nonzero) value all the time ... as long as the current > "continent" (defined by this nonzero value in the left half) is not exited. > > This could be a pattern for compiler writers, too, IMO, and has some > implications: > > you need a separation of address registers and arithmetic registers > internally; that is: the compiler has to know all the time which one > out of the 16 general registers is used for what, and it has to do > some housekeeping on this. And: passing control to another > "continent" is somehow complicated. > > But imagine what you get for this: no need to change all the pointer > fields from 4 byte to 8 byte. I find this very promising. Every seperately > compiled "unit" should fit into one continent, anyway ... > > As you might probably know, I am the maintainer of the New Stanford > Pascal compiler; if I ever reach the point where generating 64 bit code > gets interesting, I will think more about this option. At the moment, > even 31 bit would be very nice, because I am still bound to AMODE 24. > > Stanford Pascal website: http://bernd-oppolzer.de/job9.htm > on Facebook: https://www.facebook.com/StanfordPascal/ > on GitHub: https://github.com/StanfordPascal/Pascal > > Kind regards > > Bernd > > > > > > Am 11.05.2018 um 17:48 schrieb John McKown: >> >> On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll < >> wdrisc...@rocketsoftware.com> wrote: >> >>> Paul, >>> Unlike Hercules, z/Architecture is part of a business, and, as such, a >>> business value needs to be made in order to get support for changes, in >>> particular radical changes like AM32. "it would be nice" and "but it's so >>> cool" aren't business rationalizations for the amount of potentially >>> broken >>> customer code that would result from the change you propose. In order to >>> not have to recompile all applications, or maintain strict bounds between >>> 32 bit apps and 64 bit apps like most other 64 bit architectures, I will >>> gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64 >>> bit address space. If your mythical AM32 was invented, applications would >>> still have to switch back to AM31 before calling other AM31 code that >>> expects a variable length paramter list. I still fail to see any business >>> value to IBM's customers in what you are proposing. >>> >> The real solution is to go back to the 1960s and tell the OS/360 >> developers to not use bit 0 as an "end of list" indicator. If OS/360 had >> used either an initial half(or full) word which indicated how many >> addresses were in the list following or, similar to CMS, had indicated the >> end-of-list with a fullword of high values (x0), then when the >> architecture was extended to "beyond 24 bit addresses", they could have >> use >> AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, >> the >> direct result of this "problem" in the design of OS/360. Of course, the >> OS/360 design made finding the end-of-list "easier" and did not "waste" a >> fullword of storage. I guess back in the day, that was a very big >> consideration. >> >> >> >>> Wayne Driscoll >>> Rocket Software >>> Note - All opinions are strictly my own. >>> >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzerwrote: > What I found most interesting in this whole thread was a suggestion > from (IIRC) a SAS guy some days before. He suggested, if I understood > it correctly, that a large application should run in AM64, but store > internally > only 32 bit pointers; the left half of all registers used as address > registers > containing the same (nonzero) value all the time ... as long as the > current > "continent" (defined by this nonzero value in the left half) is not exited. > > This could be a pattern for compiler writers, too, IMO, and has some > implications: > > you need a separation of address registers and arithmetic registers > internally; that is: the compiler has to know all the time which one > out of the 16 general registers is used for what, and it has to do > some housekeeping on this. And: passing control to another > "continent" is somehow complicated. > > But imagine what you get for this: no need to change all the pointer > fields from 4 byte to 8 byte. I find this very promising. Every seperately > compiled "unit" should fit into one continent, anyway ... > > As you might probably know, I am the maintainer of the New Stanford > Pascal compiler; if I ever reach the point where generating 64 bit code > gets interesting, I will think more about this option. At the moment, > even 31 bit would be very nice, because I am still bound to AMODE 24. > > Stanford Pascal website: http://bernd-oppolzer.de/job9.htm > on Facebook: https://www.facebook.com/StanfordPascal/ > on GitHub: https://github.com/StanfordPascal/Pascal > > Kind regards > > Bernd > All of this "continent" stuff basically makes me think of "far pointers" in the segmented (16 bit) Intel era. A far pointer was 32 bit field in which the upper 16 bits was loaded into the ES(?) segment register and the lower 16 bits into the ? register. The continent methodology is similar except that each "register" is 32 bits and both together are actually kept in a single 64 bit register. I am guessing that the continent portion would use the LFH to be loaded into the high word of the register, and just a plain L to load the "offset within continent" into the low word of that register. The "crossing continent" makes me wonder. If one could require that any single object reside in a single continent, then it might be possible to use the IARV64 interface to use a "guard" area to cause an exception if the code tries to overflow from one continent to another. -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
I've been reading this thread (for too long) and am compelled to ask folks to please stop arguing with Paul. Jim Mulder has rejected Paul's request, and the buck stops there as far as I'm concerned. "Asked and answered, Your Honor." Paul is entitled to his "want" and all are entitled to their opinion on it, of course, but the two sides are clearly not going to achieve a meeting of the minds, so unless folks want to talk about it ad nauseum, "Let It Go." He made his case, it was interesting to think about, and now it's done. With much appreciation, Alan Altmark (speaking for himself) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 19:22:22 +0200, Bernd Oppolzerwrote: >What I found most interesting in this whole thread was a suggestion >from (IIRC) a SAS guy some days before. He suggested, if I understood >it correctly, that a large application should run in AM64, but store >internally >only 32 bit pointers; the left half of all registers used as address >registers >containing the same (nonzero) value all the time ... as long as the >current >"continent" (defined by this nonzero value in the left half) is not exited. > >This could be a pattern for compiler writers, too, IMO, and has some >implications: Note that he achieved this by allocating 4 GiB above the 4 GiB bar, in order to get 2 GiB. While this technique certainly has its merits, it would be easier to write the compiler if IBM simply provided an IARV64 GETSTOR USE2GBTO4GB. Although that wouldn't guarantee a full 2 GiB like he was able to get with his technique. >As you might probably know, I am the maintainer of the New Stanford >Pascal compiler; if I ever reach the point where generating 64 bit code >gets interesting, I will think more about this option. If you're generating 64-bit code you may as well just use 64-bit pointers and produce a pure 64-bit application? BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
Reading to cure insomnia: There may be a real reason why Paul's wording of an RFE "perhaps" "might" "possibly" be a non-started? The requests had no suggestions for 32-bit programs. Non-U.S. based Paul just has issues with English. There were no suggestions for AMODE 32. Non-U.S. based Paul just has issues with English. There is no issue with non-AMODE 64 parameter lists. There is no issue with writing or rewriting code. The wild tangents dreamed up to claim why GETMAIN LOC=2GB.to.4GB-1 is an issue are dreamed up wild tangents. ELSQA memory fragmentation is a minor inconvenience for people using the requested feature only. IARV64 REQUEST=GETSTOR losing 2GB out of 16XB or JAVA area losing 2GB is sad but I'm not crying. But there is a real reason why GETMAIN LOC=32 may have an issue. Dr. Gene claimed that the reason that IBM dropped from AMODE 32 to AMODE 31 was because of a typo in the Principals of Operation for BXH/BXLE. Translated, even S360-24bit used algebraic 32 bit addresses for BXH/BXLE to allow negative displacements. Algebraic indexing from 2GB-1 to 2GB gives the higher address a negative number so it is lower than the low address. There should be logical BXH/BXLE equilavants but are not. Was IBM switching from AMODE 32 to AMODE 31 better than just adding logical equivalents for BXH/BXLE ? Of course, the data area is requested for AMODE 64 programs so using BXH/BXLE in AMODE 31 has no relavances to the GETMAIN change request. But I checked the manuals. See below. You can skip to the last note which is for the zArch for BXH/BXHG/BXLE/BXLEG to see the issue. I had to change the format for exponentiation because I post in plain text. Sorry. Copy/Paste from OCRed .pdf file could also introduce some errors. Sorry again. Of course, Paul will say that all is AMODE 64 with all 64 bits registers so both switching to AMODE 31 and using BXH/BXLE on the 2GB to 4GB-1 memory should cause the issue the programmer asked for. Using the proper AMODE 64 or the proper AMODE 64 instructions BXHG/BXLEG does not have the issue with 32 bit algebraic values. I can't fix the problem with Paul calling the using of addresses from zero to 4GB-1 a 32-bit system. It's AMODE 64, it works no difference than GETMAIN LOC=24 or GETMAIN LOC=31 when used by an AMODE 64 program. No difference than a 24 bit address being stored in an 8 byte register. Yes, the high order 5 bytes are zero but that is a given. Can't fix Paul. A22-6821-0 IBM System/360 Principles of Operation Really old and not dated Pages 64 and 65 Branch On Index High BXH RS The second operand is added to the first operand, and the sum is compared algebraically with the third op- erand. Subsequently, the sum is placed in the first operand location, regardless of whether the branch is taken. When the sum is high, the instruction address is replaced by the branch address. When the sum is low or equal, instruction sequencing proceeds with the updated instruction address. The first and the second operands are in the registers specified hy Rl and R3. The third operand register ad- dress is odd and is either one larger than R3 or equal to R3. The branch address is determined prior to the addition and comparison. Overflow caused by the addition is ignored and does not affect the comparison. Otherwise, the addition and comparison proceed as in fixed-point arithmetic. All 32 bits of the general registers participate in the opera- tions, and negative quantities are expressed in two's- complement notation. When the first and third oper- and locations coincide, the original register contents are used as third operand. Condition Code: The code remains unchanged. Program Interruptions: None. Programming Note The name "branch on index high" indicates that one of the major purposes of this instruction is the incre- menting and testing of an index value. The increment may be algebraic and of any magnitude. SA22-7832-10 z/Architecture Principles of Operation March 2015 Pages 7-39 and 7-40 BRANCH ON INDEX HIGH BXH R1,R3,D2(B2) [RS-a] BXHG R1,R3,D2(B2) [RSY-a] BRANCH ON INDEX LOW OR EQUAL BXLE R1,R3,D2(B2) [RS-a] BXLEG R1,R3,D2(B2) [RSY-a] An increment is added to the first operand, and the sum is compared with a compare value. The result of the comparison determines whether branching occurs. Subsequently, the sum is placed at the first- operand location. The second-operand address is used as a branch address. The R3 field designates registers containing the increment and the compare value. For BRANCH ON INDEX HIGH, when the sum is high, the instruction address in the current PSW is replaced by the branch address. When the sum is low or equal, normal instruction sequencing pro- ceeds with the updated instruction address. For BRANCH ON INDEX LOW OR EQUAL, when the sum is low or equal, the instruction address in the current PSW is replaced by the branch address. When the sum is high, normal instruct
Re: GETMAIN LOC=32
What I found most interesting in this whole thread was a suggestion from (IIRC) a SAS guy some days before. He suggested, if I understood it correctly, that a large application should run in AM64, but store internally only 32 bit pointers; the left half of all registers used as address registers containing the same (nonzero) value all the time ... as long as the current "continent" (defined by this nonzero value in the left half) is not exited. This could be a pattern for compiler writers, too, IMO, and has some implications: you need a separation of address registers and arithmetic registers internally; that is: the compiler has to know all the time which one out of the 16 general registers is used for what, and it has to do some housekeeping on this. And: passing control to another "continent" is somehow complicated. But imagine what you get for this: no need to change all the pointer fields from 4 byte to 8 byte. I find this very promising. Every seperately compiled "unit" should fit into one continent, anyway ... As you might probably know, I am the maintainer of the New Stanford Pascal compiler; if I ever reach the point where generating 64 bit code gets interesting, I will think more about this option. At the moment, even 31 bit would be very nice, because I am still bound to AMODE 24. Stanford Pascal website: http://bernd-oppolzer.de/job9.htm on Facebook: https://www.facebook.com/StanfordPascal/ on GitHub: https://github.com/StanfordPascal/Pascal Kind regards Bernd Am 11.05.2018 um 17:48 schrieb John McKown: On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll < wdrisc...@rocketsoftware.com> wrote: Paul, Unlike Hercules, z/Architecture is part of a business, and, as such, a business value needs to be made in order to get support for changes, in particular radical changes like AM32. "it would be nice" and "but it's so cool" aren't business rationalizations for the amount of potentially broken customer code that would result from the change you propose. In order to not have to recompile all applications, or maintain strict bounds between 32 bit apps and 64 bit apps like most other 64 bit architectures, I will gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64 bit address space. If your mythical AM32 was invented, applications would still have to switch back to AM31 before calling other AM31 code that expects a variable length paramter list. I still fail to see any business value to IBM's customers in what you are proposing. The real solution is to go back to the 1960s and tell the OS/360 developers to not use bit 0 as an "end of list" indicator. If OS/360 had used either an initial half(or full) word which indicated how many addresses were in the list following or, similar to CMS, had indicated the end-of-list with a fullword of high values (x0), then when the architecture was extended to "beyond 24 bit addresses", they could have use AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, the direct result of this "problem" in the design of OS/360. Of course, the OS/360 design made finding the end-of-list "easier" and did not "waste" a fullword of storage. I guess back in the day, that was a very big consideration. Wayne Driscoll Rocket Software Note - All opinions are strictly my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
I never ran a S/360-32bit system, but different users logged on to TSS in different modes. An IPL of the entire computer complex every time that every user logged on was probably not done. i.e. It was a bi-modal architecture. An LPSW or other instruction would have made more sense. I also believe, but have no experience, that memory from 2GB to 4GB-1 was avoided because there were no logical versions of BXH and BXLE and some programmers like to index. - - - old post - - - Subject: Re: GETMAIN LOC=32 From: Joe Monk <joemon...@gmail.com> Date: Fri, 11 May 2018 11:57:19 -0500 "How did that work? Did a high bit in BASR cause AM32 to be activated?" No ... the 360-67 had to be IPL'd in extended PSW mode to activate AM32. Otherwise it was a BC mode PSW machine... Joe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
"How did that work? Did a high bit in BASR cause AM32 to be activated?" No ... the 360-67 had to be IPL'd in extended PSW mode to activate AM32. Otherwise it was a BC mode PSW machine... Joe On Fri, May 11, 2018 at 5:32 AM, Paul Edwardswrote: > On Fri, 11 May 2018 00:59:14 -0700, Glen wrote: > > >As far as I know, IBM did produce a mainframe with 32 bit virtual > >addressing. > > > >There might not be many around, and I don't think Hercules has this > >mode, > > Hercules/380 has been updated to support AM32. > What I did was provide an option such that any > request to activate AM31 with BSM instead > activates AM32. That means that I have to choose > between AM31 and AM32 - I can't have both. And > all my AM31 applications also need to be AM32 > capable. > > >but the 360/67 has 32 bit virtual addressing, along with BAS and > >BASR to use it. > > How did that work? Did a high bit in BASR > cause AM32 to be activated? > > Thanks. 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
Re: GETMAIN LOC=32
On Fri, 11 May 2018 09:53:32 -0500, Paul Edwardswrote: >On Fri, 11 May 2018 23:28:16 +1000, Greg Price >wrote: > >>Yes, you CAN write programs which would work using the same logic in >>AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking >>NOBODY HAS. (Specific counterexamples do not invalidate the point - we >>are talking about the bulk of application software.) > >You don't see any value in writing AM-anything >code into the future? Eventually everything will >be AM64-clean and you will have a pure AM64 >environment. At which point ELSQA can be moved to under the 4 GiB bar instead of the 2 GiB bar? For all sites that have cleaned up their code to be AM-anything. Or is it just z/OS that needs to be AM64-clean? BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll < wdrisc...@rocketsoftware.com> wrote: > Paul, > Unlike Hercules, z/Architecture is part of a business, and, as such, a > business value needs to be made in order to get support for changes, in > particular radical changes like AM32. "it would be nice" and "but it's so > cool" aren't business rationalizations for the amount of potentially broken > customer code that would result from the change you propose. In order to > not have to recompile all applications, or maintain strict bounds between > 32 bit apps and 64 bit apps like most other 64 bit architectures, I will > gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64 > bit address space. If your mythical AM32 was invented, applications would > still have to switch back to AM31 before calling other AM31 code that > expects a variable length paramter list. I still fail to see any business > value to IBM's customers in what you are proposing. > The real solution is to go back to the 1960s and tell the OS/360 developers to not use bit 0 as an "end of list" indicator. If OS/360 had used either an initial half(or full) word which indicated how many addresses were in the list following or, similar to CMS, had indicated the end-of-list with a fullword of high values (x0), then when the architecture was extended to "beyond 24 bit addresses", they could have use AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, the direct result of this "problem" in the design of OS/360. Of course, the OS/360 design made finding the end-of-list "easier" and did not "waste" a fullword of storage. I guess back in the day, that was a very big consideration. > > Wayne Driscoll > Rocket Software > Note - All opinions are strictly my own. > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 23:28:16 +1000, Greg Pricewrote: >Yes, you CAN write programs which would work using the same logic in >AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking >NOBODY HAS. (Specific counterexamples do not invalidate the point - we >are talking about the bulk of application software.) You don't see any value in writing AM-anything code into the future? Eventually everything will be AM64-clean and you will have a pure AM64 environment. Pure AM-anything ideally, which means not using negative indexes in 64-bit programs and expecting 64-bit wrap/mask. >Further: Nobody wants to go back and change all their programs so that >they can work in all these AMODEs. 1. When updating programs for unrelated reasons, they could be made AM-anything at the same time. 2. Anyone using a high-level language just needs the compiler to be AM-anything. Next time they recompile they will pick up the change. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
Hi Wayne. Let's forget about AM32. There's no convenient way to add that. All the bits in BSM are taken already. I would like to be able to run a pure AM64 z/OS environment though. You mentioned that AM32 would need to switch to AM31 because of the variable length parameters. That is not the case if the AM31 subroutine is updated to remove the high bit with N x'7FFF' instead of ignoring the bit or trying to remove it with LA. That's fine. That's part of the conversion effort to produce a pure AM64 site that runs both 32-bit and 64-bit programs. Better than Windows which can also do the same thing, but has to stuff around internally because x64 can't run 32-bit programs in 64-bit mode, but z/Arch CAN!!! Maybe this can be a selling point of z/Arch. Pure 64 is possible. BFN. Paul. On Fri, 11 May 2018 14:10:59 +, Wayne Driscoll <wdrisc...@rocketsoftware.com> wrote: >Paul, >Unlike Hercules, z/Architecture is part of a business, and, as such, a >business value needs to be made in order to get support for changes, in >particular radical changes like AM32. "it would be nice" and "but it's so >cool" aren't business rationalizations for the amount of potentially broken >customer code that would result from the change you propose. In order to not >have to recompile all applications, or maintain strict bounds between 32 bit >apps and 64 bit apps like most other 64 bit architectures, I will gladly >sacrifice 2 GiB out of the massive virtual space offorded by a 64 bit address >space. If your mythical AM32 was invented, applications would still have to >switch back to AM31 before calling other AM31 code that expects a variable >length paramter list. I still fail to see any business value to IBM's >customers in what you are proposing. > >Wayne Driscoll >Rocket Software >Note - All opinions are strictly my own. > > > >-Original Messa-e- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Paul Edwards >Sent: Friday, May 11, 2018 6:23 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >On Fri, 11 May 2018 03:32:46 -0500, Paul Edwards <mutazi...@gmail.com> wrote: > >>ahat I did was provide an option such that any request to activate AM31 >>with BSM instead activates AM32. > >BTW, it would be good if z/Arch had a similar option. ie you can configure the >hardware so that any attempt to activate AM24 can be overridden to instead >activate AM31/32/64. >Similarly an override for any attempt to activate AM31, and a downgrade option >for >AM64 to activate AM24/31/32. > >That way you can set all the overrides to >AM64 and ensure that everything running >on your system is AM64-compliant, and >the system never leaves AM64. A z/OS >shop would become a pure AM64 >environment. > >Unlike Windowa and x64 hardware, 32-bit software can be run natively under >AM64. It doesn't need a special mode. Basically z/Arch hardware is superior to >x64 and this would be a great selling point I think - a pure 64-bit >environment, even when running 32-bit software. > >BFN. Paul. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ >Main Office Toll Free Number: +1 855.577.4323 >Contact Customer Support: >https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport >Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - >http://www.rocketsoftware.com/manage-your-email-preferences >Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy > > >This communication and any attachments may contain confidential information of >Rocket Software, Inc. All unauthorized use, disclosure or distribution is >prohibited. If you are not the intended recipient, please notify Rocket >Software immediately and destroy all copies of this communication. Thank you. > >-- >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
Re: GETMAIN LOC=32
Paul, Unlike Hercules, z/Architecture is part of a business, and, as such, a business value needs to be made in order to get support for changes, in particular radical changes like AM32. "it would be nice" and "but it's so cool" aren't business rationalizations for the amount of potentially broken customer code that would result from the change you propose. In order to not have to recompile all applications, or maintain strict bounds between 32 bit apps and 64 bit apps like most other 64 bit architectures, I will gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64 bit address space. If your mythical AM32 was invented, applications would still have to switch back to AM31 before calling other AM31 code that expects a variable length paramter list. I still fail to see any business value to IBM's customers in what you are proposing. Wayne Driscoll Rocket Software Note - All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Edwards Sent: Friday, May 11, 2018 6:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 On Fri, 11 May 2018 05:32:46 -0500, Paul Edwards <mutazi...@gmail.com> wrote: >What I did was provide an option such that any request to activate AM31 >with BSM instead activates AM32. BTW, it would be good if z/Arch had a similar option. ie you can configure the hardware so that any attempt to activate AM24 can be overridden to instead activate AM31/32/64. Similarly an override for any attempt to activate AM31, and a downgrade option for AM64 to activate AM24/31/32. That way you can set all the overrides to AM64 and ensure that everything running on your system is AM64-compliant, and the system never leaves AM64. A z/OS shop would become a pure AM64 environment. Unlike Windows and x64 hardware, 32-bit software can be run natively under AM64. It doesn't need a special mode. Basically z/Arch hardware is superior to x64 and this would be a great selling point I think - a pure 64-bit environment, even when running 32-bit software. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On 2018-05-11 9:41 PM, Tom Marchant wrote: On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote: SG24-7605-00 z/OS Version 1 Release 10 Implementation April 2009 Pages 6 and 104 Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private. That illustration in that Redbook is incorrect. I disagree!! I think that illustration is correct - and I think it shows the address space structure introduced by MVS/XA and which persists till now. Ok, before z the PSA was only 4K, and not 8K, but apart from that the diagram could be for MVS/XA, MVS/ESA or z/OS (BTB). BTW, I could not see anything relevant on page 6 (maybe I didn't look closely enough) but the diagram on page 104 is very plain to see! The "problem" under discussion is not extended common - it is ELSQA. That was why I was rabbiting on about private app storage starting low and going higher, and private system storage starting at the "top" and growing downwards. To move ELSQA gets back to the issue of why XA went with AM31 and not AM32 in the first place. Answer: to minimize problems while co-existing with pre-XA software. And so we come to the central dichotomy of this whole thread. Yes, you CAN write programs which would work using the same logic in AM24, AM31, AM32, AM64, and AM-anything-else, but generally speaking NOBODY HAS. (Specific counterexamples do not invalidate the point - we are talking about the bulk of application software.) Further: Nobody wants to go back and change all their programs so that they can work in all these AMODEs. But then you may say that no-one is asking them to. To the final kybosh, then: Nobody who is paying is prepared to risk any reduction in system and/or application availability just so that features they will never need or use can be added to the system and then debugged by APAR/PTF iterations in the service stream. This is on top of the old: the folks who could do it won't do it because there is no financial upside on offer. You got a "if only things had been different" software itch you want to scratch? Sure, explore it, look it over, discuss it, write your own software pertaining to it. But don't expect anyone to abandon what they are paid to do because you (or I) think they should be more intrigued with your (or my) "great computer idea". Disclaimer: Much of the above is my opinion and may not be "fact". But anyway, I do not think there is anything incorrect in the diagram in the redbook mentioned above. Cheers, Greg P. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 06:42:25 -0500, Tom Marchant wrote: >On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote: > >>next to E-Nuc is ESQA, ELPA, ECSA, then E-private. > >That illustration in that Redbook is incorrect. I was mistaken. However, ELSQA has always been at the top. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 00:59:14 -0700, Glen wrote: >the 360/67 has 32 bit virtual addressing, along with BAS and >BASR to use it. Yes, but not BSM or BASSM. IIRC changing AMODE required a privileged instruction. The Functional Characteristics manual is on Bitsavers. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
Stop poking the bear! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Thursday, May 10, 2018 4:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GETMAIN LOC=32 Somewhere along the way, you seem to have missed the point. Which is, the proposal is REJECTED, with prejudice. It has no more chance than a baby june bug in a 100-watt zapper (unless your org. provides >5% of IBM's revenue, and Ginny R. always answers your calls). Y'all feel free to continue down your primrose path, perhaps noting that no one is listening to you anymore. You've come up with a solution to a problem no one has. The best way to shorten this tiresome thread would be to stop extending it. Nevertheless, I'm confident P. Edwards will have to have the last word. Which is fine and dandy; but the sooner the better. sas On Thu, May 10, 2018 at 5:27 PM, somitcw < 01b1f179dc6e-dmarc-requ...@listserv.ua.edu> wrote: > ... > Please help shorten this thread by helping with the wording needed to > request an AMODE 64 enhancement for AMODE 64 programs that would > double the 4-byte addressable for data. > Moving extended common would be icing on the cake. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 00:29:40 -0500, somitcw wrote: >SG24-7605-00 >z/OS Version 1 Release 10 Implementation >April 2009 >Pages 6 and 104 >Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private. That illustration in that Redbook is incorrect. >When did they move? They didn't. >Are we requesting a feature that is already there? >IBM could do that real quick. > >Paul's wanting SVC 120 to get memory up to 4GB-1 and >have IARV64 and IARST64 stick with 33 to 64bit addresses >would actually need a couple of code changes and a little >documentation. You don't have a clue what would be required to compatibly dumb down AMODE 64 the way you want it. It is something that provides no benefit for z/OS users, despite all your protestations to the contrary. I agree with Steve, Charles, Jim and others. This is a waste of time. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 05:32:46 -0500, Paul Edwardswrote: >What I did was provide an option such that any >request to activate AM31 with BSM instead >activates AM32. BTW, it would be good if z/Arch had a similar option. ie you can configure the hardware so that any attempt to activate AM24 can be overridden to instead activate AM31/32/64. Similarly an override for any attempt to activate AM31, and a downgrade option for AM64 to activate AM24/31/32. That way you can set all the overrides to AM64 and ensure that everything running on your system is AM64-compliant, and the system never leaves AM64. A z/OS shop would become a pure AM64 environment. Unlike Windows and x64 hardware, 32-bit software can be run natively under AM64. It doesn't need a special mode. Basically z/Arch hardware is superior to x64 and this would be a great selling point I think - a pure 64-bit environment, even when running 32-bit software. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
On Fri, 11 May 2018 00:59:14 -0700, Glenwrote: >As far as I know, IBM did produce a mainframe with 32 bit virtual >addressing. > >There might not be many around, and I don't think Hercules has this >mode, Hercules/380 has been updated to support AM32. What I did was provide an option such that any request to activate AM31 with BSM instead activates AM32. That means that I have to choose between AM31 and AM32 - I can't have both. And all my AM31 applications also need to be AM32 capable. >but the 360/67 has 32 bit virtual addressing, along with BAS and >BASR to use it. How did that work? Did a high bit in BASR cause AM32 to be activated? Thanks. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
As far as I know, IBM did produce a mainframe with 32 bit virtual addressing. There might not be many around, and I don't think Hercules has this mode, but the 360/67 has 32 bit virtual addressing, along with BAS and BASR to use it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: GETMAIN LOC=32
Paul, are you continuing to bother us under a new pseudonym now? -- Peter Hunkeler Von: somitcw <01b1f179dc6e-dmarc-requ...@listserv.ua.edu> An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: GETMAIN LOC=32 Datum: 11.05.18, 07:29 SG24-7605-00 z/OS Version 1 Release 10 Implementation April 2009 Pages 6 and 104 Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private. When did they move? Are we requesting a feature that is already there? IBM could do that real quick. Paul's wanting SVC 120 to get memory up to 4GB-1 and have IARV64 and IARST64 stick with 33 to 64bit addresses would actually need a couple of code changes and a little documentation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
SG24-7605-00 z/OS Version 1 Release 10 Implementation April 2009 Pages 6 and 104 Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private. When did they move? Are we requesting a feature that is already there? IBM could do that real quick. Paul's wanting SVC 120 to get memory up to 4GB-1 and have IARV64 and IARST64 stick with 33 to 64bit addresses would actually need a couple of code changes and a little documentation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN LOC=32
Agreed. And I'll wager any readers of the Herc lists will not have been surprised at the way this thread progressed... Lee B. On 2018年5月11日 9:01:24 GMT+09:00, "Jackson, Rob" <rwjack...@firsttennessee.com> wrote: >Hear hear. I wholeheartedly agree. This started off bewildering; then >it became entertaining; now it's just irritating. I'm adding a filter >to dump "GETMAIN LOC=32" in deleted. This has turned from a flight of >fantasy into a waste of resources. > >First Tennessee Bank >Mainframe Technical Support > > >-Original Message- >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On >Behalf Of Steve Smith >Sent: Thursday, May 10, 2018 5:43 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: GETMAIN LOC=32 > >[External Email] > >Somewhere along the way, you seem to have missed the point. Which is, >the proposal is REJECTED, with prejudice. It has no more chance than a >baby june bug in a 100-watt zapper (unless your org. provides >5% of >IBM's revenue, and Ginny R. always answers your calls). > >Y'all feel free to continue down your primrose path, perhaps noting >that no one is listening to you anymore. You've come up with a >solution to a problem no one has. The best way to shorten this >tiresome thread would be to stop extending it. Nevertheless, I'm >confident P. Edwards will have to have the last word. Which is fine and >dandy; but the sooner the better. > >sas > >On Thu, May 10, 2018 at 5:27 PM, somitcw < >01b1f179dc6e-dmarc-requ...@listserv.ua.edu> wrote: > >> ... >> Please help shorten this thread by helping with the wording needed to > >> request an AMODE 64 enhancement for AMODE 64 programs that would >> double the 4-byte addressable for data. >> Moving extended common would be icing on the cake. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >FIRST TENNESSEE > >Confidentiality notice: >This e-mail message, including any attachments, may contain legally >privileged and/or confidential information. If you are not the intended >recipient(s), or the employee or agent responsible for delivery of this >message to the intended recipient(s), you are hereby notified that any >dissemination, distribution, or copying of this e-mail message is >strictly prohibited. If you have received this message in error, please >immediately notify the sender and delete this e-mail message from your >computer. > > >-- >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