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

diff --git a/web/runtime b/web/runtime
index 97f2e4eb8e6..da16f189387 100644
--- a/web/runtime
+++ b/web/runtime
@@ -1,13 +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.
 
-	Currently the runtime has an image loader and metadata access
-	entry points.  The runtime comes with a simple interpreter
-	that can execute very simple programs. 
+	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.
+	</ul>
+
+	Currently we are using the Bohem conservative garbage
+	collector, but we working on incorporating the ORP GC engine. 
 
 ** Executing MSIL/CIL images
 
@@ -16,7 +26,7 @@
 	Linux.
 
 	Our roadmap looks like this, this has been updated as of
-	<b>Jul 15, 2001</b>:
+	<b>Dec 18, 2001</b>:
 
 	<ul>
 
@@ -30,12 +40,12 @@
 
 		* Milestone 3: <b>Done</b>Define an <i>lburg</i>-like
 		  instruction selector for the JITer for Intel.
-		  Although slower at JITing than a streaming JITer, it
-		  generates better code.  The same grammar can later
-		  be used for the stream jitter.
 
-		* Milestone 4: Implement JITer.  This is where our
-		  current efforts are focused on, the JITer is 60% ready.
+		* Milestone 4: <b>Done</b> Implement JITer.  This is where our
+		  current efforts are focused on, the JITer currently runs
+		  all of the code we have tested on it.  The major limitation
+		  is that our class libraries are not complete, and hence not
+		  every application can be ran.
 
 		* Milestone 5: Port of the JITer to non IA32 systems.
 	</ul>
@@ -44,17 +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.
+	Unix-like compilation environment (mostly we use GNU make in 
+	a few of the makefiles).
 
-** JIT Engine (<b>updated, Nov 16th, 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
@@ -71,20 +102,25 @@
 
 	</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
 
-	We have decided to implement a generational tracing garbage
-	collector, which is very similar to the one being used by
-	.NET.  For an introduction to the garbage collection system
-	used by Microsoft's CLR implementation, you can read this book
-	on <a
-	href="http://www.amazon.com/exec/obidos/ASIN/0471941484/o/qid=992556433/sr=2-1/ref=aps_sr_b_1_1/103-5866388-0492603">Garbage
-	Collection.</a>
+	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.
 
-	Another consideration is to use the same interface that ORP
-	uses to its Garbage Collection system and reuse that GC system
-	instead of rolling our own, as the ORP system is pretty advanced
-	and is independent of the rest of ORP.
+	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. 
 
 	Although using a conservative garbage collector like Bohem's
 	would work, all the type information is available at runtime,
@@ -111,9 +147,11 @@
 ** IO and threading
 
 	The ECMA runtime and the .NET runtime assume an IO model and a
-	threading model that is very similar to the Win32 API.  Dick
-	Porter has been working on the Mono abstraction layer that allows
-	our runtime to execute code that depend on this behaviour.
+	threading model that is very similar to the Win32 API.  
+
+	Dick Porter has been working on the Mono abstraction layer
+	that allows our runtime to execute code that depend on this
+	behaviour.
 
 ** Useful links
 
@@ -139,7 +177,23 @@
 	PInvoke is the mechanism we are using to wrap Unix API calls
 	as well as talking to system libraries.
 
-	We hvae implemented PInvoke through libffi, but we are likely
-	going to roll our own system as the runtime matures, specially
-	as the interpreter is approaching completion, and we move into
-	the JITer.
+	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.
+