migrating from ia32 to arm digest

 A porting checklistThe following list of points may prove useful when porting source code from IA-32 to ARM.

·         Recompile C/C++ code using tools which target the ARM architecture. In general, well-written, standards-conformant code should recompile without error when targeted for ARM.

·         Check for data items and data structure members which are not naturally aligned. Depending on the defaults for the software platform, these may require adjustment. This issue can only arise where externally defined data are mapped by a program as compilers will align data naturally by default.

·         Check carefully for code which depends on whether single-byte types are signed or unsigned. The default for ARM is unsigned. The default may be changed using the –signed_chars option to the compiler. However, doing this may introduce compatibility issues with standard libraries.

·         Any IA-32 code which makes use of extended-precision floating point variables will need to be examined closely. As a minimum, you will need to ensure that a suitable library is in place to handle this as there is no support for this in hardware on ARM platforms.

·         IA-32 devices using x87 floating point use an 80-bit intermediate format when carrying out floating point calculations. This results in rounding behavior which is not IEEE-compliant. ARM devices are IEEE-compliant, so numerical results may differ slightly when executing identical code on the respective platforms. Note that IA-32 devices perform much more like ARM if SSE instructions are used for floating point rather than the x87 coprocessor. Many compilers include options to force this behavior.

·         Any instances of self-modifying or dynamically-generated code will need to be examined very carefully. Apart from the need to rewrite the assembly code involved, such sequences are unlikely to function correctly on ARM systems (see 3.5 above for explanation).

·         Assembler procedures or inline assembly segments in C/C++ source code will need to be identified and rewritten, either in C/C++ or in ARM assembler. For ARM-standard components (e.g. VFP) C reference implementations are usually available which can simply be compiled. This may provide sufficient performance in the absence of an assembler version.

·         Drivers for integrated devices (e.g. interrupt controllers, timers, MMU/TLB, hardware debug etc) will need to be replaced with ARM equivalents. When using an OS (e.g. Linux) which supports both architectures, there may be little or no impact here as much of this code will be contained with the OS.

·         Drivers for hardware accelerators and other platform-dependent devices may need rewriting. In many cases, however, switching platform will remove these devices and possibly replace them with ARM equivalents. In these cases, the implications will largely be dealt with by changing drivers and compilation tools.

·         Locate all accesses to system registers, system calls, platform-dependent driver calls etc and ensure that they are replaced with ARM-specific or platform-specific equivalents.

·         Identify all uses of memory barriers and synchronization instructions in IA-32 source code and ensure that they are replaced with the ARM equivalents. Also examine carefully any code that may rely on the barrier side-effects of e.g. JUMP instructions. It may be necessary to insert additional explicit barrier instructions and cache maintenance operations when porting.

·         The power management strategy will need to be reformulated to match the features available on the target ARM device. This will be a combination of platform-dependent drivers and the interface with facilities provided by the OS.

 

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0274b/index.html