EmbeddedRelated.com
Forums

TAIL CALL

Started by B September 17, 2012
DOES IAR COMPILE TAIL CALLS CORRECTLY??
I TRIED EVERYTHING AN I COULDN'T BUT MAYBE I AM DOING SOMETHING WRONG.

THANKS
B

Beginning Microcontrollers with the MSP430

I don't understand the question, what is a tail call?

--- In m..., B wrote:
>
> DOES IAR COMPILE TAIL CALLS CORRECTLY??
> I TRIED EVERYTHING AN I COULDN'T BUT MAYBE I AM DOING SOMETHING WRONG.
>
> THANKS
> B
>

On Mon, Sep 17, 2012 at 8:30 AM, lslonim2 wrote:

> I don't understand the question, what is a tail call?

A "tail call" is the condition of a recursive function where the
recursive call is the return value. It is important because tail
calls (or tail recursion) can always be implemented as iteration, that
is, without adding a stack frame on the call stack.

The simple answer would be to look at the machine code generated by
your compiler. I'm sure there are some uC developers who would say
to ignore the elegance of the recursive function and simply re-write
the function iteratively. There is a chance this could optimize even
better, and you are certainly not going to get burned if you switch to
a different compiler that does not optimize tail recursion.

-p.
--- In m..., Peter Johansson wrote:
>
> On Mon, Sep 17, 2012 at 8:30 AM, lslonim2 wrote:
>
> > I don't understand the question, what is a tail call?
>
> A "tail call" is the condition of a recursive function where the
> recursive call is the return value. It is important because tail
> calls (or tail recursion) can always be implemented as iteration, that
> is, without adding a stack frame on the call stack.
>
> The simple answer would be to look at the machine code generated by
> your compiler. I'm sure there are some uC developers who would say
> to ignore the elegance of the recursive function and simply re-write
> the function iteratively. There is a chance this could optimize even
> better, and you are certainly not going to get burned if you switch to
> a different compiler that does not optimize tail recursion.
>
> -p.
>

Exactly. I have checked the asm generated by the compiler, and I couldn't make the compiler use tail recursion. Maybe it is not implemented. So, I did it iteratively.

B

On 17/09/12 15:40, Peter Johansson wrote:
> On Mon, Sep 17, 2012 at 8:30 AM, lslonim2 > > wrote:
>
> > I don't understand the question, what is a tail call?
>
> A "tail call" is the condition of a recursive function where the
> recursive call is the return value. It is important because tail
> calls (or tail recursion) can always be implemented as iteration, that
> is, without adding a stack frame on the call stack.
>
> The simple answer would be to look at the machine code generated by
> your compiler. I'm sure there are some uC developers who would say
> to ignore the elegance of the recursive function and simply re-write
> the function iteratively. There is a chance this could optimize even
> better, and you are certainly not going to get burned if you switch to
> a different compiler that does not optimize tail recursion.
>
> -p.
>

You don't have to use recursion to get tail call optimisation - it is a
common optimisation whenever a function ends with a call to another
function.

Turning a true recursive function into an iterative one is far from a
trivial optimisation, and is often not possible even in theory. So
don't expect a compiler to do it automatically in many cases.

Don't know if this is "tail call" or "tail branch". But using IAR, if I have:

{
...
return sub(...);
}

The compiler will not generate code to "call sub();" and return what sub(); returns. It does simply "br sub();" instead.

On 21/09/12 02:35, old_cow_yellow wrote:
> Don't know if this is "tail call" or "tail branch". But using IAR, if I
> have:
>
> {
> ...
> return sub(...);
> }
>
> The compiler will not generate code to "call sub();" and return what
> sub(); returns. It does simply "br sub();" instead.
>

That is tail call optimisation, and it's quite common in compilers (at
least in simple cases when a stack frame is not needed).