What does it do?

The concept behind objc_autoreleaseReturnValue is that if a value is to be returned from a function autoreleased, but the very next thing that is to be done is a retain on that object then it’s absolutely pointless doing the autorelease and retain – we’re just wasting cycles. So if we can somehow determine that we’re about to retain then we can save a few CPU cycles. Over the course of a running application this could add up to quite a lot of time and effort saved.

In Apple’s code they say this:

objc_autoreleaseReturnValue() examines the caller’s instructions following
the return. If the caller’s instructions immediately call
objc_autoreleaseReturnValue, then the callee omits the -autorelease and saves
the result in thread-local storage. If the caller does not look like it
cooperates, then the callee calls -autorelease as usual.

objc_autoreleaseReturnValue checks if the returned value is the same as the
one in thread-local storage. If it is, the value is used directly. If not,
the value is assumed to be truly autoreleased and is retained again. In
either case, the caller now has a retained reference to the value.

[I think there is a typo there in that it should read "If the caller's instructions immediately call objc_retainAutoreleasedReturnValue".]

So basically what it means is that if you consider this bit of code:

- (SomeClass*)createMeAnObject {
   SomeClass *obj = [[SomeClass alloc] init];
   obj.string = @"Badger";
   obj.number = 10;
   return obj;
}

- (id)init {
    if ((self = [super init])) {
        self.myObject = [self createMeAnObject];
    }
    return self;
}

Just ignore the fact that you wouldn’t really do that, but if we rewrite that to include the retains, releases & autoreleases that will be going on behind the scenes then it looks like this:

- (SomeClass*)createMeAnObject {
   SomeClass *obj = [[SomeClass alloc] init];
   obj.string = @"Badger";
   obj.number = 10;
   return [obj autorelease];
}

- (id)init {
    if ((self = [super init])) {
        [myObject release];
        SomeClass *temp = [self createMeAnObject];
        myObject = [temp retain];
    }
    return self;
}

Now then if we inline the createMeAnObject code into init:

- (id)init {
    if ((self = [super init])) {
        [myObject release];
        SomeClass *temp = [[SomeClass alloc] init];
        obj.string = @"Badger";
        obj.number = 10;
        [temp autorelease];
        myObject = [temp retain];
    }
    return self;
}

Here we notice that there is a [temp autorelease] followed immediately by a [temp retain]. It is this optimisation that the new Objective-C runtime can help us with.

How does it work – objc_autoreleaseReturnValue?

The code is out there for the x86 version of this, but there’s no ARM code so I had to go digging into the disassembly for it.

Here’s the disassembly for objc_autoreleaseReturnValue:

