Parameter Passing

At first glance, passing a parameter to a function is one of the most elementary operations in programming—a simple handoff of data. Yet, this simple act is governed by a profound and complex set of rules known as the Application Binary Interface (ABI). This unseen contract is the foundation upon which cooperative, efficient, and secure software is built, but its intricacies and consequences are often overlooked. This article lifts the veil on these critical conventions, exploring how they work and why they matter so deeply.

We will first dissect the core ​​Principles and Mechanisms​​ of parameter passing, examining the fundamental trade-offs between CPU registers and the memory stack, the etiquette of register usage, and the clever strategies for handling complex data. Following this, the article broadens its focus to ​​Applications and Interdisciplinary Connections​​, revealing how these low-level rules have a monumental impact on everything from software speed and compiler optimizations to the very features of our programming languages and the security architecture of our operating systems. This journey begins by exploring the "social contract" that allows functions to communicate in the first place.

Imagine two brilliant watchmakers working together in a workshop. To build a complex timepiece, they can't just randomly hand each other gears and springs. They need a system, a shared understanding of how to pass components, which tools are personal, and which can be borrowed. If one watchmaker needs a tiny screw, does she ask for it directly, or does the other leave it on a designated tray? If she borrows a special wrench, is she expected to return it to its exact original spot?

This is precisely the challenge that functions face inside a running program. A function is a self-contained unit of code, a specialist. For any non-trivial program to work, these specialists must communicate—they must call each other, pass data back and forth, and share resources. The set of rules governing this intricate dance is known as the ​​Application Binary Interface (ABI)​​, and at its heart lies the mechanism of ​​parameter passing​​. The ABI is not a law of physics dictated by the silicon of the processor; it is a meticulously crafted "social contract" that allows software compiled by different people, at different times, to cooperate flawlessly.

At the most fundamental level, a function has two ways to receive information from its caller: through the main memory (via the ​​stack​​) or through the CPU's own high-speed storage (the ​​registers​​).

The stack is a simple, robust, and universal solution. It's a region of memory organized like a stack of plates—you can push new items onto the top or pop the top item off. To call a function, the caller can push the arguments onto the stack one by one. The callee can then read them from that known location. It's like leaving notes on a shared whiteboard. It always works, but it's slow. Accessing memory is orders of magnitude slower than accessing data that's already inside the CPU.

A far more efficient method is to use the CPU's ​​registers​​. Registers are a small number of extremely fast storage locations built directly into the processor's core. Passing parameters in registers is like a direct conversation—the caller places a value in a register, and the callee can use it almost instantaneously. This avoids the slow round-trip to main memory, dramatically improving performance. As a thought experiment demonstrates, replacing stack-based passing with register-based passing eliminates entire streams of memory load-and-store operations, reducing traffic within the processor's data caches and freeing up critical execution resources.

Naturally, modern ABIs lean heavily on registers. But there's a catch: registers are a scarce resource. A typical 64-bit architecture might only have a handful designated for passing arguments. This leads to the first major principle of any calling convention.

Most ABIs, like the common ​​x86_64 System V ABI​​ used by Linux and macOS, adopt a simple and elegant hybrid approach. They designate a specific sequence of registers for passing the first few arguments. For integer and pointer arguments, the first six are passed in the registers RDI, RSI, RDX, RCX, R8, and R9. If a function has more than six integer arguments, the seventh and subsequent ones "spill" onto the stack.

But what if the arguments are of different types? The ABI is even more clever here. It establishes different ​​register classes​​. For instance, the x86_64 System V ABI has a separate pool of registers (XMM0 through XMM7) for floating-point (or double) arguments. The arguments are processed from left to right, and each is assigned to the next available register of its class.

Consider a hypothetical function g(double, long, double, long, ...). The first argument (a double) goes into XMM0. The second (a long) goes into RDI. The third (double) goes into XMM1, the fourth (long) into RSI, and so on. The integer and floating-point arguments fill their respective register pools independently. The first argument to be passed on the stack is the one that exhausts its class's register pool first. In this case, since there are only 6 integer argument registers but 8 floating-point ones, the 7th integer argument (the 14th argument overall) would be the first to go on the stack.

This system is a beautiful trade-off, prioritizing the speed of registers for the most common cases (functions with few arguments) while providing the unlimited capacity of the stack as a fallback.

Passing a simple integer or a pointer is straightforward—it fits neatly into a single register. But what about a complex data structure, a struct containing multiple fields?

Here, the ABI must make another pragmatic decision, often based on size.

