Re: Architectures where unaligned access is (not) OK?
+++ Leif Lindholm [2014-11-21 14:00 +0000]:
> On Fri, Nov 21, 2014 at 12:42:34PM +0000, Simon McVittie wrote:
> > A couple of questions for people who know low-level things:
> >
> > * Of Debian's architectures (official and otherwise), which ones are
> > known/defined/designed to be OK with unaligned accesses from
> > user-space, and which ones (can be configured to) crash or give wrong
> > answers?
> >
> > * Would it be safer to assume that future architectures are in the
> > "unaligned accesses are OK" category, or the "not OK"
> > category?
It would be safer to assume that unaligned accesses are a bad plan and
will always come with a performace hit if they work at all.
> So, the short answer for the ARM case is that ARMv6 and up guarantee
> that the processor can be configured such that_some_ unaligned
> accesses are fine (or at least just inefficient).
<snip nice complete summary>
High-level summary for software engineers: Don't do unaligned access
on armhf or armel. It's always inefficient, sometimes extremely
inefficent, and in various cases is not permitted at all.
> ARM64 similarly makes it possible to trap unaligned accesses, but if
> that is not enabled (which it isn't by Linux), everything apart from
> load-exclusive/store-exclusive, load-acquire/store-release and Device
> memory accesses will be handled by hardware.
Whilst that is nice and correct I'm not sure the meaning is clear to a
software engineer, which is: Don't do unaligned access on arm64. It's
always inefficient, sometimes extremely inefficient, and sometimes
won't work at all.
arm64 simply doesn't permit unaligned access in the core. Some types
of access are wrapped (in hardware) so that 2 access will get done and
you are returned the relevant pieces of the result, but this doesn't
apply to all access types and is obviously slower/energy
inefficent. If the kernel ends up fixing up unaligned accesses that's
impresively inefficient, as on other arches.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Reply to: