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

Diff of /trunk/doc/technical.html

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 14 by dpavlin, Mon Oct 8 16:18:51 2007 UTC revision 42 by dpavlin, Mon Oct 8 16:22:32 2007 UTC
# Line 4  Line 4 
4  <table border=0 width=100% bgcolor="#d0d0d0"><tr>  <table border=0 width=100% bgcolor="#d0d0d0"><tr>
5  <td width=100% align=center valign=center><table border=0 width=100%><tr>  <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">  <td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6">
7  <b>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;</b></font>  <b>Gavare's eXperimental Emulator:</b></font><br>
8  <font color="#000000" size="6"><b>Technical details</b>  <font color="#000000" size="6"><b>Technical details</b>
9  </font></td></tr></table></td></tr></table><p>  </font></td></tr></table></td></tr></table><p>
10    
11  <!--  <!--
12    
13  $Id: technical.html,v 1.63 2005/10/07 15:10:00 debug Exp $  $Id: technical.html,v 1.76 2007/06/15 18:07:08 debug Exp $
14    
15  Copyright (C) 2004-2005  Anders Gavare.  All rights reserved.  Copyright (C) 2004-2007  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:
# Line 70  because the host architecture and emulat Line 70  because the host architecture and emulat
70  compared just like that.  compared just like that.
71    
72  <p>Performance depends on several factors, including (but not limited to)    <p>Performance depends on several factors, including (but not limited to)  
73  host architecture, host clock speed, which compiler and compiler flags  host architecture, target architecture, host clock speed, which compiler
74  were used to build the emulator, what the workload is, and so on. For  and compiler flags were used to build the emulator, what the workload is,
75  example, if an emulated operating system tries to read a block from disk,  what additional runtime flags are given to the emulator, and so on.
76  from its point of view the read was instantaneous (no waiting). So 1 MIPS  
77  in an emulated OS might have taken more than one million instructions on a  <p>Devices are generally not timing-accurate: for example, if an emulated
78  real machine.  operating system tries to read a block from disk, from its point of view
79    the read was instantaneous (no waiting). So 1 MIPS in an emulated OS might
80    have taken more than one million instructions on a real machine.
81    
82  <p>Also, if the emulator says it has executed 1 million instructions, and  <p>Also, if the emulator says it has executed 1 million instructions, and
83  the CPU family in question was capable of scalar execution (i.e. one cycle  the CPU family in question was capable of scalar execution (i.e. one cycle
# Line 85  penalties that are not simulated by GXem Line 87  penalties that are not simulated by GXem
87    
88  <p>Because of these issues, it is in my opinion best to measure  <p>Because of these issues, it is in my opinion best to measure
89  performance as the actual (real-world) time it takes to perform a task  performance as the actual (real-world) time it takes to perform a task
90  with the emulator. Typical examples would be "How long does it take to  with the emulator, e.g.:
 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.)  
91    
92  <ul>  <ul>
93    <li><b>MIPS:</b><br>    <li>"How long does it take to install NetBSD onto a disk image?"
94          There are two emulation modes. The most important one is an    <li>"How long does it take to compile XYZ inside NetBSD
95          implementation of a <i>dynamic binary translator</i>.          in the emulator?".
         (Compared to real binary translators, though, GXemul's bintrans  
         subsystem is very simple and does not perform very well.)  
         This mode can be used on Alpha and i386 host. The other emulation  
         mode is simple interpretation, where an instruction is read from  
         emulated memory, and interpreted one-at-a-time. (Slow, but it  
         works. It can be forcefully used by using the <tt>-B</tt> command  
         line option.)  
   <p>  
   <li><b>All other modes:</b><br>  
         These use a kind of dynamic translation system. (This system does  
         not use host-specific backends, so it is not "recompilation" or  
         anything like that.) Speed is slower than real binary translation,  
         but faster than traditional interpretation, and with some tricks  
         it will hopefully still give reasonable speed. ARM emulation uses  
         this kind of translation, for example.  
96  </ul>  </ul>
97    
98    <p>So, how fast is it? :-)&nbsp;&nbsp;&nbsp;Answer: it varies.
99    
100    
101    
102    
103    
# Line 125  different kinds of emulation, so these m Line 107  different kinds of emulation, so these m
107  <a name="net"></a>  <a name="net"></a>
108  <h3>Networking</h3>  <h3>Networking</h3>
109    
110  <font color="#ff0000">NOTE/TODO: This section is very old and a bit  <font color="#ff0000">NOTE/TODO: This section is very old.</font>
 out of date.</font>  
