Go汇编是Plan9风格伪汇编，非x86/ARM原生，需用SP/FP/SB/PC等大写寄存器名，参数通过FP偏移访问，函数以TEXT·name(SB)开头，WASM不支持，调试依赖go tool compile -S和delve。
Go 汇编不是 x86 或 ARM 原生汇编
Go 的 asm 是一种伪汇编（plan9 风格），语法和语义都由 Go 工具链自定义，不直接对应任何 CPU 指令集。你写的是 Go 汇编，不是 NASM、GAS 或 LLVM IR；它会被 go tool asm 编译成目标平台的机器码，但中间经过多层重写（比如寄存器重命名、栈帧调整）。这意味着：不能照搬 C 的 inline asm 写法，也不能用 mov eax, 1 这类 Intel 语法。
常见错误现象：unknown instruction MOV、undefined symbol SP、函数调用后栈损坏。原因往往是用了错的语法风格，或混淆了 plan9 寄存器名（如 SP 是栈顶，不是 x86 的 %rsp）。
- 必须用 plan9 寄存器名：
SP、FP、SB、PC（全大写，无%或$） - 参数通过伪寄存器
FP访问（如a+0(FP)），不是压栈后pop或rbp+8 - 函数必须以
TEXT ·funcname(SB), NOSPLIT, $stacksize开头，·表示包本地符号，SB是静态基址
如何让 Go 函数调用汇编实现
Go 要求汇编函数与 Go 函数签名严格匹配，且必须在同一包下（不能跨包直接调用 .s 文件里的符号）。最简流程是：写 add.s → 在同目录写 add.go 声明函数原型 → go build 自动联动。
示例（amd64）：
// add.s
TEXT ·add(SB), NOSPLIT, $0
MOVQ a+0(FP), AX
MOVQ b+8(FP), BX
ADDQ BX, AX
MOVQ AX, ret+16(FP)
RET
对应 Go 声明：
// add.go package main func add(a, b int64) int64
-
a+0(FP)表示第一个参数，偏移 0 字节；b+8(FP)是第二个（int64 占 8 字节）；ret+16(FP)是返回值位置（两个参数共 16 字节） -
NOSPLIT表示禁用栈分裂，适用于无局部变量、不调用其他函数的纯计算函数；否则需算清栈帧大小并填入$stacksize - 文件名必须是
xxx_amd64.s、xxx_arm64.s等，Go 会按构建目标自动选；混用平台名和文件名不匹配会导致静默忽略
为什么 GOOS=js GOARCH=wasm 下不能写汇编
WASM 后端不支持 plan9 汇编。Go 工具链对 wasm 架构只提供纯 Go 编译路径，go tool asm 对 *_wasm.s 文件直接报错 unknown architecture wasm。这不是遗漏，而是设计选择：WASM 模块由 Go runtime 全权管理内存和调用，手写汇编会破坏安全边界。
- 所有
GOOS=js场景都不接受 .s 文件，build 时会跳过或报错 - 想优化热点？只能靠 Go 编译器内联、逃逸分析，或改用
syscall/js调 JS 实现（再由 JS 调 WASM 导出函数） - ARM64、386、ppc64le 等原生平台才真正支持汇编；RISC-V 支持从 Go 1.21 起稳定可用，但需确认
GOARCH=riscv64和对应 .s 文件名
调试汇编函数最有效的办法
别依赖 println 或日志——汇编里没有 runtime 支持。真要验证行为，唯一可靠方式是生成并检查目标汇编输出，或用 delve 单步。
- 用
go tool compile -S main.go查看 Go 编译器最终生成的汇编（含你的 .s 文件合并结果），确认符号是否被识别、调用是否内联 - 用
dlv debug启动后，disassemble -l查看函数反汇编，step-instruction逐条执行，注意SP和FP变化 - 最容易被忽略的点：Go 的栈增长机制在汇编函数中不自动生效。如果函数里分配了大量局部变量（比如大数组），又没在
TEXT行声明足够$stacksize，运行时会 panicstack overflow，且无明确行号提示
