移植到 Itanium 和 Gnat Ada答案

【问题标题】：Porting to Itanium & Gnat Ada移植到 Itanium 和 Gnat Ada
【发布时间】：2018-02-11 21:13:58
【问题描述】：

在 Ada 83 中使用 OpenVMS 平台开发的应用程序将通过 GNAT Ada 编译器迁移到安腾。

这个港口有什么风险？
是否有通用的迁移接受计划。
如果知道 GNAT Ada 和 DEC Ada 之间的浮点管理存在差异，我该如何验证此应用程序。

【问题讨论】：

@trashgod 我不同意“过于宽泛”，至少对于验收计划而言。这个问题非常具体（即使它包含“通用”一词）：OP 为我们提供了迁移中涉及的操作系统和编译器，并要求提供一份清单。这样的清单可能是由已经走过这条迁移路径的人编制的，因此可能很容易获得。
Google 找到了我 this page 关于 Alpha 和 VAX 上的 DEC 编译器之间的兼容性，可能会提供一些注意事项的指示

标签： ada itanium

【解决方案1】：

浮点类型的问题将在编译时检测到。我不记得 DEC Ada 的限制，但我在英特尔架构上使用 GNAT 的经验是，您最多可以有 18 个有效数字，这比我在 DEC Alpha 上使用 GNAT 所能拥有的要多。

我开发了一个应用程序，该应用程序从 DEC Ada 移植到 GNAT。据我了解，所有移植问题要么与表示条款有关，要么与源文本中的普通错误有关，而 DEC Ada 没有检测到。

我的猜测是你应该用 1 天/M 行 + 2 小时/表示子句来计算。

当然是时候运行你的完整测试套件了。

【讨论】：

大多数 FP 类型的问题将在编译时检测到。由于不同的舍入计算，诸如 FP 值之间的相等比较之类的行为可能会有所不同（但这些首先是对 FP 的误用）。

【解决方案2】：

DEC 聘请了 ACT（现为 AdaCore）来使 GNAT DEC 编译器兼容，因此最大的努力可能是告诉 GNAT 文件名是什么。一旦 GNAT 知道哪些文件包含哪些 Ada 单元，使用 -gnat83 选项应该可以处理除特定于平台的代码之外的所有内容，并且可能会指出它无法处理的特定于平台的代码。使用 -gnat95 选项，您可能会遇到更多的不一致，但编译器应该指出这些，并且大多数 Ada-83 代码是有效的 Ada 95。* 移动到该语言的更高版本（-gnat05 和 -gnat12）将增加问题的机会。

一旦您设置好 GNAT 可以编译您的代码，使用 -gnat83 进行编译应该会让您了解所需的工作量。很可能它会变得相当小。

*我曾经通过重新编译将几千个结束符分号的 Ada-83 代码移植到 Ada 95。当然，该代码被适当地设计和实现为独立于编译器和平台，幸运的是没有使用任何新的 Ada-95 保留字作为标识符。 YMMV

【讨论】：

【解决方案3】：

我看到很晚。只是关于 FP 的精确度。您可以将 DEC 特定的 FP 与 GNAT 一起使用。您只需重新编译所有指定您选择 DEC fp 格式的 ada 库。

【讨论】：