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.

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.

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

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.