From: John Haxby <j...@thehaxbys.co.uk> > The key thing to remember is that while the 64 bit kernel can run 32 bit > programs, the 32 bit kernel cannot run 64 bit programs.
Or more accurately ... 1) the Linux kernel: - x86-64 supports both Long Mode[1] (PAE52/flat48) and Protected386 (PAE36/flat32-virtual48) memory models - i686 supports only Protected386[1] (PAE36/flat32-virtual48) memory models And ... 2) libraries for one model cannot service calls from another, meaning: - Long Mode libraries can only service Long Mode Programs - 32-bit Legacy libraries can only service 32-bit Legacy Programs This #2 is the real kicker. "Upgrading" to x86-64 is a lesson in basic memory models. While some Long Mode OSes ship a largely 32-bit stack, so it is compatible with 32-bit programs out-of-the-box, they are not so compatible with Long Mode programs, forcing vendors of Long Mode programs to ship their own libraries. Even worse are some approaches to try to support one model on another, but in reality, it's incomplete, and "virtual machines" (e.g., for Windows, NTVDM, WoW, etc...) are still used that are limited to hardware support. Others are forcing the new mode to make calls into the old model for compatibility, because they ship the old model's libraries instead of new ones (with old). Linux has been the opposite. 64-bit Linux releases -- Alpha, PowerPC, SPARC and others prior to x86-64 (or IA-64 for that matter) -- have shipped a full and complete 64-bit stack, and then and only then included some 32-bit compatibility. Red Hat and SuSE attacked this with the multilib approach -- shipping an increasing number of 32-bit libraries for 32-bit support. However, there are still lines to be drawn at some point, especially in today's common Linux/x86-64 Long Mode implementations v. Windows x64 Long Mode. A lot of details that people don't note. For example, the biggest issue with increased memory usage of Linux/x86-64 isn't the increased size in registers. In fact, many are not increases at all. The problem is loading 32-bit (virtual48) libraries alongside Long Mode ones, for a mix of programs. In the Windows world, where things are still heavily 32-bit (the legacy of Win32, if they didn't have some dragging Win16/Win32s stuff), Windows still ships a lot of 32-bit, solving the problem one way. Of course, start loading native 64-bit (flat48) and things get messy quickly -- better in NT6 (Vista, 2008, 7) than NT5.1 (XP, 2003), but still messy, especially the more, native Long Mode programs run. That's why many native Long Mode Windows programs used to run slower on Windows x64 for a long time -- the Long Mode programs were making calls into flat32-virtual48 space, instead of native flat48. It's also why the 32-bit versions ran faster on Windows x64 as well. ;) In Linux, the more native Long Mode programs one can load, the more efficient a Linux/x86-64 system is. The memory imprint can actually be little more than old 32-bit, Segmented i686 -- especially when looking at the actual platform level/usage, not the programmer assumption (of flat32 v. flat64, which is really -- at the platform level -- virtual48 v. flat48, respectively). Since most everything for Linux/x86-64 is available in native, Long Mode implementations, this is especially efficient -- not only the server, but the desktop as well. Increasingly even 3rd party plug-ins for browsers and other office utilities -- often tied with legacy implementations for Windows (e.g., which has been well behind on native, flat48 Long Mode implementations of libraries, objects and "clean" code), which has held Linux ports from being released for native Long Mode. This has been the issue more than anything else. Upgrading from Linux/x86 to Linux/x86-64 is more about the approach, the latter focusing on true, native, flat 48-bit Long Mode implementations of libraries and programs, than just shipping a Long Mode kernel and then mainly 32-bit libraries and programs, which has been the history of Windows (especially back for NT5.1, NT6.x improves some things). [1] SIDE NOTE: Only Protected386 supports Virtual86 (DOS/DPMI), whereas Long Mode does not (for those relying on DOSEmu or other emulation, let alone a huge sloth of legacy Windows programs where they didn't use the true, full Win32 API, and not some Win16/Win32s). I wouldn't mention this except it comes up all-the-time, without people stopping to understand why (especially when things fail under Windows for the same, hardware reasons, as Linux). _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
