golang汇编语言基础

Go 编译器会输出一种抽象可移植的汇编代码，这种汇编并不对应某种真实的硬件架构。之后 Go 的汇编器使用这种伪汇编，为目标硬件生成具体的机器指令。

伪汇编这一个额外层可以带来很多好处，最主要的一点是方便将 Go 移植到新的架构上。相关的信息可以参考文后列出的 Rob Pike 的 The Design of the Go Assembler。

思考下面这行代码：

注意这里的 <code>//go:noinline 编译器指令</code>。不要省略掉这部分

将这段代码编译到汇编:

接下来一行一行地对这两个函数进行解析来帮助我们理解编译器在编译期间都做了什么事情。

<code>0x0000 00000 (test1.go:5) TEXT "".add(SB), NOSPLIT|ABIInternal, $0-16</code>

objdump 这个工具能帮我们确认上面这些结论:

Go 的调用规约要求每一个参数都通过栈来传递，这部分空间由 caller 在其栈帧(stack frame)上提供。

调用其它函数之前，caller 就需要按照参数和返回变量的大小来对应地增长(返回后收缩)栈。

Go 编译器没有 PUSH/POP 族的指令: 栈的增长和收缩是通过在栈指针寄存器 SP 上分别执行减法和加法指令来实现的

与大多数最近的编译器做法一样，Go 工具链总是在其生成的代码中，使用相对栈指针(stack-pointer)的偏移量来引用参数和局部变量。这样使得我们可以用帧指针(frame-pointer)来作为一个额外的通用寄存器，这一点即使是在那些寄存器数量较少的平台上也是一样的(例如 x86)。

“”.b 12(SP) 和 “”.a 8(SP) 分别指向栈的低 12 字节和低 8 字节位置(记住: 栈是向低位地址方向增长的！)。

.a 和 .b 是分配给引用地址的任意别名；尽管 它们没有任何语义上的含义 ，但在使用虚拟寄存器和相对地址时，这种别名是需要强制使用的。

最后，有两个重点需要指出:

ADDL 进行实际的加法操作，L 这里代表 Long，4 字节的值，其将保存在 AX 和 CX 寄存器中的值进行相加，然后再保存进 AX 寄存器中。
这个结果之后被移动到 <code>"".~r2 16(SP)</code>地址处，这是之前调用方专门为返回值预留的栈空间。这一次 “”.~r2 同样没什么语义上的含义。

由于 Go 程序中的 goroutine 数目是不可确定的，并且实际场景可能会有百万级别的 goroutine，runtime 必须使用保守的思路来给 goroutine 分配空间以避免吃掉所有的可用内存。

也由于此，每个新的 goroutine 会被 runtime 分配初始为 2KB 大小的栈空间(Go 的栈在底层实际上是分配在堆空间上的)。

随着一个 goroutine 进行自己的工作，可能会超出最初分配的栈空间限制(就是栈溢出的意思)。为了防止这种情况发生，runtime 确保 goroutine 在超出栈范围时，会创建一个相当于原来两倍大小的新栈，并将原来栈的上下文拷贝到新栈上。这个过程被称为 栈分裂(stack-split)，这样使得 goroutine 栈能够动态调整大小。

为了使栈分裂正常工作，编译器会在每一个函数的开头和结束位置插入指令来防止 goroutine 爆栈。

像我们本章早些看到的一样，为了避免不必要的开销，一定不会爆栈的函数会被标记上 NOSPLIT 来提示编译器不要在这些函数的开头和结束部分插入这些检查指令。

基础相关指令可以参考：
x86汇编指令集大全（带注释）

应用代码层面会用到的通用寄存器主要是: rax, rbx, rcx, rdx, rdi, rsi, r8~r15 这 14 个寄存器，虽然 rbp 和 rsp 也可以用，不过 bp 和 sp 会被用来管理栈顶和栈底，最好不要拿来进行运算。

plan9 中使用寄存器不需要带 r 或 e 的前缀，例如 rax，只要写 AX 即可:

Go 的汇编还引入了 4 个伪寄存器，援引官方文档的描述:

官方的描述稍微有一些问题，我们对这些说明进行一点扩充:

我们这里对容易混淆的几点简单进行说明：

图上的 caller BP，指的是 caller 的 BP 寄存器值，有些人把 caller BP 叫作 caller 的 frame pointer，实际上这个习惯是从 x86 架构沿袭来的。Go 的 asm 文档中把伪寄存器 FP 也称为 frame pointer，但是这两个 frame pointer 根本不是一回事。

此外需要注意的是，caller BP 是在编译期由编译器插入的，用户手写代码时，计算 frame size 时是不包括这个 caller BP 部分的。是否插入 caller BP 的主要判断依据是:

如果编译器在最终的汇编结果中没有插入 caller BP(源代码中所称的 frame pointer)的情况下，伪 SP 和伪 FP 之间只有 8 个字节的 caller 的 return address，而插入了 BP 的话，就会多出额外的 8 字节。也就说伪 SP 和伪 FP 的相对位置是不固定的，有可能是间隔 8 个字节，也有可能间隔 16 个字节。并且判断依据会根据平台和 Go 的版本有所不同。

图上可以看到，FP 伪寄存器指向函数的传入参数的开始位置，因为栈是朝低地址方向增长，为了通过寄存器引用参数时方便，所以参数的摆放方向和栈的增长方向是相反的，即：

假设所有参数均为 8 字节，这样我们就可以用 symname 0(FP) 访问第一个 参数，symname 8(FP) 访问第二个参数，以此类推。用伪 SP 来引用局部变量，原理上来讲差不多，不过因为伪 SP 指向的是局部变量的底部，所以 symname-8(SP) 表示的是第一个局部变量，symname-16(SP)表示第二个，以此类推。当然，这里假设局部变量都占用 8 个字节。

图的最上部的 caller return address 和 current func arg0 都是由 caller 来分配空间的。不算在当前的栈帧内。

因为官方文档本身较模糊，我们来一个函数调用的全景图，来看一下这些真假 SP/FP/BP 到底是个什么关系:

在函数声明中:

前面已经说过 $16-32 表示 $framesize-argsize。Go 在函数调用时，参数和返回值都需要由 caller 在其栈帧上备好空间。callee 在声明时仍然需要知道这个 argsize。argsize 的计算方法是，参数大小求和 返回值大小求和，例如入参是 3 个 int64 类型，返回值是 1 个 int64 类型，那么这里的 argsize = sizeof(int64) * 4。

不过真实世界永远没有我们假设的这么美好，函数参数往往混合了多种类型，还需要考虑内存对齐问题。

如果不确定自己的函数签名需要多大的 argsize，可以通过简单实现一个相同签名的空函数，然后 go tool objdump 来逆向查找应该分配多少空间。

函数的 framesize 就稍微复杂一些了，手写代码的 framesize 不需要考虑由编译器插入的 caller BP，要考虑：

math.go:

math.s:

把这两个文件放在一个目录下就可以执行 <code>go build</code> 了。

benchmark测试用例：

我们看一下benchmark 的执行结果：

我们可以看到go原生的自加其实比使用汇编写的代码要快的多，这是因为 Go 现在还不支持汇编函数内联，所以调用汇编函数执行自加会有一些函数调用的性能损耗，所以自加汇编函数实现有更高的负载。

如果我将BenchmarkAddNative禁用内联，并将自加单独抽出来：

执行结果：

在go1.13中，有一些包的里面的函数被定义为 原生函数，这些函数会在编译时候被替代 成汇编代码，而不是以汇编函数的方式调用。比如：

这里以 <code>atomic.AddInt64</code> 为例，调用链路是这样的。

sync/atomic/doc.go

sync/atomic/asm.s

runtime∕internal/atomic/asm_amd64.s

这里先解释一下两个汇编指令：

参考文献：
Golang同步机制的实现
x86汇编指令集大全（带注释）
Go 系列文章3 ：plan9 汇编入门
Go compiler intrinsics