Inspiration to bytecode from the belt model

Hi again

Would like to know if you have anything to add into this line of thought.

I got a parser working for my programming language yesterday. Progressed to write
an evaluator for the code. After thinking about it on paper a small while, I thought
Mill might inspire up an interesting choice for bytecode.

I know that bytecode is not required to implement an interpreter. You could just
directly evaluate the trees you get from your parser. Converting it to bytecode will reduce away lot of calls from runtime, that would be required if evaluting the parse tree directly.

Bytecode will require some model for representing motion of values in the code. I could just go traditional and have destination, source virtual registers for every op. What if I used the belt model here? The operations would feed their values into a belt. It feels simple, but questions arise how to handle conditional branches and loops. Each block of operations will feed fixed count of values into the belt. The belt would be a finite array of virtual registers. It wouldn’t function like FIFO though, since you can scale the amount of virtual registers in bytecode. Unlike in Mill, it would be indexed from the beginning, with end -pointer pointing out where the values go to.

The bytecode implementation could ‘pull’ the belt backwards. Every simple could set the position of the belt and copy values from anywhere in the belt, ending up to resemble a copying garbage collector as long living values would end up to the bottom of the belt. One would use dominator tree to calculate where the belt must shed out values to not fill up. The copying would work like phi-nodes. Branches are tagged with number, which is used to index out which values to copy over while reseting the belt.

If you have better idea on how to do it, I’ll listen. Though I’ll try this one this weekend.