自己原来做过一个编译相关的项目（全局优化问题变量相关性分组软件的实现），用的是字节码解释器，没有用AST解释器。当时基于的考虑是实现起来简单清晰，好调试，不像AST那么复杂，自己心中也是一直有个疑问，到底哪种方法更好？今天总结一下。
字节码结构更紧凑，内存局部性好，解释执行性能高。
从工程上说，字节码解释器也有利于把代码组织得更清晰，把关注点清晰的分离开来。
AST解释器有一些额外的开销，而字节码解释器可以节省这些开销。
AST解释器开销在于：
- AST上有些没有执行语义的节点，但解释器在执行时不得不访问它们，增加了解释开销。SquirrelFish文中用语句块（block）的举例，这个不错：一个block仅用于把一堆语句聚合在一起，自身并没有“有效的”执行语义，但解释器为了访问到这个block的子节点却不得不访问这个block。AST的节点种类相对于解析树（parse tree）通常要精简许多（括号、分号之类的token通常都扔掉了），但用于解释执行还是不够精简。
- AST通常使用链式结构实现（父节点用指针指向子节点），解释执行需要遍历AST，就得跟随这些指针不断做间接访问。外加AST常会携带一些跟解释执行没直接关系的额外信息，这使得AST节点比较“肥”，占用更多内存，而对解释执行有用的信息在内存里分隔得更开，不紧凑。
- AST中每种节点的结构未必相同，有多少个子节点、哪些子节点有用、要按什么顺序去访问那些子节点，都需要针对每种节点专门实现；换句话说，必须确定了节点种类才能确定遍历顺序，这也不利于解释器实现得紧凑。
- AST解释器的核心遍历逻辑最自然的实现方式是递归；当然，执行状态得顺着递归通过参数传递。（SquirrelFish文中还提到AST解释器要在节点间传递状态带来额外开销。这主要是以前的JavaScriptCore的实现太纱布了，不能怪AST解释器本身的概念不好⋯）
什么是语法制导翻译？
解释器边做语法分析边执行相应位置的语义动作（semantic action）而不构建AST（例如计算器，针对语义，直接执行相应的操作），于是在完成语法分析的时候也就完成了解释执行。假如不直接做解释执行，这些语义动作也可以用来生成代码（例如字节码），边做语法分析边完成了代码生成，中间也不需要AST。理解语法制导翻译的最重要的一点就是：那些嵌在语法里的语义动作，都可以看作epsilon匹配——匹配空字符串，也就是总是可以匹配——匹配到它们的时候就执行里面的代码。这样就很好理解这些代码是什么时候执行的，而它能访问到的上下文都是怎样的。
