[MLton-devel] cvs commit: C codegen cleanup

[Matthew Fluet]

>   Starting moving the implementation of Runtime.GCField from the
>   codegens to the backend.  It works with the C codegen, but the native
>   codegen needs to be fixed to handle the new kinds of operands (offsets
>   of GCState).  For now, the backend switches on which codegen is being
>   used and generates the appropriate operand.  Once the native codegen
>   is updated, we should eliminate the switches and the
>   Machine.Operand.Runtime variant.

I notice that you have defined:

#define GCState ((Pointer)&gcState)
#define ExnStack *(Word*)(GCState + ExnStackOffset)
#define Frontier *(Word*)(GCState + FrontierOffset)
#define StackBottom *(Word*)(GCState + StackBottomOffset)
#define StackTop *(Word*)(GCState + StackTopOffset)

and have removed:

#define FlushFrontier()
#define FlushStackTop()
#define CacheFrontier()
#define CacheStackTop()

Has this had a noticable impact on runtime performance?

I ask, because without a number of hacks (which would essentially expose
the Machine.Operand.Runtime variant), the native codegen won't be able to
determine which operands correspond to the stackTop and which correspond
to the frontier.  Currently, the x86-codegen works hard to keep those
values in registers.  Naively accessing them through memory in the gcState
struct will likely cause a performance impact.  I may be able to set
things up so that the codegen decides how to register allocate those
values the same way it does with pseudo-regs, and hopefully that will
recover some performance.



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel