Google V8解释器（代号Ignition）设计文档的阅读感想
https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/edit?ts=56f27d9d#
1、字节码使用了x86的变长设计，可以前缀扩展到最多4个字节，以支持宽操作数？
2、对于属性访问，所谓的TypeFeedbackVector使得解释器和优化编译器后端可以使用同样的IC code stub，这里不太明白？为什么一元和二元操作反而不行呢？TFV引用原始AST的节点
3、注意这里的CodeStubAssember（CSA），它用于JIT生成每个bytecode的handler（原文：Bytecode handlers are generated by the TurboFan compiler.），每个handler结尾通过特殊的dispatch直接跳转到下一个handler（这里让我想起了CPS~~）
4、每个BytecodeArray的常量池支持任意长度？“复杂性来自用常量池存储前向跳转”，不过之前做过v8的SH4移植，这个复杂性其实还不算复杂，只是一个编程trick而已
5、累加器（accumulator）指的就是一个通用的临时变量吧？context寄存器无非也相当于机器指令里面的fp而已吧？
我的观点：
解释器的字节码设计对于那种普通的数值计算循环语句实际上是最浪费效率的，deoptimization（去优化），即从TurboFun跳回Ignition，涉及两种Stack Frame的即时构造和切换，是基于一类特殊的CheckXxx检查指令的。也就是说，如果某些约束条件不再满足，即无法再以优化编译的机器指令运行。
但是，如果可以设计一种特殊的“超级字节码”，它相当于汇编语言概念里的“宏指令”，即有可能将一整个循环语句映射为一个字节码，完全不需要生成多个字节码的序列。这样一来，解释器实际上几乎就相当于以模板转换的方法，直接映射为机器指令运行了。不过究竟这个思路如果落实到实现，我还没有什么想法。不清楚这个文档说的Super bytecode就是我指的这个意思？