Dear Måns Rullgård,
In message <yw1xob2dakq4....@unicorn.mansr.com> you wrote:
>
> > We are not discussing application code here.
>
> What does that have to do with anything. The compiler works exactly the
> same whatever the code is for.
With application code you don't really care whether a variable is
read/written in one piece or broken down into several smaller
reads/writes - except when you notice that performance suffers.
When accessing hardware, it often makes a fundamental difference
whether you access a device register with it's correct size or not.
Usually breaking down an access into smaller ones results in crashes
or incorrect data or other errors.
> > We are dealing with low- level hardware related stuff. When I try to
> > read from a 32 bit device register I must be absolutley sure that this
> > will be a single 32 bit transfer. It is totally unacceptable if I
> > have to fear that the compiler might break this up into 4 byte
> > accesses behind my back.
>
> So because you're afraid of __packed abuse, you want to make _other_
> completely valid code crash? Would it not be preferable to make the
> actually broken code fail? Then someone might notice and fix it.
> Furthermore, the scenario you seem worried about will still happen on
> ARMv5 and other architectures which do not support unaligned memory
> accesses.
I wonder if you actually read Albert's arguments. I'll try to put it
in simple words for you.
No, this is not about __packed, at least not primarily. We are
talking about code that performs unaligned accesses. There are
architectures where the hardware supports this just fine; there are
others where you pay for this with some penalty, but it still works;
and there are yet others where it just does not work. And we cannot
rely on the compiler to do "the right thing" because the compiler
assumes the "application" model described above, while we need the
"device access" model, i. e. something different. And we want all
code (unless it is not inherently deeply architecture-specific) to be
working on all architectures, whether these support unaligned
accesses or not.
So I would like to adjust the default behaviour of the compiler to
raise errors or at least warnings for all such unaligned accesses
that he is capable of detecting, and I want clear runtime errors for
the rest, on all architectures. Code that causes such errors needs to
be reviewed and, normally, to be fixed. In cases where there are
good reasons to perform unaligned accesses, these should normally
be done explicitly, without automatic help from the compiler. Only if
there is such good reasons for unaligned accesses AND there are good
reasons not to touch the code AND we are sure it will not break on
some architectures, then we should allow the compiler to use it's
automatics.
BTW: thanks for the friendly words you found for me elsewhere.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
What about WRITING it first and rationalizing it afterwords? :-)
- Larry Wall in <8...@jpl-devvax.jpl.nasa.gov>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
