Paul Edwards wrote: >I don't want to use -m64 because that uses the >64-bit registers for everything, but I wish to produce >compact modules using only 32-bit registers and >pointers.
OK, so let's dig into this a bit. Have you taken one or more of your programs and compared -m31 and -m64 variants? How much more compact is the -m31 variant? Have you got any indication(s) of what impact(s) that difference yields, such as a performance impact? Quantifying the potential benefit is important. By the way, Java and Java run-times are agnostic to such issues. In IBM's 64-bit JVMs, including those for z/OS and for Linux on Z/LinuxONE, there's an interesting "halfway house" feature called "compressed references." This feature is automatically enabled when the Java heap size is configured below a certain amount which varies depending on platform and JVM release level but is never less than 25 GiB minus 16 bytes. "Compressed references" means that Java object references are stored in 32-bit representation, so the object size is the same as a 32-bit object. I'll let IBM explain more: "As the 64-bit objects with compressed references are smaller than default 64-bit objects, they occupy a smaller memory footprint in the Java heap. This results in improved data locality, memory utilization, and performance. You might consider using compressed references if your application uses a lot of native memory and you want the VM to run in a small footprint." In that particular set of use cases that IBM describes, evidently there's enough of a benefit with compressed references in Java. Otherwise, presumably IBM wouldn't have implemented the feature. You could do something similar in C programs, I imagine. You'd still compile -m64, but you'd embed "bracketed" AMODE31 code (with 2 GiB addressing) as/where it makes performance/compactness sense, if it makes sense. At least, that's my broad understanding of how it'd work. Moreover, conceivably an optimizing compiler could do this for you, perhaps with some "hinting," analogous to how IBM's JVM and JIT handles this optimization with its compressed references. That brings up an interesting point about running compactness tests. It'd be best to run a couple tests using the latest releases of the optimizing compilers, and to direct them to do as much optimization as they know how. I know of four C/C++ compilers for Linux on Z/LinuxONE: * GNU (gcc family) * Clang/LLVM * IBM XL C/C++ * Dignus If you can run tests with them all across at least a couple of your programs, fantastic. There's a trial edition of IBM's compiler here: https://www.ibm.com/developerworks/downloads/r/xlcpluslinuxonz/index.html Dignus has a Web-based trial which might be enough for these purposes. Details here: http://www.dignus.com/products.shtml Does anyone happen to know if expanded storage and/or data spaces would be relevant and useful here? Finally, I don't think there's a strong argument for *disk* storage compactness of program modules, within reason. Apple seems to have no trouble now distributing only 64-bit mobile apps, even if they might be slightly larger stored on the (relatively tiny) flash media in their 64-bit iPhones, iPads, and iPod touches. Memory and especially processor resource efficiency could be interesting if it's significant, but maybe this is an optimizing compiler job rather than a kernel one? -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
