2

见鬼，我决定看看我多年前开始在 Amiga 上编写并在其他机器上进一步开发的程序是否仍然可以在 Amiga 上编译和运行（在其他机器上开发之后）。我最初使用 Lattice C，因为那是我以前使用的。但是 Lattice 对 68881 的支持非常有问题。所以我决定尝试 gcc。我认为 Amiga 的 gcc 最新版本是 2.7.0（所以我无法升级）。它工作得相当好，除了 68881 支持中的一个错误：当任何负数乘以零时，结果总是：

1.:00000

打印出来时（冒号不是错字）。顺便说一句，如果您将 x 设置为零，然后打印出来，它应该是 0.00000。

这是一个测试错误的示例程序，哪个变量是0哪个是负数都没有关系，如果非零值是正数，它就可以正常工作。

#include <stdio.h>
#include <math.h>

main()
{
    float x,a,b;

    a=-10.0;
    b=0.0;
    x=a*b;
    printf("%f\n",x);
}

它是用以下方式编译的： gcc -o tt -m68020 -m68881 tt.c -lm

取出-m68881工作正常（但当然，不使用 FPU）取出-lm和/或math.h没有任何区别。

有谁知道错误修复或解决方法？也许是 gcc 命令行参数？（宁愿不必做像“ if ((a<0)&&(b==0))”这样的丑事）

顺便说一句，由于我不再有工作的 Amiga，我不得不使用模拟器。如果你想看看我在这个项目上做了什么（使用 Lattice C 版本），你可以在以下位置观看我的视频：

https://www.youtube.com/watch?v=x8O-qYQvP4M

（Amiga部分从10:07开始）

谢谢你的帮助。

4

1 回答 1

0

这并不完全是一个答案，而是揭示了问题相当复杂（比 gcc 的简单错误更复杂）。这是信息：

如果我使用 68040 的内部 FPU 将 Amiga 模拟器设置为模拟 68020 或 68030 和 68881 或 68882 INSTEAD 的 68040，它不会产生 1.:00000（换句话说，它可以工作）。所以这可能意味着模拟器没有正确模拟 68040 的 FPU（尽管我认为 68040 的 FPU 可能与 68881/68882 兼容）。（不知道将模拟器设置为 68020/30 68881/2 是否会影响性能（我将模拟器设置为在主机上尽可能快地运行，而不是以 680xx 的速度运行））。

但是，如果我使用 Amiga 的 gcc 的 -noixemul 选项进行编译，则代码在 CPU 和 FPU 的每种组合中都能正常工作。所以这表明这是 Amiga 版本的 gcc 的问题（实际上是 gcc 系统的一部分，它试图在 Amiga 上模拟 UNIX（这就是 ixemul.library 所做的））。所以这可能不是 gcc 的错（如果它是在使用 68040 的其他系统上编译的，它可能会工作），而是将 gcc 移植到 Amiga 的人的错。

因此，您可能会说“问题已解决，只需使用 -noixemul” - 好吧，没那么快......虽然简单的测试程序没有崩溃，但我暴露这个问题的更大程序仅在程序退出时崩溃（可恢复的 GURU 冥想）用 -noixemul 编译（也许它试图关闭一个从未打开的库，我不知道）。这就是为什么我没有使用 -noixemul 的原因，尽管我想这样做。

所以，它并没有完全解决，但我会说它不太可能是非 Amiga gcc 错误。

于 2019-12-26T07:39:00.707 回答