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