_objc_autoreleaseReturnValue:
00006ec4            b580        push    {r7, lr}
00006ec6            466f        mov     r7, sp
00006ec8        f01e0f01        tst.w   lr, #1  @ 0x1
00006ecc            d004        beq.n   0x6ed8
00006ece        f83e1c01        ldrh.w  r1, [lr, #-1]
00006ed2        f244623f        movw    r2, 0x463f
00006ed6            e005        b.n     0x6ee4
00006ed8        f8de1000        ldr.w   r1, [lr]
00006edc        f2470207        movw    r2, 0x7007
00006ee0        f2ce12a0        movt    r2, 0xe1a0
00006ee4            4291        cmp     r1, r2
00006ee6            d106        bne.n   0x6ef6
00006ee8        ee1d1f70        mrc     15, 0, r1, cr13, cr0, {3}
00006eec        f0210103        bic.w   r1, r1, #3      @ 0x3
00006ef0        f8c100c4        str.w   r0, [r1, #196]
00006ef4            bd80        pop     {r7, pc}
00006ef6        f00bfb93        bl      _objc_autorelease
00006efa            bd80        pop     {r7, pc}

Let’s break that down then…

00006ec4            b580        push    {r7, lr}
00006ec6            466f        mov     r7, sp

This is a standard prologue for a method in ARM.

00006ec8        f01e0f01        tst.w   lr, #1  @ 0x1
00006ecc            d004        beq.n   0x6ed8

Here we are doing the first bit of our sniffing of the following instructions. lr is the “link register” and contains the address of the method that we’re returning to. Since this method is always called as a tail call, this will contain the address of the caller of our method that’s returning a value autoreleased.

The tst instruction is doing a bitwise AND of the value in lr and the integer value 1. Then the beq will branch if the zero flag is set, i.e. if lr & 1 == 0. So this means that we are testing if the lowest bit is not set. You can either read up about ARM processors or take it from me that if the low bit is set on the link register then it means the caller is in thumb mode. So this means that if we’re going back to ARM code then we branch over a few instructions to 0x6ed8 whereas if we’re going back to Thumb code then we don’t branch.

00006ece        f83e1c01        ldrh.w  r1, [lr, #-1]
00006ed2        f244623f        movw    r2, 0x463f
00006ed6            e005        b.n     0x6ee4

This is the case that gets run if our condition before was not true. We are loading a half word (16-bits) from lr - 1 into r1 (we need the -1 because of the reason from before that the low bit is set if we’re in Thumb mode so actually the next instruction after return will be at lr - 1). We then put 0x463f into r2. Then we jump to 0x6ee4.

00006ed8        f8de1000        ldr.w   r1, [lr]
00006edc        f2470207        movw    r2, 0x7007
00006ee0        f2ce12a0        movt    r2, 0xe1a0

This is the case that gets run if our condition before was true. We are here loading a whole 32-bits from lr into r1 and loading 0xe1a07007 into r2.

00006ee4            4291        cmp     r1, r2
00006ee6            d106        bne.n   0x6ef6

The next section compares the two registers that we’ve just been setting in one of two ways. If they are not equal then we branch over to 0x6ef6

So we’re matching against either 0x463f (if it’s Thumb mode) or 0xe1a07007 (if it’s ARM mode). Why do we care that the instructions that we’re about to run when we return have those particular binary values? Well if we compile a method that does the objc_autoreleaseReturnValue and objc_retainAutoreleasedReturnValue dance then we see that the compiler adds in an instruction which acts as a marker. Let’s see what it looks like:

Thumb mode:
f7ffef56	blx	_objc_msgSend
    463f	mov	r7, r7
f7ffef54	blx	_objc_retainAutoreleasedReturnValue

ARM mode:
ebffffa0	bl	_objc_msgSend
e1a07007	mov	r7, r7
ebffff9e	bl	_objc_retainAutoreleasedReturnValue

Well take a look at that. It’s added in a mov r7, r7 in each case which is a noop (i.e. does nothing as it moves r7 back into itself). If you examine the binary values for these instructions then you’ll see they match the values that we were told to compare against. The compiler has added this as a marker to tell the objc_autoreleaseReturnValue that the caller is about to call objc_retainAutoreleasedReturnValue.

00006ee8        ee1d1f70        mrc     15, 0, r1, cr13, cr0, {3}
00006eec        f0210103        bic.w   r1, r1, #3      @ 0x3
00006ef0        f8c100c4        str.w   r0, [r1, #196]
00006ef4            bd80        pop     {r7, pc}

This is the code that gets run if the instructions matched. It appears to be getting a value from a coprocessor (the mrc instruction) then acting on it and storing r0 (which will be the value that’s to be returned) into the memory location computed. Then it returns. I’m not entirely sure what this coprocessor magic is doing but it will probably become apparent when we look at the code for objc_retainAutoreleasedReturnValue. But essentially it’s setting some flag that we’ll read later.

00006ef6        f00bfb93        bl      _objc_autorelease
00006efa            bd80        pop     {r7, pc}

Finally, this is where we get to if the instructions did not match. This performs a normal call to objc_autorelease incase the caller is not about to retain the object.

How does it work – objc_retainAutoreleasedReturnValue?

Let’s now take a look at objc_retainAutoreleasedReturnValue:

_objc_retainAutoreleasedReturnValue:
00012bbc            b580        push    {r7, lr}
00012bbe        ee1d1f70        mrc     15, 0, r1, cr13, cr0, {3}
00012bc2            466f        mov     r7, sp
00012bc4        f0210103        bic.w   r1, r1, #3      @ 0x3
00012bc8        f8d110c4        ldr.w   r1, [r1, #196]
00012bcc            4281        cmp     r1, r0
00012bce            d107        bne.n   0x12be0
00012bd0        ee1d1f70        mrc     15, 0, r1, cr13, cr0, {3}
00012bd4            2200        movs    r2, #0
00012bd6        f0210103        bic.w   r1, r1, #3      @ 0x3
00012bda        f8c120c4        str.w   r2, [r1, #196]
00012bde            bd80        pop     {r7, pc}
00012be0        f7f3f976        bl      _objc_retain
00012be4            bd80        pop     {r7, pc}

And again, breaking that down we get:

00012bbc            b580        push    {r7, lr}

Standard prologue for a method.

00012bbe        ee1d1f70        mrc     15, 0, r1, cr13, cr0, {3}
00012bc2            466f        mov     r7, sp
00012bc4        f0210103        bic.w   r1, r1, #3      @ 0x3
00012bc8        f8d110c4        ldr.w   r1, [r1, #196]

Here we get some more context on what that mrc was all about before. We can see here that we’re running the same instruction as we did before and doing the same bic instruction and then loading value stored at the computed address into r1.

00012bcc            4281        cmp     r1, r0
00012bce            d107        bne.n   0x12be0

Now this is the interesting bit. We’re checking that the value we obtained from doing the dance with the coprocessor (r1) is the same as the object passed into this method (r0). If these two match then we know that the object we are trying to retain has just been returned from a method that had called objc_autoreleaseReturnValue. So we don’t need to do anything. It’s not been autoreleased so we’re not going to retain it.

00012bd0        ee1d1f70        mrc     15, 0, r1, cr13, cr0, {3}
00012bd4            2200        movs    r2, #0
00012bd6        f0210103        bic.w   r1, r1, #3      @ 0x3
00012bda        f8c120c4        str.w   r2, [r1, #196]
00012bde            bd80        pop     {r7, pc}

This is the code that then gets run if the comparison was true – i.e. this object had just gone through a objc_autoreleaseReturnValue. We clear out the value in the coprocessor magic dance and return.

00012be0        f7f3f976        bl      _objc_retain
00012be4            bd80        pop     {r7, pc}

If it didn’t match, then we know that this object has not gone through a objc_autoreleaseReturnValue, which is likely because the method we called was not compiled with ARC enabled. So we do a retain.

Phew, so explain that again please?

It’s probably easiest to consider the following pseudo code:

id objc_autoreleaseReturnValue(id object) {
    if (thumb_mode && next_instruction_after_return == 0x463f ||
        arm_mode   && next_instruction_after_return == 0xe1a07007)
    {
        set_flag(object);
    } else {
        return objc_autorelease(object);
    }
}

id objc_retainAutoreleasedReturnValue(id object) {
    if (get_flag(object)) {
        clear_flag();
    } else {
        return objc_retain(object);
    }
}

That is basically what it all boils down to and with some tail call optimisations this can all be incredibly optimised compared to all the redundant autorelease followed by retain pairs that we must have had in code before ARC was invented.

Conclusions

This is yet again some awesome stuff from the Apple engineers here. Sniffing the next instructions to be executed is some very clever stuff to ensure that it’s always going to work. They must have to ensure that the marker (mov r7, r7) isn’t moved by the optimiser for instance and I’m sure lots of edge cases but it seems to work a treat!

Some background on new

First we’ll take a look at what new actually does. According to the Apple documentation, it does this:

Allocates a new instance of the receiving class, sends it an init message, and returns the initialized object.

So we should expect a call like [SomeClass new] to be equivalent to [[SomeClass alloc] init]. The memory management here tells us that the returned object is owned by the caller, i.e. it’s returned with a +1 retain count. In the days of pre-ARC, we would therefore have to release this object when we were done with it. ARC adds these in for us as we know.

What’s being tested

What I wanted to know is which is faster out of these methods:

1. [[SomeClass alloc] init]
2. [SomeClass new]
3. [SomeClass giveMeAnObject]
4. [SomeClass newObject]

Where giveMeAnObject is a convenience method to return an object autoreleased and newObject is a convenience method which we would hope is the same as the standard new.

How to test

In order to benchmark each of these methods I decided to time how long it would take to call each of them a given number of times with correct memory management (well, I have no choice if ARC is enabled). I used this method for timing which gives me the number of nanoseconds that my code took to execute:

uint64_t start = mach_absolute_time();
// Do something which takes a while
uint64_t end = mach_absolute_time();

mach_timebase_info_data_t timebaseInfo;
mach_timebase_info(&timebaseInfo);
uint64_t timeNanos = (end - start) * timebaseInfo.numer / timebaseInfo.denom;
NSLog(@"time = %"PRIu64, timeNanos);

In order to test this and to ensure there’d be no shortcuts made by the compiler / runtime by using an NSString or an NSNumber I created a simple dummy class called ClassA like so:

@interface ClassA : NSObject
+ (ClassA*)giveMeAnObject;
+ (ClassA*)newObject;
@end

@implementation ClassA
+ (ClassA*)giveMeAnObject {
    return [[ClassA alloc] init];
}
+ (ClassA*)newObject {
    return [[ClassA alloc] init];
}
@end

Then to benchmark each one I decided to loop for a number of iterations ranging from 1000 to 10000000 for each style of creating an instance of ClassA. Each of these should have the exact same effect, but we’d like to know how they differ in speed. Below is the code I used, commenting out all but one of the ClassA *x = each time I did the test.

for (unsigned long long i = 0; i < iterations; ++i) {
    ClassA *a = [[ClassA alloc] init];
    ClassA *b = [ClassA new];
    ClassA *c = [ClassA giveMeAnObject];
    ClassA *d = [ClassA newObject];
}

For each of these tests I used my iPhone 4 (so ARMv7), running iOS 5.0.1 and compiled the code at O3.

The results are in!

Below are the results of running the tests. The value under each column is the time taken in milliseconds for the number of iterations given on the left.

And graphically, that looks like this:

So what does that tell us then? Well it basically tells us that alloc + init is fastest, with new and our custom convenience new close behind. It also shows us that for large iterations, our convenience method that returns the value autoreleased is quite a bit slower. At the maximum number of iterations, it was more than twice as slow as the other methods.

Let’s analyse what happened then

In order to understand what’s going on here, let’s take a look at the code generated. Below are the various interesting bits of code.

ClassA‘s giveMeAnObject:

	.align	2
	.code	16
	.thumb_func	"+[ClassA giveMeAnObject]"
"+[ClassA giveMeAnObject]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC0_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC0_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC0_1+4))
LPC0_0:
        add     r1, pc
LPC0_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC0_2+4))
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC0_2+4))
LPC0_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop.w   {r7, lr}
        b.w     _objc_autorelease

[18 instructions]

ClassA‘s newObject:

	.align	2
	.code	16
	.thumb_func	"+[ClassA newObject]"
"+[ClassA newObject]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC4_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(LPC4_0+4))
        movw    r0, :lower16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC4_1+4))
        movt    r0, :upper16:(L_OBJC_CLASSLIST_REFERENCES_$_-(LPC4_1+4))
LPC4_0:
        add     r1, pc
LPC4_1:
        add     r0, pc
        ldr     r1, [r1]
        ldr     r0, [r0]
        blx     _objc_msgSend
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC4_2+4))
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC4_2+4))
LPC4_2:
        add     r1, pc
        ldr     r1, [r1]
        pop.w   {r7, lr}
        b.w     _objc_msgSend

