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

[Matthew Fluet]

> I don't know what to say about GNU MP. It seems that what I did works, at
> least for MLton so it was fine for me. Note that the GNU MP provides some
> functions written in assembly code which I had to deactivate (and fall back
> to the generic C version that is also provided).

Well, that's good to hear, and it seems that Peter Tanski is interested in 
your work.

>> 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.
>
> It is an issue in C code. The MinGW libraries provide some aliases and this
> is why we don't face the same issue with MinGW.

Ok.  I suppose that even if they aren't part of a public API, they aren't 
going anywhere.

>>> -          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.
>
> The syntax is really different :
> - In the Microsoft assembler which uses the Intel syntax, there is no suffix
> in the opcodes which gives indication about the size of the operands. It is
> different in GAS which uses the AT&T syntax.
> - You have to swap the left and right operands
> etc ...
> Anyway, it remains assembly code and it should be an isomorphic
> transformation.
>
> As I mentioned, I'm not an expert and I could not find a way to build an
> object file that does not lead to a crash. It is the part for which I would
> appreciate someone helps me.

One thing that immediately come to mind, with regards to the assembly: 
when a MLton compiled program starts, it begins in 'C' and makes a C call 
to the function MLton_jumpToSML (see include/{x86,amd64}-main.h).  That 
function is emitted by the native codegens (as assembly code), and takes 
care of setting up registers as expected by the native codegen and then 
does a direct jump to SML code, leaving the C stack suspended until the 
SML code makes an FFI call.

The MLton_jumpToSML code assumes the 'cdecl' calling convention, which is 
how a unix-ish C program would call a C function.  However, I seem to 
recall that on Windows, the default calling convention is 'stdcall', so 
that little bit of assembly in MLton_jumpToSML may be making the wrong 
assumptions about the incoming calling convention.

Similarly, unless you have otherwise patched 
mlton/elaborate/elaborate-core.fun, MLton assumes that all FFI functions 
are called via the 'cdecl' calling convention (unless they are 
specifically annoted by 'stdcall' and the target platform is Cygwin or 
MinGW).  However, since all the runtime functions are built using the 
MS toolchain, they may be assuming a 'stdcall' convention.  The native 
codegen knows how to implement the stdcall calling convention, but the FFI 
functions may simply be defaulting to cdecl.