Subroutine - Revision history

Jnc: +links

2023-05-12T13:43:56Z

+links

← Older revision		Revision as of 13:43, 12 May 2023
Line 3:		Line 3:
	==History==		==History==

	In the very earliest days of computing, a subroutine was simply a written-out sequence of ~~instructions~~ to perform some common operation (e.g. multiply, on machines which did not have a 'multiply' [[instruction]]). The programmer wishing to use that subroutine had to insert a copy of those instructions in their program, at the point at which it was desired to perform that operation.		In the very earliest days of computing, a subroutine was simply a written-out sequence of [[instruction]]s to perform some common operation (e.g. multiply, on machines which did not have a 'multiply' instruction). The programmer wishing to use that subroutine had to insert a copy of those instructions in their [[program]], at the point at which it was desired to perform that operation.

	If the same operation needed to be performed at several different places in the program, thereby necessitating several copies of the code sequence, this was obviously inefficient of space in [[main memory]], particularly crucial in early machines which had very small main memories.		If the same operation needed to be performed at several different places in the program, thereby necessitating several copies of the code sequence, this was obviously inefficient of space in [[main memory]], particularly crucial in early machines which had very small main memories.
Line 9:		Line 9:
	It thus became desirable to allow one copy of the instruction sequence to be shared; to do this, a '''calling sequence''' was defined, using existing instructions, where the [[address]] to go back to upon completion was stored in a known location, before the subroutine was entered. One copy of the subroutine could thus be 'shared' among multiple uses.		It thus became desirable to allow one copy of the instruction sequence to be shared; to do this, a '''calling sequence''' was defined, using existing instructions, where the [[address]] to go back to upon completion was stored in a known location, before the subroutine was entered. One copy of the subroutine could thus be 'shared' among multiple uses.

	Eventually hardware support (in the form of special instructions) was added to simplify calling sequences, although the first versions were often crude. E.g. in the [[Whirlwind]] computer, the subroutine calling sequence used two instructions, 'Sub-Program' and 'Transfer Address': the first saved the current PC in the [[accumulator]], and ~~jumped~~ to the subroutine; the second stored the address in the accumulator in the address field of an instruction, usually a 'jump' instruction at the end of the subroutine.		Eventually [[hardware]] support (in the form of special instructions) was added to simplify calling sequences, although the first versions were often crude. E.g. in the [[Whirlwind]] computer, the subroutine calling sequence used two instructions, 'Sub-Program' and 'Transfer Address': the first saved the current [[Program Counter\|PC]] value in the [[accumulator]], and then [[jump]]ed to the subroutine; the second stored the address (in the accumulator) in the address field of an instruction, usually a 'jump' instruction at the end of the subroutine.

	(The [[PDP-10]] [[instruction set]] contains a 'fossil' from this era: the 'JSA' instruction, which saves the return location in the first [[word]] of the subroutine, and then starts execution at the second word.)		(The [[PDP-10]] [[instruction set]] contains a 'fossil' from this era: the 'JSA' instruction, which saves the return location in the first [[word]] of the subroutine, and then starts execution at the second word.)

Jnc: typos

2018-12-15T23:24:36Z

typos

← Older revision		Revision as of 23:24, 15 December 2018
Line 17:		Line 17:
	Calling sequences which stored arguments, and the return point, in fixed locations could not be used recursively, so eventually the modern practise, of storing both arguments and the return point on a [[stack]], came into use.		Calling sequences which stored arguments, and the return point, in fixed locations could not be used recursively, so eventually the modern practise, of storing both arguments and the return point on a [[stack]], came into use.

	[Category: CPU Basics]]		[[Category: CPU Basics]]
	[Category: Software Basics]]		[[Category: Software Basics]]

Jnc: +cats

2018-12-15T23:24:14Z

+cats

