Talk:Calling convention

AMD64 / x86_64

This article lists some uncommon architecture but the probably second most used architecture (after ARM when counting phones) is missing.

46.5.255.82 (talk) 22:41, 11 March 2022 (UTC)

I added a section that mostly relies on x86 calling conventions#x86-64 calling conventions (just as the section on 32-bit x86 relies on x86 calling conventions). Guy Harris (talk) 06:58, 20 December 2022 (UTC)

"Volatile" registers

@Chumpih:: Unless I'm missing something, it appears that there are multiple terms for the same types of registers. Microsoft's "Overview of x64 ABI conventions" page says that

Volatile registers are scratch registers presumed by the caller to be destroyed across a call. Nonvolatile registers are required to retain their values across a function call and must be saved by the callee if used.

and the "Caller/callee saved registers" section of Microsoft's "x64 calling convention" page also uses the terms "volatile" and "non-volatile".

So it appears that "volatile" and "caller-save" mean the same thing, and "non-volatile" and "callee-save" mean the same thing, if "caller-save" means "if the caller needs the value in this register after a procedure call returns, it must save it before the procedure call and restore it after the call", not "the caller must save and restore this register across procedure calls even if the value in that register is dead at the point where the procedure call is made".

The terms I was used to are "caller-save" and "callee-save"; perhaps "volatile" and "non-volatile" were picked because they avoid the problem of "so does 'caller-save' mean I have to save and restore it even if I don't need it?", but they don't avoid the problem of "'volatile' is used with multiple other meanings, so which of them is intended here?" then

Note that, if "volatile" means "not preserved by a call", then

If there is more than one calling sequence for a given architecture, they may differ in:

• Conventions on which registers may be directly used by the callee, without being preserved
• Which registers are considered to be volatile and, if volatile, need not be restored by the callee

is a bit redundant. It's also not clear why it says "and, if volatile, need not be restored by the callee" - at least as I see it, "not preserved by a call" implies "not required to be saved by or restored by the callee if it modifies the register", so I'd expect that all volatile registers need not be restored by the callee. Guy Harris (talk) 06:52, 4 January 2023 (UTC)

Thank you @Guy Harris: for this clear explanation of this use of the term volatile. It would seem that volatile in this context is also mentioned in RISC-V calling convention, although only once. Preserve likewise gets a single mention. RISC-V prefers the word save. But de gustibus - we should make it obvious that the different terminology resolves on to clear concepts.

As you identify, the section If there is more than one calling sequence ... without being prserved ... if volatile does indeed seem pleonastic, since volatile == not preserved. But IMHO that section in its entirety is concerning, since several other differentiators listed above do appear in calling conventions within the same architecture. There is already a paragraph 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... which perhaps covers this concept of different calling conventions within the same architecure. Many of the differentiators can appear within the same OS: far pascal is differs from cdecl in many ways.

So perhaps an appropriate way forward is have additional bullets in the existing list, along the lines of: :* Which registers get saved buy the caller, and which saved by the callee.

• which registers are not preserved, and therefore considered volatile and available for free use by the callee

and remove the paragraph If there is more than one calling sequence.... What do you reckon? Chumpih ^t 21:30, 4 January 2023 (UTC)

I see the types of registers being:

1. registers that the callee must ensure that, when it returns, the register has the value that it had when the callee received control;
2. all other registers, which the caller cannot assume will have the same value when the callee returns that it had when the callee received control.

The callee does not need to save or restore the values of registers of the second type. It must save and restore the values of registers of the first type if and only if it modifies them, so that's "callee-save", but not "callee must save".

The caller does not need to save or restore the value of registers of the first type across a call. It must save and restore the value of registers of the second type if and only if it needs the original value of that register after the callee returns and it's not stored anywhere else, so that's "caller-save", but not "caller must save".

So the types are:

1. "callee-must-save-if-it-modifies-it", which is what "callee-save" presumably is intended to mean;
2. "caller-must-save-if-it-cares", which is what "caller-save" presumably is intended to mean;

with the second type being "volatile".

I.e., caller-save register is volatile and a callee-save register isn't, so only one bullet point:

• which registers are guaranteed to have the same value when the callee returns as they did when the callee was called;

is necessary.

And, yes, that bullet point should be in the "Calling conventions may differ in" list, and the "If there is more than one calling sequence for a given architecture, they may differ in" item, and its list, whould be removed. Guy Harris (talk) 10:43, 5 January 2023 (UTC)

Sounds good. Less is more, etc. Changes made. Chumpih ^t 18:45, 5 January 2023 (UTC)

Server / Routing level calling conventions

I got to this page from WSGI, which describes itself as well as CGI, FastCGI, etc. etc as calling conventions.

these seem somewhat distinct from the lower/compiler level calling conventions described in this page, as they they're somewhat higher level, mapping routes to functions rather than dealing with registers and the actual stack. However, they still deal with how to pass input to functions, what output should be expected and parsed.

I don't actually know enough about the subject to say for sure, but perhaps a section could be added in this article, or a separate article made on these kinds of calling conventions? 31.193.185.15 (talk) 14:24, 6 April 2023 (UTC)

