字节码堆栈与三地址
在设计字节码解释器时，现在对于堆栈还是三地址格式（或其他格式？）是否更好存在共识？我正在考虑这些因素：
目标语言是一种与 Javascript 非常相似的动态语言。
性能很重要，但目前更重要的是开发速度和可移植性。
因此，目前的实现将是严格的解释器；如果资源允许，JIT 编译器可能会稍后出现。
解释器将用 C 编写。
When designing a byte code interpreter, is there a consensus these days on whether stack or three address format (or something else?) is better? I'm looking at these considerations:
The objective language is a dynamic language fairly similar to Javascript.
Performance is important, but development speed and portability are more so for the moment.
Therefore the implementation will be strictly an interpreter for the time being; a JIT compiler may come later, resources permitting.
The interpreter will be written in C.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
阅读 Lua 的演变 和 Lua 5.0 的实现，了解 Lua 如何从基于堆栈的虚拟机变为基于寄存器的虚拟机，以及为什么它能够获得性能提升。
Read The evolution of Lua and The implementation of Lua 5.0 for how Lua changed from a stack-based virtual machine to a register-based virtual machine and why it gained performance doing it.
David Gregg 和 Roberto Ierusalimschy 所做的实验表明，基于寄存器的字节码比基于堆栈的字节码工作得更好，因为完成相同的任务所需的字节码指令更少（因此解码开销也更少）。因此，三地址格式显然是赢家。
Experiments done by David Gregg and Roberto Ierusalimschy have shown that a register-based bytecode works better than a stack-based bytecode because fewer bytecode instructions (and therefore less decoding overhead) are required to do the same tasks. So three-address format is a clear winner.
我在这方面没有太多（实际上没有）经验，因此您可能需要自己验证以下一些内容（或者也许其他人可以在必要时纠正我？）。
我现在最常使用的两种语言是 C# 和 Java，所以我自然倾向于它们的方法论。大多数人都知道，两者都被编译为字节码，并且两个平台（CLR 和 JVM）都利用 JIT（至少在主流实现中）。另外，我猜测每个平台的抖动都是用 C/C++ 编写的，但我真的不确定。
总而言之，这些语言及其各自的平台与您的情况非常相似（除了动态部分，但我不确定这是否重要）。另外，由于它们是主流语言，我确信它们的实现可以作为您的设计的很好的指南。
排除了这一点，我确信 CLR 和 JVM 都是基于堆栈的体系结构。我记得基于堆栈与基于寄存器的一些优点是
此外，我发现基于堆栈更直观和可读，但这是一个主观的事情，就像我一样前面说了，我还没有见过太多的字节码。
基于寄存器的体系结构的一些优点是：
当然，总有办法来抵消每个都有缺点，但我认为这些描述了明显需要考虑的事情。
I don't have much (not really any) experience in this area, so you might want to verify some of the following for yourself (or maybe someone else can correct me where necessary?).
The two languages I work with most nowadays are C# and Java, so I am naturally inclined to their methodologies. As most people know, both are compiled to byte code, and both platforms (the CLR and the JVM) utilize JIT (at least in the mainstream implementations). Also, I would guess that the jitters for each platform are written in C/C++, but I really don't know for sure.
All-in-all, these languages and their respective platforms are pretty similar to your situation (aside from the dynamic part, but I'm not sure if this matters). Also, since they are such mainstream languages, I'm sure their implementations can serve as a pretty good guide for your design.
With that out of the way, I know for sure that both the CLR and the JVM are stack-based architectures. Some of the advantages which I remember for stack-based vs register-based are
Also, I find stack-based to be a little more intuitive and readable, but that's a subjective thing, and like I said before, I haven't seen too much byte code yet.
Some advantages of the register-based architecture are
Of course, there are always ways to offset the disadvantages for each, but I think these describe the obvious things to consider.
看一下 OCaml 字节码解释器 - 它是同类中最快的之一。它几乎是一个堆栈机，在加载时转换为线程代码（使用 GNU 计算的 goto 扩展）。您也可以生成类似 Forth 的线程代码，应该相对容易做到。
但是，如果您考虑到未来的 JIT 编译，请确保您的堆栈机并不是真正功能齐全的堆栈机，而是表达式树序列化形式（如 .NET CLI） - 这样您就能够将“堆栈”字节码转换为 3 地址形式，然后转换为 SSA。
Take a look at the OCaml bytecode interpreter - it's one of the fastest of its kind. It is pretty much a stack machine, translated into a threaded code on loading (using the GNU computed goto extension). You can generate a Forth-like threaded code as well, should be relatively easy to do.
But if you're keeping a future JIT compilation in mind, make sure that your stack machine is not really a full-featured stack machine, but an expression tree serialisation form instead (like .NET CLI) - this way you'd be able to translate your "stack" bytecode into a 3-address form and then into an SSA.
如果您考虑 JIT，那么字节码是唯一的选择。
以防万一您可以查看我的 TIScript：http://www.codeproject.com /KB/recipes/TIScript.aspx
和来源：http://code.google.com/p/tiscript/
If you have JIT in your mind then bytecodes is the only option.
Just in case you can take a look on my TIScript: http://www.codeproject.com/KB/recipes/TIScript.aspx
and sources: http://code.google.com/p/tiscript/