merge
[mono-project.git] / web / c-sharp
blobffa0b574bef43950ccb928ef65edad10ff7409fe
1 * MCS: The Ximian C# compiler
3         The Mono C# compiler is considered feature C# 1.0 complete at
4         this point and mature.  MCS is able to compile itself and many
5         more C# programs (there is a test suite included that you can
6         use).  It is routinely used to compile Mono, roughly 1.7
7         million lines of C# code.
9         The compiler is also fairly fast.  On a IBM ThinkPad t40 it
10         compiles 18,000 lines of C# code per second.
12         Work on C# 2.0 has started: some pieces of it are available on
13         the standard compiler with the -2 switch (iterators, method
14         conversions) and some others are available on the `gmcs'
15         branch on CVS (generics)
17 ** Obtaining MCS
19         The Mono C# compiler is part of the `mcs' module in the Mono CVS
20         you can get it from our <a href="anoncvs.html">Anonymous CVS</a> server,
21         or you can get nightly <a href="download.html">download page</a>.
23 ** Running MCS
25         MCS is written in C# and uses heavily the .NET APIs.  MCS runs
26         on Linux with the Mono runtime and on Windows with both the
27         .NET runtime and the Mono runtime.
29 ** Reporting Bugs in MCS
31         When you report a bug, try to provide a small test case that would
32         show the error so we can include this as part of the Mono C# regression
33         test suite.
35         If the bug is an error or a warning that we do not flag, write
36         a sample program called `csXXXX.cs' where XXXX is the code number
37         that is used by the Microsoft C# compiler that illustrates the 
38         problem.  That way we can also do regression tests on the invalid
39         input.  
41 ** Phases of the compiler
43         The compiler has a number of phases:
45         <ul>
46                 * Lexical analyzer: hand-coded lexical analyzer that
47                   provides tokens to the parser.
49                 * The Parser: the parser is implemented using Jay (A
50                   Berkeley Yacc port to Java, that I ported to C#).
51                   The parser does minimal work and syntax checking,
52                   and only constructs a parsed tree.
54                   Each language element gets its own class.  The code
55                   convention is to use an uppercase name for the
56                   language element.  So a C# class and its associated
57                   information is kept in a "Class" class, a "struct"
58                   in a "Struct" class and so on.  Statements derive
59                   from the "Statement" class, and Expressions from the
60                   Expr class.
62                 * Parent class resolution: before the actual code
63                   generation, we need to resolve the parents and
64                   interfaces for interface, classe and struct
65                   definitions.
67                 * Semantic analysis: since C# can not resolve in a
68                   top-down pass what identifiers actually mean, we
69                   have to postpone this decision until the above steps
70                   are finished.
72                 * Code generation: The code generation is done through
73                   the System.Reflection.Emit API.
74         </ul>
76 ** CIL Optimizations.
78         The compiler performs a number of simple optimizations on its input:
79         constant folding (this is required by the C# language spec) and 
80         can perform dead code elimination.
82         Other more interesting optimizations like hoisting are not possible
83         at this point since the compiler output at this point does not
84         generate an intermediate representation that is suitable to
85         perform basic block computation.  
87         Adding an intermediate layer to enable the basic block
88         computation to the compiler should be a simple task, but we
89         are considering having a generic CIL optimizer.  Since all the
90         information that is required to perform basic block-based
91         optimizations is available at the CIL level, we might just skip
92         this step altogether and have just a generic IL optimizer that
93         would perform hoisting on arbitrary CIL programs, not only
94         those produced by MCS.  
96         If this tool is further expanded to perform constant folding
97         (not needed for our C# compiler, as it is already in there)
98         and dead code elimination, other compiler authors might be
99         able to use this generic CIL optimizer in their projects
100         reducing their time to develop a production compiler. 
102 * Open bugs
104         See the <a href="bugs.html">bugs page</a> for more information.
106         A test suite is maintained to track the progress of
107         the compiler and various programs are routinely compiled and
108         ran.
110 * Slides
112         Slides for the Mono C# Compiler presentation at .NET ONE are
113         available <a
114         href="http://primates.ximian.com/~miguel/slides-europe-nov-2002/Mono_C_Sharp_Overview_1007.sxi">here</a>
115         in StarOffice format.
117 ** History
119         MCS was able to parse itself on April 2001, MCS compiled itself
120         for the first time on December 28 2001.  MCS became self hosting
121         on January 3rd, 2002. 
123         The Mono Runtime and the Mono execution engine were able to make
124         our compiler self hosting on March 12, 2002.
126 ** Questions and Answers
128 Q: Does the Mono C# compiler support C# 2.0?
130 A: At this point the Mono C# compiler supports some of the features of
131    C# 2.0, but the support has not been completed.   To enable 2.0 features
132    you must use the -2 flag to the compiler.
134 Q: What features are available as of Feb 2004?
136 A: Iterators have been implemented as well as method group implicit
137    conversion to delegates on the main compiler branch.
139    We have a branch of the compiler in the module `mcs/gmcs' which is
140    where we are developing the Generics support for the compiler.  Plenty
141    of tests work (see mcs/tests/gen-*.cs for a list of tests), but work
142    remains to be done.
144 Q: Will the C# 2.0 features be part of the Mono 1.0 release?
146 A: Only a few, the generic compiler will not be part of the 1.0
147    stable release, but a beta preview will be distributed.
149 Q: Why not write a C# front-end for GCC?
151 A: I wanted to learn about C#, and this was an exercise in this
152    task.  The resulting compiler is highly object-oriented, which has
153    lead to a very nice, easy to follow and simple implementation of
154    the compiler.
156    I found that the design of this compiler is very similar to
157    Guavac's implementation.
159    Targeting the CIL/MSIL byte codes would require to re-architecting
160    GCC, as GCC is mostly designed to be used for register machines.
161    
162    The GCC Java engine that generates Java byte codes cheats: it does
163    not use the GCC backend; it has a special backend just for Java, so
164    you can not really generate Java bytecodes from the other languages
165    supported by GCC. 
167 Q: If your C# compiler is written in C#, how do you plan on getting
168    this working on a non-Microsoft environment.
170    We will do this through an implementation of the CLI Virtual
171    Execution System for Unix (our JIT engine). 
173    Our JIT engine is working for the purposes of using the compiler.
174    The supporting class libraries are being worked on to fully support
175    the compiler.
177 Q: Do you use Bison?
179 A: No, currently I am using Jay which is a port of Berkeley Yacc to
180    Java that I later ported to C#.  This means that error recovery is
181    not as nice as I would like to, and for some reason error
182    productions are not being caught.  
184    In the future I want to port one of the Bison/Java ports to C# for
185    the parser.
187 Q: Should someone work on a GCC front-end to C#?
189 A: I would love if someone does, and we would love to help anyone that
190    takes on that task, but we do not have the time or expertise to
191    build a C# compiler with the GCC engine.  I find it a lot more fun
192    personally to work on C# on a C# compiler, which has an intrinsic
193    beauty.
195    We can provide help and assistance to anyone who would like to work
196    on this task.
198 Q: Should someone make a GCC backend that will generate CIL images?
200 A: I would love to see a backend to GCC that generates CIL images.  It
201    would provide a ton of free compilers that would generate CIL
202    code.  This is something that people would want to look into
203    anyways for Windows interoperation in the future.
205    Again, we would love to provide help and assistance to anyone
206    interested in working in such a project.
208 Q: What about making a front-end to GCC that takes CIL images and
209    generates native code?
211 A: I would love to see this, specially since GCC supports this same
212    feature for Java Byte Codes.  You could use the metadata library
213    from Mono to read the byte codes (ie, this would be your
214    "front-end") and generate the trees that get passed to the
215    optimizer.
217    Ideally our implementation of the CLI will be available as a shared
218    library that could be linked with your application as its runtime
219    support. 
221    Again, we would love to provide help and assistance to anyone
222    interested in working in such a project.
223    
224 Q: But would this work around the GPL in the GCC compiler and allow
225    people to work on non-free front-ends?
227 A: People can already do this by targeting the JVM byte codes (there
228    are about 130 compilers for various languages that target the JVM).
230 Q: Why are you writing a JIT engine instead of a front-end to GCC?
232 A: The JIT engine and runtime engine will be able to execute CIL
233    executables generated on Windows.
235 You might also want to look at the <a href="faq.html#gcc">GCC</a>
236 section on the main FAQ