“奔腾安全的 FDIV”……在 2014 年？答案

【问题标题】："Pentium-safe FDIV" ... in year 2014?“奔腾安全的 FDIV”……在 2014 年？
【发布时间】：2014-07-28 20:42:25
【问题描述】：

每次查看编译器设置时，我都会想到同样的问题：为什么当前的 Delphi 编译器仍然有“Pentium-safe FDIV”编译器选项？

Pentium-FDIV-Bug 于 1994 年 11 月被发现，并没有出现在 1995 年的 CPU 型号中。当时的处理器可能只在 Windows 95、98 和 Me 上工作得足够强大。据我所知，第一个 133 MHz（因此速度足以达到 Windows 2000 的最低系统要求）的 Intel Pentium 1 CPU 于 1995 年 6 月发布，当然没有 FDIV 错误。

当前 Delphi 版本的 VCL/RTL 使用了在古代操作系统中不可用的 Windows API。 Windows 98 和 Me 不能使用空的 Delphi XE6 VCL 应用程序；我没有检查 Delphi XE6 的 VCL/RTL 是否已经破坏了 Windows 2000 的兼容性，但我认为是。

那么，当 Embarcadero 放弃对 2000 年使用的操作系统的支持时，为什么保留 1994 年使用的编译器开关？因此，没有人会需要这个编译选项，因为受影响的 CPU 不会与 VCL/RTL 所需的操作系统兼容。

更新；为了澄清这个问题：这个开关是否有任何用例可能有用？还是编译器在内部忽略了该选项，它只是为了保留旧项目文件的选项？

【问题讨论】：

通常你不会破坏向后兼容性。当移除一个特征的工作量大于保留它的工作量时，就没有动力去移除它。
@LU +1。我想如果你把它作为答案发布，它应该被接受:)

标签： delphi compiler-construction cpu

【解决方案1】：

这只是道听途说，但显然 Delphi 编译器是用汇编语言编写的，基本上无法维护。他们不会删除任何功能，仅仅是因为在编译器中进行任何类型的更改都非常困难，因此他们不会打扰。

【讨论】：

【解决方案2】：

如果您正在寻找“官方”答案，那么您不太可能得到答案。非正式地，我当然可以向您指出大卫的回答。他关于推理的三点很清楚。除非有令人信服的理由删除该功能，否则它没有太大的商业或技术意义。应该删除它的唯一原因是，如果 x86 后端完全从头开始重写......在这种情况下，它并没有被删除，而是一开始就不会被考虑在内。

我会注意到，新的 AMD64/ia64 和基于 LLVM 的 ARM 后端不会对该指令执行任何操作，因为这些 CPU 不受影响应该是不言而喻的。指令/选项被识别，但只是被忽略。

【讨论】：

令人信服的理由？它使编译器看起来有 20 年的历史了……如果您不打算将其从代码中删除，至少将其隐藏并使其处于禁用状态。同时，改进对 Windows 95 之后发布的任何东西的 Delphi 支持......很多代码仍然不使用比 Windows NT 更新的 API（查看服务实现......）
任何更改都会带来风险。如果它没有真正伤害任何东西，为什么还要打扰？资源不是无限的，所以我们不应该把时间花在其他事情上吗？至于支持较新的 Windows 功能，没有什么能阻止您深入定义 API 并自己调用它们。无需为他们等待新版本。
@Bauer：当然，任何更改都会带来风险，因此为了避免风险，Delphi 编译器陷入了 20 年前创建的时间泡沫中。此外，如果我必须自己调用 API，因为 Delphi VCL 框架也被困在同一个时间泡泡中，我可以从 C/C++ 比从 Delphi 更容易地做到这一点，至少我不必每次都翻译标题。我们确实为 Delphi 付费，因为我们确实希望有人不断更新编译器和框架 - 如果需要，可以承担一些风险。你的资源是有限的，因为你现在的技能非常有限，无法再改进。
从不知道他们在说什么的人那里说得好。 FTR，最新版本确实为 x86 添加了更多浮点优化，这是一件冒险的事情。多年来，编译器已经添加了泛型、内联、x64、ARM 等。那么，不承担任何风险意味着什么呢？所以你愿意放弃整个项目，这样你就不必为了调用它们而声明几个新的 API？夸张很多？如果你继续磨它，斧头最终会消失的......
@Bauer：看起来您的开发人员对他们的工作内容一无所知。当软件变得“不可触碰”时，因为没有人知道如果有人这样做会不会出错，很明显公司中没有人再了解代码库了。我们都知道困扰几个版本的泛型问题，XE6 中糟糕的浮点代码生成等等。很明显编译器在错误的人手中。将旧的、过时的代码保留在编译器中而不是清理它只会增加更混乱的代码。这就解释了为什么 Delphi 本机代码与其他人的代码不相上下

【解决方案3】：

Delphi 仍然允许制作控制台应用程序。除非您的控制台应用程序依赖于较新的 Windows API，否则您可以轻松地使其与 Windows 95 兼容。

【讨论】：

Delphi 支持控制台应用程序（这是一个永远不会被删除的基本功能）这一事实无关紧要。默认的空 Delphi XE6 项目通过加载时间链接链接到 Unicode API。所以它只能在带有 Unicode API 的 Windows 版本上运行。这意味着基于 NT 的系统。事实上，我认为 Windows 95 上不存在许多其他链接的 API。Windows 95 无法胜任运行现代 Delphi 可执行文件的工作。
@DavidHeffernan 你是对的。我只是做了一个小测试，似乎即使是使用较新版本的 Delphi 制作的控制台应用程序也需要至少 Windows 2000，因为它们从 kernel32.dll 调用某些函数，这些函数在旧版本的 kernel32.dll 中不存在，例如获取操作系统默认语言（多语言应用程序支持）。所以我上面关于能够使用将在 Windows 95 上运行的较新版本的 Delphi 制作控制台应用程序的说法是错误的。
记录在案：embarcadero.com/products/delphi/frequently-asked-questions 确实与控制台应用无关
控制台应用程序是完全原生的 Windows 应用程序，链接 Windows API - 只是没有 GUI - 记住！它们不是“DOS”应用程序。 Windows 本身依赖于控制台应用程序来执行一些低级任务，并且在服务器上，您可以只在控制台处于活动状态、没有 shell、没有 GUI 应用程序的情况下运行 Windows。如果 Delphi 删除控制台应用程序，它将成为一个功能远不如 Windows 开发工具。

【解决方案4】：

Pentium 分割错误影响了许多非常早期的 Pentium 型号。受影响型号的最高时钟速度为 100MHz。官方文档表明Delphi XE6针对Vista及以上，但实际上仍然可以针对Windows XP，而且我相信XE6可以制作在Windows 2000上运行的可执行文件。XP的最低要求是233MHz的处理器，并且对于Windows 2000 133MHz 处理器。

因此，您可以在有缺陷的奔腾处理器上运行由 XE6 编译的代码，这几乎是合理的。实际上，至少在过去的 15 年里，Embarcadero 没有人会觉得有义务支持有缺陷的 Pentium 处理器。在 21 世纪，它们根本就没有出现在野外。

那么，为什么没有删除编译器功能？只有 Embarcadero 知道答案，但我可以给出几个明显的原因：

删除该功能会干扰向后兼容性。如果有人在启用开关的情况下构建，即使他们不需要，那么移除它也会影响他们。
删除功能成本。这样做涉及对 UI、编译器、文档、测试套件等的更改。
删除该功能会带来风险。每当您更改代码，即经过多年尝试和测试的代码时，您就有引入新缺陷的风险。

【讨论】：

向后兼容性还有另一个方面：如果删除该选项，任何明确表示“我不关心旧奔腾，禁用此选项”的代码都会也失败。
好吧，有趣的是，他们可能会在删除那个旧的、过时的、无用的选项之前尝试删除诸如 GetMem() 或指针之类的功能......是否有人依赖于将其激活用于实际代码 - 二十年后来 flwaed Pentium 交付了，好吧，他或她应该得到他或她的代码中可能出现的任何问题......