1. What is byte alignment and why alignment? In modern computers, memory space is divided by byte. Theoretically, it seems that access to any type of variables can start from any address, however, the actual situation is that access to specific types of variables is often performed at specific memory addresses, which requires various types of data to be arranged in space according to certain rules, instead of sequential emissions, this is alignment. The role and cause of Uniformity: Each hardware platform has a big difference in processing the storage space. Some platforms can only access certain types of data from some specific addresses. For example, some architectures may encounter errors when the CPU accesses a variable that is not aligned, so in this architecture, the programming must ensure the byte alignment, which may not happen on other platforms, however, if the data is not aligned according to the appropriate platform requirements, the access efficiency will be compromised. For example, some platforms start from the even address each time they read data. If an int type (assuming a 32-bit System) is stored at the beginning of the even address, the 32bit can be read in a read cycle, if the data is stored at the beginning of the odd address, two read cycles are required, and the high and low bytes of the two read results are pieced together to obtain the 32bit data, obviously, reading efficiency is greatly reduced. Ii. byte alignmentProgramImpact Let's take a look at the following example (32bit, x86 environment, VC compiler) The struct is defined as follows: Struct { Int; Char B; Short C; }; Struct B { Char B; Int; Short C; }; What is the size of the above two structures? The result is: The value of sizeof (struct a) is 8. The value of sizeof (struct B) is 12. Struct a contains a four-byte int, a one-byte char, and a two-byte short data. The same applies to B., B must be 7 bytes in size. The above result is displayed because the compiler needs to align data members in space. The above is the result of alignment according to the default settings of the compiler. Can we change the default alignment settings of the compiler? Of course. For example: # Pragma pack (2)/* specify to align by 2 bytes */ # Pragma pack (1)/* specify to align by 1 byte */ # Pragma pack ()/* cancel the specified alignment and restore the default alignment */ When the values are aligned by 2 bytes, the values of A and B are both 8, and the values of A and B are both 7 when the values are aligned by 1 byte. Iii. What principles does the compiler align? Let's take a look at four important concepts: 1. alignment value of the Data Type itself: For char-type data, its alignment value is 1, for Short-type data is 2, for int, float, double type, its own alignment value is 4 bytes. 2. The alignment value of a struct or class: The value with the largest alignment value among its members. 3. Specify the alignment value: # The alignment value specified when Pragma pack (value) is used. 4. Valid alignment values of data members, struct, and classes: the alignment value of the data itself and the value smaller than the specified alignment value. With these values, we can easily discuss the data structure members and their alignment. The valid alignment value n is the final value used to determine the data storage address. Effective alignment means "alignment on N", that is, "Storage Start address % n = 0" of the data ". Data variables in the data structure are discharged in the defined order. The starting address of the first data variable is the starting address of the data structure. The member variables of the struct must be aligned to the emissions, and the struct itself must be rounded according to its own valid alignment values (that is, the total length occupied by the member variables of the struct must be an integer multiple of the valid alignment values of the struct, ). In this way, it is not difficult to understand the values of the above examples. Analysis structure B: Assume that B is discharged from the address space 0x0000. In this example, the alignment value is not defined. In VC, the default value is 8. The alignment value of the first member variable B is 1, which is smaller than the specified or default alignment value. Therefore, the valid alignment value of B is 1, therefore, the storage address 0x0000 conforms to 0 x 0000% 1 = 0. The alignment value of the second member variable A is 4, so the valid alignment value is 4, therefore, it can only be stored in the four consecutive bytes from the starting address 0x0004 to 0x0007. Check that 0 x 0004% 4 = 0 is placed next to the first variable. The third variable C has its own alignment value of 2, so the valid alignment is also 2, which can be stored in the two bytes from 0x0008 to 0x0009, Which is 0 x 0008% 2 = 0. Therefore, B content is stored from 0x0008 to 0x0009. Then, let's look at the alignment value of Data Structure B as the maximum alignment value in its variable (here it is B), so it is 4, so the valid alignment value of the structure is also 4. According to the requirements of the struct circle, 0x00000 to x0009 contains 10 bytes, (10 + 2) % 4 = 0. Therefore, 0x000a to 0x000b is also occupied by struct B. Therefore, B has 12 bytes from 0x0000 to 0x000b, And the last value of sizeof (struct B) is also 12. In fact, if this one is used, it will satisfy the byte alignment, because its starting address is 0, it must be aligned. The reason why two bytes are added to the end is that the compiler aims to implement the access efficiency of the struct array, imagine if we define an array of struct B, then the starting address of the first struct is 0, but what about the second structure? According to the definition of the array, the elements in the array are close to each other. If we do not add the size of the struct to an integer multiple of 4, the starting address of the next structure will be 0x000a, this obviously cannot satisfy the address alignment of the structure, so we need to add the structure to an integer multiple of the valid alignment size. In fact, for char data, its own alignment is 1, for short type is 2, for int, float, double type, its own alignment value is 4, the alignment values of these existing types are also based on the array, but they are also known because the length of these types is known. Similarly, analyze the following example C: # Pragma pack (2)/* specify to align by 2 bytes */ Struct C { Char B; Int; Short C; } The first variable B's own alignment value is 1 and the specified alignment value is 2. Therefore, the valid alignment value of B is 1. Suppose C starts from 0x0000, then B is stored in 0x0000, conforms to 0 x 0000% 1 = 0; the second variable, its own alignment value is 4, and the specified alignment value is 2, so the valid alignment value is 2, therefore, the data is stored in four consecutive bytes, namely 0x0002, 0x0003, 0x0004, and 0 x 0002%. The alignment value of the third variable C is 2, so the valid alignment value is 2. The order is 0x0006, 0 x 0006% 2 = 0. Therefore, from 0x0000 to 0x0007, a total of eight characters are stored in the C variable. And C's own alignment value is 4, so the valid alignment value of C is 2. Again 8% 2 = 0, C only occupies eight bytes from 0x0000 to 0x0007. So sizeof (struct c) = 8. 4. How should we consider byte alignment in programming? If we want to save space during programming, we only need to assume that the first address of the structure is 0, and then sort the variables according to the above principles, the basic principle is to declare the variables in the structure according to the type size from small to large, and minimize the space to fill. Another way is to take the space for the efficiency of time, we show to fill the space for alignment, for example, there is a way to use the space for time is to explicitly insert reserved members: Struct { Char; Char reserved [3]; // use space for time Int B; }; The reserved member has no significance for our program. It just fills the space to achieve byte alignment. Of course, even if this member is not added, the compiler will automatically fill the alignment for us, we add it as a reminder. 5. potential risks of byte alignment CodeMany of the risks of alignment are implicit. For example, in forced type conversion. For example: Unsigned int I = 0x12345678; Unsigned char * P = NULL; Unsigned short * P1 = NULL; P = & I; * P = 0x00; P1 = (unsigned short *) (p + 1 ); * P1 = 0x0000; The last two lines of code access the unsigned short variable from the odd boundary, which obviously does not comply with the alignment rules. On x86, similar operations only affect the efficiency, but on MIPS or iSCSI, they may be an error because they require the bytes to be aligned. |