1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
* The Mono runtime
The Mono 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 has an image loader and metadata access
entry points. The runtime comes with a simple interpreter
that can execute very simple programs.
** 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
Linux.
Our roadmap looks like this, this has been updated as of
<b>Jul 15, 2001</b>:
<ul>
* Milestone 1: <b>Done</b> Fully read and parse all CIL byte-codes
and metadata tokens (ie, a disassembler).
* Milestone 2: <b>Done</b> 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: <b>Done</b>Define an <i>lburg</i>-like
instruction selector for the JITer for Intel.
Although slower at JITing than a streaming JITer, it
generates better code. The same grammar can later
be used for the stream jitter.
* Milestone 4: Implement JITer. This is where our
current efforts are focused on, the JITer is 60% ready.
* Milestone 5: Port of the JITer to non IA32 systems.
</ul>
A setup similar to the Kaffe JIT engine will 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
will need to install the CygWin32 development tools to get a
Unix-like compilation environment.
** JIT Engine (<b>updated, Nov 16th, 2001</b>)
The JIT engine uses a code-generator generator approach for
compilation. Given the properties of CIL byte codes, we can
take full advantage of a real instruction selector for our
code generator.
There are a couple of books that deal with this technique: "A
Retargetable C Compiler" and "Advanced Compiler Design and
Implementation" are good references. You can also get a
technical description of <a
href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">lbrug</a>.
A few papers that describe the instruction selector:
<ul>
* <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/interface.pdf&pub=wiley">A code generation interface for ANSI C</a>
* <a href="http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/~drh/pubs/iburg.pdf&pub=ACM">Engineering efficient code generators using tree matching and dynamic programming.</a>
</ul>
** Garbage Collection
We have decided to implement a generational 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>
Another consideration is to use the same interface that ORP
uses to its Garbage Collection system and reuse that GC system
instead of rolling our own, as the ORP system is pretty advanced
and is independent of the rest of ORP.
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.
<ul>
* Garbage collection list and FAQ:<br>
<a href="http://www.iecc.com/gclist/">http://www.iecc.com/gclist/</a>
* "GC points in a Threaded Environment":<br>
<a href="http://research.sun.com/techrep/1998/abstract-70.html">
http://research.sun.com/techrep/1998/abstract-70.html</a>
* "A Generational Mostly-concurrent Garbage Collector":
<a href="http://research.sun.com/techrep/2000/abstract-88.html">
http://research.sun.com/techrep/2000/abstract-88.html</a>
* Details on The Microsoft .NET Garbage Collection Implementation:<br>
<a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI.asp</a>
<a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI2.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI2.asp</a>
</ul>
** IO and threading
The ECMA runtime and the .NET runtime assume an IO model and a
threading model that is very similar to the Win32 API. Dick
Porter has been working on the Mono abstraction layer that allows
our runtime to execute code that depend on this behaviour.
** Useful links
Paolo Molaro found a few interesting links:
<ul>
* On compilation of stack-based languages:<br>
<a href="http://www.complang.tuwien.ac.at/projects/rafts.html">
http://www.complang.tuwien.ac.at/projects/rafts.html</a>
* A paper on fast JIT compilation of a stack-based language:<br>
<a href="http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf">
http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf</a>
* Vmgen generates much of the code for efficient virtual machine (VM)
interpreters from simple descriptions of the VM instructions:<br>
<a href="http://www.complang.tuwien.ac.at/anton/vmgen/">
http://www.complang.tuwien.ac.at/anton/vmgen</a>
</ul>
** PInvoke
PInvoke is the mechanism we are using to wrap Unix API calls
as well as talking to system libraries.
We hvae implemented PInvoke through libffi, but we are likely
going to roll our own system as the runtime matures, specially
as the interpreter is approaching completion, and we move into
the JITer.
|
