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 <[email protected]> wrote: > On Thu, 2 Feb 2023 16:38:38 +0000, Peter Relson <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
