[MLton] Windows port of MLton using the Microsoft tools (e.g. without MinGW)

[Matthew Fluet]

> I've personally tried to evaluate the amount of work that would be needed by
> doing the following :
>
> -          port the GNU MP library in order to build it using the Microsoft
> C compiler

MLton uses only a fraction of the GNU MP library, and uses it out of 
convenience and performance, not necessity.  That is, implementing IntInf

> o        convert the MLton runtime C code to C89 (it is written in C99 which
> leads to a number of minor issues)

How extensive are these changes?  I'm wary of falling back to C89, since I 
imagine that one still needs to make use of many extensions.  For example, 
AFAIK, C89 didn't provide the uint<n>_t and int<n>_t fixed-width integer 
types, which makes specifying the C representations for the ML types 
Word<N>.word and Int<N>.int slightly more difficult.

> o        take into account the fact that the CRT functions which are
> equivalent to some LIBC functions are prefixed with an '_'

Is this an issue in C code or an issue in assembly code?  On *-darwin and 
x86-mingw, we need to add a leading underscore to symbols in the assembly 
files, so there is compiler hook for ensuring that leading undrescores 
are added -- but that would be to all symbols, not just some functions.

> o        include the code for some MinGW specific extensions in the MLton
> runtime (opendir/readdir/closedir/rint etc .)

Here, I would be worried about the licensing issues of borrowing 
significant portions of MinGW code.  It's not a blocking issue for this 
investigation, and we could certainly look at more native Win32 functions 
that accomplish the same thing; also, look at the way SML/NJ handles this 
functionality, since they don't use MinGW or Cygwin, and also have a 
compatible license.

> o        the generated C code may define some empty arrays which are not
> accepted by the Microsoft compiler

Those can probably be eliminated by the C codegen.

> -          write a perl script that converts the assembly code MLton
> generates in order to build it using the Microsoft assembler

What changes were needed here?

> Unfortunately, the binaries I get by doing this always crash at the
> beginning of the execution.

Hard to say what might be wrong without more information.

> As I'm not really an expert in using the Microsoft assembler, I tried to
> simplify this a bit by skipping the assembly code conversion script and
> using the GNU assembler anyway (but still compile the runtime and link using
> the Microsoft tools).

You could also try starting with just the C codegen.  That tends to be a 
little more portable and easier to debug.

> This time, I could get some binaries (even some big ones) that run pretty
> fine.

Very, very nice!

Nicolas, you might prepare a patch of the changes you needed to make and 
post it to:
   http://www.mlton.org/TemporaryUpload
That would let us take a look at what has been done.