纯面向对象语言SELF的性能分析与硬件支持评估

### 纯面向对象语言 SELF 的性能分析与硬件支持评估 #### 1. 面向对象语言与 C 语言的差异及优化影响 在面向对象编程领域，C++ 等面向对象语言与 C 语言存在显著的语义差异。然而，如果编译器采用面向对象特定的优化技术，这种差异可能会几乎完全消除。不过，在实际实现这样的系统之前，我们无法确定更好的优化是否真的能让其他面向对象语言在性能上更接近 C 语言。基于现有数据，在研究面向对象语言是否需要架构支持时，除非所使用的系统采用了最先进的优化技术，或者证明这些优化对特定语言无效，否则对于相关必要性的主张应持谨慎态度。 #### 2. 带标签算术的硬件支持 带标签的整数加法和减法指令是 SPARC 架构的独特特性，其灵感来源于 SOAR 项目的研究结果。这些特殊指令可以并行执行整数运算、标签检查（假设标签位于最低两位）和溢出检查。 在没有特殊硬件支持的情况下，对于整数加法表达式 `x + y`，在 SELF - 93 中会被编译成如下代码： ```plaintext if (x is integer) { if (y is integer) { a W x , y, temp); if (no overflow) ( result = temp; } else ... } else ... } else ... // 3 instructions (test, cond. branch, unfilled delay slot) // 2 instructions (fill delay slot with add) // 1 instruction // 1 instruction (cond. branch) // assign result (instruction in delay slot of branch) // handle ovefflow (code omitted for clarity) // handle non-integer y (code omitted for clarity) // handle non-integer x (code omitted for clarity) ``` 这个代码序列中，第一次 `if` 语句实现了对 “+” 消息的分发，内部代码是整数加法的内联方法，调用了标准系统中的 `IntAdd` 原语（也是内联的）。使用上述代码序列，一次整数加法需要八条指令。一个更优的代码序列会填充延迟槽，仅使用一次标签测试（通过先对 `x` 和 `y` 进行按位或操作），并消除额外的赋值操作，这样可以节省三条指令。下面的比较假设整数加法或减法使用六条指令的序列。 在 SPARC 架构中，给定带标签的加法指令，理想的加法代码序列只需一条指令： ```plaintext tagged-add-traplfError(x, y, result); ``` 这种带标签加法指令的变体（在 SPARC 语法中为 `taddcctv`）仅在 `x` 和 `y` 都具有整数标签且加法不溢出时才会将结果赋值给寄存器，否则会触发陷阱。由于运行时系统需要额外的机制来处理这些陷阱，并在必要时重新编译有问题的编译代码以避免频繁产生昂贵的陷阱，SELF - 93 实际上使用的是无陷阱的变体。为了得到带标签指令的最大效益上限，我们假设理想系统会充分利用带标签算术支持，在一个周期内执行所有整数加法和减法。 除了整数加法和减法，带标签指令在整数比较（类似于减法，但不检查算术溢出）和其他整数标签测试中也很有用，例如验证数组索引操作中的索引是否为整数的测试。对于这些操作中的每个整数标签测试，我们假设会有 2 个周期的开销（测试 + 分支 + 未填充的延迟槽 - 带标签加法）。因此，带标签算术指令节省的周期数为 `5 * (加法次数 + 减法次数) + 2 * 其他整数标签测试次数`。 不同程序中整数操作的频率和带标签指令的估计效益如下表所示： | 程序 | % 整数加法 | % 整数减法 | % 整数标签测试 | 硬件支持估计效益 | 更好编译器下的效益 | | --- | --- | --- | --- | --- | --- | | DeltaBlue | 0.5% | 0.1% | 1.8% | 6.4% | 4.1% | | Mango | 0.1% | 0.1% | 0.5% | 1.7% | 1.1% | | PrimMaker | 0.6% | 0.3% | 3.7% | 11.9% | 7.3% | | Richards | 0.3% | 0.2% | 1.4% | 5.1% | 3.2% | | Typeinf | 0.3% | 0.1% | 1.0% | 4.0% | 2.6% | | U13 | 0.4% | 0.4% | 2.3% | 8.3% | 5.3% | | Median | 0.3% | 0.2% | 1.7% | 5.9% | 3.7% | | | 0.6% | 0.1% | 2.4% | 8.1% | 5.1% | | | 0.6% | 0.3% | 1.9% | 8.2% | 5.4% | | | 0.4% | 0.2% | 1.8% | 6.4% | 4.1% | 从表中数据可以看出，整数算术指令的使用频率较低，仅约占所有指令的 0.6%，而其他整数标签测试更为频繁，中位数为 1.8%。如果没有对带标签整数的硬件支持，SELF 程序的运行速度将比充分利用带标签指令的系统慢 6%。 然而，实际的性能提升可能会更小，原因如下： - **编译器后端优化不足的假设**：我们假设编译器后端没有消除一些不必要的指令。一个更好的编译器可以在每次加法操作中节省一条指令（额外的赋值操作），并在每个标签测试中节省一条指令（通过填充延迟槽），从而将带标签指令的性能提升从 6.4% 降低到 4.1%。 - **指令计数与周期计数的差异**：仅计算指令数量会高估性能提升，因为代码序列中没有内存访问操作，可能接近 1.0 CPI（每指令周期数）执行，而在 SPARCstation - 2 上，基准程序的整体 CPI 更接近 2。因此，替换带标签指令的代码序列消耗约 6% 的所有指令，但仅消耗约 3% 的所有周期。具体的高估程度当然取决于机器，但我们认为即使在具有高分支惩罚的