X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fruntime;h=0bd5ebc83a685affc7ebc19c2b3149ba138f2e35;hb=88860adf56a5a8fa324b4800d5d7309a2a6989b9;hp=5ea5e23b198e13c935a0cd93bec03b07063eff0c;hpb=983d92c25f124849761b0ece45f5fc6d1f60e4b1;p=mono.git
diff --git a/web/runtime b/web/runtime
index 5ea5e23b198..0bd5ebc83a6 100644
--- a/web/runtime
+++ b/web/runtime
@@ -1,70 +1,153 @@
-* The MonoNet runtime
+* The Mono 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.
+ 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 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.
+ We currently have two runtimes:
- The runtime core will be implemented in C, in a library
- "libMonoVES.so".
+
+ * mono: The Just In Time compiler implemented
+ using a BURS instruction selector. We only support
+ x86 machines in the JIT engine at this point.
+
+ * mint: The Mono interpreter. This is an
+ easy-to-port runtime engine.
+
+
+ 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.
** 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.
+ Linux.
+
+ Our roadmap looks like this, this has been updated as of
+ Dec 18, 2001:
- Our roadmap looks like this:
+
- * Milestone 1: Fully read and parse all CIL byte-codes
- and metadata tokens (ie, a disassembler).
+ * Milestone 1: Done Fully read and parse all CIL byte-codes
+ and metadata tokens (ie, a disassembler).
- * Milestone 2: Complete an interpreter for CIL byte
+ * Milestone 2: Done 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 3: DoneDefine an lburg-like
+ instruction selector for the JITer for Intel.
- * Milestone 4: non-Intel port of the JIT engine.
+ * Milestone 4: Done 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: Optimizing JIT engine port for IA32.
+ * Milestone 5: Port of the JITer to non IA32 systems.
+
- * Milestone 6: non-Intel port of the Optimizing JIT
- engine.
-
- A setup similar to the Kaffe JIT engine can be used to
+ A setup similar to the Kaffe JIT engine will 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 which is what we know how to
- use.
+ 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 (updated, Dec 18th, 2001)
+
+ 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.
+
+ 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 lbrug.
+
+ A few papers that describe the instruction selector:
+
+
** 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 Garbage
- Collection.
+ 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,
so we can actually implement a better collector than a
conservative collector.
+
+
+** 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.
+
+** Useful links
+
+ Paolo Molaro found a few interesting links:
+
+
+
** 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.
+ PInvoke is the mechanism we are using to wrap Unix API calls
+ as well as talking to system libraries.
+
+ Initially we used libffi, but it was fairly slow, so we have
+ reused parts of the JIT work to create efficient PInvoke trampolines.