* 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.

	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. 

** Executing MSIL/CIL images

	The code will load an executable and map the references to
	external assemblies to our own version of the assemblies on
	GNU/Linux.

	Our roadmap looks like this, this has been updated as of
	<b>Jul 15, 2001</b>:

	<ul>

		* Milestone 1: <b> Done</b> Fully read and parse all CIL byte-codes
		  and metadata tokens (ie, a disassembler).  

		* Milestone 2: Complete an interpreter for CIL byte
		  codes.  This interpreter can be used temporarly to
		  run CIL byte code on a system where no JIT is
		  available.

		* Milestone 3: 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.

		* Milestone 5: Port of the JITer to non IA32 systems.
	</ul>

	A setup similar to the Kaffe JIT engine can be used to
	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
	will need to install the CygWin32 development tools to get a
	Unix-like compilation environment.

** JIT Engine (<b>updated, Jul 14th, 2001</b>)

	We will be using a code-generator generator approach for our
        JITer.  Given the properties of CIL byte codes, we can take
        full advantage of a real instruction selector for our code
        generator. 

	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
        technical description of <a
        href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</a>

	Previously we had looked at a number of JIT engines and tools,
        but they would not take full advantage of the CIL properties: 

	<ul>
		* <a
		  href="http://www.intel.com/research/mrl/orp/">ORP</a>

		* <a
		  href="http://www.gnu.org/software/lightning/">GNU
        	  Lightning</a>

		* <a href="http://www.eecs.harvard.edu/~nr/toolkit/">NJ Machine
	 	  Toolkit</a>.).

		* VCODE.
	</ul>

** 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>

	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.

	Although using a conservative garbage collector like Bohem's
	would work, all the type information is available at runtime,
	so we can actually implement a better collector than a
	conservative collector.

	<ul>
		* Garbage collection list and FAQ:<br>
		  <a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>

		* "GC points in a Threaded Environment":<br>
		  <a href="http://research.sun.com/techrep/1998/abstract-70.html">
		  http://research.sun.com/techrep/1998/abstract-70.html</a>

		* "A Generational Mostly-concurrent Garbage Collector":
		  <a href="http://research.sun.com/techrep/2000/abstract-88.html">
		  http://research.sun.com/techrep/2000/abstract-88.html</a>

		* Details on The Microsoft .NET Garbage Collection Implementation:<br>
		  <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI.asp</a>
		  <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI2.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI2.asp</a>
	</ul>

** Useful links

	Paolo Molaro found a few interesting links:

	<ul>
		* On compilation of stack-based languages:<br>
		<a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
		http://www.complang.tuwien.ac.at/projects/rafts.html</a>

		* A paper on fast JIT compilation of a stack-based language:<br>
		  <a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
		  http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>

		* Vmgen generates much of the code for efficient virtual machine (VM)
		  interpreters from simple descriptions of the VM instructions:<br>
		  <a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
		  http://www.complang.tuwien.ac.at/anton/vmgen</a>
	</ul>

** PInvoke

	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.