• ​​Pass-by-Value:​​ If the structure is small enough—say, it fits into one or two registers—the ABI may opt to copy the entire structure's contents directly into the argument registers. This is efficient for small aggregates. The definition of "small" is architecture-dependent; an 8-byte struct might require two 32-bit registers on a 32-bit RISC-V CPU but only one 64-bit register on a 64-bit one, showing how the ABI is tailored to the hardware's native word size.

• ​​Pass-by-Reference:​​ If the structure is large, copying it would be expensive and would consume too many precious argument registers. In this case, the ABI mandates passing the structure ​​by reference​​. The caller allocates the structure in its own memory, and instead of passing the whole thing, it passes a single, simple argument: a ​​pointer​​ to the structure's memory location. The callee then uses this pointer to access the original data. This is like handing over a key to a room instead of trying to carry all the furniture inside it.

The same logic applies when a function needs to return a large structure. It's too big for the single return-value register (like RAX). The solution is a clever inversion of passing by reference, often called ​​structure return via hidden pointer​​ (sret). Before the call, the caller reserves space for the return value on its own stack. It then passes a secret, implicit first argument: a pointer to this empty space. The callee performs its work and, instead of trying to return the large object, it simply writes the result directly into the memory location provided by the caller.

This reveals a subtle but beautiful interaction with another ABI rule: ​​stack alignment​​. To ensure performance, ABIs often require the stack pointer to be aligned to a 16-byte boundary before any call instruction. If a caller needs to reserve space for a 24-byte return structure, it can't just subtract 24 from the stack pointer, as that would likely break the 16-byte alignment. It must allocate the next-largest multiple of 16, which is 32 bytes, leaving 8 bytes of unused padding. This is a perfect example of how different, seemingly unrelated rules within the ABI conspire to maintain an orderly and efficient system.

We've established that registers are a shared resource. This raises a crucial question of etiquette: if a callee uses a register, is it responsible for restoring the register's original value before it returns? The answer divides registers into two philosophical camps: ​​caller-saved​​ and ​​callee-saved​​.

• ​​Caller-Saved Registers:​​ These are "scratch" or "volatile" registers. The callee is free to use them for any purpose without saving their contents. If the caller has an important value in one of these registers that it needs after the call, it is the caller's responsibility to save it (typically to the stack) before the call and restore it afterward. Argument-passing registers (RDI, RSI, etc.) are almost always caller-saved. This convention is highly efficient for ​​leaf functions​​—simple functions that don't call any others. A leaf function gets a free set of scratch registers to do its work with zero overhead for saving and restoring.

• ​​Callee-Saved Registers:​​ These are "non-volatile" or "preserved" registers. The ABI guarantees to the caller that the values in these registers will be the same after a function call as they were before. This places the burden on the ​​callee​​. If a callee needs to use a callee-saved register, it must first save the original value and meticulously restore it before returning. This is a boon for ​​non-leaf functions​​, especially those that call other functions inside a loop. They can keep important, long-lived variables (like loop counters or pointers) in callee-saved registers, confident that the values will survive the calls.

A well-designed ABI strikes a careful balance. Having too many callee-saved registers would burden every simple leaf function with save/restore overhead. Having too many caller-saved registers would force complex functions to constantly save and restore their state around every call. The typical split—a larger number of caller-saved registers and a smaller number of callee-saved ones—is a finely-tuned compromise that optimizes for the common statistical properties of real-world programs.

The beauty of the ABI is most apparent when its rules interact in non-obvious ways, revealing the deep thought behind their design.

One fascinating example is the ​​red zone​​ in the x86_64 System V ABI. This rule states that a 128-byte area below the current stack pointer is reserved for a leaf function to use as scratch space, without the need to formally allocate a stack frame by moving the stack pointer. It's a "gentlemen's agreement" that optimizes for the simplest functions. In user-mode, the operating system honors this agreement; if a hardware interrupt occurs, the OS ensures that it does not trample on the red zone. However, this agreement does not extend to the OS kernel itself. If an interrupt occurs while the CPU is already in kernel mode, the hardware might automatically push status information directly into that memory area, corrupting whatever the kernel function had stored there. The red zone thus beautifully illustrates that the ABI is a layered contract, with different rules and guarantees applying at different levels of the system.

Perhaps the ultimate test of the ABI is the ​​variadic function​​, like C's printf, which can take a variable number of arguments. Consider a variadic function F that receives its arguments in registers x0, x1, ... and then needs to call another function G. To call G, F must use those very same registers (x0, x1, ...) to pass arguments to G. But because those are caller-saved registers, the call to G will destroy the original arguments passed to F! The ABI provides a robust solution: before calling G, function F must save all of its potential incoming argument registers into a contiguous block on its own stack. This "homing" of the arguments ensures they are preserved and can be accessed later, perfectly demonstrating how the rules of register classes, caller-saved etiquette, and stack management interlock to enable even the most complex conversational patterns between functions.

