/[gxemul]/trunk/doc/technical.html

This is repository of my old source code which isn't updated any more. Go to git.rot13.org for current projects!

Diff of /trunk/doc/technical.html

Parent Directory | Revision Log | View Patch Patch

-revision 10 by dpavlin,
Mon Oct  8 16:18:27 2007 UTC
+revision 14 by dpavlin,
Mon Oct  8 16:18:51 2007 UTC
 Line 1
- <html><head><title>GXemul documentation: Technical details</title>
+ <html><head><title>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;Technical details</title>
  <meta name="robots" content="noarchive,nofollow,noindex"></head>
  <body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000">
  <table border=0 width=100% bgcolor="#d0d0d0"><tr>
  <td width=100% align=center valign=center><table border=0 width=100%><tr>
  <td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6">
- <b>GXemul documentation:</b></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+ <b>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;</b></font>
  <font color="#000000" size="6"><b>Technical details</b>
  </font></td></tr></table></td></tr></table><p>
  <!--
- $Id: technical.html,v 1.53 2005/06/27 17:31:50 debug Exp $
+ $Id: technical.html,v 1.63 2005/10/07 15:10:00 debug Exp $
  Copyright (C) 2004-2005  Anders Gavare.  All rights reserved.
 Line 40 
 SUCH DAMAGE.
  -->
  <a href="./">Back to the index</a>
  <p><br>
-Line 52 
 SUCH DAMAGE.
+Line 53 
 SUCH DAMAGE.
    <li><a href="#speed">Speed and emulation modes</a>
    <li><a href="#net">Networking</a>
    <li><a href="#devices">Emulation of hardware devices</a>
-   <li><a href="#regtest">Regression tests</a>
  </ul>
 Line 64 
 SUCH DAMAGE.
  <a name="speed"></a>
  <h3>Speed and emulation modes</h3>
- So, how fast is GXemul? There is no good answer to this. There is
+ So, how fast is GXemul? There is no short answer to this. There is
  especially no answer to the question <b>What is the slowdown factor?</b>,
  because the host architecture and emulated architecture can usually not be
  compared just like that.
 Line 89 
 with the emulator. Typical examples woul
  install NetBSD?", or "How long does it take to compile XYZ inside NetBSD
  in the emulator?".
+ <p>So, how fast is it? :-)&nbsp;&nbsp;&nbsp;Answer: it varies.
  <p>The emulation technique used varies depending on which processor type
  is being emulated. (One of my main goals with GXemul is to experiment with
  different kinds of emulation, so these might change in the future.)
  <ul>
-   <li><b>MIPS</b><br>
+   <li><b>MIPS:</b><br>
          There are two emulation modes. The most important one is an
          implementation of a <i>dynamic binary translator</i>.
          (Compared to real binary translators, though, GXemul's bintrans
-Line 105 
 different kinds of emulation, so these m
+Line 107 
 different kinds of emulation, so these m
          works. It can be forcefully used by using the <tt>-B</tt> command
          line option.)
    <p>
-   <li><b>ARM</b><br>
+   <li><b>All other modes:</b><br>
-         This mode does not really work yet, but will use
+         These use a kind of dynamic translation system. (This system does
-         dynamic translation, but not binary translation. Stay tuned. :-)
+         not use host-specific backends, so it is not "recompilation" or
-   <p>
+         anything like that.) Speed is slower than real binary translation,
-   <li><b>URISC</b><br>
+         but faster than traditional interpretation, and with some tricks
-         Simple interpretation, one instruction at a time. There is probably
+         it will hopefully still give reasonable speed. ARM emulation uses
-         no other way to emulate URISC, because it relies too heavily
+         this kind of translation, for example.
-         on self-modifying code.
-   <p>
-   <li><b>POWER/PowerPC</b><br>
-         This emulation mode is very much unfinished, but still enabled by
-         default. So far it uses plain interpretation, where an instruction
-         is read from emulated memory, and interpreted one at a time.
-         Slow. Not very interesting.
-   <p>
-   <li><b>x86</b><br>
-         Although too unstable and non-working to be enabled by default,
-         there is some code for emulating x86 machines. It simply reads
-         one instruction at a time from emulated memory, and executes it.
-         This is as slow as it gets. Not very interesting.
  </ul>
