C is a sure bet. Interpreters that rely too much on JIT are simply not available on processors where the JIT is not available (duh), which was often the case for ARM before it became really popular. Same thing with relying on an emulator (also, you are running a VM in another kind of VM; it's usually bad for performance).
As far as speed is concerned, if your Forth implementation makes it really easy to extend, you can always get something fast enough by re-coding the critical parts in C. That's why I stopped worrying about which implementation technique is the fastest and chose the one that made it the most trivial to extend the interpreter.
I like that, it appeals to my sense of pragmatism.
I wrote a Joy interpreter in Nim the other day, and when it came time to switch from machine ints to BigInts it was a breeze. There was a library already written, I updated the type and the compiler told me what else to change, the whole thing was over in fifteen minutes. And if I ever find that integer math is a performance bottleneck there is also a wrapper for GMP ready to go.
- - - -
BTW, I'm a big fan of Oberon, and I think Astrobe is awesome and admire you for making and supporting it. Cheers!
For Forth implementations, although I suspect it might be yourself (you gotta admit this sort of fetish is not very common ;-), Charles Childers [1] is collecting them.
Nowadays it's sometimes adequately fast to implement a JIT by spawning gcc or tcc and then running dlopen() on the result ;) It also makes the FFI easier :)
The dlopen trick is something I'll remember if I need that sort of stuff, but I've grown wary of FFIs. With libraries, there's often #define constants or macros that make FFIs a bit awkward. I prefer to use static linking if the lib is not too big, or dynamic loading but still with light bindings if not. If you know a bit the internals of Lua, I use a very similar method to extend Forth's "vocabulary", and the loading (and manual linkink with dlsym) is done only when the extension is invoked and initializes itself.
Over on the "αcτµαlly pδrταblε εxεcµταblε" page ( https://justine.lol/ape.html ) there's a subsection called "x86-64 Linux ABI Makes a Pretty Good Lingua Franca" it seems to me to be a reasonable suggestion (although I've never like x86 myself.) You can bundle an x86 emulator with your code to run on other architectures.
I like the Project Oberon 32-bit RISC developed by Prof. Wirth as a target. It's really simple for educational purposes. (Meaning you can more easily teach more people Oberon RISC than, say, RISC-V. ALthough see the "Selfie" project: https://selfie.cs.uni-salzburg.at/ "An educational software system of a tiny self-compiling C compiler, a tiny self-executing RISC-V emulator, and a tiny self-hosting RISC-V hypervisor.")
There are many emulators for Oberon RISC already, including one in Javascript, so you can run the old Oberon OS in your browser! Launch an emulator with a disk image from here: https://schierlm.github.io/OberonEmulator/