The art of passing a parameter to a function seems, at first glance, to be one of the most elementary operations in programming. It is the simple act of handing a piece of information from one part of a program to another. Yet, beneath this apparent simplicity lies a world of profound consequences, governed by a set of rigid, meticulously defined rules known as the Application Binary Interface, or ABI. This contract, specifying exactly how and where arguments are placed—in what registers, in what order, on what part of the memory stack—is not merely a technical detail. It is the silent, unseen machinery that dictates the speed of our software, enables the features of our programming languages, and enforces the security of our operating systems. To understand the applications of parameter passing is to embark on a journey through the very heart of computer science, revealing a beautiful unity across performance engineering, compiler design, and system architecture.

In computation, the ultimate currency is time. Every nanosecond counts, and the ABI is one of the chief accountants. The most direct economic transaction it governs is the choice between using a processor's registers and its main memory. Registers are the processor's personal scratchpad—blisteringly fast, but scarce. Memory is vast, but accessing it is like taking a long walk to a library instead of using a note on your desk. The ABI dictates that the first few arguments to a function get the privilege of traveling in registers. But what happens when you have too many?

Imagine a function in a high-performance scientific library that needs to juggle more arguments than there are available registers. For example, a modern graphics routine might need to operate on a dozen 128-bit vectors at once, while the ABI—like the System V AMD64 ABI—reserves only eight dedicated SIMD registers for this purpose. The moment the ninth vector argument is added, a performance "cliff" is reached. The compiler has no choice but to "spill" the excess arguments onto the stack, a region of main memory. Each spilled argument now incurs the cost of a memory write by the caller and a memory read by the callee, adding significant cycle overhead compared to a register. This isn't an abstract cost; it is a measurable slowdown, a direct consequence of the parameter passing contract.

This rigid rule inspires incredible ingenuity in compiler design. If you cannot change the ABI, perhaps you can change the parameters themselves. Consider a function that accepts a single, complex structure containing many small data fields. The ABI might stipulate that structures, being aggregates, must be passed by reference—that is, by passing a single pointer in a register. The function then has to perform a series of memory loads to access each field through that pointer. A clever compiler optimization called Scalar Replacement of Aggregates (SRA) performs a kind of conceptual alchemy. It "dissolves" the structure into its constituent scalar fields before the function call. Suddenly, what was one pointer argument becomes several integer or float arguments. If these new scalar arguments, along with any others, still fit within the register budget, they can now be passed directly in registers. The optimization's sole purpose is to transform the data to better fit the constraints of the parameter passing contract, beautifully illustrating how high-level optimizations are driven by low-level ABI realities.

The stakes become even higher when we expand our view from a single computer to a massive supercomputer. In a shared-memory system, passing a gigantic array to a function is trivial; you simply pass a pointer, a single 8-byte value, and the cost is a few nanoseconds. But in a distributed-memory system, where the function runs on a different physical machine, "passing the parameter" becomes a Remote Procedure Call (RPC). The entire array must be copied, serialized into a stream of bytes, and sent across a network. Here, the cost is dominated by network latency ($\alpha$) and bandwidth ($\beta$), and can be millions of times more expensive. The physical architecture of the system has fundamentally redefined the meaning and cost of parameter passing.

The parameter passing contract is not just an accountant; it is also a grammarian, defining the rules that make sophisticated language features possible. One of the most elegant concepts in computer science is tail recursion, where a function's final act is a call to itself. With the right optimization—Tail Call Elimination (TCE)—an infinite recursion can execute in a finite, constant amount of memory. But this "magic" depends entirely on the ABI.

Imagine a function F that has received its arguments, some in registers and three on the stack. As its last act, it needs to tail-call another function G, which requires six arguments on the stack. For the tail call to work, F must set up G's arguments and then jump directly to G's code, so that when G finishes, it returns to F's original caller. But here lies the problem: G needs more stack space for its arguments than F was given. The ABI's stack discipline is strict; F is a guest in its caller's stack frame and is forbidden from writing beyond its own allotted argument space. Furthermore, the ABI specifies that the original caller is responsible for cleaning up the three stack arguments it passed to F. If F were to somehow allocate more space for G, the stack would become unbalanced when G eventually returns. The tail call is ineligible. The rigid contract, designed for predictable behavior, has precluded a powerful optimization.

