[MLton-devel] heap profiling

Matthew Fluet Matthew Fluet <fluet@CS.Cornell.EDU>
Thu, 12 Sep 2002 08:52:54 -0400 (EDT)

> So, it all seems pretty reasonable to me.  I have a pretty good feel
> for the difficulty of everything except for adding the 64 bit support
> to the native codegen.  Matthew, could you comment on that?  If that's
> too hard, we could going with a C call per allocation.  Maybe the
> performance hit will be acceptable.

64 bit integer operations shouldn't be much of a problem.  The only major
hangups that I recall thinking about are interfacing to C, because
returning a 64bit integer comes back in %eax and %edx, and things are set
up right now for only expecting returns in %eax.  There is also a slight
impedance mismatch between Machine IL and x86 with the types.  I suspect
that the right thing to do is to add Int64 and UInt64 to the Machine IL
types, because the C-codegen will want to use 64 bit values as atomic.
But, the x86 codegen will need to split each 64bit operand from Machine IL
into the low and high words in order to manipuate each individually.
Likewise, the translation of Machine operands is set up to return exactly
one x86 operand.  Not that any of these issues are show stoppers, just a
little engineering around them.  

> * At what compiler pass to insert the increments
>   - At the time Matthew proposed adding code to the x86-codegen.
>     However, since then the C codegen has continued to survive, and we
>     have seen the simplification that comes from moving stuff out of
>     the codegens into the backend.  So, I propose to put it in the
>     backend.

Agreed.  The backend is a much better place to put it.  I'd suggest adding
a new Machine.Operand variant Current which the codegens expand to the
current instruction address.  I know how to expand that in assembly, but
not in C; but I'm sure there is a way.

This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
MLton-devel mailing list