Embedded
Design Center

Need more help?

Contact

Have an Intel
representative contact you.

Software Migration Design Guide

This guide provides steps for migration of PowerPC* (PPC) code to an Intel® architecture platform, and when to use Intel® software development products. It includes situational decisions, and it can be used as an outline for a migration solution and plan.

Consult the Intel® Embedded Design Center for further design information at each step.

There are five ordered steps for the migration. These steps cover operating system (OS) requirements, hardware differences and software optimization on the target Intel® architecture platform:

If the architecture migration includes a port to a different operating system, complete the port to the new operating system before you start the migration of the PPC software to the Intel architecture hardware.

The goal in this step is to ensure that the software performs as expected and correctly on the new OS. Since this step requires stability of the same code running on the target OS, do not make other software design changes in this step. Refer to the OS section in the White Paper: PowerPC* to Intel® Architecture Migration - Public for more details.

Update the operating system related code for Intel architecture

Whether the current and target OS are the same or different, device drivers, libraries and software development tools need to be surveyed to determine their availability for Intel architecture.

  • Intel® Embedded Graphics Drivers
  • Intel® embedded chipset drivers: standard desktop, mobile and server chipset drivers for Microsoft* (XP or Vista*)
  • Board support packages (BSPs) for RTOSs are provided by the RTOS vendor.
  • Board support packages (BSPs) for Microsoft* Windows CE, can be downloaded from these third-party vendors’ sites:
     
    – Adeneo Corporation*
    – BSQUARE*
    – Wipro Technologies*

If any device drivers or libraries are developed in-house, they will need to be rewritten for Intel architecture.

If any third-party drivers or libraries are required, check with the third-party vendor for equivalent Intel architecture products.

Development tools for Intel architecture: See the Intel® Software Development Products section for information about Intel tools and visit the products’ websites for information on OS support. On-chip debugging tools for Intel architecture are supported by American Arium* or Macraigor* Systems LLC (February 2009).

Choose the method for system initialization

BIOS – Choose BIOS and/or UEFI firmware if the design will support multiple standard interfaces and expansion slots, or a host mainstream OS with a broad set of pre-OS features, that is ready to run multiple applications.

Boot Loader – Choose a boot loader for minimal or specialized firmware stacks where requirements might include optimization for speed, size or specific system requirements, and will support minimal upgrade or expansion capabilities. QNX* Fastboot Technology is available for Intel® Atom™ processors.

Embedded Intel architecture designs include a firmware stack that initializes CPU cores, memory, IO, peripherals and graphics and provides runtime support for operating systems. See this white paper for an overview of these firmware technologies: Implementing Firmware on Embedded Intel® Architecture Designs.

If any part of the code is written in assembly language, update it for Intel architecture instructions

Basic assembly instructions – Manually update the basic assembly instructions using the Intel® 64 and IA-32 Architectures Software Developer's Manuals.

Vector oriented code solutions – Manually update vector oriented code using the AltiVec/SSE Migration Guide published by Apple*.

Translate the vector oriented code using the N.A.Software*/PowerPC*/AltiVec* to Intel®/SSE conversion tools:

Vector Signal Image Processing Library (VSIPL) – This is highly efficient computational middleware for signal and image processing applications. VSIPL is an open standard for embedded signal and image processing software and hardware vendors. It abstracts hardware implementation details; applications are portable across processor types and generations without rewriting the software. This tool will be available as the VSIPL library, or as C-VSIPL, the plain “C” equivalent for in-house libraries that need to be converted. N.A.Software will also port custom in-house DSP libraries to Intel architecture.

AltiVec.h include file for Intel® architecture – This is the same as PPC AltiVec.h, but targets the Intel® SSE instruction set instead of AltiVec. The application’s DSP code remains unchanged.

AltiVec assembler to Intel® assembler-compiler – This tool converts relatively small blocks of PPC AltiVec assembler into C code, which can then be compiled into SSE assembler code. This tool is currently under development.

Does the software abstract the memory architecture of the processor?

Yes – The code is endian-neutral. No changes are required.

No – The code will need to be updated for little-endian memory architecture. Manually update the endianness differences in the code. Use Intel’s Endianness White Paper as a guide to the required changes.

Table 1. Differences Between PPC and Intel® Hardware Architecture

