/[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!

Diff of /trunk/doc/intro.html

Parent Directory | Revision Log | View Patch Patch

-revision 32 by dpavlin,
Mon Oct  8 16:20:58 2007 UTC
+revision 44 by dpavlin,
Mon Oct  8 16:22:56 2007 UTC
 Line 4
  <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>Gavare's eXperimental Emulator:</b></font><br>
+ <b>GXemul:</b></font>&nbsp;&nbsp;
  <font color="#000000" size="6"><b>Introduction</b>
  </font></td></tr></table></td></tr></table><p>
  <!--
- $Id: intro.html,v 1.100 2006/11/04 06:40:20 debug Exp $
+ $Id: intro.html,v 1.125 2007/06/30 14:02:02 debug Exp $
- Copyright (C) 2003-2006  Anders Gavare.  All rights reserved.
+ Copyright (C) 2003-2007  Anders Gavare.  All rights reserved.
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are met:
 Line 52 
 SUCH DAMAGE.
    <li><a href="#build">How to compile/build the emulator</a>
    <li><a href="#run">How to run the emulator</a>
    <li><a href="#cpus">Which processor architectures does GXemul emulate?</a>
-   <li><a href="#hosts">Which host architectures are supported?</a>
+   <li><a href="#hosts">Which host architectures/platforms are supported?</a>
-   <li><a href="#translation">What kind of translation does GXemul use?</a>
    <li><a href="#accuracy">Emulation accuracy</a>
    <li><a href="#emulmodes">Which machines does GXemul emulate?</a>
  </ul>
-Line 68 
 SUCH DAMAGE.
+Line 67 
 SUCH DAMAGE.
  <a name="overview"></a>
  <h3>Overview:</h3>
- GXemul is an experimental instruction-level machine emulator. Several
+ GXemul is a framework for full-system computer architecture emulation.
- emulation modes are available. In some modes, processors and surrounding
+ Several processor architectures and machine types have been implemented.
- hardware components are emulated well enough to let unmodified operating
+ It is working well enough to allow <a href="#emulmodes">unmodified
- systems (e.g. NetBSD) run as if they were running on a real machine.
+ "guest" operating systems to run inside the emulator</a>, as if they were
+ running on real hardware.
+ <p>The emulator emulates (networks of) real machines. The machines may
+ consist of <a
+ href="http://en.wikipedia.org/wiki/ARM_architecture">ARM</a>, <a
+ href="http://en.wikipedia.org/wiki/MIPS_architecture">MIPS</a>, <a
+ href="http://en.wikipedia.org/wiki/Powerpc">PowerPC</a>, and <a
+ href="http://en.wikipedia.org/wiki/SuperH">SuperH</a> processors, and
+ various surrounding hardware components such as framebuffers, busses,
+ interrupt controllers, ethernet controllers, disk controllers, and serial
+ port controllers.
+ <p>GXemul, including the dynamic translation system, is implemented in
+ portable
+ <a href="http://en.wikipedia.org/wiki/C_(programming_language)">C</a>,
+ which means that the emulator will run on practically any 64-bit or 32-bit
+ <a href="http://en.wikipedia.org/wiki/Unix-like">Unix-like</a> systems,
+ with few or no modifications.
  <p>Devices and processors are not simulated with 100% accuracy. They are
- only ``faked'' well enough to allow guest operating systems to run without
+ only "faked" well enough to allow guest operating systems to run without
  complaining too much. Still, the emulator could be of interest for
  academic research and experiments, such as when learning how to write
  operating system code.
- <p>The emulator is written in C, does not depend on third-party libraries,
- and should compile and run on most 64-bit and 32-bit Unix-like systems.
  <p>The emulator contains code which tries to emulate the workings of CPUs
  and surrounding hardware found in real machines, but it does not contain
  any ROM code. You will need some form of program (in binary form) to run
- in the emulator. For many emulation modes, PROM calls are handled by the
+ in the emulator. For some emulation modes, PROM calls are handled by the
  emulator itself, so you do not need to use any ROM image at all.
- <p>You can use pre-compiled kernels (for example NetBSD kernels, or
+ <p>You can use pre-compiled kernels (for example <a href="http://www.netbsd.org/">NetBSD</a>
- Linux), or other programs that are in binary format, and in some cases
+ kernels, or Linux), or other programs that are in binary format, and in some cases
- even actual ROM images. A couple of different file formats are supported
+ even actual ROM images. A couple of different file formats are supported:
- (ELF, a.out, ECOFF, SREC, and raw binaries).
+ <a href="http://en.wikipedia.org/wiki/Executable_and_Linkable_Format">ELF</a>,
+ <a href="http://en.wikipedia.org/wiki/A.out">a.out</a>,
+ <a href="http://en.wikipedia.org/wiki/COFF">COFF</a>/<a href="http://en.wikipedia.org/wiki/ECOFF">ECOFF</a>,
+ <a href="http://en.wikipedia.org/wiki/SREC_%28file_format%29">SREC</a>, and raw binaries.
  <p>If you do not have a kernel as a separate file, but you have a bootable
  disk image, then it is sometimes possible to boot directly from that
- image. (This works for example with DECstation emulation, or when booting
+ image. This works for example with DECstation emulation, <a href="dreamcast.html">Dreamcast
- from ISO9660 CDROM images.)
+ emulation</a>, or when booting from generic <a href="http://en.wikipedia.org/wiki/ISO9660">ISO9660</a>
+ CDROM images if the kernel is included in the image as a plain file.
  <p>Thanks to (in no specific order) Joachim Buss, Olivier Houchard, Juli
- Mallett, Juan Romero Pardines, Alec Voropay, G�ran Weinholt, Alexander
+ Mallett, Juan Romero Pardines, Carl van Schaik, Miod Vallat, Alec Voropay,
- Yurchenko, and everyone else who has provided me with feedback.
+ G�ran Weinholt, Alexander Yurchenko, and everyone else who has provided me
+ with feedback.
-Line 134 
 way, for example by writing additional d
+Line 153 
 way, for example by writing additional d
  notes. I have not done this, since I do not plan on making distributions
  without source code. You need to check all individual files for details.
  The "easiest way out" if you plan to redistribute code from GXemul is, of
- course, to let it remain open source and simply supply the source code.
+ course, to let it remain Free Software and simply include the source code.
  <p>In case you want to reuse parts of GXemul, but you need to do that
- under a different license (e.g. the GPL), then contact me and I might
+ under a different license (e.g. the
- re-license/dual-license files on a case-by-case basis.
+ <a href="http://www.gnu.org/licenses/gpl.html">GPL</a>), then contact me and
+ I can probably re-license/dual-license files on a case-by-case basis.
-Line 158 
 Uncompress the .tar.gz distribution file
+Line 178 
 Uncompress the .tar.gz distribution file
  specific libraries to build, however, if you build on a system which does
  not have X11 libraries installed, some functionality will be lost.
  <p>The emulator's performance is highly dependent on both runtime settings
- and on compiler settings, so you might want to experiment with different
+ and on compiler settings, so you might want to experiment with using
- CC and CFLAGS environment variable values. For example, on an AMD Athlon
+ different <tt>CC</tt> and <tt>CFLAGS</tt> environment variable values when
- host, you might want to try setting <tt>CFLAGS</tt> to <tt>-march=athlon</tt>
+ running the <tt>configure</tt> script.
- before running <tt>configure</tt>.
+ <p>On some platforms, it is possible that building GXemul will fail
+ because of too high optimization. When using GCC (the GNU compiler),
+ <tt>-O3</tt> is the default optimization level. This works fine on e.g.
+ amd64 and i386 systems, but on some more uncommon platforms, <tt>-O3</tt>
+ might trigger internal bugs in GCC itself. If this happens, try setting
+ <tt>CFLAGS</tt> to <tt>-O2</tt> before running <tt>./configure</tt>, and
+ try again,
+ <p>Note that there is no <tt>make install</tt> functionality; package
+ maintainers for individual operating systems solve this for their
+ corresponding OSes.
-Line 179 
 Running <tt><b>gxemul</b></tt> without a
+Line 210 
 Running <tt><b>gxemul</b></tt> without a
  <b><tt>-h</tt></b> or <b><tt>-H</tt></b> command line options) will
  display a help message.
