[U-Boot] [PATCH] usb: do explicit unaligned accesses

[Marek Vasut]

Dear Albert ARIBAUD,

> Hi Marek,
> 
> On Sat, 1 Sep 2012 00:16:43 +0200, Marek Vasut <marex at denx.de> wrote:
> > Dear Albert ARIBAUD,
> > 
> > > I think you are talking about lumping small-sized accesses together
> > > into a bigger access possibly aligned.
> > 
> > This is exactly what I mean.
> > 
> > > If I am correct, then I don't
> > > think this is related to misaligned accesses.
> > 
> > Why won't it be? Such access can in the end turn out to be aligned,
> > therefore leveraging all the penalty.
> 
> I have not expressed myself clearly. Yes, access lumping is related to
> access alignment. What I meant is: disallowing misaligned native
> accesses will not prevent access lumping. Misalignment restrictions do
> indeed restrict how such lumpings will happen, but it does not prevent
> lumping per se.
> 
> One place where lumping and misalignement prevention did clash was
> raised in the previous discussion: a 7+1 bytes function-local char array
> was allocated on a non-aligned address (which is possible and normal
> because it is a char) and was initialized with some content. The
> compiler lumped the initialization as two misaligned 32-byte native
> accesses, despite misaligned native accesses being forbidden by
> compiler command line options. This was a compiler bug.

But that'd mean that instead of fixing a compiler, we'd be doing a workaround in 
our code?

> > > If I am not correct, can
> > > you please detail what you meant?
> > > 
> > > > Besides, right now, the code is much more readable. So I really
> > > > don't like adding some strange macros to force crazy aligned
> > > > access if the compiler can do it for us and can do it better.
> > > 
> > > I personally would let the compiler do it too, but I prefer it to be
> > > clearly indicated to the reader of the code when an access is
> > > known to be misaligned.
> > 
> > I'd enable enable the Alignment trapping in the CPU and die on an
> > unaligned access at runtime -- to indicate the user that he should
> > fix his bloody compiler.
> 
> ... or fix his bloody structure, or fix his bloody f...ixing pointer
> arithmetic, or... but I do agree with the trapping, and that's my plan.
> 
> However other architectures may need, or choose, another stance on
> alignments, and it is best if they don't have to discover intended
> misaligned accesses the hard way.

Yet still, in such case, valid compiler has to generate valid workaround code.

> Thus my opinion that any misaligned
> access which cannot be fixed should not be sliently left for the
> compiler to handle, but should (also) be clearly marked as such, if only
> for humans to notice.

I can't say I agree here ... since it's a really ad-hoc solution. I can't say I 
see any real benefit other than that it's hiding possible compiler bugs :-(

> > Best regards,
> > Marek Vasut
> 
> Amicalement,

Best regards,
Marek Vasut