1 |
<html> |
<html><head><title>Gavare's eXperimental Emulator: Introduction</title> |
2 |
<head><title>GXemul documentation: Introduction</title> |
<meta name="robots" content="noarchive,nofollow,noindex"></head> |
3 |
</head> |
<body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000"> |
4 |
<body bgcolor="#ffffff" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000"> |
<table border=0 width=100% bgcolor="#d0d0d0"><tr> |
5 |
<p> |
<td width=100% align=center valign=center><table border=0 width=100%><tr> |
6 |
<table width="100%"> |
<td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6"> |
7 |
<tr><td width="100%" bgcolor="#808070"><font color="#ffffe0" size="6"> |
<b>Gavare's eXperimental Emulator:</b></font><br> |
8 |
<b>GXemul documentation: Introduction</b></font></td></tr> |
<font color="#000000" size="6"><b>Introduction</b> |
9 |
</table> |
</font></td></tr></table></td></tr></table><p> |
|
<p> |
|
|
<!-- The first 10 lines are cut away by the homepage updating script. --> |
|
|
|
|
10 |
|
|
11 |
<!-- |
<!-- |
12 |
|
|
13 |
$Id: intro.html,v 1.30 2005/04/07 15:43:15 debug Exp $ |
$Id: intro.html,v 1.100 2006/11/04 06:40:20 debug Exp $ |
14 |
|
|
15 |
Copyright (C) 2003-2005 Anders Gavare. All rights reserved. |
Copyright (C) 2003-2006 Anders Gavare. All rights reserved. |
16 |
|
|
17 |
Redistribution and use in source and binary forms, with or without |
Redistribution and use in source and binary forms, with or without |
18 |
modification, are permitted provided that the following conditions are met: |
modification, are permitted provided that the following conditions are met: |
45 |
<h2>Introduction</h2> |
<h2>Introduction</h2> |
46 |
|
|
47 |
<p> |
<p> |
48 |
|
<table border="0" width="99%"><tr><td valign="top" align="left"> |
49 |
<ul> |
<ul> |
50 |
<li><a href="#overview">Overview</a> |
<li><a href="#overview">Overview</a> |
51 |
<li><a href="#free">Is GXemul free software?</a> |
<li><a href="#free">Is GXemul Free software?</a> |
52 |
<li><a href="#build">How to compile/build the emulator</a> |
<li><a href="#build">How to compile/build the emulator</a> |
53 |
<li><a href="#cpus">Which CPU types does GXemul emulate?</a> |
<li><a href="#run">How to run the emulator</a> |
54 |
|
<li><a href="#cpus">Which processor architectures does GXemul emulate?</a> |
55 |
|
<li><a href="#hosts">Which host architectures are supported?</a> |
56 |
|
<li><a href="#translation">What kind of translation does GXemul use?</a> |
57 |
<li><a href="#accuracy">Emulation accuracy</a> |
<li><a href="#accuracy">Emulation accuracy</a> |
58 |
<li><a href="#emulmodes">Which machines does GXemul emulate?</a> |
<li><a href="#emulmodes">Which machines does GXemul emulate?</a> |
|
<li><a href="#guestos">Which guest OSes are possible to run?</a> |
|
59 |
</ul> |
</ul> |
60 |
|
</td><td valign="center" align="center"> |
61 |
|
<a href="20050317-example.png"><img src="20050317-example_small.png"></a> |
62 |
|
<p>NetBSD/pmax 1.6.2 with X11<br>running in GXemul</td></tr></table> |
63 |
|
|
64 |
|
|
65 |
|
|
68 |
<a name="overview"></a> |
<a name="overview"></a> |
69 |
<h3>Overview:</h3> |
<h3>Overview:</h3> |
70 |
|
|
71 |
GXemul is a machine emulator, which can be used to experiment with |
GXemul is an experimental instruction-level machine emulator. Several |
72 |
binary code for (among others) MIPS-based machines. Several emulation |
emulation modes are available. In some modes, processors and surrounding |
|
modes are available. For some emulation modes, processors and surrounding |
|
73 |
hardware components are emulated well enough to let unmodified operating |
hardware components are emulated well enough to let unmodified operating |
74 |
systems run as if they were running on a real machine. |
systems (e.g. NetBSD) run as if they were running on a real machine. |
|
|
|
|
<p> |
|
|
It is important to keep in mind that devices and CPUs are not really |
|
|
emulated correctly, they are only "faked" well enough to make eg. NetBSD |
|
|
run. Still, the emulator could be of interest for academic research and |
|
|
experiments, such as when learning how to write an OS for a real machine, |
|
|
or profiling SMP, memory, or system call usage. |
|
|
|
|
|
<p> |
|
|
The emulator is written in C, does not depend on external libraries (except |
|
|
X11, but that is optional), and should compile and run on most Unix-like |
|
|
systems. If it doesn't, then that is a bug. |
|
75 |
|
|
76 |
<p> |
<p>Devices and processors are not simulated with 100% accuracy. They are |
77 |
The emulator contains code which tries to emulate the workings of CPUs and |
only ``faked'' well enough to allow guest operating systems to run without |
78 |
surrounding hardware found in real machines, but it does not contain any |
complaining too much. Still, the emulator could be of interest for |
79 |
ROM code. You will need some form of program (in binary form) to run in |
academic research and experiments, such as when learning how to write |
80 |
the emulator. For many emulation modes, PROM calls are handled by the |
operating system code. |
81 |
|
|
82 |
|
<p>The emulator is written in C, does not depend on third-party libraries, |
83 |
|
and should compile and run on most 64-bit and 32-bit Unix-like systems. |
84 |
|
|
85 |
|
<p>The emulator contains code which tries to emulate the workings of CPUs |
86 |
|
and surrounding hardware found in real machines, but it does not contain |
87 |
|
any ROM code. You will need some form of program (in binary form) to run |
88 |
|
in the emulator. For many emulation modes, PROM calls are handled by the |
89 |
emulator itself, so you do not need to use any ROM image at all. |
emulator itself, so you do not need to use any ROM image at all. |
90 |
|
|
91 |
<p> |
<p>You can use pre-compiled kernels (for example NetBSD kernels, or |
92 |
You can use pre-compiled kernels (for example NetBSD kernels, or Linux), |
Linux), or other programs that are in binary format, and in some cases |
93 |
or other programs that are in binary format, and in some cases even actual |
even actual ROM images. A couple of different file formats are supported |
94 |
ROM images. A couple of different file formats are supported (ELF, a.out, |
(ELF, a.out, ECOFF, SREC, and raw binaries). |
95 |
ECOFF, SREC, raw binaries). |
|
96 |
|
<p>If you do not have a kernel as a separate file, but you have a bootable |
97 |
|
disk image, then it is sometimes possible to boot directly from that |
98 |
|
image. (This works for example with DECstation emulation, or when booting |
99 |
|
from ISO9660 CDROM images.) |
100 |
|
|
101 |
|
<p>Thanks to (in no specific order) Joachim Buss, Olivier Houchard, Juli |
102 |
|
Mallett, Juan Romero Pardines, Alec Voropay, Göran Weinholt, Alexander |
103 |
|
Yurchenko, and everyone else who has provided me with feedback. |
104 |
|
|
105 |
|
|
|
<p> |
|
|
(You do not need any MIPS compiler toolchain to build or use GXemul. |
|
|
If you need to compile MIPS binaries from sources, then of course you need |
|
|
such a toolchain, but that is completely separate from GXemul. There |
|
|
is a <a href="technical.html#regtest">regression testing</a> framework, |
|
|
which requires that a GNU CC for mips64-unknown-elf or similar is available. |
|
|
For simply building and using the emulator, it is not required.) |
|
106 |
|
|
107 |
|
|
108 |
|
|
110 |
|
|
111 |
<p><br> |
<p><br> |
112 |
<a name="free"></a> |
<a name="free"></a> |
113 |
<h3>Is GXemul free software?</h3> |
<h3>Is GXemul Free software?</h3> |
|
|
|
|
Yes. I have released GXemul under a free license. |
|
|
(For a definitions of the four freedoms associated with free software, |
|
|
please read <a href="http://www.gnu.org/philosophy/free-sw.html"> |
|
|
http://www.gnu.org/philosophy/free-sw.html</a>.) |
|
|
|
|
|
<p> |
|
|
The code I have written is released under a 3-clause BSD-style license |
|
|
(or "revised BSD-style" if one wants to use |
|
|
<a href="http://www.gnu.org/philosophy/bsd.html">GNU jargon</a>.) |
|
|
Apart from the code I have written, some files are copied from other sources |
|
|
such as NetBSD, for example header files containing symbolic names of |
|
|
bitfields in device registers. They are also covered by similar licenses, |
|
|
but with some additional clauses. If you plan to redistribute GXemul |
|
|
(for example as a binary package), or reuse code from GXemul, |
|
|
then you should check those files for their license terms. |
|
114 |
|
|
115 |
<p> |
Yes. I have released GXemul under a Free license. The code in GXemul is |
116 |
(The licenses usually require that the original Copyright and license |
Copyrighted software, it is <i>not</i> public domain. (If this is |
117 |
terms are included when you make a copy or modification. The "easiest way |
confusing to you, you might want to read up on the definitions of the |
118 |
out" if you plan to redistribute code from GXemul is to simply supply |
four freedoms associated with Free software, <a |
119 |
the source code. You should however check individual files for details.) |
href="http://www.gnu.org/philosophy/free-sw.html">http://www.gnu.org/philosophy/free-sw.html</a>.) |
120 |
|
|
121 |
|
<p>The code I have written is released under a 3-clause BSD-style license |
122 |
|
(or "revised BSD-style" if one wants to use <a |
123 |
|
href="http://www.gnu.org/philosophy/bsd.html">GNU jargon</a>). Apart from |
124 |
|
the code I have written, some files are copied from other sources such as |
125 |
|
NetBSD, for example header files containing symbolic names of bitfields in |
126 |
|
device registers. They are also covered by similar licenses, but with some |
127 |
|
additional clauses. The main point, however, is that the licenses require |
128 |
|
that the original Copyright and license terms are included when you make a |
129 |
|
copy or modification. |
130 |
|
|
131 |
|
<p>If you plan to redistribute GXemul <i>without</i> supplying the source |
132 |
|
code, then you need to comply with each individual source file some other |
133 |
|
way, for example by writing additional documentation containing copyright |
134 |
|
notes. I have not done this, since I do not plan on making distributions |
135 |
|
without source code. You need to check all individual files for details. |
136 |
|
The "easiest way out" if you plan to redistribute code from GXemul is, of |
137 |
|
course, to let it remain open source and simply supply the source code. |
138 |
|
|
139 |
|
<p>In case you want to reuse parts of GXemul, but you need to do that |
140 |
|
under a different license (e.g. the GPL), then contact me and I might |
141 |
|
re-license/dual-license files on a case-by-case basis. |
142 |
|
|
143 |
|
|
144 |
|
|
154 |
$ <b>make</b> |
$ <b>make</b> |
155 |
</pre> |
</pre> |
156 |
|
|
157 |
<p> |
<p>This should work on most Unix-like systems. GXemul does not require any |
158 |
This should work on most Unix-like systems. If it doesn't, then please |
specific libraries to build, however, if you build on a system which does |
159 |
mail me a bug report. |
not have X11 libraries installed, some functionality will be lost. |
160 |
|
|
161 |
<p> |
<p>The emulator's performance is highly dependent on both runtime settings |
|
(Note for Windows users: there is a possibility that some releases |
|
|
and/or snapshots will also work with Cygwin, but I can't promise that.) |
|
|
|
|
|
<p> |
|
|
The emulator's performance is highly dependent on both runtime settings |
|
162 |
and on compiler settings, so you might want to experiment with different |
and on compiler settings, so you might want to experiment with different |
163 |
CC and CFLAGS environment variable values. For example, on a modern PC, |
CC and CFLAGS environment variable values. For example, on an AMD Athlon |
164 |
you could try the following: |
host, you might want to try setting <tt>CFLAGS</tt> to <tt>-march=athlon</tt> |
165 |
<p> |
before running <tt>configure</tt>. |
166 |
<pre> |
|
167 |
$ <b>CFLAGS="-mcpu=pentium4 -O3" ./configure</b> |
|
168 |
$ <b>make</b> |
|
169 |
</pre> |
|
170 |
|
|
171 |
|
|
172 |
|
|
173 |
|
<p><br> |
174 |
|
<a name="run"></a> |
175 |
|
<h3>How to run the emulator:</h3> |
176 |
|
|
177 |
|
Once you have built GXemul, running it should be rather straight-forward. |
178 |
|
Running <tt><b>gxemul</b></tt> without arguments (or with the |
179 |
|
<b><tt>-h</tt></b> or <b><tt>-H</tt></b> command line options) will |
180 |
|
display a help message. |
181 |
|
|
182 |
<p> |
<p> |
183 |
Run <b>./configure --help</b> to get a list of configure options. (The |
To get some ideas about what is possible to run in the emulator, please |
184 |
possible options differ between different releases and snapshots.) |
read the section about <a href="guestoses.html">installing "guest" |
185 |
|
operating systems</a>. If you are interested in using the emulator to |
186 |
|
develop code on your own, then you should also read the section about |
187 |
|
<a href="experiments.html#hello">Hello World</a>. |
188 |
|
|
189 |
<p> |
<p> |
|
Once you have built GXemul, running it should be rather straight-forward. |
|
190 |
To exit the emulator, type CTRL-C to enter the |
To exit the emulator, type CTRL-C to enter the |
191 |
single-step debugger, and then type <b>quit</b>. By typing CTRL-B instead, |
single-step debugger, and then type <tt><b>quit</b></tt>. |
|
a CTRL-C is sent to the emulated program. |
|
192 |
|
|
193 |
|
<p> |
194 |
|
If you are starting an emulation by entering settings directly on the |
195 |
|
command line, and you are not using the <tt><b>-x</b></tt> option, then all |
196 |
|
terminal input and output will go to the main controlling terminal. |
197 |
|
CTRL-C is used to break into the debugger, so in order to send CTRL-C to |
198 |
|
the running (emulated) program, you may use CTRL-B. |
199 |
|
(This should be a reasonable compromise to allow the emulator to be usable |
200 |
|
even on systems without X Windows.) |
201 |
|
|
202 |
|
<p> |
203 |
|
There is no way to send an actual CTRL-B to the emulated program, when |
204 |
|
typing in the main controlling terminal window. The solution is to either |
205 |
|
use <a href="configfiles.html">configuration files</a>, or use |
206 |
|
<tt><b>-x</b></tt>. Both these solutions cause new xterms to be opened for |
207 |
|
each emulated serial port that is written to. CTRL-B and CTRL-C both have |
208 |
|
their original meaning in those xterm windows. |
209 |
|
|
210 |
|
|
211 |
|
|
213 |
|
|
214 |
<p><br> |
<p><br> |
215 |
<a name="cpus"></a> |
<a name="cpus"></a> |
216 |
<h3>Which CPU types does GXemul emulate?</h3> |
<h3>Which processor architectures does GXemul emulate?</h3> |
217 |
|
|
218 |
|
The architectures that are emulated well enough to let at least one |
219 |
|
guest operating system run (per architecture) are ARM, MIPS, PowerPC, |
220 |
|
and SuperH. |
221 |
|
|
222 |
|
|
223 |
|
|
|
<h4>MIPS:</h4> |
|
224 |
|
|
|
Emulation of R4000, which is a 64-bit CPU, was my initial goal. Right |
|
|
now, R2000/R3000-like CPUs are also emulated (32-bit), and emulation of |
|
|
R1x000 (at least the parts that are similar to R4000) is beginning to work |
|
|
as expected. Code targeted for MIPS32 and MIPS64 also often work. |
|
225 |
|
|
226 |
<p> |
|
227 |
I have written an experimental dynamic binary translation subsystem. |
<p><br> |
228 |
This gives higher total performance than interpreting one instruction at a |
<a name="hosts"></a> |
229 |
time and executing it. (If you wish to enable bintrans, add <b>-b</b> to |
<h3>Which host architectures are supported?</h3> |
230 |
the command line, but keep in mind that it is still experimental.) |
|
231 |
|
GXemul should compile and run on any modern host architecture (64-bit or |
232 |
|
32-bit word-length). |
233 |
|
|
234 |
|
<p>(The dynamic translation engine translates into an intermediate |
235 |
|
representation, but not currently into native code. This means that there |
236 |
|
is no need for per-host architecture backend code.) |
237 |
|
|
238 |
|
|
239 |
|
|
240 |
|
|
|
<h4>URISC:</h4> |
|
241 |
|
|
242 |
I have implemented an <a href="http://en.wikipedia.org/wiki/URISC">URISC</a> |
<p><br> |
243 |
emulation mode, just for fun. The only instruction available in an URISC |
<a name="translation"></a> |
244 |
machine is "reverse subtract and skip on borrow". (It is probably not |
<h3>What kind of translation does GXemul use?</h3> |
|
worth trying to do bintrans with URISC, because any reasonable URISC |
|
|
program relies on self-modifying code, which is bad for bintrans |
|
|
performance.) |
|
245 |
|
|
246 |
|
<b>Static vs. dynamic:</b> |
247 |
|
|
248 |
|
<p>In order to support guest operating systems, which can overwrite old |
249 |
|
code pages in memory with new code, it is necessary to translate code |
250 |
|
dynamically. It is not possible to do a "one-pass" (static) translation. |
251 |
|
Self-modifying code and Just-in-Time compilers running inside |
252 |
|
the emulator are other things that would not work with a static |
253 |
|
translator. GXemul is a dynamic translator. However, it does not |
254 |
|
necessarily translate into native code, like many other emulators. |
255 |
|
|
256 |
|
<p><b>"Runnable" Intermediate Representation:</b> |
257 |
|
|
258 |
|
<p>Dynamic translators usually translate from the emulated architecture |
259 |
|
(e.g. MIPS) into a kind of <i>intermediate representation</i> (IR), and then |
260 |
|
to native code (e.g. AMD64 or x86 code). Since one of my main goals for |
261 |
|
GXemul is to keep everything as portable as possible, I have tried to make |
262 |
|
sure that the IR is something which can be executed regardless of whether |
263 |
|
the final step (translation from IR to native code) has been implemented |
264 |
|
or not. |
265 |
|
|
266 |
|
<p>The IR in GXemul consists of arrays of pointers to functions, and a few |
267 |
|
arguments which are passed along to those functions. The functions are |
268 |
|
implemented in either manually hand-coded C, or automatically generated C. |
269 |
|
In any case, this is all statically linked into the GXemul binary at link |
270 |
|
time. |
271 |
|
|
272 |
|
<p>Here is a simplified diagram of how these arrays work. |
273 |
|
|
274 |
|
<p><center><img src="simplified_dyntrans.png"></center> |
275 |
|
|
276 |
|
<p>There is one instruction call slot for every possible program counter |
277 |
|
location. In the MIPS case, instruction words are 32 bits in length, |
278 |
|
and pages are (usually) 4 KB large, resulting in 1024 instruction call |
279 |
|
slots. After the last of these instruction calls, there is an additional |
280 |
|
call to a special "end of page" function (which doesn't count as an executed |
281 |
|
instruction). This function switches to the first instruction |
282 |
|
on the next virtual page (which might cause exceptions, etc). |
283 |
|
|
284 |
|
<p>The complexity of individual instructions vary. A simple example of |
285 |
|
what an instruction can look like is the MIPS <tt>addiu</tt> instruction: |
286 |
|
<pre> |
287 |
|
X(addiu) |
288 |
|
{ |
289 |
|
reg(ic->arg[1]) = (int32_t) |
290 |
|
((int32_t)reg(ic->arg[0]) + (int32_t)ic->arg[2]); |
291 |
|
} |
292 |
|
</pre> |
293 |
|
|
294 |
|
<p>It stores the result of a 32-bit addition of the register at arg[0] |
295 |
|
with the immediate value arg[2] (treating both as signed 32-bit |
296 |
|
integers) into register arg[1]. If the emulated CPU is a 64-bit CPU, |
297 |
|
then this will store a correctly sign-extended value into arg[1]. |
298 |
|
If it is a 32-bit CPU, then only the lowest 32 bits will be stored, |
299 |
|
and the high part ignored. <tt>X(addiu)</tt> is expanded to |
300 |
|
<tt>mips_instr_addiu</tt> in the 64-bit case, and <tt>mips32_instr_addiu</tt> |
301 |
|
in the 32-bit case. Both are compiled into the GXemul executable; no code |
302 |
|
is created during run-time. |
303 |
|
|
304 |
|
<p>Here are examples of what the <tt>addiu</tt> instruction actually |
305 |
|
looks like when it is compiled, on various host architectures: |
306 |
|
|
307 |
|
<p><center><table border="0"> |
308 |
|
<tr><td><b>GCC 4.0.1 on Alpha:</b></td> |
309 |
|
<td width="35"></td><td></td> |
310 |
|
<tr> |
311 |
|
<td valign="top"> |
312 |
|
<pre>mips_instr_addiu: |
313 |
|
ldq t1,8(a1) |
314 |
|
ldq t2,24(a1) |
315 |
|
ldq t3,16(a1) |
316 |
|
ldq t0,0(t1) |
317 |
|
addl t0,t2,t0 |
318 |
|
stq t0,0(t3) |
319 |
|
ret</pre> |
320 |
|
</td> |
321 |
|
<td></td> |
322 |
|
<td valign="top"> |
323 |
|
<pre>mips32_instr_addiu: |
324 |
|
ldq t2,8(a1) |
325 |
|
ldq t0,24(a1) |
326 |
|
ldq t3,16(a1) |
327 |
|
ldl t1,0(t2) |
328 |
|
addq t0,t1,t0 |
329 |
|
stl t0,0(t3) |
330 |
|
ret</pre> |
331 |
|
</td> |
332 |
|
</tr> |
333 |
|
|
334 |
|
<tr><td><b><br>GCC 3.4.4 on AMD64:</b></td> |
335 |
|
<tr> |
336 |
|
<td valign="top"> |
337 |
|
<pre>mips_instr_addiu: |
338 |
|
mov 0x8(%rsi),%rdx |
339 |
|
mov 0x18(%rsi),%rax |
340 |
|
mov 0x10(%rsi),%rcx |
341 |
|
add (%rdx),%eax |
342 |
|
cltq |
343 |
|
mov %rax,(%rcx) |
344 |
|
retq</pre> |
345 |
|
</td> |
346 |
|
<td></td> |
347 |
|
<td valign="top"> |
348 |
|
<pre>mips32_instr_addiu: |
349 |
|
mov 0x8(%rsi),%rcx |
350 |
|
mov 0x10(%rsi),%rdx |
351 |
|
mov (%rcx),%eax |
352 |
|
add 0x18(%rsi),%eax |
353 |
|
mov %eax,(%rdx) |
354 |
|
retq</pre> |
355 |
|
</td> |
356 |
|
</tr> |
357 |
|
|
358 |
|
<tr><td><b><br>GCC 4.0.1 on i386:</b></td> |
359 |
|
<tr> |
360 |
|
<td valign="top"> |
361 |
|
<pre>mips_instr_addiu: |
362 |
|
mov 0x8(%esp),%eax |
363 |
|
mov 0x8(%eax),%ecx |
364 |
|
mov 0x4(%eax),%edx |
365 |
|
mov 0xc(%eax),%eax |
366 |
|
add (%edx),%eax |
367 |
|
mov %eax,(%ecx) |
368 |
|
cltd |
369 |
|
mov %edx,0x4(%ecx) |
370 |
|
ret</pre> |
371 |
|
</td> |
372 |
|
<td></td> |
373 |
|
<td valign="top"> |
374 |
|
<pre>mips32_instr_addiu: |
375 |
|
mov 0x8(%esp),%eax |
376 |
|
mov 0x8(%eax),%ecx |
377 |
|
mov 0x4(%eax),%edx |
378 |
|
mov 0xc(%eax),%eax |
379 |
|
add (%edx),%eax |
380 |
|
mov %eax,(%ecx) |
381 |
|
ret</pre> |
382 |
|
</td> |
383 |
|
</tr> |
384 |
|
</table></center> |
385 |
|
|
386 |
|
<p>On 64-bit hosts, there is not much difference, but on 32-bit hosts (and |
387 |
|
to some extent on AMD64), the difference is enough to make it worthwhile. |
388 |
|
|
389 |
|
|
390 |
|
<p><b>Performance:</b> |
391 |
|
|
392 |
|
<p>The performance of using this kind of runnable IR is obviously lower |
393 |
|
than what can be achieved by emulators using native code generation, but |
394 |
|
can be significantly higher than using a naive fetch-decode-execute |
395 |
|
interpretation loop. In my opinion, using a runnable IR is an interesting |
396 |
|
compromise. |
397 |
|
|
398 |
|
<p>The overhead per emulated instruction is usually around or below |
399 |
|
approximately 10 host instructions. This is very much dependent on your |
400 |
|
host architecture and what compiler and compiler switches you are using. |
401 |
|
Added to this instruction count is (of course) also the C code used to |
402 |
|
implement each specific instruction. |
403 |
|
|
404 |
|
<p><b>Instruction Combinations:</b> |
405 |
|
|
406 |
|
<p>Short, common instruction sequences can sometimes be replaced by a |
407 |
|
"compound" instruction. An example could be a compare instruction followed |
408 |
|
by a conditional branch instruction. The advantages of instruction |
409 |
|
combinations are that |
410 |
|
<ul> |
411 |
|
<li>the amortized overhead per instruction is slightly reduced, and |
412 |
|
<p> |
413 |
|
<li>the host's compiler can make a good job at optimizing the common |
414 |
|
instruction sequence. |
415 |
|
</ul> |
416 |
|
|
417 |
<h4>Other CPU types:</h4> |
<p>The special cases where instruction combinations give the most gain |
418 |
|
are in the cores of string/memory manipulation functions such as |
419 |
|
<tt>memset()</tt> or <tt>strlen()</tt>. The core loop can then (at least |
420 |
|
to some extent) be replaced by a native call to the equivalent function. |
421 |
|
|
422 |
|
<p>The implementations of compound instructions still keep track of the |
423 |
|
number of executed instructions, etc. When single-stepping, these |
424 |
|
translations are invalidated, and replaced by normal instruction calls |
425 |
|
(one per emulated instruction). |
426 |
|
|
427 |
|
<p><b>Native Code Back-ends: (not in this release)</b> |
428 |
|
|
429 |
|
<p>In theory, it will be possible to implement native code generation |
430 |
|
(similar to what is used in high-performance emulators such as QEMU), |
431 |
|
as long as that generated code abides to the C ABI on the host, but |
432 |
|
for now I wanted to make sure that GXemul works without such native |
433 |
|
code back-ends. For this reason, since release 0.4.0, GXemul is |
434 |
|
completely free of native code back-ends. |
435 |
|
|
|
There is some code for 64-bit (and 32-bit) POWER/PowerPC emulation too, |
|
|
but it only works for "Hello World" and similarly trivial programs. (There |
|
|
are some other CPU modes too, but they are working even less.) |
|
436 |
|
|
437 |
|
|
438 |
|
|
442 |
<a name="accuracy"></a> |
<a name="accuracy"></a> |
443 |
<h3>Emulation accuracy:</h3> |
<h3>Emulation accuracy:</h3> |
444 |
|
|
445 |
GXemul is an instruction-level simulator; things that would happen in |
GXemul is an instruction-level emulator; things that would happen in |
446 |
several steps within a real CPU are not taken into account (eg. pipe-line |
several steps within a real CPU are not taken into account (e.g. pipe-line |
447 |
stages or out-of-order execution). Still, instruction-level accuracy seems |
stalls or out-of-order execution). Still, instruction-level accuracy seems |
448 |
to be enough to be able to run complete guest operating systems inside the |
to be enough to be able to run complete guest operating systems inside the |
449 |
emulator. |
emulator. |
450 |
|
|
451 |
|
<p>The existance of instruction and data caches is "faked" to let |
452 |
|
operating systems think that they are there, but for all practical |
453 |
|
purposes, these caches are non-working. |
454 |
|
|
455 |
|
<p>The emulator is in general <i>not</i> timing-accurate, neither at the |
456 |
|
instruction level nor on any higher level. An attempt is made to let |
457 |
|
emulated clocks run at the same speed as the host (i.e. an emulated timer |
458 |
|
running at 100 Hz will interrupt around 100 times per real second), but |
459 |
|
since the host speed may vary, e.g. because of other running processes, |
460 |
|
there is no guarantee as to how many instructions will be executed in |
461 |
|
each of these 100 Hz cycles. |
462 |
|
|
463 |
|
<p>If the host is very slow, the emulated clocks might even lag behind |
464 |
|
the real-world clock. |
465 |
|
|
466 |
|
|
467 |
|
|
468 |
|
|
469 |
|
|
472 |
<a name="emulmodes"></a> |
<a name="emulmodes"></a> |
473 |
<h3>Which machines does GXemul emulate?</h3> |
<h3>Which machines does GXemul emulate?</h3> |
474 |
|
|
475 |
A few different machine types are emulated. The machine types that are |
A few different machine types are emulated. The following machine types |
476 |
emulated best at the moment are: |
are emulated well enough to run at least one "guest OS": |
477 |
|
|
478 |
<p> |
<p> |
479 |
<ul> |
<ul> |
480 |
<li><b>DECstation 5000/200</b> ("pmax") |
<li><b><u>ARM</u></b> |
481 |
<br>(Serial controller (including keyboard and mouse), ethernet, |
<ul> |
482 |
SCSI, and graphical framebuffers.) |
<li><b>CATS</b> (<a href="guestoses.html#netbsdcatsinstall">NetBSD/cats</a>, |
483 |
|
<a href="guestoses.html#openbsdcatsinstall">OpenBSD/cats</a>) |
484 |
|
<li><b>IQ80321</b> (<a href="guestoses.html#netbsdevbarminstall">NetBSD/evbarm</a>) |
485 |
|
<li><b>NetWinder</b> (<a href="guestoses.html#netbsdnetwinderinstall">NetBSD/netwinder</a>) |
486 |
|
</ul> |
487 |
<p> |
<p> |
488 |
<li><b>Acer Pica-61</b> (an ARC machine) |
<li><b><u>MIPS</u></b> |
489 |
<br>(Serial controller, "VGA" text console, and SCSI.) |
<ul> |
490 |
|
<li><b>DECstation 5000/200</b> (<a href="guestoses.html#netbsdpmaxinstall">NetBSD/pmax</a>, |
491 |
|
<a href="guestoses.html#openbsdpmaxinstall">OpenBSD/pmax</a>, |
492 |
|
<a href="guestoses.html#ultrixinstall">Ultrix</a>, |
493 |
|
<a href="guestoses.html#declinux">Linux/DECstation</a>, |
494 |
|
<a href="guestoses.html#sprite">Sprite</a>) |
495 |
|
<li><b>Acer Pica-61</b> (<a href="guestoses.html#netbsdarcinstall">NetBSD/arc</a>) |
496 |
|
<li><b>NEC MobilePro 770, 780, 800, 880</b> (<a href="guestoses.html#netbsdhpcmipsinstall">NetBSD/hpcmips</a>) |
497 |
|
<li><b>Cobalt</b> (<a href="guestoses.html#netbsdcobaltinstall">NetBSD/cobalt</a>) |
498 |
|
<li><b>Malta</b> (<a href="guestoses.html#netbsdevbmipsinstall">NetBSD/evbmips</a>) |
499 |
|
<li><b>Algorithmics P5064</b> (<a href="guestoses.html#netbsdalgorinstall">NetBSD/algor</a>) |
500 |
|
<li><b>SGI O2 (aka IP32)</b> <font color="#0000e0">(<super>*1</super>)</font> |
501 |
|
(<a href="guestoses.html#netbsdsgimips">NetBSD/sgi</a>) |
502 |
|
</ul> |
503 |
<p> |
<p> |
504 |
<li><b>NEC MobilePro 770, 780, 800, and 880</b> (HPCmips machines) |
<li><b><u>PowerPC</u></b> |
505 |
<br>(Framebuffer, keyboard, and a PCMCIA IDE controller.) |
<ul> |
506 |
|
<li><b>IBM 6050/6070 (PReP, PowerPC Reference Platform)</b> (<a href="guestoses.html#netbsdprepinstall">NetBSD/prep</a>) |
507 |
|
</ul> |
508 |
|
<p> |
509 |
|
<li><b><u>SuperH</u></b> |
510 |
|
<ul> |
511 |
|
<li><b>Sega Dreamcast</b> |
512 |
|
<font color="#0000e0">(<super>*2</super>)</font> |
513 |
|
(<a href="guestoses.html#netbsddreamcast">NetBSD/dreamcast</a>) |
514 |
|
</ul> |
515 |
</ul> |
</ul> |
516 |
|
|
517 |
<p> |
<p> |
518 |
There is code in GXemul for emulation of many other machine types; |
<small><font color="#0000e0">(<super>*1</super>)</font> = |
519 |
the degree to which these work range from "almost" being able to run |
Enough for root-on-nfs, but not for disk boot.</small> |
520 |
a complete OS, to almost completely unsupported (perhaps just enough |
<br><small><font color="#0000e0">(<super>*2</super>)</font> = |
521 |
support to output a few boot messages via serial console). |
Only enough to reach ramdisk userland; no root-on-nfs yet.</small> |
522 |
|
|
523 |
<p> |
<p>There is code in GXemul for emulation of many other machine types; the |
524 |
In addition to specific machine types, a "test-machine" can be emulated. |
degree to which these work range from almost being able to run a complete |
525 |
A test-machine consists of one or more CPUs and a few experimental |
OS, to almost completely unsupported (perhaps just enough support to |
526 |
devices such as: |
output a few boot messages via serial console). |
527 |
|
|
528 |
|
<p>In addition to emulating real machines, there is also a "test-machine". |
529 |
|
A test-machine consists of one or more CPUs and a few experimental devices |
530 |
|
such as: |
531 |
|
|
532 |
<p> |
<p> |
533 |
<ul> |
<ul> |
534 |
<li>a console I/O device (putchar() and getchar()...) |
<li>a console I/O device (putchar() and getchar()...) |
535 |
<li>an inter-processor communication device, for SMP experiments |
<li>an inter-processor communication device, for SMP experiments |
536 |
<li>a very simple linear framebuffer device (for graphics output) |
<li>a very simple linear framebuffer device (for graphics output) |
537 |
|
<li>a simple disk controller |
538 |
|
<li>a simple ethernet controller |
539 |
|
<li>a real-time clock device |
540 |
</ul> |
</ul> |
541 |
|
|
542 |
<p> |
<p>This mode is useful if you wish to run experimental code, but do not |
|
This mode is useful if you wish to run experimental code, but do not |
|
543 |
wish to target any specific real-world machine type, for example for |
wish to target any specific real-world machine type, for example for |
544 |
educational purposes. |
educational purposes. |
545 |
|
|
546 |
<p> |
<p>You can read more about these experimental devices <a |
547 |
You can read more about these experimental devices |
href="experiments.html#expdevices">here</a>. |
|
<a href="experiments.html#expdevices">here</a>. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<p><br> |
|
|
<a name="guestos"></a> |
|
|
<h3>Which guest OSes are possible to run?</h3> |
|
|
|
|
|
This table sums up the guest OSes that run well enough to be considered |
|
|
working in the emulator. They can boot from a harddisk image and be |
|
|
interacted with similar to a real machine: |
|
|
|
|
|
<p><br> |
|
|
<center> |
|
|
<table border="0"> |
|
|
<tr><td> |
|
|
<table border="0"> |
|
|
<tr><td align="center"> |
|
|
<table border="0"> |
|
|
<tr> |
|
|
<td valign="top"><b><u>Guest OS:</u></b></td> |
|
|
<td width="15"> </td> |
|
|
<td valign="top"><b><u>Emulation mode:</u></b></td> |
|
|
<td width="35"> </td> |
|
|
<td valign="top"><b><u>Guest OS:</u></b></td> |
|
|
<td width="15"> </td> |
|
|
<td valign="top"><b><u>Emulation mode:</u></b></td> |
|
|
</tr> |
|
|
|
|
|
<tr> |
|
|
<td height="1"></td> |
|
|
</tr> |
|
|
|
|
|
<tr> |
|
|
<td valign="top"><a href="http://www.netbsd.org/Ports/pmax/">NetBSD/pmax</a></td> |
|
|
<td></td> |
|
|
<td valign="top">DECstation</td> |
|
|
<td></td> |
|
|
<td valign="top"><a href="http://www.netbsd.org/Ports/arc/">NetBSD/arc</a></td> |
|
|
<td></td> |
|
|
<td valign="top">ARC (Acer Pica)</td> |
|
|
</tr> |
|
|
|
|
|
<tr> |
|
|
<td valign="top"><a href="http://www.openbsd.org/pmax.html">OpenBSD/pmax</a></td> |
|
|
<td></td> |
|
|
<td valign="top">DECstation</td> |
|
|
<td></td> |
|
|
<td valign="top"><a href="http://www.openbsd.org/arc.html">OpenBSD/arc</a></td> |
|
|
<td></td> |
|
|
<td valign="top">ARC (Acer Pica)</td> |
|
|
</tr> |
|
|
|
|
|
<tr> |
|
|
<td valign="top">Ultrix/RISC</td> |
|
|
<td></td> |
|
|
<td valign="top">DECstation</td> |
|
|
<td></td> |
|
|
<td valign="top"><a href="http://www.cs.berkeley.edu/projects/sprite/retrospective.html">Sprite</a></td> |
|
|
<td></td> |
|
|
<td valign="top">DECstation</td> |
|
|
</tr> |
|
|
|
|
|
<tr> |
|
|
<td valign="top">Redhat Linux<super>*</super></td> |
|
|
<td></td> |
|
|
<td valign="top">DECstation</td> |
|
|
<td></td> |
|
|
<td valign="top"><a href="http://www.debian.org/">Debian GNU/Linux</a><super>*</super></td> |
|
|
<td></td> |
|
|
<td valign="top">DECstation</td> |
|
|
</tr> |
|
|
|
|
|
<tr> |
|
|
<td valign="top"><a href="http://www.netbsd.org/Ports/hpcmips/">NetBSD/hpcmips</a></td> |
|
|
<td></td> |
|
|
<td valign="top">NEC MobilePro</td> |
|
|
</tr> |
|
|
</table> |
|
|
</td></tr> |
|
|
|
|
|
<tr><td height="15"> </td></tr> |
|
|
|
|
|
<tr><td> |
|
|
<center> |
|
|
<table border="0"> |
|
|
<tr> |
|
|
<td width=160 align=center><a href="netbsd-pmax-20040630.png"><img src="netbsd-pmax-20040630_small.png"></a></td> |
|
|
<td width=160 align=center><a href="openbsd-pmax-20040710.png"><img src="openbsd-pmax-20040710_small.png"></a></td> |
|
|
<td width=160 align=center><a href="ultrix4.5-20040706.png"><img src="ultrix4.5-20040706_small.gif"></a></td> |
|
|
</tr> |
|
|
<tr> |
|
|
<td align=center>NetBSD/pmax 1.6.2</td> |
|
|
<td align=center>OpenBSD/pmax 2.8</td> |
|
|
<td align=center>Ultrix 4.5</td> |
|
|
</tr> |
|
|
<tr> |
|
|
<td height=10> </td> |
|
|
</tr> |
|
|
<tr> |
|
|
<td width=160 align=center><a href="20041024-netbsd-arc-installed.gif"><img src="20041024-netbsd-arc-installed_small.gif"></a></td> |
|
|
<td width=160 align=center><a href="20041024-openbsd-arc-installed.gif"><img src="20041024-openbsd-arc-installed_small.gif"></a></td> |
|
|
<td width=160 align=center><a href="sprite-20040711.png"><img src="sprite-20040711_small.png"></a></td> |
|
|
</tr> |
|
|
<tr> |
|
|
<td align=center>NetBSD/arc 1.6.2</td> |
|
|
<td align=center>OpenBSD/arc 2.3</td> |
|
|
<td align=center>Sprite</td> |
|
|
</tr> |
|
|
<tr> |
|
|
<td height=10> </td> |
|
|
</tr> |
|
|
<tr> |
|
|
<td width=160 align=center><a href="20041129-redhat_mips.png"><img src="20041129-redhat_mips_small.png"></a></td> |
|
|
<td width=160 align=center><a href="20041213-debian_4.png"><img src="20041213-debian_4_small.gif"></a></td> |
|
|
<td width=160 align=center><a href="20050331-netbsd-hpcmips.png"><img src="20050331-netbsd-hpcmips_small.png"></a></td> |
|
|
</tr> |
|
|
<tr> |
|
|
<td align=center>Redhat Linux<super>*</super></td> |
|
|
<td align=center>Debian GNU/Linux<super>*</super></td> |
|
|
<td align=center>NetBSD/hpcmips</td> |
|
|
</tr> |
|
|
</table> |
|
|
</center> |
|
|
</td></tr> |
|
|
</table> |
|
|
</td></tr> |
|
|
</table> |
|
|
</center> |
|
|
|
|
|
<p><br> |
|
|
|
|
|
(<super>*</super> Although Linux runs under DECstation emulation, the |
|
|
default kernel in Debian GNU/Linux does not support keyboards on the 5000/200 |
|
|
(the specific DECstation model being emulated), so when the login prompt |
|
|
is reached you cannot interact with the system. |
|
|
Kaj-Michael Lang has compiled and made available a newer kernel from the |
|
|
current mips-linux development tree. You can find it here: |
|
|
<a href="http://home.tal.org/~milang/o2/kernels/">http://home.tal.org/~milang/o2/kernels</a>/<a href="http://home.tal.org/~milang/o2/kernels/vmlinux-2.4.29-rc2-r3k-mipsel-decstation">vmlinux-2.4.29-rc2-r3k-mipsel-decstation</a> |
|
|
This newer kernel supports keyboard input, but it does not have Debian's |
|
|
ethernet patches, so you will not be able to use keyboard/framebuffer |
|
|
<i>and</i> networking at the same time.) |
|
|
|
|
|
|
|
|
<p> |
|
|
It is non-trivial to get a specific operating system or OS kernel to |
|
|
run in the emulator, so don't expect the list above to grow too quickly. |
|
|
|
|
|
<p> |
|
|
There is no guarantee that anything specific will run in the emulator, but |
|
|
NetBSD is a good starting point for someone who wants to experiment. |
|
548 |
|
|
549 |
|
|
550 |
|
|
551 |
|
|
552 |
|
|
|
</p> |
|
553 |
|
|
554 |
</body> |
</body> |
555 |
</html> |
</html> |