the calling convention

Imagine two people who must hand work back and forth but never meet to agree on the rules: one prepares a parcel, the other unpacks it. If they do not share a fixed protocol — where the parcel goes, who carries it, who cleans up — the handoff fails. A calling convention is exactly that shared protocol for calling a function: the precise rules for how arguments are passed, where the return value comes back, and who is responsible for which registers across the call.

The convention nails down several things. How arguments are passed: the first few typically go in specific registers, and only extra ones spill onto the stack. On the common x86-64 System V convention (Linux, macOS), the first six integer arguments go in rdi, rsi, rdx, rcx, r8, r9, in that order, and the integer return value comes back in rax. It also fixes register responsibility (caller-saved versus callee-saved), the alignment the stack must have at a call, and small extras like the red zone — a 128-byte area just past the stack top that a leaf function may scribble in without adjusting rsp. The convention is one part of the larger ABI, the application binary interface, that also covers how types are laid out and how the executable is structured.

The whole point is that separately compiled pieces — your code, a library, the C runtime — agree on these rules so they interoperate without ever seeing each other's source. It is what lets a function written in one language call one written in another, and what lets you link against a prebuilt library. Break the convention (say, with a wrong function-pointer signature) and you get corruption, not a clean error, because each side is reading and writing registers and stack slots the other side never agreed to.