Mark Pilant wrote:
In most cases you can put any allocation unit (byte, short, int, etc.)
anywhere you want. It is just that you may have a performance issue if
it is not aligned. SPARC, and PDP-11s are the only machines I can
remember, at the moment, that can generate an exception if the memory
alignment does not agree with the allocation associated with the
instruction.
System/360 did, although I think there might have been (in at least some
models) an option to allow unaligned accesses. S/370 and later did
unaligned accesses transparently, although there might have been a
performance penalty for that.
As I remember, there's a configuration register bit in the 486 and later
x86 processors to force a trap on unaligned accesses, although I don't
know whether any OSes turn it on, as it'd break binary compatibility
with code that assumes (explicitly or implicitly) that unaligned
accesses are allowed.
Some other RISC processors might also have generated traps, although I
think at least some of them had instructions that were intended to be
used for, among other things, synthesized unaligned accesses (i.e., the
compiler can generated code that handles unaligned accesses if it thinks
it needs to).
Actually this whole discussion is a good example of why byte and short
values are falling out of favor. Since the compiler will most likely
pad the storage, why not use 32 bits.
Because caches and main memory aren't as big as we'd like? If you have
a lot of instances of a data structure, using fields big enough to hold
the values it needs to, but no bigger (except perhaps for rounding up to
a multiple of 8 bits) can reduce the cache and main memory footprint of
the code.
