深度讲解block:第一集&第二集

ARM 98浏览

 深度讲解block:第一集&第二集

 深度讲解block:第一集

 

 
 小引
还记得之前的两篇文章吗:iOS汇编教程:ARM(1)iOS汇编教程:ARM(2),里面介绍了Objective-C生成的汇编代码。本文介绍的内容也跟汇编相关,只不过是与block相关,如果对汇编有不了解的,可以先去看看那两篇带有启蒙性质的文章。本文将从汇编的角度来介绍block相关知识。另外,如果你对block还不了解的话,建议你先去看看我的上一篇文章:初识block
 
目录:
简介
基础知识
深入一个简单示例
源码在这里
何去何从
 
正文
简介
今天我们从编译器的角度观察一下block内部是如何工作的。这里说的block是指苹果为C语言增加的具有闭包性(closure)的一个功能,block已经是clang/LLVM编译器所支持的一部分了。我一直在想block是什么,以及它是如何奇迹般的出现在Objective-C对象中(开发者可以像处理实例对象一样,对block进行copy、retain、release)。本文我首先深入的介绍一点关于block的那些事。
 
基础知识
用过block的开发者都知道,下面的代码就是一个block:
  1. void(^block)(void) = ^{ 
  2.     NSLog(@"I'm a block!"); 
  3. }; 
 
上面的代码中创建了一个名为block的变量,并把一个简单的block代码赋值给这个变量。代码很简单,不是吗?不!!!在这里我想要搞清楚编译器对这点代码都做了些什么。
 
更进一步,下面的代码我给block传递了一个变量:
  1. void(^block)(int a) = ^{ 
  2.     NSLog(@"I'm a block! a = %i", a); 
  3. }; 
 
而下面的代码是从block中返回一个值:
  1. int(^block)(void) = ^{ 
  2.     NSLog(@"I'm a block!"); 
  3.     return 1; 
  4. }; 
 
作为一个封闭的包,block将所处的上下文封装到了block中:
  1. int a = 1; 
  2. void(^block)(void) = ^{ 
  3.     NSLog(@"I'm a block! a = %i", a); 
  4. }; 
 
编译器对上面这些代码具体是如何处理的——这才是我所感兴趣的。
 
