I found this an interesting adventure, albeit with a negative result. It might be that there are other nearby approaches which would have more successful - as it stands, it looks like a case of could be good in theory but didn't work out in practice.

Blog post, by own own Druzyek:
6507 Graphing Calculator: Forth Virtual Machine

Related forum thread:
6507 Calculator

Thanks for posting. I'll read through it and the thread today.

OK, I read through that page on his site, as well as his optimizing assembler. I previously read through his calculator thread on this forum. There are a lot of good ideas on his site to borrow, and my thoughts in no particular order.

I admire his ingenuity and industriousness.

A token threaded Forth to save space in exchange for speed was good thinking.

Using the BRK instruction and handler to start Forth execution is a smart idea.

I am not surprised that Forth is slower than C or assembly. When I wrote my Brainf*** interpreter and reworked it into subroutine threaded code, the compiled version that Phil Dennis wrote blew it away. But there was a code expansion with each version.

All that work only to have it not work made me a bit sad.

His optimizing assembler is impressive.

Yes, it's a pity it's a negative result (for now anyway.)

(I'll try to summarise my understanding of the story...) The challenge, I think, is to squeeze the desired calculator functionality into 8k - assembly code comes out too big. So, by adding a Forth VM (or any other tokenised execution engine) one incurs the cost of the engine, but gets the benefit of better density from that part of the code which can be interpreted. A more complex VM will soak up more functionality into fewer tokens, but the VM will be larger. Quite a complex optimisation problem!

One thing I find interesting here, is that I usually see tradeoffs of speed for memory as being a question of adding speed by spending memory. But here we're trying to save memory, and paying in speed.