diff options
Diffstat (limited to 'doc/c-sharp')
| -rw-r--r-- | doc/c-sharp | 223 |
1 files changed, 0 insertions, 223 deletions
diff --git a/doc/c-sharp b/doc/c-sharp deleted file mode 100644 index fa4dad1d732..00000000000 --- a/doc/c-sharp +++ /dev/null @@ -1,223 +0,0 @@ -* 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 |