现在的位置: 首页 > 综合 > 正文

内存对齐、const、static、extern

2019年04月20日 ⁄ 综合 ⁄ 共 7148字 ⁄ 字号 评论关闭

转自:http://blog.chinaunix.net/uid-10995602-id-2918694.html

       对于大部分程序员来说,“内存对齐”对他们来说都应该是“透明的”。“内存对齐”应该是编译器的“管辖范围”。编译器为程序中的每个“数据单元”安排在适当的位置上。但是C语言的一个特点就是太灵活,太强大,它允许你干预“内存对齐”。如果你想了解更加底层的秘密,“内存对齐”对你就不应该再透明了。

一、内存对齐的原因
大部分的参考资料都是如是说的:
1、平台原因(移植原因):不是所有的硬件平台都能访问任意地址上的任意数据的;某些硬件平台只能在某些地址处取某些特定类型的数据,否则抛出硬件异常。
2、性能原因:数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于,为了访问未对齐的内存,处理器需要作两次内存访问;而对齐的内存访问仅需要一次访问。

二、对齐规则
每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数)。程序员可以通过预编译命令#pragma pack(n),n=1,2,4,8,16来改变这一系数,其中的n就是你要指定的“对齐系数”。

规则:
1、数据成员对齐规则:结构(struct)(或联合(union))的数据成员,第一个数据成员放在offset为0的地方,以后每个数据成员的对齐按照#pragma pack指定的数值和这个数据成员自身长度中,比较小的那个进行。
2、结构(或联合)的整体对齐规则:在数据成员完成各自对齐之后,结构(或联合)本身也要进行对齐,对齐将按照#pragma pack指定的数值和结构(或联合)最大数据成员长度中,比较小的那个进行。
3、结合1、2颗推断:当#pragma pack的n值等于或超过所有数据成员长度的时候,这个n值的大小将不产生任何效果。

三、试验
我们通过一系列例子的详细说明来证明这个规则吧!
我试验用的编译器包括GCC 3.4.2和VC6.0的C编译器,平台为Windows XP + Sp2。

我们将用典型的struct对齐来说明。首先我们定义一个struct:
#pragma pack(n) /* n = 1, 2, 4, 8, 16 */
struct test_t {
 int a;
 char b;
 short c;
 char d;
};
#pragma pack(n)
首先我们首先确认在试验平台上的各个类型的size,经验证两个编译器的输出均为:
sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4

我们的试验过程如下:通过#pragma pack(n)改变“对齐系数”,然后察看sizeof(struct test_t)的值。

1、1字节对齐(#pragma pack(1))
输出结果:sizeof(struct test_t) = 8 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(1)
struct test_t {
 int a;  /* 长度4 >1 按1对齐;起始offset=0 0%1=0;存放位置区间[0,3] */
 char b;  /* 长度1 = 1 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
 short c; /* 长度2 > 1 按1对齐;起始offset=5 5%1=0;存放位置区间[5,6] */
 char d;  /* 长度1 = 1 按1对齐;起始offset=7 7%1=0;存放位置区间[7] */
};
#pragma pack()
成员总大小=8

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 1) = 1
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 8 /* 8%1=0 */ [注1]

