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://listserv.ua.edu/cgi-bin/wa?A2=ind1805&L=IBM-MAIN&P=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