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 +0000, Seymour J Metz <sme...@gmu.edu> 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 +0000, Peter Relson <rel...@us.ibm.com> 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&data=05%7C01%7Csmetz3%40gmu.edu%7C718bd144b06548bf3cbf08db057306d4%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638109763809086697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0BKWo5q0IsRuj5Iw%2FrtDtH1oMEoGvQ1Ys5BYz8bM4XU%3D&reserved=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-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
