easy-to-port runtime engine.
</ul>
- Currently both runtimes are missing garbage collection. We
- are planning on using the ORP GC engine and deploy it by
- middle January.
+ Currently we are using the Bohem conservative garbage
+ collector.
-* COM and XPCOM
-
- We plan on adding support for XPCOM on Unix and COM on Microsoft
- Windows later in our development process.
+ The Mono runtime can be used as a stand-alone process, or it
+ can be <a href="embedded-api">embedded into applications</a> (see
+ the documentation in mono/samples/embed for more details).
-** Executing MSIL/CIL images
+ Embedding the Mono runtime allows applications to be extended
+ in C# while reusing all of the existing C and C++ code.
- The code will load an executable and map the references to
- external assemblies to our own version of the assemblies on
- Linux.
+ Paolo Molaro did a presentation on the current JIT engine and
+ the new JIT engine. You can find his <a
+ href="http://primates.ximian.com/~lupus/slides/jit/">slides
+ here</a>
- Our roadmap looks like this, this has been updated as of
- <b>Dec 18, 2001</b>:
+** Current JIT Engine (<b>updated, July 8th, 2002</b>)
- <ul>
+ 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.
- * Milestone 1: <b>Done</b> Fully read and parse all CIL byte-codes
- and metadata tokens (ie, a disassembler).
+ The JIT engine implements a number of optimizations:
- * Milestone 2: <b>Done</b> 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.
+ <ul>
+ * Opcode cost estimates (our architecture allows
+ us to generate different code paths depending
+ on the target CPU dynamically).
+
+ * Inlining.
- * Milestone 3: <b>Done</b>Define an <i>lburg</i>-like
- instruction selector for the JITer for Intel.
+ * Constant folding.
- * 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.
+ Although compilers typically do
+ constant folding, the combination of inlining with
+ constant folding gives some very good results.
- * Milestone 5: Port of the JITer to non IA32 systems.
+ * Linear scan register allocation. In the past,
+ register allocation was our achilles heel, but now
+ we have left this problem behind.
</ul>
- 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 (mostly we use GNU make in
- a few of the makefiles).
-
-** JIT Engine (<b>updated, Dec 18th, 2001</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.
-
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
</ul>
+** New JIT engine.
+
+ We are working on a new JIT engine. The new JIT engine
+ focuses on portability and in two intermediate representations
+ that simplify the development of optimizations. This together
+ with the Ahead-of-Time compilation will allow developers to
+ deploy applications that match the speed of natively compiled code.
+
** Garbage Collection
+ 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.
+
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.
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.
+
projects / mono.git / blobdiff