← Older revision		Revision as of 23:24, 15 December 2018
Line 16:		Line 16:

	Calling sequences which stored arguments, and the return point, in fixed locations could not be used recursively, so eventually the modern practise, of storing both arguments and the return point on a [[stack]], came into use.		Calling sequences which stored arguments, and the return point, in fixed locations could not be used recursively, so eventually the modern practise, of storing both arguments and the return point on a [[stack]], came into use.

			[Category: CPU Basics]]
			[Category: Software Basics]]

Jnc: grammar

2018-09-26T16:25:38Z

grammar

← Older revision		Revision as of 16:25, 26 September 2018
Line 7:		Line 7:
	If the same operation needed to be performed at several different places in the program, thereby necessitating several copies of the code sequence, this was obviously inefficient of space in [[main memory]], particularly crucial in early machines which had very small main memories.		If the same operation needed to be performed at several different places in the program, thereby necessitating several copies of the code sequence, this was obviously inefficient of space in [[main memory]], particularly crucial in early machines which had very small main memories.

	It thus became desirable to allow one copy of the instruction sequence to be shared; to do this, a '''calling sequence''' was defined, using existing instructions, where the address to go back to upon completion was stored in a known location, before the subroutine was entered. One copy of the subroutine could thus be 'shared' among multiple uses.		It thus became desirable to allow one copy of the instruction sequence to be shared; to do this, a '''calling sequence''' was defined, using existing instructions, where the [[address]] to go back to upon completion was stored in a known location, before the subroutine was entered. One copy of the subroutine could thus be 'shared' among multiple uses.

	Eventually hardware support (in the form of a special ~~instruction~~) was added to simplify calling sequences, although the first versions were often crude. E.g. in the [[Whirlwind]] computer, the subroutine calling sequence used two instructions, 'Sub-Program' and 'Transfer Address': the first saved the current PC in the [[accumulator]], and jumped to the subroutine; the second stored the address in the accumulator in the address field of an instruction, usually a 'jump' instruction at the end of the subroutine.		Eventually hardware support (in the form of special instructions) was added to simplify calling sequences, although the first versions were often crude. E.g. in the [[Whirlwind]] computer, the subroutine calling sequence used two instructions, 'Sub-Program' and 'Transfer Address': the first saved the current PC in the [[accumulator]], and jumped to the subroutine; the second stored the address in the accumulator in the address field of an instruction, usually a 'jump' instruction at the end of the subroutine.

	(The [[PDP-10]] [[instruction set]] contains a 'fossil' from this era: the 'JSA' instruction, which saves ~~information~~ in the first word of the subroutine, and ~~starting~~ execution at the second word.)		(The [[PDP-10]] [[instruction set]] contains a 'fossil' from this era: the 'JSA' instruction, which saves the return location in the first [[word]] of the subroutine, and then starts execution at the second word.)

	Calling sequences were also expanded, to allow ~~arguments~~ to be passed, so that a given subroutine had more flexibility (i.e. one would not need two, slightly ~~difference~~, copies.)		Calling sequences were also expanded, to allow [[argument]]s to be passed, so that a given subroutine had more flexibility (i.e. one would not need two, slightly different, copies.)

	Calling sequences which stored arguments, and the return point, in fixed locations ~~cannot~~ be used recursively, so eventually the modern practise, of storing both arguments and the return point on a [[stack]], came into use.		Calling sequences which stored arguments, and the return point, in fixed locations could not be used recursively, so eventually the modern practise, of storing both arguments and the return point on a [[stack]], came into use.

Jnc: Add another term

2017-10-19T18:26:29Z

Add another term

← Older revision		Revision as of 18:26, 19 October 2017
Line 1:		Line 1:
	A '''subroutine''' (or '''function''') is a block of code (either in the [[source code]], or in the [[object code]]) to which control can be transferred so that the code block can perform some desired common operation; when it is done doing so, control returns to the 'caller' of the subroutine.		A '''subroutine''' (or '''function''' or '''procedure''') is a block of code (either in the [[source code]], or in the [[object code]]) to which control can be transferred so that the code block can perform some desired common operation; when it is done doing so, control returns to the 'caller' of the subroutine.

	==History==		==History==

