我遇到了以下Go代码:

type Element [12]uint64

//go:noescape
func CSwap(x, y *Element, choice uint8)

//go:noescape
func Add(z, x, y *Element)

TEXT ·CSwap(SB), NOSPLIT, $0-17

    MOVQ    x+0(FP), REG_P1
    MOVQ    y+8(FP), REG_P2
    MOVB    choice+16(FP), AL   // AL = 0 or 1
    MOVBLZX AL, AX              // AX = 0 or 1
    NEGQ    AX                  // RAX = 0x00..00 or 0xff..ff

    MOVQ    (0*8)(REG_P1), BX
    MOVQ    (0*8)(REG_P2), CX
    // Rest removed for brevity

TEXT ·Add(SB), NOSPLIT, $0-24

    MOVQ    z+0(FP), REG_P3
    MOVQ    x+8(FP), REG_P1
    MOVQ    y+16(FP), REG_P2

    MOVQ    (REG_P1), R8
    MOVQ    (8)(REG_P1), R9
    MOVQ    (16)(REG_P1), R10
    MOVQ    (24)(REG_P1), R11
    // Rest removed for brevity

.text
.global add_asm
add_asm:
  push   r12
  push   r13
  push   r14
  push   r15

  mov    r8, [reg_p1]
  mov    r9, [reg_p1+8]
  mov    r10, [reg_p1+16]
  mov    r11, [reg_p1+24]
  // Rest removed for brevity

.text
.global cswap_asm
cswap_asm:
  push   r12
  push   r13
  push   r14

  mov    al, 16
  mov    rax, al
  neg    rax

  mov    rbx, [reg_p1+(0*8)]
  mov    rcx, [reg_p2+(0*8)]

#define reg_p1  rdi
#define reg_p2  rsi
#define reg_p3  rdx

movzx  rax, dl // Get the lower 8 bits of rdx (reg_p3)
neg    rax

最佳答案

有关Go的asm的基本文档:https://golang.org/doc/asm。它并不完全等同于NASM或AT＆T语法:FP是伪寄存器名称，用于它决定用作帧指针的任何寄存器。 (通常为RSP或RBP)。 Go asm似乎也省略了功能序言(也可能是尾声)指令。 As @RossRidge comments，它有点像LLVM IR之类的内部表示，而不是真正的asm。

Go还具有其自己的对象文件格式，因此我不确定您是否可以使用NASM制作与Go兼容的对象文件。

如果要从Go之外的其他位置调用此函数，则还需要将代码移植到其他调用约定。与普通的x86-64 System V ABI或x86-64 Windows调用约定不同，Go似乎甚至对于x86-64都使用了stack-args调用约定。 (或者也许这些mov函数将args转换成REG_P1，以此类推，当Go为register-arg调用约定构建此源时，指令消失了？)

(这就是为什么您必须使用movzx eax, dl而不是从堆栈中完全加载的原因。)

顺便说一句，如果要与C一起使用C而不是NASM重写此代码，可能更有意义。编译器最好内联和优化小函数。

与Go汇编器一起组装并使用反汇编器来检查翻译或获取起点是一个好主意。
objdump -drwC -Mintel或Agner Fog's objconv disassembler会很好，但是他们不了解Go的目标文件格式。如果Go具有提取实际机器代码或将其获取到ELF对象文件中的工具，请执行此操作。

如果没有，您可以使用ndisasm -b 64(将输入文件视为平面二进制文件，将所有字节分解为指令)。如果可以找到函数的起始位置，则可以指定偏移量/长度。 x86指令的长度是可变的，在功能开始时反汇编可能会“不同步”。您可能想为反汇编器添加一堆单字节的NOP指令(类似于NOP底座)，因此，如果它解码了一些0x90字节作为立即指令或disp32的一部分，而该指令实际上不是该函数的一部分，它将同步。 (但是函数序言仍然会搞砸)。

您可以在Go asm函数中添加一些“路标”指令，以通过分解元数据作为指令来轻松地在疯狂的asm困惑中找到正确的位置。例如在其中某处放置pmuludq xmm0, xmm0或其他具有唯一助记符的指令，您可以搜索该指令不包含Go代码。或带有立即符的指令，例如addq $0x1234567, SP。 (一条会崩溃的说明在这里是不错的选择。)

或者您可以使用gdb的内置反汇编程序:添加一条将进行段错误的指令(例如，从假的绝对地址进行加载(movl 0, AX空指针deref)，或保存非指针值的寄存器，例如movl (AX), AX)。然后，您将获得内存中指令的指令指针值，并且可以从其后的某个点进行反汇编。 (功能开始可能会对齐16个字节。)

具体说明。
MOVBLZX AL, AX读取AL，因此绝对是8位操作数。 AX的大小由助记符的L部分给出，即32位的long，类似于GAS AT＆T语法。 (该movzx形式的气体助记符是movzbl %al, %eax)。有关cdq/cdqe和AT＆T等效表的信息，请参见What does cltq do in assembly?；有关等效MOVSX指令的信息，请参见AT＆T/Intel助记符。

您想要的NASM指令是movzx eax, al。将rax用作目标将浪费REX前缀。使用ax作为目的地将是一个错误:它不会零扩展到完整的寄存器中，并且会留下任何高垃圾。不习惯x86的Go asm语法非常令人困惑，因为AX可能表示AX，EAX或RAX，具体取决于操作数的大小。

显然，mov rax, al是不可能的:与大多数指令一样，mov要求两个操作数的大小相同。 movzx是罕见的异常(exception)之一。
MOVB choice+16(FP), AL是加载到AL中的字节，不是立即移动。 choice+16是FP的偏移量。该语法基本上与AT＆T寻址模式相同，其中FP为寄存器，choice为汇编时间常数。
FP是伪寄存器名称。很明显，它应该只是加载第三个arg传递槽的低字节，因为choice是函数arg的名称。 (在Go asm中，choice只是语法糖，或定义为零的常数。)

在call指令之前，rsp指向第一个堆栈arg，因此+ 16是第三个arg。看来FP是该基地址(实际上可能是rsp+8或其他名称)。在call(将8字节的返回地址压入)之后，第3个堆栈arg位于rsp + 24。再按一次后，偏移量将更大，因此请根据需要进行调整以到达正确的位置。

如果要将此函数移植为使用标准调用约定进行调用，则将在寄存器中传递3个整数args，而没有堆栈args。哪3个寄存器取决于您是针对Windows还是针对非Windows构建的。 (请参阅Agner Fog的调用约定文档:http://agner.org/optimize/)

BTW，将字节加载到AL中，然后movzx eax, al只是愚蠢的。在所有现代CPU上，一步一步完成它的效率要高得多

movzx  eax, byte [rsp + 24]      ; or rbp+32 if you made a stack frame.

关于go - 将Go汇编程序翻译为NASM，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47932759/