X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fc-sharp;h=fa4dad1d732fc629c355460e4055f62dd3ff55f6;hb=5bc50198763036923c94c011fa194b4707c27447;hp=132f51abc5a210a525961427330f85bcd6bd2a97;hpb=b633f9a08a34870e33f5e9e2474a7602de353633;p=mono.git
diff --git a/web/c-sharp b/web/c-sharp
index 132f51abc5a..fa4dad1d732 100644
--- a/web/c-sharp
+++ b/web/c-sharp
@@ -1,20 +1,46 @@
* 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 compile
- small C# programs.
+ MCS is currently able to compile itself and many more C#
+ programs (there is a test suite included that you can use).
- All type, field, method, delegates definitions are now emitted
- and the body of constructors and methods is being generated
- for a subset of the language. Although MCS can parse itself,
- it cant not yet compile itself. Most statements are generated
- correctly and about 60% of the C# expressions are supported.
+ 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.
- Work is progressing quickly on various fronts in the C#
- compiler.
+ 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.
- A test suite is being built currently to track the progress of
- the compiler.
+ 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 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 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
@@ -47,24 +73,47 @@
have to postpone this decision until the above steps
are finished.
- * Code generation: The compiler recently started generating IL
- executables that contain interfaces. Work is
- progressing in other areas.
-
- The code generation is done through the System.Reflection.Emit API.
+ * Code generation: The code generation is done through
+ the System.Reflection.Emit API.
+** 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.
+
** Current pending tasks
Simple tasks:
- * PInvoke declarations are not supported.
-
- * Pre-processing is not supported.
+ * Redo the way we deal with built-in operators.
+
- * Compiler does not pass around line/col information from tokenizer for error reporting.
+ Larger tasks:
+
* Jay does not work correctly with `error'
productions, making parser errors hard to point. It
@@ -74,31 +123,12 @@
Nick Drochak has started a project on SourceForge for this.
You can find the project at:
http://sourceforge.net/projects/jb2csharp/
-
-
- Interesting and Fun hacks to the compiler:
-
-
- * Finishing the JB port from Java to C#. If you are
- interested in working on this, please contact the project admin on SourceForge:
-
- http://sourceforge.net/projects/jb2csharp/
-
- More on JB at:
- http://www.cs.colorado.edu/~dennis/software/jb.html
-
- JB will allow us to move from the Berkeley Yacc
- based Jay to a Bison-based compiler (better error
- reporting and recovery).
* 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.
- * Enum resolutions: it is another fun hack, as enums can be defined
- in terms of themselves (enum X { a = b + 1, b = 5 }).
-
** Questions and Answers
@@ -127,6 +157,10 @@ Q: If your C# compiler is written in C#, how do you plan on getting
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