does CCS supports tail recursion?

[shailesh]

hi all,

I m new joiny.
I read that most of the compiler auto detect tail recursion in
program. can any body tell me that is Code compoaser studio for TI dsp
supports?

rgds,

[Ian Collins]

shailesh wrote:

hi all,

I m new joiny.
I read that most of the compiler auto detect tail recursion in
program. can any body tell me that is Code compoaser studio for TI dsp
supports?

Try one of their support forums, your question is OT here.

--
Ian Collins.

[jacob navia]

shailesh wrote:

hi all,

I m new joiny.
I read that most of the compiler auto detect tail recursion in
program. can any body tell me that is Code compoaser studio for TI dsp
supports?

rgds,

I suppose that if you write:

int main(void)
{
return main();
}

You will have an infinite loop if it DOES support
tail recursion, a stack fault (trap) if it doesn't...

P.S. Maybe the processor you are using doesn't have any
memory protection. In that case use a printf statement
before the call to main to see if there is other kind of problem.

#include <stdio.h>
int main(void)
{
printf("ignore this\n");
return main();
}

An infinite loop will look different than a stack overflow with
this setup.

[shailesh]

On Aug 5, 3:35 pm, jacob navia <[e-mail] mcomp.frwrote:

shailesh wrote:

hi all,

I m new joiny.
I read that most of the compiler auto detect tail recursion in
program. can any body tell me that is Code compoaser studio for TI dsp
supports?

rgds,

I suppose that if you write:

int main(void)
{
return main();

}

You will have an infinite loop if it DOES support
tail recursion, a stack fault (trap) if it doesn't...

P.S. Maybe the processor you are using doesn't have any
memory protection. In that case use a printf statement
before the call to main to see if there is other kind of problem.

#include <stdio.h>
int main(void)
{
printf("ignore this\n");
return main();

}

An infinite loop will look different than a stack overflow with
this setup.

thanks Jacob,
I could find out it using ur suggession.:)
It does not support:(

[Richard Tobin]

In article <46************ ***@yahoo.com>,
CBFalconer <cb********@mai neline.netwrote :

>Whenever the last action of the routine is to call itself with
revised parameters, this can obviously be replaced by a loop.

Not necessarily. For example, consider the case where the address
of a local variable is passed.

And of course self-call is just the simplest example of tail call.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[jacob navia]

Richard Tobin wrote:

In article <46************ ***@yahoo.com>,
CBFalconer <cb********@mai neline.netwrote :

>Whenever the last action of the routine is to call itself with
revised parameters, this can obviously be replaced by a loop.

Not necessarily. For example, consider the case where the address
of a local variable is passed.

And of course self-call is just the simplest example of tail call.

-- Richard

Why would it matter?

suppose that as the last action you make
return sameproc(2,3,&l ocal);

Since the value of "local" can't ever be used after
the call returns, it doesn't matter at all.

jacob

[Chris Dollin]

jacob navia wrote:

Richard Tobin wrote:

>In article <46************ ***@yahoo.com>,
CBFalconer <cb********@mai neline.netwrote :

>>Whenever the last action of the routine is to call itself with
revised parameters, this can obviously be replaced by a loop.

Not necessarily. For example, consider the case where the address
of a local variable is passed.

And of course self-call is just the simplest example of tail call.

-- Richard

Why would it matter?

suppose that as the last action you make
return sameproc(2,3,&l ocal);

Since the value of "local" can't ever be used after
the call returns, it doesn't matter at all.

I'm afraid you are mistaken, since the address of `local` can be used
/inside the call of `sameproc`/. Hence it's important that `local`
continue to exist, hence (in the usual implementation) that the
stack frame it's in continues to exist, hence you can't do the
straightforward stack-frame elimination part of tail-call optimisation.

Consider this horrible sketch of an example:

Answer example( Args x, struct Ex *uplink )
{
if (terminationCon dition( x ))
{
return dependsOnUplink ChainAndX( x, uplink );
}
else
{
struct Ex another;
another.uplink = uplink;
another.stuff = hackeryOn( x );
return example( shrink( x ), &another );
}
}

The recursive call can't be TCOd; the number of `another` elements
needed depends on how much `x` needs to be shrunk before meeting
the termination condition, so you can't junk the stack frames.

--
Chris "tails can't speak, never mind /call/." Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Richard Tobin]

In article <46************ ***********@new s.orange.fr>,
jacob navia <ja***@jacob.re mcomp.frwrote:

>Not necessarily. For example, consider the case where the address
of a local variable is passed.

>Why would it matter?

suppose that as the last action you make
return sameproc(2,3,&l ocal);

Since the value of "local" can't ever be used after
the call returns, it doesn't matter at all.

The second activation of sameproc needs to have its own version of
"local" which is distinct from the one in the first activation.

For example, you could build a linked list out of stack-allocated cons
cells (though of course you couldn't return it). More realistically,
you might have local structures representing some kind of environment
that contain a pointer to the passed-in parent environment.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[jacob navia]

Chris Dollin wrote:

jacob navia wrote:

>Richard Tobin wrote:

>>In article <46************ ***@yahoo.com>,
CBFalconer <cb********@mai neline.netwrote :

Whenever the last action of the routine is to call itself with
revised parameters, this can obviously be replaced by a loop.
Not necessarily. For example, consider the case where the address
of a local variable is passed.

And of course self-call is just the simplest example of tail call.

-- Richard

Why would it matter?

suppose that as the last action you make
return sameproc(2,3,&l ocal);

Since the value of "local" can't ever be used after
the call returns, it doesn't matter at all.

I'm afraid you are mistaken, since the address of `local` can be used
/inside the call of `sameproc`/. Hence it's important that `local`
continue to exist, hence (in the usual implementation) that the
stack frame it's in continues to exist, hence you can't do the
straightforward stack-frame elimination part of tail-call optimisation.

Consider this horrible sketch of an example:

Answer example( Args x, struct Ex *uplink )
{
if (terminationCon dition( x ))
{
return dependsOnUplink ChainAndX( x, uplink );
}
else
{
struct Ex another;
another.uplink = uplink;
another.stuff = hackeryOn( x );
return example( shrink( x ), &another );
}
}

The recursive call can't be TCOd; the number of `another` elements
needed depends on how much `x` needs to be shrunk before meeting
the termination condition, so you can't junk the stack frames.

Thanks, I see now. Will remember next time I try to implement
that optimization. I have considered doing it, but never got into
that.

[jacob navia]

Richard Tobin wrote:

In article <46************ ***********@new s.orange.fr>,
jacob navia <ja***@jacob.re mcomp.frwrote:

>>Not necessarily. For example, consider the case where the address
of a local variable is passed.

>Why would it matter?

suppose that as the last action you make
return sameproc(2,3,&l ocal);

Since the value of "local" can't ever be used after
the call returns, it doesn't matter at all.

The second activation of sameproc needs to have its own version of
"local" which is distinct from the one in the first activation.

For example, you could build a linked list out of stack-allocated cons
cells (though of course you couldn't return it). More realistically,
you might have local structures representing some kind of environment
that contain a pointer to the passed-in parent environment.

-- Richard

Thanks, I did not see that possibility.

jacob