Portability is one of Gforth's goals, and it has achieved it quite
well. While there has been special code that made some targets faster
than others, it always was possible to use portable code that worked
everywhere. Over time the architecture-specific code got faster, but
the generic code did, too.

In the beginning we had indirect-threaded code as portable variant,
and direct-threaded code as architecture-specific variant (typically
~10% faster, but sometimes much slower on the Pentium).

At some point we switched to hybrid direct/indirect-threaded code
(http://www.complang.tuwien.ac.at/papers/ertl02.ps.gz), which gave us
the performance advantage of direct-threaded code without requiring
architecture-specific code (and without performance pitfalls on the
Pentium and later Intel and AMD CPUs).

This was the stepping stone for dynamic superinstructions
<http://www.complang.tuwien.ac.at/papers/ertl%26gregg03euroforth.ps.gz>,
but dynamic superinstructions again needed architecture-specific code
to make sure that the code written by the program makes it from the
D-cache to the I-cache (on architectures that do not keep them
synchronized automatically), so dynamic superinstructions (and
optimizations that build on them) used to be disabled in the generic
case.

At some point GNU C acquired the builtin function
__builtin___clear_cache(), which performs exactly the function for
which we had used architecture-specific code. It took us a long time
to notice this, but eventually we did, and built a check for this
function into Gforth. If it is present, even a Gforth variant built
on an unknown architecture can make use of dynamic superinstructions
(and optimizations that build on them); gcc does not implement this
function correctly on every architecture
<https://gcc.gnu.org/bugzilla//show_bug.cgi?id=93811>
<https://gcc.gnu.org/bugzilla//show_bug.cgi?id=91248>, but these are
architectures where we (and apparently everybody else who needs this
functionality) already have architecture-specific code, so they are
not a problem.

Today this function saw productive use: We got a VisionFive V1 board
from Starfive (a RISC-V-based SBC), and built Gforth on it. While we
had a look at building Gforth on an emulated RISC-V at the 2017
Forth-Tagung, this has not resulted in any RISC-V-dependent code in
Gforth, so what I did today was just the same as for any new
architecture. And it got dynamic superinstructions and the
optimizations that build on it out of the box, without adding any
architecture-dependent code.

I also tried if "./configure STACK_CACHE_REGS=3" (using three
registers for caching stack items) is beneficial (it depends on the
amount of callee-saved registers), and it turned out to be so. So I
added code to our configure script so it uses this setting on RISC-V
by default. We could automate trying this out, but it would increase
the build time considerably. If somebody comes across a new
architecture, they can try it out manually. While this feature is
architecture-independent, we have a different default setting on some
architectures than on the others.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021