I was experimenting Wednesday with two systems, one using a Marvell Kirkwood processor (SheevaPlug) and the other using a TI OMAP (BeagleBoard), testing the PHP 1/4 bug[0] and the effect of alignment fixups[1], using the same binary F12 ARM packages.
Oddly, the OMAP system always calculated the right value regardless of the fixups setting, while the Kirkwood needed fixups enabled to display the right value. Why do the two processors act differently? Does the OMAP processor have additional logic handle to handle non-aligned access? (Or did I somehow accidentally provoke something that changed the memory layout?)
-Chris
[0] http://lists.fedoraproject.org/pipermail/arm/2009-December/000420.html
[1] http://fedora-arm.blogspot.com/2009/11/fedora-arm-alignment-errors.html , http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment
On 2 July 2010 15:03, Chris Tyler chris@tylers.info wrote:
Oddly, the OMAP system always calculated the right value regardless of the fixups setting, while the Kirkwood needed fixups enabled to display the right value. Why do the two processors act differently? Does the OMAP processor have additional logic handle to handle non-aligned access? [snip]
Yes. The OMAP3530's Cortex-A8 supports unaligned memory accesses. There will be an overhead for accessing what is actually two memory locations and fixing the result, but it'll be nothing like the overhead of causing an abort and handling it in the kernel.
See, for example:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Beihgif...
Hope that helps, Matthew
On Fri, 2010-07-02 at 15:55 +0100, Matthew Wilson wrote:
On 2 July 2010 15:03, Chris Tyler chris@tylers.info wrote:
Oddly, the OMAP system always calculated the right value regardless of the fixups setting, while the Kirkwood needed fixups enabled to display the right value. Why do the two processors act differently? Does the OMAP processor have additional logic handle to handle non-aligned access? [snip]
Yes. The OMAP3530's Cortex-A8 supports unaligned memory accesses. There will be an overhead for accessing what is actually two memory locations and fixing the result, but it'll be nothing like the overhead of causing an abort and handling it in the kernel.
See, for example:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Beihgif...
Hope that helps, Matthew
Thanks, Matthew! That's a great link.
-Chris