[HN Gopher] Moving Forth: a series on writing Forth kernels
___________________________________________________________________
Moving Forth: a series on writing Forth kernels
Author : todsacerdoti
Score : 54 points
Date : 2025-05-15 05:24 UTC (17 hours ago)
(HTM) web link (www.bradrodriguez.com)
(TXT) w3m dump (www.bradrodriguez.com)
| benji-york wrote:
| 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.
| sitkack wrote:
| 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 wrote:
| 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.
| zck wrote:
| 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 wrote:
| 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).
| zck wrote:
| 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!
| anthk wrote:
| 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 , 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.
___________________________________________________________________
(page generated 2025-05-15 23:01 UTC)