On Tue, 8 May 2018 07:24:55 -0500, Tom Marchant <m42tom-ibmm...@yahoo.com> wrote:
>On Tue, 8 May 2018 05:47:03 -0500, Paul Edwards wrote: > >>extra baggage of 64-bit programming, with >>64-bit addresses stored in memory instead >>of 32-bit addresses. > >This is 2018. Conserving memory isn't nearly as important as it was in 1970. >Storing 64-bit addresses isn't a big deal. It potentially defeats the cache. We should have the option of producing both 32-bit and 64-bit applications. >>It's about making 32-bit programs the best >>they can be in theory. That means producing >>a *single load module* that works as AM24 >>on MVS 3.8j, works as AM31 on MVS/XA and >>above, and works as AM64 on z/OS. > >>32-bit load modules should be constructed >>in a manner that still works on S/370. > >>This has nothing to do with MVS/380. It has >>to do with making beautiful 32-bit load >>modules that work anywhere. I already have >>that, but when my load modules run on z/OS >>they can only get 2 GiB of memory and I >>would like to be able to bump that up to >>4 GiB. > >You are contradicting yourself. You say that your programs should be >constructed in such a way that they work on System/370, yet you >need to be able to allocate 3 GB of contiguous storage. There is no contradiction. If I have a 32-bit program that is trimodal, I expect that if I have an application that e.g. reads a whole file into memory in one chunk, that the file size can be 16 MiB on S/370, 2 GiB on MVS/XA, and 4 GiB on z/OS. Since there appear to be technical reasons preventing a 4 GiB file on z/OS, I will have to run on MVS/380 instead if I want to edit a file that is greater than 2 GiB. However, if I have a *different* application that doesn't doing a single allocate, then I would hope that I can get 4 GiB even from z/OS, just not in a single chunk. >You are not being truthful when you say that this has nothing to do >with MVS/380. It doesn't have anything to do with MVS/380. I am trying to get 32-bit load modules to work as best as possible on all IBM systems, MVS 3.8j, MVS/XA, OS/390, z/OS. Yes, I also intend to run on MVS/380, but that is irrelevant. I am interested in "rerunning history" and coming up with S/370 "best programming practices" that people *could* have written their code to, and then fast-forward to z/OS and we have the best 32-bit load modules possible. "best programming practices" mean that you don't use the high bit of a 32-bit address as a flag etc. Basically if around the time that MVS/XA was introduced, it would have been good if IBM could have predicted that one day we will have 4 GiB of memory, so we can start preparing for that day by having programmers code LOC=32 if their program is 32-bit clean. All 32-bit programs could have an attribute saying "AMODE-infinity" in the spot that is now called "AMODE 64". And we only write AMODE infinity programs, both 32-bit and 64-bit flavors. No extra flag is needed when we start having 128-bit registers or 256-bit registers. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
