atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title><![CDATA[Category: assembler | Cocoa Factory]]></title>
  <link href="http://cocoa-factory.github.com/blog/categories/assembler/atom.xml" rel="self"/>
  <link href="http://cocoa-factory.github.com/"/>
  <updated>2013-03-23T07:24:26-05:00</updated>
  <id>http://cocoa-factory.github.com/</id>
  <author>
    <name><![CDATA[Alan Duncan]]></name>
    
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>

  
  <entry>
    <title type="html"><![CDATA[LLDB print registers]]></title>
    <link href="http://cocoa-factory.github.com/blog/2012/12/16/lldb-print-registers/"/>
    <updated>2012-12-16T12:53:00-06:00</updated>
    <id>http://cocoa-factory.github.com/blog/2012/12/16/lldb-print-registers</id>
    <content type="html"><![CDATA[<p>Somes while debugging, or when you want to understand what the compiler doing with your code under the hood, you may want to print the contents of all the registers in the current frame.</p>

<p>To print the current register contents in LLDB it's <code>register read</code>:
<img src="/images/lldb.png" alt="console" /></p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[x86_64 Assembly language tutorial:part 4]]></title>
    <link href="http://cocoa-factory.github.com/blog/2012/11/24/x86-64-assembly-language-tutorial-part-4/"/>
    <updated>2012-11-24T05:41:00-06:00</updated>
    <id>http://cocoa-factory.github.com/blog/2012/11/24/x86-64-assembly-language-tutorial-part-4</id>
    <content type="html"><![CDATA[<p>In <a href="">Part I</a> or our x86_64 assembly language tutorial for Mac OS, we analyzed the disassembly of a simple C program.  In <a href="">Part II</a>, we extended the example and learned more about the x86_64 ABI and register usage.  In <a href="">Part III</a>, we delved into the world of objects and showed what happens behind the scenes when objects meet silicon.</p>

<p>This time, we'll take a break from the analytical mode to try our hand at writing a simple program in assembly.   We're going to use two different assemblers to show the range of syntactical differences.</p>

<h3>Xcode assembly language project</h3>

<p>Although Xcode doesn't have an assembly language project template, you can start a new command line tool project for Mac OS and just delete the main.m file.  Then you can add an assembly language file to the project and paste the following code:</p>

<p><div><script src='https://gist.github.com/4139421.js?file='></script>
<noscript><pre><code>.private_extern	_main
.globl	_main
_main:                                  #   main entry point

    pushq	%rbp

    movq	%rsp, %rbp

    leaq	_helloMessage(%rip), %rdi
    callq	_puts
    xorl	%eax, %eax
    popq	%rbp
    ret

.section	__TEXT,__cstring,cstring_literals

_helloMessage:  
    .asciz	 &quot;Hello world!&quot;</code></pre></noscript></div>
</p>

<p>Like we've done with each of the prior tutorials, lets walk through the code, as simple as it is, step-by-step</p>

<h4>Step 1 - Preamble</h4>

<p><code>c-objdump
.private_extern _main
.globl  _main
_main:                                  #   main entry point
</code></p>

<p>Here we're just defining symbols for our entry point <code>_main</code>.</p>

<h4>Step 2 - Save frame pointer</h4>

<p>``` c-objdump
pushq   %rbp</p>

<p>movq    %rsp, %rbp
```
Now we just save the frame pointer.</p>

<h4>Step 3 - Print a "Hello world!" string</h4>

<p>``` c-objdump
leaq    <em>helloMessage(%rip), %rdi
callq   </em>puts</p>

<p>//</p>

<p>.section    <strong>TEXT,</strong>cstring,cstring_literals</p>

<p>_helloMessage:</p>

<pre><code>.asciz   "Hello world!"
</code></pre>

<p>```</p>

<p>Here we load a reference to the <code>_helloMessage</code> into <code>%rdi</code> our first function argument register.  And call <code>_puts</code>.  The <code>leaq</code> instruction is the 64-bit version of <code>lea</code> in x86 assembly.  This instruction places the <em>address</em> specified by the second operand into the register specified by the first operand.  It's not the contents of the memory location that are loaded, only the effective address that is computed and placed into the register.  (Sounds like a pointer in higher level languages, doesn't it?)</p>

<h4>Step 4 - Clean up</h4>

<p><code>c-objdump
xorl    %eax, %eax
popq    %rbp
ret
</code></p>

<p>Here we zero our function return register, pop the frame pointer, and return.  That was easy!</p>

<h3>NASM project</h3>

<p>Next, we're going to go through an alternative way of getting the job done with an assembler called nasm - for "netwide assembler".  It uses a very different syntax than we are accustomed to seeing from the analyses we've done so far.  We also are responsible for building the Mach-O object code and linking the program ourselves.  But it's a good experience to go through.</p>

<h4>Download the 64-bit version of <code>nasm</code></h4>

<p>For compatibility with our GNU assembler version of the "Hello world" program, we want to do it in 64 bit form.  But the version of <code>nasm</code> that ships with Mac as of this writing is an older 32 bit version.  You can check it our on your computer with <code>nasm -v</code> at the Terminal.  On my machine, it is <code>0.98.40</code>.  We need to download the latest version before continuing.  You can find it <a href="http://www.nasm.us/pub/nasm/releasebuilds/2.10.05/macosx/">here</a>.  I just downloaded it, unzipped, and copied to <code>/usr/bin</code> so I wouldn't have to deal with mofiying the path.</p>

<h4>Write the program for use in <code>nasm</code></h4>

<p>Here's the complete source:</p>

<p><div><script src='https://gist.github.com/4139297.js?file='></script>
<noscript><pre><code>;
;
;   hello64.asm
;
;   A quick demonstration of 64 assembly language on Mac OS
;
;   Generate object code:
;nasm-2.09.10 -f macho64 hello64.asm
;
;   Link executable
;gcc -m64 -mmacosx-version-min=10.6 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -o hello64 hello64.o
;

section .data
    
    hello            db &quot;Hello, world!&quot;, 0  

section .text
    
    global _main
    extern _puts

_main:
    push    r15             ;save %r15 to stack
    mov     r15,    rsp     ;load the stack pointer into %r15
    push    rbx             ;push base pointer to the stack

    mov     rbx,    rsp     ;load the stack pointer into the base pointer
    and     spl,    0xF0    ;align the stack pointer on a boundary

    mov     rdi,    hello   ;move address of string to %rdi (1st function arg register)
    call    _puts           ;call puts

    mov     rsp,    rbx     ;mov %rbx back into stack pointer after the library call

    pop     rbx             ;restore %rbx (a callee saved register)
    mov     rsp,    r15     ;restore the stack pointer from %r15
    pop     r15             ;restore %r15
    ret</code></pre></noscript></div>
</p>

<p>The first thing to recognize with <code>nasm</code> syntax is that the operand order is reversed compared with the GNU assembler syntax.  So the instruction <code>mov r15, rsp</code> moves the contents of register <code>rsp</code> to <code>r15</code>.  We also omit the <code>%</code> sign before register names.  And nasm infers the correct version of an instruction depending on the width of the operands; so we use <code>mov</code> instead of <code>movb</code>, <code>movl</code>, or <code>movq</code>.  Apart from those differences, we do things the same way.  Let's go through the program step-by-step.</p>

<h4>Step 1: Application sections</h4>

<p>``` c-objdump
section .data</p>

<pre><code>hello            db "Hello, world!", 0  
</code></pre>

<p>section .text</p>

<pre><code>global _main
extern _puts
</code></pre>

<p>```</p>

<p>We being with a data section that contain a single symbol <code>hello</code>.  <code>db</code> signifies a data block.  In this case the data block is a NULL-terminated string.  The <code>0</code> after the string is the NULL termination.  After the <code>.data</code> section, we have the <code>.text</code> section which is the code.  He expose <code>_main</code> - our entry point - as a global symbol and mame note that <code>_puts</code> is defined elsewhere and will need to be linked.</p>

<h4>Step 2: Prologue</h4>

<p>``` c-objdump
_main:</p>

<pre><code>push    r15             ;save %r15 to stack
mov     r15,    rsp     ;load the stack pointer into %r15
push    rbx             ;push base pointer to the stack
</code></pre>

<p>```</p>

<p>This is similar to the prologues we've seen before - but take a close look here at the reversed order of the operands.  If you don't understand what our function prologue is doing at this point, best go back to our earlier tutorials and review.</p>

<h4>Step 3: Call <code>puts</code></h4>

<p>``` c-objdump
mov     rbx,    rsp     ;load the stack pointer into the base pointer
and     spl,    0xF0    ;align the stack pointer on a boundary</p>

<p>mov     rdi,    hello   ;move address of string to %rdi (1st function arg register)
call    _puts           ;call puts
```</p>

<p>The first two instructions have the effect of aligning the stack pointer to a 16 byte boundary as required by the x86_64 ABI before the upcoming call.  Then we move the address of the symbol <code>hello</code> to the <code>%rdi</code> register (the first function argument register) and call <code>_puts</code>.</p>

<h4>Step 4: Cleanup</h4>

<p>``` c-objdump
mov     rsp,    rbx     ;mov %rbx back into stack pointer after the library call</p>

<p>pop     rbx             ;restore %rbx (a callee saved register)
mov     rsp,    r15     ;restore the stack pointer from %r15
pop     r15             ;restore %r15
ret
```</p>

<p>All that's left is to clean up, restoring the registers and the stack before returning.</p>

<p><img class="left" src="http://i.imgur.com/a7rqS.png" title="&#34;Build, link, run&#34;" alt="&#34;Build, link, run&#34;"></p>

<h4>Build</h4>

<p>But the program text file isn't useful by itself.  Save it to disk as "hello64.asm".  Now we need to generate the object code.  You will need to adjust the path names but on my machine, it's: <code>nasm-2.09.10 -f macho64 hello64.asm</code> to generate the 64-bit Mach-O object code and <code>gcc -m64 -mmacosx-version-min=10.6 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -o hello64 hello64.o</code> to link it.</p>

<p>Now to run our little application, from the directory where it resides:  <code>/.hello64</code>.</p>

<p>Questions or comments about this post?  Contact the author of this post <code>@NSBum</code>.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[x86_64 Assembly Language Tutorial: Part 3]]></title>
    <link href="http://cocoa-factory.github.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-3/"/>
    <updated>2012-11-23T08:48:00-06:00</updated>
    <id>http://cocoa-factory.github.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-3</id>
    <content type="html"><![CDATA[<p>In our <a href="http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1/">first tutorial</a> in this series, we presented a simple program in C and analyzed its x86_64 disassembly.  We extended the discussion in <a href="http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-2/">Part II</a> to show register usage according to the x86_64 ABI.</p>

<p>Now, we're going to start to tiptoe gently into the world of Objective-C objects and use that as a platform for peeking into what ARC does to our code behind our backs.  Let's get started with a very simple Objective-C program:</p>

<p><div><script src='https://gist.github.com/4135901.js?file='></script>
<noscript><pre><code>#import &lt;Foundation/Foundation.h&gt;

@interface Foo : NSObject {
    NSInteger _bar;
}

- (id)initWithBar:(NSInteger)aBar;
- (void)printBar;

@end

@implementation Foo

- (id)initWithBar:(NSInteger)aBar {
    self = [super init];
    if( !self ) return nil;
    
    _bar = aBar;
    return self;
}

- (void)printBar {
    printf(&quot;%ld&quot;,_bar);
}

@end

int main(int argc, const char * argv[])
{

    @autoreleasepool {
        Foo *foo = [[Foo alloc] initWithBar:15];
        [foo printBar];
    }
    return 0;
}</code></pre></noscript></div>
</p>

<p>Build and run this little application in Xcode and use the Assistant editor to review its disassembly just like we showed in <a href="http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-2/">Part II</a>:</p>

<p><div><script src='https://gist.github.com/4135938.js?file='></script>
<noscript><pre><code>0x100000de0:  pushq  %rbp
0x100000de1:  movq   %rsp, %rbp
0x100000de4:  pushq  %r15
0x100000de6:  pushq  %r14
0x100000de8:  pushq  %rbx
0x100000de9:  pushq  %rax
0x100000dea:  callq  0x100000e52               ; symbol stub for: objc_autoreleasePoolPush
0x100000def:  movq   %rax, %r14
0x100000df2:  movq   903(%rip), %rdi           ; (void *)0x0000000100001190: Foo
0x100000df9:  leaq   880(%rip), %rsi           ; { /usr/lib/libobjc.A.dylib`objc_msgSend_vtable1, &quot;alloc&quot; }
0x100000e00:  callq  *874(%rip)                ; { /usr/lib/libobjc.A.dylib`objc_msgSend_vtable1, &quot;alloc&quot; }
0x100000e06:  movq   843(%rip), %rsi           ; &quot;initWithBar:&quot;
0x100000e0d:  movq   508(%rip), %r15           ; (void *)0x00007fff871c3240: objc_msgSend
0x100000e14:  movq   %rax, %rdi
0x100000e17:  movl   $15, %edx
0x100000e1c:  callq  *%r15
0x100000e1f:  movq   %rax, %rbx
0x100000e22:  movq   823(%rip), %rsi           ; &quot;printBar&quot;
0x100000e29:  movq   %rbx, %rdi
0x100000e2c:  callq  *%r15
0x100000e2f:  movq   %rbx, %rdi
0x100000e32:  callq  0x100000e5e               ; symbol stub for: objc_release
0x100000e37:  movq   %r14, %rdi
0x100000e3a:  callq  0x100000e4c               ; symbol stub for: objc_autoreleasePoolPop
0x100000e3f:  xorl   %eax, %eax
0x100000e41:  addq   $8, %rsp
0x100000e45:  popq   %rbx
0x100000e46:  popq   %r14
0x100000e48:  popq   %r15
0x100000e4a:  popq   %rbp
0x100000e4b:  ret</code></pre></noscript></div>
</p>

<h3>Step-by-step</h3>

<p>Just looking over the disassembly, we see there are many more calls to functions in the Objective-C runtime; this will keep us busy in the step-by-step analysis.</p>

<h4>Step 1 - Preamble</h4>

<p><code>c-objdump
0x100000de0:  pushq  %rbp
0x100000de1:  movq   %rsp, %rbp
0x100000de4:  pushq  %r15
0x100000de6:  pushq  %r14
0x100000de8:  pushq  %rbx
0x100000de9:  pushq  %rax
</code></p>

<p>As with our previous forays into the world of assembly language, the function call to <code>main</code> starts with the typical preamble where we push the base pointer, move the current stack pointer to the base pointer then push several registers that we're going to use later.</p>

<h4>Step 2 - Begin autorelease pool</h4>

<p><code>c-objdump
0x100000dea:  callq  0x100000e52               ; symbol stub for: objc_autoreleasePoolPush
0x100000def:  movq   %rax, %r14
</code></p>

<p>Here we call the <code>objc_autoreleasePoolPush</code> function in the Object-C runtime and save its return value - presumably a reference to the autorelease pool to the register <code>%r14</code>.</p>

<h4>Step 3 - Allocating a <code>Foo</code></h4>

<p><code>c-objdump
0x100000df2:  movq   903(%rip), %rdi           ; (void *)0x0000000100001190: Foo
0x100000df9:  leaq   880(%rip), %rsi           ; { /usr/lib/libobjc.A.dylib`objc_msgSend_vtable1, "alloc" }
0x100000e00:  callq  *874(%rip)                ; { /usr/lib/libobjc.A.dylib`objc_msgSend_vtable1, "alloc" }
</code></p>

<p>From the comments, it looks like we're going to allocate a new <code>Foo</code>.  The instruction pointer offsets are specified, but they don't really tell us that much.  If we want to learn more, we can switch Xcode's Assistant view to Assembly.  Let's looks at this very carefully.</p>

<p>The first instruction corresponds to the following in the assembly code:</p>

<p><code>c-objdump
movq    L_OBJC_CLASSLIST_REFERENCES_$_(%rip), %rcx
movq    %rcx, %rdi
</code></p>

<p>The value from the executable that we are loading into <code>%rdi</code> is <code>rip</code> + <code>L_OBJC_CLASSLIST_REFERENCES_$_</code>.  Let's look at what's at that location:</p>

<p>``` c-objdump
L_OBJC_CLASSLIST_REFERENCES<em>$</em>:</p>

<pre><code>.quad   _OBJC_CLASS_$_Foo

.section    __TEXT,__objc_methname,cstring_literals
</code></pre>

<p>```</p>

<p><code>.quad</code> is an assembler directive that emits an 8-byte integer, in this case the symbol <code>_OBJC_CLASS_$_Foo</code>.  Rather than go further down the rabbit hole at this stage, let's just say that this is a reference to the class <code>Foo</code> which we are loading into <code>%rdi</code>.</p>

<p>Then we have the instruction <code>0x100000df9:  leaq   880(%rip), %rsi</code> in the disassembly.  Turning again to the <strong>assembly</strong> code again:</p>

<p><code>c-objdump
leaq    l_objc_msgSend_fixup_alloc(%rip), %rsi
</code></p>

<p>We're going to digress for a second examine this symbol <code>objc_msgSend_fixup_alloc</code> because it tells us something about the Objective-C runtime.  Most Objective-C methods get dispatched using a hash table in  <code>objc_msgSend</code>.  But some of the most commonly used method are dispatched using a virtual table as a runtime optimization.  In fact, if we look at the comment <code>{ /usr/lib/libobjc.A.dylib 'objc_msgSend_vtable1', "alloc" }</code> we can see evidence of the obtimization.  The function <code>objc_msgSend_vtable1</code> is the vtable-referenced version of <code>objc_msgSend</code> for <code>alloc</code>.  For completeness, others include:</p>

<table>
<thead>
<tr>
<th>Optimized objc_msgSend  </th>
<th> Referenced method</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>objc_msgSend_vTable0</code>  </td>
<td> <code>allocWithZone:</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable1</code>  </td>
<td> <code>alloc</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable2</code>  </td>
<td> <code>class</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable3</code>  </td>
<td> <code>self</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable4</code>  </td>
<td> <code>isKindOfClass:</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable5</code>  </td>
<td> <code>respondsToSelector:</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable6</code>  </td>
<td> <code>isFlipped</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable7</code>  </td>
<td> <code>length</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable8</code>  </td>
<td> <code>objectForKey:</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable9</code>  </td>
<td> <code>count</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable10</code> </td>
<td> <code>objectAtIndex:</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable11</code> </td>
<td> <code>isEqualToString:</code></td>
</tr>
<tr>
<td><code>objc_msgSend_vTable12</code> </td>
<td> <code>isEqual:</code></td>
</tr>
</tbody>
</table>


<p>Back to our function call setup; we've loaded a reference to the class <code>Foo</code> into <code>%rdi</code> which according to the <a href="http://www.x86-64.org/documentation/abi.pdf">x86_64 ABI</a> is the first argument to a function.  And we've loaded <code>objc_msgSend_vTable1</code> into <code>%rsi</code> which is the second argument to a function.  All that's left is to call a function.  Turning to the <strong>assembly</strong> code again, we see that the calling instruction is <code>callq  *l_objc_msgSend_fixup_alloc(%rip)</code> meaning that we are calling the address of the symbol <code>l_objc_msgSend_fixup_alloc</code> + the address of the instruction pointer.  Following the symbol <code>l_objc_msgSend_fixup_alloc</code> further in the assembly, there is a <code>.quad</code> value of <code>_objc_msgSend_fixup</code> there.  So, we're calling <code>objc_msgSend_fixup</code> with the parameters of <code>Foo</code> and <code>alloc</code>, thereby allocating a <code>Foo</code>.  Whew.</p>

<h4>Step 4 - Initializing a <code>Foo</code></h4>

<p>Having allocated a <code>Foo</code> we'll probably have to initialize it.  Here's the assembly code that does it:</p>

<p><code>c-objdump
0x100000e06:  movq   843(%rip), %rsi           ; "initWithBar:"
0x100000e0d:  movq   508(%rip), %r15           ; (void *)0x00007fff871c3240: objc_msgSend
0x100000e14:  movq   %rax, %rdi
0x100000e17:  movl   $15, %edx
0x100000e1c:  callq  *%r15
</code></p>

<p>We move a reference to <code>initWithBar</code> into <code>%rsi</code> which is always our 2nd argument register.  Then we move <code>objc_msgSend</code> to <code>%r15</code> which we later call.  The instruction <code>movq   %rax, %rdi</code> moves the object returned by <code>alloc</code> to <code>%rdi</code> which is our 1st function argument register.  So we have arguments 1 and 2 taken care of.  What about the value of <code>bar</code>?  The instruction <code>movl   $15, %edx</code> loads the decimal value 15 into <code>%edx</code>.  Remember that <code>%edx</code> is the lower 32 bits of <code>%rdx</code> which is the 3rd function argument register in the ABI.  No we have all three arguments to <code>objc_msgSend</code> taken care of; and we call it.</p>

<h4>Step 5 - Calling <code>printBar</code></h4>

<p>Starting to get the hang of this?  Let's look at how we call a method on our <code>Foo</code> instance.</p>

<p><code>c-objdump
0x100000e1f:  movq   %rax, %rbx
0x100000e22:  movq   823(%rip), %rsi           ; "printBar"
0x100000e29:  movq   %rbx, %rdi
0x100000e2c:  callq  *%r15
</code></p>

<p>The instruction pair <code>0x100000e1f:  movq   %rax, %rbx</code> and <code>0x100000e29:  movq   %rbx, %rdi</code> move the <code>Foo</code> instance returned by the <code>initWithBar:</code> method to <code>%rdi</code>.  So the instance, then, is our first function argument.  Then we load a reference to <code>printBar</code> into <code>%rsi</code> as our second function argument.  Finally, we call <code>objc_msgSend</code> again.  (It's stub location was already loaded in <code>%r15</code>.)</p>

<h4>Step 6 - Cleaning up our <code>Foo</code></h4>

<p><code>c-objdump
0x100000e2f:  movq   %rbx, %rdi
0x100000e32:  callq  0x100000e5e               ; symbol stub for: objc_release
</code></p>

<p>Since we created an instance of <code>Foo</code>, we have to release it.  Recall that ARC inserts retains and releases for us as needed.  Here's an example of that.  From Step 5, recall that <code>%rbx</code> has a reference to our instance.  The instruction <code>movq   %rbx, %rdi</code> sets it up as a first function argument.  Next we call <code>objc_release</code></p>

<h4>Step 7 - Cleaning up from our function</h4>

<p><code>c-objdump
0x100000e37:  movq   %r14, %rdi
0x100000e3a:  callq  0x100000e4c               ; symbol stub for: objc_autoreleasePoolPop
0x100000e3f:  xorl   %eax, %eax
0x100000e41:  addq   $8, %rsp
0x100000e45:  popq   %rbx
0x100000e46:  popq   %r14
0x100000e48:  popq   %r15
0x100000e4a:  popq   %rbp
0x100000e4b:  ret
</code>
The rest of our function clean-up is that same as in the prior installment of our tutorial series, popping the autorelease pool, restoring the stack and certain preserved registers.</p>

<h3>Conclusion</h3>

<p>In this tutorial, we dived into Objective-C objects and learned about method dispatch optimizations in the Objective-C runtime while getting still more practice in interpreting x86_64 assembly language on the Mac.</p>

<p>Question? Comments?  Tweet Alan <code>@NSBum</code>.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[x86_64 Assembly Language Tutorial: Part 2]]></title>
    <link href="http://cocoa-factory.github.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-2/"/>
    <updated>2012-11-23T05:34:00-06:00</updated>
    <id>http://cocoa-factory.github.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-2</id>
    <content type="html"><![CDATA[<p>In our <a href="http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1/">last installment</a> of our x86_64 assembler tutorial, we introduced the registers and walked through a simple C program and its assembly langugage counterpart.  This time, we'll talk a little more about the effect of optimizations and while we're at it, present some of the highlights of the application binary interface, the ABI.</p>

<p>Let's start with our original code that we <a href="http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1/">presented last time</a>:</p>

<p><div><script src='https://gist.github.com/4135115.js?file='></script>
<noscript><pre><code>#import &lt;Foundation/Foundation.h&gt;

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        uint8_t i;
        for( i = 0; i &lt; 16; i++ ) {
            printf(&quot;i = %d\n&quot;,i);
        }
    }
    return 0;
}</code></pre></noscript></div>
</p>

<h3>Optimization setting - -O, O1</h3>

<p><img class="left" src="http://i.imgur.com/O9LQR.png" title="'Figure 1: Optimization setting'" >
This time, we're going to set the optimizations differently to see what effect it has on the code.  Recall that we ran with no optimizations the first time.  If you want to follow along in Xcode, then just create a command-line application project and search for 'optimization' in the target build settings.</p>

<p><img class="right" src="http://i.imgur.com/NcgDW.png" title="'Figure 2: Disassembly assistant setting'" >
Paste the code above into <code>main.m</code> to replace the code that's autogenerated by the template; and place a breakpoint on the return line.  We won't be able to see the disassembly code unless the application is actually running; so we want to break somewhere accordingly.  We can view either the assembly or disassembly code.  We're going to look at the former because the latter contains a lot of debugging symbols that make it harder to understand what we're really interested in - the instructions.  To show the disassembly results, build and run the project.  When the debugger stops on the return line, show the Assistant editor which splits the main viewer into two panes.  In the right pane, select Disassembly as the assistant pane content.  If you're not with me, then you may want to take a while to get familiar with the Xcode 4.x interface so that you can configure it the way you want.</p>

<h3>Disassembler code</h3>

<p>The disassembler takes the machine code that your C code generated and expresses it symbolically in assembly langugage.  Let's take a look at the results and compare it to the results from the <a href="http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1/">last tutorial</a>.</p>

<p><div><script src='https://gist.github.com/4135317.js?file='></script>
<noscript><pre><code>0x100000ee0:  pushq  %rbp
0x100000ee1:  movq   %rsp, %rbp
0x100000ee4:  pushq  %r15
0x100000ee6:  pushq  %r14
0x100000ee8:  pushq  %rbx
0x100000ee9:  pushq  %rax
0x100000eea:  callq  0x100000f2e               ; symbol stub for: objc_autoreleasePoolPush
0x100000eef:  movq   %rax, %r14
0x100000ef2:  xorl   %ebx, %ebx
0x100000ef4:  leaq   111(%rip), %r15           ; &quot;i = %d\n&quot;
0x100000efb:  nopl   (%rax,%rax)
0x100000f00:  movq   %r15, %rdi
0x100000f03:  movl   %ebx, %esi
0x100000f05:  xorb   %al, %al
0x100000f07:  callq  0x100000f34               ; symbol stub for: printf
0x100000f0c:  incl   %ebx
0x100000f0e:  cmpb   $16, %bl
0x100000f11:  jne    0x100000f00               ; main + 32 at main.m:17
0x100000f13:  movq   %r14, %rdi
0x100000f16:  callq  0x100000f28               ; symbol stub for: objc_autoreleasePoolPop
0x100000f1b:  xorl   %eax, %eax
0x100000f1d:  addq   $8, %rsp
0x100000f21:  popq   %rbx
0x100000f22:  popq   %r14
0x100000f24:  popq   %r15
0x100000f26:  popq   %rbp
0x100000f27:  ret    </code></pre></noscript></div>
</p>

<h3>Step-by-step</h3>

<p>And just like we did before, let's look at the code step-by-step.  This time we're going to compare it to the code with no optimizations from last time, so you may want to be familiar with it first.</p>

<h4>Step 1 - Preamble</h4>

<p><code>c-objdump
0x100000ee0:  pushq  %rbp
0x100000ee1:  movq   %rsp, %rbp
</code></p>

<p>This is the same function preamble as before, saving the current base pointer and moving the stack pointer to the base pointer register.</p>

<h4>Step 2 - Save the registers</h4>

<p><code>c-objdump
0x100000ee4:  pushq  %r15
0x100000ee6:  pushq  %r14
0x100000ee8:  pushq  %rbx
0x100000ee9:  pushq  %rax
</code></p>

<p>We push several 64-bit registers to the stack.  We don't know yet; but probably this is because we're going to use them later on.  Let's see what's next.</p>

<h4>Step 3 - Start the autorelease pool</h4>

<p><code>c-objdump
0x100000eea:  callq  0x100000f2e               ; symbol stub for: objc_autoreleasePoolPush
0x100000eef:  movq   %rax, %r14
</code></p>

<p>Set up the autorelease pool for the function as before.  This time, we're saving the return value - a reference to the autorelease pool, presumably - to <code>%r14</code>.  We'll set it again later before we pop the autorelease pool.  But before we do, it's a good time to present some of the register allocations from the <a href="http://www.x86-64.org/documentation/abi.pdf">x86_64 ABI</a>.  The ABI exists to create some standardization in the way that assembly code interacts with the machine.  Part of that specification are standards that determine which registers are used for a given purpose.  We'll present them here:</p>

<table>
<thead>
<tr>
<th>Register  </th>
<th> Usage                                                           </th>
<th> Preserved across function calls</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>%rax</code>    </td>
<td> 1st return register, number of vector registers used            </td>
<td> No</td>
</tr>
<tr>
<td><code>%rbx</code>    </td>
<td> callee-saved register; base pointer                             </td>
<td> Yes</td>
</tr>
<tr>
<td><code>%rcx</code>    </td>
<td> pass 4th integer argument to functions                          </td>
<td> No</td>
</tr>
<tr>
<td><code>%rdx</code>    </td>
<td> pass 3rd argument fo functions, 2nd return register             </td>
<td> No</td>
</tr>
<tr>
<td><code>%rsp</code>    </td>
<td> stack pointer                                                   </td>
<td> Yes</td>
</tr>
<tr>
<td><code>%rbp</code>    </td>
<td> callee-saved register, frame pointer                            </td>
<td> Yes</td>
</tr>
<tr>
<td><code>%rsi</code>    </td>
<td> used to pass 2nd argument to functions                          </td>
<td> No</td>
</tr>
<tr>
<td><code>%rdi</code>    </td>
<td> used to pass 1st argument to functions                          </td>
<td> No</td>
</tr>
<tr>
<td><code>%r8</code>     </td>
<td> used to pass 5th argunent to functions                          </td>
<td> No</td>
</tr>
<tr>
<td><code>%r9</code>     </td>
<td> used to pass 6th argument to functions                          </td>
<td> No</td>
</tr>
<tr>
<td><code>%r10</code>    </td>
<td> temp register, used for passing a function's static chain ptr   </td>
<td> No</td>
</tr>
<tr>
<td><code>%r11</code>    </td>
<td> temp register                                                   </td>
<td> No</td>
</tr>
<tr>
<td><code>%r12</code>    </td>
<td> callee-saved register                                           </td>
<td> Yes</td>
</tr>
<tr>
<td><code>%r13</code>    </td>
<td> callee-saved register                                           </td>
<td> Yes</td>
</tr>
<tr>
<td><code>%r14</code>    </td>
<td> callee-saved register                                           </td>
<td> Yes</td>
</tr>
<tr>
<td><code>%r15</code>    </td>
<td> callee-saved register                                           </td>
<td> Yes</td>
</tr>
<tr>
<td><code>%xmm0</code>   </td>
<td> used to pass and return floating point arguments                </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm1</code>   </td>
<td> used to pass and return floating point arguments                </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm2</code>   </td>
<td> used to pass floating point arguments                           </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm3</code>   </td>
<td> used to pass floating point arguments                           </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm4</code>   </td>
<td> used to pass floating point arguments                           </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm5</code>   </td>
<td> used to pass floating point arguments                           </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm6</code>   </td>
<td> used to pass floating point arguments                           </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm7</code>   </td>
<td> used to pass floating point arguments                           </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm8</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm9</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm10</code>  </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm11</code>  </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm12</code>  </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm13</code>  </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm14</code>  </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%xmm15</code>  </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%mmx0</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%mmx1</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%mmx2</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%mmx3</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%mmx4</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%mmx5</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%mmx6</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%mmx7</code>   </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%st0</code>    </td>
<td> temporary register, used to return long double arguments        </td>
<td> No</td>
</tr>
<tr>
<td><code>%st1</code>    </td>
<td> temporary register, used to return long double arguments        </td>
<td> No</td>
</tr>
<tr>
<td><code>%st2</code>    </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%st3</code>    </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%st4</code>    </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%st5</code>    </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%st6</code>    </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
<tr>
<td><code>%st7</code>    </td>
<td> temporary register                                              </td>
<td> No</td>
</tr>
</tbody>
</table>


<p>Whew! Got that memorized yet?  Oh well, let's move on.</p>

<h4>Step 4 - Idiom for clearing register</h4>

<p><code>c-objdump
0x100000ef2:  xorl   %ebx, %ebx
</code></p>

<p>This is a curious instruction, XOR long <code>%ebx</code> with itself.  Self-XOR has the effect of clearing the register which on some processors is faster than <code>movl $0, %ebx</code>.  If we're setting something to zero, I wonder if the compiler is using <code>%ebx</code> as the loop index.  We shall see...</p>

<h4>Step 5 - Obtain format string address</h4>

<p><code>c-objdump
0x100000ef4:  leaq   111(%rip), %r15           ; "i = %d\n"
</code></p>

<p>This instruction reads "load effective address 64-bit into <code>%15</code>".  We're just grabbing the format string from a particular location in memory relative to the instruction pointer.</p>

<h4>Step 6 - Alignment</h4>

<p><code>c-objdump
0x100000efb:  nopl   (%rax,%rax)
</code></p>

<p>This is an optimization that does nothing other than align the code properly for the jump target so that it can be fetched in a single cacheline request.</p>

<h4>Step 7 - Setting up call to <code>printf</code></h4>

<p><code>c-objdump
0x100000f00:  movq   %r15, %rdi
0x100000f03:  movl   %ebx, %esi
0x100000f05:  xorb   %al, %al
0x100000f07:  callq  0x100000f34               ; symbol stub for: printf
</code></p>

<p>Remember from the ABI register usage table above that <code>%rdi</code> is used to pass the first argument to functions.  In this case, the format string is the first argument of <code>printf</code>.  Earlier in Step 5, we loaded the address of the string into <code>%r15</code>; now we're moving it to <code>%rdi</code> in preparation for the <code>printf</code> function call.  Next, <code>movl   %ebx, %esi</code> - remember earlier we wondered if the compiler was using <code>%esi</code> as the loop index?  From the reference table above, <code>%rsi</code> is used to pass the second function parameter; so this instruction passes the second parameter which is the loop index <code>i</code> in the C code.</p>

<p><code>xorb   %al, %al</code> clears the <code>%al</code> register which is the lowest 8 bits of <code>%rax</code> which is the register that passes the number of vector arguments.  As in the prior tutorial, since we are printing an integer, we don't need a vector register.  Hence, we clear <code>%al</code>.</p>

<h4>Step 8 - Increment, compare, and jump</h4>

<p><code>c-objdump
0x100000f0c:  incl   %ebx
0x100000f0e:  cmpb   $16, %bl
0x100000f11:  jne    0x100000f00               ; main + 32 at main.m:17
</code></p>

<p>In order, we increment the register we're using for the loop index, compare its lower 8 bits to decimal 16 with a byte compare instruction and jump if not equal back to Step 7.</p>

<h4>Step 9 - Pop the autorelease pool</h4>

<p><code>c-objdump
0x100000f13:  movq   %r14, %rdi
0x100000f16:  callq  0x100000f28               ; symbol stub for: objc_autoreleasePoolPop
</code></p>

<p>Recall that in Step 3 we saved a reference to the autorelease pool in <code>%r14</code>?  Now we move that reference back to <code>%rdi</code> which is used to pass the first argument to functions. (Is this sounding like a broken record now?)  Then we call objc_autoreleasePoolPop in the Objective-C runtime to release the autorelease pool.</p>

<h4>Step 10 - Setting up to return</h4>

<p><code> c-objdump
0x100000f1b:  xorl   %eax, %eax
0x100000f1d:  addq   $8, %rsp
0x100000f21:  popq   %rbx
0x100000f22:  popq   %r14
0x100000f24:  popq   %r15
0x100000f26:  popq   %rbp
0x100000f27:  ret  
</code></p>

<p>Now all that's left is just to clean up.  First we clear <code>%eax</code>.  Why now?  Since it's the lower 32 bits of the first return register, we just clear it after returning from the last function call so that we can return 0 to <strong>our</strong> caller.</p>

<p>Next we add 8 to the stack pointer.  This is an interesting development.  Why do we manually adjust the stack pointer?  Take a look at the function setup.  Initially we pushed the following registers: <code>%rbp</code>, <code>%r15</code>, <code>%r14</code>, <code>%rbx</code> and <code>%rax</code>.  But if we pop <code>%rax</code> which is our 1st function return value register, then we risk blowing away the effects of clearing <code>%eax</code> that we just did in <code>0x100000f1b:  xorl   %eax, %eax</code>, right?  So instead of popping the value, we manually adjust the stack pointer before popping the other variables in the reverse order to that in which we pushed them to the stack.</p>

<p>Lastly, we return to the caller.</p>

<p>Again, we close another chapter in our x86_64 assembly tutorial for Mac.  We will continue to build on our knowledge base with slightly more complex tutorials as we progress; so stay tuned.  Here are some interesting and useful references for you:</p>

<ul>
<li><a href="http://www.x86-64.org/documentation/abi.pdf">x86_64 ABI reference</a></li>
<li><a href="http://www.cs.virginia.edu/~evans/cs216/guides/x86.html">x86 assembly guide</a></li>
<li><a href="http://cs.mtu.edu/~mmkoksal/blog/?x=entry:entry120116-130037">GNU assembler directives</a></li>
<li><a href="http://stackoverflow.com/questions/2647640/x86-assembly-idioms">x86 assembly idioms</a></li>
</ul>


<p>And of course, <a href="http://cocoafactory.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1/">Part I</a> or our tutorial.</p>

<p>Question? Comments?  Tweet Alan <code>@NSBum</code>.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[x86_64 Assembly Language Tutorial: Part 1]]></title>
    <link href="http://cocoa-factory.github.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1/"/>
    <updated>2012-11-23T04:21:00-06:00</updated>
    <id>http://cocoa-factory.github.com/blog/2012/11/23/x86-64-assembly-language-tutorial-part-1</id>
    <content type="html"><![CDATA[<p>The majority of the time, Cocoa developers work at a such a high level of abstraction that we almost forget that all of those abstractions ultimately interact with silicon at the level of machine language.  Few of us will ever need to write such performance-critical code that we need to hand-write assembly language code; but a rudimentary understanding of it will help developers understand how the compiler behaves and how our objects that live in the upper levels of abstraction actually work.  If for no other reason, a passing familiarity with x86_64 assembly language will comfort the developer a little when the debugger stops on some line of assembly code.  With that, let's dive in.</p>

<p>Registers are the "variables" at a hardware level.  In the x86_64 architecture, the registers are 64 bits wide, of course; but they have 32, 16, and 8 bit sub-registers that are used for particular instructions.  The following table shows some of those relationships:</p>

<table>
<thead>
<tr>
<th>64-bit register </th>
<th> Lower 32 bits </th>
<th> Lower 16 bits </th>
<th> Lower 8 bits</th>
</tr>
</thead>
<tbody>
<tr>
<td>rax        </td>
<td> eax           </td>
<td> ax            </td>
<td> al</td>
</tr>
<tr>
<td>rbx             </td>
<td> ebx           </td>
<td> bx            </td>
<td> bl</td>
</tr>
<tr>
<td>rcx             </td>
<td> ecx           </td>
<td> cx            </td>
<td> cl</td>
</tr>
<tr>
<td>rdx             </td>
<td> edx           </td>
<td> dx            </td>
<td> dl</td>
</tr>
<tr>
<td>rsi             </td>
<td> esi           </td>
<td> si            </td>
<td> sil</td>
</tr>
<tr>
<td>rdi             </td>
<td> edi           </td>
<td> di            </td>
<td> dil</td>
</tr>
<tr>
<td>rbp             </td>
<td> ebp           </td>
<td> bp            </td>
<td> bpi</td>
</tr>
<tr>
<td>rsp             </td>
<td> esp           </td>
<td> sp            </td>
<td> spi</td>
</tr>
<tr>
<td>r8              </td>
<td> r8d           </td>
<td> r8w           </td>
<td> r8b</td>
</tr>
</tbody>
</table>


<p>(<code>r8</code>-<code>r15</code> follow the same convention.)  The <code>rip</code> register is the instruction pointer register which points to the instruction being executed.  As we go through this series, we'll introduce more information about the x86_64 registers.  Before we move on, it's important to note that although there are dozens of registers that the compiler can use, their use is restricted by several factors:</p>

<ol>
<li><strong>Width of register</strong> - an 8 bit register can't hold a 64-bit value.  (Duh.)</li>
<li><strong>Instructions</strong> - instructions operate on certain types of registers.</li>
<li><strong>Application binary interface</strong> - this is the low-level equivalent of an API, specifying data types, widths, calling conventions, etc.</li>
</ol>


<p>Our example is a simple C program that prints the first 16 integers:</p>

<h3>C code</h3>

<p><div><script src='https://gist.github.com/4135115.js?file='></script>
<noscript><pre><code>#import &lt;Foundation/Foundation.h&gt;

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        uint8_t i;
        for( i = 0; i &lt; 16; i++ ) {
            printf(&quot;i = %d\n&quot;,i);
        }
    }
    return 0;
}</code></pre></noscript></div>
</p>

<p>We've compiled this using no optimizations to see how the compiler behaves when it can't optimize.  In the next installment, we'll take a look at the effect of optimizations on the compiled code.</p>

<h3>Disassembly</h3>

<p><div><script src='https://gist.github.com/4134960.js?file='></script>
<noscript><pre><code>0x100000eeb:  pushq  %rbp
0x100000eec:  movq   %rsp, %rbp
0x100000eef:  pushq  %r15
0x100000ef1:  pushq  %r14
0x100000ef3:  pushq  %rbx
0x100000ef4:  pushq  %rax
0x100000ef5:  callq  0x100000f34               ; symbol stub for: objc_autoreleasePoolPush
0x100000efa:  movq   %rax, %r14
0x100000efd:  xorl   %ebx, %ebx
0x100000eff:  leaq   104(%rip), %r15           ; &quot;i = %d\n&quot;
0x100000f06:  movq   %r15, %rdi
0x100000f09:  movl   %ebx, %esi
0x100000f0b:  xorb   %al, %al
0x100000f0d:  callq  0x100000f3a               ; symbol stub for: printf
0x100000f12:  incl   %ebx
0x100000f14:  cmpb   $16, %bl
0x100000f17:  jne    0x100000f06               ; main + 27 at main.m:17
0x100000f19:  movq   %r14, %rdi
0x100000f1c:  callq  0x100000f2e               ; symbol stub for: objc_autoreleasePoolPop
0x100000f21:  xorl   %eax, %eax
0x100000f23:  addq   $8, %rsp
0x100000f27:  popq   %rbx
0x100000f28:  popq   %r14
0x100000f2a:  popq   %r15
0x100000f2c:  popq   %rbp
0x100000f2d:  ret  </code></pre></noscript></div>
</p>

<h3>Step-by-step</h3>

<h4>Step 1</h4>

<p><code>c-objdump
0x100000ec0:  pushq  %rbp
0x100000ec1:  movq   %rsp, %rbp
</code></p>

<p>This is a standard preamble for a C function.  <code>pushq %rbp</code> saves the base pointer to the stack so that it can be restored later (see <code>popq %rbp</code>…)  Then <code>movq %rsp, %rbp</code> copies <code>rsp</code> to <code>rbp</code> setting the base pointer (temporarily for our function) to the stack pointer.  That way we can push variables to the stack if our function requires it.</p>

<h4>Step 2</h4>

<p><code>c-objdump
0x100000ec4:  subq   $48, %rsp
</code></p>

<p>Grow our stack 48 bytes upward.  The compiler evidently concluded that our function may need 48 bytes of stack space for its use.</p>

<h4>Step 3</h4>

<p><code>c-objdump
0x100000ec8:  movl   $0, -4(%rbp)
</code></p>

<p>Store a 32-bit zero at the bottom of the stack.  As the stack grows, we use lower-numbered addresses in memory.  Here, the bottom four bytes of the stack are set to zero.  Presumably this is just to make sure we've cleared the stack that we are using.</p>

<h4>Step 4</h4>

<p><code>c-objdump
0x100000ecf:  movl   %edi, -8(%rbp)
</code></p>

<p>Since <code>edi</code> is the first integer argument register - and the lower 32 bits of <code>rdi</code> we are pushing this to the stack 8 bytes up.  Since we set the bottom 4 bytes to zero, we are ensuring that the 64 bit value now on the stack is just the value of <code>argc</code> from the C code.  Makes sense?</p>

<h4>Step 5</h4>

<p><code>c-objdump
0x100000ed2:  movq   %rsi, -16(%rbp)
</code></p>

<p>Now we're saving <code>rsi</code> another 8 bytes up the stack.</p>

<h4>Step 6</h4>

<p><code>c-objdump
0x100000ed6:  callq  0x100000f2e
</code></p>

<p>Like the comment says, we're calling the start of the autorelease pool.  Remember, we're looking at the disassembly.  If we were looking at the assembly instead, we'd see something like this:  <code>callq _objc_autoreleasePoolPush</code></p>

<h4>Step 7</h4>

<p><code>c-objdump
0x100000edb:  movb   $0, -17(%rbp)
</code></p>

<p>What's going on here?  We're pushing a an 8-bit zero to a position 17 bytes up the stack.  I'll bet this refers to initializing our <code>uint8_t</code> loop variable <code>i</code> to zero.  We'll see in a minute.</p>

<h4>Step 8</h4>

<p><code>c-objdump
0x100000edf:  movq   %rax, -32(%rbp)
</code></p>

<p>Now we're moving the accumulator register <code>rax</code> to the stack.</p>

<h4>Step 9</h4>

<p><code>c-objdump
0x100000ee3:  movzbl -17(%rbp), %eax
</code></p>

<p>Here's an instruction that we haven't seen yet: <code>movzbl</code>.  This instruction means "move byte to long" so we are moving a byte at <code>-17(%rbp)</code> (remember that was hypothesized to be our loop variable…) to the register <code>%eax</code> which, you will recall, is the lower 32 bits of <code>%rax</code>.  Since we're moving it back off the stack, I wonder if we're getting ready to compare it to our maximum loop index?</p>

<h4>Step 10</h4>

<p><code>c-objdump
0x100000ee7:  cmpl   $16, %eax
</code></p>

<p>Yep!  <code>cmpl</code> means "compare long", so we are comparing decimal 16 to <code>%eax</code> the lower 32 bits of the accumulator - the place where we just pulled our byte-to-long off the stack.  Now we'd expect to see some conditional jump next, I think.</p>

<h4>Step 11</h4>

<p><code>c-objdump
0x100000eec:  jge    0x100000f14               ; main + 84 at main.m:19
</code></p>

<p>And right again!</p>

<p>The <code>jge</code> instruction is "jump when greater than or equal to"; so if <code>%eax</code> is greater than or equal to 16, we'll jump to <code>0x100000f14</code> which, if you look ahead pops our autorelease pool and restores the stack, etc. thereby finishing the function.</p>

<h4>Step 12</h4>

<p><code>c-objdump
0x100000ef2:  leaq   113(%rip), %rdi           ; "i = %d\n"
</code></p>

<p>If we reach this point, our comparison failed and the integer is under 16.  So all that was left to do in the C code is to print it.  In this case, we're loading an address 113 decimal bytes ahead of our current instruction pointer into <code>%rdi</code>.  Without seeing what's beyond the end of the function in memory and without the comment, we'd be lost.  But the disassembler gives us a comment that tells us that this points to the format string that we'll use to print the integer value.  But why did the compiler chosse <code>%rdi</code> for the this argument?  The answer is buried in the <a href="http://www.x86-64.org/documentation/abi.pdf">x86_64 ABI</a> in the section 3.2.3. which states that register <code>%rdi</code> is used to pass the first argument to functions.</p>

<h4>Step 13</h4>

<p><code>c-objdump
0x100000ef9:  movzbl -17(%rbp), %esi
</code></p>

<p>Again, our "move byte to long" instruction.  This time moving the integer value to <code>%esi</code>.  I bet that's what <code>printf</code> is expecting as the integer argument.  Referring again to the <a href="http://www.x86-64.org/documentation/abi.pdf">x86_64 ABI</a>, <code>%rsi</code> is used to pass the second argument to functions.  Since <code>%esi</code> is the lower 32 bits of <code>%rsi</code>, this makes sense.</p>

<h4>Step 14</h4>

<p><code>c-objdump
0x100000efd:  movb   $0, %al
</code></p>

<p>This is the tricky bit to understand without references to the ABI.  <code>%rax</code> is used to pass information about the number of vector registers that are used.  It is also the 1st return register.  Register <code>%al</code> is the lower 8 bits of <code>%rax</code> so in this instruction we are setting the number of vector registers to zero.  Since we are simply printing an integer, no need for vector registers.</p>

<h4>Step 15</h4>

<p><code>c-objdump
0x100000eff:  callq  0x100000f34               ; symbol stub for: printf
</code></p>

<p>Now we find the call to <code>printf</code> after the setup.  In assembly, this would have been <code>callq _printf</code>.</p>

<h4>Step 16</h4>

<p><code>c-objdump
0x100000f04:  movl   %eax, -36(%rbp)
</code></p>

<p>This action (which is not really necessary) is a "Spill"; if we look at the assembly it labels it as such:</p>

<p><code>c-objdump
movl    %eax, -36(%rbp)         ## 4-byte Spill
</code></p>

<p>When optimizations are off, the compiler looks ahead and sees that we need <code>%eax</code> or one of its sub-registers and pushes it to the stack.  That is a Spill.</p>

<h4>Step 17</h4>

<p><code>c-objdump
0x100000f07:  movb   -17(%rbp), %al
</code></p>

<p>Now we get the integer loop value at <code>-17(%rbp)</code> off the stack into <code>%al</code>.  The upcoming use of <code>%al</code> is the reason that the compiler spilled the 4 bytes of <code>%eax</code> in the last instruction.</p>

<h4>Step 18</h4>

<p><code>c-objdump
0x100000f0a:  addb   $1, %al
0x100000f0c:  movb   %al, -17(%rbp)
</code></p>

<p>Now, as expected, the increment and move back to the stack.</p>

<h4>Step 19</h4>

<p><code>c-objdump
0x100000f0f:  jmpq   0x100000ee3               ; main + 35 at main.m:16
</code></p>

<p>Finally, the end of our loop.  Jump back to address <code>0x100000ee3</code> which is step 9 above and the setup for our loop index comparison.</p>

<h4>Step 20</h4>

<p><code>c-objdump
0x100000f14:  movq   -32(%rbp), %rdi
</code></p>

<p>Now we get <code>%rdi</code> off the stack; this is the opposite of a Spill - a Reload.</p>

<h4>Step 21</h4>

<p><code>c-objdump
0x100000f18:  callq  0x100000f28               ; symbol stub for: objc_autoreleasePoolPop
</code></p>

<p>Pop our Objective-C autorelease pool.</p>

<h4>Step 22</h4>

<p><code>c-objdump
0x100000f1d:  movl   $0, %eax
</code></p>

<p>Remember that <code>%rax</code> is our first return register; so this instruction is simply setting our return to 0.</p>

<h4>Step 23</h4>

<p><code>c-objdump
0x100000f22:  addq   $48, %rsp
0x100000f26:  popq   %rbp
0x100000f27:  ret
</code></p>

<p>Restore the stack pointer and the base pointer. And return.</p>

<p>With that, our first installment on x86_64 comes to a close.  We hope this was a helpful first introduction to x86_64 assembly language and that you will find it useful in understanding and debugging your applications.</p>

<p>Question? Comments?  Tweet Alan <code>@NSBum</code>.</p>
]]></content>
  </entry>
  
</feed>