qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Fabrice Bellard
Subject: Re: [Qemu-devel] understanding how arpl is translated
Date: Tue, 13 May 2008 19:59:20 +0200
User-agent: Thunderbird 1.5.0.9 (X11/20070212)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]