* MCS: The Ximian C# compiler
- MCS is currently able to compile small C# programs (there is
- a test suite included that you can use).
+ MCS is currently able to compile itself and many more C#
+ programs (there is a test suite included that you can use).
We are in feature completion mode right now. There are still
a couple of areas that are not covered by the Mono compiler, but
they are very very few at this point.
- Although MCS has been able to parse itself since April,
- it can not yet compile itself. We are working hard towards
- mkaing the compiler self hosting in Linux.
+ MCS was able to parse itself on April 2001, MCS compiled itself
+ for the first time on December 28 2001. MCS became self hosting
+ on January 3rd, 2002.
- A test suite is being built currently to track the progress of
+ A test suite is maintained to track the progress of
the compiler and various programs are routinely compiled and
ran.
+** Obtaining MCS
+
+ The Mono C# compiler is part of the `mcs' module in the Mono CVS
+ you can get it from our <a href="anoncvs.html">Anonymous CVS</a> server,
+ or you can get nightly <a href="download.html">download page</a>.
+
+** Running MCS
+
+ MCS is written in C# and uses heavily the .NET APIs. At this point
+ MCS only runs on Windows with the .NET Framework SDK installed. Work
+ is progressing rapidly in our JIT engine and our class libraries to
+ allow MCS to be ran in non-Windows systems.
+
+** Reporting Bugs in MCS
+
+ When you report a bug, try to provide a small test case that would
+ show the error so we can include this as part of the Mono C# regression
+ test suite.
+
+ If the bug is an error or a warning that we do not flag, write
+ a sample program called `csXXXX.cs' where XXXX is the code number
+ that is used by the Microsoft C# compiler that illustrates the
+ problem. That way we can also do regression tests on the invalid
+ input.
+
** Phases of the compiler
The compiler has a number of phases:
* Code generation: The code generation is done through
the System.Reflection.Emit API.
-
</ul>
+** CIL Optimizations.
+
+ The compiler performs a number of simple optimizations on its input:
+ constant folding (this is required by the C# language spec) and
+ can perform dead code elimination.
+
+ Other more interesting optimizations like hoisting are not possible
+ at this point since the compiler output at this point does not
+ generate an intermediate representation that is suitable to
+ perform basic block computation.
+
+ Adding an intermediate layer to enable the basic block
+ computation to the compiler should be a simple task, but we
+ are considering having a generic CIL optimizer. Since all the
+ information that is required to perform basic block-based
+ optimizations is available at the CIL level, we might just skip
+ this step altogether and have just a generic IL optimizer that
+ would perform hoisting on arbitrary CIL programs, not only
+ those produced by MCS.
+
+ If this tool is further expanded to perform constant folding
+ (not needed for our C# compiler, as it is already in there)
+ and dead code elimination, other compiler authors might be
+ able to use this generic CIL optimizer in their projects
+ reducing their time to develop a production compiler.
+
<a name="tasks">
** Current pending tasks
Simple tasks:
<ul>
- * Extern declarations are missing.
+ * Redo the way we deal with built-in operators.
</ul>
Larger tasks:
-
- <ul>
- * Finish constant folding.
- </ul>
-
- Interesting and Fun hacks to the compiler:
-
<ul>
* Jay does not work correctly with `error'
We will do this through an implementation of the CLI Virtual
Execution System for Unix (our JIT engine).
+ Our JIT engine is working for the purposes of using the compiler.
+ The supporting class libraries are being worked on to fully support
+ the compiler.
+
Q: Do you use Bison?
A: No, currently I am using Jay which is a port of Berkeley Yacc to
projects / mono.git / blobdiff