The rest of the storyline of this page covers what I think is the core concept that Chuck Moore started from, and defines Forth as its own environment: the core of the language that needs to be defined in order to write and execute Forth words is surprisingly small. Once you have the core words in place, you can layer on exactly the constructs you need.

I won't claim to be a proficient Forth author, but I've used it to accomplish a couple of rather odd one-off projects, and it is amazing how much you can do, as long as you're not expecting graphics or networking or huge storage needs.

Compactness matters because when you're trying to bootstrap into a tiny (or hacked together custom build) environment, the tiny bootstrap footprint means you can be up and rolling that much faster.

C is all good, I've been writing it for a long time, but I'd much rather get a Forth core going in raw assembly than even a stripped down to brass tacks C compiler.

A Forth word is simple enough that defining any other level of handling just isn't necessary. Trying to put an IR in would just be another layer and an unnecessary complication.

Using Forth gets pretty close to being the most compact representation all by itself, there's literally no extra tooling needed. No compiler or other translations, it's all just there in the words.

I think the argument against a custom IR is that once you start optimising your IR for compactness you'll probably end up near Forth in the design space anyway. As you say perhaps making the IR stack-based.

Once you're at that point you may as well just use Forth, especially since it's got a proven ability to work in these kinds of resource contrained, self-hosting/self-bootstrapping environments.

> you'll probably end up near Forth in the design space anyway

Good point. Related to this, FORTH can be treated as a target platform for compilers, although I don't think there are many mature compilers that do this.

I wonder if CollapseOS will ever seriously target heavyweight platforms like x64 (and not just through emulation with libz80). I suppose that's out scope, but it would open the door to JIT.

> you may as well just use Forth

Presumably it could be a little more compact if a less human-readable variation were used, no? FORTH uses DROP and THEN, which could be shortened at the cost of readability.

Forth basically is IR between high level and whatever is your concept of "low level". The nature of forth is that forth words can be written as composition of other forth code or syscalls to native code or as chunk of native code.

I say "concept" because you can run forth code on an interpreter or any number of semi-compiled or compiled approaches that get more and more closer to assembly.

For a more optimizing compiler for a machine with more registers, you might, to be able to store the stack in the registers. The Z80 has few enough that I can't see it being an improvement.

it doesn't mean you have to, but forth is awesome.

Sure, I'm not contesting that FORTH has a certain charm. It's a really neat 'underground' language.

You're describing a hypothetical piece of software that would be easily two or three orders of magnitude more complex than the current Forth, and potentially be entirely unfeasible to run on a resource-constrained 8-bit system. Self-hosting isn't a cute trick, either- it's a functional requirement.

Forth makes bootstrapping and cross-compilation a straightforward exercise. C provides no help whatsoever until you've climbed to the top of a mountain of abstraction.

> What does 'compactness' matter?

Because after the end of civilization, you may be inputting your first programs on punch cards or something similar, and your system's memory capacity might be measured in a few kilobytes, not gigabytes. Compactness is a huge deal in this context.

Having spent a couple of hours as a kid typing in a https://en.wikipedia.org/wiki/SpeedScript binary printed in a magazine, one byte at a time, I can confirm that compactness is valuable.