Hacker News
points by anta40 2 days ago | 0 comments
Nice to see gforth is still being maintained.

BTW, on the other side, looks like gforth still lacks the ability to create native OS executable, something like:

gcc myprog.c -o myprog

?

[–] nickcw 2 days ago
You may enjoy ccforth then which is a mostly gforth compatible compiler which compiles to native via C.

https://github.com/ncw/ccforth

I wrote it as an experiment in having both a forth interpreter and compiler running at the same time.

[–] lebuffon 2 days ago
Whoa! That is a really nice piece of work. Congrats!
[–] jan_m_savage 2 days ago
That’s because Gforth is a threaded-code VM that saves dictionary images rather than compiling to native code.

As you prolly know, Forth blurs compile time and run time in general, and there’s no so-called clean compile, then link boundary like in C.

SwiftForth, VFX Forth, and iForth do emit real executables, and there are smaller native-code Forths for Linux too, but then the opportunity cost is losing Gforth’s portability and its standards-heavy library ecosystem.

[–] MaxBarraclough 2 days ago
> That’s because Gforth is a threaded-code VM that saves dictionary images rather than compiling to native code.

That's not correct. Gforth features a JIT compiler, although they don't call it that, they call it dynamic superinstructions. It will be enabled if you run gforth-fast. If I understand correctly, the native code sequences are always generated at runtime, and cannot be baked into an image file.

• Dynamic Superinstructions https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Dyn...

• [PDF] Code-Copying Compilation in Production An Experience Report (2025) http://www.euroforth.org/ef25/papers/ertl.pdf