Date: Sun, 26 Apr 2026 19:55:06 +1000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FP stack depth limitations Newsgroups: comp.lang.forth References: <10qunhm$1nnbt$1@dont-email.me> <10r1825$2d8j6$1@dont-email.me> <69db0856$1@news.ausics.net> <871pg66epy.fsf@nightsong.com> <87wlxw45wh.fsf@nightsong.com> <69ec2328$1@news.ausics.net> <87jytv4kkl.fsf@nightsong.com> <69ecae51$1@news.ausics.net> <877bpu49d1.fsf@nightsong.com> <2026Apr26.075504@mips.complang.tuwien.ac.at> <87y0ia2nax.fsf@nightsong.com> Content-Language: en-GB From: dxf In-Reply-To: <87y0ia2nax.fsf@nightsong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit NNTP-Posting-Host: news.ausics.net Message-ID: <69ede0fa@news.ausics.net> Organization: Ausics - https://newsgroups.ausics.net Lines: 18 X-Complaints: abuse@ausics.net Path: csiph.com!news.bbs.nz!news.ausics.net!not-for-mail Xref: csiph.com comp.lang.forth:134984 On 26/04/2026 5:28 pm, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> In any case, it does not help with FP stack limitations at all, >> because N>R transfers cells from the data stack to the return stack. > > In the code I mentioned, I wasn't running out of FP stack space, but > rather, I didn't see how to write the function in any non-horrible way > without using FP locals. Horrible ways included: 1) implementing a > separate FP stack in memory for intermediate values during the > recursion, or 2) using ugly hacks to stash FP values on the regular data > stack. > > N>R was suggested as a way to implement horribleness #2 but it would > actually have to be FN>R or something like that. Probably the flocals are more complicated but users rarely look beyond the interface.