[MichaelGG]

Why can't the CLR come up with their own "X32" target? IIRC, they made the default for projects in VS to be 32-bit explicitly because of better codegen and lower overhead. If an app is OK with 4GB of RAM, why not let the process run in 64-bit mode, but use 32-bit pointers?

Also, why should the Win64 ABI constrain everything? Certainly it'd only be needed around the edges, but for .NET code calling other .NET code, you're free to do interesting things. (Like pass a GUID or tuple in a single register if it'd help.)

[henryb]

Keep in mind that Windows emphasizes a unified ABI on AMD64 largely because of what happened on x86. The x86 ABI sort of evolved into this "wild west" kind of situation, with various calling conventions for different languages/runtimes and usage scenarios (i.e. stdcall, cdecl, fastcall, pascal, etc.), which ends up making things unnecessarily complicated for the OS. (Kevin has an old blog post where he discusses this in more depth: http://blogs.msdn.com/b/freik/archive/2006/03/06/x64-calling...)

Being a good OS citizen and sticking to the Win64 ABI also makes some things significantly simpler for the rest of the runtime. An obvious example of where this pays off is native interop (e.g. P/Invoke, COM interop, C++/CLI), but one less obvious example of where this comes into play is actually managed exception handling (which is built on top of the underlying Structured Exception Handling mechanism that Windows provides). Not only does adhering to the unified ABI allow managed exceptions to interop with native exceptions, but it also makes things simpler for debuggers, anything that needs to walk the stack, etc.

Remember, the CLR is really more of an execution engine, and not so much a "virtual machine". We try not to disrupt the architectural conventions of the underlying platform, since we're not trying replace the OS environment itself.

--Henry Baba-Weiss [MSFT]