- <p>
+ <p>To get some ideas about what is possible to run in the emulator, please
- To get some ideas about what is possible to run in the emulator, please
  read the section about <a href="guestoses.html">installing "guest"
- operating systems</a>. If you are interested in using the emulator to
+ operating systems</a>. The most straight forward guest operating to
- develop code on your own, then you should also read the section about
+ install is NetBSD/pmax; the instructions provided <a
- <a href="experiments.html#hello">Hello World</a>.
+ href="guestoses.html#netbsdpmaxinstall">here</a> should let you install
+ NetBSD/pmax in a way very similar to how it is done on a real DECstation.
+ <p>If you are interested in using the emulator to develop code on your
+ own, then you should also read the section about <a
+ href="experiments.html#hello">Hello World</a>.
- <p>
+ <p>To exit the emulator, type CTRL-C to enter the
- To exit the emulator, type CTRL-C to enter the
  single-step debugger, and then type <tt><b>quit</b></tt>.
- <p>
+ <p>If you are starting an emulation by entering settings directly on the
- If you are starting an emulation by entering settings directly on the
+ command line, and you are not using the <tt><b>-x</b></tt> option, then
- command line, and you are not using the <tt><b>-x</b></tt> option, then all
+ all terminal input and output will go to the main controlling terminal.
- terminal input and output will go to the main controlling terminal.
  CTRL-C is used to break into the debugger, so in order to send CTRL-C to
