*** empty log message ***

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

1 files changed, 43 insertions, 0 deletions

diff --git a/docs/jit-thoughts b/docs/jit-thoughts
new file mode 100644
index 00000000000..4d70b189bcd
--- /dev/null
+++ b/docs/jit-thoughts
@@ -0,0 +1,43 @@
+Just some thoughts for the JITer:
+
+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.
+
+
+Forest generation:
+==================
+
+Monoburg can't handle DAGs, instead we need real trees as input for
+the code generator. So we have two problems:
+
+1.) DUP instruction: This one is obvious - we need to store the value
+into a temporary variable to solve the problem.
+
+2.) function calls: Chapter 12.8, page 343 of "A retargetable C compiler"
+explains that: "because listing a call node will give it a hidden reference
+from the code list". I don't understand that (can someone explain that?), but
+there is another reason to save return values to temporaries: Consider the
+following code:
+
+x = f(y) + g(z); // all functions return integers
+
+We could generate such a tree for this expression: STLOC(ADD(CALL,CALL))
+
+The problem is that both calls returns the value in the same register,
+so it is non trivial to generate code for that tree. We must copy one
+register into another one, which make register allocation more complex.
+The easier solution is store the result of function calls to
+temporaries. This leads to the following forest:
+
+STLOC(CALL)
+STLOC(CALL)
+STLOC(ADD (LDLOC, LDLOC))
+
+This is what lcc is doing, if I understood 12.8, page 342, 343?
+