I've been trying to follow this thread, but I'm not seeing the "what's the problem we're trying to solve?" part. (I think I saw the question, but didn't see the answer.)
It's known that, on bi-modal processors with 64-bit kernels, 32-bit applications run faster. (And here I count AM31 as "32-bit".) The difference might be more significant on z than on X86 or ARM or POWER, or maybe z is simply better instrumented. What I don't get is: what's missing from the current tool chain? I can build 32-bit ... er, uh 31-bit ... applications on 64-bit z/Linux RIGHT NOW. Where it matters, they run faster than their 64-bit counterparts. Like Martin said: On 05/22/2018 07:31 AM, Martin Schwidefsky wrote: > A 64-bit kernel recognizes the format of the binary and starts it > in the appropriate mode. Native for ELF64 or compat for ELF32. > The addressing mode is AMODE-64 for native 64-bit programs and > AMOED-31 for compat 31-bit code. If your program needs to change modes mid-flight, you're welcome to SAM31 or SAM64. What might be missing is a Public Service Announcement, "hey! 32-bit's good!". On 05/24/2018 11:40 PM, Paul Edwards wrote: > I don’t think utilities like > “sed” should be required to be 64-bit when they > don’t go anywhere near exceeding the 4 GiB > barrier. I quite agree. Problem is that most people are just not interested. Most people just don't care (that we're wasting bytes and maybe a few cycles). When building, they don't bother to mark 'sed' (or anything) as "make this one 32-bit". It would be extra effort. Or maybe they don't know it's possible. Stand-alone executables can run in either mode without impact on things which depend on them (other than that they run faster in 32-bit mode). Anyone want a 32-bit statically linked 'sed'? I've got one. Oh ... yeah ... that reminds me ... shared linkage. If you want to run 32-bit apps /and you don't link them statically/ then you have to ship 32-bit runtime support. Bummer. It's worse. There is a /conscious/ movement in the greater Linux world (probably other op sys too) to discard old and unloved technology. For distributors, it means less cats to herd. The kernel gave up support for 80386 (won't build for processor, will still run apps compiled for it). The kernel people have less code to maintain. Other software vendors can't put "old" in the rear view quite so easily. -- R; <>< ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] 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/
