Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #44628 > unrolled thread

tail call elimination

Back to article view | Back to comp.lang.forth

Contents

  tail call elimination Johan Kotlinski <kotlinski@gmail.com> - 2016-01-06 05:19 -0800
    Re: tail call elimination Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 05:59 -0800
      Re: tail call elimination Johan Kotlinski <kotlinski@gmail.com> - 2016-01-06 06:18 -0800
        Re: tail call elimination Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 06:47 -0800
          Re: tail call elimination Johan Kotlinski <kotlinski@gmail.com> - 2016-01-06 08:57 -0800
          Re: tail call elimination Johan Kotlinski <kotlinski@gmail.com> - 2016-01-08 00:40 -0800
            Re: tail call elimination Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-08 01:21 -0800
              Re: tail call elimination Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-08 01:23 -0800
    Re: tail call elimination stephen@mpeforth.com (Stephen Pelc) - 2016-01-06 14:42 +0000
      Re: tail call elimination Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 07:07 -0800
        Re: tail call elimination stephen@mpeforth.com (Stephen Pelc) - 2016-01-07 01:02 +0000
        Re: tail call elimination hughaguilar96@gmail.com - 2016-01-06 22:26 -0800
        Re: tail call elimination Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-08 03:18 +0100
          Re: tail call elimination hughaguilar96@gmail.com - 2016-01-07 21:11 -0800
          Re: tail call elimination Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-08 04:16 -0600
    Re: tail call elimination rickman <gnuarm@gmail.com> - 2016-01-06 12:24 -0500
      Re: tail call elimination "Elizabeth D. Rather" <erather@forth.com> - 2016-01-06 08:50 -1000
    Re: tail call elimination Pablo Hugo Reda <pabloreda@gmail.com> - 2016-01-06 17:29 -0800
    Re: tail call elimination Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-01-07 10:56 +0100
      Re: tail call elimination Coos Haak <chforth@hccnet.nl> - 2016-01-07 12:41 +0100
        Re: tail call elimination Mux <Yvo.Zoer@gmail.com> - 2016-01-07 16:44 -0800
    Re: tail call elimination Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-07 05:33 -0500

Page 2 of 2 — ← Prev page 1 [2]

#44669

I created an option whether or not the compiler would eliminate tail calls. IMO it's completely up to the programmer to make sure this stuff works. That's one of the things I like about (machine) forth. It's a simple language and you know exactly what's going on under the hood.
If you chose to turn on tail call elimination you better make sure your words are short and don't mess with the return stack unless that's the behavior you expect.

my 2 cents.

-Mux

[toc] | [prev] | [next] | [standalone]

#44659

On Wed, 6 Jan 2016 05:19:56 -0800 (PST)
Johan Kotlinski <kotlinski@gmail.com> wrote:

> Hi, I would like to bring up the problem of tail call elimination. I
> have it working in my STC Forth, but I am not too happy about my
> implementation and thought I should check if anyone has better ideas.
> 
> The basic idea is of course very simple: If the generated machine
> code ends with
> 
>   jsr XT ; jump to subroutine
>   rts
> 
> replace with
> 
>   jmp XT
>
> The problem is words like r>, which copies from the return stack to
> the parameter stack. If it is jmp'd instead of jsr'd to, a crash will
> happen, because the return address was never pushed and r> addressing
> will be off.

If the usage of R> is for an R> DROP sequence as EXIT then
there is nothing to do ...  Remove the R> DROP sequence
from the code.

I.e., this is only an issue if the address obtained by
an R> is modified and returned to the return stack, or some
other return address is pushed to the return stack.  These
actions will change the flow of execution, i.e., branch/jump
somewhere else.

As Hugh noted, what your code is doing not allowed for ANS.
So, why is the code doing this? ...  I.e., using mismatched
return stack operations R> >R or use of R@ with non-placed
return values.  E.g., R> DROP as an optional definition for
a high-level EXIT was the only situation I ran into with my
ITC Forth.


Rod Pemberton

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web