mono/web/c-sharp

* MCS: The Ximian C# compiler

	MCS is currently able to compile itself and many more C#
	programs (there is a test suite included that you can use).

	We are in feature completion mode right now.  There are still
	a couple of areas that are not covered by the Mono compiler, but
	they are very very few at this point.

	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.

	A test suite is maintained to track the progress of
	the compiler and various programs are routinely compiled and
	ran.

** 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 Windows (with the .NET
	framework 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. 

<a name="tasks">
** Current pending tasks

	Simple tasks:

	<ul>
		* Redo the way we deal with built-in operators.
	</ul>

	Larger tasks:
	<ul>

		* Jay does not work correctly with `error'
		  productions, making parser errors hard to point.  It
		  would be best to port the Bison-To-Java compiler to
		  become Bison-to-C# compiler. 
		  
		  Nick Drochak has started a project on SourceForge for this.
		  You can find the project at: <a href="http://sourceforge.net/projects/jb2csharp/">
		  http://sourceforge.net/projects/jb2csharp/</a>

		* Semantic Analysis: Return path coverage and
		  initialization before use coverage are two great
		  features of C# that help reduce the number of bugs
		  in applications.  It is one interesting hack.

	</ul>

** Questions and Answers

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