[17 instructions]

Iteration loop for method A:

LBB2_1:
	ldr	r1, [r5]
	ldr	r0, [r6]
	blx	_objc_msgSend
	ldr.w	r1, [r8]
	blx	_objc_msgSend
	blx	_objc_release
	adds.w	r11, r11, #1
	eor.w	r0, r11, r10
	adc	r4, r4, #0
	orrs	r0, r4
	bne	LBB2_1

[11 instructions]

Iteration loop for method B:

LBB2_1:
	ldr	r1, [r5]
	ldr	r0, [r6]
	blx	_objc_msgSend
	blx	_objc_release
	adds.w	r10, r10, #1
	eor.w	r0, r10, r8
	adc	r4, r4, #0
	orrs	r0, r4
	bne	LBB2_1

[9 instructions]

Iteration loop for method C:

LBB2_1:
	ldr	r1, [r5]
	ldr	r0, [r6]
	blx	_objc_msgSend
	@ InlineAsm Start
	mov	r7, r7		@ marker for objc_retainAutoreleaseReturnValue
	@ InlineAsm End
	blx	_objc_retainAutoreleasedReturnValue
	blx	_objc_release
	adds.w	r10, r10, #1
	eor.w	r0, r10, r8
	adc	r4, r4, #0
	orrs	r0, r4
	bne	LBB2_1

