4 ms·

Moving Forth: a series on writing Forth kernels

71 points by todsacerdoti 1y ago

benji-york 1y ago
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-FORTH.pdf https://www.forth.com/wp-content/uploads/2018/01/Starting-FO... Do yourself a favor and read a few chapters.
- sitkack 1y ago
  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.
- Verdex 1y ago
  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.
  - RetroTechie 1y ago
    Recently released under a CC license: https://thinking-forth.sourceforge.net https://thinking-forth.sourceforge.net
    - anthk 1y ago
      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.
  - anthk 1y ago
    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.
zck 1y ago
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.
- crq-yml 1y ago
  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).
anthk 1y ago
This is fun too 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 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 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.
- anthk 1y ago
  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.

71 points by todsacerdoti 1y ago

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-FORTH.pdf https://www.forth.com/wp-content/uploads/2018/01/Starting-FO... Do yourself a favor and read a few chapters.

sitkack 1y ago
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.
Verdex 1y ago
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.
- RetroTechie 1y ago
  Recently released under a CC license: https://thinking-forth.sourceforge.net https://thinking-forth.sourceforge.net
  - anthk 1y ago
    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.
- anthk 1y ago
  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.

zck 1y ago

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.

crq-yml 1y ago
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).

anthk 1y ago

This is fun too 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 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 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.

anthk 1y ago
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.