Jnc: First subroutines probably had no instruction support

2017-10-19T18:18:30Z

First subroutines probably had no instruction support

← Older revision		Revision as of 18:18, 19 October 2017
Line 7:		Line 7:
	If the same operation needed to be performed at several different places in the program, thereby necessitating several copies of the code sequence, this was obviously inefficient of space in [[main memory]], particularly crucial in early machines which had very small main memories.		If the same operation needed to be performed at several different places in the program, thereby necessitating several copies of the code sequence, this was obviously inefficient of space in [[main memory]], particularly crucial in early machines which had very small main memories.

	It thus became desirable to allow one copy of the instruction sequence to be shared; to do this, a '''calling sequence''' was defined, where the address to go back to upon completion was stored in a known location, before the subroutine was entered. One copy of the subroutine could thus be 'shared' among multiple uses.		It thus became desirable to allow one copy of the instruction sequence to be shared; to do this, a '''calling sequence''' was defined, using existing instructions, where the address to go back to upon completion was stored in a known location, before the subroutine was entered. One copy of the subroutine could thus be 'shared' among multiple uses.

	Eventually hardware support (in the form of a special instruction) was added to simplify calling sequences, although the first versions were often crude. E.g. in the [[Whirlwind]] computer, the subroutine calling sequence used two instructions, 'Sub-Program' and 'Transfer Address': the first saved the current PC in the [[accumulator]], and jumped to the subroutine; the second stored the address in the accumulator in the address field of an instruction, usually a 'jump' instruction at the end of the subroutine.		Eventually hardware support (in the form of a special instruction) was added to simplify calling sequences, although the first versions were often crude. E.g. in the [[Whirlwind]] computer, the subroutine calling sequence used two instructions, 'Sub-Program' and 'Transfer Address': the first saved the current PC in the [[accumulator]], and jumped to the subroutine; the second stored the address in the accumulator in the address field of an instruction, usually a 'jump' instruction at the end of the subroutine.

Jnc: An OK start

2017-10-19T18:12:42Z

An OK start

New page

A '''subroutine''' (or '''function''') is a block of code (either in the [[source code]], or in the [[object code]]) to which control can be transferred so that the code block can perform some desired common operation; when it is done doing so, control returns to the 'caller' of the subroutine.

==History==

In the very earliest days of computing, a subroutine was simply a written-out sequence of instructions to perform some common operation (e.g. multiply, on machines which did not have a 'multiply' [[instruction]]). The programmer wishing to use that subroutine had to insert a copy of those instructions in their program, at the point at which it was desired to perform that operation.

If the same operation needed to be performed at several different places in the program, thereby necessitating several copies of the code sequence, this was obviously inefficient of space in [[main memory]], particularly crucial in early machines which had very small main memories.

It thus became desirable to allow one copy of the instruction sequence to be shared; to do this, a '''calling sequence''' was defined, where the address to go back to upon completion was stored in a known location, before the subroutine was entered. One copy of the subroutine could thus be 'shared' among multiple uses.

Eventually hardware support (in the form of a special instruction) was added to simplify calling sequences, although the first versions were often crude. E.g. in the [[Whirlwind]] computer, the subroutine calling sequence used two instructions, 'Sub-Program' and 'Transfer Address': the first saved the current PC in the [[accumulator]], and jumped to the subroutine; the second stored the address in the accumulator in the address field of an instruction, usually a 'jump' instruction at the end of the subroutine.

(The [[PDP-10]] [[instruction set]] contains a 'fossil' from this era: the 'JSA' instruction, which saves information in the first word of the subroutine, and starting execution at the second word.)

Calling sequences were also expanded, to allow arguments to be passed, so that a given subroutine had more flexibility (i.e. one would not need two, slightly difference, copies.)

Calling sequences which stored arguments, and the return point, in fixed locations cannot be used recursively, so eventually the modern practise, of storing both arguments and the return point on a [[stack]], came into use.