- the running (emulated) program, you may use CTRL-B.
+ the running (emulated) program, you may use CTRL-B. (This should be a
- (This should be a reasonable compromise to allow the emulator to be usable
+ reasonable compromise to allow the emulator to be usable even on systems
- even on systems without X Windows.)
+ without X Windows.)
- <p>
+ <p>There is no way to send an actual CTRL-B to the emulated program, when
- There is no way to send an actual CTRL-B to the emulated program, when
+ typing in the main controlling terminal window. The solution is to either
- typing in the main controlling terminal window. The solution is to either
+ use <a href="configfiles.html">configuration files</a>, or use
- use <a href="configfiles.html">configuration files</a>, or use
  <tt><b>-x</b></tt>. Both these solutions cause new xterms to be opened for
  each emulated serial port that is written to. CTRL-B and CTRL-C both have
  their original meaning in those xterm windows.
-Line 216 
 their original meaning in those xterm wi
+Line 248 
 their original meaning in those xterm wi
  <h3>Which processor architectures does GXemul emulate?</h3>
  The architectures that are emulated well enough to let at least one
- guest operating system run (per architecture) are ARM, MIPS, PowerPC,
+ guest operating system run (per architecture) are
- and SuperH.
+ <a href="http://en.wikipedia.org/wiki/ARM_architecture">ARM</a>,
+ <a href="http://en.wikipedia.org/wiki/MIPS_architecture">MIPS</a>,
+ <a href="http://en.wikipedia.org/wiki/Powerpc">PowerPC</a>, and
+ <a href="http://en.wikipedia.org/wiki/SuperH">SuperH</a>.
+ <p>Please read the sections about <a href="#emulmodes">emulation
+ modes</a> and <a href="guestoses.html">guest operating
+ systems</a> for more information about the machines and operating systems,
+ respectively, that can be considered "working" in the emulator.
+ <p>(There is some code in GXemul for emulation of other architectures, but
+ they are not stable or complete enough to be listed among the "working"
+ architectures.)
-Line 226 
 and SuperH.
+Line 270 
 and SuperH.
  <p><br>
  <a name="hosts"></a>
