This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: PATCH: Move operand/address-size override prefixes before SIMD prefix
- From: malc <av1474 at comtv dot ru>
- To: "Menezes, Evandro" <evandro dot menezes at amd dot com>
- Cc: Dave Korn <dave dot korn at artimi dot com>, Jan Beulich <jbeulich at novell dot com>, "H. J. Lu" <hjl at lucon dot org>, binutils at sourceware dot org
- Date: Thu, 7 Dec 2006 19:09:54 +0300 (MSK)
- Subject: RE: PATCH: Move operand/address-size override prefixes before SIMD prefix
- References: <1449F58C868D8D4E9C72945771150BDFDF4A60@SAUSEXMB1.amd.com>
On Thu, 7 Dec 2006, Menezes, Evandro wrote:
I can. This will proove exactly nothing though. I want an official
position of Intel and AMD, even if the position is that the behaviour
is unspecified that will suit me just fine.
Here's the official position by AMD:
"The result of using an F2h or F3h repeat prefix along with a
66h prefix in 128-bit or 64-bit media instructions is
unpredictable." (in "AMD64 Architecture Programmer's Manual
Volume 3: General-Purpose and System Instructions", pp. 5-6.)
HTH
Thank you, but it does not. Because presence of both 0xf2 and 0xf3 in
the byte stream is not covered by this paragraph (perhaps the
situation is explained elsewhere in the manual?)
<transcript>
pref$ cat pref.s
.text
.byte 0xf2, 0xf3, 0x0f, 0x11, 0x00
.byte 0xf3, 0xf2, 0x0f, 0x11, 0x00
pref$ as pref.s -o pref.o
pref$ objdump -d pref.o
pref.o: file format elf32-i386
Disassembly of section .text:
00000000 <.text>:
0: f2 repnz
1: f3 0f 11 00 movss %xmm0,(%eax)
5: f3 repz
6: f2 0f 11 00 movsd %xmm0,(%eax)
</transcript>
At least in this case the objdump and IDA agree on the disassembly.
Perhaps someone from Intels side care to chip in?
--
vale