Documentation

Knot-tying combinator for FCode

Knot-tying combinator that throws result away

Takes code and compiles it in a completely fresh environment, except that compilation info and statics are passed in unchanged. The current environment is passed on completely unaltered, except that the Cmm code from the fork is incorporated.

forkStatics $fc$ compiles $fc$ in an environment whose statics come from the current bindings, but which is otherwise freshly initialised. The Cmm returned is attached to the current state, but the bindings and usage information is otherwise unchanged.

forkAlts $bs~d$ takes fcodes $bs$ for the branches of a case, and an an fcode for the default case $d$, and compiles each in the current environment. The current environment is passed on unmodified, except that: * the worst stack high-water mark is incorporated * the virtual Hp is moved on to the worst virtual Hp for the branches

forkEval takes two blocks of code.

• The first meddles with the environment to set it up as expected by the alternatives of a case which does an eval (or gc-possible primop). * The second block is the code for the alternatives. (plus info for semi-tagging purposes)

forkEval picks up the virtual stack pointer and returns a suitable EndOfBlockInfo for the caller to use, together with whatever value is returned by the second block.

It uses initEnvForAlternatives to initialise the environment, and stateIncUsageAlt to incorporate usage; the latter ignores the heap usage.

forkProc takes a code and compiles it in the current environment, returning the basic blocks thus constructed. The current environment is passed on completely unchanged. It is pretty similar to getBlocks, except that the latter does affect the environment.

EndOfBlockInfo tells what to do at the end of this block of code or, if the expression is a case, what to do at the end of each alternative.

Stack usage information during code generation.

INVARIANT: The environment contains no Stable references to stack slots below (lower offset) frameSp It can contain volatile references to this area though.

Heap usage information during code generation.

virtHp keeps track of the next location to allocate an object at. realHp keeps track of what the Hp STG register actually points to. The reason these aren't always the same is that we want to be able to move the realHp in one go when allocating numerous objects to save having to bump it each time. virtHp we do bump each time but it doesn't create corresponding inefficient machine code.

Initial stack usage

Initial heap usage

Return the heap usage high water mark

Sequel is a representation of the next continuation to jump to after the current function.

Any addressing modes inside Sequel must be ``robust,'' in the sense that it must survive stack pointer adjustments at the end of the block.

State only passed *downwards* by the monad

State passed around and modified during code generation