Wilco (Wilco.Dijkstra@ntlworld.com) on 1/12/11 wrote:
---------------------------
>Michael S (already5chosen@yahoo.com) on 1/12/11 wrote:
>---------------------------
>>Megol (golem960@gmail.com) on 1/12/11 wrote:
>>---------------------------
>>>Michael S (already5chosen@yahoo.com) on 1/12/11 wrote:
>>>---------------------------
>>>>Ben Harper (rogojin@gmail.com) on 1/12/11 wrote:
>>>>---------------------------
>>>>>This ARM fervor has me wondering whether I'm going to be spending some months porting
>>>>>a couple hundred K lines of code of Windows C++ code to ARM.
>>>>>
>>>>>Is there anybody out here with experience or man hours/SLOC numbers for such a port?
>
>If you use the MS compiler it's just a recompile with different flags. The only
>issues I can see: use of x86-specific intrinsics, relying on x86/x64 ABI specifics
>(like structure layout, alignment etc), existing x86 (inline) assembly code, different
>OS APIs (not all APIs may be supported on ARM). For well-written code it's trivial,
>however porting badly written code is always difficult.
>
>>>>I can think about only one pitfall - handling of unaligned data.
>>>>Other than that, don't see why 32-bit x86 C++ Win32 code should have any problems.
>>>>
>>>AFAIK later ARM cores support unaligned accesses, if the support is slow compared
>>>to x86 there could of course still be a problem...
>>>
>>
>>Yes, if you are interested only in ARMv7 (I'd guess that Microsoft is not going
>>to support older versions on Nt-based OSes, but would retain support for ARMv4 and
>>ARMv5 for CE-based OSes) then most things (i.e. 16b and 32b accesses) should work very similarly to x86.
>
>Indeed, even ARMv6 is ancient and has few GHz capable implementations - all the new 1+GHz ARM cores are v7 based.
>
>>Still I wonder what would happen if the code contains 64-bit access not aligned
>>on 4-byte boundary. Do ARM compilers use dual-word load/store instructions only
>>when they are 100% sure about 4-byte alignment?
>
>As in all modern compilers, unaligned accesses must be explicitly marked (eg. by
>packing a structure). All other accesses are naturally aligned according to the
>ABI (if they are not, you may get a trap).

[If the rumors are right and Microsoft indeed finishing porting of their Nt-based line to ARM], I see close to zero chance that they will set SCTLR.A=1.

>So an ARM compiler will use LDM or LDRD
>only if the access is guaranteed (by the ABI) to be least 4-byte aligned. For badly
>written software which doesn't understand alignment at all, I added a mode in the
>ARM compiler which assumes all accesses are unaligned.
>
>Wilco

Why do you call it badly written?
In my book the software does not have to be portable to be considered well-written. That is, as long as it runs fast and correct within well-defined platform constrains.
On x86 doing unaligned access is in most cases the best from performance perspective so, as long as portability is not part of the spec, the software that in performance-critical parts does something else could be considered badly written.