There's also the question of words like EXECUTE, which have to work with any XT (execution token -- basically a pointer to a word). How does the interpreter (or EXECUTE) manage all the different ways needed to call a word? 8/
Conversation
Well, there's a very nice solution. Actually I didn't change the text interpreter (or EXECUTE) at all when I adapted my STC engine to this new approach. As far as they are concerned, this is still a typical forth system with two stacks. 9/
1
4
How it works is that each word's XT actually points to a "preamble" that will expose a uniform calling convention for this word. This preamble is responsible for popping inputs from the stack into registers, calling the word, and then pushing the word's outputs on the stack. 10/
2
8
Thus each word has two entry points: the preamble which has a uniform calling convention that fits well with the surrounding forth system, and the actual word definition which has a calling convention tailored to this specific word. 11/
1
6
This also allows us to mix "typed" and "untyped" word. An untyped word simply doesn't have the second entry, it uses the uniform calling convention, and anyone can call it if they push the (virtual) stack values on the actual stack. 12/
1
5
But when the compiler sees a word with a type signature, it bypasses the preamble. So we only pay for the preamble when we use the uniform calling convention, e.g. in the text interpreter, or when calling EXECUTE. 13/
1
5
Actually it would be possible to have a typed EXECUTE, one for each type signature. E.g. EXECUTE-(X--X), which would skip the preamble. I didn't implement this because I don't need to, but it's a possibility. 14/
2
4
So, this pretty much describes how I managed to make a forth engine that compiles fast machine code. There's lots more details about, e.g., how to pick registers, how to inline primitives, dealing with branches, optimization ... But it's too much for this thread. 15/
1
4
What I did want to talk about is how working on this implementation finally gave me a good idea for how to integrate a type system into forth! 16/
1
1
8
One of the challenges of adding a type system to forth, is that forth is very dynamic. There's a complex mixture of execution and compilation going on at all times. E.g. you are compiling a word, say "dup", so now you have to execute dup's compiler, which is also a word. 17/
2
4
Replying to
Yeah, I've seen this. Cat has the exact problem I talked about, where it takes away compile-time execution & gives you only a statically typed postfix language. It's interesting but much less expressive than Forth.
1
Show replies