111    
112  <p>Running an entire operating system under emulation is very interesting  <p>Running an entire operating system under emulation is very interesting
113  in itself, but for several reasons, running a modern OS without access to  in itself, but for several reasons, running a modern OS without access to
# Line 318  a CDROM ISO image. You can use a read-wr Line 299  a CDROM ISO image. You can use a read-wr
299  files in both directions, but then you should be aware of the  files in both directions, but then you should be aware of the
300  fragmentation issue mentioned above.  fragmentation issue mentioned above.
301    
 <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.)  
302    
303    
304    
# Line 331  commands.) Line 309  commands.)
309  <a name="devices"></a>  <a name="devices"></a>
310  <h3>Emulation of hardware devices</h3>  <h3>Emulation of hardware devices</h3>
311    
312  Each file in the <tt>src/device/</tt> directory is responsible for one  Each file called <tt>dev_*.c</tt> in the
313  hardware device. These are used from <tt>src/machine.c</tt>, when  <a href="../src/devices/"><tt>src/devices/</tt></a> directory is
314  initializing which hardware a particular machine model will be using, or  responsible for one hardware device. These are used from
315  when adding devices to a machine using the <tt>device()</tt> command in  <a href="../src/machines/"><tt>src/machines</tt></a><tt>/machine_*.c</tt>,
316  configuration files.  when initializing which hardware a particular machine model will be using,
317    or when adding devices to a machine using the <tt>device()</tt> command in
318  <p><font color="#ff0000">NOTE: The device registry subsystem is currently  <a href="configfiles.html">configuration files</a>.
 in a state of flux, as it is being redesigned.</font>  
