On Thu, 2 Feb 2023 16:58:32 -0600, Joe Monk <joemon...@gmail.com> 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 <mutazi...@gmail.com> wrote: > >> 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 >> > >---------------------------------------------------------------------- >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
