/[gxemul]/trunk/doc/intro.html
This is repository of my old source code which isn't updated any more. Go to git.rot13.org for current projects!
ViewVC logotype

Contents of /trunk/doc/intro.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 36 - (show annotations)
Mon Oct 8 16:21:34 2007 UTC (13 years, 1 month ago) by dpavlin
File MIME type: text/html
File size: 21503 byte(s)
++ trunk/HISTORY	(local)
$Id: HISTORY,v 1.1497 2007/03/18 03:41:36 debug Exp $
20070224	Minor update to the initialization of the ns16550 in
		machine_walnut.c, to allow that machine type to boot with the
		new interrupt system (although it is still a dummy machine).
		Adding a wdc at 0x14000000 to machine_landisk.c, and fixing
		the SCIF serial interrupts of the SH4 cpu enough to get
		NetBSD/landisk booting from a disk image :-)  Adding a
		preliminary install instruction skeleton to guestoses.html.
20070306	Adding SH-IPL+G PROM emulation, and also passing the "end"
		symbol in r5 on bootup, for Landisk emulation. This is enough
		to get OpenBSD/landisk to install :)  Adding a preliminary
		install instruction skeleton to the documentation. SuperH
		emulation is still shaky, though :-/
20070307	Fixed a strangeness in memory_sh.c (read/write was never
		returned for any page). (Unknown whether this fixes any actual
		problems, though.)
20070308	dev_ram.c fix: invalidate code translations on writes to
		RAM, emulated as separate devices. Linux/dreamcast gets
		further in the boot process than before, but still bugs out
		in userland.
		Fixing bugs in the "stc.l gbr,@-rN" and "ldc.l @rN+,gbr" SuperH 
		instructions (they should NOT check the MD bit), allowing the
		Linux/dreamcast Live CD to reach userland correctly :-)
20070310	Changing the cpu name "Alpha" in src/useremul.c to "21364" to
		unbreak userland syscall emulation of FreeBSD/Alpha binaries.
20070314	Applying a patch from Michael Yaroslavtsev which fixes the
		previous Linux lib64 patch to the configure script.
20070315	Adding a (dummy) sun4v machine type, and SPARC T1 cpu type.
20070316	Creating a new directory, src/disk, and moving diskimage.c
		to it. Separating out bootblock loading stuff from emul.c into
		new files in src/disk.
		Adding some more SPARC registers.
20070318	Preparing/testing for a minirelease, 0.4.4.1.

==============  RELEASE 0.4.4.1  ==============


