【发布时间】：2019-12-18 10:01:48
【问题描述】：
首先，让我明确一点，我目前正在编写一个字节码解释器。
我到处都在阅读有关字节码必须“紧凑”的信息。但是，我真的不明白这应该是什么意思，或者有什么好处。
目前，例如，我的“字节码”是一个元组数组，第一个元素是一个字节 - 操作码本身（8 位），第二个元素是 uint64（人们称之为 unsigned long long） -操作的可选参数（64 位）。
Tha 使每个“指令”为 72 位。 （诚然，这是非常不必要的，因为它们中的许多都不带任何参数，但我认为它更容易 - 并且性能更高？ - 这样，因为我不必每次都检查是否有参数，只需通过指令列表）。
那么，我的问题：
- 更紧凑的代码有什么好处？ （例如，如果每条指令是 32 位而不是 72 位，我会实现什么？）
- 我可以做些什么来让它变得更好？ （如何以有效的方式处理“可选”参数？即：可变大小指令）
【问题讨论】：
-
更小的尺寸要求，更好的缓存，更容易解析（无冗余）...待续。
-
指令的大小严重影响第一次执行的性能，因为它主要是从主内存加载代码，而解释器循环很快就会在指令缓存中。这与仅执行一次的短时间运行程序或指令序列有关，解释语言的领域，也与混合模式引擎有关，例如 JVM，它从解释字节码开始并编译频繁执行的代码，因此它具有第一次执行主导的解释和输入格式不可知的编译代码执行。
标签： c stack virtual-machine bytecode byte-code-enhancement