So, how can a language guarantee tail recursion? It must adopt an ABI designed for it from the ground up. Such an ABI might forbid functions from allocating variable-sized stack frames, instead providing a fixed-size "scratch space" for any given call. In this world, a tail call reuses the existing scratch space. The stack pointer never moves, and recursion can proceed indefinitely. Another approach is an ABI that relies entirely on registers for arguments and forbids stack allocation for variables altogether. Features we desire in our high-level languages are not abstract wishes; they are built upon a foundation of a carefully negotiated low-level contract.

This interplay is just as crucial for other language features, like closures—functions that "capture" variables from their surrounding environment. When you pass a closure as an argument, you are passing not just a piece of code, but also its memories. This "environment" must be passed as a hidden parameter. But how do you do this if you need your language to interoperate with C, which knows nothing of closures? The C ABI has no provision for this hidden environment pointer. A brilliant and common solution is to co-opt one of the processor's general-purpose registers—one that the C ABI designates as "caller-saved"—to serve as a private channel for the environment pointer. Calls within the new language use this register; calls to C simply don't. A thin "trampoline" wrapper can make a closure look like a normal C function pointer. The parameter passing convention becomes a bridge, allowing two different language paradigms to coexist and communicate.

The ABI must also co-evolve with hardware. The Arm Scalable Vector Extension (SVE) introduced vectors whose size is not known at compile time, enabling "vector-length agnostic" programming. How can you pass a parameter whose size you don't even know? You can't put it on the stack, as you don't know how much space to reserve. The only solution is an ABI that passes these scalable types in the new, scalable registers. The calling convention itself becomes the key to unlocking the hardware's potential.

Beyond speed and semantics, the parameter passing mechanism is a cornerstone of a system's security and overall architecture. It is the formal ceremony for crossing boundaries of trust.

In an operating system, a user process might possess a file descriptor—an integer, say, 3. If the process simply writes the number 3 to another process, the receiver gets an integer, nothing more. It's just data. But if the sender uses a special kernel-mediated Inter-Process Communication (IPC) mechanism like sendmsg with a control message of type SCM_RIGHTS, something magical happens. The kernel interprets this not as passing a number, but as a request to transfer a capability. The kernel grants the receiving process its own file descriptor that points to the same underlying open file. The parameter passing mechanism has become a vehicle for securely transferring access rights. This is further enhanced with messages like SCM_CREDENTIALS, where the kernel, not the user, attaches the sender's authenticated credentials (like its process ID and user ID) to a message. The receiver can trust these credentials because the parameter passing mechanism itself is guaranteed by the most trusted entity in the system: the kernel.

The ceremony becomes even more formal when crossing from the "normal world" of user applications into a "secure world," a trusted execution environment on the processor. On an Arm processor, this is done via a Secure Monitor Call (SMC) instruction, which has its own, distinct calling convention (the SMCCC). A programmer writing a wrapper for an SMC call must act as a master diplomat, navigating three sets of rules at once: the C language ABI (AAPCS), the secure call ABI (SMCCC), and the compiler's inline assembly semantics. The wrapper must carefully place arguments in the registers expected by the secure world, execute the SMC instruction, and then collect the results from the registers where the secure world places them. It must also declare to the compiler exactly which registers might be "clobbered" or altered during this trip to another world. Here, parameter passing is a secure, delicate handshake between two different domains of trust.

This idea can be scaled up to design an entire operating system. In a traditional, monolithic kernel, a system call involves the user process passing pointers into the kernel. The kernel then dereferences these pointers to access the user's data. This creates a dangerous intimacy, opening the door to security flaws like Time-of-Check-to-Time-of-Use (TOCTOU) races, where a malicious process can alter the data after the kernel has checked it but before it has used it.

In contrast, a microkernel architecture treats services as separate processes communicating via messages. When a client wants a service, it doesn't pass pointers. Instead, it serializes all its parameters—creating a full copy of the data—into a message. This message is an self-contained, explicit contract, often with version numbers and explicit lengths. This design has profound advantages. By operating on a copy of the data, the server is completely insulated from TOCTOU attacks. By enforcing an explicit, versioned message format, the system becomes more robust and evolvable. The "parameter list" of a function call has been elevated to a formal, serialized protocol between independent programs. The principles of safe parameter passing, when applied at a system-wide scale, lead to a fundamentally more secure and modular architecture.

From the smallest choice of register versus stack to the grand architecture of an entire operating system, the simple act of passing a parameter is revealed to be a deep and unifying principle. It is a contract that binds hardware to software, shaping what is fast, what is possible, and what is safe. It is a testament to the beauty of computer science, where a single, simple idea can ripple outwards with such immense and intricate consequences.