/[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 20 by dpavlin,
Mon Oct  8 16:19:23 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.67 2005/11/24 12:32:10 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. The ARM and PowerPC
-         no other way to emulate URISC, because it relies too heavily
+         emulation modes uses this kind of translation.
-         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 330 
 a CDROM ISO image. You can use a read-wr
+Line 318 
 a CDROM ISO image. You can use a read-wr
  files in both directions, but then you should be aware of the
  fragmentation issue mentioned above.
- <p>TODO: Write a section on how to connect multiple emulator instances.
- (Using the <tt>local_port</tt> and <tt>add_remote</tt> configuration file
- commands.)
-Line 343 
 commands.)
+Line 328 
 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 called <tt>dev_*.c</tt> in the <tt>src/device/</tt> directory is
- hardware device. These are used from <tt>src/machine.c</tt>, when
+ responsible for one hardware device. These are used from
- initializing which hardware a particular machine model will be using, or
+ <tt>src/machine.c</tt>, when initializing which hardware a particular
- when adding devices to a machine using the <tt>device()</tt> command in
+ machine model will be using, or when adding devices to a machine using the
- configuration files.
+ <tt>device()</tt> command in configuration files.
- <p><font color="#ff0000">NOTE: The device registry subsystem is currently
- in a state of flux, as it is being redesigned.</font>
  <p>(I'll be using the name "<tt>foo</tt>" as the name of the device in all
  these examples.  This is pseudo code, it might need some modification to
-Line 386 
 actually compile and run.)
+Line 368 
 actually compile and run.)
                  memory_device_register(devinit->machine->memory, devinit->name,
                      devinit->addr, DEV_FOO_LENGTH,
-                     dev_foo_access, (void *)d, MEM_DEFAULT, NULL);
+                     dev_foo_access, (void *)d, DM_DEFAULT, NULL);
                  /*  This should only be here if the device
                      has a tick function:  */
-Line 406 
 actually compile and run.)
+Line 388 
 actually compile and run.)
                  /*  ...  */
          }
  </pre><br>
+         (There is an exception to this rule; ugly hacks which allow
+         code in <tt>src/machine.c</tt> to use some structures makes it
+         necessary to place the <tt>struct foo_data</tt> in
+         <tt>src/include/devices.h</tt> instead of in <tt>dev_foo.c</tt>
+         itself. This is useful for example for interrupt controllers.)
+   <p>
    <li>If <tt>foo</tt> has a tick function (that is, something that needs to be
          run at regular intervals) then <tt>FOO_TICKSHIFT</tt> and a tick
          function need to be defined as well:
  <pre>
-         #define FOO_TICKSHIFT           10
+         #define FOO_TICKSHIFT           14
          void dev_foo_tick(struct cpu *cpu, void *extra)
          {
-Line 424 
 actually compile and run.)
+Line 411 
 actually compile and run.)
          }
  </pre><br>
+   <li>Does this device belong to a standard bus?
+         <ul>
+           <li>If this device should be detectable as a PCI device, then
+                 glue code should be added to
+                 <tt>src/devices/bus_pci.c</tt>.
+           <li>If this is a legacy ISA device which should be usable by
+                 any machine which has an ISA bus, then the device should
+                 be added to <tt>src/devices/bus_isa.c</tt>.
+         </ul>
+   <p>
    <li>And last but not least, the device should have an access function.
          The access function is called whenever there is a load or store
          to an address which is in the device' memory mapped region.
-Line 474 
 by the caller (in <tt>src/memory_rw.c</t
+Line 471 
 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.20
 Legend:



Removed from v.10
 


changed lines


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

	ViewVC Help
Powered by ViewVC 1.1.26