2、2字节对齐(#pragma pack(2))
输出结果:sizeof(struct test_t) = 10 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(2)
struct test_t {
 int a;  /* 长度4 > 2 按2对齐;起始offset=0 0%2=0;存放位置区间[0,3] */
 char b;  /* 长度1 < 2 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
 short c; /* 长度2 = 2 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
 char d;  /* 长度1 < 2 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 2) = 2
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 10 /* 10%2=0 */

3、4字节对齐(#pragma pack(4))
输出结果:sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(4)
struct test_t {
 int a;  /* 长度4 = 4 按4对齐;起始offset=0 0%4=0;存放位置区间[0,3] */
 char b;  /* 长度1 < 4 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
 short c; /* 长度2 < 4 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
 char d;  /* 长度1 < 4 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 4) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */

4、8字节对齐(#pragma pack(8))
输出结果:sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(8)
struct test_t {
 int a;  /* 长度4 < 8 按4对齐;起始offset=0 0%4=0;存放位置区间[0,3] */
 char b;  /* 长度1 < 8 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
 short c; /* 长度2 < 8 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
 char d;  /* 长度1 < 8 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 8) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */

5、16字节对齐(#pragma pack(16))
输出结果:sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(16)
struct test_t {
 int a;  /* 长度4 < 16 按4对齐;起始offset=0 0%4=0;存放位置区间[0,3] */
 char b;  /* 长度1 < 16 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
 short c; /* 长度2 < 16 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
 char d;  /* 长度1 < 16 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 16) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */

四、结论
8字节和16字节对齐试验证明了“规则”的第3点:“当#pragma pack的n值等于或超过所有数据成员长度的时候,这个n值的大小将不产生任何效果”。另外内存对齐是个很复杂的东西,上面所说的在有些时候也可能不正确。呵呵^_^

[注1]
什么是“圆整”?
举例说明:如上面的8字节对齐中的“整体对齐”,整体大小=9 按 4 圆整 = 12
圆整的过程:从9开始每次加一,看是否能被4整除,这里9,10,11均不能被4整除,到12时可以,则圆整结束。

补充:

__alignof__可以获知typevarialbe的对齐

          

      __attribute__((aligned(8))) 设置类型为8字节对齐

1  const

c  onst限定的对象表示编译器可以将它放在只读存储器中,也就意味着在对其进行初始化之后就不能改变它的值。根据const使用的不同场合,大致可以分为三种情况,其一限定普通变量,其二限定函数参数,其三限定指针变量。

  第一和第二种情况最为简单,语句①和语句②分别展示了它的用法。语句①定义了一个值为10的整型常量。语句②中的const表示在函数体中不能修改src指向的区域中的数据,这与函数的拷贝功能相对应,只做它应该做的事情而不应该有其他副作用,编译器可以利用这些信息进行适当的优化。

  ① const int i=10;
  ② void *memcpy(void * dst, const void * src, size_t size);
  ③ const int *ptr;
  ④ int const *ptr;
  ⑤ int * const ptr;
  ⑥ int const * const ptr;

  第3种情况最为复杂,虽然只是const位置不同,但是却可能具有完全不同的意义。一般,一个声明语句由声明说明符(declspecifier)和一系列声明子(declarator)两部分组成,而且声明说明符中的符号可以以任何次序出现。理解声明的第一步是定位说明符和声明子的边界。这很容易:所有的说明符都是关键字或者类型名,因此说明符终止于第一个不是以上类型之一的符号。例如,在语句③和④中第一个既不是关键字也不是类型名的符号是“*”,即声明说明符分别为const int和int const,由于声明说明符中的符号可以以任意次序出现,因此语句③和④的含义是相同的。

  为了迅速弄清语句表达的含义,参考文献[1]介绍了一种简便的方法,其要点就是“逆序读出定义”,如图1所示。

按此在新窗口浏览图片
图1逆序读出声明的含义

2  static与extern

  static的含义随着出现位置(全局变量还是局部变量)和修饰对象(变量还是函数)的不同而有很大的差别。下面各条目中的模块指的是一个源文件或者一个翻译单元:

  ① 位于函数体中的静态变量在多次函数调用间会维持其值。
  ② 位于模块内(但在函数体外)的静态变量可以被模块内的所有函数访问,但不能被模块外其他函数访问。也就是说,它是一个本地的全局变量。
  ③ 位于模块内的静态函数只能被此模块内的其他函数调用。也就是说,这个函数的作用域为声明所在的模块。

  static int global;/*情况2*/
  static void foo(void)/*情况3*/
  {
    static int local = 0;/*情况1*/
  }

  为了清楚地理解static的3种用法,必须首先了解C语言中每个标识符都具有的作用域、链接和存储持续期等特性的含义。在ISO C99标准中,其定义如下:

  ① 对象的作用域指的是它仅在程序的某个区域中是可见的(即可以使用)。常见的作用域有文件作用域和块作用域。
  ② 对象的存储持续期决定对象的生命周期,即在程序执行某段区间中为对象保留存储区。有两种类型的存储持续期:静态的和自动的。静态存储持续期的对象的生命周期为程序执行的全过程,它的值在程序启动前仅初始化一次。
  ③ 链接指的是在不同作用域中声明的或者同一个作用域中多次声明的标识符可以引用相同的对象或函数。有3种类型的链接:外部、内部和无。

  在情况②和③中,static分别用来修饰全局变量global和函数foo,改变它们的链接特性,使它们具有内部链接。也就是说,只有在定义它们的翻译单元或者文件内才能使用它们,这对于创建模块化的软件非常重要。

  与static相反,extern修饰的对象或函数具有外部链接。对于那些暴露给外部使用的接口函数应该使用extern限定,那些非接口函数,例如工具函数或与实现细节相关的函数,则应该显式地使用static限定。这是因为如果函数声明不带任何存储类说明符,那么它具有外部链接就好像使用了extern一样。

  在情况①中,static用来修饰局部变量local,将local的存储持续期由自动的改变为静态的,这样在foo函数的多次调用间会为其保留值。注意作用域、链接和存储持续期特性之间是正交的。例如在情况①中,虽然变量local的存储持续期变成静态的,但是它的作用域仍然是块作用域。

3  volatile

  volatile关键字用来声明这样的对象,它们的值可能由于程序控制之外的事件而被潜在改变。volatile强制编译器不会对其所限定的对象进行任何优化,每次读写都必须访问实际的存储器而不能使用寄存器中的副本。在实践中,它大量的用来描述一个对应于内存映射的输入/输出端口,例如飞利浦公司LPC21xx系列ARM处理器的向量地址寄存器定义为:

  #define  VICVectAddr(*((volatile unsigned long *) 0xFFFFF030))

  其次,中断服务例程中使用的非自动变量或者多线程应用程序中多个任务共享的变量也必须使用volatile进行限定。例如在下面的示例中,如果没有使用volatile限定g_Flag变量,编译器看到在foo函数中并没有修改g_Flag,可能只执行一次g_Flag读操作并将g_Flag的值缓存在寄存器中,以后每次g_Flag读操作都使用寄存器中的缓存值而不进行存储器访问,导致some_action函数永远无法执行。

  int g_Flag = 0;
  void foo(void){
    while(1){
      if(g_Flag){ some_action(); }
    }
  }
  void isr_service(void){
    g_Flag = 1;
  }

4  __packed

  在嵌入式软件编程中,经常需要精确控制结构体在内存中的布局和访问非自然对齐的数据,但是C语言标准中并没有统一的规定而是留给编译器厂商自行处理。在ARM C编译器中,使用__packed关键字将任何类型的对齐设置为1字节。在实践中,__packed主要有两个功能:其一,当它修饰指针时,表示此指针指向的地址是非自然对齐的,编译器会生成特殊的代码以确保获得正确的结果;其二,当它修饰结构体、联合或它们中的域时,可以用来创建没有填充的结构。

  与其他RISC架构一样,ARM处理器能够高效地访问对齐的数据,即字地址的末尾两位为零,半字地址的最后一位为零,也称这样的数据位于它的自然大小边界或者是自然对齐的。ARM编译器希望普通的“C”指针指向一个4字节对齐内存地址,这样它可以在代码中使用LDR/STR指令一次操作4个字节,否则只能使用LDRB/LDRH等字节/半字操作指令。相反如果指针指向一个非自然对齐的地址,例如如果一个整型指针指向地址0x8006,当然希望装载地址0x8006-0x8007-0x8008-0x8009处的数据,但是实际上ARM会对非自然对齐的地址进行转换而从装载地址0x8004-0x8005-0x8006-0x8007处的数据。在下面的示例中(测试环境为uVision3),首先定义了一个大小为16字节的整型数组,依次初始化为0,1,2,…,15。由于array是一个整型数组,编译器会确保它是4字节对齐的,即指针pc指向一个4字节对齐的地址。运行程序后,可以看到如果对pc指针不加__packed标记进行修饰,将得到一个奇怪的0x01000302;而在添加了__packed关键字之后,就得到了正确的结果。也就是说,如果要访问非自然对齐的数据,必须使用__packed关键字显式地标记出来。

  int main() {
    int i, j, array[4];
    char *pc = (char *)array;
    for(i=0; i<16; i++){
      *(pc+i)=i;
    }
    /*确保pc指向一个4字节对齐的地址*/
    while((int)pc & 0x3){ ++pc; }
    /*访问非自然对齐的整型数据,i=0x01000302*/
    i = *((int*)(pc+2));
    //访问“标明”为非自然对齐的数据 i=0x05040302
    j = *((__packed int*)(pc+2));
  }

  ARM编译器总是保证程序中的变量、结构体或联合中的域分配到自然对齐的地址。这意味着编译器经常需要在各个域之间插入填充,以确保每个域的自然对齐。通常来说,程序员可以对这些填充视而不见,但是也有例外,例如为了节省结构体占用的空间,可以利用__packed去除填充。在了解了编译器的填充行为之后,可以通过调整域的顺序来减小结构体占用的空间。例如虽然结构体s1和s2的域相同,但是sizeof(s1)等于16,而sizeof(s2)等于12。

  struct s1{
    int i1;
    short s1;
    int i2;
    short s2;
  };
  struct s2{
    int i1;
    int i2;
    short s1;
    short s2;
  };

http://blog.sunyixing.com/archives/302

抱歉!评论已关闭.