On
Wed, Dec 15, 2010 at 4:17 AM, Stefano Bonifazi
<address@hidden>
wrote:
>
On 12/11/2010 03:44 PM, Blue Swirl wrote:
>
>
Hi!
>
Thank you very much! Knowing exactly where I
should check, in a so big
>
project helped me very much!!
>
Anyway after having spent more than 2 days on
that code I still can't
>
understand how it works the real execution:
>
>
in cpu-exec.c : cpu_exec_nocache i find:
>
>>
/* execute the generated code */
>>
next_tb = tcg_qemu_tb_exec(tb->tc_ptr);
>
>
and in cpu-exec.c : cpu_exec
>
>>
/* execute the generated code */
>>
>>
next_tb
= tcg_qemu_tb_exec(tc_ptr);
>
>
so I thought tcg_qemu_tb_exec "function"
should do the work of executing the
>
translated binary in the host.
>
But then I found out it is just a define in tcg.h:
>
>>
#define tcg_qemu_tb_exec(tb_ptr) ((long
REGPARM (*)(void
>>
*))code_gen_prologue)(tb_ptr)
>
>
and again in exec.c
>
>>
uint8_t code_gen_prologue[1024] code_gen_section;
>
>
Maybe I have some problems with that C syntax, but
I really don't understand
>
what happens there.. how the execution happens!
>
>
Here instead with QEMU/TCG I understood
that at runtime the target binary
>
is translated into host binary (somehow) .. but
then.. how can this new host
>
binary be run? Shall the host code at runtime do
some sort of (assembly
>
speaking) branch jump to an area of memory with
new host binary instructions
>
.. and then jump back to the old process binary
code?
1.
As I know, the host codes translated from the target
instructions exist by the format of object file, that’s
why they can be
executed directly.
2.
I think you catch the right concept in some point
of view, one part of the internal of QEMU does such jump
& back works
certainly.
>
If so, can you explain me how this happens in
those lines of code?
I
only can give a rough profile, the code you listed
do a simple thing:
Modify
the pointer of the host code execution to point
the next address that the host processor should continue
to execute.
>
I am just a student.. unluckily at university
they just tell you that a cpu
>
follows some sort of "fetch ->decode->execute"
flow .. but then you open
>
QEMU.. and wow there is a huge gap for
understanding it, and no books where
>
to study it! ;)
The
QEMU is not used to simulate the every details of
the processor should behave, it just try to approximate
the necessary
operations what a machine should be!
“fetch->decode->execute”
flow only need to be
concerned when you involve into the hardware design.
Raphaël
Lefèvre