ARM Assembly Part 5: Branching, Loops & Conditional Execution

Introduction

Branch Instruction Overview

If data-processing instructions are the "muscles" of a program, branches are its nervous system — they make decisions, create loops, call functions, and return results. AArch64 provides three clean families of branch instructions:

PC-Relative Range Limits

Every branch instruction encodes its target as a PC-relative offset within the 32-bit instruction word. Different instructions sacrifice different amounts of encoding space for the offset, giving them different ranges:

Unconditional Branches

B & BR — Jump

B (Branch) is the simplest control-flow instruction — an unconditional PC-relative jump. BR (Branch Register) is its indirect sibling, jumping to the absolute 64-bit address held in a register:

// B — PC-relative unconditional jump
    B    .target              // Jump to label (PC + signed offset)
    B    _start               // Jump to symbol (linker resolves)

    // BR — Register-indirect jump (no link)
    BR   x16                  // Jump to address in x16
                               // Does NOT save return address
                               // Used for: computed gotos, tail calls,
                               // jump tables, longjmp

BL & BLR — Call (Link)

BL (Branch with Link) and BLR (Branch with Link to Register) are the function call instructions. Before jumping, they save PC+4 (the address of the next instruction) into X30 (the Link Register), creating a breadcrumb trail for the callee to return to:

