Re: announce: my very first disassembler now available (GPL)



On Aug 19, 2:03 pm, "H. Peter Anvin" <h...@xxxxxxxxx> wrote:
Alexei A. Frounze wrote:
On Aug 16, 10:08 pm, "Alexei A. Frounze" <alexfrun...@xxxxxxxxx>
wrote:
There's also a special case in 64-bit mode. Depending on the rex
prefix (AFAIR, bit B) it can be either NOP or XCHG.

I meant to say, if both operands are rAX, then it's NOP. This is
controlled by mod, REX.R (if REX is present), reg, REX.B (if REX is
present) and r/m.

Except, it's not.

Plain 90h, which would normally be XCHG EAX,EAX (and therefore
zero-extend EAX into RAX) is actually NOP.

I might have misspoken, but the appropriate REX followed by 0x90 isn't
a NOP, it's XCHG rAX, r8.

Excerpt from the AMD's manual on XCHG:

XCHG Exchange

Exchanges the contents of the two operands. The operands can be two
generalpurpose
registers or a register and a memory location. If either operand
references
memory, the processor locks automatically, whether or not the LOCK
prefix is used
and independently of the value of IOPL. For details about the LOCK
prefix, see “Lock
Prefix” on page 10.
The x86 architecture commonly uses the XCHG EAX, EAX instruction
(opcode 90h) as
a one-byte NOP. In 64-bit mode, the processor treats opcode 90h as a
true NOP only if
it would exchange rAX with itself. Without this special handling, the
instruction
would zero-extend the upper 32 bits of RAX, and thus it would not be a
true nooperation.
Opcode 90h can still be used to exchange rAX and r8 if the appropriate
REX prefix is used.
This special handling does not apply to the two-byte ModRM form of the
XCHG
instruction.

Table A-1 also lists both NOP and XCHG r8, rAX in the cell for opcode
0x90.

Alex
.



Relevant Pages

  • Re: announce: my very first disassembler now available (GPL)
    ... controlled by mod, REX.R, reg, REX.B (if REX is ... Plain 90h, which would normally be XCHG EAX,EAX is actually NOP. ...
    (alt.lang.asm)
  • Re: lock
    ... XCHG exchanges the values in its two operands. ... prefix for purposes of multi-processor synchronization. ... LOCK prefix or of the value ... is one of the internal hidden registers within the ...
    (alt.lang.asm)
  • Re: whats the use of "data16 nop" instruction generated by gas on x86 and x86_64
    ... The basic problem is that there aren't different instruction encodings for 16-bit and 32-bit operations; a code segment has a "default" operand size, and if you want the "other" size, you need the 66h prefix. ... For instance, in 16-bit mode a "MOV AX, BX" can be turned into "MOV EAX, EBX" by adding a 66h prefix. ... 90h is the opcode for XCHG AX,AX, so adding one or more 66h prefix bytes change the code from 16 to 32 bit or vice versa. ... BTW, MOVing any register to itself is a two-byte NO-OP, but unlike the 66h/90h combination it isn't specialcased by the decoder, so it does affect the reorder buffer register pressure. ...
    (comp.arch)
  • Re: lock
    ... XCHG exchanges the values in its two operands. ... It can be used with a LOCK ... prefix for purposes of multi-processor synchronization. ...
    (alt.lang.asm)
  • Re: announce: my very first disassembler now available (GPL)
    ... Not a NOP, certainly... ... Intel, AMD or both? ... Not under a debugger, but yes, I executed them (inside a small C ... either NOP or XCHG? ...
    (alt.lang.asm)