[MLton] Win64 patches again

Wesley W. Terpstra wesley at terpstra.ca
Sun Feb 3 16:20:23 PST 2008


Here are the patches I submitted earlier, broken down into parts.

For Matthew (or anyone else who hacks on the amd64 codegen), here is  
the link to the calling convention used by windows:
http://msdn2.microsoft.com/en-us/library/7kcdt6fy.aspx

address-space.patch:

On AMD64, not all 64 bits are actually accessible to userspace  
applications. The CPU itself has a limit well below this, and win64  
imposes further a limit of 43 bits. This would be academic except that  
MLton carefully tries to position its heap by trying to map at 32  
locations linearly across the address space. Since all of the  
attempted address are larger than the maximum possible in 43 bits,  
this fails. On linux the failure is not so important because mmap(0)  
succeeds. However, this code has a purpose: to prevent fragmentation.  
In the distant future, this might matter again.

The attached patch fixes this by introducing POINTER_BITS and  
ADDRESS_BITS (which is less than POINTER_BITS). POINTER_BITS is the  
number of bits in a pointer, and ADDRESS_BITS is how many of those are  
actually useful as an address. Also, checking the value of UINTPTR_MAX  
with UINT64_MAX is a preprocessor friendly and portable way to  
configure POINTER_BITS (the old code used a non-portable __WORDSIZE).

cross-compiler-option-changed.patch:

I earlier had people add the '-b' flag as gcc needed it for cross  
compiling. Newer gcc no longer accepts this option. Instead, the  
platform prefixs the gcc executable. This patch corrects this. If the  
old behaviour is needed for old gcc, a simple shell wrapper works.

Also, when cross compiling, not only gcc, but also ar and ranlib need  
the executable prefix. The runtime/Makefile also presumed CC=gcc at  
one point.

pid-not-int.patch:

The old windows bindings for spawn assumed that it returns an int.  
However, it is actually returning a pid. This causes problems for  
win64, but was wrong for win32 as well.

mingw-updates.patch:

My previous email explained why the memory management routines for  
MinGW were broken; see it for an explanation of how this caused the  
out-of-memory bugs and random crashes when a fixed heap location is  
used.

Some MinGW builds have a symbol gettimeofday, this patch moves our  
implementation out of the way and continues to use it rather than the  
symbol exported in an extended mingw library. Ours works for our needs.

I re-implemented getrusage. As this now works, gc-summary also works  
and was enabled.

A couple points in this file assumed sizeof(long) >= sizeof(void*).  
These were corrected.

I added more platforms to the uname code now that MinGW supports them.

Several headers in MinGW have been changed since the code was last  
touched. I adjusted timespec and the signals to deal with the least  
common denominator.

I also modified the display maps method to work with 64 bit pointers.

----------------------

Please note: these new patches won't bootstrap mlton with the old  
toolchain I posted. I've managed to get several fixes into the  
upstream mingw-win64 so I don't include work-arounds for them any  
more. I'm working on getting a better toolchain together which doesn't  
ICE. I'll post a link once I have this working.

-------------- next part --------------
Skipped content of type multipart/mixed


More information about the MLton mailing list