Is LEA the only instruction in x86 with a memory operand that doesn't access memory?

Question

I'm using libdis, the x86 disassembler library from the bastard, and I'm trying to find out which instructions access memory.

With reference to these two instructions:

mov eax, [ebx + 10]
lea eax, [ebx + 10]

In libdis, both are listed with instruction type insn_mov, and the address operands have the same flags in both cases. So the only way I can tell if memory is accessed is to look at the instruction mnemonic.

Hence my question: is LEA the only instruction using a memory operand that doesn't actually access memory? Any links to references would be nice.

Answer 1

The prefetch family of instructions (prefetcht1, prefetcht2, prefetcht3, prefetchnta) ask the processor to go and pull those memory lines into cache because they will be needed soon. But, Intel's documentation makes it clear that no faults can result from a bad address passed to prefetch. This is so that software can pass potentially out-of-bound addresses to prefetch without checking them first, so that the data can be in-flight while those checks are performed.

Prefetches also don't have an 'output', unlike LEA.

Answer 2

Intel has a multi-byte "NOP" instruction with opcode 0F 1F /0 that takes memory addressing operands. From Intel's manual:

The multi-byte NOP instruction does not alter the content of a register and will not issue a memory operation

The discussion in comments is about putting the opcode byte of a nop at the end of an unmapped page, and code fetch faulting if it can't read a complete instruction including the ModR/M and displacement bytes. That's orthogonal to this question.

---

You can think of long-NOP as working as follows:

• Instruction decoding hardware knows how to find the end of an instruction that takes a ModRM (which implies optional SIB and/or displacement).
• Based on that opcode specifically being a NOP, the rest of the CPU doesn't do anything with the addressing mode encoded by the ModRM.

This makes it possible for software to encode multi-byte NOPs by using a variety of addressing modes and prefixes. The CPU can be designed to handle it without needing any special hardware beyond recognizing one more opcode as a nop. The overall instruction format is the same as most.