This question already has answers here:
Are stack variables aligned by the GCC __attribute__((aligned(x)))?
(4 answers)
Closed 5 years ago.
I have the following local variable (that will get stored in the stack).
struct test1 {
int a;
int b;
char c;
};
How do I align the starting address of integer a to a 16byte boundary in the stack?
I am running this C code on a custom written MIPS ISA processor.
Here is some non-standard way of aligning your data.
struct test1 *pdata;
// here we assume data on stack is word aligned
pdata = alloca(sizeof(*pdata) + 14);
if (pdata & 0xF)
{
pdata = (unsigned char*)pdata + 16 - (pdata & 0xF);
}
AFAIK On MIPS ISA C compilers are forced align to word boundaries in this case, just add an int (which is 32 bit) to the structure. so:
struct test1 {
int a; // 4 bytes
int b; // 4 bytes
int foralign;// 4 bytes for 16 byte alignment
char c; // 1 byte but will be aligned 4 bytes
};
Unfortunately there's no standard way to get objects aligned like that. There's almost always some compiler-specific trick, such as __attribute__ in GCC, but you'll have to check your compiler's documentation.
(Of course there's no standard use for that kind of alignment either, which is why there's no standard method for achieving it. So you're probably resorting to extensions already, so there's no real harm going further.)
A union that contains a large-enough elemental object often does the trick, but I believe the largest elemental C objects for MIPS CPUs are long long and double, which are only 8 bytes.
Related
This question already has answers here:
memory alignment within gcc structs
(6 answers)
Closed 6 years ago.
I’m unsure on whether it’s normal or it’s a compiler bug but I have a C struct with lot of members. Among of them, there’s, :
struct list {
...
...
const unsigned char nop=0x90; // 27 bytes since the begining of the structure
const unsigned char jump=0xeb; // 28 bytes since the begining of the structure
const unsigned char hlt=0xf4; // 29 bytes since the begining of the structure
unsigned __int128 i=0xeb90eb90eb90eb90f4f4 // should start at the 30th byte, but get aligned on a 16 byte boundary and starts on the 32th byte instead
const unsigned char data=0x66; // should start at the 46th byte, but start on the 48th instead.
}; // end of struct list.
I had a hard time to find out why my program wasn’t working, but I finally found there’s a 2 bytes gap between hltand i which is set to 0x0. This means that the i is getting aligned.
This is very clear when I printf that part of the structure, because with :
for(int i=28;i<35;i++)
printf("%02hhX",buf[i]);
I get EBF40000EB90EB90 on the screen.
I tried things like volatile struct list data;in my program, but it didn’t changed the alignment problem.
So is there a #pragma or a __attribute__to tell gcc to not align i inside struct listtype ?
In GCC you can use __attribute__((packed)) like this:
// sizeof(x) == 8
struct x
{
char x;
int a;
};
// sizeof(y) == 5
struct y
{
char x;
int a;
} __attribute__((packed));
See doc.
Also if you rely on the addresses of struct fields, take a look at the offsetof macro. Maybe you don't need to pack the structure at all.
As touched on by #Banex
#pragma pack(push,1)
struct
{
char a;
int b;
long long c;
} foo;
#pragma pack(pop)
The #pragma pack(push,1) pushes the current packing mode internally, and sets packing to 1, no padding
The #pragma pack(pop) restores the previous packing
Supposedly compatible with Microsoft's syntax
http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Structure_002dPacking-Pragmas.html
The fields within the struct are padded in an implementation defined manner.
That being said, fields are typically aligned on an offest which is a multiple of the size of the data member (or array element if the member is an array) in question. So a 16 bit field starts on a 2 byte offset, 32 bit field starts on a 4 byte offset, and so forth.
If you reorder the fields in your struct to adhere to this guideline, you can typically avoid having any internal padding within the struct (although you may end up with some trailing padding).
By putting the fields at the proper offset, there can be performance gains over forcefully packing the struct.
For more details, see this article on structure packing.
While using the above techniques are not guaranteed, they tend to work in most cases.
C question:
Does malloc'ing a struct always result in linear placement from top to bottom of the data inside? As a second minor question: is there a standard on the padding size, or does it vary between 32 and 64 bit machines?
Using this test code:
#include <stdio.h>
#include <stdlib.h>
struct test
{
char a;
/* char pad[3]; // I'm assuming this happens from the compiler */
int b;
};
int main() {
int size;
char* testarray;
struct test* testarraystruct;
size = sizeof(struct test);
testarray = malloc(size * 4);
testarraystruct = (struct test *)testarray;
testarraystruct[1].a = 123;
printf("test.a = %d\n", testarray[size]); // Will this always be test.a?
free(testarray);
return 0;
}
On my machine, size is always 8. Therefore I check testarray[8] to see if it's the second struct's 'char a' field. In this example, my machine returns 123, but this obviously isn't proof it always is.
Does the C compiler have any guarantees that struct's are created in linear order?
I am not claiming the way this is done is safe or the proper way, this is a curiosity question.
Does this change if this is becomes C++?
Better yet, would my memory look like this if it malloc'd to 0x00001000?
0x00001000 char a // First test struct
0x00001001 char pad[0]
0x00001002 char pad[1]
0x00001003 char pad[2]
0x00001004 int b // Next four belong to byte b
0x00001005
0x00001006
0x00001007
0x00001008 char a // Second test struct
0x00001009 char pad[0]
0x0000100a char pad[1]
0x0000100b char pad[2]
0x0000100c int b // Next four belong to byte b
0x0000100d
0x0000100e
0x0000100f
NOTE: This question assumes int's are 32 bits
As far as I know, malloc for struct is not linear placement of data but it's a linear allocation of memory for the members with in the structure that too when you create an object of it.
This is also necessary for padding.
Padding also depends on the type of machine (i.e 32 bit or 64 bit).
The CPU fetches the memory based on whether it is 32 bit or 64 bit.
For 32 bit machine your structure will be:
struct test
{
char a; /* 3 bytes padding done to a */
int b;
};
Here your CPU fetch cycle is 32 bit i.e 4 bytes
So in this case (for this example) the CPU takes two fetch cycles.
To make it more clear in one fetch cycle CPU allocates 4 bytes of memory. So 3 bytes of padding will be done to "char a".
For 64 bit machine your structure will be:
struct test
{
char a;
int b; /* 3 bytes padding done to b */
}
Here the CPU fetch cycle is 8 bytes.
So in this case (for this example) the CPU takes one fetch cycles. So 3 bytes of padding here must be done to "int b".
However you can avoid the padding you can use #pragma pack 1
But this will not be efficient w.r.t time because here CPU fetch cycles will be more (for this example CPU fetch cycles will be 5).
This is tradeoff between CPU fetch cycles and padding.
For many CPU types, it is most efficient to read an N-byte quantity (where N is a power of 2 — 1, 2, 4, 8, sometimes 16) when it is aligned on an N-byte address boundary. Some CPU types will generate a SIGBUS error if you try to read an incorrectly aligned quantity; others will make extra memory accesses as necessary to retrieve an incorrectly aligned quantity. AFAICR, the DEC Alpha (subsequently Compaq and HP) had a mechanism that effectively used a system call to fix up a misaligned memory access, which was fiendishly expensive. You could control whether that was allowed with a program (uac — unaligned access control) which would stop the kernel from aborting the process and would do the necessary double reads.
C compilers are aware of the benefits and costs of accessing misaligned data, and go to lengths to avoid doing so. In particular, they ensure that data within a structure, or an array of structures, is appropriately aligned for fast access unless you hold them to ransom with quasi-standard #pragma directives like #pragma pack(1).
For your sample data structure, for a machine where sizeof(int) == 4 (most 32-bit and 64-bit systems), then there will indeed be 3 bytes of padding after an initial 1 byte char field and before a 4-byte int. If you use short s; after the single character, there would be just 1 byte of padding. Indeed, the following 3 structures are all the same size on many machines:
struct test_1
{
char a;
/* char pad[3]; // I'm assuming this happens from the compiler */
int b;
};
struct test_2
{
char a;
short s;
int b;
};
struct test_3
{
char a;
char c;
short s;
int b;
};
The C standard mandates that the elements of a structure are laid out in the sequence in which they are defined. That is, in struct test_3, the element a comes first, then c, then s, then b. That is, a is at the lowest address (and the standard mandates that there is no padding before the first element), then c is at an address higher than a (but the standard does not mandate that it will be one byte higher), then s is at an address higher than c, and that b is at an address higher than s. Further, the elements cannot overlap. There may be padding after the last element of a structure. For example in struct test_4, on many computers, there will be 7 bytes of padding between a and d, and there will be 7 bytes of padding after b:
struct test_4
{
char a;
double d;
char b;
};
This ensures that every element of an array of struct test_4 will have the d member properly aligned on an 8-byte boundary for optimal access (but at the cost of space; the size of the structure is often 24 bytes).
As noted in the first comment to the question, the layout and alignment of the structure is independent of whether the space is allocated by malloc() or on the stack or in global variables. Note that malloc() does not know what the pointer it returns will be used for. Its job is simply to ensure that no matter what the pointer is used for, there will be no misaligned access. That often means the pointer returned by malloc() will fall on an 8-byte boundary; on some 64-bit systems, the address is always a multiple of 16 bytes. That means that consecutive malloc() calls each allocating 1 byte will seldom produce addresses 1 byte apart.
For your sample code, I believe that standard does require that testdata[size] does equal 123 after the assignment. At the very least, you would be hard-pressed to find a compiler where it is not the case.
For simple structures containing plain old data (POD — simple C data types), C++ provides the same layout as C. If the structure is a class with virtual functions, etc, then the layout rules depend on the compiler. Virtual bases and the dreaded 'diamond of death' multiple inheritance, etc, also make changes to the layout of structures.
This question already has answers here:
Structure padding and packing
(11 answers)
Closed 8 years ago.
I am a bit lost on calculating the size of structures
So we have the structure:
struct AcronymNode{
struct AcronymNode* next;
char acronym[5];
double num_phrases;
struct The_Phrase* phrase_list;
} Dictionary;
I see it as
next : 4bytes
acronym: 5bytes + 3
num_phrases: 8bytes
phraselist: 4bytes
=24 bytes
When I look at the notes it says: 32 bytes = 4 + 5 + 3 (alignment to
word) + 4 (to align for the double) + 8 + 4 + 4 (to align next structure to a multiple of 8 for
the double)
Why are we adding an extra 8 for alignment since it doesn't overflow, 4 before the double and 4 after the 2nd structure
In the more efficient structure it has double first, following the structures for 24 bytes
Also I wanted to check if this is right
structT{
int a;
char b[5];
float c;
char d[2];
};
Is the size 4 + 5+3 + 4 + 4 = 20?
If memory access latency is not something you are concerned with, you can instruct the compiler to layout a structure on a different alignment (than that which is most efficient for the machine). For example:
#pragma pack(1)
struct AcronymNode{
struct AcronymNode* next;
char acronym[5];
double num_phrases;
struct The_Phrase* phrase_list;
} Dictionary;
#pragma pack()
Although '#pragma pack' is not officially part of the C language, it is supported by most compilers. In the example above, '#pragma pack(1)' instructs the compiler to pack the structure on a one-byte boundaries, effectively changing the layout of the structure as you described it:
next : 4bytes
acronym: 5bytes + 3
num_phrases: 8bytes
phraselist: 4bytes
=24 bytes
Then, '#pragma pack()' returns alignment back to it's default.
.
'#pragma pack(1)' is often used to define structures where other alignments are not desirable; for example, when sending such structures "over the wire" to another system. Wire protocols are generally packed so that there is no filler between fields.
packing structs to a 1 byte boundary is used to optimize for space, otherwise the compiler will pad out for speed performance.
See: http://en.wikipedia.org/wiki/Data_structure_alignment#Data_structure_padding
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Why isn’t sizeof for a struct equal to the sum of sizeof of each member?
Consider the following C code:
#include <stdio.h>
struct employee
{
int id;
char name[30];
};
int main()
{
struct employee e1;
printf("%d %d %d", sizeof(e1.id), sizeof(e1.name), sizeof(e1));
return(0);
}
The output is:
4 30 36
Why is the size of the structure not equal to the sum of the sizes of its individual component variables?
The compiler may add padding for alignment requirements. Note that this applies not only to padding between the fields of a struct, but also may apply to the end of the struct (so that arrays of the structure type will have each element properly aligned).
For example:
struct foo_t {
int x;
char c;
};
Even though the c field doesn't need padding, the struct will generally have a sizeof(struct foo_t) == 8 (on a 32-bit system - rather a system with a 32-bit int type) because there will need to be 3 bytes of padding after the c field.
Note that the padding might not be required by the system (like x86 or Cortex M3) but compilers might still add it for performance reasons.
As mentioned, the C compiler will add padding for alignment requirements. These requirements often have to do with the memory subsystem. Some types of computers can only access memory lined up to some 'nice' value, like 4 bytes. This is often the same as the word length. Thus, the C compiler may align fields in your structure to this value to make them easier to access (e.g., 4 byte values should be 4 byte aligned) Further, it may pad the bottom of the structure to line up data which follows the structure. I believe there are other reasons as well. More info can be found at this wikipedia page.
Your default alignment is probably 4 bytes. Either the 30 byte element got 32, or the structure as a whole was rounded up to the next 4 byte interval.
Aligning to 6 bytes is not weird, because it is aligning to addresses multiple to 4.
So basically you have 34 bytes in your structure and the next structure should be placed on the address, that is multiple to 4. The closest value after 34 is 36. And this padding area counts into the size of the structure.
Is bitfield a C concept or C++?
Can it be used only within a structure? What are the other places we can use them?
AFAIK, bitfields are special structure variables that occupy the memory only for specified no. of bits. It is useful in saving memory and nothing else. Am I correct?
I coded a small program to understand the usage of bitfields - But, I think it is not working as expected. I expect the size of the below structure to be 1+4+2 = 7 bytes (considering the size of unsigned int is 4 bytes on my machine), But to my surprise it turns out to be 12 bytes (4+4+4). Can anyone let me know why?
#include <stdio.h>
struct s{
unsigned int a:1;
unsigned int b;
unsigned int c:2;
};
int main()
{
printf("sizeof struct s = %d bytes \n",sizeof(struct s));
return 0;
}
OUTPUT:
sizeof struct s = 12 bytes
Because a and c are not contiguous, they each reserve a full int's worth of memory space. If you move a and c together, the size of the struct becomes 8 bytes.
Moreover, you are telling the compiler that you want a to occupy only 1 bit, not 1 byte. So even though a and c next to each other should occupy only 3 bits total (still under a single byte), the combination of a and c still become word-aligned in memory on your 32-bit machine, hence occupying a full 4 bytes in addition to the int b.
Similarly, you would find that
struct s{
unsigned int b;
short s1;
short s2;
};
occupies 8 bytes, while
struct s{
short s1;
unsigned int b;
short s2;
};
occupies 12 bytes because in the latter case, the two shorts each sit in their own 32-bit alignment.
1) They originated in C, but are part of C++ too, unfortunately.
2) Yes, or within a class in C++.
3) As well as saving memory, they can be used for some forms of bit twiddling. However, both memory saving and twiddling are inherently implementation dependent - if you want to write portable software, avoid bit fields.
Its C.
Your comiler has rounded the memory allocation to 12 bytes for alignment purposes. Most computer memory syubsystems can't handle byte addressing.
Your program is working exactly as I'd expect. The compiler allocates adjacent bitfields into the same memory word, but yours are separated by a non-bitfield.
Move the bitfields next to each other and you'll probably get 8, which is the size of two ints on your machine. The bitfields would be packed into one int. This is compiler specific, however.
Bitfields are useful for saving space, but not much else.
Bitfields are widely used in firmware to map different fields in registers. This save a lot of manual bitwise operations which would have been necessary to read / write fields without it.
One disadvantage is you can't take address of bitfields.