diff options
author | Miguel de Icaza <miguel@gnome.org> | 2001-06-20 03:08:44 +0400 |
---|---|---|
committer | Miguel de Icaza <miguel@gnome.org> | 2001-06-20 03:08:44 +0400 |
commit | 6049b85accef724f847767f3b0a9e9033b8c34bb (patch) | |
tree | 7ac962987263ba8805a235e78567ee62082196dd | |
parent | 2df9c2fb52a216fe6bc82dc3d04b28ab6f55bc30 (diff) |
Add docs
svn path=/trunk/mono/; revision=15
-rw-r--r-- | doc/c-sharp | 114 | ||||
-rw-r--r-- | doc/class-library | 67 | ||||
-rw-r--r-- | doc/download | 11 | ||||
-rw-r--r-- | doc/gcc-frontend | 10 | ||||
-rw-r--r-- | doc/rationale | 159 | ||||
-rw-r--r-- | doc/roadmap | 12 | ||||
-rw-r--r-- | doc/runtime | 70 | ||||
-rw-r--r-- | doc/team | 2 | ||||
-rw-r--r-- | web/c-sharp | 114 | ||||
-rw-r--r-- | web/class-library | 67 | ||||
-rw-r--r-- | web/download | 11 | ||||
-rw-r--r-- | web/gcc-frontend | 10 | ||||
-rw-r--r-- | web/rationale | 159 | ||||
-rw-r--r-- | web/roadmap | 12 | ||||
-rw-r--r-- | web/runtime | 70 | ||||
-rw-r--r-- | web/team | 2 |
16 files changed, 890 insertions, 0 deletions
diff --git a/doc/c-sharp b/doc/c-sharp new file mode 100644 index 00000000000..d77490d46de --- /dev/null +++ b/doc/c-sharp @@ -0,0 +1,114 @@ +* 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. + + 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. + +** Phases of the compiler + + The compiler has a number of phases: + + * Lexical analizer: hand-coded lexical analizer that + provides token 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 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 process can happen + on the actual code generation, we need to resolve + the parents for interfaces, classes and structs. + + * 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: nothing done so far, but I do not + expect this to be hard, as I will just use + System.Reflection.Emit to generate the code. + +** Current pending tasks + + Arrays declarations are currently being ignored, + + PInvoke is not supported. + + Pre-processing is not supported. + + Attribute declarations and passing is currently ignored. + + Compiler does not pass around line/col information from tokenizer for error reporting. + + Jay does not work correctly with `error' productions, making parser errors hard to point. + +** Questions and Answers + +Q: Why not write a C# front-end for GCC? + +A: I wanted to learn about C#, and this was an excercise 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-architect + 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. + + The compiler will have two output mechanisms: IL code or C code. + A compiled version of the compiler could be ran on Unix by just + using the JIT runtime. + + 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 on Unix and voila! We have a native + compiler for GNU/Linux. + +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 catched. + + In the future I want to port one of the Bison/Java ports to C# for + the parser. + +Q: How do I compile it? + +A: Compiling MCS currently requires you to run my port of <a + href="http://primates.ximian.com/~miguel/code/jay.cs.tar.gz">Jay to + C#</a> on a Unix system to generate the parser, and then you need + to use Microsoft's .NET csc.exe compiler to compile the compiler. + + It might be simple to port Jay.cs to Windows, but I have not tried + this. + diff --git a/doc/class-library b/doc/class-library new file mode 100644 index 00000000000..4cea4b24a9d --- /dev/null +++ b/doc/class-library @@ -0,0 +1,67 @@ +* The Class Library + + The Class Library should be compatible with Microsoft's .NET + implementation. + + Ideally as much code as possible should be written using C#, + in some cases we might either need to interface with code + written in C for large chunks of functionality (libart and + Gtk+ for example) or we would need to interface to the system + libraries (libc on Unix for networking functions for + example). + +** Using existing components from GNOME. + + Our current plan is to implement the GUI tools on top of + Gtk+. The only problem is that applications from Windows + might expect to be able to pull the HWND property from the + widgets and use PInvoke to call Windows functions. + +** Class Library and Win32 dependencies. + + There are a few spots where the Win32 foundation is exposed to + the class library (the HDC and HWND properties in the GDI+), + it seems from casual inspection that these can be safely + mapped to Gdk's GC and GdkWindow pointers without breaking anything. + + The only drawback is that, we will not support PInvoke + invocations of Win32 code. This could be possible in the + future by reusing pieces of Wine, and probably using Wine as + our toolkit, but we think this is not as important as most + people will always be isolated from the Win32 system. + +*** Initial GDI+ and WinForms implementation + + The initial implementation will use Gtk+ as the underlying + toolkit, but implementations for other windowing systems + should be possible (specially thinking about PDA devices + here). + + Since Gtk+ 2.0 has been ported to other windowing systems + other than X (frame buffer, Win32 and BeOS implementation + exist) it should cover most uses for most users. + +*** Database access + + Implementing the ADO.NET functionality can be done through + reusing <a href="http://www.gnome-db.org">GNOME-DB</a> as + GNOME-DB was implemented precisely to provide an ADO-like + system for GNOME. + +*** Component Integration + + We will provide a new namespace to use GNOME specific features + as well as a namespace to host Bonobo interfaces and classes + in Mono. + +** Licensing + + The class library will be licensed under the terms of the GNU + GPL, with the special provision that linking to this library + does not cause your application to be covered by the GNU GPL. + + This is a stop gap measure, I am using this until we can + figure out why not use the laxer GNU LGPL license. We do + request that contributors allow us to relicense the code under + a GNU LGPL like license in the future for inclussion in the + code base at any point in the future. diff --git a/doc/download b/doc/download new file mode 100644 index 00000000000..9ac6f1afa1f --- /dev/null +++ b/doc/download @@ -0,0 +1,11 @@ +* Software Availability + + The Virtual Execution System is available in package `mono'. + + Currently the code for the C# compiler as well as the error + test suite and the class library is in package `mcs', we will + move this later into `mono'. + + The parser generator required by `mcs' is available in the + module `jay'. + diff --git a/doc/gcc-frontend b/doc/gcc-frontend new file mode 100644 index 00000000000..6046d6c66e5 --- /dev/null +++ b/doc/gcc-frontend @@ -0,0 +1,10 @@ +* The GCC front-end + + The GCC front-end will be a front-end that would accept as + input in a binary file with codes in the Common Intermediate + Language (CIL) that will generate native code. + + This will allow pre-compilation and full optimization to take + place before a program is executed. + + diff --git a/doc/rationale b/doc/rationale new file mode 100644 index 00000000000..a57132d939e --- /dev/null +++ b/doc/rationale @@ -0,0 +1,159 @@ + +The Mono Project + +* Background. + + The GNOME project goal was to bring missing technologies to + Unix and make it competitive in the current market place for + desktop applications. We also realized early on that language + independence was important, and that is why GNOME APIs were + coded using a standard that allowed the APIs to be easily + wrapper for other languages. Our APIs are available on most + programming languages on Unix (Perl, Python, Scheme, C++, + Objective-C, Ada). + + Later on we decided to use better methods for encapsulating + our APIs, and we started to use CORBA to define interfaces to + components, and we complemented it policy and a set of + standard GNOME interfaces for easily creating reusable and + language independent components, controls and compound + documents. This technology is known as <a + href="http://www.ximian.com/tech/bonobo.php3">Bonobo<a>, and + easy to use interfaces to Bonobo exist for C, Perl, Python, + Java. + + CORBA is good when you define coarse interfaces, and most + Bonobo interfaces are coarse. The only problem is that + Bonobo/CORBA interfaces are not good for small interfaces. + For example implementing an XML parser component and use it to + parse, create and walk an XML document would be inneficient + compared to a C API. + +* Microsoft's .NET + + The Microsoft .NET initiative is confusing because it is a + company wide effort that ranges from development tools to end + user applications. + + Depending who you ask, you will probably get a different + answer on what .NET is, .NET is a branding name that has been + applied to: + + * The .NET development platform, a new platform for + writing software. + + * Web services. + + * Microsoft Server Applications. + + * New tools that use the new development platform. + + * Hailstorm, the Passport centralized single-signon + system that is being integrated into Windows XP. + + From all the above, the one I am interested in is the new .NET + development platform. + +* The .NET development platform. + + Microsoft has created a new development platform, the + highlights of this new development platform are: + + * A runtime environment that provides garbage + collection, threading and a virtual machine + specification (The Virtual Execution System, VES) + + * A comprehensive class library. + + * A new language, C#. Very similar to Java, that + allows programmers to use all the features available + on the .NET runtime. + + * A language specification that compilers can + follow if they want to generate classes and code + that can interoperate with other programming + languages (The Common Language Specification: CLS) + + The .NET development platform is similar to the goals we had + in GNOME of giving language independence to programmers. Any + API that is written using a CLS provider language can be used + by any language that is a CLS consumer. Compilers generate + code in a format called Common Intermediate Language (CIL) + which is an intermediate representation of a compiled program + and is easy to compile to native code or compiled using + Just-in-Time (JIT) engines. The restrictions placed by the + runtime on the CIL byte codes ensures that it is possible to + do a good job at optimizing the code in a JIT compiler. + + There is not really a lot of innovation in this platform, we + have seen all of these concepts before, and we are all + familiar with how these things work. + + What makes the .NET development platform interesting is that + it is a good mix of technologies that have been nicely + integrated. + + The .NET development platform is essentially a new foundation + for program development that gives Microsoft a room to grow + for the next years. + +* ECMA standards. + + Microsoft together with HP and Intel have submitted the + specifications of C#, the runtime, the metadata and the + other various bits of the .NET development platform to the + ECMA for standarization. + +* Mono: The GNU .NET implementation. + + Ximian has begun work on Mono, a project that aims to bring + the .NET development platform to free systems. + + When the GNU project was launched, they picked the best + operating system that was available out there, and they + began to clone it: Unix. + + The .NET development platform is a very rich, powerful, and + well designed platform that would help improve the free + software development platform. Just like the GNU project + began to clone Unix sixteen years ago, we will be cloning the + .NET development platform because it is a great platform to + build on. + +* What makes up Mono? + + There are various pieces that will make up Mono: + + * A C# compiler. + + * A .NET executable tools. + + * The Virtual Execution System: that will have the + Just-in-Time compiler, garbage collector, loader, + threading engine. + + A byte code interpreter will be provided for quickly + porting Mono to new systems. + + * An implemenation of the .NET class library. + + * Visual development tools. + + * A CIL GCC frontend. + +* Why use GNOME components? + + GNOME is an umbrella project that consists of infrastructural + components (GUI toolkit, XML libraries, CORBA implementation, + printing architecture, imaging system), a desktop environment, + and productivity applications. + + The GNOME infrastructural components can be used to quickly + implement various pieces of the .NET API without reinventing + the wheel, and since all those components are licensed under + the terms of the GNU LGPL it is a perfect fit. + + Libart will be used to implement the Drawing.2D API; Gtk+ and + the GNOME libraries will be used to implement the WinForms + API and of course Glib and libxml will be used in various + places.
\ No newline at end of file diff --git a/doc/roadmap b/doc/roadmap new file mode 100644 index 00000000000..6cdfa1366a8 --- /dev/null +++ b/doc/roadmap @@ -0,0 +1,12 @@ +* Roadmap + + We are working on the following three projects at Ximian: + + The C# Compiler (mcs/mcs) + + A .NET compatible Class Library (mcs/class) + + The JIT/interpreter (mono) + + +
\ No newline at end of file diff --git a/doc/runtime b/doc/runtime new file mode 100644 index 00000000000..877d3435e51 --- /dev/null +++ b/doc/runtime @@ -0,0 +1,70 @@ +* The MonoNet runtime + + The MonoNet runtime will implement the JIT engine (and a byte + code interpreter for quickly porting to new systems), the + class loader, the garbage collector, threading system and + metadata access libraries. + + Currently the runtime contains the beginning of an image + loader and metadata access entry points. Since Beta2 has been + now released, it is possible to resume work using the ECMA + specs and testing with Beta2-generated executables. + + The runtime core will be implemented in C, in a library + "libMonoVES.so". + +** Executing MSIL/CIL images + + The code will load an executable and map the references to + external assemblies to our own version of the assemblies on + GNU/Linux. + + Our roadmap looks like this: + + * Milestone 1: Fully read and parse all CIL byte-codes + and metadata tokens (ie, a disassembler). + + * Milestone 2: Complete an interpreter for CIL byte + codes. This interpreter can be used temporarly to + run CIL byte code on a system where no JIT is + available. + + * Milestone 3: IA32 translating-JIT engine. + + * Milestone 4: non-Intel port of the JIT engine. + + * Milestone 5: Optimizing JIT engine port for IA32. + + * Milestone 6: non-Intel port of the Optimizing JIT + engine. + + A setup similar to the Kaffe JIT engine can be used to + layout the code to support non-IA32 architectures. Our work + will be focused on getting a IA32 version running first. + + The JIT engine should work on Linux and Win32, although you + might need to install the CygWin32 development tools to get a + Unix-like compilation environment which is what we know how to + use. + +** Garbage Collection + + We have decided to implement a tracing garbage collector, + which is very similar to the one being used by .NET. For an + introduction to the garbage collection system used by + Microsoft's CLR implementation, you can read this book on <a + href="http://www.amazon.com/exec/obidos/ASIN/0471941484/o/qid=992556433/sr=2-1/ref=aps_sr_b_1_1/103-5866388-0492603">Garbage + Collection.</a> + + Although using a conservative garbage collector like Bohem's + would work, all the type information is available at runtime, + so we can actually implement a better collector than a + conservative collector. + +** PInvoke + + PInvoke will be supported, and will be used to wrap Unix API + calls, these in turn are required for reusing some of the + GNOME libraries that will reduce the work we have to do to + deliver a complete class library + diff --git a/doc/team b/doc/team new file mode 100644 index 00000000000..eff7bc9d3d5 --- /dev/null +++ b/doc/team @@ -0,0 +1,2 @@ +* The MonoNet Team + diff --git a/web/c-sharp b/web/c-sharp new file mode 100644 index 00000000000..d77490d46de --- /dev/null +++ b/web/c-sharp @@ -0,0 +1,114 @@ +* 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. + + 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. + +** Phases of the compiler + + The compiler has a number of phases: + + * Lexical analizer: hand-coded lexical analizer that + provides token 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 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 process can happen + on the actual code generation, we need to resolve + the parents for interfaces, classes and structs. + + * 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: nothing done so far, but I do not + expect this to be hard, as I will just use + System.Reflection.Emit to generate the code. + +** Current pending tasks + + Arrays declarations are currently being ignored, + + PInvoke is not supported. + + Pre-processing is not supported. + + Attribute declarations and passing is currently ignored. + + Compiler does not pass around line/col information from tokenizer for error reporting. + + Jay does not work correctly with `error' productions, making parser errors hard to point. + +** Questions and Answers + +Q: Why not write a C# front-end for GCC? + +A: I wanted to learn about C#, and this was an excercise 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-architect + 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. + + The compiler will have two output mechanisms: IL code or C code. + A compiled version of the compiler could be ran on Unix by just + using the JIT runtime. + + 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 on Unix and voila! We have a native + compiler for GNU/Linux. + +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 catched. + + In the future I want to port one of the Bison/Java ports to C# for + the parser. + +Q: How do I compile it? + +A: Compiling MCS currently requires you to run my port of <a + href="http://primates.ximian.com/~miguel/code/jay.cs.tar.gz">Jay to + C#</a> on a Unix system to generate the parser, and then you need + to use Microsoft's .NET csc.exe compiler to compile the compiler. + + It might be simple to port Jay.cs to Windows, but I have not tried + this. + diff --git a/web/class-library b/web/class-library new file mode 100644 index 00000000000..4cea4b24a9d --- /dev/null +++ b/web/class-library @@ -0,0 +1,67 @@ +* The Class Library + + The Class Library should be compatible with Microsoft's .NET + implementation. + + Ideally as much code as possible should be written using C#, + in some cases we might either need to interface with code + written in C for large chunks of functionality (libart and + Gtk+ for example) or we would need to interface to the system + libraries (libc on Unix for networking functions for + example). + +** Using existing components from GNOME. + + Our current plan is to implement the GUI tools on top of + Gtk+. The only problem is that applications from Windows + might expect to be able to pull the HWND property from the + widgets and use PInvoke to call Windows functions. + +** Class Library and Win32 dependencies. + + There are a few spots where the Win32 foundation is exposed to + the class library (the HDC and HWND properties in the GDI+), + it seems from casual inspection that these can be safely + mapped to Gdk's GC and GdkWindow pointers without breaking anything. + + The only drawback is that, we will not support PInvoke + invocations of Win32 code. This could be possible in the + future by reusing pieces of Wine, and probably using Wine as + our toolkit, but we think this is not as important as most + people will always be isolated from the Win32 system. + +*** Initial GDI+ and WinForms implementation + + The initial implementation will use Gtk+ as the underlying + toolkit, but implementations for other windowing systems + should be possible (specially thinking about PDA devices + here). + + Since Gtk+ 2.0 has been ported to other windowing systems + other than X (frame buffer, Win32 and BeOS implementation + exist) it should cover most uses for most users. + +*** Database access + + Implementing the ADO.NET functionality can be done through + reusing <a href="http://www.gnome-db.org">GNOME-DB</a> as + GNOME-DB was implemented precisely to provide an ADO-like + system for GNOME. + +*** Component Integration + + We will provide a new namespace to use GNOME specific features + as well as a namespace to host Bonobo interfaces and classes + in Mono. + +** Licensing + + The class library will be licensed under the terms of the GNU + GPL, with the special provision that linking to this library + does not cause your application to be covered by the GNU GPL. + + This is a stop gap measure, I am using this until we can + figure out why not use the laxer GNU LGPL license. We do + request that contributors allow us to relicense the code under + a GNU LGPL like license in the future for inclussion in the + code base at any point in the future. diff --git a/web/download b/web/download new file mode 100644 index 00000000000..9ac6f1afa1f --- /dev/null +++ b/web/download @@ -0,0 +1,11 @@ +* Software Availability + + The Virtual Execution System is available in package `mono'. + + Currently the code for the C# compiler as well as the error + test suite and the class library is in package `mcs', we will + move this later into `mono'. + + The parser generator required by `mcs' is available in the + module `jay'. + diff --git a/web/gcc-frontend b/web/gcc-frontend new file mode 100644 index 00000000000..6046d6c66e5 --- /dev/null +++ b/web/gcc-frontend @@ -0,0 +1,10 @@ +* The GCC front-end + + The GCC front-end will be a front-end that would accept as + input in a binary file with codes in the Common Intermediate + Language (CIL) that will generate native code. + + This will allow pre-compilation and full optimization to take + place before a program is executed. + + diff --git a/web/rationale b/web/rationale new file mode 100644 index 00000000000..a57132d939e --- /dev/null +++ b/web/rationale @@ -0,0 +1,159 @@ + +The Mono Project + +* Background. + + The GNOME project goal was to bring missing technologies to + Unix and make it competitive in the current market place for + desktop applications. We also realized early on that language + independence was important, and that is why GNOME APIs were + coded using a standard that allowed the APIs to be easily + wrapper for other languages. Our APIs are available on most + programming languages on Unix (Perl, Python, Scheme, C++, + Objective-C, Ada). + + Later on we decided to use better methods for encapsulating + our APIs, and we started to use CORBA to define interfaces to + components, and we complemented it policy and a set of + standard GNOME interfaces for easily creating reusable and + language independent components, controls and compound + documents. This technology is known as <a + href="http://www.ximian.com/tech/bonobo.php3">Bonobo<a>, and + easy to use interfaces to Bonobo exist for C, Perl, Python, + Java. + + CORBA is good when you define coarse interfaces, and most + Bonobo interfaces are coarse. The only problem is that + Bonobo/CORBA interfaces are not good for small interfaces. + For example implementing an XML parser component and use it to + parse, create and walk an XML document would be inneficient + compared to a C API. + +* Microsoft's .NET + + The Microsoft .NET initiative is confusing because it is a + company wide effort that ranges from development tools to end + user applications. + + Depending who you ask, you will probably get a different + answer on what .NET is, .NET is a branding name that has been + applied to: + + * The .NET development platform, a new platform for + writing software. + + * Web services. + + * Microsoft Server Applications. + + * New tools that use the new development platform. + + * Hailstorm, the Passport centralized single-signon + system that is being integrated into Windows XP. + + From all the above, the one I am interested in is the new .NET + development platform. + +* The .NET development platform. + + Microsoft has created a new development platform, the + highlights of this new development platform are: + + * A runtime environment that provides garbage + collection, threading and a virtual machine + specification (The Virtual Execution System, VES) + + * A comprehensive class library. + + * A new language, C#. Very similar to Java, that + allows programmers to use all the features available + on the .NET runtime. + + * A language specification that compilers can + follow if they want to generate classes and code + that can interoperate with other programming + languages (The Common Language Specification: CLS) + + The .NET development platform is similar to the goals we had + in GNOME of giving language independence to programmers. Any + API that is written using a CLS provider language can be used + by any language that is a CLS consumer. Compilers generate + code in a format called Common Intermediate Language (CIL) + which is an intermediate representation of a compiled program + and is easy to compile to native code or compiled using + Just-in-Time (JIT) engines. The restrictions placed by the + runtime on the CIL byte codes ensures that it is possible to + do a good job at optimizing the code in a JIT compiler. + + There is not really a lot of innovation in this platform, we + have seen all of these concepts before, and we are all + familiar with how these things work. + + What makes the .NET development platform interesting is that + it is a good mix of technologies that have been nicely + integrated. + + The .NET development platform is essentially a new foundation + for program development that gives Microsoft a room to grow + for the next years. + +* ECMA standards. + + Microsoft together with HP and Intel have submitted the + specifications of C#, the runtime, the metadata and the + other various bits of the .NET development platform to the + ECMA for standarization. + +* Mono: The GNU .NET implementation. + + Ximian has begun work on Mono, a project that aims to bring + the .NET development platform to free systems. + + When the GNU project was launched, they picked the best + operating system that was available out there, and they + began to clone it: Unix. + + The .NET development platform is a very rich, powerful, and + well designed platform that would help improve the free + software development platform. Just like the GNU project + began to clone Unix sixteen years ago, we will be cloning the + .NET development platform because it is a great platform to + build on. + +* What makes up Mono? + + There are various pieces that will make up Mono: + + * A C# compiler. + + * A .NET executable tools. + + * The Virtual Execution System: that will have the + Just-in-Time compiler, garbage collector, loader, + threading engine. + + A byte code interpreter will be provided for quickly + porting Mono to new systems. + + * An implemenation of the .NET class library. + + * Visual development tools. + + * A CIL GCC frontend. + +* Why use GNOME components? + + GNOME is an umbrella project that consists of infrastructural + components (GUI toolkit, XML libraries, CORBA implementation, + printing architecture, imaging system), a desktop environment, + and productivity applications. + + The GNOME infrastructural components can be used to quickly + implement various pieces of the .NET API without reinventing + the wheel, and since all those components are licensed under + the terms of the GNU LGPL it is a perfect fit. + + Libart will be used to implement the Drawing.2D API; Gtk+ and + the GNOME libraries will be used to implement the WinForms + API and of course Glib and libxml will be used in various + places.
\ No newline at end of file diff --git a/web/roadmap b/web/roadmap new file mode 100644 index 00000000000..6cdfa1366a8 --- /dev/null +++ b/web/roadmap @@ -0,0 +1,12 @@ +* Roadmap + + We are working on the following three projects at Ximian: + + The C# Compiler (mcs/mcs) + + A .NET compatible Class Library (mcs/class) + + The JIT/interpreter (mono) + + +
\ No newline at end of file diff --git a/web/runtime b/web/runtime new file mode 100644 index 00000000000..877d3435e51 --- /dev/null +++ b/web/runtime @@ -0,0 +1,70 @@ +* The MonoNet runtime + + The MonoNet runtime will implement the JIT engine (and a byte + code interpreter for quickly porting to new systems), the + class loader, the garbage collector, threading system and + metadata access libraries. + + Currently the runtime contains the beginning of an image + loader and metadata access entry points. Since Beta2 has been + now released, it is possible to resume work using the ECMA + specs and testing with Beta2-generated executables. + + The runtime core will be implemented in C, in a library + "libMonoVES.so". + +** Executing MSIL/CIL images + + The code will load an executable and map the references to + external assemblies to our own version of the assemblies on + GNU/Linux. + + Our roadmap looks like this: + + * Milestone 1: Fully read and parse all CIL byte-codes + and metadata tokens (ie, a disassembler). + + * Milestone 2: Complete an interpreter for CIL byte + codes. This interpreter can be used temporarly to + run CIL byte code on a system where no JIT is + available. + + * Milestone 3: IA32 translating-JIT engine. + + * Milestone 4: non-Intel port of the JIT engine. + + * Milestone 5: Optimizing JIT engine port for IA32. + + * Milestone 6: non-Intel port of the Optimizing JIT + engine. + + A setup similar to the Kaffe JIT engine can be used to + layout the code to support non-IA32 architectures. Our work + will be focused on getting a IA32 version running first. + + The JIT engine should work on Linux and Win32, although you + might need to install the CygWin32 development tools to get a + Unix-like compilation environment which is what we know how to + use. + +** Garbage Collection + + We have decided to implement a tracing garbage collector, + which is very similar to the one being used by .NET. For an + introduction to the garbage collection system used by + Microsoft's CLR implementation, you can read this book on <a + href="http://www.amazon.com/exec/obidos/ASIN/0471941484/o/qid=992556433/sr=2-1/ref=aps_sr_b_1_1/103-5866388-0492603">Garbage + Collection.</a> + + Although using a conservative garbage collector like Bohem's + would work, all the type information is available at runtime, + so we can actually implement a better collector than a + conservative collector. + +** PInvoke + + PInvoke will be supported, and will be used to wrap Unix API + calls, these in turn are required for reusing some of the + GNOME libraries that will reduce the work we have to do to + deliver a complete class library + diff --git a/web/team b/web/team new file mode 100644 index 00000000000..eff7bc9d3d5 --- /dev/null +++ b/web/team @@ -0,0 +1,2 @@ +* The MonoNet Team + |