SoylentNews is people
SoylentNews
It appears the leadership of Collapse OS have decided to switch from Z-80 to Forth. In this article, they explain their reasoning.
Collapse OS' first incarnation was written in Z80 assembler. One of the first feedbacks I had after it went viral was "why not Forth?". I briefly looked at it and it didn't seem such a great choice at first, so I first dismissed it. Then, I had what alcoholics refer to as a "Moment of clarity".
[...] The Z80 asm version of Collapse OS self-hosts on a RC2014 with a 5K shell on ROM, a 5K assembler binary loaded in RAM from SD card (but that could be in ROM, that's why I count it as ROM in my project's feature highlights) and 8K of RAM. That is, it can assemble itself from source within those resources.
[...] If I wanted to re-implement that assembler feature-for-feature in Forth, it would probably require much more resources to build. Even though higher level words are more compact, the base of the pyramid to get there couldn't compete with the straight assembler version. This was under this reasoning that I first dismissed Forth.
So, again, what makes Forth more compact than assembler? Simplicity. The particularity of Forth is that it begins "walking by itself", that is, implementing its own words from its base set, very, very early. This means that only a tiny part of it needs to be assembled into native code. This tiny part of native code requires much less tooling, and thus an assembler with much less features. This assembler requires less RAM.
What is more compact than something that doesn't exist? Even Z80 assembler can't beat the void.
That's how although Forth is not more compact that native code (duh!), a Forth Collapse OS achieves self-hosting with as much resources than its Z80 counterpart.
(Score: 2) by hendrikboom on Wednesday June 10 2020, @03:34PM (8 children)
Forth works quite well on a 16-bit machine. It's compact.
But put it on a 64-bit machine ... suddenly every code syllable is 8 bytes wide instead of two.
Compactness is gone. You'd want to go to a variable bit-length encoding. Simplicity and elegance are gone.
(Score: 0) by Anonymous Coward on Wednesday June 10 2020, @04:12PM (5 children)
You are right.
There is a reason Forth use peaked in the 1980s. Forth was a very good fit for the machine architectures and what was expected of them at the time: 16 bit CPU, no real OS as an abstraction like we have today, and single user machines running a single app at a time. Also, a simple commandline interface for everything. Think Commodore 64 but with a 16 bit processor. Also, an embedded device controlling one machine hooked up to it.
(Score: 1, Informative) by Anonymous Coward on Wednesday June 10 2020, @04:40PM (1 child)
Chuck Moore is still designing forth chips - greenarraychips.com.
(Score: 2) by hendrikboom on Wednesday June 10 2020, @10:53PM
Very interesting sounding chips.
(Score: 3, Interesting) by hendrikboom on Wednesday June 10 2020, @10:53PM (2 children)
I once wrote a threaded-code concatenative-language interpreter in assembler with a garbage collector. The garbage collector was written in the same language it was collecting for. And it could collect code, including its own code.
It was fun, but not greatly useful. The thing was a toy.
I also had a C run-time system for use when debugging. That C system could do static type-checking.
-- hendrik
(Score: 3, Funny) by Bot on Thursday June 11 2020, @09:53PM (1 child)
>The garbage collector was written in the same language it was collecting for. And it could collect code, including its own code
sorry to be the one pointing that out, but, that inevitably means that the collected code was garbage.
Account abandoned.
(Score: 3, Informative) by hendrikboom on Friday June 12 2020, @02:04AM
True, but it did have to go through its own code (like all code) to determine its extent. It was a two-space copying garbage collector, and partway through the collection it would be executing its code both in the from and to spaces, depending where it happened to be at the time.
-- hendrik
(Score: 2) by turgid on Friday June 12 2020, @07:06PM (1 child)
But put it on a 64-bit machine ... suddenly every code syllable is 8 bytes wide instead of two.
Only if you write it in bare assembly language on a RISC, surely?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by hendrikboom on Saturday June 13 2020, @10:55PM
Well, the standard, elegant way to implement Forth is to have a Forth program be a series of addresses of functions to be called one after another. A Forth function would then start with a bit of machine code to start the address-fetcher and jumper-to loop on the addresses that follow it. Except the primitive operations, which would just be assembler.
But on a 64-bit machine, addresses are now 8 bytes long. A huge waste of space for most code.
You *could* byte-code and have a limit of 256 functions.
Or restrict total memory to 64K out of your machine's available 8 gigabytes of RAM.
Or other similar.
Or, when storing Forth instructions into memory, you could translate them to in-place hardware machine code, and even do some optimization while you're at it. It might even come close to saving space.
None of this really feels like the traditional simplicity of Forth. Though technically, I suppose it could still be called Forth.
-- hendrik