So consider the following method:

void foo() {
    @autoreleasepool {
        NSNumber *number = [NSNumber numberWithInt:0];
        NSLog(@"number = %p", number);
    }
}

This is entirely contrived, of course, but it should let us see what’s going on. In non-ARC land we would assume here that number would be allocated inside numberWithInt: and returned autoreleased. So when the autorelease pool is next drained, it will be released. So let’s see if that’s what happened (as usual, this is ARMv7 instructions):

        .globl  _foo
        .align  2
        .code   16
        .thumb_func     _foo
_foo:
        push    {r4, r7, lr}
        add     r7, sp, #4
        blx     _objc_autoreleasePoolPush
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_0+4))
        movs    r2, #0
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_0+4))
        mov     r4, r0
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC0_1+4))
LPC0_0:
        add     r1, pc
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC0_1+4))
LPC0_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        mov     r1, r0
        movw    r0, :lower16:(L__unnamed_cfstring_-(LPC0_2+4))
        movt    r0, :upper16:(L__unnamed_cfstring_-(LPC0_2+4))
LPC0_2:
        add     r0, pc
        blx     _NSLog
        mov     r0, r4
        blx     _objc_autoreleasePoolPop
        pop     {r4, r7, pc}

Well, yes. That’s exactly what’s happening. We can see the call to push an autorelease pool then a call to numberWithInt: then a call to pop an autorelease pool. Exactly what we’d expect. Now let’s look at the exact same code compiled under ARC:

        .globl  _foo
        .align  2
        .code   16
        .thumb_func     _foo
_foo:
        push    {r4, r5, r7, lr}
        add     r7, sp, #8
        blx     _objc_autoreleasePoolPush
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_0+4))
        movs    r2, #0
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_0+4))
        mov     r4, r0
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC0_1+4))
LPC0_0:
        add     r1, pc
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC0_1+4))
LPC0_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        @ InlineAsm Start
        mov     r7, r7          @ marker for objc_retainAutoreleaseReturnValue
        @ InlineAsm End
        blx     _objc_retainAutoreleasedReturnValue
        mov     r5, r0
        movw    r0, :lower16:(L__unnamed_cfstring_-(LPC0_2+4))
        movt    r0, :upper16:(L__unnamed_cfstring_-(LPC0_2+4))
        mov     r1, r5
LPC0_2:
        add     r0, pc
        blx     _NSLog
        mov     r0, r5
        blx     _objc_release
        mov     r0, r4
        blx     _objc_autoreleasePoolPop
        pop     {r4, r5, r7, pc}

Notice the calls to objc_retainAutoreleasedReturnValue and objc_release. What’s happening there is that ARC has determined for us that it doesn’t really need to worry about the autorelease pool that’s in place, because it can simply tell the autorelease to not happen (with the call to objc_retainAutoreleasedReturnValue) and then release the object later itself. This is desirable as it means the autorelease logic doesn’t have to happen.

Note that the autorelease pool is still required to be pushed and popped because ARC can’t know what’s going on in the calls to numberWithInt: and NSLog to know if objects will be put into the pool there. If it did know that they didn’t autorelease anything then it could actually get rid of the push and pop. Perhaps that kind of logic will come in future versions although I’m not quite sure how the semantics of that would work though.

Now let’s consider another example which is where we want to use number outside of the scope of the autorelease pool block. This should show us why ARC is a wonder to work with. Consider the following code:

void bar() {
    NSNumber *number;
    @autoreleasepool {
        number = [NSNumber numberWithInt:0];
        NSLog(@"number = %p", number);
    }
    NSLog(@"number = %p", number);
}

You might be (correctly) thinking that this is going to cause problems even though it looks perfectly innocuous. It’s a problem because number will be allocated inside the autorelease pool block, will be deallocated when the autorelease pool pops but is then used after it’s been deallocated. Uh oh! Let’s see if we’re right by compiling it without ARC enabled:

        .globl  _bar
        .align  2
        .code   16
        .thumb_func     _bar
_bar:
        push    {r4, r5, r6, r7, lr}
        add     r7, sp, #12
        blx     _objc_autoreleasePoolPush
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
        movs    r2, #0
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
        mov     r4, r0
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC1_1+4))
LPC1_0:
        add     r1, pc
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC1_1+4))
LPC1_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r6, :lower16:(L__unnamed_cfstring_-(LPC1_2+4))
        movt    r6, :upper16:(L__unnamed_cfstring_-(LPC1_2+4))
LPC1_2:
        add     r6, pc
        mov     r5, r0
        mov     r1, r5
        mov     r0, r6
        blx     _NSLog
        mov     r0, r4
        blx     _objc_autoreleasePoolPop
        mov     r0, r6
        mov     r1, r5
        blx     _NSLog
        pop     {r4, r5, r6, r7, pc}

Obviously no calls to retain, release or autorelease as we’d expect since we haven’t made any explicitly and we’re not using ARC. We can see here that it’s been compiled exactly as we’d expect from our reasoning before. So let’s see what it looks like when ARC gives us a helping hand:

        .globl  _bar
        .align  2
        .code   16
        .thumb_func     _bar
