This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] i386-dis: fix decoding of reserved "prefetch" encodings
On Tue, Aug 7, 2012 at 10:52 AM, Roland McGrath <mcgrathr@google.com> wrote:
> On Tue, Aug 7, 2012 at 10:34 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> Those are marked as NOPs in AMD manual and reserved in Intel
>> manual. I don't like "prefetch(bad)". I can live with "nop/reserved".
>
> Can you cite the manuals you are looking at?
>
> I'm looking at http://support.amd.com/us/Processor_TechDocs/24594_APM_v3.pdf
> on page 254:
> The reserved PREFETCH types do not result in an invalid-opcode
> exception if executed. Instead, for forward compatibility with
> future processors that may implement additional forms of the
> PREFETCH instruction, all reserved PREFETCH types are implemented
> as synonyms of the basic PREFETCH type (the PREFETCH instruction
> with type 000b).
> That says they are prefetch, not nop. That's for the 0f 0d set.
>
> For 0f 18, the same AMD manual's Table A-7 (page 430, in the "Group 16"
> row) says "NOP[4]" for these excess encodings but the footnote is:
> 4. Reserved prefetch encodings are aliases to the /0 encoding
> (PREFETCH Exclusive) for future compatibility.
> So these Intel reserved opcodes are in fact also prefetch on AMD, not nop,
> despite the appearance of "NOP" in the table grid.
>
> So it seems to me the mnemonic ought to have "prefetch" in it somewhere.
> How about "prefetch/reserved"?
>
Since it is marked as NOP in AMD table, I prefer nop. As for aliasing
to PREFETCH Exclusive. It is just an implementation detail. A future
processor may alias them to a different NOP, not necessarily
PREFETCH Exclusive.
--
H.J.