Compilation strategy

[Dmitry Olshansky]

12/18/2012 9:30 PM, Walter Bright пишет:
> On 12/18/2012 8:57 AM, Dmitry Olshansky wrote:
>> But adequate bytecode designed for interpreters (see e.g. Lua) are
>> designed for
>> faster execution. The way CTFE is done now* is a polymorphic call per
>> AST-node
>> that does a lot of analysis that could be decided once and stored in
>> ... *ehm*
>> ... IR. Currently it's also somewhat mixed with semantic analysis
>> (thus rising
>> the complexity).
>
> The architectural failings of CTFE are primary my fault from taking an
> implementation shortcut and building it out of enhancing the constant
> folding code.
>
> They are not a demonstration of inherent superiority of one scheme or
> another. Nor does CTFE's problems indicate that modules should be
> represented as bytecode externally.
>
Agreed. It seemed to me that since CTFE implements an interpreter for D 
it would be useful to define a flattened representation of semantically 
analyzed AST that is tailored for execution. The same bytecode then 
could be be used for external representation.

There is however a problem of templates that can only be analyzed on 
instantiation. Then indeed we can't fully "precompile" semantic step 
into bytecode meaning that it won't be much beyond flattened result of 
parse step. So on this second thought it may not that useful after all.

>> Another point is that pointer chasing data-structures is not a recipe
>> for fast
>> repeated execution.
>>
>> To provide an analogy: executing calculation recursively on AST tree of
>> expression is bound to be slower then running the same calculation
>> straight on
>> sanely encoded flat reverse-polish notation.
>>
>> A hit below belt: also peek at your own DMDScript - why bother with
>> plain IR
>> (_bytecode_!) for JavaScript if it could just fine be interpreted as
>> is on AST-s?
>
> Give me some credit for learning something over the last 12 years! I'm
> not at all convinced I'd use the same design if I were doing it now.
>
OK ;)

> If I was doing it, and speed was paramount, I'd probably fix it to
> generate native code instead of bytecode and so execute code directly.
> Even simple JITs dramatically speeded up the early Java VMs.

Granted JIT is faster but I'm personally more interested in portable 
interpreters. I've been digging around and gathering techniques and so 
far it looks rather promising.
Though I need more field testing... and computed gotos in D! Or more 
specifically a way to _force_ tail-call.

-- 
Dmitry Olshansky