Getting rid of Unaligned Accesses (UA)

[Jay Estabrook]

U. George wrote:
> I suppose I should ask, why do u care?

The example I initially gave was perhaps not the best to show the
reason why eliminating UAs is a goodness.

Recently, I happened to try printing a webpage from
firefox; the ghostscript interpreter was used to render it for the
print job. It seemed to take a really long time for something that
was almost entirely text.

When I could, I looked at /proc/cpuinfo before and after the render;
it indicated that over 200 MILLION UAs had occurred during that single
operation. When I fixed it, the render time dropped from more than
30 seconds to only a second or two.

Was that not enough to care? :-)

> early cpu's could only store/fetch certain types ( int's/long's ) on
> aligned boundaries. fetching a byte, storing a byte, required an
> int/long fetch, and shifting.

In fact, the later CPUs have the same restriction, they just support
more data types, like shorts and bytes, and their lesser requirements.

> Overcoming such a problem, would mean expanding the byte storage into 4
> byte, aligned on int boundaries. For structs, there is/was a pragma to
> force byte alignment, short alignment on int boundaries. You pay for
> this by wasted memory space.

And in fact, that's the default for structs - fields aligned on natural
boundary offsets from the start of the struct. Only by adding the pragma
to pack it will that not be done.

And in most cases, the defaults work well for generating generic Alpha
code. It's when the code does tricks, or the programmer doesn't realize
the consequences of a choice, that a price must be paid on Alpha.

> I think the 21264 cpu's can fetch/store bytes anywhere without faulting
> to external fixup routines.

Indeed, IFF the compiler is told to generate those instructions when
needed, via "-mcpu=ev6" or such switch to GCC. But if it's NOT told,
so that the resulting code generated can/will run on ALL Alpha CPUs, it
does not have that flexibility.

--Jay++