如何解决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:不幸的是,我所看到的这些图像没有任何意义。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。