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


Groups > comp.lang.forth > #44659

Re: tail call elimination

From Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm>
Newsgroups comp.lang.forth
Subject Re: tail call elimination
Date 2016-01-07 05:33 -0500
Organization Aioe.org NNTP Server
Message-ID <20160107053337.1c4e6ef6@_> (permalink)
References <be97e063-c1fa-4a18-8dfd-8e4099a281a6@googlegroups.com>

Show all headers | View raw


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

Back to comp.lang.forth | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

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

csiph-web