AArch64 Procedure Call Standard Analysis

Why We Need a "Standard" for Calling Functions

When you compile different parts of a large project, perhaps with different compilers or linking against pre-compiled libraries, how does it all work together? How does main() know how to pass arguments to calculate_crc() if they were compiled separately?

The answer is the Application Binary Interface (ABI). The ABI is a low-level contract that defines standards for data types, memory alignment, and, most importantly for us, how functions are called. The part of the ABI that specifies the rules for function calls is called the Procedure Call Standard (PCS). For AArch64, this is officially known as the "Procedure Call Standard for the Arm 64-bit Architecture," or AAPCS64.

To get a clear understanding of these concepts and their importance, please start by reading this introductory material.

The Rules of Engagement: AAPCS64

Now that you understand the why, let's dive into the what. The AAPCS64 defines a clear set of rules for register usage during function calls. Understanding these rules is like having a decoder ring for assembly language.

The definitive source for these rules is the Arm architecture documentation.

Let's break down and expand on the key rules from that document.

1. Parameter Passing and Return Values

• Arguments (Parameters): The first eight integer or pointer arguments to a function are passed in registers X0 through X7.
  • If an argument is 32 bits (like int or uint32_t), the corresponding W register (W0-W7) is used.
  • If a function has more than eight arguments, the additional ones are passed on the stack.
• Return Value: A single integer or pointer result is returned in register X0 (or W0 for a 32-bit value).
• C++ this pointer: In C++, the implicit this pointer is passed in X0, so the first explicit argument to a member function would start in X1.
• Large Return Values: If a function returns a large struct (too big for registers), the caller allocates space for it on the stack and passes a pointer to this space in register X8.

2. Register Roles: Caller-Saved vs. Callee-Saved

This is the most critical concept in the PCS. The standard divides the general-purpose registers into two groups based on who is responsible for preserving their value across a function call.

• Caller-Saved (Volatile / Corruptible) Registers: X0 - X18

  • A function being called (a "callee") is free to modify these registers for its own calculations without restriction.
  • If the function that made the call (the "caller") needs the value in one of these registers to be preserved across the call, it is the caller's responsibility to save it (e.g., push it to the stack) before making the call and restore it afterward.
  • X9-X15 are the primary temporary or "scratch" registers.

• Callee-Saved (Non-Volatile) Registers: X19 - X28

  • A callee function must ensure that these registers have the same value when it returns as they did when it was called.
  • If the callee needs to use one of these registers, it is the callee's responsibility to save the original value at the start of the function (in its prologue) and restore it just before returning (in its epilogue).

• Special Registers:

  • X29 (FP): Frame Pointer. It points to a fixed location within the current function's stack frame, allowing stable access to local variables even as the stack pointer moves.
  • X30 (LR): Link Register. Before branching to a function, the address of the instruction after the branch is placed in LR. The RET instruction uses this address to return to the caller.

From C to Assembly: The "Rosetta Stone"

The best way to understand the PCS is to see it in action. A great technique is to write a small, targeted C function and then look at the assembly code the compiler generates.

This video demonstrates this "Rosetta Stone" technique brilliantly.

Let's apply this ourselves. Consider this simple C function:

// C Code
#include <stdint.h>

uint64_t add_and_scale(uint64_t a, uint64_t b, uint64_t scale) {
    uint64_t temp_val = a + b;
    uint64_t result = temp_val * scale;
    return result;
}

If we compile this for AArch64 (e.g., using aarch64-linux-gnu-gcc -S), we get the following assembly:

// AArch64 Assembly
add_and_scale:
    // Function Prologue (none needed here as we don't use callee-saved registers)
    
    // Body
    add	x9, x0, x1    // temp_val = a + b. Arguments a and b are in x0 and x1.
                      // Result is stored in a caller-saved register x9.
    mul	x0, x9, x2    // result = temp_val * scale. Argument scale is in x2.
                      // The final result is placed in x0 for returning.
    
    // Function Epilogue
    ret               // Return to the address stored in the Link Register (LR/X30)

This simple example clearly shows:

1. The input arguments a, b, and scale are expected to be in registers x0, x1, and x2, respectively.
2. The calculation uses a temporary (caller-saved) register, x9.
3. The final result is placed in x0 just before returning.
4. The ret instruction performs the return.

Now, let's look at a slightly more complex example involving callee-saved registers and the stack.

