[oe] [PATCH/RFC] qt4-embedded: tune QT_ARCH for armv6

[Phil Blundell]

On Thu, 2010-11-04 at 19:26 +0100, Holger Freyther wrote:
> Phil do you happen to know why unaligned access got allowed starting from
> armv6? How fast will it be?

I don't know, but I would suspect that unaligned access was added to
ARMv6 in response to customer demand, and because a certain other
popular architecture supported it already.

Having the silicon be able to do unaligned accesses isn't a totally
worthless thing.  If you're faced with, say, a 32-bit int of unknown
alignment which you want to demarshal, there are two possible ways you
can do it in a pre-v6 world:

a) use four single-byte loads plus some ALU operations to combine the
results.  This is guaranteed safe for all alignments, but the LDRB+LDRB
+ORR+LDRB+ORR+LDRB+ORR sequence is inefficient compared to a single LDR:
it takes seven cycles to execute and requires a scratch register, even
if the operand is in fact naturally aligned at runtime.

b) use a single LDR instruction, let the MMU trap unaligned accesses,
and fix them up in software using sequence (a).  This has the advantage
that the aligned case runs at full speed, but the performance penalty
for loads which turn out to be unaligned is severe, probably at least
several tens of cycles and perhaps even more than that.  If many
unaligned operands are encountered then the performance might be worse
than just using (a) in the first place.

If the processor can do unaligned accesses natively then this problem
goes away: you can just use a single LDR instruction and it will always
execute at the maximum speed the hardware is capable of for that
particular operand.  For naturally aligned operands the load will
complete in a single cycle, just like it always did.  Since AHB doesn't
support unaligned access at the bus level, misaligned operands will need
two bus cycles but that's still much faster than either of the
software-based approaches.

p.