[MLton-user] A few questions

[Wesley W. Terpstra]

On Dec 12, 2007, at 10:00 AM, David Hansel wrote:
> I downloaded the environment that Wesley had put together.  It  
> _almost_
> works, but for any non-trivial part of our sources I get a link error
> about the missing symbol "__imp___difftime64".  I guess it's the same
> problem as what Wesley mentioned in his post about the "date"  
> regression
> failing.  Any suggestions on how to work around that?

You can modify the file runtime/basis/System/Date.c where there is
> /* The idea for Date_localOffset comes from KitV3 src/Runtime/Time.c  
> */
> C_Double_t Date_localOffset(void) {
>   time_t t1, t2;
>
>   t1 = time(NULL);
>   t2 = mktime(gmtime(&t1));
>   return difftime(t2, t1);
> }
If you make the last line
	return 1.0*(t2-t1);
... you might get it to work. However, until I am back home, I only  
have a powerpc, and can't check this for you.

If you want to try this, get a copy of the svn mlton, apply my patch,  
change into the runtime directory and "make TARGET=x86_64-pc-mingw32"  
to build the runtime. Copy the resulting libmlton.a into /mingw/lib/ 
mlton/x86_64-pc-mingw/.

Just to be clear: there seem to be a number of bugs in the mingw/win64  
port. Don't trust this toolchain for anything important! Eventually,  
someone needs to get in contact with the author, Kai Tietz, who seems  
single-handedly responsible for the win64 port. I imagine he just  
doesn't know / hasn't gotten to these issues. It would be better to  
fix them (like the UINTPTR_MAX problem!) than to work around them.

> Anyways,  this is a very encouraging first step and I would like to
> help in getting MLton to work on Win64.  I can mostly offer testing
> (i.e. compiling and running our sources) but given time I might be  
> able
> to find/fix one or the other problem myself.

IMO, the best way to improve the MLton/win64 port is to help Kai Tietz  
wrinkle out bugs in the mingw win64 port. To improve the mlton windows  
port in general, there are many stubs in runtime/platform/mingw.c that  
could be filled out with work-alike methods on windows. In particular,  
I think alarm and get/settimer are easy high-impact targets. The  
Windows structure from the basis library is also missing.

Adding the ms_abi calling convention to the amd64 codegen would be a  
big improvement, but probably needs to be done by Matthew when he has  
time (and access to a win64 machine?).