wherein i summarise a universally deployable container format for forth systems • Fri#34 of 2025
my set of reasons for this has changed plenty over time, naturally; i've been experimenting with forth in various forms since 2023, and in the two years since (at the time of writing) both my self and my elaborately tangled moral system have changed greatly.
however, there is one core aspect of forth that has kept it as important to me as i continue to find it now: the sheer intensity of its bang-for-your-buck factor. that is to say, its power-for-your-resources.
to put it simply, if you give forth a not-so-large amount of memory (as low as 3KiB on home computers such as the jupiter ace!) and computing time, it will give you a lot of power in return. to clarify, that's without an external runtime; forth forms its own, with very low overhead.
the simple explanation for this is that in 1968 chuck moore found a need for a compact and efficient language to *checks notes* aid in controlling radio telescopes!? okay, that's sick. sorry, where was i. computing resources weren't super extensive at the time, and there was use in having a language that could easily extend itself. soon enough, after showing the system to a co-worker, elizabeth rather, it became clear that this quality is in fact not only useful in controlling humongous astronomy equipment, but also in general computing. hence, the two founded forth inc. (yes, it's actually called that.)
soon, they found themselves implementing the language for just about every common architecture under the sun; forth, as it turns out, is very good at running just about everywhere.
i'm not exactly in the business of explaining how forths are implemented (for that you'll have to turn to someone better at writing), but i am in the business of understanding and being very excited about it. in fact, i've been excited about it practically the entire time that i've known about it, though i didn't have a good understanding at first.
now that i do, i'm even more excited, because as a permacomputing type of guy, forth's flexibility and power is massively advantageous. a good forth system gives you the tools to make the most of just about any computer system that has some sort of i/o method.
enough thinking about this eventually led me to the thought: what if you designed a forth system that not only lets you make the most of the system it's running on, but any other system external to it?
now, that may sound somewhat meaningless, so i'll just jump to the proposal: what if you had an operating system, that could run on any computer after 1990, and could modify and deploy itself and all of its software to any other compatible system with no more than 64 kilobytes of memory?
this is my goal with something called heph, and the related tools i'm building for it.
in short, heph is a format that can serialise the full state of an entire forth system, in a way that is completely agnostic to any particular processor architecture. the core appeal of this format is that it stores this state in a way that can be fairly trivially deserialised and executed on any computer with at least 64K of addressable memory.
that is to say, you can write a program, (or in my case an entire operating system,) build it to a heph pack (which includes all the space-saving advantages of indirect threading), and then deploy it to any processor that has a 16-bit or higher address space. neat, right?
i won't go into the technical details here, but the way heph works is by having a series of fairly simple "elements" which each either define a structural element of the final memory layout or contain an instruction in a fairly simple intermediate representation ("simple" means four registers and ten total instructions) optimised for forth machines.
the end goal of this project is to develop an operating system that:
in practice, this makes a development-ready operating system that is capable of entirely compiling itself to any number of other architectures with 64K of memory (or less!) with no external support. not only this, but due to the nature of the format's specification, the only requirements for this hypothetical system to run is
the eventual goal for the ecosystem is to be able to sit down with a computer, an isa reference, a cup of coffee and a couple afternoons and be able to write a translator for whatever machine you desire. the advantage of intentionally forcing all software in the ecosystem through this format is that its relative simplicity (4 registers, 4 simple addressing modes, 10 instructions, and 8 distinct structural elements) makes porting entire toolchains as simple as writing one small bit of glue (also, most of the structural code can be reused between system! most of the effort is in ir translation.) this, hopefully, should make the repurposing of just about any computational device after the 80s wonderfully uncomplicated - once you write a heph translator, your entire toolchain comes with you.
tl;dr: heph is a container format capable of serialising anything from a few forth words to an entire forth system in a way that is completely independent of any particular architecture or processor. this allows the existence of a hypothetical operating system capable of deploying itself and all of its software to any other architecture with 64K of memory or less, while keeping the porting process exceptionally simple. this means that once you write a small piece of glue code for a target architecture, your entire toolchain will now be usable on that architecture.
fin
2025 © mjm
this page licensed under
CC BY-SA 4.0
return