By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,983 Members | 1,717 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,983 IT Pros & Developers. It's quick & easy.

does CCS supports tail recursion?

P: n/a
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,

Aug 5 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
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.
Aug 5 '07 #2

P: n/a
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.
Aug 5 '07 #3

P: n/a
On Aug 5, 3:35 pm, jacob navia <ja...@jacob.remcomp.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:(

Aug 5 '07 #4

P: n/a
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Aug 6 '07 #5

P: n/a
Richard Tobin wrote:
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.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,&local);

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

jacob
Aug 6 '07 #6

P: n/a
jacob navia wrote:
Richard Tobin wrote:
>In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.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,&local);

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 (terminationCondition( x ))
{
return dependsOnUplinkChainAndX( 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

Aug 6 '07 #7

P: n/a
In article <46***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.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,&local);

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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Aug 6 '07 #8

P: n/a
Chris Dollin wrote:
jacob navia wrote:
>Richard Tobin wrote:
>>In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.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,&local);

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 (terminationCondition( x ))
{
return dependsOnUplinkChainAndX( 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.

Aug 6 '07 #9

P: n/a
Richard Tobin wrote:
In article <46***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.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,&local);

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
Aug 6 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.