Talk:Subroutine

From Wikipedia, the free encyclopedia

	This article is within the scope of WikiProject Computer science, which aims to create a comprehensive computer science reference for Wikipedia. Visit the project page for more information and to join in on related discussions.
Start	rated as start-Class on the assessment scale
Top	rated as top-importance on the assessment scale

Contents 1 Old text from Subprogram 2 New stuff 3 Return address 4 Subroutines and Methods 5 Subroutines and parameters 6 Proposal to merge section from Control Flow article into Subroutine article

[edit] Old text from Subprogram

Someone with more patience and objectivity than I, might want to resurrect some of the text from this revision of Subroutine that was subsequently eroded and finally obliterated by well-meaning edits. I wrote this draft, and I think it has a decent, straightforward, NPOV structure that's more encyclopedic than what's currently on this page. --P3d0 02:04, Oct 1, 2004 (UTC)

[edit] New stuff

"however, the C programming language and its programmers view subroutines simply as functions that do not return a value."

The one thing in life that frustrates me most is arguing over definitions, so this is just a thought. I'm a (mostly) self-taught C programmer, so I have very little use for terminology, but what about functions that return only success or failure... Would they not be considered a sub routine?

--The Extremist

Returning a boolean is still returning a value. IMHO. --Mike Van Emmerik 03:51, 12 May 2005 (UTC)

indeed

[edit] Return address

"The IBM 360 range used to save this address in a register, relying on macros to save and restore deeper return addresses in memory associated with individual subroutines, then using branches to the address specified in the register to accomplish a return. However stacks have proved a very useful approach, and are typically used in more modern architectures."

Sorry, that's the fashion again. Push/pop architectures like the Pentium are now obsoleted by RISC and VLIW machines (e.g. SPARC, PowerPC, Itanium, etc) that use a link register to store the return address, which has to be saved by non-leaf subroutines. Push and pop instructions aren't always used even when available, e.g. see Pentium code generated by the MLton compiler. It subtracts a constant from the stack pointer for every call, and all local variables and also outgoing parameters are handled as offsets from the stack pointer. Even return instructions are replaced by a branch indirect on an offset from the PC. Presumably they do this for speed, but it may just be easier to write RISC-like code for all target machines. In any case, it's simply not true to say that the more modern machines prefer to use stack instructions. Pentiums only have stack instructions because of backwards compatibility to the 8086 (at the binary level) arguably the 8008 (at assembly language level). I don't have time for this right now, and would also like to seek confirmation on this point.

--Mike Van Emmerik 03:51, 12 May 2005 (UTC)

Yes, the link register has come back into fashion -- many RISC machines have a link register to store the return address. (I've done a bit of ARM assembly language programming -- ARM was post-8086, right ?).

However, we *are* still using a stack -- a stack is necessary for recursive subroutines.

Um, NO. Continuation passing style has been used for years in Standard ML compilers, and SML uses recursion almost exclusively as the control-flow of choice. --bmills 18:34, 24 October 2005 (UTC)

We're not going back to the bad old days of the MIX and other machines that required self-modifying code. Those machines begin each (non-leaf) subroutine by overwriting the address in the "jump" instruction at the end of a subroutine with the value of the link register. Are you sure that "return instructions are replaced by a branch indirect on an offset from the PC" ? Because that sort of thing makes recursive subroutines impossible. I might believe you if you said "branch indirect on an offset from the SP", because that is still (effectively) a stack. --DavidCary 05:55, 16 July 2005 (UTC)

However, we *are* still using a stack -- a stack is necessary for recursive subroutines.

Agreed.

I might believe you if you said "branch indirect on an offset from the SP", because that is still (effectively) a stack.

Sorry, that is what I meant.

My point was this: RISC machines have no more hardware support than what the IBM360 had (ability to copy the program counter to a register). I assumed that this means that the IBM used a stack... if not why not? --Mike Van Emmerik 13:46, 17 July 2005 (UTC)

No, the 360 calling convention did not use a stack. See the Overview in this article at Everything2 and/or the History section of this 390 linkage pdf.

The 360 hardware architecture was excellent (in historical context), but the software wasn't. Of course the hardware could support a call stack, but they explored piles of calling convention kludges instead.

Why did they do that? Hard to say; ignorance is my best guess. You might get some insight from Stack? S/360 don't need no stinkin' stack!. I think in part it was overreaction to the Burroughs stack approach (B5000). This is suggested by the "Pushdown stack vs address registers" discussion in Amdahl's 1964 "Architecture of the S/360" paper. It says "Subroutine transparency ... is one of the apparent advantages of the stack. However, the disadvantage is that the transparency does not materialize unless additional independent stacks are introduced for addressing purposes" (whatever that means). -R. S. Shaw 20:02, 17 July 2005 (UTC)

OK, thanks for all the info. I've now cleaned up the part which I was objecting to (i.e. that RISC machines have somehow "reverted" to the bad old days of the IBM 360). --Mike Van Emmerik 04:14, 18 July 2005 (UTC)

[edit] Subroutines and Methods

Aren't subroutines and methods pretty simliar? If so, I think each article should mention the other one to some degree. -Hyad 2 July 2005 23:26 (UTC)

I actually think that merging the article 'Function Stack' with 'Subroutine' is a good idea. I also think that the page describing a 'Subprogram' should be reintroduced. --Anonymous 16:20, 15 July 2005 (UTC)

Actually they can be similar or dissimilar (if I understand the termonology) depending on the language you use.

A method can be called a function or subroutine (and in other languages it is once again different) but thow in an object oriented language and you have something different. The method implements variables that modify an object. Normally methods would just return varibles or modify something, but that is language depenent.

[edit] Subroutines and parameters

I think that the Parameter (computer science) article ought to be dropped and redirected to this article. Please see the comment on Talk:Parameter (computer science). —Preceding unsigned comment added by Donhalcon (talk • contribs) 07:14, 23 October 2005

What? No. Parameters are vaster then simple methods, although the article doesn't seem to explain that. Look, if you have an equation the parameters of that equation are what go in to fill (ex) x, y, and z. The Parameter artile needs a re-work, but it should not be incorporated into a single article

Furthermore, the separation of facts is nessicary for a working encyclopedia. You wouldn't combind Time with Watch just because of the similarities. Or god with devil because they exist within the same idea. The more separated objects are the better.

http://www.answers.com/parameter&r=67

A parameter is something that is passed to the subroutine. They are separate concepts. Poppafuze 06:04, 28 September 2006 (UTC)

[edit] Proposal to merge section from Control Flow article into Subroutine article

Currently, the Subroutine section in Control flow and the Subroutine article are both covering the same topic. When a section summarises the content of a linked article, it should be a short summary and should not include any significant content that is not in the linked article - this is not currently the case at all. The section in Control flow on subroutines is not short, it is not a summary, and it contains content that is not in the main article. Any objections to this proposed merge?—greenrd 13:20, 27 May 2007 (UTC)

I am surprised to hear a claim that these articles are covering the same subject. If they read as if they are covering the same subject then some rewriting is needed. I have read them and don't think they read as if they are covering the same subject. Derek farn 15:01, 27 May 2007 (UTC)

Perhaps I was not sufficiently clear. I am talking about the Subroutine section in the Control flow article, not the entire Control flow article. Both that section and the Subroutine article are talking about the same subject, subroutines...—greenrd 16:47, 27 May 2007 (UTC)

You were sufficiently clear, but I was insufficiently switched on. Good call. Do the merge. Derek farn 19:24, 27 May 2007 (UTC)