Deutsch   English   Français   Italiano  
<87seu01zbj.fsf@nightsong.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!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: Sun, 15 Sep 2024 12:39:28 -0700
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <87seu01zbj.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>
	<87bk0vbvgk.fsf@nightsong.com> <66e0fa58$1@news.ausics.net>
	<66e11d64$1@news.ausics.net> <877cbh4b6z.fsf@nightsong.com>
	<2024Sep12.105526@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sun, 15 Sep 2024 21:39:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5321994d6d6ba23f84e0622f042553ae";
	logging-data="2459302"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/c0O7or3zd/vgYoqXyWVln"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:MHKabZE967gJTyfCRuDuXdP5q4s=
	sha1:LY3UQoQ+R1zQ2eS7UpbgXeqIVKk=
Bytes: 2478

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> So by keeping the values on the stack you not just eliminate their
> repeated mention, but also eliminate one branch of the IF.

Is the repeated mention just a matter of DRY, assuming the compiler puts
the locals in registers so that the extra mention doesn't transfer them
between stacks a second time?  I do prefer your version where you factor
out VIERROR.

I wonder whether Moore's 1999 aversion to locals had something to do
with his hardware designs of that era, where having more registers
(besides T and N) connected to the ALU would have cost silicon and
created timing bottlenecks.  Today's mainstream processors have GPR's
anyway, but I wonder what the real problem was with stack caches like
the CRISP:  https://thechipletter.substack.com/p/at-and-ts-crisp-hobbits

Commenters there say CRISP failed basically because its early
implementation was buggy, it lost an important design win because of the
bugs, and AT&T management then gave up on it.

I remember the SPARC had "register windows" but I don't know if that's
similar or what went wrong with them.