X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fruntime;h=da16f189387ff062b86e09b7de1f0787c7db15f4;hb=a69c1bf3d3bb70a92aac9cca2edbf0f68c3f5bf3;hp=0bd5ebc83a685affc7ebc19c2b3149ba138f2e35;hpb=ab7465ea46961ce33b982d9bea33a7a462a78072;p=mono.git

diff --git a/web/runtime b/web/runtime
index 0bd5ebc83a6..da16f189387 100644
--- a/web/runtime
+++ b/web/runtime
@@ -16,14 +16,8 @@
 		  easy-to-port runtime engine.
 	</ul>
 
-	Currently both runtimes are missing garbage collection.  We
-	are planning on using the ORP GC engine and deploy it by
-	middle January.  
-
-* COM and XPCOM
-
-	We plan on adding support for XPCOM on Unix and COM on Microsoft
-	Windows later in our development process.
+	Currently we are using the Bohem conservative garbage
+	collector, but we working on incorporating the ORP GC engine. 
 
 ** Executing MSIL/CIL images
 
@@ -60,18 +54,38 @@
 	layout the code to support non-IA32 architectures.  Our work
 	will be focused on getting a IA32 version running first.  
 
-	The JIT engine should work on Linux and Win32, although you
+	The JIT engine works on Linux and Win32, although you
 	will need to install the CygWin32 development tools to get a
 	Unix-like compilation environment (mostly we use GNU make in 
 	a few of the makefiles).
 
-** JIT Engine (<b>updated, Dec 18th, 2001</b>)
+** JIT Engine (<b>updated, July 8th, 2002</b>)
 
 	The JIT engine uses a code-generator generator approach for
 	compilation.  Given the properties of CIL byte codes, we can
 	take full advantage of a real instruction selector for our
 	code generator. 
 
+	The JIT engine implements a number of optimizations:
+
+	<ul>
+		* Opcode cost estimates (our architecture allows
+	 	  us to generate different code paths depending
+		  on the target CPU dynamically).
+		  
+		* Inlining.
+
+		* Constant folding.  
+
+		  Although compilers typically do
+		  constant folding, the combination of inlining with
+		  constant folding gives some very good results.
+
+		* Linear scan register allocation.  In the past,
+		  register allocation was our achilles heel, but now 
+		  we have left this problem behind.
+	</ul>
+
 	There are a couple of books that deal with this technique: "A
 	Retargetable C Compiler" and "Advanced Compiler Design and
 	Implementation" are good references.  You can also get a
@@ -88,8 +102,22 @@
 
 	</ul>
 
+** Future plans
+
+	We are evaluating the future directions for the JIT engine:
+	both from our needs (optimizations like inlining, better register allocation,
+	instruction scheduling, and porting to other CPUs).
+
+	We have not yet decided how we will evolve the JIT engine.  We
+	might just upgrade our current architecture, and provide optimizations as
+	an extra layer.
+
 ** Garbage Collection
 
+	Currently we are using the Boehm conservative GC.  Although our plans 
+	are to move to the Intel ORP GC engine, our plans on a next generation
+	dual-JIT engine have to be taken into account.
+
 	We will be using the Intel ORP GC engine as it provides a precise
 	garbage collector engine, similar to what is available on the
 	.NET environment. 
@@ -151,3 +179,21 @@
 
 	Initially we used libffi, but it was fairly slow, so we have
 	reused parts of the JIT work to create efficient PInvoke trampolines. 
+
+** Remoting
+
+	Mono has support for remoting and proxy objects, just like
+	.NET does.  The runtime provides these facilities.
+
+** Porting
+
+	If you are interested in porting the Mono runtime to other
+	platforms, you might find the pre-compiled <a
+	href="archive/mono-tests.tar.gz">Mono regression test
+	suite</a> useful to debug your implementation.
+
+* COM and XPCOM
+
+	We plan on adding support for XPCOM on Unix and COM on Microsoft
+	Windows later in our development process.
+