On 18/05/2016 9:01 AM, Martin Nowak wrote:

Yes, this
is really ugly and complex, but you won't get rid of this inherent
complexity. The e2ir code for AssingExp looks almost the same

IMO this is a different problem, that AssignExp is stupidly complex and needs to be split up.

You might imagine that it's easier to work with syntax trees than to
start from scratch but I'm certain that's not true. I'm pretty sure that
the simplest approach is to use the simplest possible
machine-independent bytecode that you can come up with. I had got to the
point of starting that, but I just couldn't face doing it in C++.

All I'm saying is that interpreting the AST to generate bytecode is
going to be as complex as interpreting the AST directly, but then you
still a bytecode interpreter and later might still want a JIT.

The bytecode generator and bytecode interpreter can be debugged (and tested!) independently. So the total amount of code will increase but the components themselves will be better isolated and easier to work with.

I don't think a possible future need for a JIT is a good reason to avoid an bytecode interpreter. A large part of the work of adding a new (JIT) backend is pinning down the semantics, and adding a bytecode interpreter will certainly help to do that.

Using dedicated value types during interpretation instead of recycling
the AST for that will also make the transitions clearer and get rid of
some of the lifetime complexities in the current code.

Meh, sure. But this feels just as difficult as switching to a simple bytecode, without all the benefits.

Reply via email to