In which we interpret Forth using Forth and a bit of cheating With an implementation of refill, we are in the position of implementing the interpreter loop in Forth itself. In the previous post, we defined the interpreter loop like this: attempt to read a line into the input buffer while last read was successful … Continue reading Forth interpreting Itself
Category: forth
Forth Inside Out part 2
In which we internalise the read-execute loop, or die in the attempt. In Forth: Inside Out I did some refactoring on the read-execute loop. In this part I and going to re-engineer it entirely and implement it in Forth. The reason for doing this is that it will play better with some of the core … Continue reading Forth Inside Out part 2
Forth: Inside Out
In which we turn the interpreter inside out My Forth interpreter is working fairly well so far, but I think there is some unnecessary complexity. The interpreter is event driven, which means that everything it does is driven by some event, which is always receipt of some text input. This works OK and I chose … Continue reading Forth: Inside Out
The Forth Protocol
In which I accidentally discover a performance enhancement I'm really not a fan of the massive switch statement at the heart of the execution loop, so I have decided to see if I can do something with virtual functions or closures on a WordList. The execute function would be reduced to running a particular function … Continue reading The Forth Protocol
RE-Evaluating Forth
In which I take another crack at the evaluation cherry Just a short post to note that I have finally cracked evaluate. After the refactoring exercise, I still had a number of issues mostly caused by the design decision to put the currently interpreting word in the word list at position 0 and to use … Continue reading RE-Evaluating Forth
Forth Refactored
In which my head exploded so I had to simplify things Because my Forth interpreter is effectively event driven i.e. the input parser parses and then calls the interpreter to interpret one word, it gets very complicated when an executing word needs to pull something off the input parser. It has to exit the interpreter … Continue reading Forth Refactored
Evaluating Forth
In which I evaluate some strings The evaluate word is next on the list of core tests. This allows a Forth program to evaluate a string as if it were another Forth program. The simplest way to implement this would seem to be to implement a stack of sequences of input characters. evaluate then simply … Continue reading Evaluating Forth
Defining Forth
In which I try to unify the defining expressions. There are a number of ways to add words to the dictionary. These include: :, create, constant, and variable. It seems to me that the "primitive" should really be to just add the word to the dictionary and then each of the above words can be … Continue reading Defining Forth
Forth does create
In which we have to reimplement create and does>. Having implemented create and does> as described previously, there are two problems. Consider the following extract from my core tests: t(": DOES1 DOES> @ 1 + ;", expected: "") t(": DOES2 DOES> @ 2 + ;", expected: "") t("CREATE CR1", expected: "") t("CR1 here =", expected: … Continue reading Forth does create
Does Forth create
In which my head explodes. create and does> are what is currently causing the unit tests of my Forth interpreter to fail. So what do these things do? Well, if you read the Forth specification, it becomes obvious that the main thing they do is make a nice smoothy out of your brain. Fortunately, I … Continue reading Does Forth create
Sincere Flattery 