mirror of https://github.com/dotnet/runtime
Add docs
svn path=/trunk/mono/; revision=15
Commit migrated from 6049b85acc
This commit is contained in:
Miguel de Icaza
parent
0eccccc203
commit
404b88f444
|
|
@ -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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
@ -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'.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
@ -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)
|
||||
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
* The MonoNet Team
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
@ -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'.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
@ -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)
|
||||
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
* The MonoNet Team
|
||||
|
||||
Loading…
Reference in New Issue