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: </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: |
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 |
|
|
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 |
|
|
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 |
|
|
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 |
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> |
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; |