[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.