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

["Jun Koi" <junkoi2004@gmail.com>]

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