/[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 21 by dpavlin, Mon Oct 8 16:19:23 2007 UTC revision 22 by dpavlin, Mon Oct 8 16:19:37 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.67 2005/11/24 12:32:10 debug Exp $  $Id: technical.html,v 1.72 2006/02/18 15:18:15 debug Exp $
14    
15  Copyright (C) 2004-2005  Anders Gavare.  All rights reserved.  Copyright (C) 2004-2006  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 108  different kinds of emulation, so these m Line 108  different kinds of emulation, so these m
108          line option.)          line option.)
109    <p>    <p>
110    <li><b>All other modes:</b><br>    <li><b>All other modes:</b><br>
111          These use a kind of dynamic translation system. (This system does          These use a kind of dynamic translation system. This system does
112          not use host-specific backends, so it is not "recompilation" or          not recompile anything into native code, it only uses tables of
113          anything like that.) Speed is slower than real binary translation,          pointers to functions written in (sometimes machine-generated) C
114          but faster than traditional interpretation, and with some tricks          code. Speed is lower than what can be achieved using real binary
115          it will hopefully still give reasonable speed. The ARM and PowerPC          translation into native code, but higher than when traditional
116          emulation modes uses this kind of translation.          interpretation is used. With some tricks, it will hopefully still
117            give reasonable speed. The ARM and PowerPC
118            emulation modes use this kind of translation.
119  </ul>  </ul>
120    
121    
# Line 330  fragmentation issue mentioned above. Line 332  fragmentation issue mentioned above.
332    
333  Each file called <tt>dev_*.c</tt> in the <tt>src/device/</tt> directory is  Each file called <tt>dev_*.c</tt> in the <tt>src/device/</tt> directory is
334  responsible for one hardware device. These are used from  responsible for one hardware device. These are used from
335  <tt>src/machine.c</tt>, when initializing which hardware a particular  <tt>src/machines/machine_*.c</tt>, when initializing which hardware a particular
336  machine model will be using, or when adding devices to a machine using the  machine model will be using, or when adding devices to a machine using the
337  <tt>device()</tt> command in configuration files.  <tt>device()</tt> command in configuration files.
338    
# Line 345  actually compile and run.) Line 347  actually compile and run.)
347    <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
348          would typically look something like this:          would typically look something like this:
349  <pre>  <pre>
350          /*          DEVINIT(foo)
          *  devinit_foo():  
          */  
         int devinit_foo(struct devinit *devinit)  
351          {          {
352                  struct foo_data *d = malloc(sizeof(struct foo_data));                  struct foo_data *d = malloc(sizeof(struct foo_data));
353    
# Line 356  actually compile and run.) Line 355  actually compile and run.)
355                          fprintf(stderr, "out of memory\n");                          fprintf(stderr, "out of memory\n");
356                          exit(1);                          exit(1);
357                  }                  }
358                  memset(d, 0, sizeof(struct foon_data));                  memset(d, 0, sizeof(struct foo_data));
359    
360                  /*                  /*
361                   *  Set up stuff here, for example fill d with useful                   *  Set up stuff here, for example fill d with useful
# Line 380  actually compile and run.) Line 379  actually compile and run.)
379          }                }      
380  </pre><br>  </pre><br>
381    
382            <p><tt>DEVINIT(foo)</tt> is defined as <tt>int devinit_foo(struct devinit *devinit)</tt>,
383            and the <tt>devinit</tt> argument contains everything that the device driver's
384            initialization function needs.
385    
386      <p>
387    <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
388          should be defined.          should be defined.
389  <pre>  <pre>
# Line 423  actually compile and run.) Line 427  actually compile and run.)
427    <p>    <p>
428    <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.
429          The access function is called whenever there is a load or store          The access function is called whenever there is a load or store
430          to an address which is in the device' memory mapped region.          to an address which is in the device' memory mapped region. To
431  <pre>          simplify things a little, a macro <tt>DEVICE_ACCESS(x)</tt>
432          int dev_foo_access(struct cpu *cpu, struct memory *mem,          is expanded into<pre>
433            int dev_x_access(struct cpu *cpu, struct memory *mem,
434              uint64_t relative_addr, unsigned char *data, size_t len,              uint64_t relative_addr, unsigned char *data, size_t len,
435              int writeflag, void *extra)              int writeflag, void *extra)
436    </pre>  The access function can look like this:
437    <pre>
438            DEVICE_ACCESS(foo)
439          {          {
440                  struct foo_data *d = extra;                  struct foo_data *d = extra;
441                  uint64_t idata = 0, odata = 0;                  uint64_t idata = 0, odata = 0;

Legend:
Removed from v.21  
changed lines
  Added in v.22

  ViewVC Help
Powered by ViewVC 1.1.26