[MLton] MinGW done

Matthew Fluet fluet@cs.cornell.edu
Mon, 12 Jun 2006 14:52:50 -0400 (EDT)


>> I made a few minor changes to the commits that switch over to stdio and 
>> that change MLton.world.save.
>
> I would've used C_Errno_t(Bool_t) myself, but was too afraid to include 
> c-types.h in gc.h. :-)

It shouldn't be a problem.  The only reason it wasn't before was that much 
of the gc code was refactored before the Basis Library.

> Incidentally, it seems to me that many of the primitive function calls 
> are/will be broken when the next step for 64bit comes. The basis has been 
> nicely abstracted, but the primitives use hard-coded prototypes in the 
> compiler for Word32.

Correct.  There is significant work to be done to abstract the native 
pointer size in the compiler proper.

> I don't really understand why these aren't handled the same way as the 
> FFI.

Simply because they are part of the compiler that hasn't yet been modified 
to work with 64-bit systems.

> I understand that some primitives are not transformed to a function 
> call, but for those that are, shouldn't we be using autogenerated type 
> information?

We'll probably use something like that.  But, a lot of the primitives are 
under our control, so where we don't need the representations to change 
between platforms, its better to leave them the same.

> Also, am I correct that once the runtime in x86_64 is stabilized, it will be 
> merged back to HEAD? Then a new branch proceeds to address the memory layout 
> code in the compiler, followed by merge, then branch for c-codegen, merge, 
> x86-codegen, merge?

I think it makes sense to merge the refactored runtime and Basis Library 
into HEAD in the near future.  For the next step, I don't think that there 
is much to be accomplished by merging without having a working c-codegen; 
it seems to me that the changes to the C-codegen itself will be fairly 
minor and that we won't really be able to test the other changes without a 
64-bit codegen around.  Certainly, though, changing the x86-codgen to an 
x86_64-codegen will probably deserve its own branch.