Is the memory alignment different for different data types

Question

Do different data types in C such as char, short, int, long, float, double have different memory alignment boundaries? In a 32 bit word aligned byte addressable operating system, how is accessing a char or short different from accessing an int or float? In both cases, does the CPU read a full 32-bit word? What happens when an int is not at the boundary? How is it able to read a char at any memory address?

Answer 1

The short answer, as others have pointed out, is the compiler will do what's best for the architecture it's compiling to. It may align them to the native word size. It may not. Here is a sample program demonstrating this point:

#include <iostream>

int main()
{
    using namespace std;

    char c;
    short s;
    int i;

    cout << "sizeof(char): " << sizeof(char) << endl;
    cout << "sizeof(short): " << sizeof(short) << endl;
    cout << "sizeof(int): " << sizeof(int) << endl;

    cout << "short is " << (int)&s - (int)&c << " bytes away from a char" << endl;
    cout << "int is " << (int)&i - (int)&s << " bytes away from a short" << endl;
}

The output:

sizeof(char): 1
sizeof(short): 2
sizeof(int): 4
short is 1 bytes away from a char
int is 4 bytes away from a short

As you can see, it added some padding between the int and the short. It didn't bother with the short. In other cases, the reverse may be true. Optimization rules are complex.

And, a warning: The compiler is smarter than you. Don't play with padding and alignment unless you have a really, really good reason. Just trust that what the compiler is doing is the right thing.

Answer 2

It depends on the compiler and the way you defined your variables. The default behavior of most compilers is to align variables in such a away, as to yield fastest access on the given platform. Aligned variables get the best performance for you.

However, compilers such as gcc, provide compiler specific directives which can be used to "pack" adjacent variables of different types (and hence sizes), to save on memory at the cost of performance (but that's what you get to decide, by using the packing directive.) See this question.

The CPU may read a full 32-bit word (and maybe more to get the whole cacheline) when reading a char/short.