Talk:Calling convention/Archive 1

Archive 1

Grammar

The grammar and punctuation of this page need serious work, and the content is disorganized and fairly confusing. Marking for cleanup. --bmills 18:24, 21 October 2005 (UTC)

Another type of fastcall convention

I've encountered a program that uses register calling convention that passes as many as FOUR parameters via registers (EAX,EDX,EBX,ECX). Does anyone know to which language/compiler does this concern? I have only an assembly with no evidence of compiler info :( --Ivan Pozdeev 08:09, 13 June 2006 (UTC)

This turned out to be Watcom's version of __fastcall
(oh my! one more meaning for the same keyword!) --Ivan Pozdeev 07:47, 14 June 2006 (UTC)

Safecall?

I've heard of a "safecall" calling convention before, but frankly, i dont know any of the details, or even if it is conceptually different from any of the other calling conventions. also, i havae no idea when/where it is used, and by which compilers. should i just delete that heading from the artical? --Whiteknight 15:54, 8 September 2005 (UTC)

My Delphi helpfile says that I must declare my routines with the "Safecall" convention if it is to support both compile time binding and runtime binding through COM automation. Not sure if this is used outside Delphi... --203.173.159.178 23:10, 27 June 2006 (UTC)

Other architectures?

What about SPARC/SPARC64? MIPS? PowerPC? Others? Should not this article be renamed into "Calling convention x86"?

I split the article and created section stubs for those other architectures. Allnamesinuse 23:32, 2 September 2006 (UTC)

To dos

I put up some quick information now, but i dont really have the time or all the know-how to fill out the article in it's entirety right now. here is a list of things that (as I see it) this article will need:

