[MLton-devel] cvs commit: mark compact GC and backend/codegen changes

[Stephen Weeks]

> I'll try to take a look sometime this week.  What's the status of the
> x86-codegen?  I.e., does everything that was done to the c-codegen need to
> be ported, or are there particular issues cropping up?

I did enough changes to make it type check, and started to look into
making it work, but decided that if you have the time you could do it
more quickly.  The main thing to look at is the folding of Runtime
transfer into CCall.  This should allow some code sharing, because
Runtimes eventually made a C call anyway.  The new stuff is that
Runtime calls can return results (e.g. GC_arrayAllocate,
GC_copyThread), and there is finer grained information about the C
functions, which may allow finer grained cache/flush assertions in the
codegen.  For example, the IntInf_do{Add,Mul,...} functions may modify
the frontier, but will not GC.  Or Thread_switch (not in yet, but
soon) modifies the stack top but not the frontier.

The other big change to the codegen is that a lot of implementation of
primitives got deleted, but those should just work once CCall does.
If you look at ccodegen.h, you'll see that there's not much left
there.

Actually, while looking, I was thinking that even more primitives
should be moved out of the x86 codegen.  In particular, IMO, any of
the Real.Math functions that are implemented in terms of other
primitives should be moved into the basis library implementation,
possibly with a conditional so they are only used when compiling
-native true.

> > + * 19 bits means that there are only 2^19 different different object layouts,
> > + * which appears to be plenty, since there were < 128 different types required
> > + * for a self-compile.
> > + */
> 
> The 128 different types is 128 different representations, not SSA types,
> correct?

Right.  There are probably a few thousand types.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Oh, it's good to be a geek.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel