On Thu, 7 Oct 2010 21:31:43 +0200 Wolfgang Denk <w...@denx.de> wrote:
> Dear Scott Wood, > > In message <20101007135257.05a93...@udp111988uds.am.freescale.net> you wrote: > > > > > 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. > > Huch? Which part of that is not well-defined (or even not > standard-conforming) C? Well, how do you obtain the unaligned pointer? Casting an integer to a pointer? 6.3.2.3: "An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be properly aligned, and might not point to an entity of the referenced type." Casting a pointer to a pointer of a different type? 6.3.2.3: "A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the pointed-to type, the behavior is undefined." I was expecting to find something stating that it was not well-defined behavior if you dereference a pointer that points to data of a different type, but couldn't (maybe I wasn't searching for the right terms) -- though a similar limitation is present in 6.5.2.3 for unions: "With one exception, if the value of a member of a union object is used when the most recent store to the object was to a different member, the behavior is implementation-defined." Extensions like __attribute__((packed)) are obviously not well-defined C. > > 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. > > I also complain about poor performance when instead of a single > instruction (a 32 bit load) at least 4 (8 bit) instructions need to be > executed. So only use the unaligned annotation when there's a significant chance of it really being unaligned -- and make sure the compiler knows whether the cost of an unaligned access is significantly worse than the cost of its workaround. > > BTW, I see GCC splitting accesses to bitfields in a packed > > struct into bytes on powerpc, even with -mno-strict-align. > > Indeed. Bitfields have always been evil. Evil or not, I don't see why GCC feels the need to do this. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
