Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.forth
Subject: Re: locals
Date: Fri, 01 May 2026 23:50:04 -0700
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <87pl3e2tlv.fsf@nightsong.com>
References: <10qunhm$1nnbt$1@dont-email.me> <10r1825$2d8j6$1@dont-email.me> <nnd$7d2e6a4e$3bd4aa4f@294189cda32d8f1f> <nnd$5fbdae9b$6428335d@7ddbf5ece7eb9625> <nnd$4d4782db$73d0020c@69cc4648be712fe3> <69db0856$1@news.ausics.net> <871pg66epy.fsf@nightsong.com> <2026Apr25.064712@mips.complang.tuwien.ac.at> <87o6j74l1z.fsf@nightsong.com> <2026Apr25.084323@mips.complang.tuwien.ac.at> <87340i46vi.fsf@nightsong.com> <2026Apr26.115059@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sat, 02 May 2026 06:50:04 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="2086224"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19dqf+0zCHF1wyyD/K2n7s7"; posting-host="ba054269875f2ad3fe21291289399423"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:DYui1mJT4YDQBO2tN7xrPDPa3cs= sha1:bl7XpxjbZzCpYKz6lv4dIcPrAEs=
Xref: csiph.com comp.lang.forth:135049

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> If you cannot chose the names... You might then just as well work with
> >R >R >R >R and R@, R'@, 2 RPICK and 3 RPICK.

That actually might be a workable idea. Thanks.

> In the code you see the threaded code interspersed with the native
> code.  If you ignore the native code, you see what a simple
> interpreter would see (if it had a locals implementation that produced
> code similar to that of Gforth).

I wonder if gforth would get less code bloat if you added some
primitives for pushing more than one local.  E.g. 2>L, 3>L, etc. would
push that many stack elements to LOCAL0, LOCAL1, LOCAL2.  Then there
wouldn't be that big chunk of replicated code.

> So it's "code cleanup", not making use of hardware facilities for
> efficiency on simple interpreters, that you see as the benefit of
> locals.

Well, I had hoped to get both, but yeah, ultimately cleaner and more
reliable code takes precedence in most situations, by the 90/10 rule.

> Even with multi-representation stack-caching as used since Gforth 0.7
> (which does require more compiler smarts), no statically determined
> stack effect is necessary, because the code generator returns to the
> canonical state on control-flow.

I see, yeah, but that means stack juggling to get to the canonical
state.

> ... we have user variables like BASE and HLD (in F83, HOLDPTR in
> gforth).  They are used across multiple words, and the fact that you
> don't have to pass them and put them into a local has been touted as
> an advantage over locals: Definitions that use global variables are
> easier to factor.

Urgggh...