Labels as values and threaded-code interpretation

Dmitry Olshansky dmitry.olsh at gmail.com
Sun Jun 2 13:10:15 PDT 2013


02-Jun-2013 22:54, Walter Bright пишет:
> On 6/2/2013 10:58 AM, Dmitry Olshansky wrote:
>> Anyhow cramming the whole interpreter in one huge function too has
>> downsides
>> (and hopelessly inefficent register allocation is one).
>
> This should not be the case with register allocation using live ranges.
>

The problem is that if every goto *get_me_new_opcode compile may have no 
idea of where it will through it with computed labels. Hence some 
conservativeness of what registers contain and reloads and in effect all 
labels end up as isolated "functions". Plus a big stack frame is liability.

And then there is a fair share of obstacles in making the kind of 
threaded interpreter code optimized properly, this post I find interesting:
http://article.gmane.org/gmane.comp.lang.lua.general/75426

> You can also help with this by organizing declarations so the variables
> have the shortest scope.

Then splitting opcodes as functions separates their timespan even more.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list