// Direct function call (BL)
    BL   printf              // X30 = PC+4, then jump to printf
                               // printf will RET back to here

    // Indirect function call (BLR)
    LDR  x8, [x0, #callback] // Load function pointer from struct
    BLR  x8                  // X30 = PC+4, then call via x8

    // Multiple calls in sequence
    BL   init_hardware        // X30 = addr_of_next_instr
    BL   config_clocks        // X30 updated again (overwritten!)
    BL   main                 // Each BL overwrites X30

RET — Return

RET branches to the address in X30 (by default), returning control to the caller. Critical details:

• RET is NOT a stack pop: It only jumps to X30. It does NOT pop the return address from the stack (unlike x86-64's RET). The callee must restore X30 from the stack manually if it saved it.
• Optional register: RET Xn returns to the address in Xn instead of X30 — rarely used but available for coroutines or custom dispatch.
• Branch prediction hint: The processor treats RET differently from BR x30 — RET uses the return address stack predictor, which is faster. Always use RET for function returns, never BR X30.

// Leaf function (no calls → no need to save X30)
    ADD  x0, x0, x1           // Compute result
    RET                        // Return to caller via X30

    // Non-leaf function (calls other functions → must save X30)
    STP  x29, x30, [sp, #-16]!  // Save FP and LR
    MOV  x29, sp                 // Set frame pointer
    BL   helper                  // Call helper (overwrites X30)
    LDP  x29, x30, [sp], #16    // Restore FP and LR
    RET                          // Return to original caller

Compare & Branch

CBZ/CBNZ — Compare Zero

CBZ (Compare and Branch on Zero) and CBNZ (Compare and Branch on Nonzero) test a register directly without setting or reading NZCV flags. They combine a comparison with zero and a branch into a single instruction — saving the separate CMP that x86-64 requires:

// Null pointer check (most common use)
    CBZ  x0, .return_null    // if (ptr == NULL) goto return_null
    // ptr is guaranteed non-null here

    // Loop termination (count down to zero)
    SUB  x1, x1, #1          // Decrement (no S suffix = no flags)
    CBNZ x1, .loop_body      // if (count != 0) continue

    // Linked list traversal
.traverse:
    LDR  x0, [x0, #next]     // Follow next pointer
    CBZ  x0, .end_of_list    // NULL? End of list
    // Process node...
    B    .traverse

    // 32-bit variants (test W registers)
    CBZ  w0, .is_zero_32     // Test lower 32 bits only
    CBNZ w5, .nonzero_32

TBZ/TBNZ — Test Bit

TBZ (Test Bit and Branch if Zero) and TBNZ (Test Bit and Branch if Nonzero) test a single specific bit within a register and branch accordingly. Like CBZ/CBNZ, they don't touch the NZCV flags:

// Test bit 31 (sign bit of a 32-bit value in a 64-bit register)
    TBNZ x0, #31, .is_negative  // Branch if signed negative

    // Test bit 0 (odd/even check)
    TBZ  x0, #0, .is_even       // Branch if bit 0 is clear (even)

    // Check a specific permission flag
    TBNZ x_flags, #PERM_WRITE, .has_write  // Branch if write permitted

    // Hardware status register bit test
    MRS  x0, DAIF               // Read interrupt mask register
    TBNZ x0, #7, .irq_masked    // Branch if IRQ bit (bit 7) is masked

    // Bit-scan loop (find first set bit)
.scan:
    TBZ  x0, #0, .next_bit      // Test LSB
    // Bit 0 is set — process it
    B    .done
.next_bit:
    LSR  x0, x0, #1             // Shift right
    ADD  x1, x1, #1             // Increment bit position
    CBNZ x0, .scan              // Continue if bits remain

Conditional Branches

NZCV Conditions Reference

AArch64 uses four condition flags — N (Negative), Z (Zero), C (Carry), V (Overflow) — collectively called NZCV. These flags are set by flag-setting instructions (ADDS, SUBS, ANDS, CMP, TST, etc.) and read by conditional branches and CSEL/CSET. There are 15 named conditions (14 meaningful + AL/always):

B.cond — Conditional Branch

Append any condition code to B. to create a conditional branch. The condition is evaluated against NZCV flags set by the most recent flag-setting instruction. The two most common flag-setters are CMP (subtract, discard result) and TST (AND, discard result):

// If-else pattern: if (x0 > x1) { ... } else { ... }
    CMP   x0, x1             // Set NZCV based on x0 - x1
    B.GT  .greater           // Signed: x0 > x1?
    // else path here
    B     .done
.greater:
    // greater-than path
.done:

    // Unsigned comparison
    CMP   x0, x1
    B.HI  .x0_higher         // Unsigned: x0 > x1?

    // Chained comparisons (if-elseif-else)
    CMP   x0, #0
    B.LT  .negative          // x0 < 0?
    B.EQ  .zero              // x0 == 0?
    // x0 > 0 (fall-through)

    // CMN — Compare Negative (adds instead of subtracts)
    CMN   x0, #1             // Equivalent to CMP x0, #-1
    B.EQ  .is_minus_one      // x0 == -1?

    // TST-based branching (test specific bits)
    TST   x0, #0x3           // Test alignment (low 2 bits)
    B.NE  .not_aligned        // Branch if any low bits set

CSEL, CSET, CSINC, CSINV

The CSEL family provides branchless conditional data operations — they select between two values based on a condition code without branching. This eliminates branch misprediction penalties for simple conditionals:

// CSEL — Conditional Select
    CMP   x0, x1
    CSEL  x2, x0, x1, LT    // x2 = (x0 < x1) ? x0 : x1  (min)
    CSEL  x3, x1, x0, LT    // x3 = (x0 < x1) ? x1 : x0  (max)

    // CSET — Conditional Set (boolean result)
    CMP   x0, #0
    CSET  x1, GT             // x1 = (x0 > 0) ? 1 : 0

    // CSINC — Conditional Select Increment
    CMP   x0, x1
    CSINC x2, x3, x4, EQ    // x2 = (x0 == x1) ? x3 : x4+1

    // CSINV — Conditional Select Invert
    CMP   x0, #0
    CSINV x1, xzr, xzr, GE  // x1 = (x0 >= 0) ? 0 : -1 (sign extension)

    // CSNEG — Conditional Select Negate
    CMP   x0, #0
    CSNEG x1, x0, x0, GE    // x1 = (x0 >= 0) ? x0 : -x0  (abs value!)

    // Common patterns:
    // abs(x):   CSNEG x0, x0, x0, GE  (after CMP x0, #0)
    // clamp:    CMP x0, x_max; CSEL x0, x_max, x0, GT
    // bool:     CMP x0, x1; CSET x2, EQ  (x2 = x0 == x1)

Loop Patterns

Counted Loops (SUBS + B.NE)

The most fundamental loop pattern in assembly: decrement a counter, check if it's zero, and branch back if not. The S suffix on SUBS sets the Zero flag when the counter reaches 0, eliminating the need for a separate CMP:

// Counted loop: sum 64-element array
    MOV  x0, xzr             // sum = 0
    MOV  x2, #64             // count = 64
    ADRP x1, array; ADD x1, x1, :lo12:array
.loop:
    LDR  x3, [x1], #8        // Load element, post-increment pointer
    ADD  x0, x0, x3          // sum += element
    SUBS x2, x2, #1          // count--; set Z flag when 0
    B.NE .loop                // Repeat if count != 0
    // x0 now contains the sum

    // Alternative: CBZ-based loop (no flag setting)
    MOV  x2, #64
.loop2:
    LDR  x3, [x1], #8
    ADD  x0, x0, x3
    SUB  x2, x2, #1          // No S suffix
    CBNZ x2, .loop2           // Test register directly

    // Decrement-until-zero with early exit
    MOV  x2, #MAX_ITER
.search:
    LDR  x3, [x1], #8
    CMP  x3, x_target
    B.EQ .found               // Exit early if found
    SUBS x2, x2, #1
    B.NE .search
    // Not found (exhausted iterations)

While Loops & Do-While

A while loop tests the condition before the first iteration (may execute zero times). A do-while loop tests at the bottom (always executes at least once). Compilers typically transform while-loops into do-while with a guard check for efficiency:

// while (x0 > 0) { x0 = x0 - x1; count++; }
    // Compiler transforms to: if (x0 > 0) do { ... } while (x0 > 0)
    CMP  x0, #0
    B.LE .while_done          // Guard: skip if condition already false
.while_body:
    SUB  x0, x0, x1          // x0 -= x1
    ADD  x2, x2, #1          // count++
    CMP  x0, #0
    B.GT .while_body          // Bottom test (do-while style)
.while_done:

    // do-while: process string characters
.do_loop:
    LDRB w3, [x0], #1        // Load byte, advance pointer
    // ... process character ...
    CBNZ w3, .do_loop         // Continue until null terminator

    // strlen implementation (do-while with pointer arithmetic)
    MOV  x1, x0              // Save start pointer
.strlen_loop:
    LDRB w2, [x0], #1        // Load byte
    CBNZ w2, .strlen_loop    // Continue until \0
    SUB  x0, x0, x1          // Length = end - start
    SUB  x0, x0, #1          // Adjust for post-increment past \0

Loop Unrolling Hints

Unrolling processes multiple elements per iteration, reducing branch overhead and enabling the processor to schedule instructions more efficiently:

// 4x unrolled array sum (processes 4 elements per iteration)
    MOV  x0, xzr             // sum = 0
    MOV  x2, #64             // count (must be multiple of 4)
.unrolled:
    LDP  x3, x4, [x1], #16   // Load 2 elements
    LDP  x5, x6, [x1], #16   // Load 2 more
    ADD  x0, x0, x3
    ADD  x0, x0, x4
    ADD  x0, x0, x5
    ADD  x0, x0, x6
    SUBS x2, x2, #4
    B.NE .unrolled

Function Pointers & Indirect Calls

BLR for Function Pointers

In C, every function pointer call compiles to a simple pattern: load the pointer into a register, then BLR. The AAPCS64 calling convention is identical for direct and indirect calls — arguments in X0–X7, return value in X0, return address in X30:

// C: result = callback(arg1, arg2);
// callback is a function pointer stored in a struct
    LDR  x8, [x0, #fn_offset]  // Load function pointer from struct
    MOV  x0, x1                 // First argument (shifts x1 → x0)
    MOV  x1, x2                 // Second argument
    BLR  x8                     // Call via function pointer
                                 // Return value in x0

    // Array of function pointers (dispatch table)
    ADRP x9, handler_table
    ADD  x9, x9, :lo12:handler_table
    LDR  x8, [x9, x0, LSL #3]  // handlers[event_type]
    BLR  x8                     // Dispatch to handler

    // Callback with context (like qsort comparator)
    LDR  x8, [x19, #cmp_func]  // Load comparator
    LDP  x0, x1, [x20]         // Load two items to compare
    BLR  x8                     // Call comparator(a, b)
    CMP  x0, #0                 // Check result
    B.LT .swap                   // If a < b, swap them

C++ vtable Dispatch Pattern

Virtual method calls in C++ follow a characteristic two-level indirection: load the vtable pointer from the object, then load the method pointer from the vtable slot:

// C++: obj->virtual_method(arg);
// Object layout: +0 = vptr, +8 = first data member
    LDR  x8, [x0]              // Load vptr (first word of object)
    LDR  x9, [x8, #16]         // Load vtable slot 2 (offset = N*8)
    BLR  x9                     // Call virtual method
                                 // x0 = 'this' pointer (already there)

    // Apple ARM64e: PAC-authenticated vtable dispatch
    LDR  x8, [x0]              // Load vptr
    LDR  x9, [x8, #16]         // Load vtable slot
    BLRAAZ x9                   // Authenticate and call
                                 // Traps if PAC invalid (ROP protection)

Computed Jump Tables

switch() Lowering

When a switch statement has dense, contiguous cases (e.g., 0–7), compilers generate a jump table — an array of target addresses indexed by the switch value. This is O(1) dispatch vs O(n) for a chain of compare-and-branch. The pattern has three steps: (1) bounds-check to handle the default case, (2) index into the table to load the target, (3) branch via BR:

// Compiler-generated switch/jump-table pattern
// switch (event_type) { case 0: ... case 7: ... default: ... }
    CMP   x0, #7              // Bounds check against max case
    B.HI  .default             // Out-of-range → default handler
    ADRP  x1, .jtable
    ADD   x1, x1, :lo12:.jtable
    LDR   x2, [x1, x0, LSL #3] // Load target address (8-byte entries)
    BR    x2                    // Jump to case handler

    .balign 8
.jtable:
    .dword case0, case1, case2, case3
    .dword case4, case5, case6, case7

case0:
    // Handle event 0
    B     .switch_done
case1:
    // Handle event 1
    B     .switch_done
    // ... cases 2–7 ...
.default:
    // Default handler
.switch_done:

PIC-Safe Jump Tables

Position-Independent Code (PIC) cannot embed absolute addresses in jump tables because the code may be loaded at any virtual address (shared libraries, ASLR). Instead, entries store PC-relative offsets from a known base. The loader never needs to patch the table:

// PIC-safe jump table: entries are signed offsets from table base
    CMP   x0, #7
    B.HI  .default
    ADR   x1, .pic_jtable       // PC-relative address of table
    LDRSW x2, [x1, x0, LSL #2] // Load 32-bit signed offset
    ADD   x2, x1, x2           // target = table_base + offset
    BR    x2                    // Jump to case handler

    .balign 4
.pic_jtable:
    .word case0 - .pic_jtable   // Offset from table base
    .word case1 - .pic_jtable
    .word case2 - .pic_jtable
    .word case3 - .pic_jtable

Conclusion & Next Steps

This part covered the complete AArch64 branching toolkit. Unconditional branches (B, BR, BL, BLR, RET) handle jumps, calls, and returns. Compare & Branch (CBZ/CBNZ, TBZ/TBNZ) provide efficient zero-test and bit-test patterns without touching the flags. Conditional branches (B.cond) use the 15 condition codes against NZCV flags, while CSEL/CSET/CSINC/CSINV/CSNEG deliver branchless conditional data selection. For loops, the SUBS + B.NE idiom handles counted loops, while-loops canonicalize to do-while with guard checks, and manual unrolling with LDP boosts throughput. Function pointers compile to a simple LDR + BLR pattern, C++ vtable dispatch adds one extra indirection, and PAC secures indirect calls on Apple Silicon. Jump tables give O(1) switch dispatch with PIC-safe offset encoding for shared libraries.