了解OC语言Runtime机制的开发者都知道，几乎所有的方法调用都会转化成objc_msgSend(void /* id self, SEL op, ... */ )的调用,今天探索一下ARM64架构下的objc_msgSend的汇编实现，objc_msgSend 用汇编语言进行实现，具体理由有两个：首先纯 C 语言无法实现这么一个函数：接收不定个数且未知类型的参数作为入参跳转至任意函数指针（即调用实现）；其次，执行速度对 objc_msgSend 来说非常重要，汇编语言能最大化提升该项指标。具体可以看这个,为什么objc_msgSend必须用汇编
在真机环境下，设置一个符号断点即可查看
objc_msgSend的汇编实现
图片来源
objc_msgSend主要有以下几个步骤：
- 通过
isa获取传入的对象的类 - 获取这个类的方法缓存表
- 通过传入的
selector，在缓存中查找方法 - 如果缓存中没有，调用C函数
- 跳到这个方法的
IMP
下面对汇编程序逐行分析
0x232c6f520 <+0>: cmp x0, #0x0 ; =0x0
0x232c6f524 <+4>: b.le 0x232c6f58c ; <+108>
判断x0是nil还是tagged pointer，等于0为nil,小于0为tagged pointer
0x232c6f528 <+8>: ldr x13, [x0]
将x0中所表示的self的isa地址放到x13寄存器中
0x232c6f52c <+12>: and x16, x13, #0xffffffff8
当前对象逻辑与mask获取类的地址，x16 = isa & mask，
# if __arm64__
# define ISA_MASK 0x0000000ffffffff8ULL
# define ISA_MAGIC_MASK 0x000003f000000001ULL
# define ISA_MAGIC_VALUE 0x000001a000000001ULL
# define ISA_BITFIELD \
uintptr_t nonpointer : 1; \
uintptr_t has_assoc : 1; \
uintptr_t has_cxx_dtor : 1; \
uintptr_t shiftcls : 33; /*MACH_VM_MAX_ADDRESS 0x1000000000*/ \
uintptr_t magic : 6; \
uintptr_t weakly_referenced : 1; \
uintptr_t deallocating : 1; \
uintptr_t has_sidetable_rc : 1; \
uintptr_t extra_rc : 19
arm64架构下使用 non-pointer isa技术，和之前的isa相比，isa字段不仅存放了Class的信息，还存放了其他信息（上面的代码块），这里通过AND运算除去低位的冗余信息将最终的Class的地址放入x16寄存器中
0x232c6f530 <+16>: ldp x10, x11, [x16, #0x10]
该指令会将Class中的方法缓存哈希表bucket加载到x10 和 x11 两个寄存器中。ldp指令会将有效的内存信息加载到该指令的前两个寄存器中，而第三个参数则对应该信息的内存地址，在该例中缓存哈希表地址为x16寄存器中地址偏移16后所处的位置，
struct objc_class : objc_object {
// Class ISA; // 8
Class superclass; // 8
cache_t cache; // fpointer and vtable
class_data_bits_t bits; //
}；
ISA 和 superclass 各占8个字节，所以偏移16个字节后，指向cache_t cache
struct cache_t {
struct bucket_t *_buckets; //哈希表
mask_t _mask; //大小
mask_t _occupied; //已占用大小
}；
在上述指令中，x10 = _buckets，而 x11 寄存器的高 32 位保存的是 _occupied 低 32 位则保存了 _mask ,x11 = occupied|mask
0x232c6f534 <+20>: and w12, w1, w11
该指令用于计算 _cmd 所传递过来的 selector 在哈希表中的起始位置。因为 _cmd 保存在 x1 寄存器中，所以 w1 寄存器则包含了 _cmd 的低 32 位信息。而 w11 寄存器保存了上面提到的 _mask 信息。通过 AND 指令我们将这两个寄存器中数值与操作结果保存到 w12 寄存器中。计算结果相当于 _cmd % table_size。
0x232c6f538 <+24>: add x12, x10, x12, lsl #4
我们只得到了sel的索引,我们需要得到最终的实际地址。而这正是该指令的目的。因为哈希表的_buckets结构体都是 16 个字节,所以这里先对 x12 寄存器中的索引值左移 4 位也就是乘以 16 ，然后再将其与表首地址相加后的确切 _buckets 地址信息保存到 x12 中。
buckets+((_cmd & mask)<<4),((_cmd & mask)<<4) = hash_key
这是bucket_t结构体:
struct bucket_t {
#if __arm64__
MethodCacheIMP _imp;
cache_key_t _key;
};
0x232c6f53c <+28>: ldp x17, x9, [x12]
通过ldp指令，将x12寄存器中的_buckets对应的信息加载到x9和x17寄存器中，x9 = sel， x17 = IMP
0x232c6f540 <+32>: cmp x9, x1
0x232c6f544 <+36>: b.ne 0x232c6f54c ; <+44>
这段指令将x9中的sel和x1中的_cmd相比较if (_buckets->sel != _cmd)如果不等，则跳转0x232c6f54c，相等，则继续下一条指令
0x232c6f548 <+40>: br x17
跳转到x17寄存器所指位置，也就是IMP，方法的实现
0x232c6f54c <+44>: cbz x9,0x232c6f820 ;_objc_msgSend_uncached
x9 包含sel信息，与0作比较，如果等于0就跳转到_objc_msgSend_uncached方法进行更全面的查找,此时_buckets是空的，意味着查找失败。否则就说明_buckets不是空的，只是没有匹配，继续查找
0x232c6f550 <+48>: cmp x12, x10
0x232c6f554 <+52>: b.eq 0x232c6f560 ; <+64>
将 x12 寄存器中的当前 _buckets 地址与 x10 寄存器中的哈希表首地址进行比较。如果哈希桶中对应的项已经被占用但是又不是要执行的方法，则通过开地址法来继续寻找缓存该方法的桶，注意：这里是从尾部开始的（为了效率）
0x232c6f558 <+56>: ldp x17, x9, [x12, #-0x10]!
ldp指令 x12-=16，x12指向新的_buckets
0x232c6f55c <+60>: b 0x232c6f540 ; <+32>
现在是一个新的_buckets，这条指令回到0x232c6f540，再次查找，相当是循环查找
0x232c6f560 <+64>: add x12, x12, w11, uxtw #4
x12 = buckets+(mask<<4)，现在x12指向表的末尾
0x232c6f564 <+68>: ldp x17, x9, [x12]
ldp加载新的_buckets
0x232c6f568 <+72>: cmp x9, x1
0x232c6f56c <+76>: b.ne 0x232c6f574 ; <+84>
0x232c6f570 <+80>: br x17
和上面相同，检查bucket是否匹配，跳转
0x232c6f574 <+84>: cbz x9, 0x232c6f820 ; _objc_msgSend_uncached
还是和之前一样，miss if bucket->sel == 0
0x232c6f578 <+88>: cmp x12, x10
0x232c6f57c <+92>: b.eq 0x232c6f588 ; <+104>
再次检查是否已到表头
0x232c6f580 <+96>: ldp x17, x9, [x12, #-0x10]!
0x232c6f584 <+100>: b 0x232c6f568 ; <+72>
循环查找
0x232c6f588 <+104>: b 0x232c6f820 ; _objc_msgSend_uncached
跳转到c方法
0x232c6f58c <+108>: b.eq 0x232c6f5c4 ; <+164>
nil check,0为nil， 负数为tagged pointer
0x232c6f590 <+112>: adrp x10, 241366
0x232c6f594 <+116>: add x10, x10, #0x0 ; =0x0
这里加载了_objc_debug_taggedpointer_classes的地址，即tagged pointer主表。
0x232c6f598 <+120>: lsr x11, x0, #60
x0的前四位保存了tagged pointer的索引。如果需要把它用于索引，则需要将其右移60位，这样它就变成一个0-15的整数了。这个指令执行了位移并将索引放到x11中。
0x232c6f59c <+124>: ldr x16, [x10, x11, lsl #3]
这里通过x11里的索引到x10所指向的表中查找条目。x16寄存器现在包含了这个tagged pointer的类。
0x232c6f5a0 <+128>: adrp x10, 241365
0x232c6f5a4 <+132>: add x10, x10, #0xed8 ; =0xed8
扩展的tagged类执行起来也是一样的。这两条指令加载了指向扩展表的指针。
0x232c6f5a8 <+136>: cmp x10, x16
0x232c6f5ac <+140>: b.ne 0x232c6f530 ; <+16>
0x232c6f5b0 <+144>: adrp x10, 241366
0x232c6f5b4 <+148>: add x10, x10, #0x80 ; =0x80
0x232c6f5b8 <+152>: ubfx x11, x0, #52, #8
这条指令加载了扩展类的索引。它从self中的第52位开始，提取8位，保存到x11中。
0x232c6f5bc <+156>: ldr x16, [x10, x11, lsl #3]
这个索引用于在表中查找类，并存入x16
0x232c6f5c0 <+160>: b 0x232c6f530 ; <+16>
0x232c6f5c4 <+164>: mov x1, #0x0
0x232c6f5c8 <+168>: movi d0, #0000000000000000
0x232c6f5cc <+172>: movi d1, #0000000000000000
0x232c6f5d0 <+176>: movi d2, #0000000000000000
0x232c6f5d4 <+180>: movi d3, #0000000000000000
0x232c6f5d8 <+184>: ret
0x232c6f5dc <+188>: nop
以上代码是处理nil的过程
参考
Dissecting objc_msgSend on ARM64
Why objc_msgSend Must be Written in Assembly