While Allen takes a break from blogging to salvage what he can from a dying hard disk (repeated platform installs and uninstalls are brutal on hard disk actuators), I can elbow my way back into the network pool here in the Microsoft hardware dev labs to show the fruits of todays labors:
The source code of the form is shown in the IDE editor window behind the running app. The button click event prints out the size of IntPtr and an object reference (Self, the form instance). Pointer types such as these change size between 32 bit and 64 bit platforms; numeric integers do not change size with the platform.
Exhibit Native Code
Notice the use of 64 bit offsets and extended 64 bit registers such as “rax” and “rsp”. This example doesn’t use a lot of local variables or intermediate results, so the generated code doesn’t make use of the additional R8 through R15 registers. Also, accessing the additonal 8 registers requires use of an instruction prefix byte, so you don’t want codegen to use them indiscriminately.
Incidentally, not all .NET development tools can do what you’ve just seen. Unmanaged code, and to a lesser extent unsafe managed code, cannot move seamlessly between 32 bit and 64 bit hardware. Only 100% managed typesafe code can execute smoothly on 32 bit .NET 1.1, 32 bit .NET 2.0 (Whidbey), and 64 bit .NET 2.0 (Whidbey). I’m glad we stuck to our guns and put in the extra effort to implement all the corners of the Delphi language using typesafe managed IL code. These experiments show the first rewards of that extra work a year or more ago.
The careful observer will notice that there is no mention of VCL for .NET in those test results. We need to massage the P/Invoke DLLImport declarations VCL for .NET uses to bind to the Win64 API, just as Microsoft has had to do with WinForms. I haven’t found any indications that VCL for .NET cannot support 64 bit execution.
I might experiment with register pressure tomorrow while Allen liposuctions his MBR with a hex editor