[11 instructions]

Iteration loop for method D:

LBB2_1:
	ldr	r1, [r5]
	ldr	r0, [r6]
	blx	_objc_msgSend
	blx	_objc_release
	adds.w	r10, r10, #1
	eor.w	r0, r10, r8
	adc	r4, r4, #0
	orrs	r0, r4
	bne	LBB2_1

[9 instructions]

So having looked at all the relevant code it might be surprising that these are that different. They’re all going to have a similar number of instructions. Infact method A has in the inner loop more instructions, but it was the fastest. The interesting question is why is method C so much slower than the others for large number of iterations? If we take a look at the generated code for method C we’ll notice that there’s a call to objc_retainAutoreleasedReturnValue. This method is a kind of shortcut to retain a value that will have been returned autoreleased. It should be working with our code since all of this is compiled using ARC and running on an iOS 5 device. It was interesting to me then that this method took twice as long at large numbers of iterations. I can understand that it’s likely to be slower since there’s more message dispatch going on, but I did not expect it to be that much slower and also interesting that the difference increase with increasing number of iterations.

Conclusions

I’m actually at a loss as to how to explain why method C is so much slower. It’s great to see that A, B and D are roughly the same speed, which is of course what we would expect. This whole thing does mean that we are much better off using new, alloc + init or a convenience method that returns an object with a +1 retain count rather than using convenience methods that return the object autoreleased. See below for a reasoning for why method C was slower and how method C can become just as fast as the other methods.

