I adore the `Threaded Interpretive Languages` book! It very clearly describes the internals of a real language, and variations on how to get it all done. https://archive.org/details/R.G.LoeligerThreadedInterpretive...
Implementing a Forth
21–30 of 70 posts
Re: Implementing a Forth
#22Re: Implementing a Forth
#23Not sure if this counts as an implementation, but this is my Forth compiler, written in the high-level language Go [0]. This is also a challenge, as Forth usually requires machine language, call stack access, and is naturally written in assembler. Took several tries until I found working data structures. The funniest thing is, you can easily write and invent your own control structures in Forth, as well as change the…
Not really. Many implementations indeed do that, but only in pursuit of performance - the weakness of interpreted languages is speed. Otherwise one can just implement it as a bytecode interpreter, like e.g. Lua.
Re: Implementing a Forth
#24I am under impression that more people implement Forth than use it for programming...
we used FORTH extensively in the bring-up of the Atari ST. it was easy for the hardware engineers to come up with little fragments of FORTH so they could exercise their chips without needing much support from the software team FORTHs are fun to write. they'll teach you a lot about ruthless simplicity i don't think FORTH is useful for large programs, but that's not the point of the language
Re: Implementing a Forth
#25I am under impression that more people implement Forth than use it for programming...
and that's why we don't hear from them anymore
Re: Implementing a Forth
#26I went down the "make your own Forth" rabbit hole about 45 years ago. In January 1979, Byte Magazine's Language Forum contained the article, "IPS, An Unorthodox High Level Language."[1] The article described IPS, a language based on Forth, but with the word names translated to German. Thus, Forth's SWAP became VERT, short for vertauschen. The intriguing article concluded with a reference to Charles Moore's 1974 paper…
What kind of programs would one naturally reach for Forth as the optimal solution? It has always struck me as a very low level language but I rarely hear this caveat from its advocates.
: WASHER ( -- ) WASH SPIN RINSE SPIN ;
I won't repeat all the rest, even though it's short, but let's look at a few other definitions that build up to that: : RINSE ( -- ) FILL-TUB AGITATE DRAIN ;
: DRAIN ( -- ) PUMP ON 3 MINUTES ;
: ON ( mask -- ) PORT C@ OR PORT C! ;
4 CONSTANT PUMP
01 CONSTANT PORT
All very high level and fairly straightforward to understand word-by-word until you get to the bottom, that being the last 3 lines I pasted. (Though in a file this would be written the other way around with WASHER being the final line.) The PORT is a memory mapped hardware address, PORTB on a 68HC12 chip, and various other constants like PUMP are defined as bitmasks to get at individual bits on the port. The ON word takes the current value at the PORT address, ORs it with the stack-passed mask, and sets it back.In C this might look like (again in reverse order):
void washer(void) {
wash();
spin();
rinse();
spin();
}
void drain(void) {
on(PUMP);
minutes(3);
}
void on(uint8_t mask) {
PORT |= mask;
}
#define PUMP (1
That is, if you program the C in a similar procedural style that closely follows the physical function of the device. It's maybe more common to express similar C code in a state machine style, in which case it'd look a lot different.Is the Forth version actually worth it? To me the C is "good enough", and more explicit or at least clearer as I'm familiar with C. Where Forth could win me over is in its ease of having a truly interactive environment to iteratively develop the software via a REPL, much like Lisp. (But then I'd rather just use Lisp.) My embedded systems hobby work for the last 10+ years has all been really simple, though, so interactivity isn't a big enough advantage to just using C. (When working with hardware, it's somewhat exciting to stick a pin in a breadboard and move it between power and ground to toggle a motor. It'd be even more exciting to do this interactively via REPL commands poking at memory.)
Re: Implementing a Forth
#27The idea is to use it to drive an LED matrix and have a simple web UI to develop "fragment shaders" in Forth. It's developed as part of the Lwan project, although currently it generates GIF files on the fly rather than drive a LED matrix.
The source code is here for those that want to play with it: https://github.com/lpereira/lwan/tree/master/src/samples/for...
Re: Implementing a Forth
#28I am under impression that more people implement Forth than use it for programming...
Re: Implementing a Forth
#29Earlier quoted context omitted.
we used FORTH extensively in the bring-up of the Atari ST. it was easy for the hardware engineers to come up with little fragments of FORTH so they could exercise their chips without needing much support from the software team FORTHs are fun to write. they'll teach you a lot about ruthless simplicity i don't think FORTH is useful for large programs, but that's not the point of the language
Why is it not useful for large programs (if you keep your words small)? What about Factor?
Re: Implementing a Forth
#30Not sure if this counts as an implementation, but this is my Forth compiler, written in the high-level language Go [0]. This is also a challenge, as Forth usually requires machine language, call stack access, and is naturally written in assembler. Took several tries until I found working data structures. The funniest thing is, you can easily write and invent your own control structures in Forth, as well as change the…