[Qemu-devel] TCG is hard to understand!

[Qemu-devel] TCG is hard to understand!

[Jun Koi]

Hi,

I am trying to understand how TCG works. For example, I look at the
LLDT insn on x86.

In target-i386/translate.c, we translate LLDT to TCG code, like below:


static TCGv_i32 cpu_tmp2_i32;                                      // 1
...
gen_ldst_modrm(s, modrm, OT_WORD, OR_TMP0, 0);   // 2
gen_jmp_im(pc_start - s->cs_base);                                // 3
tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);                // 4
gen_helper_lldt(cpu_tmp2_i32);                                       // 5


This is quite confused. I understand that:

- In line (2), we retrieve the operand and save it into cpu_T[0].

- Line (3) generates jump code, but I dont understand why we need that ????

- Line (4) generate the code to copy cpu_T[0] to the (local) variable
cpu_tmp2_i32.
However, as tcg_gen_trunc_tl_i32() put the *value* of that variable,
but not its *address*, into the generated code, I dont see how next
line (5) can generate code that use the same variable.
Clearly there is no connection between cpu_tmp2_i32 on line (4) and
line (5), so how the generated code works here??

Thanks a lot,
Jun

Re: [Qemu-devel] TCG is hard to understand!

[Andreas Färber]

Hi,

Am 10.12.2009 um 17:44 schrieb Jun Koi:

> I am trying to understand how TCG works. For example, I look at the
> LLDT insn on x86.
>
> In target-i386/translate.c, we translate LLDT to TCG code, like below:
>
>
> static TCGv_i32  
> cpu_tmp2_i32;                                      // 1
> ...
> gen_ldst_modrm(s, modrm, OT_WORD, OR_TMP0, 0);   // 2
> gen_jmp_im(pc_start - s->cs_base);                                // 3
> tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);                // 4
> gen_helper_lldt 
> (cpu_tmp2_i32);                                       // 5
>
>
> This is quite confused. I understand that:
[...]
> - Line (4) generate the code to copy cpu_T[0] to the (local) variable
> cpu_tmp2_i32.
> However, as tcg_gen_trunc_tl_i32() put the *value* of that variable,
> but not its *address*, into the generated code, I dont see how next
> line (5) can generate code that use the same variable.
> Clearly there is no connection between cpu_tmp2_i32 on line (4) and
> line (5), so how the generated code works here??

Line 4 generates code to truncate the value from the source associated  
with cpu_T[0] and put it into the destination associated with  
cpu_tmp2_i32, which may be a general-purpose register on PowerPC for  
instance (i.e., not an address). The connection between line 4 and 5  
is that cpu_tmp2_i32 has as its value the same identifier (sort of a  
handle), allowing TCG internal code to lookup its location.

Btw if the code confuses you, cpu_T[n] is actually a leftover from the  
dyngen to TCG conversion. Feel free to provide patches replacing the  
remaining occurrences by individual local TCG variables if it helps  
your understanding. :)

Andreas

Re: [Qemu-devel] TCG is hard to understand!

[Jun Koi]

On Fri, Dec 11, 2009 at 7:21 AM, Andreas Färber <andreas.faerber@web.de> wrote:
> Hi,
>
> Am 10.12.2009 um 17:44 schrieb Jun Koi:
>
>> I am trying to understand how TCG works. For example, I look at the
>> LLDT insn on x86.
>>
>> In target-i386/translate.c, we translate LLDT to TCG code, like below:
>>
>>
>> static TCGv_i32 cpu_tmp2_i32;                                      // 1
>> ...
>> gen_ldst_modrm(s, modrm, OT_WORD, OR_TMP0, 0);   // 2
>> gen_jmp_im(pc_start - s->cs_base);                                // 3
>> tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);                // 4
>> gen_helper_lldt(cpu_tmp2_i32);                                       // 5
>>
>>
>> This is quite confused. I understand that:
>
> [...]
>>
>> - Line (4) generate the code to copy cpu_T[0] to the (local) variable
>> cpu_tmp2_i32.
>> However, as tcg_gen_trunc_tl_i32() put the *value* of that variable,
>> but not its *address*, into the generated code, I dont see how next
>> line (5) can generate code that use the same variable.
>> Clearly there is no connection between cpu_tmp2_i32 on line (4) and
>> line (5), so how the generated code works here??
>
> Line 4 generates code to truncate the value from the source associated with
> cpu_T[0] and put it into the destination associated with cpu_tmp2_i32, which
> may be a general-purpose register on PowerPC for instance (i.e., not an
> address). The connection between line 4 and 5 is that cpu_tmp2_i32 has as
> its value the same identifier (sort of a handle), allowing TCG internal code
> to lookup its location.
>
> Btw if the code confuses you, cpu_T[n] is actually a leftover from the
> dyngen to TCG conversion. Feel free to provide patches replacing the
> remaining occurrences by individual local TCG variables if it helps your
> understanding. :)
>

