Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #44629
| Newsgroups | comp.lang.forth |
|---|---|
| Date | 2016-01-06 05:59 -0800 |
| References | <be97e063-c1fa-4a18-8dfd-8e4099a281a6@googlegroups.com> |
| Message-ID | <adacbfe4-2130-4dbd-b611-e2f2cbb58c8d@googlegroups.com> (permalink) |
| Subject | Re: tail call elimination |
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
miercuri, 6 ianuarie 2016, 15:19:58 UTC+2, Johan Kotlinski a scris: > 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. > > The way I worked around this is to manually tag words like r> with a special flag, no-tail-call-elimination. Obviously this manual tagging is very error prone, it is easy to forget, and errors can go unnoticed for a long time. > > Surely others must have run into this problem before, are there better ways to do it? > > Thanks, > Johan Tail call elimination always has to check if it is possible or not. You already implemented some checks for sure, because when you need to compile the exit it's not always a previous CALL (JSR) compiled, maybe it is something else, a literal, some inline code, whatever. So in the same tail call elimination check procedure you have to check for >R and the stuff too. There is no workaround. The implementation is up to you, a flag bit, direct address comparing, etc. What I don't understand is your concern about being error prone. How many >R words or the like are you having in the system? And what's easy to forget?
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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