1 <html><head><title>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;Introduction</title>
2 <meta name="robots" content="noarchive,nofollow,noindex"></head>
3 <body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000">
4 <table border=0 width=100% bgcolor="#d0d0d0"><tr>
5 <td width=100% align=center valign=center><table border=0 width=100%><tr>
6 <td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6">
7 <b>Gavare's eXperimental Emulator:</b></font><br>
8 <font color="#000000" size="6"><b>Introduction</b>
9 </font></td></tr></table></td></tr></table><p>
10
11 <!--
12
13 $Id: intro.html,v 1.107 2007/03/08 19:04:09 debug Exp $
14
15 Copyright (C) 2003-2007 Anders Gavare. All rights reserved.
16
17 Redistribution and use in source and binary forms, with or without
18 modification, are permitted provided that the following conditions are met:
19
20 1. Redistributions of source code must retain the above copyright
21 notice, this list of conditions and the following disclaimer.
22 2. Redistributions in binary form must reproduce the above copyright
23 notice, this list of conditions and the following disclaimer in the
24 documentation and/or other materials provided with the distribution.
25 3. The name of the author may not be used to endorse or promote products
26 derived from this software without specific prior written permission.
27
28 THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
29 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
30 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
31 ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
32 FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
33 DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
34 OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
35 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
36 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
37 OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
38 SUCH DAMAGE.
39
40 -->
41
42 <a href="./">Back to the index</a>
43
44 <p><br>
45 <h2>Introduction</h2>
46
47 <p>
48 <table border="0" width="99%"><tr><td valign="top" align="left">
49 <ul>
50 <li><a href="#overview">Overview</a>
51 <li><a href="#free">Is GXemul Free software?</a>
52 <li><a href="#build">How to compile/build the emulator</a>
53 <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>
58 <li><a href="#emulmodes">Which machines does GXemul emulate?</a>
59 </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
66
67 <p><br>
68 <a name="overview"></a>
69 <h3>Overview:</h3>
70
71 GXemul is an experimental instruction-level machine emulator. Several
72 emulation modes are available. In some modes, processors and surrounding
73 hardware components are emulated well enough to let unmodified operating
74 systems (e.g. NetBSD) run as if they were running on a real machine.
75
76 <p>Devices and processors are not simulated with 100% accuracy. They are
77 only ``faked'' well enough to allow guest operating systems to run without
78 complaining too much. Still, the emulator could be of interest for
79 academic research and experiments, such as when learning how to write
80 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.
90
91 <p>You can use pre-compiled kernels (for example NetBSD kernels, or
92 Linux), or other programs that are in binary format, and in some cases
93 even actual ROM images. A couple of different file formats are supported
94 (ELF, a.out, ECOFF, SREC, and raw binaries).
95
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, Dreamcast
99 emulation, or when booting from generic ISO9660 CDROM images if the
100 kernel is included in the image as a plain file.)
101
102 <p>Thanks to (in no specific order) Joachim Buss, Olivier Houchard, Juli
103 Mallett, Juan Romero Pardines, Alec Voropay, Göran Weinholt, Alexander
104 Yurchenko, and everyone else who has provided me with feedback.
105
106
107
108
109
110
111
112 <p><br>
113 <a name="free"></a>
114 <h3>Is GXemul Free software?</h3>
115
116 Yes. I have released GXemul under a Free license. The code in GXemul is
117 Copyrighted software, it is <i>not</i> public domain. (If this is
118 confusing to you, you might want to read up on the definitions of the
119 four freedoms associated with Free software, <a
120 href="http://www.gnu.org/philosophy/free-sw.html">http://www.gnu.org/philosophy/free-sw.html</a>.)
121
122 <p>The code I have written is released under a 3-clause BSD-style license
123 (or "revised BSD-style" if one wants to use <a
124 href="http://www.gnu.org/philosophy/bsd.html">GNU jargon</a>). Apart from
125 the code I have written, some files are copied from other sources such as
126 NetBSD, for example header files containing symbolic names of bitfields in
127 device registers. They are also covered by similar licenses, but with some
128 additional clauses. The main point, however, is that the licenses require
129 that the original Copyright and license terms are included when you make a
130 copy or modification.
131
132 <p>If you plan to redistribute GXemul <i>without</i> supplying the source
133 code, then you need to comply with each individual source file some other
134 way, for example by writing additional documentation containing copyright
135 notes. I have not done this, since I do not plan on making distributions
136 without source code. You need to check all individual files for details.
137 The "easiest way out" if you plan to redistribute code from GXemul is, of
138 course, to let it remain open source and simply supply the source code.
139
140 <p>In case you want to reuse parts of GXemul, but you need to do that
141 under a different license (e.g. the GPL), then contact me and I might
142 re-license/dual-license files on a case-by-case basis.
143
144
145
146
147
148 <p><br>
149 <a name="build"></a>
150 <h3>How to compile/build the emulator:</h3>
151
152 Uncompress the .tar.gz distribution file, and run
153 <pre>
154 $ <b>./configure</b>
155 $ <b>make</b>
156 </pre>
157
158 <p>This should work on most Unix-like systems. GXemul does not require any
159 specific libraries to build, however, if you build on a system which does
160 not have X11 libraries installed, some functionality will be lost.
161
162 <p>The emulator's performance is highly dependent on both runtime settings
163 and on compiler settings, so you might want to experiment with different
164 CC and CFLAGS environment variable values. For example, on an AMD Athlon
165 host, you might want to try setting <tt>CFLAGS</tt> to <tt>-march=athlon</tt>
166 before running <tt>configure</tt>.
167
168
169
170
171
172
173
174 <p><br>
175 <a name="run"></a>
176 <h3>How to run the emulator:</h3>
177
178 Once you have built GXemul, running it should be rather straight-forward.
179 Running <tt><b>gxemul</b></tt> without arguments (or with the
180 <b><tt>-h</tt></b> or <b><tt>-H</tt></b> command line options) will
181 display a help message.
182
183 <p>
184 To get some ideas about what is possible to run in the emulator, please
185 read the section about <a href="guestoses.html">installing "guest"
186 operating systems</a>. If you are interested in using the emulator to
187 develop code on your own, then you should also read the section about
188 <a href="experiments.html#hello">Hello World</a>.
189
190 <p>
191 To exit the emulator, type CTRL-C to enter the
192 single-step debugger, and then type <tt><b>quit</b></tt>.
193
194 <p>
195 If you are starting an emulation by entering settings directly on the
196 command line, and you are not using the <tt><b>-x</b></tt> option, then all
197 terminal input and output will go to the main controlling terminal.
198 CTRL-C is used to break into the debugger, so in order to send CTRL-C to
199 the running (emulated) program, you may use CTRL-B.
200 (This should be a reasonable compromise to allow the emulator to be usable
201 even on systems without X Windows.)
202
203 <p>
204 There is no way to send an actual CTRL-B to the emulated program, when
205 typing in the main controlling terminal window. The solution is to either
206 use <a href="configfiles.html">configuration files</a>, or use
207 <tt><b>-x</b></tt>. Both these solutions cause new xterms to be opened for
208 each emulated serial port that is written to. CTRL-B and CTRL-C both have
209 their original meaning in those xterm windows.
210
211
212
213
214
215 <p><br>
216 <a name="cpus"></a>
217 <h3>Which processor architectures does GXemul emulate?</h3>
218
219 The architectures that are emulated well enough to let at least one
220 guest operating system run (per architecture) are ARM, MIPS, PowerPC,
221 and SuperH.
222
223 <p>Please read the page about <a href="guestoses.html">guest operating
224 systems</a> for more information about the machines and operating systems
225 that can be considered "working" in the emulator.
226
227
228
229
230
231
232 <p><br>
233 <a name="hosts"></a>
234 <h3>Which host architectures are supported?</h3>
235
236 GXemul should compile and run on any modern host architecture (64-bit or
237 32-bit word-length).
238
239 <p>Note: The dynamic translation engine does <i>not</i> require backends
240 for native code generation to be written for each individual host
241 architecture; the "intermediate representation" that the dyntrans system
242 uses can be executed on any host architecture.
243
244
245
246
247
248 <p><br>
249 <a name="translation"></a>
250 <h3>What kind of translation does GXemul use?</h3>
251
252 <b>Static vs. dynamic:</b>
253
254 <p>In order to support guest operating systems, which can overwrite old
255 code pages in memory with new code, it is necessary to translate code
256 dynamically. It is not possible to do a "one-pass" (static) translation.
257 Self-modifying code and Just-in-Time compilers running inside
258 the emulator are other things that would not work with a static
259 translator. GXemul is a dynamic translator. However, it does not
260 necessarily translate into native code, like many other emulators.
261
262 <p><b>"Runnable" Intermediate Representation:</b>
263
264 <p>Dynamic translators usually translate from the emulated architecture
265 (e.g. MIPS) into a kind of <i>intermediate representation</i> (IR), and then
266 to native code (e.g. AMD64 or x86 code). Since one of my main goals for
267 GXemul is to keep everything as portable as possible, I have tried to make
268 sure that the IR is something which can be executed regardless of whether
269 the final step (translation from IR to native code) has been implemented
270 or not.
271
272 <p>The IR in GXemul consists of arrays of pointers to functions, and a few
273 arguments which are passed along to those functions. The functions are
274 implemented in either manually hand-coded C, or automatically generated C.
275 In any case, this is all statically linked into the GXemul binary at link
276 time.
277
278 <p>Here is a simplified diagram of how these arrays work.
279
280 <p><center><img src="simplified_dyntrans.png"></center>
281
282 <p>There is one instruction call slot for every possible program counter
283 location. In the MIPS case, instruction words are 32 bits in length,
284 and pages are (usually) 4 KB large, resulting in 1024 instruction call
285 slots. After the last of these instruction calls, there is an additional
286 call to a special "end of page" function (which doesn't count as an executed
287 instruction). This function switches to the first instruction
288 on the next virtual page (which might cause exceptions, etc).
289
290 <p>The complexity of individual instructions vary. A simple example of
291 what an instruction can look like is the MIPS <tt>addiu</tt> instruction:
292 <pre>
293 X(addiu)
294 {
295 reg(ic->arg[1]) = (int32_t)
296 ((int32_t)reg(ic->arg[0]) + (int32_t)ic->arg[2]);
297 }
298 </pre>
299
300 <p>It stores the result of a 32-bit addition of the register at arg[0]
301 with the immediate value arg[2] (treating both as signed 32-bit
302 integers) into register arg[1]. If the emulated CPU is a 64-bit CPU,
303 then this will store a correctly sign-extended value into arg[1].
304 If it is a 32-bit CPU, then only the lowest 32 bits will be stored,
305 and the high part ignored. <tt>X(addiu)</tt> is expanded to
306 <tt>mips_instr_addiu</tt> in the 64-bit case, and <tt>mips32_instr_addiu</tt>
307 in the 32-bit case. Both are compiled into the GXemul executable; no code
308 is created during run-time.
309
310 <p>Here are examples of what the <tt>addiu</tt> instruction actually
311 looks like when it is compiled, on various host architectures:
312
313 <p><center><table border="0">
314 <tr><td><b>GCC 4.0.1 on Alpha:</b></td>
315 <td width="35"></td><td></td>
316 <tr>
317 <td valign="top">
318 <pre>mips_instr_addiu:
319 ldq t1,8(a1)
320 ldq t2,24(a1)
321 ldq t3,16(a1)
322 ldq t0,0(t1)
323 addl t0,t2,t0
324 stq t0,0(t3)
325 ret</pre>
326 </td>
327 <td></td>
328 <td valign="top">
329 <pre>mips32_instr_addiu:
330 ldq t2,8(a1)
331 ldq t0,24(a1)
332 ldq t3,16(a1)
333 ldl t1,0(t2)
334 addq t0,t1,t0
335 stl t0,0(t3)
336 ret</pre>
337 </td>
338 </tr>
339
340 <tr><td><b><br>GCC 3.4.4 on AMD64:</b></td>
341 <tr>
342 <td valign="top">
343 <pre>mips_instr_addiu:
344 mov 0x8(%rsi),%rdx
345 mov 0x18(%rsi),%rax
346 mov 0x10(%rsi),%rcx
347 add (%rdx),%eax
348 cltq
349 mov %rax,(%rcx)
350 retq</pre>
351 </td>
352 <td></td>
353 <td valign="top">
354 <pre>mips32_instr_addiu:
355 mov 0x8(%rsi),%rcx
356 mov 0x10(%rsi),%rdx
357 mov (%rcx),%eax
358 add 0x18(%rsi),%eax
359 mov %eax,(%rdx)
360 retq</pre>
361 </td>
362 </tr>
363
364 <tr><td><b><br>GCC 4.0.1 on i386:</b></td>
365 <tr>
366 <td valign="top">
367 <pre>mips_instr_addiu:
368 mov 0x8(%esp),%eax
369 mov 0x8(%eax),%ecx
370 mov 0x4(%eax),%edx
371 mov 0xc(%eax),%eax
372 add (%edx),%eax
373 mov %eax,(%ecx)
374 cltd
375 mov %edx,0x4(%ecx)
376 ret</pre>
377 </td>
378 <td></td>
379 <td valign="top">
380 <pre>mips32_instr_addiu:
381 mov 0x8(%esp),%eax
382 mov 0x8(%eax),%ecx
383 mov 0x4(%eax),%edx
384 mov 0xc(%eax),%eax
385 add (%edx),%eax
386 mov %eax,(%ecx)
387 ret</pre>
388 </td>
389 </tr>
390 </table></center>
391
392 <p>On 64-bit hosts, there is not much difference, but on 32-bit hosts (and
393 to some extent on AMD64), the difference is enough to make it worthwhile.
394
395
396 <p><b>Performance:</b>
397
398 <p>The performance of using this kind of runnable IR is obviously lower
399 than what can be achieved by emulators using native code generation, but
400 can be significantly higher than using a naive fetch-decode-execute
401 interpretation loop. In my opinion, using a runnable IR is an interesting
402 compromise.
403
404 <p>The overhead per emulated instruction is usually around or below
405 approximately 10 host instructions. This is very much dependent on your
406 host architecture and what compiler and compiler switches you are using.
407 Added to this instruction count is (of course) also the C code used to
408 implement each specific instruction.
409
410 <p><b>Instruction Combinations:</b>
411
412 <p>Short, common instruction sequences can sometimes be replaced by a
413 "compound" instruction. An example could be a compare instruction followed
414 by a conditional branch instruction. The advantages of instruction
415 combinations are that
416 <ul>
417 <li>the amortized overhead per instruction is slightly reduced, and
418 <p>
419 <li>the host's compiler can make a good job at optimizing the common
420 instruction sequence.
421 </ul>
422
423 <p>The special cases where instruction combinations give the most gain
424 are in the cores of string/memory manipulation functions such as
425 <tt>memset()</tt> or <tt>strlen()</tt>. The core loop can then (at least
426 to some extent) be replaced by a native call to the equivalent function.
427
428 <p>The implementations of compound instructions still keep track of the
429 number of executed instructions, etc. When single-stepping, these
430 translations are invalidated, and replaced by normal instruction calls
431 (one per emulated instruction).
432
433 <p><b>Native Code Back-ends:</b>
434
435 <p>In theory, it will be possible to implement native code generation,
436 similar to what is used in high-performance emulators such as QEMU,
437 as long as that generated code abides to the C ABI on the host.
438
439 <p>However, since I wanted to make sure that GXemul works without such
440 native code back-ends, there are no implemented backends in this release.
441
442 <p>(There is a place-holder in the source code for native code generation,
443 which can be used for experiments, but it does not contain any working
444 code at the moment.)
445
446
447
448
449
450
451 <p><br>
452 <a name="accuracy"></a>
453 <h3>Emulation accuracy:</h3>
454
455 GXemul is an instruction-level emulator; things that would happen in
456 several steps within a real CPU are not taken into account (e.g. pipe-line
457 stalls or out-of-order execution). Still, instruction-level accuracy seems
458 to be enough to be able to run complete guest operating systems inside the
459 emulator.
460
461 <p>The existance of instruction and data caches is "faked" to let
462 operating systems think that they are there, but for all practical
463 purposes, these caches are non-working.
464
465 <p>The emulator is in general <i>not</i> timing-accurate, neither at the
466 instruction level nor on any higher level. An attempt is made to let
467 emulated clocks run at the same speed as the host (i.e. an emulated timer
468 running at 100 Hz will interrupt around 100 times per real second), but
469 since the host speed may vary, e.g. because of other running processes,
470 there is no guarantee as to how many instructions will be executed in
471 each of these 100 Hz cycles.
472
473 <p>If the host is very slow, the emulated clocks might even lag behind
474 the real-world clock.
475
476
477
478
479
480
481 <p><br>
482 <a name="emulmodes"></a>
483 <h3>Which machines does GXemul emulate?</h3>
484
485 A few different machine types are emulated. The following machine types
486 are emulated well enough to run at least one "guest OS":
487
488 <p>
489 <ul>
490 <li><b><u>ARM</u></b>
491 <ul>
492 <li><b>CATS</b> (<a href="guestoses.html#netbsdcatsinstall">NetBSD/cats</a>,
493 <a href="guestoses.html#openbsdcatsinstall">OpenBSD/cats</a>)
494 <li><b>IQ80321</b> (<a href="guestoses.html#netbsdevbarminstall">NetBSD/evbarm</a>)
495 <li><b>NetWinder</b> (<a href="guestoses.html#netbsdnetwinderinstall">NetBSD/netwinder</a>)
496 </ul>
497 <p>
498 <li><b><u>MIPS</u></b>
499 <ul>
500 <li><b>DECstation 5000/200</b> (<a href="guestoses.html#netbsdpmaxinstall">NetBSD/pmax</a>,
501 <a href="guestoses.html#openbsdpmaxinstall">OpenBSD/pmax</a>,
502 <a href="guestoses.html#ultrixinstall">Ultrix</a>,
503 <a href="guestoses.html#declinux">Linux/DECstation</a>,
504 <a href="guestoses.html#sprite">Sprite</a>)
505 <li><b>Acer Pica-61</b> (<a href="guestoses.html#netbsdarcinstall">NetBSD/arc</a>)
506 <li><b>NEC MobilePro 770, 780, 800, 880</b> (<a href="guestoses.html#netbsdhpcmipsinstall">NetBSD/hpcmips</a>)
507 <li><b>Cobalt</b> (<a href="guestoses.html#netbsdcobaltinstall">NetBSD/cobalt</a>)
508 <li><b>Malta</b> (<a href="guestoses.html#netbsdevbmipsinstall">NetBSD/evbmips</a>, Linux/Malta <font color="#0000e0">(<super>*1</super>)</font>)
509 <li><b>Algorithmics P5064</b> (<a href="guestoses.html#netbsdalgorinstall">NetBSD/algor</a>)
510 <li><b>SGI O2 (aka IP32)</b> <font color="#0000e0">(<super>*2</super>)</font>
511 (<a href="guestoses.html#netbsdsgimips">NetBSD/sgi</a>)
512 </ul>
513 <p>
514 <li><b><u>PowerPC</u></b>
515 <ul>
516 <li><b>IBM 6050/6070 (PReP, PowerPC Reference Platform)</b> (<a href="guestoses.html#netbsdprepinstall">NetBSD/prep</a>)
517 <li><b>MacPPC (generic "G4" Macintosh)</b> (<a href="guestoses.html#netbsdmacppcinstall">NetBSD/macppc</a>)
518 </ul>
519 <p>
520 <li><b><u>SuperH</u></b>
521 <ul>
522 <li><b>Sega Dreamcast</b> (<a href="dreamcast.html#netbsd_generic_md">NetBSD/dreamcast</a>, <a href="dreamcast.html#linux_live_cd">Linux/dreamcast</a>)
523 </ul>
524 </ul>
525
526 <p>
527 <small><font color="#0000e0">(<super>*1</super>)</font> =
528 Linux/Malta may be run as a guest OS, however I have not yet found any stable
529 URL to pre-compiled Linux/Malta kernels. Thus, Linux/Malta emulation is not
530 tested for every release of the emulator; sometimes it works, sometimes
531 it doesn't.</small>
532
533 <br><small><font color="#0000e0">(<super>*2</super>)</font> =
534 SGI O2 emulation is enough for root-on-nfs, but not for disk boot.</small>
535
536
537 <p>There is code in GXemul for emulation of many other machine types; the
538 degree to which these work range from almost being able to run a complete
539 OS, to almost completely unsupported (perhaps just enough support to
540 output a few boot messages via serial console).
541
542 <p>In addition to emulating real machines, there is also a "test-machine".
543 A test-machine consists of one or more CPUs and a few experimental devices
544 such as:
545
546 <p>
547 <ul>
548 <li>a console I/O device (putchar() and getchar()...)
549 <li>an inter-processor communication device, for SMP experiments
550 <li>a very simple linear framebuffer device (for graphics output)
551 <li>a simple disk controller
552 <li>a simple ethernet controller
553 <li>a real-time clock device
554 </ul>
555
556 <p>This mode is useful if you wish to run experimental code, but do not
557 wish to target any specific real-world machine type, for example for
558 educational purposes.
559
560 <p>You can read more about these experimental devices <a
561 href="experiments.html#expdevices">here</a>.
562
563
564
565
566
567
568 </body>
569 </html>

  ViewVC Help
Powered by ViewVC 1.1.26