[Qemu-devel] understanding how arpl is translated

[Qemu-devel] understanding how arpl is translated

[Jun Koi]

Hi,

I am trying to understand how "arpl" insn (i386) is translated. In
translate.c we have:

.....
modrm = ldub_code(s->pc++);
reg = (modrm >> 3) & 7;
mod = (modrm >> 6) & 3;
rm = modrm & 7;
if (mod != 3) {
    gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
    gen_op_ld_T0_A0(ot + s->mem_index);      // (1)  ****
} else {
    gen_op_mov_TN_reg(ot, 0, rm);                   // (2)  ****
}
if (s->cc_op != CC_OP_DYNAMIC)
    gen_op_set_cc_op(s->cc_op);
gen_op_arpl();
s->cc_op = CC_OP_EFLAGS;
...

I can see that we decrypt 2 operands of arpl and then call
gen_op_arpl(). This function finally leads to execute op_arpl(), which
is defined as:

void OPPROTO op_arpl(void)
{
    if ((T0 & 3) < (T1 & 3)) {
        /* XXX: emulate bug or 0xff3f0000 oring as in bochs ? */
        T0 = (T0 & ~3) | (T1 & 3);
        T1 = CC_Z;
   } else {
        T1 = 0;
    }
    FORCE_RET();
}

Obviously op_arpl() relies on T0 and T1 have the value of the 1st and
2nd operands of the above "arpl" insn. However, I can only see that we
copy the 1st operand into T0 at (1) or (2) in the first snippet, but I
never see when we copy 2nd operand into T1. This confuses me, or I
missed something here?

Many thanks,
Jun

Re: [Qemu-devel] understanding how arpl is translated

[Fabrice Bellard]

Jun Koi wrote:
> Hi,
> 
> I am trying to understand how "arpl" insn (i386) is translated. In
> translate.c we have:
> 
> .....
> modrm = ldub_code(s->pc++);
> reg = (modrm >> 3) & 7;
> mod = (modrm >> 6) & 3;
> rm = modrm & 7;
> if (mod != 3) {
>     gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
>     gen_op_ld_T0_A0(ot + s->mem_index);      // (1)  ****
> } else {
>     gen_op_mov_TN_reg(ot, 0, rm);                   // (2)  ****
> }
> if (s->cc_op != CC_OP_DYNAMIC)
>     gen_op_set_cc_op(s->cc_op);
> gen_op_arpl();
> s->cc_op = CC_OP_EFLAGS;
> ...
> 
> I can see that we decrypt 2 operands of arpl and then call
> gen_op_arpl(). This function finally leads to execute op_arpl(), which
> is defined as:
> 
> void OPPROTO op_arpl(void)
> {
>     if ((T0 & 3) < (T1 & 3)) {
>         /* XXX: emulate bug or 0xff3f0000 oring as in bochs ? */
>         T0 = (T0 & ~3) | (T1 & 3);
>         T1 = CC_Z;
>    } else {
>         T1 = 0;
>     }
>     FORCE_RET();
> }
> 
> Obviously op_arpl() relies on T0 and T1 have the value of the 1st and
> 2nd operands of the above "arpl" insn. However, I can only see that we
> copy the 1st operand into T0 at (1) or (2) in the first snippet, but I
> never see when we copy 2nd operand into T1. This confuses me, or I
> missed something here?

You are right. Moreover, the eflags update is also invalid because arpl
is not signaled in the opc_write_flags array...

Fabrice.

Re: [Qemu-devel] understanding how arpl is translated

[Jun Koi]

On Wed, May 14, 2008 at 2:59 AM, Fabrice Bellard <fabrice@bellard.org> wrote:
> Jun Koi wrote:
>> Hi,
>>
>> I am trying to understand how "arpl" insn (i386) is translated. In
>> translate.c we have:
>>
>> .....
>> modrm = ldub_code(s->pc++);
>> reg = (modrm >> 3) & 7;
>> mod = (modrm >> 6) & 3;
>> rm = modrm & 7;
>> if (mod != 3) {
>>     gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
>>     gen_op_ld_T0_A0(ot + s->mem_index);      // (1)  ****
>> } else {
>>     gen_op_mov_TN_reg(ot, 0, rm);                   // (2)  ****
>> }
>> if (s->cc_op != CC_OP_DYNAMIC)
>>     gen_op_set_cc_op(s->cc_op);
>> gen_op_arpl();
>> s->cc_op = CC_OP_EFLAGS;
>> ...
>>
>> I can see that we decrypt 2 operands of arpl and then call
>> gen_op_arpl(). This function finally leads to execute op_arpl(), which
>> is defined as:
>>
>> void OPPROTO op_arpl(void)
>> {
>>     if ((T0 & 3) < (T1 & 3)) {
>>         /* XXX: emulate bug or 0xff3f0000 oring as in bochs ? */
>>         T0 = (T0 & ~3) | (T1 & 3);
>>         T1 = CC_Z;
>>    } else {
>>         T1 = 0;
>>     }
>>     FORCE_RET();
>> }
>>
>> Obviously op_arpl() relies on T0 and T1 have the value of the 1st and
>> 2nd operands of the above "arpl" insn. However, I can only see that we
>> copy the 1st operand into T0 at (1) or (2) in the first snippet, but I
>> never see when we copy 2nd operand into T1. This confuses me, or I
>> missed something here?
>
> You are right. Moreover, the eflags update is also invalid because arpl
> is not signaled in the opc_write_flags array...

OK, so that means ARPL is incorrectly implemented?

No wonder why I badly struggle to understand how it works :-)

Many thanks,
Jun