Lably
Skip to content

Calling convention

Mechanism of function calls in computers

  • 18 min read
  • 3 chapters

Related on Lably

Through Computer science, Function (computer programming) and Parameter (computer programming)

Lab · Class 10–11NLP PipelinesLab · Class 6–12AI & Python Builds (Medha AI)Lab · Class 6–12Data Visualization LabLab · Class 11Binary and Logic Gates

Introduction

Calling conventions are usually considered part of the application binary interface (ABI). They may be considered a contract between the caller and the called function.

The names or meanings of the parameters and return values are defined in the application programming interface (API, as opposed to ABI), which is a separate though related concept to ABI and calling convention. The names of members within passed structures and objects would also be considered part of the API, and not ABI. Sometimes APIs do include keywords to specify the calling convention for functions.

Calling conventions do not typically include information on handling lifespan of dynamically allocated structures and objects. Other supplementary documentation may state where the responsibility for freeing up allocated memory lies.

Calling conventions are unlikely to specify the layout of items within structures and objects, such as byte ordering or structure packing.

For some languages, the calling convention includes details of error or exception handling, (e.g. Go, Java) and for others, it does not (e.g. C++).

For remote procedure calls, there is an analogous concept called Marshalling.

Calling conventions may be related to a particular programming language's evaluation strategy, but most often are not considered part of it (or vice versa), as the evaluation strategy is usually defined on a higher abstraction level and seen as a part of the language rather than as a low-level implementation detail of a particular language's compiler.

Different calling conventions

Calling conventions may differ in:

  • Where parameters are placed. Options include registers, on the call stack, a mix of both, or in other memory structures.
  • The order in which parameters are passed. Options include left-to-right order, or right-to-left, or something more complex.
  • How functions that take a variable number of arguments (variadic functions) are handled. Options include just passed in order (presuming the first parameter is in an obvious position) or the variable parts in an array.
  • How return values are delivered from the callee back to the caller. Options include on the stack, in a register, or reference to something allocated on the heap.
  • How long or complex values are handled, perhaps by splitting across multiple registers, within the stack frame, or with reference to memory.
  • Which registers are guaranteed to have the same value when the callee returns as they did when the callee was called. These registers are said to be saved or preserved, so they are not volatile.
  • How the task of setting up for and cleaning up after a function call is divided between the caller and the callee. In particular, how the stack frame is restored so the caller may continue after the callee has finished.
  • Whether and how metadata describing the arguments is passed
  • Where the previous value of the frame pointer is stored, which is used to restore the stack frame when the subroutine ends. Options include within the call stack, or in a specific register. Sometimes frame pointers are not used at all.
  • Where any static scope links for the routine's non-local data access are placed (typically at one or more positions in the stack frame, but sometimes in a general register, or, for some architectures, in special-purpose registers)
  • For object-oriented languages, how the function's object is referenced

Calling conventions within one platform

Sometimes multiple calling conventions appear on a single platform; a given platform and language implementation may offer a choice of calling conventions. Reasons for this include performance, adaptation of conventions of other popular languages, and restrictions or conventions imposed by various computing platforms.

Many architectures only have one widely used calling convention, often suggested by the architect. For RISCs including SPARC, MIPS, and RISC-V, registers names based on this calling convention are often used. For example, MIPS registers $4 through $7 have "ABI names" $a0 through $a3, reflecting their use for parameter passing in the standard calling convention. (RISC CPUs have many equivalent general-purpose registers so there's typically no hardware reason for giving them names other than numbers.)

The calling convention of a given program's language may differ from the calling convention of the underlying platform, OS, or of some library being linked to. For example, on 32-bit Windows, operating system calls have the stdcall calling convention, whereas many C programs that run there use the cdecl calling convention. To accommodate these differences in calling convention, compilers often permit keywords that specify the calling convention for a given function. The function declarations will include additional platform-specific keywords that indicate the calling convention to be used. When handled correctly, the compiler will generate code to call functions in the appropriate manner.

Some languages allow the calling convention for a function to be explicitly specified with that function; other languages will have some calling convention but it will be hidden from the users of that language, and therefore will not typically be a consideration for the programmer.

Sign in to keep reading

2 more chapters are free with a Lably account.

More in Computing and communication

ISBNUnique numeric book identifier since 1970X (social network)American social networking serviceWayback MachineDigital archive by the Internet ArchivePython (programming language)General-purpose programming languageMacOSOperating system for Apple computersUnicodeCharacter encoding standard