解码接口运行类型断言的编译器输出

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《解码接口运行类型断言的编译器输出》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

我最近在使用 Atomic.Value 的 Load() 方法时遇到空接口。我正在尝试空接口类型断言 - https://play.golang.org/p/CLyY2y9-2VF

这激起了我的兴趣，我决定在幕后看看编译器会采取哪些操作，以便代码在尝试读取 nil 接口 {} 上的具体值时不会出现恐慌（例如，当 Store 尚未被调用时，您调用 Load.(type) 时）。

我可以看到，在不安全版本中，编译器有这个汇编指令导致恐慌：调用runtime.panicdottypeE(SB)

安全版本中显然不存在紧急指令。有人可以更详细地解释一下当我们使用 ok 捕获返回值时编译器正在做什么吗（或许还可以向我指出 godbolt 链接中相应的汇编指令）？

以下是不安全版本 [1] 和安全版本 [2] 的 godbolt 编译器链接。

[1] https://godbolt.org/z/76onvj

[2] https://godbolt.org/z/e8aoqe

解决方案

空接口类型（在运行时包中称为 eface）是 2 个指针，第一个指向基础类型（例如 bool 类型、int 类型、yourstruct 类型...），第二个是指向数据的指针（iirc 在某些情况下数据本身）。

不安全版本：

call "".returnemptyinterface(sb)   call the function
pcdata $0, $1                      pcdata is not a real instruction, ignore 
movq 8(sp), ax                     ax <- pointer to data 
movq    (sp), cx                   cx <- pointer to type 
pcdata $0, $2 
leaq type.bool(sb), dx             dx <- pointer to bool type 
cmpq cx, dx                        compare cx and dx 
jne main_pc156                     if they are not equal jump to main_pc156

在main_pc156中，编译器将调用runtime.panicdottypee，这基本上会出现恐慌。源代码来自runtime/iface.go（可以在你的$gopath/src中找到它）：

func panicdottypee(have, want, iface *_type) {
    panic(&typeassertionerror{iface, have, want, ""})
}

安全版本：

pcdata  $0, $0
pcdata  $1, $0
call    "".returnemptyinterface(sb)    call the function
pcdata  $0, $1
movq    8(sp), ax                      ax <- pointer to data
movq    (sp), cx                       cx <- pointer to type
main_pc47:
pcdata  $0, $2
leaq    type.bool(sb), dx              dx <- pointer to bool type
cmpq    cx, dx                         compare cx and dx
jne     main_pc186                     if not equal jump main_pc186
pcdata  $0, $3
movblzx (ax), ax                       ax <- dereference ax
main_pc62:

和main_pc186

pcdata  $0, $3
xorl    ax, ax                        ax <- 0
jmp     main_pc62                     jump back at the end of previous block

这里ax对应于代码中的x，但是什么对应于代码中的ok呢？没有什么！如果您检查 println 的代码，您会看到：

cmpq    cx, dx                        compare cx and dx
seteq   al                            al <- 1 if cx equal to dx otherwise 0

因此编译器决定在打印时再次比较它们。

快速总结：它们执行完全相同的操作，只是 ok == false 的情况不同。

这两个位有以下共同点：

pcdata  $0, $0
        pcdata  $1, $0
        call    "".returnemptyinterface(sb)
        pcdata  $0, $1
        movq    8(sp), ax
        movq    (sp), cx
        pcdata  $0, $2
        leaq    type.bool(sb), dx
        cmpq    cx, dx
        jne     main_pc156   <==== jump
        pcdata  $0, $3
        movblzx (ax), ax

在main_pc156中找到的代码是我们关心的部分。正如您所注意到的，对于单值类型断言，这是：

main_pc156:
        movq    dx, 8(sp)
        pcdata  $0, $1
        leaq    type.interface {}(sb), ax
        pcdata  $0, $0
        movq    ax, 16(sp)
        call    runtime.panicdottypee(sb)
        xchgl   ax, ax

这是不可避免的，一旦我们跳转到 main_pc156，我们就会恐慌。

另一方面，二值类型断言的代码是：

main_pc186:
        pcdata  $0, $3
        xorl    AX, AX
        jmp     main_pc62

这与之前的情况有很大不同，它让我们回到第一段代码的末尾，恢复执行。

理论要掌握，实操不能落！以上关于《解码接口运行类型断言的编译器输出》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！