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
An attempt at using Forth for compact calculator code
An attempt at using Forth for compact calculator code
Last edited by BigEd on Mon Jan 30, 2023 12:30 pm, edited 1 time in total.
Re: An attempt at using Forth for compact calculator code
Thanks for posting. I'll read through it and the thread today.
Re: An attempt at using Forth for compact calculator code
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.
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.
Re: An attempt at using Forth for compact calculator code
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.
(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.