c++ - 将 MIPS 代码移植到 x86_64 时的浮点差异

Question

我目前正致力于将使用 MIPSPro 为 SGI 编写和编译的一段代码移植到带有 gcc 4.4.7 的 RHEL 6.7。我的目标架构是 x86_64 我能够为此代码生成一个可执行文件，现在我正在尝试运行它。

我正在尝试从文件中读取二进制数据，该文件是在 SGI 系统中生成的，基本上是将对象的指针转换为 char*。并将其保存到文件中。我正在尝试读取的二进制数据或多或少具有以下格式:

[ Header, Object A , Object B, ..., Object N ]

其中每个对象都是不同类的实例化。

代码当前处理文件的方式是将其全部读入内存，并获取指向对象开始位置的指针并使用reinterpret_class<Class A>(pointer)。给它。有些事告诉我，最初设计它的人并不关心便携性。

到目前为止，我能够通过交换字节来处理 Header 对象的字节顺序。不幸的是，对象 A、B、..、N 都包含 double 类型的字段并尝试对 8 个字节进行字节交换似乎不起作用。

那么我的问题是，SGI/MIPSPro 中的 double 结构是否与 Linux 中的结构不同？我知道 sizeof(double)在 SGI 机器返回 8所以我认为它们的大小相同。

Answer 1

根据 the MIPSPro ABI :

the MIPS processors conform to the IEEE 754 floating point standard

您的目标平台，x86_64, shares this quality .

因此，double 在两个平台上都表示 IEEE-754 double float 。

就字节顺序而言，x86_64 处理器是小端；但是，根据 the MIPSpro assembly programmers' guide , 一些 MIPSPro 处理器是大端的:

For R4000 and earlier systems, byte ordering is configurable into either big-endian or little-endian byte ordering (configuration occurs during hardware reset). When configured as a big-endian system, byte 0 is always the most-significant (leftmost) byte. When configured as a little-endian system, byte 0 is always the least-significant (rightmost byte).

The R8000 CPU, at present, supports big-endian only

因此，您必须检查原始平台的数据表，看看是否需要任何字节交换。