319    
320  <p>(I'll be using the name "<tt>foo</tt>" as the name of the device in all  <p>(I'll be using the name "<tt>foo</tt>" as the name of the device in all
321  these examples.  This is pseudo code, it might need some modification to  these examples.  This is pseudo code, it might need some modification to
# Line 351  actually compile and run.) Line 328  actually compile and run.)
328    <li>A <tt>devinit</tt> function in <tt>src/devices/dev_foo.c</tt>. It    <li>A <tt>devinit</tt> function in <tt>src/devices/dev_foo.c</tt>. It
329          would typically look something like this:          would typically look something like this:
330  <pre>  <pre>
331          /*          DEVINIT(foo)
          *  devinit_foo():  
          */  
         int devinit_foo(struct devinit *devinit)  
332          {          {
333                  struct foo_data *d = malloc(sizeof(struct foo_data));                  struct foo_data *d;
334    
335                  if (d == NULL) {                  CHECK_ALLOCATION(d = malloc(sizeof(struct foo_data)));
336                          fprintf(stderr, "out of memory\n");                  memset(d, 0, sizeof(struct foo_data));
                         exit(1);  
                 }  
                 memset(d, 0, sizeof(struct foon_data));  
337    
338                  /*                  /*
339                   *  Set up stuff here, for example fill d with useful                   *  Set up stuff here, for example fill d with useful
340                   *  data. devinit contains settings like address, irq_nr,                   *  data. devinit contains settings like address, irq path,
341                   *  and other things.                   *  and other things.
342                   *                   *
343                   *  ...                   *  ...
344                   */                   */
345    
346                    INTERRUPT_CONNECT(devinit->interrupt_path, d->irq);
347                    
348                  memory_device_register(devinit->machine->memory, devinit->name,                  memory_device_register(devinit->machine->memory, devinit->name,
349                      devinit->addr, DEV_FOO_LENGTH,                      devinit->addr, DEV_FOO_LENGTH,
350                      dev_foo_access, (void *)d, MEM_DEFAULT, NULL);                      dev_foo_access, (void *)d, DM_DEFAULT, NULL);
351                    
352                  /*  This should only be here if the device                  /*  This should only be here if the device
353                      has a tick function:  */                      has a tick function:  */
# Line 386  actually compile and run.) Line 359  actually compile and run.)
359          }                }      
360  </pre><br>  </pre><br>
361    
362            <p><tt>DEVINIT(foo)</tt> is defined as <tt>int devinit_foo(struct devinit *devinit)</tt>,
363            and the <tt>devinit</tt> argument contains everything that the device driver's
364            initialization function needs.
365    
366      <p>
367    <li>At the top of <tt>dev_foo.c</tt>, the <tt>foo_data</tt> struct    <li>At the top of <tt>dev_foo.c</tt>, the <tt>foo_data</tt> struct
368          should be defined.          should be defined.
369  <pre>  <pre>
370          struct foo_data {          struct foo_data {
371                  int     irq_nr;                  struct interrupt        irq;
372                  /*  ...  */                  /*  ...  */
373          }          }
374  </pre><br>  </pre><br>
375            (There is an exception to this rule; some legacy code and other
376            ugly hacks have their device structs defined in
377            <tt>src/include/devices.h</tt> instead of <tt>dev_foo.c</tt>.
378            New code should not add stuff to <tt>devices.h</tt>.)
379      <p>
380    <li>If <tt>foo</tt> has a tick function (that is, something that needs to be    <li>If <tt>foo</tt> has a tick function (that is, something that needs to be
381          run at regular intervals) then <tt>FOO_TICKSHIFT</tt> and a tick          run at regular intervals) then <tt>FOO_TICKSHIFT</tt> and a tick
382          function need to be defined as well:          function need to be defined as well:
383  <pre>  <pre>
384          #define FOO_TICKSHIFT           10          #define FOO_TICKSHIFT           14
385    
386          void dev_foo_tick(struct cpu *cpu, void *extra)          DEVICE_TICK(foo)
387          {          {
388                  struct foo_data *d = (struct foo_data *) extra;                  struct foo_data *d = extra;
389    
390                  if (.....)                  if (.....)
391                          cpu_interrupt(cpu, d->irq_nr);                          INTERRUPT_ASSERT(d->irq);
392                  else                  else
393                          cpu_interrupt_ack(cpu, d->irq_nr);                          INTERRUPT_DEASSERT(d->irq);
394          }          }
395  </pre><br>  </pre><br>
396    
397      <li>Does this device belong to a standard bus?
398            <ul>
399              <li>If this device should be detectable as a PCI device, then
400                    glue code should be added to
401                    <tt>src/devices/bus_pci.c</tt>.
402              <li>If this is a legacy ISA device which should be usable by
403                    any machine which has an ISA bus, then the device should
404                    be added to <tt>src/devices/bus_isa.c</tt>.
405            </ul>
406      <p>
407    <li>And last but not least, the device should have an access function.    <li>And last but not least, the device should have an access function.
408          The access function is called whenever there is a load or store          The access function is called whenever there is a load or store
409          to an address which is in the device' memory mapped region.          to an address which is in the device' memory mapped region. To
410  <pre>          simplify things a little, a macro <tt>DEVICE_ACCESS(x)</tt>
411          int dev_foo_access(struct cpu *cpu, struct memory *mem,          is expanded into<pre>
412            int dev_x_access(struct cpu *cpu, struct memory *mem,
413              uint64_t relative_addr, unsigned char *data, size_t len,              uint64_t relative_addr, unsigned char *data, size_t len,
414              int writeflag, void *extra)              int writeflag, void *extra)
415    </pre>  The access function can look like this:
416    <pre>
417            DEVICE_ACCESS(foo)
418          {          {
419                  struct foo_data *d = extra;                  struct foo_data *d = extra;
420                  uint64_t idata = 0, odata = 0;                  uint64_t idata = 0, odata = 0;
421    
422                  idata = memory_readmax64(cpu, data, len);                  if (writeflag == MEM_WRITE)
423                            idata = memory_readmax64(cpu, data, len);
424    
425                  switch (relative_addr) {                  switch (relative_addr) {
426                  /* .... */  
427                    /*  Handle accesses to individual addresses within
428                        the device here.  */
429    
430                    /*  ...  */
431    
432                  }                  }
433    
434                  if (writeflag == MEM_READ)                  if (writeflag == MEM_READ)
Legend:
Removed from v.14  
changed lines
  Added in v.42
  ViewVC Help
Powered by ViewVC 1.1.26