Porting to Itanium & Gnat Ada
在 Ada 83 中使用 OpenVMS 平台开发的应用程序将通过 GNAT Ada 编译器迁移到 Itanium。
这个端口有什么风险？
是否有一个通用的迁移接受计划。
如果知道 GNAT Ada 和 DEC Ada 之间的浮点管理存在差异，我该如何验证此应用程序。
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
浮点类型的问题将在编译时检测到。我不记得 DEC Ada 的限制，但我在英特尔架构上使用 GNAT 的经验是，您最多可以有 18 个有效数字，这比我在 DEC Alpha 上使用 GNAT 所能拥有的要多。
我开发了一个应用程序，该应用程序从 DEC Ada 移植到 GNAT。据我了解，所有移植问题要么与表示条款有关，要么与源文本中的普通错误有关，DEC Ada 没有检测到。
我的猜测是你应该用 1 天/M 行 2 小时/表示条款来计算。
当然是时候运行完整的测试套件了。
我看到很晚。只是关于 FP 的精度。您可以将 DEC 特定的 FP 与 GNAT 一起使用。您只需重新编译所有指定您选择 DEC fp 格式的 ada 库。