* The MonoNet runtime

	The MonoNet 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 contains the beginning of an image
	loader and metadata access entry points.  Since Beta2 has been
	now released, it is possible to resume work using the ECMA
	specs and testing with Beta2-generated executables.

	The runtime core will be implemented in C, in a library
	"libMonoVES.so".  

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

	<ul>

		* Milestone 1: 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: IA32 translating-JIT engine.

		* Milestone 4: non-Intel port of the JIT engine.

		* Milestone 5: Optimizing JIT engine port for IA32.

		* Milestone 6: non-Intel port of the Optimizing JIT
		  engine.
	</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
	might need to install the CygWin32 development tools to get a
	Unix-like compilation environment.

** JIT Engine

	Currently we are evaluating various mechanisms for our JIT
	engine (<a
	href="http://www.intel.com/research/mrl/orp/">ORP</a>, <a
	href="http://www.gnu.org/software/lightning/">GNU
	Lightning</a>, and <a
	href="http://www.eecs.harvard.edu/~nr/toolkit/">NJ Machine
	Toolkit</a>.

	We have not made a decision yet, but we might want to use a
	Code Generator Generator for the Common Intermediate Language,
	as that is likely going to allow us to create better code.

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

	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>
	</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 will be supported, and will be used to wrap Unix API
	calls, these in turn are required for reusing some of the
	GNOME libraries that will reduce the work we have to do to
	deliver a complete class library.