Forth is a stack-based language, so it does really well on a stack-based CPU. Optimizers for common languages like C perform analysis on which values in a function are more commonly used, and want to control whether those values live in registers or RAM; register based CPU ISAs can give them more fine-grained control.

But if you're working in Forth, everything is stack ops anyway, you wouldn't benefit much from that kind of analysis, and really a stack-based CPU is going to give you the most speed because the most common operations boil down to a single instruction per.

Chuck Moore doesn't mind this because he writes literally everything in Forth. Most of us who work in other languages would mind the performance hit.

> Forth is a stack-based language, so it does really well on a stack-based CPU.

But IIRC so is JVM (Java), CIL (C#), and Python's bytecode, so why did op single out Forth and omit those?..

And webassembly. I wonder if we'll see dedicated wasm accelerators at some point.

Is there a need, with WASM implementations generating native code? Jazelle tried that for the JVM on ARM, but I also get the impression that compilers made Jazelle unnecessary.

tbf on Moore's CPUs, stack ops boil down to a fractional instruction. (because there are multiple ops per architectural I-space word)