Question: What do subroutines require?

Answer: programmers to use the call sequence

The idea of a subroutine was worked out after computing machines had already existed for some time. The arithmetic and conditional jump instructions were planned ahead of time and have changed relatively little; but the special instructions used for procedure calls have changed greatly over the years. The earliest computers and microprocessors, such as the Small-Scale Experimental Machine and the RCA 1802, did not have a single subroutine call instruction. <hl> Subroutines could be implemented, but they required programmers to use the call sequence —a series of instructions—at each call site. <hl> Some very early computers and microprocessors, such as the IBM 1620, the Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines. Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines. The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.

The idea of a subroutine was worked out after computing machines had already existed for some time. The arithmetic and conditional jump instructions were planned ahead of time and have changed relatively little; but the special instructions used for procedure calls have changed greatly over the years. The earliest computers and microprocessors, such as the Small-Scale Experimental Machine and the RCA 1802, did not have a single subroutine call instruction. Subroutines could be implemented, but they required <hl> programmers to use the call sequence <hl>—a series of instructions—at each call site. Some very early computers and microprocessors, such as the IBM 1620, the Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines. Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines. The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.

Subroutines could be implemented, but they required <hl> programmers to use the call sequence <hl> —a series of instructions—at each call site.


Question: What does a calling convention allow for?

The idea of a subroutine was worked out after computing machines had already existed for some time.
The arithmetic and conditional jump instructions were planned ahead of time and have changed relatively little; but the special instructions used for procedure calls have changed greatly over the years.
The earliest computers and microprocessors, such as the Small-Scale Experimental Machine and the RCA 1802, did not have a single subroutine call instruction.
Subroutines could be implemented, but they required programmers to use the call sequence—a series of instructions—at each call site.
Some very early computers and microprocessors, such as the IBM 1620, the Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines.
Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines.
The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.

Answer: deep levels of subroutine nesting

The idea of a subroutine was worked out after computing machines had already existed for some time. The arithmetic and conditional jump instructions were planned ahead of time and have changed relatively little; but the special instructions used for procedure calls have changed greatly over the years. The earliest computers and microprocessors, such as the Small-Scale Experimental Machine and the RCA 1802, did not have a single subroutine call instruction. Subroutines could be implemented, but they required programmers to use the call sequence—a series of instructions—at each call site. Some very early computers and microprocessors, such as the IBM 1620, the Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines. Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. <hl> This allows arbitrarily deep levels of subroutine nesting , but does not support recursive subroutines. <hl> The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.

The idea of a subroutine was worked out after computing machines had already existed for some time. The arithmetic and conditional jump instructions were planned ahead of time and have changed relatively little; but the special instructions used for procedure calls have changed greatly over the years. The earliest computers and microprocessors, such as the Small-Scale Experimental Machine and the RCA 1802, did not have a single subroutine call instruction. Subroutines could be implemented, but they required programmers to use the call sequence—a series of instructions—at each call site. Some very early computers and microprocessors, such as the IBM 1620, the Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines. Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily <hl> deep levels of subroutine nesting <hl>, but does not support recursive subroutines. The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.

This allows arbitrarily <hl> deep levels of subroutine nesting <hl> , but does not support recursive subroutines.


Question: What is a call sequence?

Answer: a series of instructions

The idea of a subroutine was worked out after computing machines had already existed for some time. The arithmetic and conditional jump instructions were planned ahead of time and have changed relatively little; but the special instructions used for procedure calls have changed greatly over the years. The earliest computers and microprocessors, such as the Small-Scale Experimental Machine and the RCA 1802, did not have a single subroutine call instruction. <hl> Subroutines could be implemented, but they required programmers to use the call sequence— a series of instructions —at each call site. <hl> Some very early computers and microprocessors, such as the IBM 1620, the Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines. Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines. The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.

The idea of a subroutine was worked out after computing machines had already existed for some time. The arithmetic and conditional jump instructions were planned ahead of time and have changed relatively little; but the special instructions used for procedure calls have changed greatly over the years. The earliest computers and microprocessors, such as the Small-Scale Experimental Machine and the RCA 1802, did not have a single subroutine call instruction. Subroutines could be implemented, but they required programmers to use the call sequence—<hl> a series of instructions <hl>—at each call site. Some very early computers and microprocessors, such as the IBM 1620, the Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines. Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines. The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.

Subroutines could be implemented, but they required programmers to use the call sequence— <hl> a series of instructions <hl> —at each call site.


Question: What did machines before the mid 1960s use?

Answer: a calling convention

The idea of a subroutine was worked out after computing machines had already existed for some time. The arithmetic and conditional jump instructions were planned ahead of time and have changed relatively little; but the special instructions used for procedure calls have changed greatly over the years. The earliest computers and microprocessors, such as the Small-Scale Experimental Machine and the RCA 1802, did not have a single subroutine call instruction. Subroutines could be implemented, but they required programmers to use the call sequence—a series of instructions—at each call site. Some very early computers and microprocessors, such as the IBM 1620, the Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines. <hl> Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. <hl> This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines. The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.

The idea of a subroutine was worked out after computing machines had already existed for some time. The arithmetic and conditional jump instructions were planned ahead of time and have changed relatively little; but the special instructions used for procedure calls have changed greatly over the years. The earliest computers and microprocessors, such as the Small-Scale Experimental Machine and the RCA 1802, did not have a single subroutine call instruction. Subroutines could be implemented, but they required programmers to use the call sequence—a series of instructions—at each call site. Some very early computers and microprocessors, such as the IBM 1620, the Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines. Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use <hl> a calling convention <hl> which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines. The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.


Question: How were program instructions entered into memory with early computers?

In many early computers, the program instructions were entered into memory from a punched paper tape. Each subroutine could then be provided by a separate piece of tape, loaded or spliced before or after the main program; and the same subroutine tape could then be used by many different programs. A similar approach was used in computers whose main input was through punched cards. The name subroutine library originally meant a library, in the literal sense, which kept indexed collections of such tapes or card decks for collective use.

Answer: punched paper tape

<hl> In many early computers, the program instructions were entered into memory from a punched paper tape . <hl> Each subroutine could then be provided by a separate piece of tape, loaded or spliced before or after the main program; and the same subroutine tape could then be used by many different programs. A similar approach was used in computers whose main input was through punched cards. The name subroutine library originally meant a library, in the literal sense, which kept indexed collections of such tapes or card decks for collective use.

In many early computers, the program instructions were entered into memory from a <hl> punched paper tape <hl>. Each subroutine could then be provided by a separate piece of tape, loaded or spliced before or after the main program; and the same subroutine tape could then be used by many different programs. A similar approach was used in computers whose main input was through punched cards. The name subroutine library originally meant a library, in the literal sense, which kept indexed collections of such tapes or card decks for collective use.

