Little Endian与Big Endian架构

问题描述

我有一个疑问，这与大学教授关于Endianness有点不同，所以我没有找到解决这个问题的方法，没有找到正确的答案，而是在Stack Overflow社区中进行了讨论。

假设我们将这个数字（十六进制）11FF1定义为整数，例如，在C ++中，它将是： int num = 0x11FF1 ，而 我说 ，该数字将在小端机器中的内存中显示为：

 addr[0] is f1   addr[1] is 1f   addr[2] is 01   addr[3] is 00
 in binary : 1111 0001   0001 1111   0000 0001   0000 0000

编译器将 0x11ff1 视为 0x0001ff1 ，还将 00 视为第一个字节和 01 作为第二个字节，依此类推，对于 Big Endian ，我认为它看起来像：

 addr[0] is 00   addr[1] is 01   addr[2] is 1f   addr[3] is f1
 in binary : 0000 0000   0000 0001   0001 1111   1111 0001

但他有另一种看法， 他说 ：

小尾数法

Big Endian ：

实际上，我看不到他的陈述中有任何逻辑，因此我希望开发人员解决此分歧，谢谢。

解决方法

您的十六进制和二进制数字正确。

您（教授？）的小尾数法式图像完全没有意义，这三种表示形式都不与其他两种表示形式一致。

73713的十六进制为0x11ff1，因此没有任何0xFF字节（二进制11111111）。
在32位little-endian中，字节按F1 1F 01 00的顺序递增内存地址。
您可以通过从完整十六进制值的低端获取成对的十六进制数字（字节/八位字节）来获取该值，然后在消耗完该值后以零填充。

看起来它们可能用{s而不是0x11ff1000而不是0x00011ff1来填充十六进制值的错误一侧，以0扩展到32位。请注意，这些是整数的完整十六进制值，而不是试图以任何顺序将其分解为单独的十六进制字节。

但是十六进制和二进制不匹配；它们的二进制结尾以全为一个字节，因此它以FF作为高字节，而不是第3个字节。我没有检查是否与他们在PDP（混合）字节序中的十六进制相符。

他们将十六进制列分成4个字节大小的组，这似乎表明它按内存顺序显示字节。但这列在他们的大端和小端图像之间是相同的，因此显然这不是他们在做的，他们实际上只是通过左移将其扩展为32位（填充低而不是高零）。 / p>

此外，大字节序与小字节序中的二进制字段不是彼此相反的。要从大字节序到小字节序翻转，请反转整数中字节的顺序，并使每个字节值保持相同。 （如x86 bswap）。他们的11111111（FF）字节在大端版本中是第二个，但在小端版本中是最后一个。

TL：DR：不幸的是，我所看到的这些图像没有任何意义。