From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NIw24-0001oN-9k
	for qemu-devel@nongnu.org; Thu, 10 Dec 2009 22:19:04 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NIw1z-0001hj-3T
	for qemu-devel@nongnu.org; Thu, 10 Dec 2009 22:19:03 -0500
Received: from [199.232.76.173] (port=46896 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NIw1y-0001ha-TO
	for qemu-devel@nongnu.org; Thu, 10 Dec 2009 22:18:58 -0500
Received: from mail-px0-f189.google.com ([209.85.216.189]:63217)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <junkoi2004@gmail.com>) id 1NIw1y-0006O8-IG
	for qemu-devel@nongnu.org; Thu, 10 Dec 2009 22:18:58 -0500
Received: by pxi27 with SMTP id 27so388263pxi.4
	for <qemu-devel@nongnu.org>; Thu, 10 Dec 2009 19:18:57 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <D977842A-C628-479F-93D5-FAA6105C8372@suse.de>
References: <fdaac4d50912100844g33d8bf07g4826869dcc2d0258@mail.gmail.com>
	<4CC2A3A0-B3BC-48C2-850B-3EC92BAC4ED8@web.de>
	<fdaac4d50912101834udad1fban25a5b2a322fd7ef5@mail.gmail.com>
	<D977842A-C628-479F-93D5-FAA6105C8372@suse.de>
From: Jun Koi <junkoi2004@gmail.com>
Date: Fri, 11 Dec 2009 12:18:37 +0900
Message-ID: <fdaac4d50912101918s5c11cebardc845acf704f2a0e@mail.gmail.com>
Subject: Re: [Qemu-devel] TCG is hard to understand!
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-devel@nongnu.org

Hi Alex,

>> However, I still dont understand what the line (3) does. Could you
>> give some hints?
>>
>>>> static TCGv_i32 cpu_tmp2_i32; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// 1
>>>> ...
>>>> gen_ldst_modrm(s, modrm, OT_WORD, OR_TMP0, 0); =A0 // 2
>>>> gen_jmp_im(pc_start - s->cs_base); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0// 3
>
> This sets the position counter to the current address. That's important i=
n case a helper command calls an exception, because only then the unrolling=
 works and the IP is actually at the instruction we're processing.

This is excellent, thanks!

Another question: I look at tcg_gen_callN() to see how the helper is
executed. We put the helper opcode into the TCG code buffer, and put
helper's params into gen_opparam_buf.

However, then when TCG generates code to actually call the helper, we
just put the opcode of the host insn into the output buffer, which is
target code at this step, then run it.

Now when the helper is executed, it must get its param from the stack,
which is really the host stack. But as said above, its params are in
gen_opparam_buf, but not in stack?
I searched around, and dont see anywhere we link gen_opparam_buf with
the host stack. So how the helper can get its param??

Surely I missed something, or misunderstand the whole picture. Any hint?

Thanks a lot,
Jun