Path: csiph.com!aioe.org!.POSTED!not-for-mail From: Rod Pemberton Newsgroups: comp.lang.forth Subject: Re: tail call elimination Date: Thu, 7 Jan 2016 05:33:37 -0500 Organization: Aioe.org NNTP Server Lines: 42 Message-ID: <20160107053337.1c4e6ef6@_> References: NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Claws Mail 3.13.1 (GTK+ 2.24.10; x86_64-unknown-linux-gnu) Xref: csiph.com comp.lang.forth:44659 On Wed, 6 Jan 2016 05:19:56 -0800 (PST) Johan Kotlinski 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