I would also recommend "R. G. Loeliger Threaded Interpretive Languages Their Design And Implementation" between these two books the whole beauty of Forth and their implementation should just click.
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.
Now I'd love the same with Starting Forth set to ANS Forth standards, and not just in web form. Yes, I know how to use wget --mirror and such, but I'm used to MuPDF and the editor terminal switching back and forth. No pun intended.
Writing a Forth myself, I find it somewhat frustrating that I have relatively different design restrictions than these guides. I don't need to be incredibly low-power, so I'm using C, not assembly. I'm not a great C coder, and I've never done assembly, so I find it hard (but not impossible) to learn from assembly. Also, because it's not assembly, I can't just JUMP to code the same way assembly can.
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.
It took me a few tries(over a few years) to properly approach the task of writing a Forth, and when I approached it, I made my Forth in Lua, and all I really did was implement the wordlist in FORTH-83 as the spec indicated, and rewrite every time my model assumptions were off. No diving into assembly listings. Eventually I hit the metaprogramming words and those were where I grasped the ways in which the parser and evaluator overlap in a modal way - that aspect is the beating heart of a bootstrappable Forth system and once you have it, the rest is relatively trivial to build when starting from a high level environment.
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).
I understand implementing words as you think they should be. However, you need the core first, and that's where I'm working right now. I'm trying to get the central loop, dictionary, and threading model functional.
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!
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.
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.
Some trivia for those who might not be aware: the tile of the series is a reference to the beloved 1981 book "Starting FORTH" which you can now read online at https://www.forth.com/wp-content/uploads/2018/01/Starting-FO...
Do yourself a favor and read a few chapters.
I would also recommend "R. G. Loeliger Threaded Interpretive Languages Their Design And Implementation" between these two books the whole beauty of Forth and their implementation should just click.
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.
Also recommending Thinking Forth by Leo Brodie. The book feels like it was written in the 2010s but the original publish date was mid 80s.
Recently released under a CC license:
https://thinking-forth.sourceforge.net
Now I'd love the same with Starting Forth set to ANS Forth standards, and not just in web form. Yes, I know how to use wget --mirror and such, but I'm used to MuPDF and the editor terminal switching back and forth. No pun intended.
That's more for ANS Forth. PForth for instance has a block editor, but is not documented ( edit-blockfile file -- ).
I would love a Starting Forth book on PDF form but updated, as the web does.
Writing a Forth myself, I find it somewhat frustrating that I have relatively different design restrictions than these guides. I don't need to be incredibly low-power, so I'm using C, not assembly. I'm not a great C coder, and I've never done assembly, so I find it hard (but not impossible) to learn from assembly. Also, because it's not assembly, I can't just JUMP to code the same way assembly can.
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.
It took me a few tries(over a few years) to properly approach the task of writing a Forth, and when I approached it, I made my Forth in Lua, and all I really did was implement the wordlist in FORTH-83 as the spec indicated, and rewrite every time my model assumptions were off. No diving into assembly listings. Eventually I hit the metaprogramming words and those were where I grasped the ways in which the parser and evaluator overlap in a modal way - that aspect is the beating heart of a bootstrappable Forth system and once you have it, the rest is relatively trivial to build when starting from a high level environment.
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).
I understand implementing words as you think they should be. However, you need the core first, and that's where I'm working right now. I'm trying to get the central loop, dictionary, and threading model functional.
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!
This is fun too
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.
Well I made a typo in the former comment; in order to run the NEW subleq.fth image, as you might guessed it's './subleq ./new.dec' .
I post this because I can't edit my comment any more.