Hacker News Reader

Comment by ludocode | Hacker News Reader

Author here. I think my opinion would be about the same as the authors of the stage0 project [1]. They invested quite a bit of time trying to get Forth to work but ultimately abandoned it. Forth has been suggested often for bootstrapping a C compiler, and I hope someone does it someday, but so far no one has succeeded.

Programming for a stack machine is really hard, whereas programming for a register machine is comparatively easy. I designed the Onramp VM specifically to be easy to program in bytecode, while also being easy to implement in machine code. Onramp bootstraps through the same linker and assembly languages that are used in a traditional C compilation process so there are no detours into any other languages like Forth (or Scheme, which live-bootstrap does with mescc.)

tl;dr I'm not really convinced that Forth would simplify things, but I'd love to be proven wrong!

[1]: https://github.com/oriansj/stage0?tab=readme-ov-file#forth

View on HN

You might get a kick out of DuskOS(baremetal forth system)'s C compiler.

https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...

To add a bit to this, although Dusk OS doesn't have the same goals as stage0, that is to mitigate the "trusting trust" attack, I think it effectively does it. Dusk OS kernels are less than 3000 bytes. The rest boots from source. One can easily audit those 3000 bytes manually to ensure that there's nothing inserted.

That being said, the goal of stage0 is to ultimately compile gcc and there's no way to do that with Dusk OS.

That being said (again), this README in stage0 could be updated because I indeed think that Dusk is a good counterpoint to this critique of Forth.

Oh, amazing! I've heard of DuskOS before but I didn't realize its C compiler was written in Forth.

Looks like it makes quite a few changes to C so it can't really run unmodified C code. I wonder how much work it would take to convert a full C compiler into something DuskCC can compile.

One of my goals with Onramp is to compile as much unmodified POSIX-style C code as possible without having to implement a full POSIX system. For example Onramp will never support a real fork() because the VM doesn't have virtual memory, but I do want to implement vfork() and exec().

It can't compile unmodified C code targeting POSIX. That's by design. Allowing this would import way too much complexity in the project.

But it does implement a fair chunk of C itself. The idea is to minimize the magnitude of the porting effort and make it mechanical.

For example, the driver the the DWC USB controller (the controller on the raspberry pi) comes from plan 9. There was a fair amount of porting to do, but it was mostly to remove the unnecessary hooks. The code itself, where the real logic happens, stays pretty much the same and can be compiled just fine by Dusk's C compiler.

Reply on news.ycombinator.com