Closed GoogleCodeExporter closed 9 years ago
It's a bit hard to remember the details of why ARMv6 was excluded here, but
I've been told there might be something with a privileged bit needing to be set
for unaligned accesses (or them being so slow that doing it in software was
faster).
Do you have an ARM11 where you've actually tested this?
Original comment by se...@google.com
on 29 Apr 2014 at 9:23
No, unfortunately I do not have board to test. I just have been dealing with
unaligned access problems in pure C port of snappy, so I was reading ARM
documentation and original snappy sources. Noticed this difference and become
curios whether it is mistake in snappy or there are some problems with
unaligned access on ARMv6, so we need to use memcpy same as on ARMv5.
Original comment by pakhuc...@gmail.com
on 29 Apr 2014 at 9:39
OK, well, if we don't have any hard data that says otherwise, I'll let things
stay the way they are. I'm pretty sure we looked harder at this back in the day
before we made these decisions.
Original comment by se...@google.com
on 29 Apr 2014 at 10:25
// ARMv7 and newer support native unaligned accesses, but only of 16-bit // and 32-bit values (not 64-bit); older versions either raise a fatal signal, // do an unaligned read and rotate the words around a bit, or do the reads very // slowly (trip through kernel mode). There's no simple #define that says just // “ARMv7 or higher”, so we have to filter away all ARMv5 and ARMv6 // sub-architectures. // // This is a mess, but there's not much we can do about it.
elif defined(arm) && \
Original issue reported on code.google.com by
pakhuc...@gmail.com
on 29 Apr 2014 at 7:57