_bar:
        push    {r4, r5, r6, r7, lr}
        add     r7, sp, #12
        blx     _objc_autoreleasePoolPush
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
        movs    r2, #0
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
        mov     r4, r0
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC1_1+4))
LPC1_0:
        add     r1, pc
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC1_1+4))
LPC1_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        @ InlineAsm Start
        mov     r7, r7          @ marker for objc_retainAutoreleaseReturnValue
        @ InlineAsm End
        blx     _objc_retainAutoreleasedReturnValue
        movw    r6, :lower16:(L__unnamed_cfstring_-(LPC1_2+4))
        movt    r6, :upper16:(L__unnamed_cfstring_-(LPC1_2+4))
LPC1_2:
        add     r6, pc
        mov     r5, r0
        mov     r1, r5
        mov     r0, r6
        blx     _NSLog
        mov     r0, r4
        blx     _objc_autoreleasePoolPop
        mov     r0, r6
        mov     r1, r5
        blx     _NSLog
        mov     r0, r5
        blx     _objc_release
        pop     {r4, r5, r6, r7, pc}

Round of applause for ARC please! Notice that it’s realised we’re using number outside of the scope of the autorelease pool block so it’s retained the return value from numberWithInt: just as it did before, but this time it’s placed the release at the end of the bar function rather than before the autorelease pool is popped. That will have saved us a crash in some code that we might have thought was correct but actually had a subtle memory management bug.

Download All

In order to visualise it I decided to create a card with an ‘F’ on the front and then trace through the ‘F’ onto the back to that effectively it is mirrored. The purpose of the mirror is to enable me to visualise the case when dealing with images that are mirrored (i.e. UIImageOrientationUpMirrored, UIImageOrientationDownMirrored, etc). Here is an example of my card:

Now we can get to work using that to work out how we might want to translate & rotate a context whilst drawing into. Consider first of all an image that is in the UIImageOrientationDown orientation. So hold your card with the ‘F’ on it with the front facing you and rotate it through 180 degrees. That is the orientation we want to determine the correct transformation matrix for in this case. Now since Quartz draws with the origin in the bottom right, you need to imagine a coordinate system where the y-axis is going up from the bottom to the top of your card and the x-axis is going across from the left to the right. I like to imagine little arrows going up & left from the bottom left corner of my card.

So to get this to draw into our canvas correctly it’s pretty clear that we need to rotate by 180 degrees. A rotation will rotate about the origin of our coordinate system so if we purely rotate by 180 degrees then the image will be drawn the right way up but will lie down and left from the origin. To see why this is, hold your card with your fingers at the bottom left. Now imagine the canvas going up and right from here, the size of the card. Now push the card round from the top right corner by 180 degrees, pivoting about the bottom left. You can see that nothing would be drawn into the canvas! So what we need to do is translate up by the height and right by the width. That then brings the image into the right place in the canvas.

I like to draw out this like so on paper:

I think this helps explain it because if at all times you keep your little coordinate arrows on your card lined up with the ones in the diagram, you can visualise what’s going on.

Now let’s consider a much more complicated example, the case of UIImageOrientationLeftMirrored. Start with your card on its front and on its side with the long side of the ‘F’ at the bottom. Then flip it over. This is now in the desired orientation.

It’s hard to work out from here what needs to be done but if you follow through the diagram below and at all times keeping your little coordinate arrows on your card aligned with the arrows on the diagram then you should be able to convince yourself that it’s right.

So to follow this you would hold your card with the ‘F’ in the position described above with its bottom left aligned with the bottom left of the canvas ’1′ on the diagram. Then to get to position 2 you would move the card horizontally across the width of the canvas where your little arrows should line up with the arrows in the diagram on canvas ’2′. To get to position 3 you would rotate 90 degrees counter-clockwise (i.e. positive rotation – which is rotating from the positive x-axis towards the positive y-axis). Then to get to position 4 you need to move the card vertically, which is a translation in positive x if you look at it carefully. Then finally to get to position 5 you need to flip the card along the y-axis which brings the image into the canvas fully and you’ll notice the ‘F’ is the right way up!

Note that if we want to then draw the image we would need to define the rectangle to draw into with a width equal to the canvas height and a height equal to the canvas width because our x axis is now vertical and our y axis is horizontal. Alternatively think of it that the height of the image is the width of the canvas and the width of the image is the height of the canvas.

I used this method to work out how to draw a UIImage rotated correctly to its upright position. Here is that code:

UIImage *image = <THE_IMAGE>;
CGSize imageSize = image.size;

CGRect imageRect = CGRectIntegral(CGRectMake(0.0f, 0.0f, imageSize.width, imageSize.height));
CGRect imageTransposedRect = CGRectMake(0.0f, 0.0f, imageSize.height, imageSize.width);

CGAffineTransform transform = CGAffineTransformIdentity;
CGRect drawRect = imageRect;

