On Thu, 7 Oct 2010 19:57:01 +0200 Wolfgang Denk <w...@denx.de> wrote:
> Dear Scott Wood, > > In message <20101007114634.70e0f...@udp111988uds.am.freescale.net> you wrote: > > > > I think this gets down to how such pointers are generated -- if you > > stick with well-defined C, the compiler/ABI should be able to avoid > > generating an unaligned pointer. > > It is a pretty common method to use a pointer to some struct (for > example, some form of PDU) and make it point to some I/O buffer. Yes, but at that point we are not talking about well-defined C, but rather implementation-specific behavior. There's nothing wrong with it, but the C standard is no longer authoritative on what happens in such cases. > Depending on I/O subsystem, pre-pended protocol headerss and such the > resulting pointer may or may not be aligned. This is something that > the compiler has zero influence on. [Yes, of course the application > could always copy the data to a properly aligned memory region. But I > bet you would quickly complain about the poor throughput if the > network stack on your systems were implemented that way.] Yes. And there would also be performance complaints if each of those accesses were to trap and be emulated (even ignoring weird stuff like old ARM). Thus it's nice to have some sort of pointer or data type annotation to tell the compiler to be careful. > > when unaligned, e.g. old ARM chips that do weird rotaty things rather > > than trap when you do an unaligned access. > > I think it was acceptable for such systems to enforce the compiler (by > setting special compiler switches) to implement such extra access modes. > But doing it by default and unconditionally for all systems of that > architecture seems broken to me. It's unfair collective punishment. Yes, it ought to be configurable -- but this is only happening when you use __attribute__((packed)) without explicit alignment, right? BTW, I see GCC splitting accesses to bitfields in a packed struct into bytes on powerpc, even with -mno-strict-align. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot