compiler-construction - 非机器字原语的倍数是个好主意吗？

Question

假设您有一种动态语言（类似于常见的脚本语言）并想为它编写一个编译器。为类型标签之类的东西保留一些机器字是个好主意吗？特别是对于微控制器和类似设备，这是一个好主意吗？

我可以想到一些优点，例如减少类型信息的存储，更容易的内存管理（甚至可能是 gc）和更容易调试。但是这些是否可以证明普通算术运算或其他需要完整单词的运算的开销是合理的？请注意，字节码虚拟机在这方面会更糟，因为性能开销要大得多。所以不建议这样做；）

无论如何，有些人不会为微控制器级硬件编写数字密集型代码，但仍然......

Answer 1

必须确保您的类型位不会通过任何计算所增加的复杂性可能远远超过任何存储节省。您始终可以分配与包含任何所需元数据/标志的任何原始字段相邻的类型字段。然后你知道任何值的存储大小总是 n+1 个字，假设你可以用一个字来存储你想要的类型和状态信息。

Answer 2

SPARC芯片直接在硬件中标记了算术工具 - 专门为此类应用程序设计。我还看到了对具有此功能的其他架构的引用。它们在实践中的广泛使用是另一个问题 - 大多数动态语言（如 Python）都是为可移植性而构建的，因此在您的架构中并没有真正选择依赖它的选项。

我认为旧的 smalltalks 过去常常用小整数来做到这一点 - 直到某个值是一个 int 并且超过阈值是一个对象指针。

Answer 3

这可能取决于您的微控制器的“微型”程度。

例如，我猜测（从未尝试过）ARM 内核上的桶形移位器和/或您可以在加载/存储时拥有的免费掩码将使处理这些标志的成本保持相当合理。显然，这是一流的，但如今 ARM 确实无处不在。

LISP 使用类型标志，这意味着 fixnum 小于一个单词。因此，您可以查看 LISP 实现（如果您可以为您关心的处理器找到它们），看看它们如何最大限度地降低成本，以及它们是否会尽最大努力满足您的要求。

Answer 4

不，这对于通用编译器来说绝不是一个好主意。在算术运算中处理“类型标签”位的开销将是严重的。

就其本质而言，动态类型语言需要额外的空间来存储每个值的类型信息。如果您必须存储大量同质类型的数据，正确的方法通常是使用设计用于在 C 中执行此操作的本机代码模块！

例如，当你想存储一个由 5 个整数组成的数组时，一个 Pythonlist就可以了（它可以存储任意复杂的混合类型）。但是，如果你想存储一个包含 500 万个整数的数组，你应该使用将array它们存储为同构 C 数组的模块，或者使用 NumPy 来执行类似的操作，但针对对它们进行大量数学运算进行了优化。

Answer 5

一方面，如果您希望编译后的代码直接测试每个操作的标志，它会很慢，原因与解释的字节码很慢一样。也许不像字节码那么慢，但阿姆达尔定律会对你不利。

另一方面，完全动态语言的简单编译器无论如何都需要进行某种形式的类型检查。动态调度的普遍使用将对现代处理器造成严重的性能损失（尽管对于微控制器来说可能没有那么严重？）

如果您的编译器可以优化上述大部分运行时类型检查，则可以恢复性能。然而，实现这一点可能既不简单也不简单。我的猜测是，在这种情况下，您希望避免使用位标志，因为所需的屏蔽只是不必要的工作。