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

[skaller]

On Thu, 2007-07-26 at 14:53 +0200, Wesley Terpstra wrote:
> On Jul 26, 2007, at 1:17 PM, Nicolas Bertolotti wrote:
> > I’m interested in getting a Win64 version of MLton. Now the 64 bits
> > port for Linux (and also other targets as I could read some messages
> > about it on the mailing list) is getting stable, I guess it should
> > not be too complex to update the MinGW port of MLton for Win64.
> > 
> > 
> In contrast to skaller, I think this is the way forward. MinGW is a
> very thin wrapper that provides most of what a UNIX-ish app like MLton
> needs. As you can still link to and FFI to MS compiled code, there's
> little downside.

Why does Mlton need any "Unix-ish" code? It's a language translator,
the bulk of the compiler should be entirely platform independent.

The run time libraries may need to abstract various facilities
needed by both the core run time system and standard libraries
like Basis, and, additional support for specific OS may also
be needed when platform specific development is required.

However in these cases the system native libraries are 
always both mandatory and superior, and the system compiler
is always the best way to bind to these resources.

If you start going with weak emulations like MinGW you will pay 
the price in the long run. 

For example, Windows now uses assemblies, and building
them is a mandatory part of the toolchain. Dynamic linking
using a DLL in the PATH is not acceptable. It isn't supported
on my XP64 box by default -- don't waste your time making a
binary that requires MS C library (MSCRT80.DLL) because that
will never work on my system. You have to ship the C library
WITH your product.

Is MinGW going to support that? Multi-arch binaries?

Windows has more advanced dynamic linker support than
Unix, and you simply HAVE to use it or get left behind
in the old world -- a bad idea for a product that doesn't
build yet on Windows, to target something known to be out
of date already .. and then delay the port because the 
already obsolete tool required to build it isn't even
available yet.

So when you say about 'FFI' to Windows native code you're
missing the point. It isn't just the FFI source code
but the whole product integration technique that you need
to use. You need to understand the ONLY function calls that
you can make directly to unshipped code are to the Windows.h
supplied Kernel.DLL and other OS intrinsics.  Calls to C
library functions REQUIRE shipping the C library as part
of the product assembly. The C library is a 'third party
library'. It isn't part of Windows. And it can NOT be
shipped separately, it has to be shipped with EVERY
executable or DLL that requires it.

This impacts users generated code as well as the compiler
itself .. users can't just ship a MLton generated *.exe
file. They must ship a full assembly including the C library
the *.exe file has to link against.

My compiler product Felix builds on Unixen, OSX, Win32,
and Win64, Cygwin, and Cygwin/nocygwin (aka Mingw) including 
the compiler (easy because it is written
in Ocaml) and all the support libraries -- *including* full
support for high performance asynchronous socket I/O.

There's no reason to bother with MinGW here .. we actually
dropped it as a direct target. We do provide the platform:

	nocygwin

which is a built under Cygwin using --nocygwin flag to gcc
driver, which invoke the MinGW gcc. However cygwin and
nocygwin have to be considered obsolete targets. The primary
target is, and will always be, the native Windows system.

If I can get all this working for Felix, you can do it for
Mlton too :)

BTW: But, I haven't figured out how to make assemblies
work yet .. do tell me if you find out! ;(

BTW2: It may seems silly to generate CLR bytecode from MLton
but it isn't!

Mlton, like Felix, is a whole program analyser. It can provide
significance performance gains for ANY target including .NET VM,
due to high level optimisations.

SO whilst Mlton likes to mess about with very high performance
low level optimisations .. the bulk of the performance gains
don't come from a fast runtime, they come from significant
high level optimisations non-whole program analysers simply
cannot do.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net