Compilation strategy

[Dmitry Olshansky]

12/18/2012 7:01 PM, Walter Bright пишет:
> On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
>> Compared to doing computations on AST tries (and looking up every name
>> in symbol
>> table?), creating fake nodes when the result is computed etc?
>
> CTFE does not look up every (or any) name in the symbol table.

I stand corrected - ditch "the looking up every name in symbol table".

Honestly I've deduced that from your statement:
 >>>the type information and AST trees and symbol table.

Note the symbol table. Looking inside I cannot immediately grasp if it 
ever uses it. I see that e.g. variables are tied to nodes that represent 
declarations, values to expression nodes of already processed AST.

> I don't
> see any advantage to interpreting bytecode over interpreting ASTs. In
> fact, all the Java bytecode is is a serialized AST.
>
We need no stinkin' Java ;)

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).

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?

*I judge by a cursory look at source and bits that Don sometimes shares 
about it.

-- 
Dmitry Olshansky