* MCS: The Ximian C# compiler
- MCS began as an experiment to learn the features of C# by
- writing a large C# program. MCS is currently able to compile
- small C# programs.
+ MCS is currently able to compile small C# programs (there is
+ a test suite included that you can use).
All type, field, method, delegates definitions are now emitted
and the body of constructors and methods is being generated
have to postpone this decision until the above steps
are finished.
- * Code generation: The compiler recently started generating IL
- executables that contain interfaces. Work is
- progressing in other areas.
+ * Code generation: The code generation is done through
+ the System.Reflection.Emit API.
- The code generation is done through the System.Reflection.Emit API.
</ul>
<a name="tasks">
* Implement constant expression evaluator.
* Implement constant declarations.
-
- * Implement enumerations.
</ul>
Interesting and Fun hacks to the compiler:
features of C# that help reduce the number of bugs
in applications. It is one interesting hack.
- * Enum resolutions: it is another fun hack, as enums can be defined
- in terms of themselves (<tt>enum X { a = b + 1, b = 5 }</tt>).
-
</ul>
** Questions and Answers
You can contact the team at: <a
href="mailto:mono-list@ximian.com">mono-list@ximian.com</a>
+** Nov 16, 2001
+
+ Mike Kestner has posted an <a
+ href="http://lists.ximian.com/archives/public/gtk-sharp-list/2001-November/000015.html">update</a>
+ on Gtk# development.
+
** Nov 14, 2001
Paolo today got the Mono C# compiler running <a
* <a href="http://www.intel.com/research/mrl/orp">ORP:</a> A research
JIT/VM/GC system from Intel.
- * C# bindings for OpenGL are available here: <a
+ * C# bindings for OpenGL a
nd SDL are available here: <a
href="http://csgl.sourceforge.net">http://csgl.sourceforge.net</a>
* <a
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
<b>Jul 15, 2001</b>:
<ul>
- * Milestone 1: <b> Done</b> Fully read and parse all CIL byte-codes
+ * 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
+ * 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.
- * 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 3: <b>Done</b>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 4: Implement JITer. This is where our
+ current efforts are focused on, the JITer is 60% ready.
* Milestone 5: Port of the JITer to non IA32 systems.
</ul>
will need to install the CygWin32 development tools to get a
Unix-like compilation environment.
-** JIT Engine (<b>updated, Jul 14th, 2001</b>)
+** JIT Engine (<b>updated, Nov 16th, 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.
+ 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 <a
- href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</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:
+ A few papers that describe the instruction selector:
<ul>
- * <a
- href="http://www.intel.com/research/mrl/orp/">ORP</a>
+ * <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/interface.pdf&pub=wiley">A code generation interface for ANSI C</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>.).
+ * <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">Engineering efficient code generators using tree matching and dynamic programming.</a>
- * VCODE.
</ul>
** Garbage Collection
<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>
+** 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:
Pieces of Mono that have been implemented:
<ul>
- * C# compiler: The C# parser can now generate parse
- trees. Next up: semantic analysis, compiler lever optimizations
- and code generation.
+ * C# compiler: The C# compiler is mostly complete, a
+ few features are still missing (for a list, check the
+ <a href="c-sharp.html">C# compiler</a> web page.
- * Metadata library: Can currently parse and load
- information from .NET modules (executables and DLL
- files).
+ * A CIL bytecode interpreter (<b>mint</b>). This
+ currently can be used to run most .NET programs
+ (modulo the fact that our class libraries are not
+ complete enough).
- Parsing of Exception tables is missing.
+ <b>mint</b> can currently run the Mono C# compiler and
+ the compiler generates valid code.
+
+ We use <b>mint</b> as a reference implementation of
+ the runtime environment and to quickly support
+ non-Intel platforms.
+
+ * The Mono JIT engine. The JIT engine is the real
+ virtual machine that we will be supporting. It is
+ approaching maturity rapidly.
+
+ * Metadata library: Can currently parse
+ and load information from .NET modules (executables
+ and DLL files).
* Disassembler: Can disassemble .NET modules. Still
lacking exception handling as well as useful debugging
tools (hex dumping, token dumping).
* Class Libraries: You can check the current status in the
- <a href="class-status.html">Class Status page</a>
+ <a href="class-status.html">Class Status page</a>.
</ul>
- Tasks on the critical path:
-
- <ul>
- * Bytecode interpreter: (Paolo is working on this).
-
- * Simple JIT: Not implemented yet (Miguel is
- researching the code-generator generator)
-
- * Garbage collection engine (Dick is working on this, his contact is <a
- href="mailto:dick@ximian.com">dick@ximian.com</a>
- </ul>
-
- If you want to work on any task here, please mail <a
- href="mailto:mono-list@ximian.com">mono-list@ximian.com</a>
* MCS: The Ximian C# compiler
- MCS began as an experiment to learn the features of C# by
- writing a large C# program. MCS is currently able to compile
- small C# programs.
+ MCS is currently able to compile small C# programs (there is
+ a test suite included that you can use).
All type, field, method, delegates definitions are now emitted
and the body of constructors and methods is being generated
have to postpone this decision until the above steps
are finished.
- * Code generation: The compiler recently started generating IL
- executables that contain interfaces. Work is
- progressing in other areas.
+ * Code generation: The code generation is done through
+ the System.Reflection.Emit API.
- The code generation is done through the System.Reflection.Emit API.
</ul>
<a name="tasks">
* Implement constant expression evaluator.
* Implement constant declarations.
-
- * Implement enumerations.
</ul>
Interesting and Fun hacks to the compiler:
features of C# that help reduce the number of bugs
in applications. It is one interesting hack.
- * Enum resolutions: it is another fun hack, as enums can be defined
- in terms of themselves (<tt>enum X { a = b + 1, b = 5 }</tt>).
-
</ul>
** Questions and Answers
You can contact the team at: <a
href="mailto:mono-list@ximian.com">mono-list@ximian.com</a>
+** Nov 16, 2001
+
+ Mike Kestner has posted an <a
+ href="http://lists.ximian.com/archives/public/gtk-sharp-list/2001-November/000015.html">update</a>
+ on Gtk# development.
+
** Nov 14, 2001
Paolo today got the Mono C# compiler running <a
* <a href="http://www.intel.com/research/mrl/orp">ORP:</a> A research
JIT/VM/GC system from Intel.
- * C# bindings for OpenGL are available here: <a
+ * C# bindings for OpenGL a
nd SDL are available here: <a
href="http://csgl.sourceforge.net">http://csgl.sourceforge.net</a>
* <a
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
<b>Jul 15, 2001</b>:
<ul>
- * Milestone 1: <b> Done</b> Fully read and parse all CIL byte-codes
+ * 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
+ * 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.
- * 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 3: <b>Done</b>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 4: Implement JITer. This is where our
+ current efforts are focused on, the JITer is 60% ready.
* Milestone 5: Port of the JITer to non IA32 systems.
</ul>
will need to install the CygWin32 development tools to get a
Unix-like compilation environment.
-** JIT Engine (<b>updated, Jul 14th, 2001</b>)
+** JIT Engine (<b>updated, Nov 16th, 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.
+ 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 <a
- href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</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:
+ A few papers that describe the instruction selector:
<ul>
- * <a
- href="http://www.intel.com/research/mrl/orp/">ORP</a>
+ * <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/interface.pdf&pub=wiley">A code generation interface for ANSI C</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>.).
+ * <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">Engineering efficient code generators using tree matching and dynamic programming.</a>
- * VCODE.
</ul>
** Garbage Collection
<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>
+** 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:
Pieces of Mono that have been implemented:
<ul>
- * C# compiler: The C# parser can now generate parse
- trees. Next up: semantic analysis, compiler lever optimizations
- and code generation.
+ * C# compiler: The C# compiler is mostly complete, a
+ few features are still missing (for a list, check the
+ <a href="c-sharp.html">C# compiler</a> web page.
- * Metadata library: Can currently parse and load
- information from .NET modules (executables and DLL
- files).
+ * A CIL bytecode interpreter (<b>mint</b>). This
+ currently can be used to run most .NET programs
+ (modulo the fact that our class libraries are not
+ complete enough).
- Parsing of Exception tables is missing.
+ <b>mint</b> can currently run the Mono C# compiler and
+ the compiler generates valid code.
+
+ We use <b>mint</b> as a reference implementation of
+ the runtime environment and to quickly support
+ non-Intel platforms.
+
+ * The Mono JIT engine. The JIT engine is the real
+ virtual machine that we will be supporting. It is
+ approaching maturity rapidly.
+
+ * Metadata library: Can currently parse
+ and load information from .NET modules (executables
+ and DLL files).
* Disassembler: Can disassemble .NET modules. Still
lacking exception handling as well as useful debugging
tools (hex dumping, token dumping).
* Class Libraries: You can check the current status in the
- <a href="class-status.html">Class Status page</a>
+ <a href="class-status.html">Class Status page</a>.
</ul>
- Tasks on the critical path:
-
- <ul>
- * Bytecode interpreter: (Paolo is working on this).
-
- * Simple JIT: Not implemented yet (Miguel is
- researching the code-generator generator)
-
- * Garbage collection engine (Dick is working on this, his contact is <a
- href="mailto:dick@ximian.com">dick@ximian.com</a>
- </ul>
-
- If you want to work on any task here, please mail <a
- href="mailto:mono-list@ximian.com">mono-list@ximian.com</a>
projects / mono.git / commitdiff