Thanks a lot for the insight! Now it is quite clear to me.

However, I still dont understand what the line (3) does. Could you
give some hints?

>> static TCGv_i32 cpu_tmp2_i32;                                      // 1
>> ...
>> gen_ldst_modrm(s, modrm, OT_WORD, OR_TMP0, 0);   // 2
>> gen_jmp_im(pc_start - s->cs_base);                                // 3
>> tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);                // 4
>> gen_helper_lldt(cpu_tmp2_i32);                                       // 5


Thanks,
Jun

Re: [Qemu-devel] TCG is hard to understand!

[Alexander Graf]

On 11.12.2009, at 03:34, Jun Koi wrote:

> On Fri, Dec 11, 2009 at 7:21 AM, Andreas Färber <andreas.faerber@web.de> wrote:
>> Hi,
>> 
>> Am 10.12.2009 um 17:44 schrieb Jun Koi:
>> 
>>> I am trying to understand how TCG works. For example, I look at the
>>> LLDT insn on x86.
>>> 
>>> In target-i386/translate.c, we translate LLDT to TCG code, like below:
>>> 
>>> 
>>> static TCGv_i32 cpu_tmp2_i32;                                      // 1
>>> ...
>>> gen_ldst_modrm(s, modrm, OT_WORD, OR_TMP0, 0);   // 2
>>> gen_jmp_im(pc_start - s->cs_base);                                // 3
>>> tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);                // 4
>>> gen_helper_lldt(cpu_tmp2_i32);                                       // 5
>>> 
>>> 
>>> This is quite confused. I understand that:
>> 
>> [...]
>>> 
>>> - Line (4) generate the code to copy cpu_T[0] to the (local) variable
>>> cpu_tmp2_i32.
>>> However, as tcg_gen_trunc_tl_i32() put the *value* of that variable,
>>> but not its *address*, into the generated code, I dont see how next
>>> line (5) can generate code that use the same variable.
>>> Clearly there is no connection between cpu_tmp2_i32 on line (4) and
>>> line (5), so how the generated code works here??
>> 
>> Line 4 generates code to truncate the value from the source associated with
>> cpu_T[0] and put it into the destination associated with cpu_tmp2_i32, which
>> may be a general-purpose register on PowerPC for instance (i.e., not an
>> address). The connection between line 4 and 5 is that cpu_tmp2_i32 has as
>> its value the same identifier (sort of a handle), allowing TCG internal code
>> to lookup its location.
>> 
>> Btw if the code confuses you, cpu_T[n] is actually a leftover from the
>> dyngen to TCG conversion. Feel free to provide patches replacing the
>> remaining occurrences by individual local TCG variables if it helps your
>> understanding. :)
>> 
> 
> Thanks a lot for the insight! Now it is quite clear to me.
> 
> However, I still dont understand what the line (3) does. Could you
> give some hints?
> 
>>> static TCGv_i32 cpu_tmp2_i32;                                      // 1
>>> ...
>>> gen_ldst_modrm(s, modrm, OT_WORD, OR_TMP0, 0);   // 2
>>> gen_jmp_im(pc_start - s->cs_base);                                // 3

This sets the position counter to the current address. That's important in case a helper command calls an exception, because only then the unrolling works and the IP is actually at the instruction we're processing.

Alex

Re: [Qemu-devel] TCG is hard to understand!

[Jun Koi]

Hi Alex,

>> However, I still dont understand what the line (3) does. Could you
>> give some hints?
>>
>>>> static TCGv_i32 cpu_tmp2_i32;                                      // 1
>>>> ...
>>>> gen_ldst_modrm(s, modrm, OT_WORD, OR_TMP0, 0);   // 2
>>>> gen_jmp_im(pc_start - s->cs_base);                                // 3
>
> This sets the position counter to the current address. That's important in 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

Re: [Qemu-devel] TCG is hard to understand!

[Laurent Desnogues]

On Fri, Dec 11, 2009 at 4:18 AM, Jun Koi <junkoi2004@gmail.com> wrote:
>
> 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?

Take a look at tcg.c:tcg_reg_alloc_call


Laurent

Re: [Qemu-devel] TCG is hard to understand!

[Jun Koi]

On Fri, Dec 11, 2009 at 4:36 PM, Laurent Desnogues
<laurent.desnogues@gmail.com> wrote:
> On Fri, Dec 11, 2009 at 4:18 AM, Jun Koi <junkoi2004@gmail.com> wrote:
>>
>> 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?
>
> Take a look at tcg.c:tcg_reg_alloc_call
>

Now I see how TCG manipulates the stack memory there.

Thanks,
J