X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fc-sharp;h=ddf6844701f73790dda4c60efec685c56f340860;hb=9d93ddc5daf9a96e7fcd5d9ef7fac0ddba68feb9;hp=69f391ab323e06c39d9573c5467e627e8f6e542c;hpb=aceaacc0abe56540c7f93bcf8d5050d087573a23;p=mono.git diff --git a/web/c-sharp b/web/c-sharp index 69f391ab323..ddf6844701f 100644 --- a/web/c-sharp +++ b/web/c-sharp @@ -1,20 +1,57 @@ * MCS: The Ximian C# compiler - MCS began as an experiment to learn the features of C# by - writing a large C# program. MCS is currently able to parse C# - programs and create an internal tree representation of the - program. MCS can parse itself. + The Mono C# compiler is considered feature complete at this + point and relatively 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 + half a million lines of C# code. - Work is progressing quickly on various fronts in the C# - compiler. Recently I started using the System.Reflection API - to load system type definitions and avoid self-population of - types in the compiler and dropped my internal Type - representation in favor of using .NET's System.Type. +* Pending tasks + + There are a few known bugs in the Mono C# compiler, but + they are very very few at this point, + you can also browse the MCS bugs from Bugzilla. + + 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 here + in StarOffice format. + +** Obtaining MCS + + The Mono C# compiler is part of the `mcs' module in the Mono CVS + you can get it from our Anonymous CVS server, + or you can get nightly download page. + +** 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: + + +** CIL Optimizations. -** Current pending tasks + 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. - Array declarations are currently being ignored, + 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. - PInvoke is not supported. + 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. - Pre-processing is not supported. + 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. - Attribute declarations and passing currently ignored. +** History - Compiler does not pass around line/col information from tokenizer for error reporting. + 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. - Jay does not work correctly with `error' productions, making parser errors hard to point. + The Mono Runtime and the Mono execution engine were able to make + our compiler self hosting on March 12, 2002. ** Questions and Answers @@ -82,16 +140,12 @@ A: I wanted to learn about C#, and this was an exercise in this Q: If your C# compiler is written in C#, how do you plan on getting this working on a non-Microsoft environment. - The compiler will have two output mechanisms: IL code or C code. - A compiled version of the compiler could be run on Unix - using the JIT runtime. + We will do this through an implementation of the CLI Virtual + Execution System for Unix (our JIT engine). - The C output generation bit is just intended to be a temporary - measure to allow Unix hackers to contribute to the effort without - requiring Windows and Microsoft's .NET implementation to work on - the compiler. So the MCS C# compiler will compile itself to C, - this code then compiled to an executable on Unix and voila! We - have a native compiler for GNU/Linux. + 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? @@ -103,13 +157,53 @@ A: No, currently I am using Jay which is a port of Berkeley Yacc to In the future I want to port one of the Bison/Java ports to C# for the parser. -Q: How do I compile it? +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). -A: Compiling MCS currently requires you to run my port of Jay to - C# on a Unix system to generate the parser, and then you need - to use Microsoft's .NET csc.exe compiler to compile the compiler. +Q: Why are you writing a JIT engine instead of a front-end to GCC? - It might be simple to port Jay.cs to Windows, but I have not tried - this. +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 GCC +section on the main FAQ