From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60900 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PeTs5-0001my-IQ for qemu-devel@nongnu.org; Sun, 16 Jan 2011 09:46:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PeTs4-0008N9-CD for qemu-devel@nongnu.org; Sun, 16 Jan 2011 09:46:21 -0500 Received: from mail-gw0-f45.google.com ([74.125.83.45]:54120) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PeTs4-0008N5-77 for qemu-devel@nongnu.org; Sun, 16 Jan 2011 09:46:20 -0500 Received: by gwaa12 with SMTP id a12so1657969gwa.4 for ; Sun, 16 Jan 2011 06:46:19 -0800 (PST) From: "Raphael Lefevre" Subject: Re: [Qemu-devel] TCG flow vs dyngen Date: Sun, 16 Jan 2011 22:46:13 +0800 Message-ID: <000001cbb58c$221f5a00$011aa8c0@side35ya3cah0n> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CBB5CF.30450B00" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: stefboombastic@gmail.com Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CBB5CF.30450B00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 15, 2010 at 4:17 AM, Stefano Bonifazi = wrote: > On 12/11/2010 03:44 PM, Blue Swirl wrote: >=20 > 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: >=20 > in cpu-exec.c : cpu_exec_nocache i find: >=20 >> /* execute the generated code */ >> next_tb =3D tcg_qemu_tb_exec(tb->tc_ptr); >=20 > and in cpu-exec.c : cpu_exec >=20 >> /* execute the generated code */ >>=20 >> next_tb =3D tcg_qemu_tb_exec(tc_ptr); >=20 > 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: >=20 >> #define tcg_qemu_tb_exec(tb_ptr) ((long REGPARM (*)(void >> *))code_gen_prologue)(tb_ptr) >=20 > and again in exec.c >=20 >> uint8_t code_gen_prologue[1024] code_gen_section; >=20 > Maybe I have some problems with that C syntax, but I really don't = understand > what happens there.. how the execution happens! >=20 > 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? =20 1. As I know, the host codes translated from the target instructions = exist by the format of object file, that=E2=80=99s 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. =20 > If so, can you explain me how this happens in those lines of code? =20 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. =20 > 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! ;) =20 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! =E2=80=9Cfetch->decode->execute=E2=80=9D flow only need to be concerned = when you involve into the hardware design. =20 Rapha=C3=ABl Lef=C3=A8vre ------=_NextPart_000_0001_01CBB5CF.30450B00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

On Wed, Dec 15, 2010 at 4:17 AM, Stefano = Bonifazi <stefboombastic@gmail.com> 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 =3D = tcg_qemu_tb_exec(tb->tc_ptr);

> 

> and in cpu-exec.c : = cpu_exec

> 

>> /* execute the generated code = */

>> 

>>      &nbs= p;            = ; next_tb =3D 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=E2=80=99s 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!

=E2=80=9Cfetch->decode->execute=E2=80=9D = flow only need to be concerned when you involve into the hardware design.

 

Raphaël Lefèvre

------=_NextPart_000_0001_01CBB5CF.30450B00--