[Qemu-devel] qustion about x86 sse insn "lddqu"

[Qemu-devel] qustion about x86 sse insn "lddqu"

[Hui Zhu]

Hi,

In qemu 0.11.0, it handle lddqu as:
        case 0x3f0: /* lddqu */
            if (mod == 3)
                goto illegal_op;
            gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
            gen_sto_env_A0(s->mem_index, offsetof(CPUX86State,xmm_regs[reg]));
            break;
It st the value of xmm[reg] to address A0, right?

But in intel doc about this insn:
LDDQU—Load Unaligned Integer 128 Bits
The instruction is functionally similar to MOVDQU xmm, m128 for loading from
memory. That is: 16 bytes of data starting at an address specified by the source
memory operand (second operand) are fetched from memory and placed in
a destination
register (first operand). The source operand need not be aligned on a 16-byte
boundary. Up to 32 bytes may be loaded from memory; this is implementation
dependent.

Did I miss something? Or this code have some bug?

Thanks,
Hui

Re: [Qemu-devel] qustion about x86 sse insn "lddqu"

[Aurelien Jarno]

On Thu, Dec 03, 2009 at 01:29:23PM +0800, Hui Zhu wrote:
> Hi,
> 
> In qemu 0.11.0, it handle lddqu as:
>         case 0x3f0: /* lddqu */
>             if (mod == 3)
>                 goto illegal_op;
>             gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
>             gen_sto_env_A0(s->mem_index, offsetof(CPUX86State,xmm_regs[reg]));
>             break;
> It st the value of xmm[reg] to address A0, right?
> 
> But in intel doc about this insn:
> LDDQU—Load Unaligned Integer 128 Bits
> The instruction is functionally similar to MOVDQU xmm, m128 for loading from
> memory. That is: 16 bytes of data starting at an address specified by the source
> memory operand (second operand) are fetched from memory and placed in
> a destination
> register (first operand). The source operand need not be aligned on a 16-byte
> boundary. Up to 32 bytes may be loaded from memory; this is implementation
> dependent.
> 
> Did I miss something? Or this code have some bug?
> 

The patch is indeed wrong, I have just committed a patch to fix the
problem.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net