Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Newsgroups: comp.lang.forth Subject: Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Date: Mon, 16 Sep 2024 16:26:51 GMT Organization: Institut fuer Computersprachen, Technische Universitaet Wien Lines: 86 Message-ID: <2024Sep16.182651@mips.complang.tuwien.ac.at> References: <66d26c4b$1@news.ausics.net> <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> <87seu01zbj.fsf@nightsong.com> Injection-Date: Mon, 16 Sep 2024 19:28:46 +0200 (CEST) Injection-Info: dont-email.me; posting-host="30716ef6ab1ebd867530a5bb0a7c7e47"; logging-data="3129219"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/4XaZBs/rb7iWmnOReugho" Cancel-Lock: sha1:m9PmxH/WaSw+EP7Pe4XV7T5ADLE= X-newsreader: xrn 10.11 Bytes: 5339 Paul Rubin writes: >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? That, too, but the elimination of the ELSE has more weight with me. In the VICHECK ( pindex paddr -- pindex' paddr ) case this favours the locals-less code. For a word that is similar in having an IF where only one side has to do something other than to make sure that the stack effect is satisfied, but with the stack effect ( x1 x2 -- ), the advantage s with locals code: : WORD1 {: x1 x2 -- :} ... ( f ) if ( ) ... x1 ... x2 ... then ; : WORD2 ( x1 x2 -- ) ... ( f ) if ( x1 x2 ) ... else 2drop then ; Forth has a special word ?DUP for one specific variant of this situation, but it helps only in specific cases. >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. I think he had the aversion long before he did such hardware designs. He has been quoted as thinking that humans should do all they can to make the computer's work easier (or something like that). While his sayings, like any religious text, are sufficiently fuzzy to be interpretable in many ways, his denouncing of locals over the years makes it clear that he thinks that humans should invest time to write code with stack manipulation words and globals, so that the compiler does not need to be bloated by the code for dealing with locals. >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 I don't think that the CRISP lived long enough for the real problems to become big: In contrast to GPRs or the stacks of Chuck Moore's chips, the stack accesses in CRISP alias with potentially all memory accesses, so every load of a C variable on a stack may potentially have to produce the result of a preceding store (and it often actually is the result of the previous instruction). In the last four decades, CPU designers have invented a number of techniques for predicting when loads don't alias earlier stores, and for fast store-to-load forwarding when they do, but these techniques are not cheap. Even today, a CPU can do maybe 3 loads and two stores, while they can deal with a dozen or so input operands in registers, and maybe 6 output operands in registers. The CRISP's successors would have been uncompetetive soon after introduction, and I doubt that they would ever have reached competetive performance. >I remember the SPARC had "register windows" but I don't know if that's >similar or what went wrong with them. Not at all similar. Register windows were a window into a larger register file, no aliasing with memory at all; that was treated as a stack of register windows. In a similar vein (all heritage of Berkeley RISC) were the AMD 29K's and the IA-64's register stack. It's interesting that Forthers were never excited about that; the register stack allows to push or pop individual registers instead of register windows. I think the pushing and popping is not a cheap operation, so you would want to use it only at the call, but you could have used it for one of the Forth stacks, and avoided some memory accesses that way. - anton -- M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html New standard: https://forth-standard.org/ EuroForth 2024: https://euro.theforth.net