Write one! Forths are so simple that you can write one in minutes if you understand it, and a bit more if you don't know anything about it. Having your own forth is both really gratifying, and gives you an opportunity to play around with the internals and change things up to see what happens (and why the choices made were made).

Forth is one of the languages where you have to know the internals to write it, but the internals are really simple.

I'd recommend gforth. It runs on lots of systems and is well maintained.

https://gforth.org/

Eventually you'll build your own forth (seems to be a right of passage!)

I'm no Forth expert, but I've found Gforth highly educational. It's interactive, runs under Linux, is free software, supports the ANS standard, is well documented, is widely used (at least as widely used as any Forth these days), is still maintained after 27 years, and supports SEE so you can disassemble words and see how they're written. Since Gforth 1.0 it has context-sensitive help ("help begin", etc.) Before Gforth I used PFE, which shares most of these attributes.

Richard W. M. Jones's Jonesforth is pretty interesting reading, and maybe the best explanation around of how to build a Forth, but keep in mind he wasn't by any means a Forth expert when he wrote it; at first he had the rotation direction backwards for ROT. But he was already a first-class hacker, and that matters more.

But more recently my understanding of Forth has changed. I never did understand why such a janky programming language had such enthusiastic fans; even though C doesn't have closures, C is a better programming language for any situation that doesn't involve an existing Forth codebase, and for many situations that do.

My epiphany was that Forth isn't a programming language. I mean, it does have a programming language in it, but it's not a very good programming language, just the tiniest step past assembly language that can give you structured control flow and nested expressions. What's excellent about Forth is that it contains an interactive programming system with virtual memory, multithreading, compile-time metaprogramming, higher-order run-time programming, and instant recompilation, in about 8 kilobytes of memory. You can even get a substantial fraction of it in much less than that.

You know how it's useful to be able to log into the flaky web or database server and run some commands to see what's going on, maybe restart an errant process or two, or tweak a config file parameter? (Even if you don't actually do this because you push all your config changes through Git and Kubernetes, surely you've at least felt the temptation if you've ever administered a server.) Forth gives you an interactive shell on almost the tiniest microcontrollers, and it's a scriptable interactive shell that has full access to the machine's I/O ports and memory. Which is what you want when you're trying to get a weird new peripheral working. You want an interactive environment (maybe like target debugging with GDB, but with a more efficient scripting language, or OpenOCD), not a batch-mode setup where every new experiment requires waiting for a compile and reflash.

It's in that spirit that Frank Sergeant described his 66-byte target-debugging stub/bootloader for the 68HC11, which has 192 bytes of RAM, as a "three-instruction Forth": https://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html It clearly isn't a programming language he's after.

And, from that point of view, things like Gforth and Jonesforth are likely to mislead, because they're "Forth without Forth": the Forth language, but without the Forth "operating system", and only runnable in environments that are far too large to justify the tradeoffs Forth makes. They do work, but they aren't compelling.

I think this is sort of like conflating Unix with bash. People who use Unix intensively tend to use bash intensively (or, previously, tcsh or ksh, and nowadays sometimes oil, zsh, or fish, but usually bash). And part of the reason for that is that you can actually whip up some pretty cool stuff pretty quickly as a shell script. For example, here's a thing I wrote in a few minutes the other day which generates a random incorrect acronym expansion for "STC" (reformatted for readability):

    echo stc | while :;
    do
      dd of=/tmp/tmp.c.$$ bs=1 count=1 2>/dev/null;
      c=$(cat /tmp/tmp.c.$$);
      if [ -z "$c" ]; then break; fi;
      grep "^$c" /usr/share/dict/words | 
        shuf -n 1 | 
        tr '\n' ' ';
    done; echo

Result:

    spoil transform circumference 

But imagine trying to apply bash in an environment without disk caching for your filesystem, multitasking, grep, cat, dd, shuf, tr, or /usr/share/dict/words. All you're left with is the programming language! And bash is honestly a pretty shitty programming language. You'd wonder why anybody ever bothered with Unix in the first place! And that's because Unix isn't bash or the Bourne shell. They're an important part of it but not the bulk of it; bash outside of the context that makes it so insanely useful is a bit like a fish out of water, or maybe an elevator operator in a modern automatic elevator.

I don't know what embedded Forth to recommend, though, because I've never actually used Forth on a microcontroller. The only time I've ever used Forth without another OS under it is in OpenBootPROM/OpenFirmware. So I might be all wrong about this! Hopefully more experienced people can correct me. Paging DonHopkins! Paging abecedarius!

See Starting Forth by the same author; it's good and short. It is even older, so it won't help on choosing an implementation and will be affected by a few differences in dialect.

For the forths, pforth is certainly portable, pfe on windows, 8th is ok. ficl is supposed to be for scripting, awhile back (years) measured and it turns out its the fastest one in certain cases.

For the new agey stuff I'd say start with factor if you're on x86. if you're not maybe try retro[0], or write your own.

[0]: http://forthworks.com/retro/