- <h3>Which host architectures are supported?</h3>
+ <h3>Which host architectures/platforms are supported?</h3>
  GXemul should compile and run on any modern host architecture (64-bit or
--bit word-length).
+-bit word-length). I generally test it on
+ <a href="http://www.freebsd.org/platforms/amd64.html">FreeBSD/amd64</a> 6.x,
+ <a href="http://www.freebsd.org/platforms/alpha.html">FreeBSD/alpha</a> 4.x,
+ sometimes also on Linux (various platforms), and every
+ now and then also on <a href="http://www.netbsd.org/">NetBSD</a> or
+ <a href="http://www.openbsd.org/">OpenBSD</a> inside the emulator itself
+ (various platforms).
+ <p>Note 1: The <a href="translation.html">dynamic translation</a> engine
+ does <i>not</i> require backends for native code generation to be written
+ for each individual host architecture; the intermediate representation
+ that the dyntrans system uses can be executed on any host architecture.
+ <p>Note 2: Although GXemul may build and run on non-Unix-like platforms,
+ such as <a href="http://www.cygwin.com/">Cygwin</a>, Unix-like systems are
+ the primary platform. Some functionality may be lost when running on Cygwin.
- <p>(The dynamic translation engine translates into an intermediate
- representation, but not currently into native code. This means that there
- is no need for per-host architecture backend code.)
- <p><br>
- <a name="translation"></a>
- <h3>What kind of translation does GXemul use?</h3>
- <b>Static vs. dynamic:</b>
- <p>In order to support guest operating systems, which can overwrite old
- code pages in memory with new code, it is necessary to translate code
- dynamically. It is not possible to do a "one-pass" (static) translation.
- Self-modifying code and Just-in-Time compilers running inside
- the emulator are other things that would not work with a static
- translator. GXemul is a dynamic translator. However, it does not
- necessarily translate into native code, like many other emulators.
- <p><b>"Runnable" Intermediate Representation:</b>
- <p>Dynamic translators usually translate from the emulated architecture
- (e.g. MIPS) into a kind of <i>intermediate representation</i> (IR), and then
- to native code (e.g. AMD64 or x86 code). Since one of my main goals for
- GXemul is to keep everything as portable as possible, I have tried to make
- sure that the IR is something which can be executed regardless of whether
- the final step (translation from IR to native code) has been implemented
- or not.
- <p>The IR in GXemul consists of arrays of pointers to functions, and a few
- arguments which are passed along to those functions. The functions are
- implemented in either manually hand-coded C, or automatically generated C.
- In any case, this is all statically linked into the GXemul binary at link
- time.
- <p>Here is a simplified diagram of how these arrays work.
- <p><center><img src="simplified_dyntrans.png"></center>
- <p>There is one instruction call slot for every possible program counter
- location. In the MIPS case, instruction words are 32 bits in length,
- and pages are (usually) 4 KB large, resulting in 1024 instruction call
- slots. After the last of these instruction calls, there is an additional
- call to a special "end of page" function (which doesn't count as an executed
- instruction). This function switches to the first instruction
- on the next virtual page (which might cause exceptions, etc).
- <p>The complexity of individual instructions vary. A simple example of
- what an instruction can look like is the MIPS <tt>addiu</tt> instruction:
- <pre>
-         X(addiu)
-         {
-                 reg(ic->arg[1]) = (int32_t)
-                     ((int32_t)reg(ic->arg[0]) + (int32_t)ic->arg[2]);
-         }
- </pre>
- <p>It stores the result of a 32-bit addition of the register at arg[0]
- with the immediate value arg[2] (treating both as signed 32-bit
- integers) into register arg[1]. If the emulated CPU is a 64-bit CPU,
- then this will store a correctly sign-extended value into arg[1].
- If it is a 32-bit CPU, then only the lowest 32 bits will be stored,
- and the high part ignored. <tt>X(addiu)</tt> is expanded to
- <tt>mips_instr_addiu</tt> in the 64-bit case, and <tt>mips32_instr_addiu</tt>
- in the 32-bit case. Both are compiled into the GXemul executable; no code
- is created during run-time.
- <p>Here are examples of what the <tt>addiu</tt> instruction actually
- looks like when it is compiled, on various host architectures:
- <p><center><table border="0">
-     <tr><td><b>GCC 4.0.1 on Alpha:</b></td>
-         <td width="35"></td><td></td>
-     <tr>
-         <td valign="top">
- <pre>mips_instr_addiu:
-      ldq     t1,8(a1)
-      ldq     t2,24(a1)
-      ldq     t3,16(a1)
-      ldq     t0,0(t1)
-      addl    t0,t2,t0
-      stq     t0,0(t3)
-      ret</pre>
-         </td>
-         <td></td>
-         <td valign="top">
- <pre>mips32_instr_addiu:
-      ldq     t2,8(a1)
-      ldq     t0,24(a1)
-      ldq     t3,16(a1)
-      ldl     t1,0(t2)
-      addq    t0,t1,t0
-      stl     t0,0(t3)
-      ret</pre>
-         </td>
-     </tr>
-     <tr><td><b><br>GCC 3.4.4 on AMD64:</b></td>
-     <tr>
-         <td valign="top">
- <pre>mips_instr_addiu:
-      mov    0x8(%rsi),%rdx
-      mov    0x18(%rsi),%rax
-      mov    0x10(%rsi),%rcx
-      add    (%rdx),%eax
-      cltq
-      mov    %rax,(%rcx)
-      retq</pre>
-         </td>
-         <td></td>
-         <td valign="top">
- <pre>mips32_instr_addiu:
-      mov    0x8(%rsi),%rcx
-      mov    0x10(%rsi),%rdx
-      mov    (%rcx),%eax
-      add    0x18(%rsi),%eax
-      mov    %eax,(%rdx)
-      retq</pre>
-         </td>
-     </tr>
-     <tr><td><b><br>GCC 4.0.1 on i386:</b></td>
-     <tr>
-         <td valign="top">
- <pre>mips_instr_addiu:
-      mov    0x8(%esp),%eax
-      mov    0x8(%eax),%ecx
-      mov    0x4(%eax),%edx
-      mov    0xc(%eax),%eax
-      add    (%edx),%eax
-      mov    %eax,(%ecx)
-      cltd
-      mov    %edx,0x4(%ecx)
-      ret</pre>
-         </td>
-         <td></td>
-         <td valign="top">
- <pre>mips32_instr_addiu:
-      mov    0x8(%esp),%eax
-      mov    0x8(%eax),%ecx
-      mov    0x4(%eax),%edx
-      mov    0xc(%eax),%eax
-      add    (%edx),%eax
-      mov    %eax,(%ecx)
-      ret</pre>
-         </td>
-     </tr>
- </table></center>
- <p>On 64-bit hosts, there is not much difference, but on 32-bit hosts (and
- to some extent on AMD64), the difference is enough to make it worthwhile.
- <p><b>Performance:</b>
- <p>The performance of using this kind of runnable IR is obviously lower
- than what can be achieved by emulators using native code generation, but
- can be significantly higher than using a naive fetch-decode-execute
- interpretation loop. In my opinion, using a runnable IR is an interesting
- compromise.
- <p>The overhead per emulated instruction is usually around or below
- approximately 10 host instructions. This is very much dependent on your
- host architecture and what compiler and compiler switches you are using.
- Added to this instruction count is (of course) also the C code used to
- implement each specific instruction.
- <p><b>Instruction Combinations:</b>
- <p>Short, common instruction sequences can sometimes be replaced by a
- "compound" instruction. An example could be a compare instruction followed
- by a conditional branch instruction. The advantages of instruction
- combinations are that
- <ul>
-   <li>the amortized overhead per instruction is slightly reduced, and
-   <p>
-   <li>the host's compiler can make a good job at optimizing the common
-         instruction sequence.
- </ul>
- <p>The special cases where instruction combinations give the most gain
- are in the cores of string/memory manipulation functions such as
- <tt>memset()</tt> or <tt>strlen()</tt>. The core loop can then (at least
- to some extent) be replaced by a native call to the equivalent function.
- <p>The implementations of compound instructions still keep track of the
- number of executed instructions, etc. When single-stepping, these
- translations are invalidated, and replaced by normal instruction calls
- (one per emulated instruction).
- <p><b>Native Code Back-ends: (not in this release)</b>
- <p>In theory, it will be possible to implement native code generation
- (similar to what is used in high-performance emulators such as QEMU),
- as long as that generated code abides to the C ABI on the host, but
- for now I wanted to make sure that GXemul works without such native
- code back-ends. For this reason, since release 0.4.0, GXemul is
- completely free of native code back-ends.
  <p><br>
