[MLton] MLton on MinGW/win64: regression ok(ish)!

[Wesley W. Terpstra]

After hearing another person complain about no 64bit on windows, I  
decided to install Windows 2003 and port it!

So far things have gone relatively smoothly. I am uploading a complete  
win32+win64 gcc+mlton toolchain to
	http://terpstra.ca/mlton-win64.tar.bz2
(It's 158,862,125 bytes, which takes about 4 hours for me to upload,  
so it's not there yet. Downloading it should be fast.)
You'll also need msys for bash or the mlton.bat to run the compiler.

This toolchain is 32-bit hosted which means you should be able to run  
it on Windows XP/win32 (although I have not tried this). To compile 32- 
bit apps, just run mlton as normal. To compile 64-bit apps, use "mlton  
-target x86_64-pc-mingw32 -codegen c".

I've not tried to setup a native toolchain, because the native gcc  
ICEs all over the place. I've not seen a 64bit MLton compiled program  
die yet. Be warned: there is no gdb for win64!

The patch I've attached should not break win32 (I've tested it); in  
fact, it fixes a few bugs. The patch might affect amd64/linux  
(untested).

After patching, MLton compiles cleanly and more-or-less passes the  
regression suite. The exn-history regression also applies to win32, so  
I am ignoring it. The date compilation regression is a due to difftime  
being undefined in the mingw/win64 libraries. The smith-normal-form  
regression comes from gcc ICEing. The size diffs seem reasonable. I  
have not investigated the floating point bugs.

I tried to add an 'ms_abi' toggle in the amd64 codegen, but couldn't  
figure out where to add instructions for pushing/popping the "shadow  
space" (32 bytes) as required. I'd appreciate some help here,  
Matthew. :-) At the moment I only have it working with the C codegen.  
I'm hoping that using gcc only as an assembler will make the floating  
point and ICE regressions go away.

While working on this patch, I've found and fixed the problems  
reported by Tom Murphy for Vista under win32.

First, MLton uses MEM_DECOMMIT to "free" the heap when it is shrunk.  
This leaves the memory reserved which causes later VirtualAlloc to not  
have enough address space. I've added remap for Windows which can  
recommit the reserved space, mitigating this problem. I don't believe  
it's possible to partially free a mapping beyond decommit, so that's  
the best we can do. Without my patch, you can work around this problem  
using a fixed-heap. Before an application could run out of address  
space with under 512MB. Now I'm pretty confident you should be safe up  
to 1GB on win32.

The second problem, that temp file creation fails, was due to the  
filename buffer being too large for the windows dll (!). Fixed.

I also found the cause of the long-standing VirtualAlloc bug which  
broke cygwin/mingw and we worked around by using base=0. See the  
comment above the method call. The gist of the problem was that we  
used MEM_COMMIT without MEM_RESERVE.

If you want to recompile GMP, you'll need the patch from my prior  
email. I'm going on vacation for a couple of weeks, so I won't be  
updating/working on the port in this time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mlton-mingw64.patch
Type: application/octet-stream
Size: 40756 bytes
Desc: not available
Url : http://mlton.org/pipermail/mlton/attachments/20071210/22ef6c6a/mlton-mingw64-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: regression.64
Type: application/octet-stream
Size: 14006 bytes
Desc: not available
Url : http://mlton.org/pipermail/mlton/attachments/20071210/22ef6c6a/regression-0001.obj