Instruction Set
Instructions PPC and Intel® architecture instructions are very different. For some instructions there is no one-to-one (PPC to Intel® architecture) equivalent. Refer to the Intel® Software Developer Manuals and instruction set information and tools that may assist the assembly code migration.
Alignment PPC instructions are all 4 bytes in size and must be aligned on 4-byte boundaries. Intel® architecture instructions vary in size and therefore do not require alignment.
On PPC a bool is 4 bytes. On Intel® architecture, a bool is 1 byte. Make the code portable by changing the PPC boolean data to an unsigned 32-bit integer.
Vector oriented instructions PPC uses AltiVec* instructions. Intel® architecture uses streaming SIMD extensions (SSE). Refer to the Vector Oriented Code section for details about migrating AltiVec to SSE instructions.
Operations
Divide-by-zero For integer divide-by-zero, PPC simply returns zero. On Intel® architecture, executing this operation is fatal. Code should always check the denominator for zero before executing the divide operation. There is no difference in operation between PPC and Intel® architecture floating point divide-by-zero.
Hardware Devices
Drivers and libraries If a PPC driver or library comes from a third-party vendor, check with the vendor for equivalent Intel® architecture products. If any device drivers or libraries are developed in-house, they will need to be rewritten for Intel® architecture.
Refer to the Device Drivers section of PowerPC* to Intel® Architecture Migration for chipset and graphics driver information.
Registers
Calling conventions specified by the application binary interface (ABI) Arguments are passed in registers for PPC. For Intel® architecture, arguments are passed on the stack.
Intel® architecture has fewer registers than PPC and therefore local variables may be stored on the stack as well.
Memory
Byte order (endianness) Endianness describes how multi-byte data is represented by a computer system and is dictated by the CPU architecture of the system. Intel® architecture uses little endian and PPC uses big endian format to store multi-byte data. The difference in endian architecture is an issue when software or data is shared between computer systems. Refer to the Endianness section of PowerPC* to Intel® Architecture Migration for more information.
Bit fields The order of bit fields in memory can be reversed between architectures. Refer to the Bit Fields and Bit Masks section of the endianness white paper for more details.
For further reference, see: "Architectural Differences." Universal Binary Programming Guidelines. 26 Feb 2007. Apple.com. 18 Dec 2008.

Although the end product will run on multi-core architecture, performance tuning methodology first requires serial code to be optimized for serial performance.

Use the top down, closed end loop performance methodology.

When applicable use the appropriate Intel® Software Development Products.

Analyze code performance

Use the Intel® VTune™ Performance Analyzer to pinpoint hotspots in the code where the processing could be distributed between the available cores.

Use the Intel® Thread Profiler to identify any thread imbalances.

Generate alternatives and implement code changes

Use the Intel® C++ Compiler. Select features to implement advanced optimizations using profile-guided optimization (PGO), executable size and power consumption.

Use the Intel® Performance Libraries to increase performance with a variety of APIs that are highly tuned for Intel architecture.

Functions include video, imaging, compression, cryptography, audio, speech recognition and signal processing functions and codec component functions for digital media and data-processing applications.

Debug the code

Use the Intel® Thread Checker to identify threading bugs, such as data race and deadlock conditions.

The operating system vendor (OSV) should also provide a set of software development tools. Check with the OSV to understand which tools are available.

Use an on-chip debugging tool (JTAG) for low-level debugging at the hardware level and where a high-level debugger would otherwise interfere with timing critical code.

Intel® multi-core processors are based on Intel® Core™ microarchitecture.

There are several ways to benefit from multi-core. PPC migrations will most likely start from serial code bases. Therefore, the target software design needs to identify the solution to meet the migration requirements.

Symmetric multiprocessing (SMP) can improve application performance and can be designed to scale as the number of processors increases.

Note: SMP requires analysis to identify opportunities for parallelism in the code and rewriting the source code to introduce the parallelism using multithreading. For CPU intensive code, which is difficult to redesign for parallel processing using SMP and multithreading, asymmetric multiprocessing (AMP) could be a good alternative solution.

Refer to the White Paper: PowerPC* to Intel® Architecture Migration - Public for more details on AMP, SMP and virtualization.

Choose the right multi-core design for your application

AMP – Choose AMP if the migration requirements specify that no changes can be made to the application or operating system.

SMP – Choose SMP if one operating system will be run, using all of the cores as equal processing resources, and the applications can be parallelized to benefit from SMP systems. SMP affinity can sometimes improve cache hit rates on multiprocessor systems by pinning certain tasks to certain cores to improve data locality.

Virtualization – Choose virtualization for system consolidation, OS co-location, and the additional benefits of features such as security, quality of service (QoS), high availability (HA) and load distribution.

Whether the design is SMP or AMP, multi-core software designs require specialized software development tools.

For SMP the tools help identify and implement parallelism into the code and pinpoint threading issues such as race conditions, deadlocks and thread load imbalances. The tuning methodology is the same as for a uni-processor, except that the goal is to correctly and efficiently execute multiple processes or threads simultaneously across multiple cores. Multi-core tools help implement parallelism and help tune and debug the parallelized code.

Use the top down, closed end loop performance methodology.

When applicable use the following Intel Software Development Products:

Intel® VTune™ Performance Analyzer – This tool pinpoints hotspots in the code where the processing could be distributed between the available cores.

Intel® C++ Compiler – Multi-core features include OpenMP and auto-parallel.

Intel® Performance Libraries – Increase parallelism with performance-threaded APIs that are highly tuned for Intel architecture multi-core.

Intel® Threading Tools – Implement threads with Intel® Thread Building Blocks. Debug threads with Intel® Thread Checker. Identify workload imbalances and lock contention of the threads with Intel® Thread Profiler.

The OSV should also provide a set of multi-core development tools. Check with the OSV to understand which tools are available.

Use an on-chip debugging tool (JTAG) for low-level debugging at the hardware level and where a high-level debugger would otherwise interfere with timing critical code.

Learn more