switch (image.imageOrientation) {
    case UIImageOrientationUp:
        break;
    case UIImageOrientationUpMirrored:
        transform = CGAffineTransformTranslate(transform, rect.size.width, 0.0f);
        transform = CGAffineTransformScale(transform, -1.0f, 1.0f);
        break;
    case UIImageOrientationDown:
        transform = CGAffineTransformTranslate(transform, rect.size.width, rect.size.height);
        transform = CGAffineTransformRotate(transform, M_PI);
        break;
    case UIImageOrientationDownMirrored:
        transform = CGAffineTransformTranslate(transform, 0.0f, rect.size.height);
        transform = CGAffineTransformScale(transform, 1.0f, -1.0f);
        break;
    case UIImageOrientationLeft:
        transform = CGAffineTransformTranslate(transform, rect.size.width, 0.0f);
        transform = CGAffineTransformRotate(transform, M_PI_2);
        drawRect = imageTransposedRect;
        break;
    case UIImageOrientationLeftMirrored:
        transform = CGAffineTransformTranslate(transform, rect.size.width, 0.0f);
        transform = CGAffineTransformRotate(transform, M_PI_2);
        transform = CGAffineTransformTranslate(transform, rect.size.height, 0.0f);
        transform = CGAffineTransformScale(transform, -1.0f, 1.0f);
        drawRect = imageTransposedRect;
        break;
    case UIImageOrientationRight:
        transform = CGAffineTransformTranslate(transform, 0.0f, rect.size.height);
        transform = CGAffineTransformRotate(transform, -M_PI_2);
        drawRect = imageTransposedRect;
        break;
    case UIImageOrientationRightMirrored:
        transform = CGAffineTransformScale(transform, -1.0f, 1.0f);
        transform = CGAffineTransformRotate(transform, M_PI_2);
        drawRect = imageTransposedRect;
        break;
}

CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
CGContextRef bitmap = CGBitmapContextCreate(NULL,
                                            drawRect.size.width,
                                            drawRect.size.height,
                                            8,
                                            0,
                                            colorSpace,
                                            kCGImageAlphaPremultipliedLast);

CGContextConcatCTM(bitmap, transform);
CGContextDrawImage(bitmap, drawRect, image);

CGImageRef newImageRef = CGBitmapContextCreateImage(bitmap);
UIImage *newImage = [UIImage imageWithCGImage:newImageRef];

CGContextRelease(bitmap);
CGImageRelease(newImageRef);
CGColorSpaceRelease(colorSpace);

Consider this class:

#import <Foundation/Foundation.h>

@interface ClassA : NSObject

@property (nonatomic, strong) NSMutableArray *array;

@end

@implementation ClassA

@synthesize array;

- (id)popObject {
    id lastObject = [array lastObject];
    if (lastObject) {
        [array removeLastObject];
    }
    return lastObject;
}

@end

In non-ARC land, the call to removeLastObject would release the object that was in the array and then if that was the last reference to it, it would dealloc the object meaning that we return a dead object. So we would retain lastObject and then return it with an autorelease.

But this scared me not doing this, even though I knew full well that ARC should be doing its job. I think I thought this because naively I thought that ARC would parse the method line by line. If it did then I thought it might not necessarily add in a retain because when we get a reference to the last object, ARC doesn’t know it needs to add a retain because well, why would it necessarily have to?

That’s where I was wrong. Obviously what ARC does is it will add in a retain once we get a reference to that object and then when that variable goes out of scope it adds a release or in our case, because we are returning it and the method name does not start with new or copy, it autoreleases it.

Let’s see what that code compiled to:

        .thumb_func     "-[ClassA popObject]"
"-[ClassA popObject]":
        push    {r4, r5, r6, r7, lr}
        movw    r6, :lower16:(_OBJC_IVAR_$_ClassA.array-(LPC0_0+4))
        mov     r4, r0
        movt    r6, :upper16:(_OBJC_IVAR_$_ClassA.array-(LPC0_0+4))
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_1+4))
LPC0_0:
        add     r6, pc
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_1+4))
LPC0_1:
        add     r1, pc
        add     r7, sp, #12
        ldr     r0, [r6]
        ldr     r1, [r1]
        ldr     r0, [r4, r0]
        blx     _objc_msgSend
        @ InlineAsm Start
        mov     r7, r7          @ marker for objc_retainAutoreleaseReturnValue
        @ InlineAsm End
        blx     _objc_retainAutoreleasedReturnValue
        mov     r5, r0
        cbz     r5, LBB0_2
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC0_2+4))
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC0_2+4))
        ldr     r0, [r6]
LPC0_2:
        add     r1, pc
        ldr     r1, [r1]
        ldr     r0, [r4, r0]
        blx     _objc_msgSend
LBB0_2:
        mov     r0, r5
        blx     _objc_autoreleaseReturnValue
        pop     {r4, r5, r6, r7, pc}

Well, there we go. ARC has done a fine job for us. What it’s actually done is added a call to objc_retainAutoreleaseReturnValue which means it has noticed it needs to retain a value that was returned autoreleased which must be an ARC optimisation that will just pull the object once from the autorelease pool rather than actually performing a retain. Then at the end of the method it calls objc_autoreleaseReturnValue which must do the work of autoreleasing the value we’re returning.

