字节序、比特序、大端、小端

梗概

本文介绍了字节序和比特序中的大端和小端,不同的cpu架构有不同的内存数据读写方式,但程序的数值计算发生在寄存器上,cpu通过在寄存器和内存的数据传输转换中对用户隐藏了大端小端;数据在网络中发送的时候会统一转成大端,在主机接收的时候根据主机的CPU架构自行转换,这维护了不同CPU架构下的数据通信;但仍有缺陷的是,如果在跨平台的程序中使用了位域,由于涉及到比特序块数据反转问题,需要手动处理。

字节序: 大端数和小端数

大端数(big-endian)和小端数(little-endian)是两种不同的数据存储方式,这两个中文会让人绕晕,从英文上是比较好理解的。

big-endian:大的部分(数的高位)在存储单元的尾部
little-endian:小的部分(数的低位)在存储单元的尾部

来看一张内存图, 从内存单元上来看排列顺序是这样的,也就是从下往上增长,从右往左增长,当一个指针指向一个int型(四内存单元)的变量时,指针的地址是地址最低的内存单元,CPU从内存中取数的时候是永远都是从最低位(右边)开始一个字节一个字节的取,将它放到寄存器中(寄存器永远是符合人类直觉的LE little-endian存储方式, 内存上的大小端存储经过CPU的加载到寄存器时被转换成LE little-endian, 从而隐藏了内存上的大小端),最左边是就是取一个数的尾部.


image.png

所以就很好理解了,对于一个数int a=0x01020304

内存地址 0x00000004 0x00000003 0x00000002 0x00000001
big-endian 04 03 02 01
little-endian 01 02 03 04

而字节序在CPU与程序中的本质是,字节序是在数据的存储字节大于1的时候,从内存加载一个字节到寄存器上的不同加载方式, 但使用数据的时候,无论是读short ,int 还是long long最终真正使用的是寄存器上的le little endian 的值,所以大小端对人是隐藏的,但当你一个一个去看内存的值的时候,就是直接加载到最低位,这时候就不同了。


image.png

验证机器是big-endian还是little-endian

union num{
int temp;
char c[4];
};

int main(){

union num number;
number.temp = 0x01020304;

cout<

网络传输中的字节序

网络中传输的字节序统一为big endian,主机上的数据在send的时候会通过hton进行转换,到接收端recv的时候ntoh恢复回来,如果hton在big endian架构的系统上是一个空宏

比特序

字节序是在数据的存储字节大于1的时候,从内存加载一个字节到寄存器上的不同加载方式。而比特序,则是加载一个8位的bit的时候到寄存器上的不同方式,一般而言比特序和主机的字节序保持一致是大端或者小端


image.png
image.png

网络传输中的比特序和跨平台程序

网络传输过程中,传输协议做了hton的字节序转换,而网卡则会替我们将比特序统一转换到大端,接收端网卡接收的时候根据自己的cpu架构进行转换,对于cpu,内存而言也是不可见的;但是在使用c的位域的时候,会出现问题,对于如下的结构体,

struct A{
     uint16_t first:4;
     uint16_t second:4;
}A;

从小端序传到大端序的主机上,比特序发生的倒序,cpu在读取的进寄存器时候可以解决,但是 first 和 second对应数值的比特块却完全颠倒了,这就需要手动矫正:


image.png

所以在涉及到位域的跨平台设计中常会看到如下内容,如此一来,在不同平台下,就会发生反转

struct A{
#if defined(__LITTLE_ENDIAN_BITFIELD)
     uint16_t first:4;
     uint16_t second:4;
#elif defined (__BIG_ENDIAN_BITFIELD)
     uint16_t second:4;
     uint16_t first:4;
}A;
image.png

具体参考:
https://www.linuxjournal.com/article/6788
https://blog.csdn.net/liuxingen/article/details/45420455/

你可能感兴趣的:(字节序、比特序、大端、小端)