It would be my pleasure :) I'll refer to jonesforth [1], but I think the lessons apply to the other Forth's I've seen. The main core of a Forth is generally w

It would be my pleasure :) I'll refer to jonesforth [1], but I think the lessons apply to the other Forth's I've seen. The main core of a Forth is generally written in assembly to bridge the specifics of a processing unit and the canonical Forth words. For instance, most control flow words are defined in Forth, but a couple critical ones are implemented in assembly and "exported" up to the higher level words. [2] The main task of the core is to bootstrap to a sufficiently powerful yet abstract dictionary of words that will allow a full Forth to flourish. But to get there, you'll have to make a lot of choices that will be constrained by your chip (Intel x86, x86_64, ARM, Z80, etc). The big one is type of interpreter (direct threaded, indirect threaded, etc). In jonesforth, check out the docs and implementation of NEXT [3]. The choice was guided by a quirk of the Intel instruction set that allowed loading the memory pointed by esi into eax and incrementing esi all in one step; further, Intel x86 allows an indirect jump to the address stored in a register (eax). Not all instruction sets support this pattern, you'll have to experiment and investigate for various chips. That choice is a critical one, but it's one of many. Where do you store the dictionary of words? How do you implement DOCOL? What registers will you preserve? Why? What instructions will you expose? Which ones will you hide? Will you allow new words to be created with machine code? In C, much of this has been decided by others decades ago (existing operating system ABI choices, mainly). In Forth, you can try things out and only be restricted by the chips, which is what all of us are ultimately constrained by, even fancy-pants languages like Rust and Go :) Once you get past the core into Forth, some of the computer details recede, but you usually have to be somewhat aware of how you are using the system, far more than modern programming languages. Forth is the ultimate deep-dive "language" [4], but that is as much a curse as a blessing. Basically, use Forth for the understanding it provides, then go back to making good software in typical languages aided by the enlightenment you've attained :) [1] https://github.com/nornagon/jonesforth/blob/master/jonesforth.S https://github.com/nornagon/jonesforth/blob/master/jonesfort... [2] https://github.com/nornagon/jonesforth/blob/master/jonesforth.S#L1989 https://github.com/nornagon/jonesforth/blob/master/jonesfort... [3] https://github.com/nornagon/jonesforth/blob/master/jonesforth.S#L227 https://github.com/nornagon/jonesforth/blob/master/jonesfort... [4] I've actually stopped calling Forth a programming language; programming system captures the idea a little better, I find.