Parrot on Win64

For the past few weeks I've been idly trying to get Parrot building and running on 64-bit Windows. With the release quickly approaching and Christoph laying down a feature freeze, I've been doubling my efforts to get something working on this system. Astute observers will notice that there have been smolder reports coming from "MSWin32" on "amd64" processors, but this is an illusion. Parrot does indeed build and run on a 64-bit Windows platform, if you compile it into a 32-bit binary with a 32-bit compiler. However, this isn't exactly the same thing as having a 64-bit bird. So all the previous smolder reports we have from "Win64" or "Windows - amd64" are reports of 32-bit birds on those platforms. After a lot of effort I've managed to finally upload an actual smolder report of a 64-bit bird on Win64, and it's not pretty.

64-Bit Compiler

The first big problem with Win64 is that there aren't too many compilers there. MinGW, a port of GCC to Windows (and the compiler that ships with Strawberry Perl), doesn't have a 64-bit version on Windows available yet. At least, not a stable one. Consequently Strawberry Perl doesn't have a 64-bit distribution. I don't know if ActiveState offers a 64-bit Perl, but that still wouldn't have a compiler associated with it.

Microsoft offers it's 64-bit compiler for free on that platform, but it's hard to find any free alternatives to that. However, Microsoft doesn't offer a 64-bit version of visual studio yet (that I am aware of), so we're doing this all on the command line with the Microsoft C compiler cl.

Compiling with 64-bit cl.exe

I've found this incantation seems to get us through the compilation process and allows us to run the test suite without too much hackery:

perl Configure.pl --ccflags="-GS- -MD" --intval="long long" --opcode="long long"

At least, this incantation should work after r40176.

Win64 Problems

I mentioned earlier that one of the problems on Win64 is finding a compiler. There are some that cost $$$, but I'm poor and refuse to buy a compiler for this work. If somebody has access to a proprietary one that might perform better I would love to hear about it. However, the compiler isn't the only problem.

For backwards compatibility, the Microsoft C compiler on Win64 treats "int" and "long" values as being both 32-bit quantities. If you want access to a 64-bit integer type, you need to use "long long". While it shouldn't, Parrot currently expects the size of INTVAL to be the same as the size of a pointer. It's bad practice, but that's the way things are right now. So, that's why you see the bits --intval="long long" and --opcode="long long" in the Configure.pl command line up there: To make sure these things are both 64-bit quantities.

[Update 22 July 2009: particle pointed me to this article, which explains the 64-bit landscape better then I do. For reference, Win64 with MSVC is "LLP64", while GCC on it's various supported platforms (including, I hope, MinGW when a 64-bit port of that is finally released) is LP64 instead.]

Another problem is a major lack of important definitions of things that support 64-bit programming. For instance, MSVC doesn't seem to define the values LLONG_MAX and LLONG_MIN, even though the C89 standard specifies them. Instead, MSVC provides the idiosyncractic _I64_MAX and _I64_MIN macros. MSVC also doesn't provide a strtoll function, for converting an ASCII string into a long long int. It does have strtol, but since long is only 32 bit, this function only returns a 32-bit quantity. This is a huge problem inside IMCC, which uses strtol, because suddenly a 64-bit Parrot on a 64-bit platform can't handle 64-bit integer constants in PIR code. Bummer.

Parrot Has a Problem

Microsoft isn't the only guilty party in this situation, one major problem in this process is actualy Parrot's fault: Parrot assumes throughout the codebase that INTVALs and pointers are the same size, and it casts data from one to the other without considering possible truncation. It's not hugely prevalent, but it does happen in several systems and in ways that are not going to be easy to resolve. One place where it happens very frequently is in the get_pointer and set_pointer VTABLEs, which we can resolve by preventing these two from ever being used in a way that pointer values are accessible to PIR code.

A lot of code cleanup is going to have to happen in Parrot, some of it painful, in order to get Parrot properly building on more of these "exotic" systems like Win64. Luckily this is a problem that can be broken down into small chunks, and might be a perfect job for new Parrot hackers to play with. However, this problem will definitely not be resolved by the release tomorrow, and may not be resolved for several releases to come.

Conclusion

So that's the state of Parrot on Win64. The release tomorrow is going to be shipping with the very first Win64 entry in the PLATFORMS file, although a quick glance at it will show that it's not nearly the success story that other platforms are. 64-bit Ubuntu is an example of a platform that has great support, although that's because of the large number of Parrot developers that use it. Like other amd64 platforms, Win64 doesn't have JIT either, so that's not a mark against it. I would like to see support for Parrot on Win64 improved, but I'm not hopeful that it's going to happen any time soon.