On Thursday 19 July 2012 02:28:05 Albert ARIBAUD wrote: > On Thu, 19 Jul 2012 00:29:23 -0400, Mike Frysinger wrote: > > On Monday 02 July 2012 12:14:40 Måns Rullgård wrote: > > > It's slightly more complicated than that. Data can be misaligned for a > > > variety of reasons: > > > > > > 1. Errors in software. > > > 2. Specified by a file format or communication protocol. > > > 3. Deliberately misaligned by the compiler. > > > > > > Misaligned data of type 1 should of course be fixed properly, not > > > worked around in any way. > > > > it's also a reliability aspect. people don't write bug free software, > > not bug free protocols, nor bug free compilers. when misalignment does > > happen in the field, it's a hell of a lot better if the software > > continued to execute correctly rather than randomly triggered an > > exception. > > Nitpick: this is robustness, not reliability.
useless pedantry: by increasing robustness, the system is more reliable > That being said, yes, this robustness is desirable when you do not control > all of the SW running on the product; Linux, for instance, will have to > execute processes which were built with any old (or new) compiler > settings, thus the Linux folks have to make sure the kernel won't fail > running those. > > But the only uncontrolled SW U-Boot runs is its payload -- typically the > kernel image -- which are usually very cautious in what they assume they > can do, thus are unlikely to perform unaligned accesses. it isn't just that. there is no way you can guarantee both the linux kernel and u-boot code bases themselves are perfect. in fact, it's even worse when these are the ones that get tripped up because it means your system resets/hardlocks/kills a kitten. when doing driver development under the linux kernel, we would come across parts of core stacks that lacked alignment checking and would panic the system. sometimes it would always panic, other times it depended on factors that made life worse: the compiler version (newer ones always like to pack/optimize better), the actual data stream, or the execution paths. > > simply search the kernel for get_unaligned then. there are plenty of > > examples in there. granted, many apply to stacks that don't show up in > > u-boot (yet?) such as bluetooth, wireless, and irda, but i'm pretty sure > > TCP/IPv4 has a few edge cases too. > > I'll have a look, if only to lament that protocol are not what they used to > be in the old days. :) > > Anyway: as I said: performing *controlled* unaligned accesses for external > reasons other than bugs is fine with me. Having our own get_unaligned() in > such places would be fine with me. i have no problem adding put/get_unaligned() to all the right places. that makes perfect sense. but, as an orthogonal issue wrt ARMv7, i don't see any problem enabling hardware functionality: it increases robustness (:P), shrinks the code base (all the get/put unaligned macros expand into a single memory access as they no longer have to do alignment fixups in software), and speeds up the runtime (a single unaligned memory access is always faster than address masking/multiple loads/bit shifting/etc... -- obviously this ignores multimedia type code that does alignment adjustment at the start, then lets of memory accesses, then another adjustment at the end, but that's not what we're talking about here). if you want to tell people that if they found an unaligned access in code they must fix that, then great. make them fix it. then once that bug has been fixed, let's merge the purely optimization patch that allows the hardware to do unaligned accesses. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot