Update on the FAQ
[mono.git] / web / c-sharp
1 * MCS: The Ximian C# compiler
2
3         MCS began as an experiment to learn the features of C# by
4         writing a large C# program.  MCS is currently able to parse C#
5         programs and create an internal tree representation of the
6         program.  MCS can parse itself.  
7
8         Work is progressing quickly on various fronts in the C#
9         compiler.  Recently I started using the System.Reflection API
10         to load system type definitions and avoid self-population of
11         types in the compiler and dropped my internal Type
12         representation in favor of using the CLI's System.Type.  
13
14 ** Phases of the compiler
15
16         The compiler has a number of phases:
17
18         <ul>
19                 * Lexical analyzer: hand-coded lexical analyzer that
20                   provides tokens to the parser.
21
22                 * The Parser: the parser is implemented using Jay (A
23                   Berkeley Yacc port to Java, that I ported to C#).
24                   The parser does minimal work and syntax checking,
25                   and only constructs a parsed tree.
26
27                   Each language element gets its own class.  The code
28                   convention is to use an uppercase name for the
29                   language element.  So a C# class and its associated
30                   information is kept in a "Class" class, a "struct"
31                   in a "Struct" class and so on.  Statements derive
32                   from the "Statement" class, and Expressions from the
33                   Expr class.
34
35                 * Parent class resolution: before the actual code
36                   generation, we need to resolve the parents and
37                   interfaces for interface, classe and struct
38                   definitions.
39
40                 * Semantic analysis: since C# can not resolve in a
41                   top-down pass what identifiers actually mean, we
42                   have to postpone this decision until the above steps
43                   are finished.
44
45                 * Code generation: nothing done so far, but I do not
46                   expect this to be hard, as I will just use
47                   System.Reflection.Emit to generate the code. 
48         
49         </ul>
50
51 <a name="tasks">
52 ** Current pending tasks
53
54         Simple tasks:
55
56         <ul>
57                 * Array declarations are currently being ignored, 
58
59                 * PInvoke declarations are not supported.
60
61                 * Pre-processing is not supported.
62
63                 * Attribute declarations and passing currently ignored.
64
65                 * Compiler does not pass around line/col information from tokenizer for error reporting.
66
67                 * Jay does not work correctly with `error'
68                   productions, making parser errors hard to point.  It
69                   would be best to port the Bison-To-Java compiler to
70                   become Bison-to-C# compiler (bjepson@oreilly.com
71                   might have more information)
72         </ul>
73
74         Interesting and Fun hacks to the compiler:
75
76         <ul>
77                 * Finishing the JB port from Java to C#.  If you are
78                   interested in working on this, please contact Brian
79                   Jepson (bjepson at oreilly d-o-t com).
80
81                   More on JB at: <a href="http://www.cs.colorado.edu/~dennis/software/jb.html">
82                   http://www.cs.colorado.edu/~dennis/software/jb.html</a>
83
84                   JB will allow us to move from the Berkeley Yacc
85                   based Jay to a Bison-based compiler (better error
86                   reporting and recovery).
87
88                 * Semantic Analysis: Return path coverage and
89                   initialization before use coverage are two great
90                   features of C# that help reduce the number of bugs
91                   in applications.  It is one interesting hack.
92
93                 * TypeRefManager.  This exists currently in its infancy only. 
94
95                 * Enum resolutions: it is another fun hack, as enums can be defined 
96                   in terms of themselves (<tt>enum X { a = b + 1, b = 5 }</tt>). 
97
98         </ul>
99
100 ** Questions and Answers
101
102 Q: Why not write a C# front-end for GCC?
103
104 A: I wanted to learn about C#, and this was an exercise in this
105    task.  The resulting compiler is highly object-oriented, which has
106    lead to a very nice, easy to follow and simple implementation of
107    the compiler.
108
109    I found that the design of this compiler is very similar to
110    Guavac's implementation.
111
112    Targeting the CIL/MSIL byte codes would require to re-architecting
113    GCC, as GCC is mostly designed to be used for register machines.
114    
115    The GCC Java engine that generates Java byte codes cheats: it does
116    not use the GCC backend; it has a special backend just for Java, so
117    you can not really generate Java bytecodes from the other languages
118    supported by GCC. 
119
120 Q: If your C# compiler is written in C#, how do you plan on getting
121    this working on a non-Microsoft environment.
122
123    We will do this through an implementation of the CLI Virtual
124    Execution System for Unix (our JIT engine). 
125
126 Q: Do you use Bison?
127
128 A: No, currently I am using Jay which is a port of Berkeley Yacc to
129    Java that I later ported to C#.  This means that error recovery is
130    not as nice as I would like to, and for some reason error
131    productions are not being caught.  
132
133    In the future I want to port one of the Bison/Java ports to C# for
134    the parser.
135
136 Q: Should someone work on a GCC front-end to C#?
137
138 A: I would love if someone does, and we would love to help anyone that
139    takes on that task, but we do not have the time or expertise to
140    build a C# compiler with the GCC engine.  I find it a lot more fun
141    personally to work on C# on a C# compiler, which has an intrinsic
142    beauty.
143
144    We can provide help and assistance to anyone who would like to work
145    on this task.
146
147 Q: Should someone make a GCC backend that will generate CIL images?
148
149 A: I would love to see a backend to GCC that generates CIL images.  It
150    would provide a ton of free compilers that would generate CIL
151    code.  This is something that people would want to look into
152    anyways for Windows interoperation in the future.
153
154    Again, we would love to provide help and assistance to anyone
155    interested in working in such a project.
156
157 Q: What about making a front-end to GCC that takes CIL images and
158    generates native code?
159
160 A: I would love to see this, specially since GCC supports this same
161    feature for Java Byte Codes.  You could use the metadata library
162    from Mono to read the byte codes (ie, this would be your
163    "front-end") and generate the trees that get passed to the
164    optimizer.
165
166    Ideally our implementation of the CLI will be available as a shared
167    library that could be linked with your application as its runtime
168    support. 
169
170    Again, we would love to provide help and assistance to anyone
171    interested in working in such a project.
172    
173 Q: But would this work around the GPL in the GCC compiler and allow
174    people to work on non-free front-ends?
175
176 A: People can already do this by targeting the JVM byte codes (there
177    are about 130 compilers for various languages that target the JVM).
178
179 Q: Why are you writing a JIT engine instead of a front-end to GCC?
180
181 A: The JIT engine and runtime engine will be able to execute CIL
182    executables generated on Windows.
183
184
185 You might also want to look at the <a href="faq.html#gcc">GCC</a>
186 section on the main FAQ