lua虚拟机字节码修改_云风的 BLOG: 虚拟机之比较，lua 5 的实现

Comments

double占8个字节，在32位机器上可以用一个特殊的double来编码其它的TValue

http://hi.baidu.com/pcall/blog/item/c83d917f5ae4003e0cd7dafe.html

我做游戏也在自己设计指令集和虚拟机，有机会能探讨一下。

也来凑两句。

采用RB的虚拟机，编译的工作量是大一些，主要原因是虚拟寄存器的合理分配，云风以前好像也指出过。要实现虚拟寄存器的合理分配，邻近的虚拟指令的operand需要无缝地吻合起来，这点是有点复杂。

Roberto关于手写编译器的原因还是蛮合理的。另外我估计使用yacc/bison之类的工具，比较难合理的分配虚拟寄存器。

Roberto 大大的解释：

- Better control over code quality. The skeletons from yacc/bison

frequently use system #ifdefs, malloc.h, etc.

- Better control over static and extern variables. We were already

planning "stateless Lua".

- Possibility of using the C stack to hold some data structures. For

instance, with nested functions, we need one structure (with lots of

fields) for each function being compiled. With a recursive descendent

parser, it is trivial to allocate them as local variables. (To use

dynamic allocation for them is tricky, because in case of errors we must

be able to free them correctly...)

- Better error messages.

On the other hand, the syntax of Lua was already quite stable, so one of the

main advantages of yacc (easy of change) was not that important.

http://lua-users.org/lists/lua-l/2002-03/msg00035.html

不过写出来的好处是显而易见的，就和 paper 里说的一样，smaller, more efficient, more portable, and fully reentrant :)

--- 再纸上谈兵一把：

从算法上来讲，我看不出手写的代码有什么可能比基于LALR文法的，基于状态机的编译器更为快捷的。在这种基于有限状态机的编译模型中，整个编译的速度几乎就没有什么冗余的操作。而且无论是源代码的清晰程度也远高许多啊。所以，这点，我对云风的论点不敢苟同。

我对虚拟机和编译也是很感兴趣，不过，一向是只读不动手。所以，我的观点纯粹是纸上谈兵。

关于register based/stack based，我的感觉是，对于脚本语言而已，采用RB，那么编译器(从源代码到字节吗)，编译器的工作量会大很多，而且字节码本身相对来说会更为复杂一些。而已，从RB的字节码向机器码进行JIT我觉得也会相对简单一些，毕竟RB的模型和CPU的寄存器模型是相近的。而SB则对编译器是非常简化的，但对JIT的要求就相对复杂一些，需要再次将SB转移到RB上去(不过，这种转换基于数据流的分析是完全可行的)。

因此，从理论上说，RB与SB是等价的，如果纯粹采用解释的方式(没有JIT)，那么RB的优势会明显一些，因为在RB中，指令数目明显会减少。但采用JIT模式时，则2者不会有本质的差别。Java的做法还是相当聪明的，将优化的工作集中到JVM中，使得Bytecode和编译器的工作大大简化，这样，至少使得产生一个新的语言编译器(将新的语言编译成bytecode)大大简化了。

确实开发程序语言最难的大概就是能否坚持下来