>> If high-level language compilers start following >> the 32-bit addressing rules, they will naturally >> start supporting 4 GiB with no additional >> effort by the programmer.
> If high level language compilers (and run-time environments) start > following 64-bit addressing rules, they will naturally start supporting > 16 EB, with no additional effort by the programmer. > What's your point? That assumes that you are happy to have the extra baggage of 64-bit programming, with 64-bit addresses stored in memory instead of 32-bit addresses. Ideally *both* 32-bit and 64-bit programs can be generated by a compiler, and you use the 32-bit version if you don't need more than 4 GiB of memory. >> That's a good idea, and we could get a compiler >> to generate such code, but it prevents the >> 32-bit application from being moved to cheaper >> 32-bit hardware in the future, as a possibility. > OMFG! Is that what this is all about? Moving > to 32-bit hardware? 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. >>No, what you are calling a 24-bit application is >>actually a 32-bit application that runs on a >>reduced addressing mode of 24. > You are making up your own terminology, > using words similar to > those of existing terminology. I already asked you what terminology you preferred to refer to programs that used 32-bit registers, but you didn't provide any. >>I want my programs to run on S/370 hardware > S/370? really? System/370 doesn't even support 31-bit. It doesn't need to. That's the whole point. 32-bit load modules should be constructed in a manner that still works on S/370. That means creating ANY/ANY load modules. > You are asking to break lots of application > code as well as system code so that you can > run on a poorly implemented extension of > MVS 3.8 on a PC under Hercules. Why don't > you fix your implementation of MVS/380 instead? 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. >>But you are happy to constrain >>32-bit applications to 2 GiB when all you may >>need is a LOC=32 parameter and you can go >>all the way up to 4 GiB. > No, you also have to run AMODE(64), which means that there are many > system services that you cannot use without switching to AMODE 31. That is true, of z/OS, currently. There are two solutions to this problem: 1. Add 20 lines of code to each system service so that they switch to AM31 themselves instead of requiring the program to do it itself. 2. Construct the 32-bit program so that whenever it is about to execute a system service like READ, it switches down to AM31 itself. I have implemented number 2 in my universal 32-bit modules, which means it can also run on MVS/XA, where it needs to "step down" to 24-bit before executing READ. My modules check the current AMODE and RMODE at startup to see what "step down" paradigm is required. > Maybe you believe that if you keep repeating > the phrase "32-bit applications", it will be > accepted that there is such a thing on > z/Architecture. There is not. The term "32-bit application" exists wherever there are 32-bit registers. It is not specific to z/Arch, it is ubiquitous. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
