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.



_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Nicolas Bertolotti-2]

Hello,

I am trying to setup a MLton cross compiler for Win64 using the patches you provided (actually using the SVN trunk since it appears that you have submitted them).

The C codegen works pretty well so thanks for the patches. Now, I would like to go further and use the native codegen.

Did you get any feed back about the question you asked?

> 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.

I am unfortunately unable to answer it ... and hope someone can.

Nicolas


_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Matthew Fluet-3]

On Mon, 16 Jun 2008, Nicolas Bertolotti wrote:
>> 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.
>
> I am unfortunately unable to answer it ... and hope someone can.

<src>/mlton/codegen/amd64-codegen/amd64-generate-transfers.fun:1348 has
code to round the C-stack to a 16byte alignment.  You could probably
follow that code by something like:

val (setup_args, size_stack_args) =
   if convention = CFunction.Convention.MSx64
      then (AppendList.append
            (setup_args,
             AppendList.single
             (Assembly.instruction_binal
              {oper = Instruction.SUB,
               dst = c_stackP,
               src = Operand.immediate_int 32,
               size = pointerSize})),
            size_stack_args + 32)
   else (setup_args, size_stack_args)

You might also need to adjust the fixCStack instructions
(<src>/mlton/codegen/amd64-codegen/amd64-generate-transfers.fun:1554) if
the MSx64 ABI requires the caller to pop the C stack.

The portion of Wesley's patch that adjusts the argument registers
depending on the ABI wasn't committed, so you would need to add that as
well.


_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton