Ugh, I can't believe I'm responding but there are a couple of items that need to be set straight. Not that Aiden will understand them or accept them, but at least other readers should know how it really works.
AidenShaw said:
Or, one could read your docs and take them to mean that the EFER.LME is the mode bit.
I never said that the "mode bit" was automatic - the process mode bit is a marker for the scheduler to "do the right thing". It takes a few instructions for the scheduler to "honor" the process mode bit.
Grasping at straws now aren't you? Anything to try to claim you're still right. The fact is that switching the mode of the processor works nothing like you described it, if you'd have read the AMD documents then you would understand this.
You described it as a "per-process mode bit" and this is wrong. The processor can either run in Legacy mode or Long mode, it cannot have various different processes/threads running, some in Legacy mode and others in Long mode. When the processor is in a given mode, everything on the processor must be running in that mode. In order to switch modes everything in the current mode - page tables, global descriptor tables (GDT), local descriptor tables (LDT), interrupt descriptor tables (IDT), exception handlers, code descriptors, data-segment descriptors, etc. - must be stopped, their context saved and then the data structures for the new mode must be loaded. In other words, everything the processor requires to run must be saved for the current mode then loaded for the new mode. It's similar to turning the processor off, switching the mode, and then turning it back on.
This is really only useful for an application such as VMware that virtualizes a separate operating environment where performance is expected to be slower than native and data-sharing/communication between the two modes is not required. It's not at all feasible for an environment such as Tiger's 64-bit support that requires 100%-native performance and extensive data-sharing/communication. If it were feasible then you can be sure that Apple would implement it for the version of Tiger that will be running on the new Mac Pros - it's not and they won't.
AidenShaw said:
And it's something that Windows x64 does constantly as you run a mix of 32-bit applications, 64-bit application, and the 64-bit OS. No one has noticed any performance problems due to the "complex and resource intensive" switch.
Wrong again. Windows x64 does not do this at all, if you would read the AMD documentation then you would understand this. Windows x64 (and other 64-bit OSs that support x86-64) run completely in Long mode (64-bit mode). Long mode supports two types of operation 1) Compatibility and 2) 64-bit. Compatibility operation is where it runs unmodified, legacy 32-bit (and 16-bit) applications. 64-bit operation is where it runs new 64-bit applications that utilize the larger 64-bit address space and the additional 64-bit registers.
Because Long mode supports both 32-bit and 64-bit applications there is no need for the slow and complex mode switches between Long mode and Legacy mode.
AidenShaw said:
My main point, however, is that it *is* possible for a 32-bit operating system to run 64-bit tasks.
And your main point is still fundamentally flawed and wrong. Basically your argument is analogous to someone claiming that PPC Macs can natively run Windows applications and then pointing to VirtualPC as the proof. Never mind that VirtualPC emulates instructions and VMware can run many instructions natively, this is basically what your argument is. It doesn't matter to you that the only way for a 32-bit OS to run the processor in 64-bit mode is through a virtual machine running a 64-bit operating system with less than native performance. But your mind is already made up and nothing I nor anyone else will say will change it. Hopefully others that read this thread will now understand the real issues involved.
AidenShaw said:
The corollary to that point is that Microsoft already had a 64-bit version of Windows, no there was no need for a hybrid 32/64 bit effort - although it would have been possible, it was unnecessary.
If it were possible then you can bet that Microsoft would have done it. Microsoft is obsessed with backwards compatibility and if they could have created a 32-bit/64-bit hybrid OS such as Tiger (only with complete 64-bit libraries) that doesn't require any driver rewrites or yet another Windows code-base then they surely would have done it. As it is now they have yet another version of Windows (Windows x64) that they have to support and that requires completely new drivers for everything.
As AMD states repeatedly in their documentation, Long mode requires a 64-bit operating system. So you can either believe Aiden and his weak VMware virtual machine argument (which still requires a 64-bit OS) or you can believe AMD. I'll let the readers decide.
That's it for me on this thread, I'm out.