X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fruntime;h=0bd5ebc83a685affc7ebc19c2b3149ba138f2e35;hb=3c592236c79b0a2cc746f222c9bfd93e8e82171a;hp=bf7c55501cdc56fdde694477b8548bec83603be3;hpb=78c33903018fb6c3693c4f94c8b481e2a0f3b808;p=mono.git
diff --git a/web/runtime b/web/runtime
index bf7c55501cd..0bd5ebc83a6 100644
--- a/web/runtime
+++ b/web/runtime
@@ -1,13 +1,29 @@
* 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:
+
+
+ * 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
@@ -16,7 +32,7 @@
Linux.
Our roadmap looks like this, this has been updated as of
- Jul 15, 2001:
+ Dec 18, 2001:
@@ -30,25 +46,26 @@
* Milestone 3: DoneDefine an lburg-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: 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: Port of the JITer to non IA32 systems.
- 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
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 (updated, Nov 16th, 2001)
+** 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
@@ -73,18 +90,9 @@
** 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.
-
- 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 +119,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 +149,5 @@
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.