By: Wilco (Wilco.Dijkstra.delete@this.ntlworld.com), November 4, 2006 11:20 am
Room: Moderated Discussions
Gabriele Svelto (gabriele.svelto@gmail.com) on 11/3/06 wrote:
---------------------------
>rwessel (robertwessel@yahoo.com) on 11/2/06 wrote:
>---------------------------
>Sigh. Being a software guy in embedded land just makes you forget about the simple
>hardware 'fixups' that desktop processors offer. That said I'm kind of lucky since
>I work on VM/compiler stuff so I am in charge of creating code and I won't allow
>unaligned stuff to get thru. BTW I'd really like to hear about codes (aside from
>implementing wire-protocols and memcpy()) which might benefit from unaligned access
>support. In my experience keeping everything aligned simply means not doing anything
>wrong, if I write straightforward code everything will be aligned anyway.
Unaligned accesses are used a lot in the embedded space. Most, if not all, embedded compilers have extensions that allow you to specify the alignment of all types, including over and underalignment. In the compiler I used to work on we implemented a __packed type qualifier which basically changes the natural aligment of a type to 1. Very simple and effective (much better than the #pragma pack hack).
Unaligned accesses are used a lot to access data that comes in via peripherals, to squeeze as much data into small memories, to enable old code (x86/68k) to run correctly, and to speed up byte oriented routines (eg. string functions). It is very useful when doing compression, and can dramatically speed up motion compensation. Hardware unaligned support is essential when doing SIMD. Not allowing unaligned access was the single biggest mistake of Altivec.
From my compiler experience I would say unaligned access is at least as important in the embedded space as on desktop. It was so popular in software that it was beneficial for ARM to add hardware support.
Wilco
---------------------------
>rwessel (robertwessel@yahoo.com) on 11/2/06 wrote:
>---------------------------
>Sigh. Being a software guy in embedded land just makes you forget about the simple
>hardware 'fixups' that desktop processors offer. That said I'm kind of lucky since
>I work on VM/compiler stuff so I am in charge of creating code and I won't allow
>unaligned stuff to get thru. BTW I'd really like to hear about codes (aside from
>implementing wire-protocols and memcpy()) which might benefit from unaligned access
>support. In my experience keeping everything aligned simply means not doing anything
>wrong, if I write straightforward code everything will be aligned anyway.
Unaligned accesses are used a lot in the embedded space. Most, if not all, embedded compilers have extensions that allow you to specify the alignment of all types, including over and underalignment. In the compiler I used to work on we implemented a __packed type qualifier which basically changes the natural aligment of a type to 1. Very simple and effective (much better than the #pragma pack hack).
Unaligned accesses are used a lot to access data that comes in via peripherals, to squeeze as much data into small memories, to enable old code (x86/68k) to run correctly, and to speed up byte oriented routines (eg. string functions). It is very useful when doing compression, and can dramatically speed up motion compensation. Hardware unaligned support is essential when doing SIMD. Not allowing unaligned access was the single biggest mistake of Altivec.
From my compiler experience I would say unaligned access is at least as important in the embedded space as on desktop. It was so popular in software that it was beneficial for ARM to add hardware support.
Wilco