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

diff --git a/web/runtime b/web/runtime
index 8a08cc86163..da16f189387 100644
--- a/web/runtime
+++ b/web/runtime
@@ -1,28 +1,23 @@
 * The Mono runtime
 
-	The Mono runtime will implement the JIT engine (and a byte
-	code interpreter for quickly porting to new systems), the
-	class loader, the garbage collector, threading system and
-	metadata access libraries.
+	The Mono runtime implements a JIT engine for the CIL virtual
+	machine (as well as a byte code interpreter, this is to
+	quickly port it to new systems), the class loader, the garbage
+	collector, threading system and metadata access libraries.
 
 	We currently have two runtimes:
 
 	<ul>
+		* <b>mono:</b> The Just In Time compiler implemented
+	 	  using a BURS instruction selector.  We only support
+		  x86 machines in the JIT engine at this point.
+	
 		* <b>mint:</b> The Mono interpreter.  This is an
 		  easy-to-port runtime engine.
-
-		* <b>mono:</b> The Just In Time compiler implemented
-	 	  using a BURS instruction selector
 	</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
 
@@ -59,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
@@ -87,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. 
@@ -150,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.
+