// C Code
#include <stdint.h>

// A dummy function for us to call
extern uint64_t some_other_function(uint64_t);

uint64_t complex_function(uint64_t a, uint64_t b) {
    uint64_t persistent_value = a * 10;
    uint64_t sub_result = some_other_function(b);
    return persistent_value + sub_result;
}

The assembly for complex_function would look something like this:

// AArch64 Assembly
complex_function:
    // --- PROLOGUE ---
    // Save callee-saved registers we will use (x19) and the Link Register (x30)
    // to the stack. Also adjusts the stack pointer.
    stp x19, x30, [sp, #-16]!

    // --- BODY ---
    mov x19, x0          // Move argument 'a' (from x0) into a callee-saved register x19
                         // because we need its value AFTER the call to some_other_function.
    
    mov x0, x1           // Prepare the argument for some_other_function.
                         // Move 'b' (from x1) into x0.
    
    bl some_other_function // Call the function. x0-x18 might be changed. x19 is safe.
                         // The return address is saved in x30 (LR).

    // After the call, the return value of some_other_function is in x0.
    // The original 'a' is still safe in x19.
    mov x1, #10          // Load immediate value 10 into a temporary register.
    mul x19, x19, x1     // persistent_value = a * 10
    add x0, x19, x0      // result = persistent_value + sub_result
    
    // --- EPILOGUE ---
    // Restore the original values of x19 and the Link Register from the stack.
    // Adjusts the stack pointer back.
    ldp x19, x30, [sp], #16

    ret                  // Return

This example shows the full picture:

• Prologue: The function saves x19 (which it plans to use) and x30 (the Link Register, because it's making a call itself) to the stack. stp means "Store Pair" of registers.
• Callee-Saved Usage: It stores the value of a in x19 to protect it across the bl (Branch with Link) instruction.
• Epilogue: It restores x19 and x30 using ldp ("Load Pair") before returning.

Interview Corner

Your grasp of the procedure call standard is a direct indicator of your comfort with low-level coding and debugging. Expect questions like these:

Q1: You're debugging a C function. You have a local variable that holds an important value. After you call a library function, your local variable's value is corrupted. What is the likely cause?
A: The compiler likely allocated that local variable to a caller-saved register (e.g., X9-X15). The library function, as the "callee," is permitted to overwrite these registers. When the library function returned, the original value was gone. This indicates the compiler didn't correctly save the value to the stack before the call, or the variable should have been allocated to a callee-saved register if its value needed to persist across the call.

Q2: What is the difference between the BL and RET instructions?
A: BL (Branch with Link) is used to call a function. It does two things: it stores the address of the next instruction into the Link Register (X30/LR), and then it branches to the target function's address. RET is used to return from a function. It simply branches to the address stored in the Link Register, effectively returning control to the caller.

Q3: According to the AAPCS64, for a function uint32_t foo(uint64_t a, uint32_t b), which registers are used to pass in a and b, and to return the result?
A: a is a 64-bit value, so it will be passed in X0. b is a 32-bit value and the second argument, so it will be passed in W1. The function returns a 32-bit value, so the result will be in W0. (This question is adapted from the LINK resource).

Conclusion

You've now connected high-level C/C++ function calls to the low-level machine instructions that execute them. This knowledge is not just academic; it's a practical tool for debugging tricky bugs, optimizing performance-critical code, and writing robust software that interfaces with assembly.

Key Takeaways:

• The AAPCS64 is the contract that enables function interoperability in AArch64.
• Arguments are passed in X0-X7, and the return value is in X0.
• Caller-saved registers (X0-X18) are volatile and can be freely modified by a callee.
• Callee-saved registers (X19-X28) are non-volatile, and their values must be preserved by a callee.
• The function prologue saves necessary registers; the epilogue restores them.
• The Link Register (X30) is crucial for storing the return address.

Next Lesson Preview:
This lesson concludes our module on advanced ARM architectures. We have moved from the high-level exception model down to the instruction-by-instruction flow of a function call.

In our next module, "Multi-Core Programming Concepts," we will broaden our scope again. We'll move beyond the world of a single CPU core and explore the challenges and strategies involved in making multiple cores work together. Our first lesson will be to contrast Symmetric Multiprocessing (SMP) and Asymmetric Multiprocessing (AMP) architectures, which are foundational designs for the multi-core SoCs you see in complex automotive systems today.