1

Given the movsxd instruction on the x86-64 architecture (see: movsxd)

The instructions:

MOVSXD r16, r/m16

and

MOVSXD r32, r/m32

receive source & destination operands of the same sizes. As far as I understand, there's no point for sign extension in these cases. If I'm wrong please explain why. Otherwise, why do these variations exist?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Rouki
  • 2,239
  • 1
  • 24
  • 41
  • You mean why isn't the operand-size for `movsxd` fixed at 64-bit, so it wouldn't need a REX prefix? Perhaps decode complexity; perhaps special-casing it would have cost more hardware, and it's rarer than push/pop and other stack ops where the operand-size is fixed. Or just an oversight by AMD, which could have decreased code-size when used with registers that don't include r8..r15. – Peter Cordes Nov 09 '22 at 15:54
  • 3
    These forms only exist because of the way instructions are encoded. They have no purpose and should not be used. Intel says, "The use of MOVSXD without REX.W in 64-bit mode is discouraged." – prl Nov 09 '22 at 15:56
  • 4
    Related: [MOVZX missing 32 bit register to 64 bit register](//stackoverflow.com/q/51387571) has some discussion of movsxd encodings and various shenanigans, and that NASM refuses to assemble `movsxd eax, eax`. Not really a duplicate of that question since that's not the main point of that answer, so I guess that part of my answer could be transplanted here as an answer to this. Let me know if there's anything that doesn't cover which an answer to this should address. – Peter Cordes Nov 09 '22 at 16:00
  • I think that answers it. Thanks. – Rouki Nov 11 '22 at 07:58

0 Answers0