the calling convention

Two people can only hand work back and forth smoothly if they agree on the protocol: where to leave the inbox, who tidies up afterwards, how to label the output. The calling convention is exactly that agreed protocol for function calls, written down so that any two pieces of code, even compiled by different tools years apart, can call each other and get it right. It is part of a larger agreement called the ABI (application binary interface).

A calling convention pins down the practical questions. Which registers carry the first few arguments (on RISC-V, a0 through a7)? Which register holds the return value (a0, and a1 for a second one)? Which registers must a called function leave untouched (callee-saved) versus which can it freely clobber (caller-saved)? How is the stack aligned, and which register is the stack pointer? When arguments don't fit in registers, where do the extras go on the stack? None of these answers is dictated by the hardware; they are choices, but once fixed for a platform everyone must follow them.

The calling convention matters because it is the glue of a software ecosystem. It is why your program can call a library someone else wrote and shipped only as machine code, why a C program can call a routine written in assembly, and why operating systems and applications interoperate. Break the convention, even subtly, and calls between separately compiled pieces corrupt registers or the stack in ways that are maddening to debug. Compilers follow it automatically; humans writing assembly must follow it by hand, which is one of the easiest places to make a quiet, devastating mistake.