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
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.
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
--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_MIN, even though the C89 standard specifies them. Instead, MSVC provides the idiosyncractic
_I64_MINmacros. MSVC also doesn't provide a
strtollfunction, for converting an ASCII string into a
long long int. It does have
strtol, but since
longis 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
set_pointerVTABLEs, 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.
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
PLATFORMSfile, 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.