Memory Alignment is one of the most important concepts when working low-level with memory. The bliss of the x86 processor, which is very kind about alignment, has left me unaware of it for years. That was until Kaja mentioned it, and therefore I decided to rebuild my Gc.
Like err.. what you talking ’bout?
Data should be aligned in the memory. Why? Because the processor doesn’t see the memory as most programmers do. For the processor the memory isn’t an array of bytes, but rather an array of blocks. In the case of the x86 processor this is usually 4 bytes.
When I got a simple piece of code like ‘
(*i)++‘ the processor will find the 4 byte block in which this 4 byte integer
i is located, increments it and stores it.
Well.. it does this when
i fits exactly in one block. When
i is partially in one block, and the rest is in a second block (it is unaligned) the processor will have to fetch both blocks, reconstruct the integer, increment it, split it, and store it back.
This is a lot of extra work. The processor will spend a few times more work on a simple increment. Although the actual difference is only about 5% because requesting 2 blocks or 1 block doesn’t differ that much.
Because this means a lot of extra work for the processor, and even more transistors, some processor manufacturers decided to barely or not support unaligned data.
- Some processors will just cope with unalligned data, although it takes a bit more time. (x68)
- Other’s will throw an hardware exception and let the OS fix it up, which takes a hell of a lot more time.
- A bunch will get unstable and the process crashes, or the whole processor will.
- Ans some will silently ignore the unaligned data using the first aligned data that comes close instead which leads to silent corruptions and hard to trace bugs.
Bliss of C
Maybe this will shock you, at least it shocked me. Luckily you don’t need to worry a lot when you aren’t writing specific low-level applications like memory managers or compilers. Your C compiler will take care of alignment for you.