assembly - MOV moffs32 在 64 位模式下对地址进行符号或零扩展？

Question

让我们有一个指令 MOV EAX,[0xFFFFFFFF] 编码为 64 位模式 如 67A1FFFFFFFF (有效地址大小通过 67 前缀从默认 64 位切换到 32 位)。
英特尔 instruction reference manual (文档订单号:325383-057US 从 2015 年 12 月起)在第 Vol. 2A 2-11 说:

2.2.1.3 Displacement
Addressing in 64-bit mode uses existing 32-bit ModR/M and SIB encodings. The ModR/M and SIB sizes do not change. Theyremain 8 bits or 32 bits and are sign-extended to 64 bits.

这表明 32 位位移应该是 符号扩展但我不确定这是否也涉及特殊的 moffs 寻址模式。
在下一页英特尔说:

2.2.1.6 RIP-Relative Addressing

RIP-relative addressing is enabled by 64-bit mode, not by a 64-bit address-size. The use of theaddress-size prefix does not disable RIP-relative addressing. Theeffect of the address-size prefix is to truncate and zero-extend thecomputed effective address to 32 bits.

这表明在相对寻址模式中，disp32 被符号扩展到 64 位，添加到 RIP 然后被截断和 零扩展 .
但是我不确定相同的规则是否适用于绝对寻址模式，这是 MOV moffs 操作的情况。
EAX 将从哪个地址加载，A) FFFFFFFFFFFFFFFF 或 B) 00000000FFFFFFFF ？

Answer 1

67 A1 FFFFFFFF没有使用 disp32寻址模式，因此文档的 Mod/RM 部分不适用。
英特尔的 x86 手册 vol.1 说:

All 16-bit and 32-bit address calculations are zero-extended in IA-32e mode to form 64-bit addresses. Address calculations are first truncated to the effective address size of the current mode (64-bit mode or compatibility mode), as overridden by any address-size prefix. The result is then zero-extended to the full 64-bit address width. [...] A 32-bit address generated in 64-bit mode can access only the low 4 GBytes of the 64-bit mode effective addresses.

这适用于特殊 moffs absolute addressing forms of mov 以及常规的 ModR/M 寻址模式，如 mov eax, [edi]而不是 mov eax, [rdi] .
请注意 moffs8/16/32/64命名显示操作数大小，而不是地址大小(例如 mov al, moffs8 )。 32 位地址大小没有不同的术语 moffs在 64 位模式下。
地址大小前缀更改 A1从 64 位立即数地址到 32 位的操作码，即它改变了指令其余部分的长度(与 64 位模式下的 ModR/M 寻址模式不同，后者总是 disp0/8/32)。这实际上 causes LCP stalls on Skylake, according to my testing , 为 a32 mov eax, [abs buf] (NASM 选择在这种情况下使用 moffs 编码，因为指定了 a32 覆盖，它比 ModR/M + disp32 短)
另见 Does a Length-Changing Prefix (LCP) incur a stall on a simple x86_64 instruction?有关 LCP 摊位的更多详细信息，包括 67h地址大小前缀。

无论如何，这意味着将其拆解为 mov eax, [0xFFFFFFFF]是错误的(至少在 NASM 语法中)，因为它会重新组合成一条执行不同操作的指令。
正确的 YASM/NASM syntax将组装回该机器代码的是 a32 mov eax, [0xFFFFFFFF]NASM 也接受 mov eax, [a32 0xFFFFFFFF] ，但 YASM 没有。

GNU as还提供了一种表达方式(不使用 .byte ):addr32 mov 0xffffffff,%eax

movl    0x7FFFFFFF, %eax  # 8B mod/rm disp32
movl    0xFFFFFFFF, %eax  # A1 64bit-moffs32: Older GAS versions may have required the movabs mnemonic to force a moffs encoding

movabs  0x7FFFFF, %eax    #     A1 64b-moffs32: movabs forces MOFFS
movabs  0xFFFFFFFF, %rax  # REX A1 64b-moffs64
movabs  0xFFFF, %ax       #  66 A1 64b-moffs64: operand-size prefix

.byte 0x67, 0xa1, 0xff, 0xff, 0xff, 0xff  # disassembles to  addr32 mov 0xffffffff,%eax
                                          # and that syntax works as assembler input:
addr32 mov 0xffffffff,%eax    # 67 A1 FF FF FF FF:  32b-moffs32

使用 NASM/YASM，无法以拒绝与 AL/AX/EAX/RAX 以外的寄存器组装的方式强制 32 位 MOFFS 编码。 a32 mov [0xfffffff], cl组装到 67 88 0c 25 ff ff ff 0f addr32 mov BYTE PTR ds:0xfffffff,cl ( mov r/m8, r8 的 ModR/M + disp32 编码)。
你可以写 mov eax, [qword 0xffff...]获取 moffs64编码，但没有办法要求 32 位 moffs 编码。

阿格纳雾的 objconv反汇编器弄错了(从上面的块中反汇编用 GNU as 生成的机器代码)。 objconv似乎假定符号扩展。 (它将机器代码放在注释中为 prefixes: opcode, operands )

; Note: Absolute memory address without relocation
    mov     eax, dword [abs qword 7FFFFFH]          ; 0033 _ A1, 00000000007FFFFF
 ...
; Note: Absolute memory address without relocation
    mov     eax, dword [0FFFFFFFFFFFFFFFFH]         ; 0056 _ 67: A1, FFFFFFFF

ndisasm -b64也会错误地反汇编，以编写甚至无法以相同方式工作的代码 :

00000073  A1FFFF7F00000000  mov eax,[qword 0x7fffff]
         -00
...
00000090  67A1FFFFFFFF      mov eax,[0xffffffff]

我本来期望像 mov eax, [qword 0xffffffff] 这样的拆卸，如果它不打算使用 a32关键词。这将组装成一个 64 位 moff，它引用与原始地址相同的地址，但更长。可能在向 ndisasm 添加 AMD64 支持时忽略了这一点，该支持在 AMD64 之前就已经存在。