In many early computers, the program instructions were entered into memory from a <hl> punched paper tape <hl> .


Question: What did a subroutine library originally do?

Answer: kept indexed collections of such tapes or card decks for collective use

In many early computers, the program instructions were entered into memory from a punched paper tape. Each subroutine could then be provided by a separate piece of tape, loaded or spliced before or after the main program; and the same subroutine tape could then be used by many different programs. A similar approach was used in computers whose main input was through punched cards. <hl> The name subroutine library originally meant a library, in the literal sense, which kept indexed collections of such tapes or card decks for collective use . <hl>

In many early computers, the program instructions were entered into memory from a punched paper tape. Each subroutine could then be provided by a separate piece of tape, loaded or spliced before or after the main program; and the same subroutine tape could then be used by many different programs. A similar approach was used in computers whose main input was through punched cards. The name subroutine library originally meant a library, in the literal sense, which <hl> kept indexed collections of such tapes or card decks for collective use <hl>.

The name subroutine library originally meant a library, in the literal sense, which <hl> kept indexed collections of such tapes or card decks for collective use <hl> .


Question: What were computers main input?

Answer: punched cards

In many early computers, the program instructions were entered into memory from a punched paper tape. Each subroutine could then be provided by a separate piece of tape, loaded or spliced before or after the main program; and the same subroutine tape could then be used by many different programs. <hl> A similar approach was used in computers whose main input was through punched cards . <hl> The name subroutine library originally meant a library, in the literal sense, which kept indexed collections of such tapes or card decks for collective use.

In many early computers, the program instructions were entered into memory from a punched paper tape. Each subroutine could then be provided by a separate piece of tape, loaded or spliced before or after the main program; and the same subroutine tape could then be used by many different programs. A similar approach was used in computers whose main input was through <hl> punched cards <hl>. The name subroutine library originally meant a library, in the literal sense, which kept indexed collections of such tapes or card decks for collective use.

A similar approach was used in computers whose main input was through <hl> punched cards <hl> .


Question: What ways can subroutines be provided?

Answer: by a separate piece of tape, loaded or spliced before or after the main program

In many early computers, the program instructions were entered into memory from a punched paper tape. <hl> Each subroutine could then be provided by a separate piece of tape, loaded or spliced before or after the main program ; and the same subroutine tape could then be used by many different programs. <hl> A similar approach was used in computers whose main input was through punched cards. The name subroutine library originally meant a library, in the literal sense, which kept indexed collections of such tapes or card decks for collective use.

In many early computers, the program instructions were entered into memory from a punched paper tape. Each subroutine could then be provided <hl> by a separate piece of tape, loaded or spliced before or after the main program <hl>; and the same subroutine tape could then be used by many different programs. A similar approach was used in computers whose main input was through punched cards. The name subroutine library originally meant a library, in the literal sense, which kept indexed collections of such tapes or card decks for collective use.

Each subroutine could then be provided <hl> by a separate piece of tape, loaded or spliced before or after the main program <hl> ; and the same subroutine tape could then be used by many different programs.


Question: What is a call stack?

Most modern implementations use a call stack, a special case of the stack data structure, to implement subroutine calls and returns. Each procedure call creates a new entry, called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls. Each stack frame contains the private data of the corresponding call, which typically includes the procedure's parameters and internal variables, and the return address.

Answer: a special case of the stack data structure

<hl> Most modern implementations use a call stack, a special case of the stack data structure , to implement subroutine calls and returns. <hl> Each procedure call creates a new entry, called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls. Each stack frame contains the private data of the corresponding call, which typically includes the procedure's parameters and internal variables, and the return address.

Most modern implementations use a call stack, <hl> a special case of the stack data structure <hl>, to implement subroutine calls and returns. Each procedure call creates a new entry, called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls. Each stack frame contains the private data of the corresponding call, which typically includes the procedure's parameters and internal variables, and the return address.

Most modern implementations use a call stack, <hl> a special case of the stack data structure <hl> , to implement subroutine calls and returns.


Question: What are call stacks used for?

Answer: to implement subroutine calls and returns

<hl> Most modern implementations use a call stack, a special case of the stack data structure, to implement subroutine calls and returns . <hl> Each procedure call creates a new entry, called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls. Each stack frame contains the private data of the corresponding call, which typically includes the procedure's parameters and internal variables, and the return address.

Most modern implementations use a call stack, a special case of the stack data structure, <hl> to implement subroutine calls and returns <hl>. Each procedure call creates a new entry, called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls. Each stack frame contains the private data of the corresponding call, which typically includes the procedure's parameters and internal variables, and the return address.

Most modern implementations use a call stack, a special case of the stack data structure, <hl> to implement subroutine calls and returns <hl> .


Question: What is a stack frame?

Answer: a new entry

Most modern implementations use a call stack, a special case of the stack data structure, to implement subroutine calls and returns. <hl> Each procedure call creates a new entry , called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls. <hl> Each stack frame contains the private data of the corresponding call, which typically includes the procedure's parameters and internal variables, and the return address.

Most modern implementations use a call stack, a special case of the stack data structure, to implement subroutine calls and returns. Each procedure call creates <hl> a new entry <hl>, called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls. Each stack frame contains the private data of the corresponding call, which typically includes the procedure's parameters and internal variables, and the return address.

Each procedure call creates <hl> a new entry <hl> , called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls.


Question: What do stack frames contain?

Answer: the private data of the corresponding call

Most modern implementations use a call stack, a special case of the stack data structure, to implement subroutine calls and returns. Each procedure call creates a new entry, called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls. <hl> Each stack frame contains the private data of the corresponding call , which typically includes the procedure's parameters and internal variables, and the return address. <hl>

Most modern implementations use a call stack, a special case of the stack data structure, to implement subroutine calls and returns. Each procedure call creates a new entry, called a stack frame, at the top of the stack; when the procedure returns, its stack frame is deleted from the stack, and its space may be used for other procedure calls. Each stack frame contains <hl> the private data of the corresponding call <hl>, which typically includes the procedure's parameters and internal variables, and the return address.

Each stack frame contains <hl> the private data of the corresponding call <hl> , which typically includes the procedure's parameters and internal variables, and the return address.


Question: Why were stack-based procedure calls introduced originally?

When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure. At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management.

Answer: to save precious memory

