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: >> 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