-Line 132 
 different kinds of emulation, so these m
+Line 121 
 different kinds of emulation, so these m
  <p><br>
  <a name="net"></a>
  <h3>Networking</h3>
-Line 343 
 commands.)
+Line 331 
 commands.)
  <a name="devices"></a>
  <h3>Emulation of hardware devices</h3>
- Each file in the <tt>device/</tt> directory is responsible for one
+ Each file in the <tt>src/device/</tt> directory is responsible for one
  hardware device. These are used from <tt>src/machine.c</tt>, when
  initializing which hardware a particular machine model will be using, or
  when adding devices to a machine using the <tt>device()</tt> command in
-Line 474 
 by the caller (in <tt>src/memory_rw.c</t
+Line 462 
 by the caller (in <tt>src/memory_rw.c</t
- <p><br>
- <a name="regtest"></a>
- <h3>Regression tests</h3>
- In order to make sure that the emulator actually works like it is supposed
- to, it must be tested. For this purpose, there is a simple regression
- testing framework in the <tt>tests/</tt> directory.
- <p>
- <i>NOTE:  The regression testing framework is basically just a skeleton so far.
- Regression tests are very good to have. However, the fact that complete
- operating systems can run in the emulator indicate that the emulation is
- probably not too incorrect. This makes it less of a priority to write
- regression tests.</i>
- <p>
- To run all the regression tests, type <tt>make regtest</tt>. Each assembly
- language file matching the pattern <tt>test_*.S</tt> will be compiled and
- linked into a 64-bit MIPS ELF (using a gcc cross compiler), and run in the
- emulator. If everything goes well, you should see something like this:
- <pre>
-         $ make regtest
-         cd tests; make run_tests; cd ..
-         gcc33 -Wall -fomit-frame-pointer -fmove-all-movables -fpeephole -O2
-                 -mcpu=ev5 -I/usr/X11R6/include -lm -L/usr/X11R6/lib -lX11  do_tests.c
-                 -o do_tests
-         do_tests.c: In function `main':
-         do_tests.c:173: warning: unused variable `s'
-         /var/tmp//ccFOupvD.o: In function `do_tests':
-         /var/tmp//ccFOupvD.o(.text+0x3a8): warning: tmpnam() possibly used
-                 unsafely; consider using mkstemp()
-         mips64-unknown-elf-gcc -g -O3 -fno-builtin -fschedule-insns -mips64
-                 -mabi=64 test_common.c -c -o test_common.o
-         ./do_tests "mips64-unknown-elf-gcc -g -O3 -fno-builtin -fschedule-insns
-                 -mips64 -mabi=64" "mips64-unknown-elf-as -mabi=64 -mips64"
-                 "mips64-unknown-elf-ld -Ttext 0xa800000000030000 -e main
-                 --oformat=elf64-bigmips" "../gxemul"
-         Starting tests:
-           test_addu.S (-a)
-           test_addu.S (-a -b)
-           test_clo_clz.S (-a)
-           test_clo_clz.S (-a -b)
-           ..
-           test_unaligned.S (-a)
-           test_unaligned.S (-a -b)
-         Done. (12 tests done)
-             PASS:     12
-             FAIL:      0
-         ----------------
-           All tests OK
-         ----------------
- </pre>
- <p>
- Each test writes output to stdout, and there is a <tt>test_*.good</tt> for
- each <tt>.S</tt> file which contains the wanted output. If the actual
- output matches the <tt>.good</tt> file, then the test passes, otherwise it
- fails.
- <p>
- Read <tt>tests/README</tt> for more information.
  </body>
  </html>

 Legend:



Removed from v.10
 


changed lines


 
Added in v.14
 Legend:



Removed from v.10
 


changed lines


 
Added in v.14
-Removed from v.10
+Added in v.14

	ViewVC Help
Powered by ViewVC 1.1.26