big Endian Little Endian

大端(Big Endian)与小端(Little Endian)详解


来源: ChinaUnix博客 　日期： 2008.01.25 10:24　(共有0条评论) 我要评论


【大端(Big Endian)与小端(Little Endian)简介】
Byte Endian是指字节在内存中的组织，所以也称它为Byte Ordering，或Byte Order。
对于数据中跨越多个字节的对象， 我们必须为它建立这样的约定:
(1) 它的地址是多少?
(2) 它的字节在内存中是如何组织的?
针对第一个问题，有这样的解释:
对于跨越多个字节的对象，一般它所占的字节都是连续的，它的地址等于它所占字节最低地址。(链表可能是个例外， 但链表的地址可看作链表头的地址)。
比如: int x， 它的地址为0x100。 那么它占据了内存中的Ox100， 0x101， 0x102， 0x103这四个字节（32位系统，所以int占用4个字节）。
上面只是内存字节组织的一种情况: 多字节对象在内存中的组织有一般有两种约定。 考虑一个W位的整数。
它的各位表达如下:[Xw-1， Xw-2， ... ， X1， X0],它的
MSB (Most Significant Byte， 最高有效字节)为 [Xw-1， Xw-2， ... Xw-8];
LSB (Least Significant Byte， 最低有效字节)为 [X7，X6，...， X0]。
其余的字节位于MSB， LSB之间。
LSB和MSB谁位于内存的最低地址， 即谁代表该对象的地址?
这就引出了大端(Big Endian)与小端(Little Endian)的问题。
如果LSB在MSB前面， 既LSB是低地址， 则该机器是小端; 反之则是大端。
大端和小端是针对字节为单位定义的。
DEC (Digital Equipment Corporation，现在是Compaq公司的一部分)和Intel的机器（X86平台）一般采用小端。
IBM， Motorola(Power PC)， Sun的机器一般采用大端。
当然，这不代表所有情况。有的CPU即能工作于小端， 又能工作于大端， 比如ARM， Alpha，摩托罗拉的PowerPC。 具体情形参考处理器手册。
具体这类CPU是大端还是小端，应该和具体设置有关。
（如，Power PC支持little-endian字节序，但在默认配置时是big-endian字节序）
一般来说，大部分用户的操作系统（如windows, FreeBsd,Linux）是Little Endian的。少部分，如MAC OS ,是Big Endian 的。
所以说，Little Endian还是Big Endian与操作系统和芯片类型都有关系。
Linux系统中，你可以在/usr/include/中（包括子目录）查找字符串BYTE_ORDER(或
_BYTE_ORDER, __BYTE_ORDER)，确定其值。BYTE_ORDER中文称为字节序。这个值一般在endian.h或machine/endian.h文件中可以找到,有时在feature.h中，不同的操作系统可能有所不同。
对于一个数0x1122
使用Little Endian方式时，低字节存储0x22，高字节存储0x11
而使用Big Endian方式时, 低字节存储0x11, 高字节存储0x22
【用函数判断系统是Big Endian还是Little Endian】
bool IsBig_Endian()
//如果字节序为big-endian，返回true;
//反之为 little-endian，返回false
{
unsigned short test = x1122;
if(*( (unsigned char*) &test ) == 0x11)
return TRUE;
else
return FALSE;
}//IsBig_Endian()
以上内容，整理自：
如何判断系统是Big Endian还是Little Endian？
http://jlingmei.spaces.live.com/blog/cns!77254CCC13222C11!391.entry?wa=wsignin1.0
判断机器字节存储顺序是big endian还是little endian
http://hi.baidu.com/cppyun/blog/item/9625c8396d5ff7f33b87ce33.html
动态判断cpu字节序是big-endian还是little-endian
http://chongyanglee.bokee.com/4919503.html


本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/feelinghappy/archive/2010/09/03/5862184.aspx