It's also frustrating trying to understand some of the lowest-level information. For example, a few systems have a very fundamental `w` variable -- but what is is used for? You can't search for it. Or just using registers and having to remember that %esi is the program counter (aka instruction pointer).
I keep wanting to make a series of diagrams to really understand Forth's program flow. It makes sense in concept, but when I go to program it, there are a lot of nuances I keep missing.
The thing is, pretty much every modern high level language tends to feel a bit clumsy as a Forth because the emphasis of the execution model is different - under everything with an Algol-like runtime, there's a structured hierarchy of function calls with named parameters describing subprograms. Those are provisions of the compiler that automate a ton of bookkeeping and shape the direction of the code.
It's easier to see what's going on when starting from the metaphor of a line-number BASIC (as on most 8-bit micros) where program execution is still spatial in nature and there usually aren't function calls and sometimes not even structured loops, so GOTO and global temporaries are used heavily instead. That style of coding maps well to assembly, and the Forth interpreter adds just a bit of glue logic over it.
When I try to understand new systems, now, I will look for the SEE word and use that to tear things down word by word. But I still usually don't need to go down to the assembly(although some systems like GForth do print out an assembly listing if asked about their core wordset).
Which brings up another complication -- the threading model. There are multiple, of course. But sometimes I want to figure out, for example, what the `w` variable does. Is it different between indirect threading and subroutine threading? Maybe!
https://github.com/howerj/subleq/
but you might need to edit subleq.fth and create a new image
with some of the constants named opt.* settings set to 1 (enabled) in order
to enable do...loop support and such. After you enabled them, try ./sublec ./sublrec.dec < ./sublec.fth > new.dec, wait a lot, and then run ./subleq sublec.dec .In order to save lots of time, clone the muxleq repo https://github.com/howerj/muxleq , edit muxleq.fth as always, and then run ./muxleq ./muxlec.dec < muxlec.fth > new.dec, and ./muxlec ./new.dec to run the new DEC EForth image.
Is not especially fast but it's a ready to run Forth and the Subleq machine can be compiled even under Windows XP and up with Min-C or any bundled C compiled on GNU/Linux BSD, from cproc to tcc, gcc or clang. If some of your code runs fast under Muxleq+EForth, it will fly under PForth and GForth.
https://minc.commandlinerevolution.nl/english/home.html
The speeds I get under an n270 atom with Muxleq are almost like a Forth machine under a boosted up 8 bit machine, kinda like an 8MHZ z80 with a native Forth, or a very low end M68k machine.
benji-york•8h ago
Do yourself a favor and read a few chapters.
sitkack•5h ago
Forth isn't one of those languages that you _use_. You extend the language from the inside, so you need to know how your Forth is implemented. I'd say it is the only language where users of the language could all recreate the language.
Verdex•5h ago