深入一个简单示例
首先我的思路是看看编译器是如何编译一个非常简单的block。来看看如下代码:
  1. #import <dispatch/dispatch.h> 
  2.   
  3. typedef void(^BlockA)(void); 
  4.   
  5. __attribute__((noinline)) 
  6. void runBlockA(BlockA block) { 
  7.     block(); 
  8.   
  9. void doBlockA() { 
  10.     BlockA block = ^{ 
  11.         // Empty block 
  12.     }; 
  13.     runBlockA(block); 
 
之所以要用上面这样的代码,是因为我想看看block是如何创建的,以及如何调用一个block。如果block的创建和调用都在一个函数里面,那么优化器(optimiser)可能会对代码做优化处理,导致我们看不到任何感兴趣的东西,所以我给runBlockA函数添加了noinline,这样优化器就不会在doBlockA函数中对runBlockA的调用做内联优化处理。
 
上面代码通过编译器编译之后(armv7,03),会得到如下汇编指令:
  1.     .globl  _runBlockA 
  2.     .align  2 
  3.     .code   16                      @ @runBlockA 
  4.     .thumb_func     _runBlockA 
  5. _runBlockA: 
  6. @ BB#0: 
  7.     ldr     r1, [r0, #12] 
  8.     bx      r1 
 
上面的汇编代码是对应runBlockA函数——这相当的简单。注意观察之前的源码,可以知道这个函数只是简单的调用了block。在ARM EABI中,将r0(寄存器r0)设置为第一个参数。第一条指令(r1)是将存储在地址为r0 + 12的值装载到寄存器r1中。这可以理解为指针的解引用——读12个字节到寄存器中。然后跳转到这个地址执行后面的指令。注意,这里使用了r1,而r0没有被修改,仍然是原来的block。所以这里很有可能是利用第一个参数来调用block。
 
据此,可以确定block在结构中的一些排序规则:block被当做执行的函数时存储在某个结构中,并占据了12个字节。当传递一个block时,指向这些结构的一个指针被传递进来了。
 
下面来看看doBlockA函数:
  1.     .globl  _doBlockA 
  2.     .align  2 
  3.     .code   16                      @ @doBlockA 
  4.     .thumb_func     _doBlockA 
  5. _doBlockA: 
  6.     movw    r0, :lower16:(___block_literal_global-(LPC1_0+4)) 
  7.     movt    r0, :upper16:(___block_literal_global-(LPC1_0+4)) 
  8. LPC1_0: 
  9.     add     r0, pc 
  10.     b.w     _runBlockA 
 
OK,上面的代码也不复杂——这是关于pc(program counter)的相关加载。你可以将其看做是把变量___block_literal_global的地址加载到r0中。然后调用runBlockA函数。因为从之前的源码中,可以知道我们把block传递给了runBlockA,所以这里的___block_literal_global一定就是那个被传递的block对象了。
 
到目前为止,我们对上面的源码的运作有一些眉目了!不过这里的___block_literal_global是什么呢?继续看汇编代码,可以找到如下这样的内容:
  1. .align  2                       @ @__block_literal_global 
  2. lock_literal_global: 
  3. .long   __NSConcreteGlobalBlock 
  4. .long   1342177280              @ 0x50000000 
  5. .long   0                       @ 0x0 
  6. .long   ___doBlockA_block_invoke_0 
  7. .long   ___block_descriptor_tmp 
 
Cool!上面的汇编代码看起来像是一个结构体。在结构体中又5个值,每个值有4个字节(long)。这肯定就是RunBlockA调用中涉及到的那个block对象。再细看一下,12个字节所在处就像一个函数指针:___doBlockA_block_invoke_0。这也是runBlockA函数中跳转执行的那个分支(bx r1)。
 
那么上面的汇编代码中__NSConcreteGlobalBlock又是何物?OK,现在先不介绍这个,后面会做介绍哦!下面我们来看看另外两个感兴趣的东西:___doBlockA_block_invoke_0___block_descriptor_tmp,这两个东东同样出现在了汇编代码中:
  1.     .align  2 
  2.     .code   16                      @ @__doBlockA_block_invoke_0 
  3.     .thumb_func     ___doBlockA_block_invoke_0 
  4. ___doBlockA_block_invoke_0: 
  5.     bx      lr 
  6.   
  7.     .section        __DATA,__const 
  8.     .align  2                       @ @__block_descriptor_tmp 
  9. ___block_descriptor_tmp: 
  10.     .long   0                       @ 0x0 
  11.     .long   20                      @ 0x14 
  12.     .long   L_.str 
  13.     .long   L_OBJC_CLASS_NAME_ 
  14.   
  15.     .section        __TEXT,__cstring,cstring_literals 
  16. L_.str:                                 @ @.str 
  17.     .asciz   "v4@?0" 
  18.   
  19.     .section        __TEXT,__objc_classname,cstring_literals 
  20. L_OBJC_CLASS_NAME_:                     @ @"1L_OBJC_CLASS_NAME_" 
  21.     .asciz   "01" 
 
上面的代码中___doBlockA_block_invoke_0看起来有点像block的实现部分,只不过这里的block是空的,所以会立即返回(刚开始我们就期望编译一个空的block哦)。
接着看看___block_descriptor_tmp。这里可以看到另外一个数据结构——有4个值。其中第2个是20,这表示___block_literal_global的大小。接着是一个名为.str的C字符串,它的值为v4@?0,看起来有点像某个类型的编码形式。这可能是block 类型的编码(示例返回void和不携带任何参数)。上面代码中别的一些值我暂时还不清楚。
 
源码在这里
没错,这里有源代码!这是LLVM中compiler-rt项目的一部分。查看代码,我发现在Block_private.h文件中,有如下相关代码:
  1. struct Block_descriptor { 
  2.     unsigned long int reserved; 
  3.     unsigned long int size; 
  4.     void (*copy)(void *dst, void *src); 
  5.     void (*dispose)(void *); 
  6. }; 
  7.   
  8. struct Block_layout { 
  9.     void *isa; 
  10.     int flags; 
  11.     int reserved; 
  12.     void (*invoke)(void *, ...); 
  13.     struct Block_descriptor *descriptor; 
  14.     /* Imported variables. */ 
  15. }; 
 
这看起来很熟悉吧!其中Block_layout结构体就是___block_literal_global,而Block_descriptor结构体则是__block_descriptor_tmp。细看Block_descriptor中的第2个变量size正如我之前描述的一样(表示___block_literal_global的大小)。在Block_descriptor中的第3和第4个值有点奇怪。这看起来有点想函数指针,但是在上面的汇编代码中看起来更像是两个字符串。现在我忽略掉这个细节。
 
Block_layout中的isa肯定就是__NSConcreteGlobalBlock,这也将确定block如何能够模拟Objective-C对象。如果__NSConcreteGlobalBlock是一个Class,那么Objective-C消息派送系统会将block对象当做一个普通的对象来处理。这跟如何处理toll-free
bridging工作类似。更多相关toll-free bridging信息,可以阅读Mike Ash写的一篇优秀文章。
 
将所有的代码片段拼凑起来,编译器做的工作内容看起来如下所示:
  1. #import <dispatch/dispatch.h> 
  2.   
  3. __attribute__((noinline)) 
  4. void runBlockA(struct Block_layout *block) { 
  5.     block->invoke(); 
  6.   
  7. void block_invoke(struct Block_layout *block) { 
  8.     // Empty block function 
  9.   
  10. void doBlockA() { 
  11.     struct Block_descriptor descriptor; 
  12.     descriptor->reserved = 0; 
  13.     descriptor->size = 20; 
  14.     descriptor->copy = NULL; 
  15.     descriptor->dispose = NULL; 
  16.   
  17.     struct Block_layout block; 
  18.     block->isa = _NSConcreteGlobalBlock; 
  19.     block->flags = 1342177280; 
  20.     block->reserved = 0; 
  21.     block->invoke = block_invoke; 
  22.     block->descriptor = descriptor; 
  23.   
  24.     runBlockA(&amp;block); 
 
 
 

深度围观block:第二集
今天翻译了第二篇,这个翻译是比较痛苦(其实不止这篇,所有的都是), 不比单纯的阅读,许多地方需要查阅资料,并细心的遣词造句,还得注意词不达意的地方(示例文中的A block that captures scope我翻译为block的拷贝范围,总感觉缺了一些作者原意,功力有限啊)。所以,我劝大家要是能看原文尽量去看原文吧,我这翻译的权当参考。
 
目录
介绍
block类型
block的拷贝范围
block拷贝对象的类型
何去何从
 
正文
介绍
接着-深度围观block:第一集,继续从编译器的角度深度围观block。在本文中,将介绍block并不是一成不变的,以及block在栈上的构成。
 
block类型
在第一篇文章中,我们已经看到block有一个_NSConcreteGlobalBlock这样的类。由于所有变量都是已知的,所以在编译期间,block的结构(structure)和描述(descriptor)都将全部被初始化。关于block这里有几种不同的类型,每种类型都有对应的类。为了简单起见,这里只考虑其中三种:
 
_NSConcreteGlobalBlock是定义一个全局的block,在编译器就已经完成相关初始化任务。这种类型的block不会涉及到任何拷贝,示例一个空的block。
_NSConcreteStackBlock是一个分配在栈上的block。这里是所有最终被拷贝到堆(heap)上的block的开始。
_NSConcreteMallocBlock是分配到堆(heap)上的block。拷贝完一个block之后,这就会结束。当block的引用计数变为0,该block就会被释放。
 
block拷贝范围
这次我们来看看另外一些代码,如下所示:
  1. #import <dispatch/dispatch.h> 
  2.   
  3. typedef void(^BlockA)(void); 
  4. void foo(int); 
  5.   
  6. __attribute__((noinline)) 
  7. void runBlockA(BlockA block) { 
  8.     block(); 
  9.   
  10. void doBlockA() { 
  11.     int a = 128; 
  12.     BlockA block = ^{ 
  13.         foo(a); 
  14.     }; 
  15.     runBlockA(block); 
 
为了让block拷贝一些内容,上面的代码中调用了foo函数,并给这个函数传递了一个变量。再说一下,本文涉及到的汇编代码是与armv7相关指令。下面是其中一部分汇编指令:
  1.     .globl  _runBlockA 
  2.     .align  2 
  3.     .code   16                      @ @runBlockA 
  4.     .thumb_func     _runBlockA 
  5. _runBlockA: 
  6.     ldr     r1, [r0, #12] 
  7.     bx      r1 
 
上面的汇编代码与runBlockA函数相关,这跟第一篇文章中的相同——都是调用了block中的invoke函数。接着是doBlockA汇编代码,如下所示:
  1.     .globl  _doBlockA 
  2.     .align  2 
  3.     .code   16                      @ @doBlockA 
  4.     .thumb_func     _doBlockA 
  5. _doBlockA: 
  6.     push    {r7, lr} 
  7.     mov     r7, sp 
  8.     sub     sp, #24 
  9.     movw    r2, :lower16:(L__NSConcreteStackBlock$non_lazy_ptr-(LPC1_0+4)) 
  10.     movt    r2, :upper16:(L__NSConcreteStackBlock$non_lazy_ptr-(LPC1_0+4)) 
  11.     movw    r1, :lower16:(___doBlockA_block_invoke_0-(LPC1_1+4)) 
  12. LPC1_0: 
  13.     add     r2, pc 
  14.     movt    r1, :upper16:(___doBlockA_block_invoke_0-(LPC1_1+4)) 
  15.     movw    r0, :lower16:(___block_descriptor_tmp-(LPC1_2+4)) 
  16. LPC1_1: 
  17.     add     r1, pc 
  18.     ldr     r2, [r2] 
  19.     movt    r0, :upper16:(___block_descriptor_tmp-(LPC1_2+4)) 
  20.     str     r2, [sp] 
  21.     mov.w   r2, #1073741824 
  22.     str     r2, [sp, #4] 
  23.     movs    r2, #0 
  24. LPC1_2: 
  25.     add     r0, pc 
  26.     str     r2, [sp, #8] 
  27.     str     r1, [sp, #12] 
  28.     str     r0, [sp, #16] 
  29.     movs    r0, #128 
  30.     str     r0, [sp, #20] 
  31.     mov     r0, sp 
  32.     bl      _runBlockA 
  33.     add     sp, #24 
  34.     pop     {r7, pc} 
 
看看,这跟之前的代码有所不同了。看起来这不仅仅是从一个全局的符号中加载block,而且还做了额外的一些事情。乍一看这么多代码让人有点无从下手,不过认真看,还是很容易理解的。从上面的代码可以看出,编译器已经忽略了对代码排序的优化,为了方便阅读代码,我对上面的汇编代码重新进行排序(当然,请相信我,这不会影响任何功能)。下面是我重排好的代码效果:
  1. _doBlockA: 
  2.         // 1 
  3.         push    {r7, lr} 
  4.         mov     r7, sp 
  5.   
  6.         // 2 
  7.         sub     sp, #24 
  8.   
  9.         // 3 
  10.         movw    r2, :lower16:(L__NSConcreteStackBlock$non_lazy_ptr-(LPC1_0+4)) 
  11.         movt    r2, :upper16:(L__NSConcreteStackBlock$non_lazy_ptr-(LPC1_0+4)) 
  12. LPC1_0: 
  13.         add     r2, pc 
  14.         ldr     r2, [r2] 
  15.         str     r2, [sp] 
  16.   
  17.         // 4 
  18.         mov.w   r2, #1073741824 
  19.         str     r2, [sp, #4] 
  20.   
  21.         // 5 
  22.         movs    r2, #0 
  23.         str     r2, [sp, #8] 
  24.   
  25.         // 6 
  26.         movw    r1, :lower16:(___doBlockA_block_invoke_0-(LPC1_1+4)) 
  27.         movt    r1, :upper16:(___doBlockA_block_invoke_0-(LPC1_1+4)) 
  28. LPC1_1: 
  29.         add     r1, pc 
  30.         str     r1, [sp, #12] 
  31.   
  32.         // 7 
  33.         movw    r0, :lower16:(___block_descriptor_tmp-(LPC1_2+4)) 
  34.         movt    r0, :upper16:(___block_descriptor_tmp-(LPC1_2+4)) 
  35. LPC1_2: 
  36.         add     r0, pc 
  37.         str     r0, [sp, #16] 
  38.   
  39.         // 8 
  40.         movs    r0, #128 
  41.         str     r0, [sp, #20] 
  42.   
  43.         // 9 
  44.         mov     r0, sp 
  45.         bl      _runBlockA 
  46.   
  47.         // 10 
  48.         add     sp, #24 
  49.         pop     {r7, pc} 
 
下面我们来看看这些代码都做了什么:
 
1.开场白。首先将 r7 push到栈上面——因为r7会被覆盖,而r7寄存器中的内容在跨函数调用时是需要用到的。lr是链接寄存器(link register),该寄存器中存储着当这个函数返回时需要执行下一条指令的地址。接着mov这条指令的作用是把栈指针保存到r7寄存器中。
 
2.从栈指针所处位置开始减去24,也就是在栈空间上开辟24字节来存储数据。
 
3.这里涉及到的代码是为了对符号L__NSConcreteStackBlock$non_lazy_ptr进行寻址,由于跟pc(program counter)相关联,所以无论代码处于二进制文件中任何位置,当最终链接时,都能对该符号做到正确的寻址。
 
4.将值1073741824存储到栈指针 + 4 的位置。
 
5.将值0存储到栈指针 + 8 的位置。现在,将要发生什么可能已经变得逐渐清晰了——在栈上创建了一个Block_layout结构的对象!到现在为止,已经设置了该结构的3个值:isa指针,flags和reserved值
 
6.将___doBlockA_block_invoke_0存储至栈指针 + 12的位置。这是block结构中的invoke
 
7.将___block_descriptor_tmp存储至栈指针 + 16的位置。这是block结构中的descriptor
 
8.将值128存储到栈指针 + 20的位置。如果回头看看Block_layout结构,可以看到里面只应该有5个值。那么在这个block结构体后面存储的128是什么呢?——注意到这个128实际上就是在block中拷贝的变量的值。所以这肯定就是存储block使用到的值的地方——在Block_layout结构尾部。
 
9.现在栈指针指向了已经完成初始化之后的block结构,在这里的汇编指令是将栈指针装载到r0中,然后调用runBlockA函数。(记住:在ARM EABI中,r0中存储的内容被当做函数的第一个参数)。
 
10.最后将栈指针加上24,这样就能够把最开始减去的24(在栈上开辟的24位空间)收回来。接着将栈中的两个值pop到r7pc寄存器中。这里pop到r7中的,跟最开始从r7中push至栈中的内容是一致的,而pc的值则是最开始push lr到栈中的值,这样当函数返回时,可以让CPU能够正确的继续执行后续指令。
 
下面我们再看看block中的invoke函数和descriptor。希望跟第一集中的不要有太大差别。如下汇编代码:
  1.     .align  2 
  2.     .code   16                      @ @__doBlockA_block_invoke_0 
  3.     .thumb_func     ___doBlockA_block_invoke_0 
  4. ___doBlockA_block_invoke_0: 
  5.     ldr     r0, [r0, #20] 
  6.     b.w     _foo 
  7.   
  8.     .section        __TEXT,__cstring,cstring_literals 
  9. L_.str:                                 @ @.str 
  10.     .asciz   "v4@?0" 
  11.   
  12.     .section        __TEXT,__objc_classname,cstring_literals 
  13. L_OBJC_CLASS_NAME_:                     @ @"1L_OBJC_CLASS_NAME_" 
  14.     .asciz   "01P" 
  15.   
  16.     .section        __DATA,__const 
  17.     .align  2                       @ @__block_descriptor_tmp 
  18. ___block_descriptor_tmp: 
  19.     .long   0                       @ 0x0 
  20.     .long   24                      @ 0x18 
  21.     .long   L_.str 
  22.     .long   L_OBJC_CLASS_NAME_ 
 
看着没错,跟第一集中的没多大区别。唯一不同的就是block descriptor中的size——现在是24(之前是20)。这是因为block拷贝了一个整型值,所以block的结构需要24个字节,而不再是标准的20个字节了。在之前的代码中,我们已经分析了在创建block时,多出的4个字节被添加到block结构的尾部。
 
在实际的block函数中,示例___doBlockA_block_invoke_0,可以看到从block结构尾部读取出相关值,如r0 + 20,就是在block中拷贝的变量。
 
block拷贝对象的类型
下面我们来看看如果block拷贝的是别的对象类型(示例 NSString),而不是integer,会发生什么呢?如下代码:
  1. #import <dispatch/dispatch.h> 
  2.   
  3. typedef void(^BlockA)(void); 
  4. void foo(NSString*); 
  5.   
  6. __attribute__((noinline)) 
  7. void runBlockA(BlockA block) { 
  8.     block(); 
  9.   
  10. void doBlockA() { 
  11.     NSString *a = @"A"
  12.     BlockA block = ^{ 
  13.         foo(a); 
  14.     }; 
  15.     runBlockA(block); 
 
由于doBlockA变化不大,所以在此不深入介绍。这里感兴趣的是根据上面代码创建的block descriptor结构:
  1.     .section        __DATA,__const 
  2.     .align  4                       @ @__block_descriptor_tmp 
  3. ___block_descriptor_tmp: 
  4.     .long   0                       @ 0x0 
  5.     .long   24                      @ 0x18 
  6.     .long   ___copy_helper_block_ 
  7.     .long   ___destroy_helper_block_ 
  8.     .long   L_.str1 
  9.     .long   L_OBJC_CLASS_NAME_ 
 
注意看上面的汇编代码中有指向两个函数(___copy_helper_block_和___destroy_helper_block_)的指针。下面是这两个函数的定义:
 
  1. .align  2 
  2. .code   16                      @ @__copy_helper_block_ 
  3. .thumb_func     ___copy_helper_block_ 
  4. opy_helper_block_: 
  5. ldr     r1, [r1, #20] 
  6. adds    r0, #20 
  7. movs    r2, #3 
  8. b.w     __Block_object_assign 
  9.  
  10. .align  2 
  11. .code   16                      @ @__destroy_helper_block_ 
  12. .thumb_func     ___destroy_helper_block_ 
  13. estroy_helper_block_: 
  14. ldr     r0, [r0, #20] 
  15. movs    r1, #3 
  16. b.w     __Block_object_dispose 
 
这里我先假设当block被拷贝和销毁时,都会调用这里的函数。那么被block拷贝的对象肯定会发生reatain和release。上面的代码中,可以看出如果r0和r1包含有效数据时,拷贝函数接收两个参数(r0和r1)。而销毁函数接收一个参数。可以看出所有的拷贝和销毁任务都应该是由__Block_object_assign__Block_object_dispose两个函数完成的。这两个函数位于block的运行时代码中(是LLVM里面compiler-rt工程的一部分)。
 
如果你希望了解一下block运行时相关代码,可以来这里下载源码:http://compiler-rt.llvm.org。特别关注一下里面的runtime.c文件。

何去何从
在下一集中我将调查Block_copy相关代码,并看看相关工作处理情况,以此来深度围观一下block运行时。通过下一集的学习,你也将会深入了解拷贝和销毁函数(也就是本文中我们刚刚看到的在block拷贝对象时使用的函数)。