3

What happens when you use a memory override prefix but all the operands are registers?

So, let's say you code mov eax, ebx or add eax, ebxand the default is 32-bit but you use a 67h override.

How does the processor handle that situation?

matrix2
  • 39
  • 2
  • 2
    `66` is the operand-size prefix, so it makes it into `mov ax,bx`. Did you mean the `67` address-size prefix? – Peter Cordes Sep 13 '17 at 03:32
  • Yes, I edited the original question. No, wait I meant the original question. That was the whole point, mixing a memory prefix with no memory operands. – matrix2 Sep 14 '17 at 23:48
  • 1
    `66` isn't a "memory" prefix. `89 d8` is `mov eax, ebx`. `66 89 d8` is `mov ax, bx` (in 32 or 64-bit mode, otherwise the 66 prefix make the operand size 32-bit instead of the default 16). Is that what you meant to ask, or did you really want to know about the `67` address-size prefix that makes `mov eax, [ebx]` into `mov eax, [bx]`. (Or in 64-bit mode, `mov eax, [rbx]` into `mov eax, [ebx]`.) – Peter Cordes Sep 14 '17 at 23:56
  • I meant 67h, and I changed it. Thanks. – matrix2 Sep 15 '17 at 00:11

1 Answers1

5

The Intel Software Developer's Manual*, volume 2, section 2.1, details the behavior of each instruction prefix. It says use of the address-size prefix (67h) with an instruction that doesn't have a memory operand is reserved and may cause unpredictable behavior.

The operand-size prefix (66h) may be used to switch between 16- and 32-bit operand sizes and also as a mandatory prefix with certain SSE2/SSE3/SSSE3/SSE4 instructions. Other use is reserved and may cause unpredictable behavior.

The segment override prefixes are reserved with any branch instruction.

* https://software.intel.com/en-us/articles/intel-sdm

prl
  • 11,716
  • 2
  • 13
  • 31
  • 2
    On real hardware, prefixes which don't apply are ignored. This is why they're "reserved" instead of "cause #UD". Except for `lock`, which does `#UD` when it doesn't apply. – Peter Cordes Sep 13 '17 at 05:30
  • @peter but does Intel document that "reserved" means you can use it and it will be ignored? I would assume it means "don't use it, anything can happen". Now it seems like in practice reserved prefix use is often ignored, which is convenient for Intel because they can then define new behavior later using previously pointless prefixes and also document at that point that it is fine (ignored) on earlier chips too. Other reserved behavior may very well UD though. – BeeOnRope Sep 13 '17 at 21:47
  • @BeeOnRope: No, I don't think so, since they usually only document future-proof guarantees, not specific details of what current CPUs do if they don't want to guarantee that for the future. As you say, they'll only document the ignore behaviour after the fact, like for `tzcnt`/`bsf`. However, there are a few cases like `rep ret` which can't be repurposed without breaking vast amounts of gcc-compiled binaries, so [I don't expect any mainstream CPU to repurpose it for decades.](https://stackoverflow.com/questions/20526361/what-does-rep-ret-mean/32347393#32347393). – Peter Cordes Sep 13 '17 at 22:02