https://sourceware.org/bugzilla/show_bug.cgi?id=33893
--- Comment #10 from Craaijo, Jos <jos.craaijo at ou dot nl> --- Created attachment 16662 --> https://sourceware.org/bugzilla/attachment.cgi?id=16662&action=edit Patch to fix operand type for movq2dq and movdq2q I have started working on this. It looks like there are actually two separate bugs: 1) movq2dq and movdq2q should always take one mmx and one xmm argument. This is specified by the manuals. I have attached a patch for this bug, which changes one of the operand types in the prefix table to always be an MMX register. 2) The REP prefix should take priority over the DATA prefix. As far as I can tell this is not explicitly specified in the reference manuals, but both CPUs and other disassemblers do give priority to REP over DATA. For example, when disassembling F2660FD0C1 in various disassemblers libopcodes is the odd-one-out: opcodes: "addsubpd %xmm1,%xmm0" capstone: "addsubps %xmm1, %xmm0" XED: "addsubps xmm0, xmm1" zydis: "addsubps xmm0, xmm1" iced: "addsubps xmm0, xmm1" A test program for this behavior is: #include <stdio.h> #include <stdint.h> int main() { uint32_t in = 0x44332211; uint32_t out[4] = {0}; __asm__ volatile ( "pxor %%xmm0, %%xmm0\n\t" "movd %[input], %%xmm1\n\t" ".byte 0xF2, 0x66, 0x0F, 0xD0, 0xC1\n\t" "movdqu %%xmm0, %[output]\n\t" : [output] "=m" (out) : [input] "r" (in) : "xmm0", "xmm1" ); printf("Full xmm0: %08x %08x %08x %08x\n", out[3], out[2], out[1], out[0]); return 0; } By modifing the "0xF2, 0x66" to either "0xF2" or "0x66" you can confirm that F266 behaves as F2 and not as 66. -- You are receiving this mail because: You are on the CC list for the bug.