<hl> When stack-based procedure calls were first introduced, an important motivation was to save precious memory .[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure. <hl> At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management.

When stack-based procedure calls were first introduced, an important motivation was <hl> to save precious memory <hl>.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure. At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management.

When stack-based procedure calls were first introduced, an important motivation was <hl> to save precious memory <hl> .[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure.


Question: What does the stack contain?

Answer: the private data of the calls that are currently active

When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure. <hl> At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). <hl> Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management.

When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure. At any moment, the stack contains only <hl> the private data of the calls that are currently active <hl> (namely, which have been called but haven't returned yet). Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management.


Question: What is the call stack mechanism known for?

Answer: the earliest and simplest method for automatic memory management

When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure. At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. <hl> Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management . <hl>

When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure. At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. Indeed, the call stack mechanism can be viewed as <hl> the earliest and simplest method for automatic memory management <hl>.

Indeed, the call stack mechanism can be viewed as <hl> the earliest and simplest method for automatic memory management <hl> .


Question: What is private data?

Answer: parameters, return address, and local variables

<hl> When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data ( parameters, return address, and local variables ) of each procedure <hl> . At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management.

When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (<hl> parameters, return address, and local variables <hl>) of each procedure. At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management.

When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data ( <hl> parameters, return address, and local variables <hl> ) of each procedure


Question: What can the call stack mechanism help do?

Answer: could save significant amounts of memory.

When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure. At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). <hl> Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism could save significant amounts of memory. Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management. <hl>

When stack-based procedure calls were first introduced, an important motivation was to save precious memory.[citation needed] With this scheme, the compiler does not have to reserve separate space in memory for the private data (parameters, return address, and local variables) of each procedure. At any moment, the stack contains only the private data of the calls that are currently active (namely, which have been called but haven't returned yet). Because of the ways in which programs were usually assembled from libraries, it was (and still is) not uncommon to find programs that include thousands of subroutines, of which only a handful are active at any given moment.[citation needed] For such programs, the call stack mechanism <hl> could save significant amounts of memory. <hl> Indeed, the call stack mechanism can be viewed as the earliest and simplest method for automatic memory management.


Question: How do modern compilers reduce overhead?

This overhead is most obvious and objectionable in leaf procedures or leaf functions, which return without making any procedure calls themselves.
To reduce that overhead, many modern compilers try to delay the use of a call stack until it is really needed.[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump. If procedure P returns without making any other call, the call stack is not used at all. If P needs to call another procedure Q, it will then use the call stack to save the contents of any registers (such as the return address) that will be needed after Q returns.

Answer: delay the use of a call stack until it is really needed

This overhead is most obvious and objectionable in leaf procedures or leaf functions, which return without making any procedure calls themselves. <hl> To reduce that overhead, many modern compilers try to delay the use of a call stack until it is really needed .[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump. <hl> If procedure P returns without making any other call, the call stack is not used at all. If P needs to call another procedure Q, it will then use the call stack to save the contents of any registers (such as the return address) that will be needed after Q returns.

This overhead is most obvious and objectionable in leaf procedures or leaf functions, which return without making any procedure calls themselves. To reduce that overhead, many modern compilers try to <hl> delay the use of a call stack until it is really needed <hl>.[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump. If procedure P returns without making any other call, the call stack is not used at all. If P needs to call another procedure Q, it will then use the call stack to save the contents of any registers (such as the return address) that will be needed after Q returns.

To reduce that overhead, many modern compilers try to <hl> delay the use of a call stack until it is really needed <hl> .[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump.


Question: Where is overhead most obvious?

Answer: leaf procedures or leaf functions

<hl> This overhead is most obvious and objectionable in leaf procedures or leaf functions , which return without making any procedure calls themselves. <hl> To reduce that overhead, many modern compilers try to delay the use of a call stack until it is really needed.[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump. If procedure P returns without making any other call, the call stack is not used at all. If P needs to call another procedure Q, it will then use the call stack to save the contents of any registers (such as the return address) that will be needed after Q returns.

This overhead is most obvious and objectionable in <hl> leaf procedures or leaf functions <hl>, which return without making any procedure calls themselves. To reduce that overhead, many modern compilers try to delay the use of a call stack until it is really needed.[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump. If procedure P returns without making any other call, the call stack is not used at all. If P needs to call another procedure Q, it will then use the call stack to save the contents of any registers (such as the return address) that will be needed after Q returns.

This overhead is most obvious and objectionable in <hl> leaf procedures or leaf functions <hl> , which return without making any procedure calls themselves.


Question: What do leaf functions do?

Answer: return without making any procedure calls themselves

<hl> This overhead is most obvious and objectionable in leaf procedures or leaf functions, which return without making any procedure calls themselves . <hl> To reduce that overhead, many modern compilers try to delay the use of a call stack until it is really needed.[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump. If procedure P returns without making any other call, the call stack is not used at all. If P needs to call another procedure Q, it will then use the call stack to save the contents of any registers (such as the return address) that will be needed after Q returns.

This overhead is most obvious and objectionable in leaf procedures or leaf functions, which <hl> return without making any procedure calls themselves <hl>. To reduce that overhead, many modern compilers try to delay the use of a call stack until it is really needed.[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump. If procedure P returns without making any other call, the call stack is not used at all. If P needs to call another procedure Q, it will then use the call stack to save the contents of any registers (such as the return address) that will be needed after Q returns.

This overhead is most obvious and objectionable in leaf procedures or leaf functions, which <hl> return without making any procedure calls themselves <hl> .


Question: When is call stack not used?

Answer: If procedure P returns without making any other call

This overhead is most obvious and objectionable in leaf procedures or leaf functions, which return without making any procedure calls themselves. To reduce that overhead, many modern compilers try to delay the use of a call stack until it is really needed.[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump. <hl> If procedure P returns without making any other call , the call stack is not used at all. <hl> If P needs to call another procedure Q, it will then use the call stack to save the contents of any registers (such as the return address) that will be needed after Q returns.

This overhead is most obvious and objectionable in leaf procedures or leaf functions, which return without making any procedure calls themselves. To reduce that overhead, many modern compilers try to delay the use of a call stack until it is really needed.[citation needed] For example, the call of a procedure P may store the return address and parameters of the called procedure in certain processor registers, and transfer control to the procedure's body by a simple jump. <hl> If procedure P returns without making any other call <hl>, the call stack is not used at all. If P needs to call another procedure Q, it will then use the call stack to save the contents of any registers (such as the return address) that will be needed after Q returns.

<hl> If procedure P returns without making any other call <hl> , the call stack is not used at all.


Question: What are subprograms referred to as?

In the Visual Basic 6 language, subprograms are termed functions or subs (or methods when associated with a class). Visual Basic 6 uses various terms called types to define what is being passed as a parameter. By default, an unspecified variable is registered as a variant type and can be passed as ByRef (default) or ByVal. Also, when a function or sub is declared, it is given a public, private, or friend designation, which determines whether it can be accessed outside the module or project that it was declared in.

Answer: termed functions or subs

<hl> In the Visual Basic 6 language, subprograms are termed functions or subs (or methods when associated with a class). <hl> Visual Basic 6 uses various terms called types to define what is being passed as a parameter. By default, an unspecified variable is registered as a variant type and can be passed as ByRef (default) or ByVal. Also, when a function or sub is declared, it is given a public, private, or friend designation, which determines whether it can be accessed outside the module or project that it was declared in.

In the Visual Basic 6 language, subprograms are <hl> termed functions or subs <hl> (or methods when associated with a class). Visual Basic 6 uses various terms called types to define what is being passed as a parameter. By default, an unspecified variable is registered as a variant type and can be passed as ByRef (default) or ByVal. Also, when a function or sub is declared, it is given a public, private, or friend designation, which determines whether it can be accessed outside the module or project that it was declared in.


Question: What is the default setting for Visual Basic 6 Language?

Answer: an unspecified variable is registered as a variant type

In the Visual Basic 6 language, subprograms are termed functions or subs (or methods when associated with a class). Visual Basic 6 uses various terms called types to define what is being passed as a parameter. <hl> By default, an unspecified variable is registered as a variant type and can be passed as ByRef (default) or ByVal. <hl> Also, when a function or sub is declared, it is given a public, private, or friend designation, which determines whether it can be accessed outside the module or project that it was declared in.

In the Visual Basic 6 language, subprograms are termed functions or subs (or methods when associated with a class). Visual Basic 6 uses various terms called types to define what is being passed as a parameter. By default, <hl> an unspecified variable is registered as a variant type <hl> and can be passed as ByRef (default) or ByVal. Also, when a function or sub is declared, it is given a public, private, or friend designation, which determines whether it can be accessed outside the module or project that it was declared in.


Question: What is the name of the default setting?

Answer: ByRef (default) or ByVal

In the Visual Basic 6 language, subprograms are termed functions or subs (or methods when associated with a class). Visual Basic 6 uses various terms called types to define what is being passed as a parameter. <hl> By default, an unspecified variable is registered as a variant type and can be passed as ByRef (default) or ByVal . <hl> Also, when a function or sub is declared, it is given a public, private, or friend designation, which determines whether it can be accessed outside the module or project that it was declared in.

In the Visual Basic 6 language, subprograms are termed functions or subs (or methods when associated with a class). Visual Basic 6 uses various terms called types to define what is being passed as a parameter. By default, an unspecified variable is registered as a variant type and can be passed as <hl> ByRef (default) or ByVal <hl>. Also, when a function or sub is declared, it is given a public, private, or friend designation, which determines whether it can be accessed outside the module or project that it was declared in.

By default, an unspecified variable is registered as a variant type and can be passed as <hl> ByRef (default) or ByVal <hl> .


Question: What are subs?

Answer: methods when associated with a class

<hl> In the Visual Basic 6 language, subprograms are termed functions or subs (or methods when associated with a class ). <hl> Visual Basic 6 uses various terms called types to define what is being passed as a parameter. By default, an unspecified variable is registered as a variant type and can be passed as ByRef (default) or ByVal. Also, when a function or sub is declared, it is given a public, private, or friend designation, which determines whether it can be accessed outside the module or project that it was declared in.

In the Visual Basic 6 language, subprograms are termed functions or subs (or <hl> methods when associated with a class <hl>). Visual Basic 6 uses various terms called types to define what is being passed as a parameter. By default, an unspecified variable is registered as a variant type and can be passed as ByRef (default) or ByVal. Also, when a function or sub is declared, it is given a public, private, or friend designation, which determines whether it can be accessed outside the module or project that it was declared in.

In the Visual Basic 6 language, subprograms are termed functions or subs (or <hl> methods when associated with a class <hl> ).


Question: How many call sites can a subprogram have?

A subprogram may have any number and nature of call sites. If recursion is supported, a subprogram may even call itself, causing its execution to suspend while another nested execution of the same subprogram occurs. Recursion is a useful means to simplify some complex algorithms, and breaking down complex problems. Recursive languages generally provide a new copy of local variables on each call. If the programmer desires the value of local variables to stay the same between calls, they can be declared static in some languages, or global values or common areas can be used. Here is an example of recursive subroutine in C/C++ to find Fibonacci numbers:

Answer: any number and nature

<hl> A subprogram may have any number and nature of call sites. <hl> If recursion is supported, a subprogram may even call itself, causing its execution to suspend while another nested execution of the same subprogram occurs. Recursion is a useful means to simplify some complex algorithms, and breaking down complex problems. Recursive languages generally provide a new copy of local variables on each call. If the programmer desires the value of local variables to stay the same between calls, they can be declared static in some languages, or global values or common areas can be used. Here is an example of recursive subroutine in C/C++ to find Fibonacci numbers:

A subprogram may have <hl> any number and nature <hl> of call sites. If recursion is supported, a subprogram may even call itself, causing its execution to suspend while another nested execution of the same subprogram occurs. Recursion is a useful means to simplify some complex algorithms, and breaking down complex problems. Recursive languages generally provide a new copy of local variables on each call. If the programmer desires the value of local variables to stay the same between calls, they can be declared static in some languages, or global values or common areas can be used. Here is an example of recursive subroutine in C/C++ to find Fibonacci numbers:


Question: What is recursion?

Answer: to simplify some complex algorithms, and breaking down complex problems

A subprogram may have any number and nature of call sites. If recursion is supported, a subprogram may even call itself, causing its execution to suspend while another nested execution of the same subprogram occurs. <hl> Recursion is a useful means to simplify some complex algorithms, and breaking down complex problems . <hl> Recursive languages generally provide a new copy of local variables on each call. If the programmer desires the value of local variables to stay the same between calls, they can be declared static in some languages, or global values or common areas can be used. Here is an example of recursive subroutine in C/C++ to find Fibonacci numbers:

A subprogram may have any number and nature of call sites. If recursion is supported, a subprogram may even call itself, causing its execution to suspend while another nested execution of the same subprogram occurs. Recursion is a useful means <hl> to simplify some complex algorithms, and breaking down complex problems <hl>. Recursive languages generally provide a new copy of local variables on each call. If the programmer desires the value of local variables to stay the same between calls, they can be declared static in some languages, or global values or common areas can be used. Here is an example of recursive subroutine in C/C++ to find Fibonacci numbers:

Recursion is a useful means <hl> to simplify some complex algorithms, and breaking down complex problems <hl> .


Question: What happens is recursion occurs?

Answer: a subprogram may even call itself

A subprogram may have any number and nature of call sites. <hl> If recursion is supported, a subprogram may even call itself , causing its execution to suspend while another nested execution of the same subprogram occurs. <hl> Recursion is a useful means to simplify some complex algorithms, and breaking down complex problems. Recursive languages generally provide a new copy of local variables on each call. If the programmer desires the value of local variables to stay the same between calls, they can be declared static in some languages, or global values or common areas can be used. Here is an example of recursive subroutine in C/C++ to find Fibonacci numbers:

A subprogram may have any number and nature of call sites. If recursion is supported, <hl> a subprogram may even call itself <hl>, causing its execution to suspend while another nested execution of the same subprogram occurs. Recursion is a useful means to simplify some complex algorithms, and breaking down complex problems. Recursive languages generally provide a new copy of local variables on each call. If the programmer desires the value of local variables to stay the same between calls, they can be declared static in some languages, or global values or common areas can be used. Here is an example of recursive subroutine in C/C++ to find Fibonacci numbers:

If recursion is supported, <hl> a subprogram may even call itself <hl> , causing its execution to suspend while another nested execution of the same subprogram occurs.


Question: What happens when a subprogram calls itself due to recursion?

Answer: execution to suspend while another nested execution of the same subprogram occurs

A subprogram may have any number and nature of call sites. <hl> If recursion is supported, a subprogram may even call itself, causing its execution to suspend while another nested execution of the same subprogram occurs . <hl> Recursion is a useful means to simplify some complex algorithms, and breaking down complex problems. Recursive languages generally provide a new copy of local variables on each call. If the programmer desires the value of local variables to stay the same between calls, they can be declared static in some languages, or global values or common areas can be used. Here is an example of recursive subroutine in C/C++ to find Fibonacci numbers:

A subprogram may have any number and nature of call sites. If recursion is supported, a subprogram may even call itself, causing its <hl> execution to suspend while another nested execution of the same subprogram occurs <hl>. Recursion is a useful means to simplify some complex algorithms, and breaking down complex problems. Recursive languages generally provide a new copy of local variables on each call. If the programmer desires the value of local variables to stay the same between calls, they can be declared static in some languages, or global values or common areas can be used. Here is an example of recursive subroutine in C/C++ to find Fibonacci numbers:

If recursion is supported, a subprogram may even call itself, causing its <hl> execution to suspend while another nested execution of the same subprogram occurs <hl> .


Question: What happens when nested calls accumulate?

Modern languages after ALGOL such as PL/1 and C almost invariably use a stack, usually supported by most modern computer instruction sets to provide a fresh activation record for every execution of a subprogram. That way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. As nested calls accumulate, a call stack structure is formed, consisting of one activation record for each suspended subprogram. In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed stack frames.

Answer: call stack structure is formed

Modern languages after ALGOL such as PL/1 and C almost invariably use a stack, usually supported by most modern computer instruction sets to provide a fresh activation record for every execution of a subprogram. That way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. <hl> As nested calls accumulate, a call stack structure is formed , consisting of one activation record for each suspended subprogram. <hl> In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed stack frames.

Modern languages after ALGOL such as PL/1 and C almost invariably use a stack, usually supported by most modern computer instruction sets to provide a fresh activation record for every execution of a subprogram. That way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. As nested calls accumulate, a <hl> call stack structure is formed <hl>, consisting of one activation record for each suspended subprogram. In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed stack frames.

As nested calls accumulate, a <hl> call stack structure is formed <hl> , consisting of one activation record for each suspended subprogram.


Question: What does a call stack structure contain?

Answer: one activation record for each suspended subprogram

Modern languages after ALGOL such as PL/1 and C almost invariably use a stack, usually supported by most modern computer instruction sets to provide a fresh activation record for every execution of a subprogram. That way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. <hl> As nested calls accumulate, a call stack structure is formed, consisting of one activation record for each suspended subprogram . <hl> In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed stack frames.

Modern languages after ALGOL such as PL/1 and C almost invariably use a stack, usually supported by most modern computer instruction sets to provide a fresh activation record for every execution of a subprogram. That way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. As nested calls accumulate, a call stack structure is formed, consisting of <hl> one activation record for each suspended subprogram <hl>. In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed stack frames.

As nested calls accumulate, a call stack structure is formed, consisting of <hl> one activation record for each suspended subprogram <hl> .


Question: What are activation records referred to as?

Answer: stack frames

Modern languages after ALGOL such as PL/1 and C almost invariably use a stack, usually supported by most modern computer instruction sets to provide a fresh activation record for every execution of a subprogram. That way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. As nested calls accumulate, a call stack structure is formed, consisting of one activation record for each suspended subprogram. <hl> In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed stack frames . <hl>

Modern languages after ALGOL such as PL/1 and C almost invariably use a stack, usually supported by most modern computer instruction sets to provide a fresh activation record for every execution of a subprogram. That way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. As nested calls accumulate, a call stack structure is formed, consisting of one activation record for each suspended subprogram. In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed <hl> stack frames <hl>.

In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed <hl> stack frames <hl> .


Question: What are examples of modern languages?

Answer: PL/1 and C

<hl> Modern languages after ALGOL such as PL/1 and C almost invariably use a stack, usually supported by most modern computer instruction sets to provide a fresh activation record for every execution of a subprogram. <hl> That way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. As nested calls accumulate, a call stack structure is formed, consisting of one activation record for each suspended subprogram. In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed stack frames.

Modern languages after ALGOL such as <hl> PL/1 and C <hl> almost invariably use a stack, usually supported by most modern computer instruction sets to provide a fresh activation record for every execution of a subprogram. That way, the nested execution is free to modify its local variables without concern for the effect on other suspended executions in progress. As nested calls accumulate, a call stack structure is formed, consisting of one activation record for each suspended subprogram. In fact, this stack structure is virtually ubiquitous, and so activation records are commonly termed stack frames.


Question: What does reentrant mean?

If a subprogram can function properly even when called while another execution is already in progress, that subprogram is said to be reentrant. A recursive subprogram must be reentrant. Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can call the same subprogram without fear of interfering with each other. In the IBM CICS transaction processing system, quasi-reentrant was a slightly less restrictive, but similar, requirement for application programs that were shared by many threads.

Answer: a subprogram can function properly even when called while another execution is already in progress

<hl> If a subprogram can function properly even when called while another execution is already in progress , that subprogram is said to be reentrant. <hl> A recursive subprogram must be reentrant. Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can call the same subprogram without fear of interfering with each other. In the IBM CICS transaction processing system, quasi-reentrant was a slightly less restrictive, but similar, requirement for application programs that were shared by many threads.

If <hl> a subprogram can function properly even when called while another execution is already in progress <hl>, that subprogram is said to be reentrant. A recursive subprogram must be reentrant. Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can call the same subprogram without fear of interfering with each other. In the IBM CICS transaction processing system, quasi-reentrant was a slightly less restrictive, but similar, requirement for application programs that were shared by many threads.

If <hl> a subprogram can function properly even when called while another execution is already in progress <hl> , that subprogram is said to be reentrant.


Question: Is a recursive subprogram considered to be reentrant?

Answer: must be reentrant

If a subprogram can function properly even when called while another execution is already in progress, that subprogram is said to be reentrant. <hl> A recursive subprogram must be reentrant . <hl> Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can call the same subprogram without fear of interfering with each other. In the IBM CICS transaction processing system, quasi-reentrant was a slightly less restrictive, but similar, requirement for application programs that were shared by many threads.

If a subprogram can function properly even when called while another execution is already in progress, that subprogram is said to be reentrant. A recursive subprogram <hl> must be reentrant <hl>. Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can call the same subprogram without fear of interfering with each other. In the IBM CICS transaction processing system, quasi-reentrant was a slightly less restrictive, but similar, requirement for application programs that were shared by many threads.

A recursive subprogram <hl> must be reentrant <hl> .


Question: What is an advantage of having multiple threads?

Answer: call the same subprogram without fear of interfering with each other

If a subprogram can function properly even when called while another execution is already in progress, that subprogram is said to be reentrant. A recursive subprogram must be reentrant. <hl> Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can call the same subprogram without fear of interfering with each other . <hl> In the IBM CICS transaction processing system, quasi-reentrant was a slightly less restrictive, but similar, requirement for application programs that were shared by many threads.

If a subprogram can function properly even when called while another execution is already in progress, that subprogram is said to be reentrant. A recursive subprogram must be reentrant. Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can <hl> call the same subprogram without fear of interfering with each other <hl>. In the IBM CICS transaction processing system, quasi-reentrant was a slightly less restrictive, but similar, requirement for application programs that were shared by many threads.

Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can <hl> call the same subprogram without fear of interfering with each other <hl> .


Question: What is the purpose of quasi-reentrant?

Answer: slightly less restrictive

If a subprogram can function properly even when called while another execution is already in progress, that subprogram is said to be reentrant. A recursive subprogram must be reentrant. Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can call the same subprogram without fear of interfering with each other. <hl> In the IBM CICS transaction processing system, quasi-reentrant was a slightly less restrictive , but similar, requirement for application programs that were shared by many threads. <hl>

If a subprogram can function properly even when called while another execution is already in progress, that subprogram is said to be reentrant. A recursive subprogram must be reentrant. Reentrant subprograms are also useful in multi-threaded situations, since multiple threads can call the same subprogram without fear of interfering with each other. In the IBM CICS transaction processing system, quasi-reentrant was a <hl> slightly less restrictive <hl>, but similar, requirement for application programs that were shared by many threads.

In the IBM CICS transaction processing system, quasi-reentrant was a <hl> slightly less restrictive <hl> , but similar, requirement for application programs that were shared by many threads.


Question: How is a square root function defined?

In strongly typed languages, it is sometimes desirable to have a number of functions with the same name, but operating on different types of data, or with different parameter profiles. For example, a square root function might be defined to operate on reals, complex values or matrices. The algorithm to be used in each case is different, and the return result may be different. By writing three separate functions with the same name, the programmer has the convenience of not having to remember different names for each type of data. Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative.

Answer: to operate on reals, complex values or matrices

In strongly typed languages, it is sometimes desirable to have a number of functions with the same name, but operating on different types of data, or with different parameter profiles. <hl> For example, a square root function might be defined to operate on reals, complex values or matrices . <hl> The algorithm to be used in each case is different, and the return result may be different. By writing three separate functions with the same name, the programmer has the convenience of not having to remember different names for each type of data. Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative.

In strongly typed languages, it is sometimes desirable to have a number of functions with the same name, but operating on different types of data, or with different parameter profiles. For example, a square root function might be defined <hl> to operate on reals, complex values or matrices <hl>. The algorithm to be used in each case is different, and the return result may be different. By writing three separate functions with the same name, the programmer has the convenience of not having to remember different names for each type of data. Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative.

For example, a square root function might be defined <hl> to operate on reals, complex values or matrices <hl> .


Question: What is desirable in strongly typed languages?

Answer: number of functions with the same name, but operating on different types of data, or with different parameter profiles

<hl> In strongly typed languages, it is sometimes desirable to have a number of functions with the same name, but operating on different types of data, or with different parameter profiles . <hl> For example, a square root function might be defined to operate on reals, complex values or matrices. The algorithm to be used in each case is different, and the return result may be different. By writing three separate functions with the same name, the programmer has the convenience of not having to remember different names for each type of data. Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative.

In strongly typed languages, it is sometimes desirable to have a <hl> number of functions with the same name, but operating on different types of data, or with different parameter profiles <hl>. For example, a square root function might be defined to operate on reals, complex values or matrices. The algorithm to be used in each case is different, and the return result may be different. By writing three separate functions with the same name, the programmer has the convenience of not having to remember different names for each type of data. Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative.

In strongly typed languages, it is sometimes desirable to have a <hl> number of functions with the same name, but operating on different types of data, or with different parameter profiles <hl> .


Question: What is the advantage of separate functions?

Answer: not having to remember different names for each type of data

In strongly typed languages, it is sometimes desirable to have a number of functions with the same name, but operating on different types of data, or with different parameter profiles. For example, a square root function might be defined to operate on reals, complex values or matrices. The algorithm to be used in each case is different, and the return result may be different. <hl> By writing three separate functions with the same name, the programmer has the convenience of not having to remember different names for each type of data . <hl> Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative.

In strongly typed languages, it is sometimes desirable to have a number of functions with the same name, but operating on different types of data, or with different parameter profiles. For example, a square root function might be defined to operate on reals, complex values or matrices. The algorithm to be used in each case is different, and the return result may be different. By writing three separate functions with the same name, the programmer has the convenience of <hl> not having to remember different names for each type of data <hl>. Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative.

By writing three separate functions with the same name, the programmer has the convenience of <hl> not having to remember different names for each type of data <hl> .


Question: How can two functions be written?

Answer: one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative

In strongly typed languages, it is sometimes desirable to have a number of functions with the same name, but operating on different types of data, or with different parameter profiles. For example, a square root function might be defined to operate on reals, complex values or matrices. The algorithm to be used in each case is different, and the return result may be different. By writing three separate functions with the same name, the programmer has the convenience of not having to remember different names for each type of data. <hl> Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative . <hl>

In strongly typed languages, it is sometimes desirable to have a number of functions with the same name, but operating on different types of data, or with different parameter profiles. For example, a square root function might be defined to operate on reals, complex values or matrices. The algorithm to be used in each case is different, and the return result may be different. By writing three separate functions with the same name, the programmer has the convenience of not having to remember different names for each type of data. Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, <hl> one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative <hl>.

Further if a subtype can be defined for the reals, to separate positive and negative reals, two functions can be written for the reals, <hl> one to return a real when the parameter is positive, and another to return a complex value when the parameter is negative <hl> .


Question: What might a subroutine construct?

As another example, a subroutine might construct an object that will accept directions, and trace its path to these points on screen. There are a plethora of parameters that could be passed in to the constructor (colour of the trace, starting x and y co-ordinates, trace speed). If the programmer wanted the constructor to be able to accept only the color parameter, then he could call another constructor that accepts only color, which in turn calls the constructor with all the parameters passing in a set of default values for all the other parameters (X and Y would generally be centered on screen or placed at the origin, and the speed would be set to another value of the coder's choosing).

Answer: an object that will accept directions

<hl> As another example, a subroutine might construct an object that will accept directions , and trace its path to these points on screen. <hl> There are a plethora of parameters that could be passed in to the constructor (colour of the trace, starting x and y co-ordinates, trace speed). If the programmer wanted the constructor to be able to accept only the color parameter, then he could call another constructor that accepts only color, which in turn calls the constructor with all the parameters passing in a set of default values for all the other parameters (X and Y would generally be centered on screen or placed at the origin, and the speed would be set to another value of the coder's choosing).

As another example, a subroutine might construct <hl> an object that will accept directions <hl>, and trace its path to these points on screen. There are a plethora of parameters that could be passed in to the constructor (colour of the trace, starting x and y co-ordinates, trace speed). If the programmer wanted the constructor to be able to accept only the color parameter, then he could call another constructor that accepts only color, which in turn calls the constructor with all the parameters passing in a set of default values for all the other parameters (X and Y would generally be centered on screen or placed at the origin, and the speed would be set to another value of the coder's choosing).

As another example, a subroutine might construct <hl> an object that will accept directions <hl> , and trace its path to these points on screen.


Question: What parameters could be passed in to the constructor?

Answer: colour of the trace, starting x and y co-ordinates, trace speed

As another example, a subroutine might construct an object that will accept directions, and trace its path to these points on screen. <hl> There are a plethora of parameters that could be passed in to the constructor ( colour of the trace, starting x and y co-ordinates, trace speed ). <hl> If the programmer wanted the constructor to be able to accept only the color parameter, then he could call another constructor that accepts only color, which in turn calls the constructor with all the parameters passing in a set of default values for all the other parameters (X and Y would generally be centered on screen or placed at the origin, and the speed would be set to another value of the coder's choosing).

As another example, a subroutine might construct an object that will accept directions, and trace its path to these points on screen. There are a plethora of parameters that could be passed in to the constructor (<hl> colour of the trace, starting x and y co-ordinates, trace speed <hl>). If the programmer wanted the constructor to be able to accept only the color parameter, then he could call another constructor that accepts only color, which in turn calls the constructor with all the parameters passing in a set of default values for all the other parameters (X and Y would generally be centered on screen or placed at the origin, and the speed would be set to another value of the coder's choosing).

There are a plethora of parameters that could be passed in to the constructor ( <hl> colour of the trace, starting x and y co-ordinates, trace speed <hl> ).


Question: What would the programmer do if he/she wanted the constructor to be able to accept only the color parameter?

Answer: he could call another constructor that accepts only color,

As another example, a subroutine might construct an object that will accept directions, and trace its path to these points on screen. There are a plethora of parameters that could be passed in to the constructor (colour of the trace, starting x and y co-ordinates, trace speed). <hl> If the programmer wanted the constructor to be able to accept only the color parameter, then he could call another constructor that accepts only color, which in turn calls the constructor with all the parameters passing in a set of default values for all the other parameters (X and Y would generally be centered on screen or placed at the origin, and the speed would be set to another value of the coder's choosing). <hl>

As another example, a subroutine might construct an object that will accept directions, and trace its path to these points on screen. There are a plethora of parameters that could be passed in to the constructor (colour of the trace, starting x and y co-ordinates, trace speed). If the programmer wanted the constructor to be able to accept only the color parameter, then <hl> he could call another constructor that accepts only color, <hl> which in turn calls the constructor with all the parameters passing in a set of default values for all the other parameters (X and Y would generally be centered on screen or placed at the origin, and the speed would be set to another value of the coder's choosing).


Question: What does the constructor that accept only color call in return?

Answer: the constructor with all the parameters passing in a set of default values for all the other parameters

As another example, a subroutine might construct an object that will accept directions, and trace its path to these points on screen. There are a plethora of parameters that could be passed in to the constructor (colour of the trace, starting x and y co-ordinates, trace speed). <hl> If the programmer wanted the constructor to be able to accept only the color parameter, then he could call another constructor that accepts only color, which in turn calls the constructor with all the parameters passing in a set of default values for all the other parameters (X and Y would generally be centered on screen or placed at the origin, and the speed would be set to another value of the coder's choosing). <hl>

As another example, a subroutine might construct an object that will accept directions, and trace its path to these points on screen. There are a plethora of parameters that could be passed in to the constructor (colour of the trace, starting x and y co-ordinates, trace speed). If the programmer wanted the constructor to be able to accept only the color parameter, then he could call another constructor that accepts only color, which in turn calls <hl> the constructor with all the parameters passing in a set of default values for all the other parameters <hl> (X and Y would generally be centered on screen or placed at the origin, and the speed would be set to another value of the coder's choosing).


Question: What do proponents of modular programming advocate?

Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code. For example, the use of global variables is generally deemed unwise by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables. If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead. However, increasing the number of parameters passed to subroutines can affect code readability.

Answer: that each subroutine should have minimal dependency on other pieces of code

<hl> Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code . <hl> For example, the use of global variables is generally deemed unwise by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables. If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead. However, increasing the number of parameters passed to subroutines can affect code readability.

Proponents of modular programming (modularizing code) advocate <hl> that each subroutine should have minimal dependency on other pieces of code <hl>. For example, the use of global variables is generally deemed unwise by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables. If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead. However, increasing the number of parameters passed to subroutines can affect code readability.

Proponents of modular programming (modularizing code) advocate <hl> that each subroutine should have minimal dependency on other pieces of code <hl> .


Question: Why is the use of global variables generally deemed unwise?

Answer: because it adds tight coupling between the subroutine and these global variables

Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code. <hl> For example, the use of global variables is generally deemed unwise by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables . <hl> If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead. However, increasing the number of parameters passed to subroutines can affect code readability.

Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code. For example, the use of global variables is generally deemed unwise by advocates for this perspective, <hl> because it adds tight coupling between the subroutine and these global variables <hl>. If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead. However, increasing the number of parameters passed to subroutines can affect code readability.

For example, the use of global variables is generally deemed unwise by advocates for this perspective, <hl> because it adds tight coupling between the subroutine and these global variables <hl> .


Question: What is the use of global variables generally deemed to be?

Answer: unwise

Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code. <hl> For example, the use of global variables is generally deemed unwise by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables. <hl> If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead. However, increasing the number of parameters passed to subroutines can affect code readability.

Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code. For example, the use of global variables is generally deemed <hl> unwise <hl> by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables. If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead. However, increasing the number of parameters passed to subroutines can affect code readability.


Question: What is programmers' advice if such coupling is not necessary?

Answer: to refactor subroutines to accept passed parameters instead

Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code. For example, the use of global variables is generally deemed unwise by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables. <hl> If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead . <hl> However, increasing the number of parameters passed to subroutines can affect code readability.

Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code. For example, the use of global variables is generally deemed unwise by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables. If such coupling is not necessary, their advice is <hl> to refactor subroutines to accept passed parameters instead <hl>. However, increasing the number of parameters passed to subroutines can affect code readability.

If such coupling is not necessary, their advice is <hl> to refactor subroutines to accept passed parameters instead <hl> .


Question: What's the consequence of increasing the number of parameters passed to subroutines?

Answer: can affect code readability

Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code. For example, the use of global variables is generally deemed unwise by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables. If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead. <hl> However, increasing the number of parameters passed to subroutines can affect code readability . <hl>

Proponents of modular programming (modularizing code) advocate that each subroutine should have minimal dependency on other pieces of code. For example, the use of global variables is generally deemed unwise by advocates for this perspective, because it adds tight coupling between the subroutine and these global variables. If such coupling is not necessary, their advice is to refactor subroutines to accept passed parameters instead. However, increasing the number of parameters passed to subroutines <hl> can affect code readability <hl>.

However, increasing the number of parameters passed to subroutines <hl> can affect code readability <hl> .


Question: What is involved in runtime overhead in calling a subroutine?

There is a significant runtime overhead in a calling a subroutine, including passing the arguments, branching to the subprogram, and branching back to the caller. The overhead often includes saving and restoring certain processor registers, allocating and reclaiming call frame storage, etc.. In some languages, each subroutine call also implies automatic testing of the subroutine's return code, or the handling of exceptions that it may raise. In object-oriented languages, a significant source of overhead is the intensively used dynamic dispatch for method calls.

Answer: passing the arguments, branching to the subprogram, and branching back to the caller

<hl> There is a significant runtime overhead in a calling a subroutine, including passing the arguments, branching to the subprogram, and branching back to the caller . <hl> The overhead often includes saving and restoring certain processor registers, allocating and reclaiming call frame storage, etc.. In some languages, each subroutine call also implies automatic testing of the subroutine's return code, or the handling of exceptions that it may raise. In object-oriented languages, a significant source of overhead is the intensively used dynamic dispatch for method calls.

There is a significant runtime overhead in a calling a subroutine, including <hl> passing the arguments, branching to the subprogram, and branching back to the caller <hl>. The overhead often includes saving and restoring certain processor registers, allocating and reclaiming call frame storage, etc.. In some languages, each subroutine call also implies automatic testing of the subroutine's return code, or the handling of exceptions that it may raise. In object-oriented languages, a significant source of overhead is the intensively used dynamic dispatch for method calls.

There is a significant runtime overhead in a calling a subroutine, including <hl> passing the arguments, branching to the subprogram, and branching back to the caller <hl> .


Question: What does the overhead often include?

Answer: saving and restoring certain processor registers, allocating and reclaiming call frame storage

There is a significant runtime overhead in a calling a subroutine, including passing the arguments, branching to the subprogram, and branching back to the caller. <hl> The overhead often includes saving and restoring certain processor registers, allocating and reclaiming call frame storage , etc.. <hl> In some languages, each subroutine call also implies automatic testing of the subroutine's return code, or the handling of exceptions that it may raise. In object-oriented languages, a significant source of overhead is the intensively used dynamic dispatch for method calls.

There is a significant runtime overhead in a calling a subroutine, including passing the arguments, branching to the subprogram, and branching back to the caller. The overhead often includes <hl> saving and restoring certain processor registers, allocating and reclaiming call frame storage <hl>, etc.. In some languages, each subroutine call also implies automatic testing of the subroutine's return code, or the handling of exceptions that it may raise. In object-oriented languages, a significant source of overhead is the intensively used dynamic dispatch for method calls.

The overhead often includes <hl> saving and restoring certain processor registers, allocating and reclaiming call frame storage <hl> , etc..


Question: What does each subroutine call also imply in some languages?

Answer: automatic testing of the subroutine's return code, or the handling of exceptions that it may raise

There is a significant runtime overhead in a calling a subroutine, including passing the arguments, branching to the subprogram, and branching back to the caller. The overhead often includes saving and restoring certain processor registers, allocating and reclaiming call frame storage, etc.. <hl> In some languages, each subroutine call also implies automatic testing of the subroutine's return code, or the handling of exceptions that it may raise . <hl> In object-oriented languages, a significant source of overhead is the intensively used dynamic dispatch for method calls.

There is a significant runtime overhead in a calling a subroutine, including passing the arguments, branching to the subprogram, and branching back to the caller. The overhead often includes saving and restoring certain processor registers, allocating and reclaiming call frame storage, etc.. In some languages, each subroutine call also implies <hl> automatic testing of the subroutine's return code, or the handling of exceptions that it may raise <hl>. In object-oriented languages, a significant source of overhead is the intensively used dynamic dispatch for method calls.

In some languages, each subroutine call also implies <hl> automatic testing of the subroutine's return code, or the handling of exceptions that it may raise <hl> .


Question: What is the intensively used dynamic dispatch for method calls in object=oriented languages?

Answer: a significant source of overhead

There is a significant runtime overhead in a calling a subroutine, including passing the arguments, branching to the subprogram, and branching back to the caller. The overhead often includes saving and restoring certain processor registers, allocating and reclaiming call frame storage, etc.. In some languages, each subroutine call also implies automatic testing of the subroutine's return code, or the handling of exceptions that it may raise. <hl> In object-oriented languages, a significant source of overhead is the intensively used dynamic dispatch for method calls. <hl>

There is a significant runtime overhead in a calling a subroutine, including passing the arguments, branching to the subprogram, and branching back to the caller. The overhead often includes saving and restoring certain processor registers, allocating and reclaiming call frame storage, etc.. In some languages, each subroutine call also implies automatic testing of the subroutine's return code, or the handling of exceptions that it may raise. In object-oriented languages, <hl> a significant source of overhead <hl> is the intensively used dynamic dispatch for method calls.