Sectorlisp[0] is an attempt to make a lisp that can fit in a bootsector (512 bytes). It's currently ~1.5 bootsectors; larger than the smallest forths, but certainly in the same ballpark.
Stage0[1] is an attempt to make a boostrappable seed from a minimum of binary dependencies. I recommend taking a look at what it says[2] on the matter, though it's too long to quote here.
0. https://github.com/jart/sectorlisp
1. https://savannah.nongnu.org/projects/stage0/
2. https://git.savannah.nongnu.org/cgit/stage0.git/tree/README.... skip to ‘stage2’
If you want something closer to assembly, you can just use a normal Lisp and have the Lisp compile itself to an assembly program, but with the benefit of things like variable names whatever other abstractions you can come up with. This approach is taken by Fairlylog[1] which is implemented in Racket but produces Verilog. You are basically writing a new language which compiles to assembly, but with the benefit of better tooling. Racket gives you the benefit of things like syntax-parse for writing the parser in a way that gives good error messages and more flexibility than a parser generator.
You've described region-based memory management, also known as arena allocation. [0] This can indeed work nicely in short-lived applications like missile-guidance and even serious compilers. [1] It's not real garbage collection though.
[0] https://en.wikipedia.org/wiki/Region-based_memory_management
[1] https://web.archive.org/web/20190126213344/https://www.drdob...
Do you have any resources handy on how one could do that from scratch?
I wrote several Forth compilers when learning to code as a teenager, one using the A86 assembler, and two fully bootstrapped-from-assembler ones for 8086 and 386. The 8086 source code is here (I didn't write the assembler myself): https://github.com/benhoyt/third (KERNEL.F has the assembler parts)
[1] https://github.com/nornagon/jonesforth/blob/master/jonesfort...
The key point is that Forth can easily incorporate an RPN assembler which you can write in Forth, and with which you can then build a better Forth. I'm not sure if I even started with the official TI assembler for the chip; I probably first wrote a cross assembler in Mach 2 by transcribing the ISA manual and bootstrapped from that.
Basically start with a s-exp based Assembler, add a macro support subset and go from there.
While not the same thing, you can have a look at http://www.ulisp.com/ for AVR.
That's not to say it can't be done in Lisp but Lisp needs a lot more runtime support than Forth. If I was going to bootstrap a Lisp, I'd bootstrap a Forth first and then write the garbage collector for Lisp in Forth.
A Lisp compiler in assembler is just about rationally unjustifiable, though.
If you want to learn forth concepts, you can build one yourself easily in any language (lots of examples), but Assembly or C are the most idiomatic as they allow you to get to a much lower level.
Every forth system is different, but they share a lot of design fundamentals. There are almost too many to count.
If you're okay with closed source, 8th has a very nice free version if you just want to get a hang of writing forth code in it. I usually recommend that one check out 8th as it comes with all the niceties of modern scripting languages and can cross-compile to a lot of systems, has GUI support, bluetooth, iPhone/Android, modern data structures, database support...etc.
It's also a bit confusing that most Forth systems were traditionally for embedded work. There are a few commercial offerings (SwiftForth and VxForth) for that. It used to also be extremely common to bootstrap new hardware with Forth as you got a full REPL so you could interactively interact with the hardware and test out each piece before a compiler like C could be ported to the system. I'm not sure how common that is now, but there are a lot of Forth systems that are pretty barebones compared to modern languages. You have to look around.
The joke is that if you have seen one Forth system, you have seen one Forth system :)
http://forth.sourceforge.net/standard/fst83/
There are certain cosmological nuances of Forth that come through by the time you get to where you have bootstrapped IF ELSE - and while later Forths add more features(which is great for production uses) they aren't the essence of Forth, which is in the minimalism.
Factor is also so much different that it deserves another category, despite syntactic resemblance.
RetroForth is smaller and easier to build than gforth or Factor. I actively use it and seek to improve it, and I've been told the documentation is good, though I still feel I have a long way to go on that front. It's not a traditional Forth, but it works well for me. I borrow things from traditional Forth, colorForth, Factor, 8th, and other languages when I think they make sense for my needs. Releases are quarterly, with daily snapshots provided.
Gforth is big and I find it to be difficult to build from source. If you need or want a traditional/standard Forth, it's probably what I'd recommend if using one of the commercial ones isn't an option. Definitely build it from source though; the releases are infrequent and the development versions have a lot of bug fixes and improvements.
Factor is big, has lots of interesting stuff, but apart from stacks and colon decisions, really doesn't feel like Forth to me. It is under active development, but releases other than snapshots are very infrequent (last in 2018). Building from source isn't something I've done with this in years, and platform support is more limited (Linux, Windows, macOS, on x86 or x86-64). I've borrowed some ideas and terminology from Factor over the years and would consider it worth learning from.
Main x86 source to bootstrap minimal interpreter/compiler: https://github.com/nornagon/jonesforth/blob/master/jonesfort...
Further Forth definitions: https://github.com/nornagon/jonesforth/blob/master/jonesfort...
rwmj gave some background in comments on the HN story: https://news.ycombinator.com/item?id=10187248