* 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 parse C#
- programs and create an internal tree representation of the
- program. MCS can parse itself.
+ The Mono C# compiler is considered feature C# 1.0 complete at
+ this point and mature. MCS is able to compile itself and many
+ more C# programs (there is a test suite included that you can
+ use). It is routinely used to compile Mono, roughly 1.7
+ million lines of C# code.
- Work is progressing quickly on various fronts in the C#
- compiler. Recently I started using the System.Reflection API
- to load system type definitions and avoid self-population of
- types in the compiler and dropped my internal Type
- representation in favor of using .NET's System.Type.
+ The compiler is also fairly fast. On a IBM ThinkPad t40 it
+ compiles 18,000 lines of C# code per second.
+
+ Work on C# 2.0 has started: some pieces of it are available on
+ the standard compiler with the -2 switch (iterators, method
+ conversions) and some others are available on the `gmcs'
+ branch on CVS (generics)
+
+** 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. MCS runs
+ on Linux with the Mono runtime and on Windows with both the
+ .NET runtime and the Mono runtime.
+
+** 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:
- * Lexical analizer: hand-coded lexical analizer that
- provides token to the parser.
+ <ul>
+ * Lexical analyzer: hand-coded lexical analyzer that
+ provides tokens to the parser.
* The Parser: the parser is implemented using Jay (A
Berkeley Yacc port to Java, that I ported to C#).
- The parser does minimal work and checking, and only
- constructs a parsed tree.
+ The parser does minimal work and syntax checking,
+ and only constructs a parsed tree.
Each language element gets its own class. The code
convention is to use an uppercase name for the
from the "Statement" class, and Expressions from the
Expr class.
- * Parent class resolution: before process can happen
- on the actual code generation, we need to resolve
- the parents for interfaces, classes and structs.
+ * Parent class resolution: before the actual code
+ generation, we need to resolve the parents and
+ interfaces for interface, classe and struct
+ definitions.
* Semantic analysis: since C# can not resolve in a
top-down pass what identifiers actually mean, we
have to postpone this decision until the above steps
are finished.
- * Code generation: nothing done so far, but I do not
- expect this to be hard, as I will just use
- System.Reflection.Emit to generate the code.
+ * Code generation: The code generation is done through
+ the System.Reflection.Emit API.
+ </ul>
+
+** CIL Optimizations.
-** Current pending tasks
+ 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.
- Arrays declarations are currently being ignored,
+ 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.
- PInvoke is not supported.
+ 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.
- Pre-processing is not supported.
+ 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.
- Attribute declarations and passing is currently ignored.
+* Open bugs
- Compiler does not pass around line/col information from tokenizer for error reporting.
+ See the <a href="bugs.html">bugs page</a> for more information.
- Jay does not work correctly with `error' productions, making parser errors hard to point.
+ A test suite is maintained to track the progress of
+ the compiler and various programs are routinely compiled and
+ ran.
+
+* Slides
+
+ Slides for the Mono C# Compiler presentation at .NET ONE are
+ available <a
+ href="http://primates.ximian.com/~miguel/slides-europe-nov-2002/Mono_C_Sharp_Overview_1007.sxi">here</a>
+ in StarOffice format.
+
+** History
+
+ 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.
+
+ The Mono Runtime and the Mono execution engine were able to make
+ our compiler self hosting on March 12, 2002.
** Questions and Answers
+Q: Does the Mono C# compiler support C# 2.0?
+
+A: At this point the Mono C# compiler supports some of the features of
+ C# 2.0, but the support has not been completed. To enable 2.0 features
+ you must use the -2 flag to the compiler.
+
+Q: What features are available as of Feb 2004?
+
+A: Iterators have been implemented as well as method group implicit
+ conversion to delegates on the main compiler branch.
+
+ We have a branch of the compiler in the module `mcs/gmcs' which is
+ where we are developing the Generics support for the compiler. Plenty
+ of tests work (see mcs/tests/gen-*.cs for a list of tests), but work
+ remains to be done.
+
+Q: Will the C# 2.0 features be part of the Mono 1.0 release?
+
+A: Only a few, the generic compiler will not be part of the 1.0
+ stable release, but a beta preview will be distributed.
+
Q: Why not write a C# front-end for GCC?
-A: I wanted to learn about C#, and this was an excercise in this
+A: I wanted to learn about C#, and this was an exercise in this
task. The resulting compiler is highly object-oriented, which has
lead to a very nice, easy to follow and simple implementation of
the compiler.
I found that the design of this compiler is very similar to
Guavac's implementation.
- Targeting the CIL/MSIL byte codes would require to re-architect
+ Targeting the CIL/MSIL byte codes would require to re-architecting
GCC, as GCC is mostly designed to be used for register machines.
- The GCC Java engine that generates java byte codes cheats: it does
- not use the GCC backend, it has a special backend just for Java, so
+ The GCC Java engine that generates Java byte codes cheats: it does
+ not use the GCC backend; it has a special backend just for Java, so
you can not really generate Java bytecodes from the other languages
supported by GCC.
Q: If your C# compiler is written in C#, how do you plan on getting
this working on a non-Microsoft environment.
- The compiler will have two output mechanisms: IL code or C code.
- A compiled version of the compiler could be ran on Unix by just
- using the JIT runtime.
+ We will do this through an implementation of the CLI Virtual
+ Execution System for Unix (our JIT engine).
- The C output generation bit is just intended to be a temporary
- measure to allow Unix hackers to contribute to the effort without
- requiring Windows and Microsoft's .NET implementation to work on
- the compiler. So the MCS C# compiler will compile itself to C,
- this code then compiled on Unix and voila! We have a native
- compiler for GNU/Linux.
+ 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
Java that I later ported to C#. This means that error recovery is
not as nice as I would like to, and for some reason error
- productions are not being catched.
+ productions are not being caught.
In the future I want to port one of the Bison/Java ports to C# for
the parser.
-Q: How do I compile it?
+Q: Should someone work on a GCC front-end to C#?
+
+A: I would love if someone does, and we would love to help anyone that
+ takes on that task, but we do not have the time or expertise to
+ build a C# compiler with the GCC engine. I find it a lot more fun
+ personally to work on C# on a C# compiler, which has an intrinsic
+ beauty.
+
+ We can provide help and assistance to anyone who would like to work
+ on this task.
+
+Q: Should someone make a GCC backend that will generate CIL images?
+
+A: I would love to see a backend to GCC that generates CIL images. It
+ would provide a ton of free compilers that would generate CIL
+ code. This is something that people would want to look into
+ anyways for Windows interoperation in the future.
+
+ Again, we would love to provide help and assistance to anyone
+ interested in working in such a project.
+
+Q: What about making a front-end to GCC that takes CIL images and
+ generates native code?
+
+A: I would love to see this, specially since GCC supports this same
+ feature for Java Byte Codes. You could use the metadata library
+ from Mono to read the byte codes (ie, this would be your
+ "front-end") and generate the trees that get passed to the
+ optimizer.
+
+ Ideally our implementation of the CLI will be available as a shared
+ library that could be linked with your application as its runtime
+ support.
+
+ Again, we would love to provide help and assistance to anyone
+ interested in working in such a project.
+
+Q: But would this work around the GPL in the GCC compiler and allow
+ people to work on non-free front-ends?
+
+A: People can already do this by targeting the JVM byte codes (there
+ are about 130 compilers for various languages that target the JVM).
-A: Compiling MCS currently requires you to run my port of <a
- href="http://primates.ximian.com/~miguel/code/jay.cs.tar.gz">Jay to
- C#</a> on a Unix system to generate the parser, and then you need
- to use Microsoft's .NET csc.exe compiler to compile the compiler.
+Q: Why are you writing a JIT engine instead of a front-end to GCC?
- It might be simple to port Jay.cs to Windows, but I have not tried
- this.
+A: The JIT engine and runtime engine will be able to execute CIL
+ executables generated on Windows.
+You might also want to look at the <a href="faq.html#gcc">GCC</a>
+section on the main FAQ
projects / mono.git / blobdiff