Talk:Call stack/Archive 1

Archive 1

Moving to 'call stack'

I plan on moving this article to give it the title 'call stack' soon. This is the name by which the stack is usually known, as is made clear by, for instance, this data on Google hits for various exact phrases "X stack":

Phrase	Hits	Comments
"function stack"	7,620
"call stack"	170,000
"execution stack"	28,000
"control stack"	16,000
"call return stack"	551
"return stack"	23,200	(includes "call/return stack")
"return address stack"	5,280
"address stack"	8,700	(includes return address stack)
"procedure stack"	954
"data stack"	26,600
"parameter stack"	5,260
"frame stack"	7,020
"runtime stack"	11,800	(usually like "runtime stack overflow")

This should be done with a move, not a copy-paste, to preserve the edit history. (that may require help via WP:RM, or maybe not). There'll be a few fixups to do too. -R. S. Shaw 22:11, 16 February 2006 (UTC)

Sounds fine. Anything that makes it clear that the stacks primary purpose is tracking function returns, and not necessarily params/locals, is fine by me. --Mgreenbe 00:48, 17 February 2006 (UTC)

History

It would be nice to see some material about the history of these concepts. For instance, who came up with the concept (and the name) "activation record". I presume it must have appeared in the first Algol 60 implementation? Tsferreira 17:59, 13 March 2006 (UTC)

Stack unwinding

The sentence mentioning "stack unwinding" may accurately summarise the stub article, but it not right. Stack unwinding is usually performed in the context of an exception, where control is transferred up the stack. The tricky part is making sure that you destruct and/or deallocate the appropriate objects. For example, see [1] or [2], just the first two hits for a google search on "stack unwinding". There are other contexts, e.g. stack unwinding for C code. So I think that this sentence needs to be removed now, and replaced soon with a proper treatment of "stack unwinding", which I'm sorry to say probably belongs in its own article. --Mike Van Emmerik 11:24, 21 January 2006 (UTC)

Agreed, and the section on winding; The Forth programming language allows explicit winding of the call stack (called there the "return stack"). is completely wrong. Forth doesn't work that way; there's no frame to wind or unwind. Alex 21:49, 28 March 2006 (UTC)

Return processing

In the recently added section "Return processing", the last sentence says essentially that there is typically no cleanup required by the caller. This is true for RISC processors. For CISC processors using PUSH and POP instructions, it is also true for the callee-pop calling convention, but not for the caller-pop convention. Or of course it is trivially true if there happen to be no arguments pushed, or the arguments are passed in registers (but when there are enough parameters, some arguments are passed on the stack anyway).

In other words, there is a large set of programs (CISC architecture, nonzero arguments, and caller-pop convention as used by C) for which this statement is misleading. I can't immediately think of a change that is compact but not misleading. --Mike Van Emmerik 00:42, 9 April 2006 (UTC)

I've revised it to cover this variation. -R. S. Shaw 21:17, 10 April 2006 (UTC)

Processor Support

This article should include a discussion of built-in processor support for stack pointers and/or call frames, e.g. which chip architecture introduced this concept, how it works, etc. —The preceding unsigned comment was added by Tzadikv (talk • contribs) 14:57, 10 May 2007 (UTC).

Hardware stack

Shouldn't this be merged with the Hardware stack discussion in Stack? —Preceding unsigned comment added by 99.235.205.120 (talk) 21:21, 21 February 2008 (UTC)

Merging with other wikipedia articles

I disagree with the merging proposal, just put references

• I also think it's not good to merge this with Subroutine. Subroutine is a basic programming concept whose main audience would be relatively unfamiliar with programming. The stack is an advanced topic about internals related to storage allocation, debugging, compiling, exception handling and other things beyond subroutines. -R. S. Shaw 20:22, 28 July 2005 (UTC)

• I disagree with the proposed merge also. Merging Stack unwinding here makes much more sense than merging the two stack articles with Subroutine. --Mike Van Emmerik 21:42, 7 August 2005 (UTC)

• I'm in favor of directing stack unwinding to either here, exception handling, or continuation. Stack frame should surely go here. The article badly, badly needs pictures and good explanation. --Mgreenbe 23:13, 3 January 2006 (UTC)

• Merged with stack unwinding. Stack frame might need some work. Strongly disagree that Subroutine should be merged. —EatMyShortz 08:58, 21 January 2006 (UTC)