This is just another example of how to look at what ARC is doing under the hood. The more I use ARC, the more I realise how useful it is. It makes code less prone to memory management errors and allows for optimisations such as the one shown here of retaining an autoreleased return value.

We shall start by defining a class like so:

#import <Foundation/Foundation.h>

@interface ClassA : NSObject 

@property (nonatomic, retain) NSNumber *foo;

@end

@implementation ClassA

@synthesize foo;

- (void)changeFooDirect:(NSNumber*)inFoo {
    foo = inFoo;
}

- (void)changeFooSetter:(NSNumber*)inFoo {
    self.foo = inFoo;
}

- (NSNumber*)newNumber {
    return [[NSNumber alloc] initWithInt:10];
}

- (NSNumber*)getNumber {
    return [[NSNumber alloc] initWithInt:10];
}

@end

This outlines a few important aspects of ARC including direct access to ivars versus using a setter and how ARC will add autorelease calls when returning an object from a method based on the name of the method.

Let’s first look at the direct access to ivars versus using a setter. If we compile that code and look at the assembly then we’ll get an insight into what’s going on. I decided to use ARMv7 because it’s easier to understand what’s going on than x86 (in my opinion anyway!). We can turn ARC on and off with the -fobjc-arc and -fno-objc-arc compiler options. In these examples I’ve used optimisation level 3 which will mean the compiler will also remove redundant code which we’re not really interested in and would clog up the understanding (an exercise for the reader is to try without any optimisations and see what it looks like).

So to compile without ARC I used the following command:

$ /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk -arch armv7 -fno-objc-arc -O3 -S -o - test-arc.m

So, let’s look at changeFooDirect: and changeFooSetter::

        .align  2
        .code   16
        .thumb_func     "-[ClassA changeFooDirect:]"
"-[ClassA changeFooDirect:]":
        movw    r1, :lower16:(_OBJC_IVAR_$_ClassA.foo-(LPC0_0+4))
        movt    r1, :upper16:(_OBJC_IVAR_$_ClassA.foo-(LPC0_0+4))
LPC0_0:
        add     r1, pc
        ldr     r1, [r1]
        str     r2, [r0, r1]
        bx      lr

        .align  2
        .code   16
        .thumb_func     "-[ClassA changeFooSetter:]"
"-[ClassA changeFooSetter:]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
LPC1_0:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

And following straight on, let’s look at what it looks like with ARC enabled. To do this I used the following command:

$ /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk -arch armv7 -fobjc-arc -O3 -S -o - test-arc.m

Again, we’re interested at the moment in changeFooDirect: and changeFooSetter::

        .align  2
        .code   16
        .thumb_func     "-[ClassA changeFooDirect:]"
"-[ClassA changeFooDirect:]":
        push    {r7, lr}
        movw    r1, :lower16:(_OBJC_IVAR_$_ClassA.foo-(LPC0_0+4))
        mov     r7, sp
        movt    r1, :upper16:(_OBJC_IVAR_$_ClassA.foo-(LPC0_0+4))
LPC0_0:
        add     r1, pc
        ldr     r1, [r1]
        add     r0, r1
        mov     r1, r2
        blx     _objc_storeStrong
        pop     {r7, pc}

        .align  2
        .code   16
        .thumb_func     "-[ClassA changeFooSetter:]"
"-[ClassA changeFooSetter:]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC1_0+4))
LPC1_0:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

We can instantly see the difference here. The changeFooSetter: is exactly the same whereas changeFooDirect: has changed with a single call to objc_storeStrong. That’s the interesting bit. If we looks at the LLVM documentation for this then we see that it’s doing a standard swap of the variable by releasing the old value and retain the new value. Whereas in the non-ARC version the ivar is just swapped without any retain or release. That’s just what we’d expect! Thanks ARC!

Now for the more interesting bit, the newNumber versus getNumber. Those methods in non-ARC land are both returning NSNumber objects which have a retain count of 1, i.e. the caller owns them. That sounds right for newNumber but not for getNumber according to Cocoa’s naming conventions. We’d expect to see an autorelease call when returning from getNumber. So let’s see what the code looks like without ARC:

        .align  2
        .code   16
        .thumb_func     "-[ClassA newNumber]"
"-[ClassA newNumber]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
LPC2_0:
        add     r1, pc
LPC2_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC2_2+4))
        movs    r2, #10
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC2_2+4))
LPC2_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

        .align  2
        .code   16
        .thumb_func     "-[ClassA getNumber]"
"-[ClassA getNumber]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
LPC3_0:
        add     r1, pc
LPC3_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC3_2+4))
        movs    r2, #10
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC3_2+4))
LPC3_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

And now with ARC:

        .align  2
        .code   16
        .thumb_func     "-[ClassA newNumber]"
"-[ClassA newNumber]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC2_1+4))
LPC2_0:
        add     r1, pc
LPC2_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC2_2+4))
        movs    r2, #10
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC2_2+4))
LPC2_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop     {r7, pc}

        .align  2
        .code   16
        .thumb_func     "-[ClassA getNumber]"
