VM解释器-更大指令集/调度循环的加权性能优点和缺点

我正在开发一个简单的VM，我正处于十字路口的中间。

我最初的目标是使用字节长指令，因此需要一个小循环和快速计算的goto分派。

然而，事实证明，256远远不足以涵盖有符号和无符号的8,16,32和64位整数，浮点数和双精度，指针操作，不同的寻址组合。一种选择是不实现byte和short，但目标是使VM支持完整的C子集以及向量操作，因为它们几乎无处不在，尽管在不同的实现中。

所以我切换到16位指令，所以现在我也能够添加可移植的SIMD intrinsic和更多编译的常见例程，这些例程通过不被解释来真正节省性能。还有全局地址的缓存，最初编译为基指针偏移量，第一次编译地址时，它只是覆盖偏移量和指令，以便下一次直接跳转，代价是指令每次使用全局地址时，在集合中额外增加一条指令。

由于我不在分析阶段，我处于两难境地，额外的指令是否值得更大的灵活性，更多指令的存在以及因此来回复制指令的缺失是否可以弥补增加的调度循环大小?请记住，每个指令只是几个汇编指令，例如:

.globl  __Z20assign_i8u_reg8_imm8v
.def    __Z20assign_i8u_reg8_imm8v; .scl    2;  .type   32; .endef
__Z20assign_i8u_reg8_imm8v:
LFB13:
.cfi_startproc
movl    _ip, %eax
movb    3(%eax), %cl
movzbl  2(%eax), %eax
movl    _sp, %edx
movb    %cl, (%edx,%eax)
addl    $4, _ip
ret
.cfi_endproc
LFE13:
.p2align 2,,3
.globl  __Z18assign_i8u_reg_regv
.def    __Z18assign_i8u_reg_regv;   .scl    2;  .type   32; .endef
__Z18assign_i8u_reg_regv:
LFB14:
.cfi_startproc
movl    _ip, %edx
movl    _sp, %eax
movzbl  3(%edx), %ecx
movb    (%ecx,%eax), %cl
movzbl  2(%edx), %edx
movb    %cl, (%eax,%edx)
addl    $4, _ip
ret
.cfi_endproc
LFE14:
.p2align 2,,3
.globl  __Z24assign_i8u_reg_globCachev
.def    __Z24assign_i8u_reg_globCachev; .scl    2;  .type   32; .endef
__Z24assign_i8u_reg_globCachev:
LFB15:
.cfi_startproc
movl    _ip, %eax
movl    _sp, %edx
movl    4(%eax), %ecx
addl    %edx, %ecx
movl    %ecx, 4(%eax)
movb    (%ecx), %cl
movzwl  2(%eax), %eax
movb    %cl, (%eax,%edx)
addl    $8, _ip
ret
.cfi_endproc
LFE15:
.p2align 2,,3
.globl  __Z19assign_i8u_reg_globv
.def    __Z19assign_i8u_reg_globv;  .scl    2;  .type   32; .endef
__Z19assign_i8u_reg_globv:
LFB16:
.cfi_startproc
movl    _ip, %eax
movl    4(%eax), %edx
movb    (%edx), %cl
movzwl  2(%eax), %eax
movl    _sp, %edx
movb    %cl, (%edx,%eax)
addl    $8, _ip
ret
.cfi_endproc

这个例子包含以下指令:

• 从直接值分配无符号字节到寄存器
• 将无符号字节从寄存器赋值到寄存器
• 从全局偏移量中分配无符号字节到寄存器和缓存，并更改为直接指令
• 从全局偏移量中分配无符号字节到寄存器(现在缓存的先前版本)
• …

当然，当我为它生成一个编译器时，我将能够在生产代码中测试指令流，并优化内存中指令的排列，以将经常使用的指令打包在一起，并获得更多的缓存命中。

