PDF version - ARM Information Center

A porting checklist5 A porting checklistThe following list of points may prove useful when porting source code from PPC to ARM.Recompile C/C++ code using tools which target the ARM architecture. In general,code which has been optimized for the PPC architecture should recompile wellwhen targeted for ARM.Identify any instances in the source code where it is important that 8-bit variablesare unsigned. Either redeclare individual instances to be explicitly unsigned or usethe “—unsigned_chars” compilation switch to reconfigure the entire ARMtoolchain.Locate all accesses to system registers, system calls, platform-dependent drivercalls etc and ensure that they are replaced with ARM-dependent or platformdependentequivalents.Assembler procedures or inline assembly segments in C/C++ source code willneed to be identified and rewritten, either in C/C++ or in ARM assembler. ForARM-standard components (e.g. VFP) C reference implementations are usuallyavailable which can simply be compiled. This may provide sufficient performancein the absence of an assembler version.Identify any code which is, or may be, endian-dependent. Static analyzers (suchas “Sparse”) can help with this. ARM devices do not support the per-pageendianness configuration available on PPC. Any code which relies on this willneed to be rewritten very carefully, making use of the ARM byte reversalinstructions and data endianness configuration bit in the CPSR.Drivers for integrated devices (e.g. interrupt controllers, timers, MMU/TLB,hardware debug etc) will need to be replaced with ARM equivalents. When usingan OS (e.g. Linux) which supports both architectures, there may be little or noimpact here as much of this code will be contained with the OS.Any code which makes use of the extended 36-bit addressing supported by somePPC devices will need careful investigation.Drivers for hardware accelerators and other platform-dependent devices mayneed rewriting. In many cases, however, switching platform will remove thesedevices and possibly replace them with ARM equivalents (e.g. switching Altivecfor NEON). In these cases, the implications will largely be dealt with by changingdrivers and compilation tools.PPC code which makes use of the hypervisor and virtualization extensionsavailable in more recent implementations will need to be recoded. If possible, youshould target an ARM platform (e.g. Cortex-A15) which provides similar hardwarefeatures to support this.Identify all uses of memory barriers and synchronization instructions in PPCsource code and ensure that they are replaced with the ARM equivalents. Alsoexamine carefully any code may rely on the barrier side-effects of e.g. TLBmanagement operations. It may be necessary to insert additional explicit barrierinstructions when porting.The power management strategy will need to be reformulated to match thefeatures available on the target ARM device. This will be a combination ofplatform-dependent drivers and the interface with facilities provided by the OS.Any PPC code which makes use of 128-bit floating point variables will need to beexamined closely. As a minimum, you will need to ensure that a suitable library isApplication Note 245 Copyright © 2012 ARM Limited. All rights reserved. 33ARM DAI 0245B