*** empty log message ***
[mono.git] / doc / c-sharp
1 * MCS: The Ximian C# compiler
2
3         MCS is currently able to compile itself and many more C#
4         programs (there is a test suite included that you can use).
5
6         We are in feature completion mode right now.  There are still
7         a couple of areas that are not covered by the Mono compiler, but
8         they are very very few at this point.
9
10         MCS was able to parse itself on April 2001, MCS compiled itself
11         for the first time on December 28 2001.  MCS became self hosting
12         on January 3rd, 2002. 
13
14         The Mono Runtime and the Mono execution engine were able to make
15         our compiler self hosting on March 12, 2002.
16
17         A test suite is maintained to track the progress of
18         the compiler and various programs are routinely compiled and
19         ran.
20
21 ** Obtaining MCS
22
23         The Mono C# compiler is part of the `mcs' module in the Mono CVS
24         you can get it from our <a href="anoncvs.html">Anonymous CVS</a> server,
25         or you can get nightly <a href="download.html">download page</a>.
26
27 ** Running MCS
28
29         MCS is written in C# and uses heavily the .NET APIs.  MCS runs
30         on Linux (with the Mono runtime) and Windows (with the .NET
31         framework runtime)
32
33 ** Reporting Bugs in MCS
34
35         When you report a bug, try to provide a small test case that would
36         show the error so we can include this as part of the Mono C# regression
37         test suite.
38
39         If the bug is an error or a warning that we do not flag, write
40         a sample program called `csXXXX.cs' where XXXX is the code number
41         that is used by the Microsoft C# compiler that illustrates the 
42         problem.  That way we can also do regression tests on the invalid
43         input.  
44
45 ** Phases of the compiler
46
47         The compiler has a number of phases:
48
49         <ul>
50                 * Lexical analyzer: hand-coded lexical analyzer that
51                   provides tokens to the parser.
52
53                 * The Parser: the parser is implemented using Jay (A
54                   Berkeley Yacc port to Java, that I ported to C#).
55                   The parser does minimal work and syntax checking,
56                   and only constructs a parsed tree.
57
58                   Each language element gets its own class.  The code
59                   convention is to use an uppercase name for the
60                   language element.  So a C# class and its associated
61                   information is kept in a "Class" class, a "struct"
62                   in a "Struct" class and so on.  Statements derive
63                   from the "Statement" class, and Expressions from the
64                   Expr class.
65
66                 * Parent class resolution: before the actual code
67                   generation, we need to resolve the parents and
68                   interfaces for interface, classe and struct
69                   definitions.
70
71                 * Semantic analysis: since C# can not resolve in a
72                   top-down pass what identifiers actually mean, we
73                   have to postpone this decision until the above steps
74                   are finished.
75
76                 * Code generation: The code generation is done through
77                   the System.Reflection.Emit API.
78         </ul>
79
80 ** CIL Optimizations.
81
82         The compiler performs a number of simple optimizations on its input:
83         constant folding (this is required by the C# language spec) and 
84         can perform dead code elimination.
85
86         Other more interesting optimizations like hoisting are not possible
87         at this point since the compiler output at this point does not
88         generate an intermediate representation that is suitable to
89         perform basic block computation.  
90
91         Adding an intermediate layer to enable the basic block
92         computation to the compiler should be a simple task, but we
93         are considering having a generic CIL optimizer.  Since all the
94         information that is required to perform basic block-based
95         optimizations is available at the CIL level, we might just skip
96         this step altogether and have just a generic IL optimizer that
97         would perform hoisting on arbitrary CIL programs, not only
98         those produced by MCS.  
99
100         If this tool is further expanded to perform constant folding
101         (not needed for our C# compiler, as it is already in there)
102         and dead code elimination, other compiler authors might be
103         able to use this generic CIL optimizer in their projects
104         reducing their time to develop a production compiler. 
105
106 <a name="tasks">
107 ** Current pending tasks
108
109         Simple tasks:
110
111         <ul>
112                 * Redo the way we deal with built-in operators.
113         </ul>
114
115         Larger tasks:
116         <ul>
117
118                 * Jay does not work correctly with `error'
119                   productions, making parser errors hard to point.  It
120                   would be best to port the Bison-To-Java compiler to
121                   become Bison-to-C# compiler. 
122                   
123                   Nick Drochak has started a project on SourceForge for this.
124                   You can find the project at: <a href="http://sourceforge.net/projects/jb2csharp/">
125                   http://sourceforge.net/projects/jb2csharp/</a>
126
127                 * Semantic Analysis: Return path coverage and
128                   initialization before use coverage are two great
129                   features of C# that help reduce the number of bugs
130                   in applications.  It is one interesting hack.
131
132         </ul>
133
134 ** Questions and Answers
135
136 Q: Why not write a C# front-end for GCC?
137
138 A: I wanted to learn about C#, and this was an exercise in this
139    task.  The resulting compiler is highly object-oriented, which has
140    lead to a very nice, easy to follow and simple implementation of
141    the compiler.
142
143    I found that the design of this compiler is very similar to
144    Guavac's implementation.
145
146    Targeting the CIL/MSIL byte codes would require to re-architecting
147    GCC, as GCC is mostly designed to be used for register machines.
148    
149    The GCC Java engine that generates Java byte codes cheats: it does
150    not use the GCC backend; it has a special backend just for Java, so
151    you can not really generate Java bytecodes from the other languages
152    supported by GCC. 
153
154 Q: If your C# compiler is written in C#, how do you plan on getting
155    this working on a non-Microsoft environment.
156
157    We will do this through an implementation of the CLI Virtual
158    Execution System for Unix (our JIT engine). 
159
160    Our JIT engine is working for the purposes of using the compiler.
161    The supporting class libraries are being worked on to fully support
162    the compiler.
163
164 Q: Do you use Bison?
165
166 A: No, currently I am using Jay which is a port of Berkeley Yacc to
167    Java that I later ported to C#.  This means that error recovery is
168    not as nice as I would like to, and for some reason error
169    productions are not being caught.  
170
171    In the future I want to port one of the Bison/Java ports to C# for
172    the parser.
173
174 Q: Should someone work on a GCC front-end to C#?
175
176 A: I would love if someone does, and we would love to help anyone that
177    takes on that task, but we do not have the time or expertise to
178    build a C# compiler with the GCC engine.  I find it a lot more fun
179    personally to work on C# on a C# compiler, which has an intrinsic
180    beauty.
181
182    We can provide help and assistance to anyone who would like to work
183    on this task.
184
185 Q: Should someone make a GCC backend that will generate CIL images?
186
187 A: I would love to see a backend to GCC that generates CIL images.  It
188    would provide a ton of free compilers that would generate CIL
189    code.  This is something that people would want to look into
190    anyways for Windows interoperation in the future.
191
192    Again, we would love to provide help and assistance to anyone
193    interested in working in such a project.
194
195 Q: What about making a front-end to GCC that takes CIL images and
196    generates native code?
197
198 A: I would love to see this, specially since GCC supports this same
199    feature for Java Byte Codes.  You could use the metadata library
200    from Mono to read the byte codes (ie, this would be your
201    "front-end") and generate the trees that get passed to the
202    optimizer.
203
204    Ideally our implementation of the CLI will be available as a shared
205    library that could be linked with your application as its runtime
206    support. 
207
208    Again, we would love to provide help and assistance to anyone
209    interested in working in such a project.
210    
211 Q: But would this work around the GPL in the GCC compiler and allow
212    people to work on non-free front-ends?
213
214 A: People can already do this by targeting the JVM byte codes (there
215    are about 130 compilers for various languages that target the JVM).
216
217 Q: Why are you writing a JIT engine instead of a front-end to GCC?
218
219 A: The JIT engine and runtime engine will be able to execute CIL
220    executables generated on Windows.
221
222 You might also want to look at the <a href="faq.html#gcc">GCC</a>
223 section on the main FAQ