The current approach is to keep the JITer as simple as possible, and thus as
fast as possible. The generated code quality will suffer from that.
-Register allocation is first done inside the trees of the forest, and each
-tree can use the full set of registers. We simply split a tree if we get out of
-registers, for example the following tree:
-
-
- add(R0)
- / \
- / \
- a(R0) add(R1)
- / \
- / \
- b(R1) add(R2)
- / \
- / \
- c(R2) b(R3)
-
-can be transformed to:
-
-
- stloc(t1) add(R0)
- | / \
- | / \
- add(R0) a(R0) add(R1)
- / \ / \
- / \ / \
- c(R0) b(R1) b(R1) t1(R2)
-
-
-Please notice that the split trees use less registers than the original
-tree.
-
-Triggering JIT compilation:
-===========================
-
-The current approach is to call functions indirectly. The address to call is
-stored in the MonoMethod structure. For each method we create a trampoline
-function. When called, this function does the JIT compilation and replaces the
-trampoline with the compiled method address.
-
-We should consider using the CACAO approach, they do not use a trampoline at
-all.
-
Register Allocation:
====================
in EAX on x86. The current implementation works without such system, due to
special forest generation.
-X86 Register Allocation:
-========================
-
-We can use 8bit or 16bit registers on the x86. If we use that feature we have
-more registers to allocate, which maybe prevents some register spills. We
-currently ignore that ability and always allocate 32 bit registers, because I
-think we would gain very little from that optimisation and it would complicate
-the code.
-
Different Register Sets:
========================
be be a bit inefficient.
The more performant solution is to allocate two 32bit registers for each 64bit
-value. We add a new non terminal to the monoburg grammar called long_reg. The
+value. We add a new non terminal to the monoburg grammar called "lreg". The
register allocation routines takes care of this non terminal and allocates two
32 bit registers for them.
-
Forest generation:
==================
STLOC.0 (5) [1,0]
STLOC.1 () [1,5]
-The current forest generation generates:
+A simple forest generation generates:
STLOC.0(LDC.1)
STLOC.1(LDLOC.0)
This is what lcc is doing, if I understood 12.8, page 342, 343?
-Value Types:
-============
-
-The only CLI instructions which can handle value types are loads and stores,
-either to local variable, to the stack or to array elements. Value types with a
-size smaller than sizeof(int) are handled like any other basic type. For other
-value types we load the base address and emit block copies to store them.
-
Possible Optimisations:
=======================
The "else" is only to keep original semantics (exception handling).
+We need loop detection logic in order to implement this (dominator tree).
+
+AFAIK CACAO also implements this.
\ No newline at end of file