Go 1.17 调用规约 golang

Go 1.17 修改了用了很久的基于栈的调用规约，在了解 Go 的调用规约之前，我们得知道什么是调用规约。
x86 calling convention，简单概括一下，其实就是语言对于函数之间传参的一种约定。调用方要知道我要把参数按照什么形式，什么顺序传给被调用函数，被调用函数也遵守该规范去相应的位置找到传入的参数内容。
老版本的 Go 的参数传递图我们已经在很多很多地方见过了，这里贴一个我之前画的：

文章图片

可以看到入参和返回值都在栈上，按顺序，从低地址，到高地址排列。
这种基于栈的传参在设计和实现上确实要简单，但栈上传参会导致函数调用过程中数次发生从寄存器和内存之间的参数搬运操作。比如 call 的时候，要把参数全搬到 SP 的位置(这里从寄存器 -> 内存)； ret 的时候，也要把参数从寄存器搬到 FP 位置。ret 完毕之后，要把返回值从内存 -> 寄存器。

文章图片

寄存器是 CPU 内部的组件，而主存一般都在外部，两者之间有数量级的性能差异，所以一直有人说 Go 的函数调用性能很差，需要优化(虽然这些人大概率也不是从系统整体性能考虑去做优化的)。
Go 1.17 设计了一套基于寄存器传参的调用规约，目前只在 x86 平台下开启，我们可以通过反汇编对其进行简单的观察。这里依然为了简化问题，我们只用 int 参数(float 使用的不是通用寄存器)。

package main//go:noinline func add(x int, y int, z int, a, b, c int, d, e, f int, g, h, l int) (int, int, int, int, int, int, int, int, int, int, int) { println(x, y) return 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 }func main() { println(add(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)) }

稍微多传一些参数方便我们观察，输入 12 个参数，返回 11 个值。
直接看反汇编的结果，首先是对 main.add 的调用部分：

TEXT main.main(SB) /Users/xargin/test/abi.go abi.go:150x1054e604c8da42478ffffffLEAQ 0xffffff78(SP), R12 abi.go:150x1054e684d3b6610CMPQ 0x10(R14), R12 abi.go:150x1054e6c0f865a020000JBE 0x10550cc abi.go:150x1054e724881ec08010000SUBQ $0x108, SP abi.go:150x1054e794889ac2400010000MOVQ BP, 0x100(SP) abi.go:150x1054e81488dac2400010000LEAQ 0x100(SP), BP abi.go:160x1054e8948c704240a000000MOVQ $0xa, 0(SP) // 第 10 个参数 abi.go:160x1054e9148c74424080b000000MOVQ $0xb, 0x8(SP) // 第 11 个参数 abi.go:160x1054e9a48c74424100c000000MOVQ $0xc, 0x10(SP) // 第 12 个参数 abi.go:160x1054ea3b801000000MOVL $0x1, AX // 第 1 个参数，后面以此类推 abi.go:160x1054ea8bb02000000MOVL $0x2, BX abi.go:160x1054eadb903000000MOVL $0x3, CX abi.go:160x1054eb2bf04000000MOVL $0x4, DI abi.go:160x1054eb7be05000000MOVL $0x5, SI abi.go:160x1054ebc41b806000000MOVL $0x6, R8 abi.go:160x1054ec241b907000000MOVL $0x7, R9 abi.go:160x1054ec841ba08000000MOVL $0x8, R10 abi.go:160x1054ece41bb09000000MOVL $0x9, R11 abi.go:160x1054ed4e807fdffffCALL main.add(SB) abi.go:160x1054ed948898424f8000000MOVQ AX, 0xf8(SP)

可以看到，官方只使用了 9 个通用寄存器，依次是 AX，BX，CX，DI，SI，R8，R9，R10，R11，超出部分，按顺序放在栈上。
然后是 main.add 的返回值部分：

TEXT main.add(SB) /Users/xargin/test/abi.go ....省略 print 的部分 abi.go:60x1054c2f48c74424400a000000MOVQ $0xa, 0x40(SP) // 第 10 个返回值 abi.go:60x1054c3848c74424480b000000MOVQ $0xb, 0x48(SP) // 第 11 个返回值 abi.go:60x1054c41b801000000MOVL $0x1, AX // 第 1 个返回值，后面以此类推 abi.go:60x1054c46bb02000000MOVL $0x2, BX abi.go:60x1054c4bb903000000MOVL $0x3, CX abi.go:60x1054c50bf04000000MOVL $0x4, DI abi.go:60x1054c55be05000000MOVL $0x5, SI abi.go:60x1054c5a41b806000000MOVL $0x6, R8 abi.go:60x1054c6041b907000000MOVL $0x7, R9 abi.go:60x1054c6641ba08000000MOVL $0x8, R10 abi.go:60x1054c6c41bb09000000MOVL $0x9, R11 abi.go:60x1054c72488b6c2418MOVQ 0x18(SP), BP abi.go:60x1054c774883c420ADDQ $0x20, SP abi.go:60x1054c7bc3RET

返回值和输入使用了完全相同的寄存器序列，同样在超出 9 个返回值时，多出的内容在栈上返回。
在传统的调用规约中，一般会区分 caller saved registers 和 callee saved registers，但在 Go 中，所有寄存器都是 caller saved，也就是由 caller 负责保存，在 callee 中不保证不对其现场进行破坏。
这里可以看到，返回值直接就把入参使用的寄存器直接覆盖掉了，也可以证明这一点。
因为函数调用不需要通过栈来传参了，所以在一些函数调用嵌套层次比较深的场景下，goroutine 栈本身使用的内存也有一定概率会降低。不过因为暂时手边没有什么生产环境，所以暂时也无法验证就是了。
【Go 1.17 调用规约】