Memory Alignment

Memory alignment, in the x86 world at least, has to do with performance rather than operability.  That means that the x86 family CPUs can access a byte of data regardless of how it's aligned in memory but that doing so might be much slower than if the data were aligned on a 32-bit or with newer CPUs, 64-bit boundary.  Some CPUs, most notably the HP PA RISC, PowerPC, and Sun SPARC chips cannot access data on anything but a 32-bit boundary and attempts to do an unaligned access will cause a fault.

So what is alignment?  We often think of byte in programming and bytes are 8-bit pieces of data.  On an 8-bit CPU (like an 8080, Z80, 6800, 6502, etc.) alignment is not an issue since each memory address represents one and only one byte.

On a 16-bit CPU (8086, 68000, etc.) it's more complicated.  Each memory address now represents 16-bits or TWO bytes.  So when you access a memory element you may be interested in the full 16-bit value or you may be interested in either the upper or lower 8-bits of the 16-bit value.  Here's where it gets tricky.  Normally you'd store that 16-bit value at an EVEN address like 0, 2, 4, 6, ... since the ODD addresses, 1, 3, 5, 7, ... represent the UPPER 8-bits of the 16-bit value, at least on an x86 CPU.  That's OK and you can read BYTES at any address.  But what do you get if you try to READ a 16-bit WORD at address 1?  This is alignment at work.  In the x86 CPU, this causes TWO read cycles, one to get the upper byte of address 0 and another to get the lower byte of address 2 so that when they are assembled you can have the 16-bit value at address 1.  So while this is possible, on the x86 CPU at least, it's not desirable for the most part because it takes 2X as long to read.  

On a 32-bit CPU (80386 and beyond) you have even more possibilities since any address has possibly 4 8-bit values, two 16-bit values, or one 32-bit values.  And even more alignment confusion is possible.

In general, when programming, it's best to let the compiler adjust the alignment automatically for best performance on your target CPU.  It will often add padding bytes when needed so that it keeps data aligned on a 32-bit boundary.

Why would you NOT want this to happen?  There are some specific reasons.  The most common is when you have an existing data structure (perhaps from a database a network socket or something else you have to live with and can't change) and you must either read or write to that structure in a compatible way.  While there are other ways to do this that don't involve non-aligned access, you MAY want to use this option to make your job simpler.