Unsure if it's appropriate to call the mechanism for remote invocation a 'calling convention'. Microsoft referred to the address-binding-contract in WCF, and there's the notion of marshalling for data in other phraseologies. There's a bunch of stuff over at Remote procedure call, with dozens of related terms for different languages and frameworks, but 'calling convention' is conspicuous by its absence. Chumpih ^t 18:03, 6 April 2023 (UTC)

Languages

Originally this article was only about various architectures. With the edit of 15:00, 23 April 2018‎ (UTC), an IP user created a section on Threaded code. Later a section was added on PL/I and these two were made subsections of "Calling conventions outside machine architectures". Now it is time to do it right. "Calling conventions outside machine architectures" should be renamed "Languages", which pairs with "Architectures". Languages should start with Fortran and should include at least Pascal and C. Fortran is important because it was first and influenced everything else. Pascal is important because it emphasizes the distinction between pass by value and pass by reference and makes both available. C is important because so much is written in C and its variants, and for other reasons. Perhaps ALGOL, COBOL, Forth, Lisp and APL also need sections, but having PL/I as the only actual programming language is wrong. —Anomalocaris (talk) 07:49, 27 June 2023 (UTC)

The opening paragraph says

In computer science, a calling convention is an implementation-level (low-level) scheme for how subroutines or functions receive parameters from their caller and how they return a result.

"Are arguments passed by name, by value, or by reference?" is, to some degree, a matter of the language specification rather than of a low-level scheme. In C, all arguments are passed by value (pass-by-reference is done by passing a pointer to a data element), so that's not a low-level question implementation question.

So either "call by name, by value, or by reference" belongs here, or the lede shouldn't claim that a calling convention is just an implementation-level scheme. What do various reliable sources say about what a calling convention is? Guy Harris (talk) 19:29, 27 June 2023 (UTC)

Renaming to some Languages section seems sensible. I suspect the choice of languages should be at least partially driven by what is currently popular. (There are several programming language popularity resources that can help, although they clearly don't use consistent methodologies and therefore only partially agree.) Your suggestion of choice by legacy definitely has merit. It may also make sense to group languages, or have one language refer to another: C and C++ have many similarities, as do Java and C#.

For some compile-to-native languages, the calling convention will often follow those of the target platform, unless overridden. For compile-to-vm, there will be more consistency, but calls to native will be interesting.

So I reckon partial support, and let each language's section stand or fall by the quality, significance and relevance of the content therein. It's OK if we're not comprehensive here. Chumpih ^t 05:37, 28 June 2023 (UTC)

The source you added indicates says that

A calling convention governs how functions on a particular architecture and operating system interact. This includes rules about includes how function arguments are placed, where return values go, what registers functions may use, how they may allocate local variables, and so forth. Calling conventions ensure that functions compiled by different compilers can interoperate, and they ensure that operating systems can run code from different programming languages and compilers. Some aspects of a calling convention are derived from the instruction set itself, but some are conventional, meaning decided upon by people (for instance, at a convention).

Calling conventions constrain both callers and callees. A caller is a function that calls another function; a callee is a function that was called. The currently-executing function is a callee, but not a caller.

although it links "calling convention" to... this article, so that runs the risk of this turning into a case of citogenesis. A reference that doesn't point to Wikipedia (and maybe even predates Wikipedia) would be preferable, to make it less likely that they're saying "it's about low-level details" because the Wikipedia article about calling conventions says it's about low-level details.

But if we do find such references, that means that issues such as call by name vs. call by value vs. call by reference (whether a "reference" to an array is a pointer or a dope vector containing array bounds) vs. ... aren't part of a calling convention (they're part of the language specification). A platform's calling sequence may specify how those forms of argument passing are implemented on the architecture in question, but they don't dictate which form should be used - the language specification dictates that.

The evaluation strategy page discusses various forms of call-by-XXX (although its lede points to this page, which perhaps it shouldn't). Guy Harris (talk) 07:18, 28 June 2023 (UTC)

Take your point re. the risk of citogenesis - perhaps it's permissible here given that the source page is from a reliable academic institute. The Evaluation strategy page is really good stuff, but it's debateable if 'calling convention' applies as richly to those languages that would permit parameter passing by name, with lazy evaluation. Sure, if we view this as part of computer science, through the lens SICP etc, then the imperative languages are part of a larger mathematical endeavour that yields computation, and a calling convention should fit within that taxonomy. But then again, there's the more practical, engineering aspect with 'convention' and choice of registers or stack, etc. and this is independent of the taxonomy. This page should (and currently does) make reference to evaluation strategy and identifies it as a related though different concept, which seems about right. It's reasonable likewise for evaluation strategy to link to here, although the current 6-word sentence at the end of the lede there isn't super helpful IMHO, and it's rightly tagged for further clarification. I'm still OK with Anomalocaris's suggestion of renaming the outside architectures section to Languages, and for those languages that support lazy evaluation, etc, references to evaluation strategy would be very appropriate. Chumpih ^t 08:10, 30 June 2023 (UTC)