Subject: Re: -mstrict-align on powerpc
To: None <tech-toolchain@netbsd.org>
From: M L Riechers Mlr <mlr@sun.rse.com>
List: tech-toolchain
Date: 03/16/2003 21:41:51
>> Why? The performance of unaligned fetches always sucks, even when they
>> don't trap. I think we should be going the other way: actively
>> preventing, if not forbidding, unaligned data structures even on CPUs
>> that don't require alignment, to improve performance.
>
> Is unaligned access really that bad on PowerPC CPUs that can do it?
>
> -- Jason R. Thorpe <thorpej@wasabisystems.com>
(Good Harummmph follows:)
Yes, it is. A cycle is a cycle is a cycle. ;<
Depending on the machine vs memory speed, it may take 1 to 20 (and up,
as cpu cycle speeds increase) machine cycles to get that un-aligned
access. That may incur a 0 to 20 instruction penalty
(i.e. instructions not done because of the access). (Argument by
intimidation.)
(\Harummmph)
More to the point, though, I remember the argument a couple of years
ago concerning double word struct members aligned on odd word
boundaries, and the problems that gave a, say, 604 processor doing odd
word 64-bit floating loads and stores. I believe the point was made
that various compilers (gcc?) were aligning the struct member
improperly, (or at least non-optimally,) but there was nothing we
could do about that without breaking binary compatibility with
existing programs. (Wasn't "-mstrict-align" bandied about to solve
the problem?) So, someone made a kernel trap to handle those
optimizations.
But I can't think of any implicit integer alignment assumptions. I'd
just like to point it out as a possible issue -- binary compatibility?
Best Regards,
-Mike