-Line 495 
 are emulated well enough to run at least
+Line 354 
 are emulated well enough to run at least
      <li><b>Acer Pica-61</b> (<a href="guestoses.html#netbsdarcinstall">NetBSD/arc</a>)
      <li><b>NEC MobilePro 770, 780, 800, 880</b> (<a href="guestoses.html#netbsdhpcmipsinstall">NetBSD/hpcmips</a>)
      <li><b>Cobalt</b> (<a href="guestoses.html#netbsdcobaltinstall">NetBSD/cobalt</a>)
-     <li><b>Malta</b> (<a href="guestoses.html#netbsdevbmipsinstall">NetBSD/evbmips</a>)
+     <li><b>Malta</b> (<a href="guestoses.html#netbsdevbmipsinstall">NetBSD/evbmips</a>, Linux/Malta <font color="#0000e0">(<super>*1</super>)</font>)
      <li><b>Algorithmics P5064</b> (<a href="guestoses.html#netbsdalgorinstall">NetBSD/algor</a>)
-     <li><b>SGI O2 (aka IP32)</b> <font color="#0000e0">(<super>*1</super>)</font>
+     <li><b>SGI O2 (aka IP32)</b> <font color="#0000e0">(<super>*2</super>)</font>
          (<a href="guestoses.html#netbsdsgimips">NetBSD/sgi</a>)
    </ul>
    <p>
    <li><b><u>PowerPC</u></b>
    <ul>
      <li><b>IBM 6050/6070 (PReP, PowerPC Reference Platform)</b> (<a href="guestoses.html#netbsdprepinstall">NetBSD/prep</a>)
