http://en.wikipedia.org/wiki/Data_structure_alignment#Typical_alignment_of_C_structs_on_x86

[EDIT]
I didn't see Oscar's post before I posted this, what he means is:

The memory management stuff in the computer accesses some certain size all the time,
assume 32 bit bus.

Access a char (byte)
Nxxx xxxx
xNxx xxxx //All fit within a 32 bit access
xxNx xxxx
xxxN xxxx
xxxx Nxxx...

Access a 16 bit int
NNxx xxxx
xNNx xxxx
xxxN Nxxx <-crosses 32 bit boundary
xxxx NNxx...

same for 32 bit var
NNNN xxxx
xNNN Nxxx <-crosses
  .
  .
  .
xxxN NNNx

xxxx NNNN <-aligned again

Care to post your source? Because that's not true. Memory must be accessed word by word (that's called a line), it's not possible to read just one byte (well, unless you're working with an 8 bit cpu where a word is 1 byte). It doesn't matter where in the word the byte you want is, since the cpu must retrieve the entire word no matter what.

I think you haven't even cared to read that wikipedia article because it explains how data is aligned pretty cleanly :/

Just something I've learned reading about how CPUs work.

Uh, a "line" is generally larger, and depends on the CPU architecture, at least if you're talking about the cache line. My Phenom II 810 has a L3 line size of 64 bytes (not bits, 64 bits is the word size).

Yeah, I didn't read it. I've skimmed it. But I can see how it can help to group and pack individual chars, so it fetches all 4 at the same time, saving some operations. Of course thats only if you group all your chars in the struct into 4-8 in a row groupings. Space them out a bunch, and its pretty inefficient (on x86/x86-64).

And as I mentioned, some cpu's CAN'T access unaligned data at all. All you get is an exception, so if you attempt to access one of those packed chars, you have to fetch an entire word manually, and throw away the bits you don't want, which is what x86 does for you anyhow.

I'd say all of those would be packed tightly as they are, since they're not a hodgepodge of sizes.

Thomas: when did I mentioned anything about cache? I think what you got wrong is the definition of data alignment. For starters, by definition, a byte is always aligned; there's no such thing as a misaligned byte. If you don't want to trust me or that wikipedia article, I'll just copy here a paragrahp of the IA32 Intel Architecture Software Developer Manual book:

(note: it's using the intel asm terminology for naming data types, so a word means 2 bytes, doubleword 4 bytes and quadword 8 bytes)

See how it doesn't mention bytes anywhere, and words (shorts in our discussion) should just be aligned to even boundaries (not necessarily to addresses divisible by 4 as you say)

PD: you should first document yourself properly. I hate when someone discusses about something he doesn't really know and doesn't even seem interested at all about learning the truth. I've studied this at university, and I've worked with a Sparc CPU (yes one of those that don't allow misaligned memory accesses).

http://en.wikipedia.org/wiki/Conventional_PCI#Conventional_hardware_specifications
(old skool PCI)
says PCI bus width is 32 bits.

http://en.wikipedia.org/wiki/PCI_Express
(since 2004)
has a sidebar saying "width in bits: 1 - 32"
but also says data transmission is serial

I've read elsewhere that past Pentium I (?) cache line size is always 64 bytes. It doesn't "match" the motherboard bus size, but so what? Neither does HDD sector or cluster size.

OTOH, my mobo is 64 bit, which implies at least 64 bit bus (I hope), but I was under the impression it's not PCI express (not mentioned in manual) and there's an AGP video slot.

You are right it is getting pretty stupid. I can't find any clear references, mind you I'm not trying very hard. But I still believe that even accessing a single byte that isn't at an aligned location will be slower, at least on some cpus. For a long time intel at least has been implementing some older operations solely in microcode stored in some hidden sram on the die. Though I'm not convinced opcodes that would take byte arguments would be a very wise candidate (not that thats stopped intel and other cpu companies from doing un-wise things) for microcode.

I am wondering weather or not you're taking this a little too personally though.

It is possible I'm mixing up the full size variable alignment restrictions. I do know that many ARM architectures can not access an unaligned 16 or 32 bit variable. They just throw exceptions. And I may have just extended that to any unaligned data. If they can access unaligned bytes, it wouldn't take much more to extend that to unaligned shorts imo.

This is the best I could find: http://webster.cs.ucr.edu/AoA/Windows/HTML/SystemOrganizationa2.html

Skip to the middle of the page, when it starts talking about 16 bit data buses, later it also explains 32 bit.