/
c-sharp
236 lines (171 loc) · 8.66 KB
/
c-sharp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
* MCS: The Ximian C# compiler
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.
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:
<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 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
language element. So a C# class and its associated
information is kept in a "Class" class, a "struct"
in a "Struct" class and so on. Statements derive
from the "Statement" class, and Expressions from the
Expr class.
* 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: 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.
* Open bugs
See the <a href="bugs.html">bugs page</a> for more information.
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 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-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
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.
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
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 caught.
In the future I want to port one of the Bison/Java ports to C# for
the parser.
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).
Q: Why are you writing a JIT engine instead of a front-end to GCC?
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