This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: PATCH: Move operand/address-size override prefixes before SIMD prefix


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]