Recursion Question

  • Thread starter Thread starter AMP
  • Start date Start date
A

AMP

I have the following simple recursion and as I unwind the call stack
(stepping through it), I am trying figure out where the eventual
return value is being stored. Any help is appreciated.
Thanks
Mike

namespace Factorial
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
label1.Text = Factorial(5).ToString();
}

public int Factorial(int n)
{
if(n==0) return 1;
return n * Factorial(n-1);
}
}
}
 
I have the following simple recursion and as I unwind the call stack
(stepping through it), I am trying figure out where the eventual
return value is being stored. Any help is appreciated.
private void button1_Click(object sender, EventArgs e)
{
label1.Text = Factorial(5).ToString();
}

public int Factorial(int n)
{
if(n==0) return 1;
return n * Factorial(n-1);
}

The C# compiler and the CLR JIT compiler may do all kinds
of optimizations.

But before the optimization it will use the stack
to store the n's and a register for function result.

Arne
 
AMP said:
I have the following simple recursion and as I unwind the call stack
(stepping through it), I am trying figure out where the eventual
return value is being stored. Any help is appreciated.
Thanks
Mike

namespace Factorial
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
label1.Text = Factorial(5).ToString();
}

public int Factorial(int n)
{
if(n==0) return 1;
return n * Factorial(n-1);
}
}
}

At the time the call to the next inner nesting is made there is no result yet
from the current invocation - said result depends on the value returned from the
next nested recursive call, after all. And as function results are typically
returned in registers, there is not necessarily a need for a place on the stack
(or heap) to store it.

In any case, any work space allocated by the runtime during the function
execution, including storage for intermediate results, would not have a symbolic
name that the debugger would know anything about. Your best bet for tracing the
entire execution flow so as to see the generation and disposition of the final
result might be to disassemble your program to MSIL and trace through that. It
is a good exercise if, as I gather, you are just curious about how it
(recursion) manages to work at all.


HTH,
-rick-
 
At the time the call to the next inner nesting is made there is no resultyet
from the current invocation - said result depends on the value returned from the
next nested recursive call, after all.  And as function results are typically
returned in registers, there is not necessarily a need for a place on thestack
(or heap) to store it.

In any case, any work space allocated by the runtime during the function
execution, including storage for intermediate results, would not have a symbolic
name that the debugger would know anything about.  Your best bet for tracing the
entire execution flow so as to see the generation and disposition of the final
result might be to disassemble your program to MSIL and trace through that.  It
is a good exercise if, as I gather, you are just curious about how it
(recursion) manages to work at all.

HTH,
-rick-- Hide quoted text -

- Show quoted text -

Rick and Arne,
Great explanations.
Thanks
 
Back
Top