我只是很难确定这样的策略是否是个好主意，膨胀会弥补灵活性，但性能呢?更多的编译例程是否可以弥补更大的分派循环?是否值得缓存全局地址?

我也希望有人，体面的汇编表达对由GCC生成的代码质量的意见-是否有任何明显的低效和优化的空间?为了使情况更清楚，有一个sp指针，它指向实现寄存器的堆栈(没有其他堆栈)，ip逻辑上是当前指令指针，gp是全局指针(未被引用，作为偏移量访问)。

编辑:另外，这是我执行指令的基本格式:

INSTRUCTION assign_i8u_reg16_glob() { // assign unsigned byte to reg from global offset
FETCH(globallAddressCache);
REG(quint8, i.d16_1) = GLOB(quint8);
INC(globallAddressCache);
}

FETCH返回对该指令基于操作码

使用的结构体的引用。REG从offset

返回对寄存器值T的引用GLOB从缓存的全局偏移量(实际上是绝对地址)返回对全局值的引用

INC只是将指令指针按指令的大小加1。

有些人可能会建议不要使用宏，但是使用模板的话可读性会差很多。这样代码就很明显了。

编辑:我想对这个问题补充几点:

• 我可以去一个"仅寄存器操作"的解决方案，只能在寄存器和"内存"之间移动数据-全局或堆。在这种情况下，每次"全局"访问和堆访问都必须复制值，修改或使用它，并将其移回更新。这样我就有了一个更短的分派循环，但是对于每条处理非寄存器数据的指令都有一些额外的指令。因此，两难的选择是，使用更长的直接跳转的本地代码增加几倍，或者使用更短的分派循环的解释指令增加几倍。一个简短的调度循环是否能够提供足够的性能来弥补额外的和昂贵的内存操作?也许较短和较长的调度循环之间的差异不足以产生真正的差异?就缓存命中而言，就汇编跳转的成本而言。

• 我可以去额外的解码和只有8位宽的指令，然而，这可能会增加另一个跳转-跳转到处理该指令的任何地方，然后浪费时间跳转到处理特定寻址方案的情况或解码操作和更复杂的执行方法。在第一种情况下，调度循环仍然在增长，并添加了另一个跳转。第二种选择——寄存器操作可以用来解码寻址，但是为了寻址，需要一个更复杂的指令，需要更多未知的编译时间。我真的不确定这与更短的调度循环如何叠加，再一次，不确定我的"更短和更长的调度循环"如何与汇编指令的长短，它们所需的内存和执行速度相关联。

• 我可以选择"多指令"的解决方案-调度循环是几倍大，但它仍然使用预先计算的直接跳转。复杂寻址是特定的，针对每个指令进行了优化，并编译为本机，因此"仅寄存器"方法所需的额外内存操作将被编译并主要在寄存器上执行，这对性能有好处。一般来说，这个想法是在指令集中增加更多的内容，同时也增加了可以提前编译并在单个"指令"中完成的工作量。独立指令集也意味着更长的调度循环，更长的跳转(尽管可以优化到最小化)，更少的缓存命中，但问题是多少?考虑到每条"指令"都只是一些汇编指令，那么大约7-8k条指令的汇编代码片段是否正常，还是太多了?考虑到平均指令大小在2-3b左右变化，这应该不超过20k内存，足以完全容纳大多数L1缓存。但这不是具体的数学，只是我在谷歌上搜索到的东西，所以也许我的"计算"错了?或者可能不是这样的?我对缓存机制没有经验。

对我来说，当我目前权衡这些参数时，"多指令"方法似乎最有可能获得最佳性能，当然，前提是我关于在L1缓存中适合"扩展调度循环"的理论是正确的。所以这就是你的专业知识和经验发挥作用的地方。既然上下文已经缩小，并且提出了一些支持思想，那么通过减少较慢的解释代码的数量，更大指令集的好处是否优于本机代码的大小增加，可能会更容易给出一个更具体的答案。

我的指令大小数据是基于这些统计。