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