• translation to other ASM codes (i use only x86 architecture right now)
• examples using high-level languages (C/C++ for cdecl and stdcall, Pascal for pascal, don't new versions of Delphi use fastcall?)
• performance indices
• history of calling conventions, inventors, initial implementations, etc.

--Whiteknight 18:58, 25 Apr 2005 (UTC)

I also see the need for an explanation of various methods of implementing multiparameter functions. Despite statements to the contrary, I do not see how caller balanced stacks are better for such a task. What is frequently left out is how the called function knows how many parameters is on the stack, or more accurately accesses all of the parameters on the stack, not knowing beforhand how many are there. Hackwrench 01:51, 6 November 2005 (UTC)

To clarify BASIC uses callee stack balancing, but it has several internal functions that are muliparameter.

Not all returns are through registers. I noticed returning a structure seems to be using a pointer put on the stack from the caller. Other return methods such as this need to be added. -- para45

The MIPS section lacks any references to documents describing the calling conventions/ABI. — Preceding unsigned comment added by 62.159.77.166 (talk) 09:51, 18 April 2012 (UTC)

Article references WP

The first (and one of only two sources referenced) reference is to a Wikipedia article (Threaded_code#Subroutine_threading). Tsk, tsk... 213.243.164.59 (talk) 17:06, 20 May 2009 (UTC)

Yes, that is not an acceptable reference. I removed it. History2007 (talk) 08:20, 6 June 2012 (UTC)

Article quality

Article has missed the software boat by just looking at specific pieces of hardware. The issues related to call by name etc. are not even mentioned, although they are in Evaluation strategy. And there are other large chunks of errors. Article is neglected and should not be relied upon. History2007 (talk) 08:20, 6 June 2012 (UTC)

MIPS section contains strange instruction

"For multi-threaded code, the thread local storage pointer is typically stored in special hardware register $29 and is accessed by using the mfhw (move from hardware) instruction. At least one vendor is known to store this information in the $k0 register which is normally reserved for kernel use, but this is not standard."

I can't find this mfhw instruction anywhere. A Google search only shows results that copied the Wikipedia article. I can't imagine such an instruction is so unknown if it is indeed used for TLS, so either this is a typo, or no such instruction exists. — Preceding unsigned comment added by 178.203.192.191 (talk) 20:55, 23 July 2013 (UTC)

Huh

"This is somewhat related to a particular programming language's evaluation strategy but most often not considered part of it (or vice versa), as the latter is part of the language rather than the compiler and largely defined on a higher abstraction level." - this paragraph seems confusing. This, it, and the latter should probably be explicitly spelled out, and this sentence is dropped in with no further amplification. Peter Flass (talk) 22:11, 29 December 2014 (UTC)

You're right, it was somewhat confusing. Got it straightened out a bit, please check it out. — Dsimic (talk | contribs) 06:53, 30 December 2014 (UTC)

Sounds better now. I couldn't figure out what it was trying to say enough to attempt to fix it. Thanks. Peter Flass (talk) 12:55, 30 December 2014 (UTC)

You're welcome, and thank you for pointing it out! — Dsimic (talk | contribs) 14:48, 30 December 2014 (UTC)

IBM 1130 example

I added the 1130 example as a description of a completely different calling sequence than most modern architctures. I got to the end of the sample code and realized I had forgotten how to return if there were arguments. It seems the subroutine would have to add the argument count to the return address before returning. Is this correct? Probably should show the call also... Most of the sample code is cribbed from the IBM 1130 article. Peter Flass (talk) 05:25, 22 December 2014 (UTC)

Thank you, Peter Flass. --DavidCary (talk) 03:59, 3 January 2015 (UTC)

Other languages

anybody with knowledge on the calling conventions of other languages (as opposed to the focus on C and C++ in the artical as it currently stands) would be greatly appreciated. it is easy for people to forget that there are other common compiled languages besides C/C++: Pascal, Fortran, Ada, Delphi, etc... --Whiteknight 15:52, 8 September 2005 (UTC)

• Don't forget that object-oriented languages often have some rather special arrangement for reserving the (hidden) parameter usually known as this variable. Also, I know that Smalltalk cannot use stack to implement parameter passing; instead heap-based parameter passing technique would be required. Exactly how that is accomplished, I am not that familiar, as I haven't played with Smalltalk enough. So, there is a third way the parameters get passed. TheBlueWizard (talk) 03:57, 23 November 2010 (UTC)

This is another dimension besides platform. I agree that different languages should be added. I'm going to do PL/I. Peter Flass (talk) 00:29, 16 May 2016 (UTC)

Move registers

A lot of this article is talk about registers, not calling convention. I would suggest moving most of that to the articles of the respective architecture and transcluding it.159.100.126.214 (talk) 11:45, 11 September 2020 (UTC)

Registers are part of the calling convention on most machines. The relevant register details are:

• Is a register used to hold the stack pointer/frame pointer?
• Is a register used to hold the return address?
• Which registers must be saved and restored by the callee?
• Which registers are used for return values?

(Whether the caller saves registers is up to the caller; I'm not sure a distinction between "scratch" and "caller-save" registers is meaningful.) Guy Harris (talk) 22:52, 11 September 2020 (UTC)

Standard Entry and Exit sequences.

See also: Talk:Call stack § Return address alternatives

I'm wondering if the last section on standard entry and exit sequences would be better served by moving them to a separate artical on stack frames. any ideas? --Whiteknight 15:57, 8 September 2005 (UTC)

A separate article seems like a good idea. However, in my opinion it should really try to give a high-level picture, rather than going into miniscule details of a particular (not even typical) architecture (such as explaining which programming language constructs need a stack pointer, which need a frame pointer, which need the stack to be dynamically allocated etc.). --Mellum 16:56, 8 September 2005 (UTC)

Done. stack frame. --75.19.73.101 (talk) 07:00, 9 December 2007 (UTC)

Something has gone wrong. When I click on stack frame or function stack, I get redirected to the "call stack" article, which a few minutes ago claimed "Using a stack to save the return address has important advantages over alternatives."

What are those alternatives?

One comment on talk:call stack#alternatives points out that IBM Basic assembly language and successors#Examples gives one example of one such alternative, and suggests that this "calling convention" article would be a better place to mention those alternatives.

Alas, neither the "call stack" article nor the "calling convention" article nor the "Stack (abstract data type)" article mention any of these alternatives at the moment, nor do they mention the "closures" that were once mentioned in the "stack frame" article. How can we get that missing information back into the appropriate article(s)? --DavidCary (talk) 15:20, 17 December 2014 (UTC)

I might be missing something obvious, but things seems to be just fine. Calling convention article mentions and describes alternatives to the stack (registers, heap), while Call stack article also briefly describes calling conventions in its Call stack § Call site processing section:

The values for the actual arguments are evaluated at the call site, since they are specific to the particular call, and either pushed onto the stack or placed into registers, as determined by the calling convention being used.

Am I missing something? — Dsimic (talk | contribs) 19:54, 21 December 2014 (UTC)

This article does touch upon most of the right areas, it seems with a quick look, but perhaps is a little thin on description. Most all of the explanation is in the introduction, the rest of the article being specific examples. Probably it could use some general descriptions of various things in the article body before giving details of specific architectures. Might cover things like approaches to values vs references, register usage vs memory, e.g. stacks, at-code storage locations, at-call-site locations, leaf routines that use registers only, register spilling, ... So, I think it has a good start and some good examples, but could use enhancements.

BTW, a non-stack convention, which DavidCary mentioned earlier in this talk-page-split discussion, has an example already in this article -- the IBM 1130 section shows a convention like the similar contemporaneous S/360 one, using the first subroutine location for return address storage (the BSI instruction at the call site puts it there and the Branch Indirect ending the epilog branches through that location). This has the advantage of using only a single location for linking (params are also linked to via that cell), but lacks all the advantages given by stacks. --R. S. Shaw (talk) 05:45, 24 December 2014 (UTC)

Exactly, more generally-applicable explanations are required. The new Calling convention § Overview section I've split off might be a good candidate for receiving some new content. — Dsimic (talk | contribs) 19:25, 29 December 2014 (UTC)

Subroutine goes into some detail on call by reference/value/etc. Peter Flass (talk) 22:20, 29 December 2014 (UTC)

Am I missing something? Yes, we are missing something. I've heard that the "Calling convention article discusses the ways return addresses are passed around", and I also hear that "Using a stack to save the return address has important advantages over alternatives." What are those alternatives? We are missing those alternatives in this article.

A few days ago, none of the "alternatives" were mentioned. *Every* calling convention described in the calling convention article either (a) the caller directly pushed the return address on "the" stack, or (b) the caller puts the return address in some register (the MIPS $ra register, the ARM link register, etc.) and then the prologue of each (non-leaf) subroutine pushes that return address to "the" stack. Both (a) and (b) "use a stack to save the return address".

I'm glad that User: Peter Flass added the "IBM 1130" section to the "calling convention" article a few days ago. That addition gives one (1) alternative to using the data stack to save the return address.

The 1130 is not the only machine with a different calling sequence than the "push the return address on the data stack" approach of most modern architectures.

The subroutine article, as pointed out by Peter Flass, mentions that some early computers didn't have a "indirect jump"/"branch indirect" instruction, which is required for the IBM 1130 calling convention. That article mentions (2) another "way the return address is passed around" on such computers that is not yet mentioned in the "calling convention" article.

My understanding is that many (most?) implementations of "threaded code" and many (most?) embedded microcontrollers store the return address in a "return stack", a (3) hardware stack or (4) software stack, separate and independent from the "data stack" used to store local variables. The "calling convention" article doesn't mention the "separate stacks" idea either.

My understanding is that continuations seem to require (5) a cactus stack that is another alternative to a single linear stack. (Do coroutines and closure (computer programming) also require a cactus stack?)

So by my count that is 5 alternatives -- that I know of -- to the "push the return address on a linear data stack" approach. I suspect there are others. This article should mention all of those alternatives, but most of them are missing. --DavidCary (talk) 03:59, 3 January 2015 (UTC)

This is getting too complicated to reply individually. I (or someone) should do System/360, which is a different stack-less convention. As far as the indirect branch question, someone pointed me to the 1130 DM2 listings, and they used something like this

SUBR EQU *+2
    B *-*
 ... body of subroutine...
   B SUBR-1

i.e. the call stored the return address into a branch instruction, and the return branched to that. (syntax may be wildly incorrect, but the meaning should be clear) Peter Flass (talk) 17:03, 3 January 2015 (UTC)

This was relatively straightforward in the 1130 because it had a 2-word branch instruction where the second word was simply the target address for the branch, and thus could simply be overlaid by a store into that word. In very early machines, the designers didn't make much of any provision for subroutines, so that return linkage had to be accomplished by constructing the branch instruction more laborously, as by taking the return address and ORing (or adding) in the opcode for a branch and storing the result in memory to be executed. If interested, take a gander at the 1947 EDSAC's method here. However, this is so primitive that, while amusing, is not terribly enlightening and probably doesn't warrant mention in this WP article. --R. S. Shaw (talk) 07:10, 5 January 2015 (UTC)

The main alternative that over which a call stack has an advantage is "store the return address in a fixed address in memory", as used in, for the example, the IBM 1130, where the fixed location is the word just before the first instruction of the subroutine. "Save it in a register" can be combined with a call stack or a spaghetti stack or other mechanisms in which there isn't a fixed address, so it's not really a different mechanism, it's just a mechanism that leaves part of the mechanism up to the assembler-language programmer or the compiler code generator rather than to the instruction set (as with instructions with a "push it on the stack" call instruction). And, as far as I know, a spaghetti stack can also support reentrancy, recursion ,and thread safety.

So I updated Call stack § Functions of the call stack to mention "store the return address in a fixed address in memory" as an example of the alternatives in question. Guy Harris (talk) 08:19, 12 March 2022 (UTC)