Re: Use of unaligned load/stores by compilers

Reid Tatge <reid@micro.ti.com> writes:
> Even in this X86-dominated world, it always surprises me how many
> programmers are completely unaware that there is such a thing as
> hardware enforced alignment of memory references. <Sigh>
>
> [I think this is the 1990s equivalent of the old observation that a
> determined programmer can write a Fortran program in any language. -John]


Perhaps you can take some comfort in the fact that said programmers
are paying a huge runtime price for their cluelessness, even on their
favorite X86 architecture. Misaligned reads and writes require
multiple memory cycles on the X86 series, too (at least on anything
with more than an 8-bit path to memory). In fact, my reference book
says that on 486 and up, a misaligned 32-bit read or write takes
*four* cycles, versus one cycle for aligned 32-bit data. It's only
because of Intel's unshakable dedication to backwards compatibility at
ANY cost that the feature is still there...


regards, tom lane
[The fact that it's so slow suggests that in fact they don't care all
that much. I was surprised to read that in the later IBM 390
machines, there's very little penalty for misaligned data. The cache
lines are quite long, so more often than not misaligned data is still
in a single line in which case there's no penalty, or it's in two
lines in which case there's in effect an extra load or store. The x86
takes a three cycle hit if misaligned data is in a single line and a
six to 12 cycle hit if it crosses into a second line. Intel's x86
optimization manual says it's an important performance issue, and the
Ppro and PII can count misaligned accesses as part of the internal
profiling features. -John




--

Return to the comp.compilers page.
Search the comp.compilers archives again.