Sure! One fantastic starting point is Lisp in Small Pieces, which shows you how to build multiple different Lisp interpreters, and then several increasingly fancy Lisp compilers.

The trick with a macro-assembler that uses Lisp macros to generate assembly was basically folklore when I learned it, and I haven't seen it fully fleshed out anywhere in the literature. For a tiny chip, you'd run this as a cross compiler from a bigger machine. But you basically have Lisp macros that expand to other Lisp macros that eventually expand to assembly representated as s-expressions.

As for why basic Lisps are register-hungry, you usually reserve an "environment pointer register", which points to closure data or scope data associated with the currently running function. And then you might also want a "symbol table base" register, which points to interned symbols. The first symbol value (located directly where the symbol register points) should be 'nil', which is both "false" and the "empty list". This allows you to check Boolean expressions and check for the empty list with a single register-to-register comparison, and it makes checks against other built-in symbols much cheaper. So now you've sacrificed 2 registers to the Lisp gods. If you have 8 registers, this is fine. If you have 4 registers, it's going to hurt but you can do it. If you have something like the 65C02, which has an 8-bit accumulator and two sort-of-flexible index registers, you're going to have to get ridiculously clever.

Of course, working at this level is a bit like using #[no_std] in Rust. You won't have garbage collection yet, and you may not even have a memory allocator until you write one. There are a bunch of Lisp bootstrapping dialects out there with names like "pre-Scheme" if you want to get a feel for this.

Forth is a stack machine, so you basically just need a stack pointer, and a couple of registers that can be used to implement basic operations.

Anyway, Lisp in Small Pieces is fantastic, and it contains a ton of the old tricks and tradeoffs.

I was just looking at Factor yesterday. I find it cool that it was originally created as a scripting language for a game engine.

> Anything that you say is missing can be added.

For sure, it can be extended indefinitely. It's good that you made that clear. You can add a C compiler if you like (see Dusk OS) even, or a generic BNF parser generator (see Bradford Rodriguez) into "the language". Anything that you devise for code correctness, and static analysis can be added. My points about the lack of these language features were towards the previous comment about FORTH looking "more high-level than C". These are definitely major shortcoming for an inexperienced programmer to be able to do anything reasonably complex in FORTH (similar to using assembly).

> ... I would create a word that did something in a balanced way, test it quickly, and use that word instead to build on. Forth makes it easy to climb the levels abstraction quickly.

I would say any programming language with functions provide the same ease by that definition. That is, in each you can write a set of functions, than use them to compose higher level functions ad infinitum until you create a DSL as essentially a collection of functions for your problem space. Although doing so in C-like languages syntactically it may look more like Lisp than FORTH. In FORTH it looks more concise, and reads left-to-right thanks to it being accidentally a "concatenative language" with point-free notation and combinatory calculus roots. A great example of this being formalized is Joy by Manfred von Thun.

So I think what makes FORTH unique is more of the philosophy around it (again, see POL book by Chuck), which is a kind of zealous struggle for simplicity, but not easy, and keeping the problem in focus and not ignoring what's inside the boxes you build upon. You could say it's a panacea for yak-shaving if done right. Concrete examples for what FORTH does away in its search for simplicity and avoidance of yak-shaving, here are a few:

- no in-fix notation or ASTs: computers understand post/reverse-Polish by default by virtue of them being a stack(/register) machine, the programmer can do this work without major difficulty, - no filesystem: blocks and table of block indices are enough most of the time, - no floating point: fixed point is good enough for most problems, - no classes, arrays, structs: you can build your own constructs suited for your problem as they are needed, there is no one size fits all solution,

Etc. The list goes on. Some of these are added into the so-called standards, but some argue trying to standardize FORTH defeats itself.

> The method that it uses to interpret/compile a word varies by implementation. Subroutine call is just one of them.

I used a vague terminology there, and should have clarified by saying "regardless of the threading model". What I meant was that effectively the FORTH source compilation is a one step pass that converts string tokens into series of "subroutine" (conceptually) calls that map 1:1 with the source code (homoiconicity); direct/indirected threaded, token threaded, or subroutine threaded all effectively is laying out/interpreting a series of subroutine calls, including those in FORTH CPUs like Harris RTX or GA144.