This is a simple one. Alpha and 68k and most RISC processors don't
like to access unaligned memory. "What is unaligned memory?" you ask.
Bytes are always aligned because each memory address refers to one
byte and therefore there is a unique byte at every address that does
not overlap any other bytes. Aligned 16-bit words all have the
least-significant bit set to zero. The first 16-bit word is at
address 0, the second is at address 2. An unaligned 16-bit word would
have an odd address such as 1 or 5 or 7. The CPU manufacturers make
this requirement because the CPU can be more efficient when reading
aligned memory. BTW, aligned 32-bit values have the two LSBs set to
"Why are aligned accesses more efficient?" you ask. Let's assume that
the CPU can read 32 bits at a time. The address decode logic is very
simple when we want to access aligned data because all memory can be
uniquely referenced by ignoring the lowest two address bits. We can
use this assumption to streamline the cache and to reduce the number
of pins leaving the CPU chip. If we want to access an unaligned
32-bit value we need to read twice, discard the uninteresting portions
of the data, and combine what's left.
"Why is this all-of-a-sudden a problem?" you ask. The x86 performs
unaligned memory accesses by reading twice and fixing the result.
It's not efficient and is usually optimized out of good programs, but
since the x86 permits this behavior the programmers who were not
careful about aligning their data will find their programs faulting on
RISC machines. It is possible that the unaligned memory is the fault
of one of those foolish Microsoft/IBM engineers who designed another
persistent (serialized or in other words written-to-disk) data
structure that is unaligned. One annoying example is the BMP bitmap
format. Partition tables may be another.
-- Marc Singer
-- To unsubscribe: send e-mail to firstname.lastname@example.org with 'unsubscribe' as the subject. Do not send it to email@example.com
Copyright © 1995-1997 Red Hat Software. Legal notices