1

The AMD64 Architecture Manual Volume 3 talks about when the r/m field of the ModRM byte has a value of 100b, a SIB byte must follow. I understand that this is because you give up the ability to use the SP register (which is normally designated with 100b) for register indirect (with no offset) addressing in 32-bit and 16-bit systems that only have 8 GPRs. I also understand that using the SP this way would not be very useful as the SP is a dedicated stack pointer. However, when a REX prefix is used with REX.B set (41), the r/m field is expanded to four bits so that the expanded ModRM.r/m field has a value of 1100b which codes for R12 and not RSP. But JWASM (an assembler that uses MASM syntax) still generates code that would seem to imply that both 1100b and 0100b for the r/m require a SIB byte to follow. It really doesn't make sense to require a SIB byte when the expanded field codes for R12 and not RSP as R12 is not the Stack Pointer. Does anyone have a full understanding of this issue?

ecm
  • 2,583
  • 4
  • 21
  • 29
Paul McKneely
  • 11
  • 2
  • 1
    My answer on [rbp not allowed as SIB base?](//stackoverflow.com/q/52522544) goes over all 3 of the special cases in x86-64 addressing-mode encoding, and even comments on why this design-decision might have been made (simplifying decoder and pre-decoder HW by not having to check REX.B when determining instruction length and SIB presence.) – Peter Cordes Mar 13 '19 at 02:59
  • So you are saying that the ModRM special cases do not use the extended 4-bit register fields (when a REX.B=1 or REX.X=1) but only the 3-bit pre-extended register fields for the determination of whether a SIB byte is called for or not. That's what I was hoping would not be the case. Oh well... – Paul McKneely Mar 14 '19 at 20:30
  • Yes, that's exactly what I'm saying, except for using `r12` as an index register (which you *can* do, but not RSP). Read my linked answer for comments about why that but not the other. – Peter Cordes Mar 14 '19 at 20:35
  • I love it when someone like you knows what he is talking about! Thanks. Do you happen to be familiar with the mov AL/AX/EAX/RAX,AbsAdr opcodes A0~A3 instructions? Do 64-bit absolute immediate address values follow or is it something else? The AMD64 architecture manuals have missing information. – Paul McKneely Mar 15 '19 at 23:16
  • 1
    Intel's manuals are correct. https://www.felixcloutier.com/x86/MOV.html. Yes, a 64-bit absolute immediate. Assemblers like GAS (`movabs 0x12345678abc, %al`) and NASM (`mov al, [qword 0x123456789ABCD]`) / and disassemblers like objdump and ndisasm all handle this correctly, it's easy enough to just try it. Or with a `0x67` address-size prefix, they take a 32-bit absolute immediate. (But that causes a LCP (length-changing prefix) decode stall on Intel CPUs, so often not worth saving a byte or 2 vs. a ModRM if an absolute address fits in a 32-bit signed disp32) – Peter Cordes Mar 16 '19 at 04:59

0 Answers0