+     <li><b>MacPPC (generic "G4" Macintosh)</b> (<a href="guestoses.html#netbsdmacppcinstall">NetBSD/macppc</a>)
+     <li><b>Artesyn PM/PPC</b> <font color="#0000e0">(<super>*2</super>)</font>
+         (<a href="guestoses.html#netbsdpmppc">NetBSD/pmppc</a>)
    </ul>
    <p>
    <li><b><u>SuperH</u></b>
    <ul>
-     <li><b>Sega Dreamcast</b>
+     <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>)
-         <font color="#0000e0">(<super>*2</super>)</font>
+     <li><b>Landisk I-O DATA USL-5P</b> (<a href="guestoses.html#openbsdlandiskinstall">OpenBSD/landisk</a>)
-         (<a href="guestoses.html#netbsddreamcast">NetBSD/dreamcast</a>)
    </ul>
  </ul>
  <p>
  <small><font color="#0000e0">(<super>*1</super>)</font> =
- Enough for root-on-nfs, but not for disk boot.</small>
+ Linux/Malta may be run as a guest OS, however I have not yet found any stable
+ URL to pre-compiled Linux/Malta kernels. Thus, Linux/Malta emulation is not
+ tested for every release of the emulator; sometimes it works, sometimes
+ it doesn't.</small>
  <br><small><font color="#0000e0">(<super>*2</super>)</font> =
- Only enough to reach ramdisk userland; no root-on-nfs yet.</small>
+ The emulation is enough for root-on-nfs, but no disk controller (SCSI nor
+ IDE) is emulated yet for this machine type.</small>
+ <p>Note that of all of the machines above, none of them is emulated to
+%. The most complete emulation mode is probably the DECstation
+/200. Things that will most likely <b>not</b> work include running
+ raw PROM images for most machines, SGI IRIX, MacOS X or Darwin, Windows
+ NT, or Dreamcast games.
- <p>There is code in GXemul for emulation of many other machine types; the
+ <p>There is code in GXemul for emulation of several other machine types; the
  degree to which these work range from almost being able to run a complete
- OS, to almost completely unsupported (perhaps just enough support to
+ OS, to almost completely unsupported, perhaps just enough support to
- output a few boot messages via serial console).
+ output a few boot messages via serial console. (See the end of
+ <a href="guestoses.html#generalnotes">this section</a> on the Guest OSes
+ page for some examples, but remember that these do not necessarily work.)
  <p>In addition to emulating real machines, there is also a "test-machine".
  A test-machine consists of one or more CPUs and a few experimental devices
-Line 536 
 such as:
+Line 410 
 such as:
    <li>a very simple linear framebuffer device (for graphics output)
    <li>a simple disk controller
    <li>a simple ethernet controller
+   <li>a simple interrupt controller
    <li>a real-time clock device
  </ul>

 Legend:



Removed from v.32
 


changed lines


 
Added in v.44
 Legend:



Removed from v.32
 


changed lines


 
Added in v.44
-Removed from v.32
+Added in v.44

	ViewVC Help
Powered by ViewVC 1.1.26