Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.forth
Subject: Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!]
Date: Tue, 10 Sep 2024 04:26:51 -0700
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <87bk0vbvgk.fsf@nightsong.com>
References: <nnd$61e0ad9a$48ed61c2@b4d945e456041481>
	<vasqjd$icjm$1@dont-email.me> <66d26c4b$1@news.ausics.net>
	<vaubf7$tbke$1@dont-email.me> <nnd$04cff141$0193ba04@301336b8dd8ed69a>
	<vbfqnd$v4c4$1@dont-email.me> <nnd$26b4d59b$27bdb181@ce638e508b04426e>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 10 Sep 2024 13:26:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5421477f7a879778ddcfb611042653ee";
	logging-data="3083749"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+lDNoU73qbRisgJu7yTAPS"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:ZMO09wSTiGznXjisAebOa5kOSKE=
	sha1:YtSvMgU4765yMNnf46daTmp7L7E=
Bytes: 2662

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> What bothers me most technologically is that parameters flow through
> the stack undisturbed. You break that paradigm when using locals. With 
> locals you *HAVE TO* create some kind of stack frame that you have to
> destroy when you exit.

Forth programs very frequently end up juggling parameters and other data
to and from the return stack, instead of using locals.  Simple
implementations of locals put them in the return stack too.
"Destroying" the stack frame just means adjusting RP when the function
exits.  Usually a single instruction.

> Needless to say this copying, releasing and stuff takes time.

Similar to DUP (copy) or DROP (release).

> In all honesty I must state that this overhead is not always
> translated to a diminished performance

Right, I don't think one can assert a performance hit without
measurements supporting the idea.

> TL;DR my objections are mostly based on pure architectural arguments,
> rather than practicality. 

Sure, that's reasonable, it's a matter of what you prefer.  That's
harder to take issue with than claims about performance.

> I also don't like Python, PHP and Perl for those very same reasons -

Those are at a totally different level than Forth, in terms of layers of
implementation and runtime libraries, overhead, etc.  It's better to
compare to something like C, or a hypothetical cleaned up version of C,
or even to Forth with locals ;).