Ah ha! That’s why!

Having done a bit more digging I have found why method C was so much slower. Whilst I was writing this up I thought it was a bit odd that the tail call in giveMeAnObject was to objc_autorelease rather than objc_autoreleaseReturnValue. The magic of objc_retainAutoreleasedReturnValue which I refer to previously only works if the value has been returned with objc_autoreleaseReturnValue. The internals of that are for a later blog post but just take it from me that it works like that. So I decided to just change the return type of giveMeAnObject from ClassA* to id. I thought that this should make absolutely no difference. I was wrong. Take a look and see:

+ (id)giveMeAnObject {
    return [[ClassA alloc] init];
}

This outputs this assembly:

        .align  2
        .code   16
        .thumb_func     "+[ClassA giveMeAnObject3]"
"+[ClassA giveMeAnObject3]":
        push    {r7, lr}
        movw    r1, :lower16:(L_OBJC_SELECTOR_REFERENCES_-(LPC2_0+4))
        mov     r7, sp
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_-(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_2-(LPC2_2+4))
        movt    r1, :upper16:(L_OBJC_SELECTOR_REFERENCES_2-(LPC2_2+4))
LPC2_2:
        add     r1, pc
        ldr     r1, [r1]
        blx     _objc_msgSend
        pop.w   {r7, lr}
        b.w     _objc_autoreleaseReturnValue

The single difference here is the call to objc_autoreleaseReturnValue rather than objc_autorelease. I still don’t particularly understand why the compiler is doing something different here, so I’ve still to work that one through but The results for the benchmark using this method are as follows (added to the previous results where I’ve called this new method, E):

So that at least explains why method C was so much slower. But I’ve no idea why the compiler doesn’t emit the same thing when the return type of giveMeAnObject is ClassA* or id.

Update: Turns out, it’s a bug

It turns out that it’s a bug that the compiler (well, the optimiser part of the compiler) did something different for the case of returning id versus ClassA* and the cases of splitting out the alloc + init in the method versus returning on the same line. All of these should compile exactly the same, but they don’t in the current version of clang.

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
}