• IMO Call Stack is a pretty good article as is (haven't read the whole thing) and should remain largely as is. There should also be a Stack Frame article that goes into greater detail about what's in the stack frame, like a few of the more popular architecture's implementations (Call Stack has little detail which I think is good, but the detail _should_ be somewhere). I agree with the first point on Subroutine. It's a concept all on it's own. I'm not sure whether Stack unwinding should be part of Call Stack or not, need some more thought on that, but I lean towards one article there. —Von Fugal 15:43, 5 April 2008 (UTC)

• I agree that it should not be merged. Call stack (saving return addresses) is logically distinct, though often combined, with stacking of arguments or local variables. It happens that on many processors it is convenient to do all on one stack, but the explanations should be separate. Gah4 (talk) 20:39, 10 June 2008 (UTC)

Merger proposal

Most, if not all, of the text in the article Stack-based memory allocation appears to be covered in this article. I propose merging it into this article; are there any thoughts on this? Hertzsprung 15:04, 14 August 2007 (UTC)

I don't think it is a good idea to merge them, since they are different concepts, the Call stack is a method that uses Stack-based memory allocation, but they are not the same thing. JorgeFierro (talk) 23:26, 11 September 2008 (UTC)

Agreed. A call stack is stack-based memory allocation, but stack-based memory allocation is not a call stack. I'd consider merging stack-based memory allocation with dynamic memory allocation and sticking the Frankenstein result into memory allocation (a redirect page at the time of this writing); individual articles on both concepts seems unnecessary when both have only a little bit of content. However, it just isn't a matter of import. (Seems like a huuuuuge amount of Wikipedia regards trivialities like this...) --Jtgibson (talk) 00:26, 5 October 2008 (UTC)

NO A GOOD IDEA —Preceding unsigned comment added by 128.243.253.112 (talk) 23:59, 10 November 2008 (UTC)

Evaluation Stack

I'm no true expert, but the call stack (also known as the environmental stack) is a different struture as the evaluation (arithmetic) stack.

It is true, that in some implementation they are mixed together, but this is a conceptual flaw of the implementation.

But as I said, I am no expert. As for my information source: http://www.sbql.pl/Topics/Environment%20stack.html

pl:Quintria

The functions of tracking calls, evaluatating arithmetic expressions, allocating temporary storage to a subroutine, and passing parameters are all separate functions. Each can be addressed by using a stack structure. The stacks used for these functions can all be separate, or can be brought together in any combination. The decision in an implementation to combine any or all of these stacks is an engineering decision, which will have better or worse efficiencies under different conditions. There is nothing conceptually wrong with combining any of these functions into the same stack. The functions are conceptually separate, but implementations can be more effective by combining some or all of them. -R. S. Shaw 18:42, 1 July 2006 (UTC)

Exactly! I support your well formulated analysis and description. 83.255.35.198 (talk) 13:27, 24 March 2011 (UTC)

Perfomance analysis: call instruction vs. entire function call

"The reason is if a subroutine call instruction appears on the call stack for a certain fraction of execution time, its possible removal would save that much time." I don't think sampling the call stack is intended to measure the amount of time spent in the call instruction, but rather to measure the amount of time spent in the subroutine, which (except in the case of absolutely trivial functions) is much greater. This is in line with what is said on the Deep sampling page about eliminating "extraneous function calls". John lindgren (talk) 13:24, 16 June 2011 (UTC)

Error in "Structure" section ?

Original text "For example, if a subroutine named DrawPoint is currently running, having just been called by a subroutine DrawLine having been called by a DrawSquare subroutine, the top part of the call stack might be laid out like this (where the stack is growing towards the top):" and image below it do not match. Upper stack frame on image is for DrawLine, but text specifies that it should be for DrawPoint. Am I right ?
Cybevnm (talk) 21:47, 28 October 2011 (UTC)

Yes, you are right. The text should not have described a "DrawPoint" as running; DrawLine is the code that is in the middle of execution when DrawLine's frame is at the top. When the illustration first went in, that is what the text said, but somebody changed it since then to have the DrawPoint reference. I have fixed it. -R. S. Shaw (talk) 19:41, 29 October 2011 (UTC)

"Activation record" redirect

Computers can have activation records and recursive function calls without using stacks. Computers built on the S/360 and AS/400 architectures use a linked list of activation records either in static memory or dynamically allocated from a heap-like area (using GETMAIN on the S/360 and Call Return Elements on the AS/400) instead of a stack. The caller's activation record holds the registers and parameters, and the callee's activation record holds its local variables. Architectures using this method typically use Branch and Link instructions for calls and might also have queue or linked list instructions to manipulate this data structure instead of the Push and Pop found on an architecture with a call stack. 69.54.60.34 (talk) 04:40, 11 November 2011 (UTC)

The introduction

For some reason, the second sentence just cracks me up. I have no idea why. -— Isarra (talk) 19:40, 11 January 2012 (UTC)