"-[ClassA getNumber]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC3_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC3_1+4))
LPC3_0:
        add     r1, pc
LPC3_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC3_2+4))
        movs    r2, #10
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_4-(LPC3_2+4))
LPC3_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        blx     _objc_autorelease
        pop     {r7, pc}

And look at the single difference – a blx (this is a method call) to objc_autorelease in getNumber:. That’s just what we’d expect from ARC because it’s noticed that the method name doesn’t start with new or copy and it knows that at the point of return the NSNumber has a retain count of 1 so it adds in an autorelease call. Excellent!

This has just shown a little insight into how ARC works in two circumstances and I hope it inspires the reader to go away and look for themselves into how ARC works rather than just taking it for granted. It’s important as a programmer to understand how your tools work.

Since 2.2 went live we’ve seen a lot more uptake of the app with more people reviewing beers and even some of the social media integration being used in the app which is exactly what we wanted. We wanted to push the app in a more social direction rather than just reviewing beers and pubs. If you’re simply reviewing beers and pubs then you need critical mass of users before any of that data becomes usable. So opting for the more Twitter-like style of a review now being a “Taste” and having a timeline of realtime “Tastes” coming in, the idea becomes like a way to tell the world what you think about the beer you’re drinking right now. We kept the idea of pubs (or places as we call them, because it might be a pub, a bar, a beer festival, etc) but you cannot actually review a pub. This serves the purpose of making the app simpler to understand because there’s just one first class citizen and that’s the “Taste”.

But, I’m sad now. Why is it that people decide for themselves what an app should do? Why is it that people writing reviews for apps cannot be constructive? Why is it that people think that free apps should be 100% perfect straight away? Here’s a review we got a day after 2.2 came out:

[1 star] – Why hasn’t beerintheevening got an app? This is not a satisfactory substitute – it neither adequately provides user reviews of pubs nor does it review beers. FAIL.

This was coupled with a support email request which goes further to complain about the app and how they failed to read the instructions for adding a new pub (it’s really not that complicated).

We’ll see what the future holds for BeerMap. I sincerely hope that it’s good things because I think that there’s a definite use for an app like this, especially in the UK where beer can vary between parts of the country so you want a way to find a pub that’s great.

So if you’ve got an iPad and want cheap data for it then go grab a GiffGaff SIM and away you go!

void a() {
    int a = 0;
    int b = 0;
    __asm__("\n"
            "\tmov %0, 0\n"
            "\tldr %0, %1\n"
            "\tmov %1, 0\n"
            : "=r"(a), "+m"(b)
           );
}

To break that down a bit, the function is doing this:

1.     int a = 0;
       int b = 0;
   

   Initialise a couple of variables and set them to 0.

2.     __asm__("\n"
               "\tmov %0, 0\n"
               "\tldr %0, %1\n"
               "\tmov %1, 0\n"
               : "=r"(a), "+m"(b)
              );
   

   Then perform some inline assembly using the variables. This just puts 0 into the register that will hold our ‘a’ variable, then loads the value of ‘b’ into ‘a’, then sets ‘b’ to 0.

This is of course a contrived example, but it illustrates the bug. The output assembly from LLVM-GCC or clang is (for ARM architecture):

        .globl  _a
        .align  2
        .code   16
        .thumb_func     _a
