documentation updates

svn path=/trunk/mono/; revision=3126

1 files changed, 4 insertions, 61 deletions

diff --git a/docs/jit-thoughts b/docs/jit-thoughts
index 90cf4785523..cb50d0ecd05 100644
--- a/docs/jit-thoughts
+++ b/docs/jit-thoughts
@@ -11,48 +11,6 @@ We are designing a JIT compiler, so we have to consider two things:
 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:
 ====================
 
@@ -61,15 +19,6 @@ allocation. For example this is needed by call, which return the value always
 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:
 ========================
 
@@ -86,11 +35,10 @@ call class methods for ALU operations like add or sub. Sure, this method will
 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:
 ==================
 
@@ -157,14 +105,6 @@ STLOC(ADD (LDLOC, LDLOC))
 
 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:
 =======================
 
@@ -180,3 +120,6 @@ else for (i = 0; i < N; i++) { check_range (a, i); a [i] = X; }
 
 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