_a:
        sub     sp, #8
        movs    r0, #0
        movt    r0, #0
        str     r0, [sp, #4]
        str     r0, [sp]
        mov     r0, sp
        @ InlineAsm Start

        mov r0, 0
        ldr r0, [r0]
        mov [r0], 0

        @ InlineAsm End
        str     r0, [sp, #4]
        add     sp, #8
        bx      lr

The interesting bit is the inline assembly. You’ll notice that it’s doing something very stupid. It’s choosing the same register for both operands (it’s choosing r0). This is completely wrong, and will lead to a runtime crash in this case due to the dereference of 0.

I did a bit of hunting and it appears to be a problem in generating the LLVM bytecode as the problem manifests itself before the LLVM bytecode is compiled down into instructions, like so:

define void @a() nounwind ssp {
  %a = alloca i32, align 4
  %b = alloca i32, align 4
  store i32 0, i32* %a, align 4
  store i32 0, i32* %b, align 4
  %1 = call i32 asm "\0A\09mov $0, 0\0A\09ldr $0, $1\0A\09mov $1, 0\0A", "=r,=*m,*m"(i32* %b, i32* %b) nounwind, !srcloc !0
  store i32 %1, i32* %a, align 4
  ret void
}

You can see here that the ‘%a’ (i.e. variable ‘a’) is never referenced, only ‘%b’ (i.e. variable ‘a’). This is not what we’d expect at all given we’re referencing both variables in the code.

I found this quite interesting .

[Update]

I’ve actually found out that this isn’t a bug! That’s good news, right? It’s quite a subtle thing, but the heart of the problem can be explained after understanding the modifiers to operands on inline assembly. The problem is that we’re not specifying that ‘a’ is clobbered early. In the assembly, we’re writing to it before reading we’ve finished using all input operands (only ‘b’ in this case) so we’re meant to mark it like that. It’s just luck that GCC does the right thing – Apple’s LLVM is doing the right thing and using less registers!

So the correct code is this:

void a() {
    int a = 0;
    int b = 0;
    __asm__("\n"
            "\tmov %0, 0\n"
            "\tldr %0, %1\n"
            "\tmov %1, 0\n"
            : "=&r"(a), "+m"(b)
           );
}

Which results in the following assembly:

        .globl  _a
        .align  2
        .code   16
        .thumb_func     _a
_a:
        sub     sp, #8
        movs    r0, #0
        movt    r0, #0
        str     r0, [sp, #4]
        str     r0, [sp]
        mov     r0, sp
        @ InlineAsm Start

        mov r1, 0
        ldr r1, [r0]
        mov [r0], 0

        @ InlineAsm End
        str     r1, [sp, #4]
        add     sp, #8
        bx      lr

And the following LLVM:

define void @a() nounwind ssp {
  %a = alloca i32, align 4
  %b = alloca i32, align 4
  store i32 0, i32* %a, align 4
  store i32 0, i32* %b, align 4
  %1 = call i32 asm "\0A\09mov $0, 0\0A\09ldr $0, $1\0A\09mov $1, 0\0A", "=&r,=*m,*m"(i32* %b, i32* %b) nounwind, !srcloc !0
  store i32 %1, i32* %a, align 4
  ret void
}

I usually end up hand rolling a UITableViewCell subclass, or if I only ever want 1 of that type of cell in a given view (for instance a single username and single password cell) I might use Interface Builder to create the cell and put it in the XIB for the view controller. But when you end up with 10+ projects each with a handful of custom cells, you soon go quite mad trying to remember each detail about each cell.

So I was pleasantly surprised when I was recently given the opportunity to take a look at Sensible Cocoa‘s Sensible TableView (STV) project, which is a collection of Objective-C classes for easily creating custom UITableViewCells.

The Review

Having had a play with STV I have managed to get to grips with how it works and why you might want to use it. Hopefully by reading this you can get an insight into why you might want to use STV.

Features

STV at it’s core is a very simple way of creating custom cells (see the code samples below) but also there’s a lot of very impressive extra features such as binding to a data model so that you can create very complex interfaces to interact with your data. They also appear to be adding features all the time which is a good sign.

Examples

The best examples are on Sensible Cocoa’s website where there are videos showing how to use it.

Cost

STV is currently $99 for a license which includes full source code & limited time support. I think this is pretty decent value for money given what you can do with it.

Summary

If you’re someone who uses UITableView everyday, I can see that STV will definitely make your life a lot easier. I’d suggest that it might be suited more to contractors who are constantly churning out apps rather than developers working on long term projects where rolling your own cells is probably the right way to go still, given that you still get much more control over the cells if you do it yourself. For instance, in my Subnet Calc range of applications I have created a custom cell that is far too custom for STV to ever implement – it’s too specific to the application.

Overall, go and give STV a look. Watch the tutorial videos and see if it can do something for you.

In the coming weeks I aim to write a few more posts aimed at showing a few of the features of STV.

Here is an example of what happened…

Consider the following C file. It’s just a very simple function that has some inline assembly (to count down from 10 to 0) and a very simple function that does absolutely nothing.

void func() {
    int tmp;
    __asm__ __volatile__ (
        "\tmov %0, #10\n"

        ".loop:\n"
        "\tsubs %0, %0, #1\n"
        "\tbne .loop\n"

        : "=r" (tmp)
        : "r" (tmp)
    );
}

void funcB() {
}

Let’s see what happens when we compile it for iOS…

        .section __TEXT,__text,regular
        .section __TEXT,__textcoal_nt,coalesced
        .section __TEXT,__const_coal,coalesced
        .section __TEXT,__picsymbolstub4,symbol_stubs,none,16
        .text
        .align 2
        .globl _func
_func:
        @ args = 0, pretend = 0, frame = 4
        @ frame_needed = 1, uses_anonymous_args = 0
        stmfd   sp!, {r7, lr}
        add     r7, sp, #0
        sub     sp, sp, #4
        ldr     r3, [sp]
                mov r3, #10
.loop:
        subs r3, r3, #1
        bne .loop

        str     r3, [sp]
        sub     sp, r7, #0
        ldmfd   sp!, {r7, pc}
        .align 2
        .globl _funcB
_funcB:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 1, uses_anonymous_args = 0
        stmfd   sp!, {r7, lr}
        add     r7, sp, #0
        ldmfd   sp!, {r7, pc}
        .subsections_via_symbols

That all looks fairly normal and we could quite happily believe that was going to work just fine. So, let’s use this function in a test application. The code below is just a very simple application that calls the ‘func()’ function and then returns.

void func();
int main() {
    func();
    return 0;
}

So now let’s see what happens when we link this with the same options that you would have on by default in an iOS application (hint: -dead_strip is active).

Output from ‘otool -vV -t’ on the linked application:

_main:
00002fa0        e92d4080        push    {r7, lr}
00002fa4        e28d7000        add     r7, sp, #0      @ 0x0
00002fa8        eb000002        bl      _func
00002fac        e3a03000        mov     r3, #0  @ 0x0
00002fb0        e1a00003        mov     r0, r3
00002fb4        e8bd8080        pop     {r7, pc}
_func:
00002fb8        e92d4080        push    {r7, lr}
00002fbc        e28d7000        add     r7, sp, #0      @ 0x0
00002fc0        e24dd004        sub     sp, sp, #4      @ 0x4
00002fc4        e59d3000        ldr     r3, [sp]
00002fc8        e3a0300a        mov     r3, #10 @ 0xa

What?! Where’s the rest of the ‘func()’ code?! Not only is it missing, but it would appear that ‘func()’ just simply stops without ever returning?! That looks very suspicious… So, let’s compile it without the ‘-dead_strip’ option:

Output from ‘otool -vV -t’ on the linked application:

_main:
00002f80        e92d4080        push    {r7, lr}
00002f84        e28d7000        add     r7, sp, #0      @ 0x0
00002f88        eb000002        bl      _func
00002f8c        e3a03000        mov     r3, #0  @ 0x0
00002f90        e1a00003        mov     r0, r3
00002f94        e8bd8080        pop     {r7, pc}
_func:
00002f98        e92d4080        push    {r7, lr}
00002f9c        e28d7000        add     r7, sp, #0      @ 0x0
00002fa0        e24dd004        sub     sp, sp, #4      @ 0x4
00002fa4        e59d3000        ldr     r3, [sp]
00002fa8        e3a0300a        mov     r3, #10 @ 0xa
.loop:
00002fac        e2533001        subs    r3, r3, #1      @ 0x1
00002fb0        1afffffd        bne     .loop
00002fb4        e58d3000        str     r3, [sp]
00002fb8        e247d000        sub     sp, r7, #0      @ 0x0
00002fbc        e8bd8080        pop     {r7, pc}
_funcB:
00002fc0        e92d4080        push    {r7, lr}
00002fc4        e28d7000        add     r7, sp, #0      @ 0x0
00002fc8        e8bd8080        pop     {r7, pc}

Ah, that’s better! The loop is back and so is the return. Also, ‘funcB()’ is still in there. So, what has happened you may ask. Well, -dead_strip is designed to remove symbols from a binary that are not required. So we’d expect ‘funcB’ to be removed, but not .loop as it’s part of ‘func’. However, if we look closer, what has happened is that ‘.loop’ has become a top level symbol rather than a symbol local to the ‘func’ symbol. So -dead_strip assumed that it was a symbol not used anywhere (as it’s only accessed from within .loop itself) and so it removed it, resulting in a completely mangled application binary.

To stop this happening you must always prefix your local symbols with ‘L’ (as per the GCC documentation!). But I think this is an excellent example of what can go wrong if you just do 1 tiny thing wrong with inline assembly.

As a side note, I decided to try compiling/assembling/linking all of the above for Android as well. Interestingly the results were different. First I’ll show the outputs of the various stages and then explain the results.

The assembly generated for Android:

        .arch armv6
        .fpu softvfp
        .eabi_attribute 20, 1
        .eabi_attribute 21, 1
        .eabi_attribute 23, 3
        .eabi_attribute 24, 1
        .eabi_attribute 25, 1
        .eabi_attribute 26, 2
        .eabi_attribute 30, 6
        .eabi_attribute 18, 4
        .file   "test.c"
        .text
        .align  2
        .global func
        .type   func, %function
func:
        @ args = 0, pretend = 0, frame = 8
        @ frame_needed = 1, uses_anonymous_args = 0
        @ link register save eliminated.
        str     fp, [sp, #-4]!
        add     fp, sp, #0
        sub     sp, sp, #12
        ldr     r3, [fp, #-8]
#APP
@ 3 "test.c" 1
                mov r3, #10
.loop:
        subs r3, r3, #1
        bne .loop

@ 0 "" 2
        str     r3, [fp, #-8]
        add     sp, fp, #0
        ldmfd   sp!, {fp}
        bx      lr
        .size   func, .-func
        .align  2
        .global funcB
        .type   funcB, %function
funcB:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 1, uses_anonymous_args = 0
        @ link register save eliminated.
        str     fp, [sp, #-4]!
        add     fp, sp, #0
        add     sp, fp, #0
        ldmfd   sp!, {fp}
        bx      lr
        .size   funcB, .-funcB
        .ident  "GCC: (GNU) 4.4.3"
        .section        .note.GNU-stack,"",%progbits

Disassembly of linked app for Android (without stripping):

000082e0 <main>:
    82e0:       e92d4800        push    {fp, lr}
    82e4:       e28db004        add     fp, sp, #4      ; 0x4
    82e8:       eb000002        bl      82f8 <func>
    82ec:       e3a03000        mov     r3, #0  ; 0x0
    82f0:       e1a00003        mov     r0, r3
    82f4:       e8bd8800        pop     {fp, pc}

000082f8 <func>:
    82f8:       e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
    82fc:       e28db000        add     fp, sp, #0      ; 0x0
    8300:       e24dd00c        sub     sp, sp, #12     ; 0xc
    8304:       e51b3008        ldr     r3, [fp, #-8]
    8308:       e3a0300a        mov     r3, #10 ; 0xa

0000830c <.loop>:
    830c:       e2533001        subs    r3, r3, #1      ; 0x1
    8310:       1afffffd        bne     830c <.loop>
    8314:       e50b3008        str     r3, [fp, #-8]
    8318:       e28bd000        add     sp, fp, #0      ; 0x0
    831c:       e8bd0800        pop     {fp}
    8320:       e12fff1e        bx      lr

00008324 <funcB>:
    8324:       e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
    8328:       e28db000        add     fp, sp, #0      ; 0x0
    832c:       e28bd000        add     sp, fp, #0      ; 0x0
    8330:       e8bd0800        pop     {fp}
    8334:       e12fff1e        bx      lr

Disassembly of linked app for Android (after using strip command):

000082e0 <main>:
    82e0:       e92d4800        push    {fp, lr}
    82e4:       e28db004        add     fp, sp, #4      ; 0x4
    82e8:       eb000002        bl      82f8 <func>
    82ec:       e3a03000        mov     r3, #0  ; 0x0
    82f0:       e1a00003        mov     r0, r3
    82f4:       e8bd8800        pop     {fp, pc}

000082f8 <func>:
    82f8:       e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
    82fc:       e28db000        add     fp, sp, #0      ; 0x0
    8300:       e24dd00c        sub     sp, sp, #12     ; 0xc
    8304:       e51b3008        ldr     r3, [fp, #-8]
    8308:       e3a0300a        mov     r3, #10 ; 0xa
    830c:       e2533001        subs    r3, r3, #1      ; 0x1
    8310:       1afffffd        bne     830c <func+0x14>
    8314:       e50b3008        str     r3, [fp, #-8]
    8318:       e28bd000        add     sp, fp, #0      ; 0x0
    831c:       e8bd0800        pop     {fp}
    8320:       e12fff1e        bx      lr

You can see that the Android GCC has done a much better job at stripping out the symbols. This is because of a subtle “.size” attribute given to functions in the assembly for Linux (and therefore Android) which tells the assembler how big the function is. However, this doesn’t exist on Mac and the size is calculated by taking the distance between the start of a symbol and the next symbol.

This actually helps us to understand a bit more what actually went wrong. If you look back up at the assembly generated for iOS and Android you’ll see that the ‘.loop’ appears as a top level symbol, which is confirmed by running ‘nm’ on the resulting object file. This sounds all wrong, since the .loop symbol should really be local to the ‘func()’ function. The reason being because you need to prefix local symbols with ‘L’. If we change ‘.loop’ for ‘Lloop’ in the sample file, then these are the resulting outputs showing the iOS linker doing the right thing this time even with -dead_strip enabled.

Compiled output:

        .section __TEXT,__text,regular
        .section __TEXT,__textcoal_nt,coalesced
        .section __TEXT,__const_coal,coalesced
        .section __TEXT,__picsymbolstub4,symbol_stubs,none,16
        .text
        .align 2
        .globl _func
_func:
        @ args = 0, pretend = 0, frame = 4
        @ frame_needed = 1, uses_anonymous_args = 0
        stmfd   sp!, {r7, lr}
        add     r7, sp, #0
        sub     sp, sp, #4
        ldr     r3, [sp]
                mov r3, #10
Lloop:
        subs r3, r3, #1
        bne Lloop

        str     r3, [sp]
        sub     sp, r7, #0
        ldmfd   sp!, {r7, pc}
        .align 2
        .globl _funcB
_funcB:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 1, uses_anonymous_args = 0
        stmfd   sp!, {r7, lr}
        add     r7, sp, #0
        ldmfd   sp!, {r7, pc}
        .subsections_via_symbols

Disassembly of linked application:

_main:
00002f8c        e92d4080        push    {r7, lr}
00002f90        e28d7000        add     r7, sp, #0      @ 0x0
00002f94        eb000002        bl      _func
00002f98        e3a03000        mov     r3, #0  @ 0x0
00002f9c        e1a00003        mov     r0, r3
00002fa0        e8bd8080        pop     {r7, pc}
_func:
00002fa4        e92d4080        push    {r7, lr}
00002fa8        e28d7000        add     r7, sp, #0      @ 0x0
00002fac        e24dd004        sub     sp, sp, #4      @ 0x4
00002fb0        e59d3000        ldr     r3, [sp]
00002fb4        e3a0300a        mov     r3, #10 @ 0xa
00002fb8        e2533001        subs    r3, r3, #1      @ 0x1
00002fbc        1afffffd        bne     0x2fb8
00002fc0        e58d3000        str     r3, [sp]
00002fc4        e247d000        sub     sp, r7, #0      @ 0x0
00002fc8        e8bd8080        pop     {r7, pc}

This all serves to illustrate the point that it’s worth knowing about the options of your compiler, assembler & linker and understanding how everything fits together.