Building applications on a secondary platform is perhaps the simplest definition of a porting platform. This article explores the porting aspects in the context of AIX®.

Brad Cobb, Senior Technical Consultant, IBM

For more than ten years, Brad has helped ISVs port, tune, debug, and enhance their applications on AIX. Aside from helping ISVs, Brad enjoys filing for patents, publishing articles, and speaking at developer conferences. You can reach him at bcobb@us.ibm.com.



24 November 2009

Also available in Chinese

Introduction

Software development platforms have evolved from mainframes, to mini-frames, to UNIX® systems, to Microsoft Windows®, and most recently, to Intel x86 Linux® systems. During the mid 1980's through the 1990's, UNIX systems such as those from Hewlett Packard, IB®M, Silicon Graphics, and Sun Microsystems attempted to become the dominant development platform but the advent of the personal computer and its cost effectiveness of economically placing a system on every developer's desktop soon took over the development environment. Today, those same personal computers provide the primary development environment based on Microsoft Windows and Linux, leaving the UNIX systems as secondary platforms, or more commonly know as porting platforms. This article covers the high-level aspects of porting as it pertains to AIX.


Aspects of porting

Porting applications to another platform is largely the same as developing a new software product with the exception that most of the design and development are completed on a different hardware platform. From a porting perspective, the porting process consists of the following steps:


Build

Building consists of compiling source application code into binary objects that are then linked together to form an executable binary called an application that can then be run on a hardware operating system such as AIX. To build applications today, developers need open source repositories that contain AIX binaries, compilers to create binary objects, make to automate the build process, and linker/loaders to create executable's and shared libraries/objects.

Open source repositories

Rapid application development is a necessity in today's fast-paced world, and open source projects are just one way in which independent software vendors develop applications rapidly. A primary issue with open source projects and their respective tools, libraries, and more is the availability of these tools on AIX. Luckily, there are repositories throughout the world. Here are just a few:

  • The AIX Toolbox provides a mix of commonly sought open source tools and resources.
  • BULL offers are large repositories of open source tools that support the gamut of AIX releases (4.3.3, 5L, and 6.1).
  • Hudson Valley Community College provides pWare, which is an AIX open source software for IBM AIX 5.3 and 6.1 download site.

Compilers

IBM offers compilers for C, C++, and FORTRAN for AIX as well as Java™. Additionally, as part of the AIX Toolbox, IBM offers GNU compilers. See the Resources section for product information and further documentation.

Make

AIX provides a version of make with its bos.adt.base fileset, as well as gmake as part of the AIX Toolbox.

Linking

Linking objects to create executables and shared libraries and objects is perhaps the most difficult aspect of porting applications to AIX. See the Resources section for a few excellent resources to ease porting on AIX.


Debug

Debug, as the name suggests, is debugging the application to locate and correct "bugs" found in the application when run on the porting platform. The following are the most commonly used debuggers on AIX:

  • dbx is the standard debugger for AIX. It is a command-line debugger.
  • kdb is similar to dbx, but is a kernel debugger.
  • IBM debugger is a GUI-based debugger that can be run locally on AIX and remotely on Microsoft Windows.
  • gdb is the GNU debugger. It is similar to dbx in that it is a command-line debugger.
  • GNU Data Display Debugger offers a GUI interface for both dbx and gdb.

Tune

An often overlooked step, tune is taking an application and analyzing its performance to determine areas that could be improved though techniques such as loop unrolling, applying higher levels of optimization, and more.

  • Optimization

    When talking about optimization, there are two basic types of optimization, hand optimization and automated optimization.

    Hand optimization is taking an executable, analyzing its performance, and identifying areas of code that need to be adjusted to perform better on the given platform. One specific tool to assist hand optimization is profiling, which is discussed in the following section. Hand optimization is both a science and an art. To perform hand optimization, you must understand the underlying processor architecture to fully understand how the code should be restructured to perform well on a given hardware platform. One technique that is often now performed by the compiler is loop unrolling. This technique focuses on how best to optimize the usage of cache in order to reduce the number of times the system must retrieve data and place it in cache to perform a given set of operations. Using this technique, a simple 10-line matrix multiply routine could expand to hundreds of lines of code that performs on the order of magnitudes better.

    Automated optimization is the most widely used technique, as this type of optimization is often performed by the compiler. The most common techniques are:

    • Higher levels of optimization. This uses the compiler flags -O, -O2, -O3, where each level of optimization applies higher levels of optimization techniques to squeeze more and more performance. With each higher level of optimization, compile time and systems resources used to compiler the source code increase as the additional amount of performance squeezed out decreases. This is why most code is compiled with –O or –O2 and specialized code being compiled at higher optimization levels.
    • Hardware-specific optimization is applying hardware-specific optimization. On AIX, this typically means the –qarch=architecture and –qtune=architecture where architecture is the micro-processor architecture. The –qarch flag introduces micro-processor-specific hardware instructions that are specific to that micro-processor. Specifying the –qarch flag for a binary produces a binary that can only be run on that given micro-processor architecture. The –qtune on the other hand does not introduce micro-processor architecture instructions but will instead order the code in such a way that it will optimally perform on a given micro-processor architecture.
    • Feedback-directed program restructuring is a technique used to reorder an executable based on a given workload. When using this technique, data is collected for a given workload, such as a profile that is then used to rebuild the application binary in such a way to optimize the workload. More information can be found at: http://www.haifa.ibm.com/projects/systems/cot/fdpr/.
  • Profiling

    Profiling is taking a slice of time and looking at the executable to understand what is going on during that particular time slice. More specifically, it is looking for areas of code that are not performing as optimally as desired. AIX provides the following tools to aid the developer:

    • tprof is a tool that can be used to locate trouble spots and then dig deeper with micro-profiling to the source line level. To use tprof for micro-profiling, the application must be linked and compiled with the –g debug flag.
    • prof and gprof require code to be compiled with either the –p or –gp flag to provide information on the number of times a function is called, who called the function, and the like. A major difference between this profiling technique and micro-profiling with tprof is that micro-profiling can analyze a time slice of the program versus the entire program, as do prof and gprof.
    • probeVUE is a dynamic tracing tool introduced with AIX 6.1.

Conclusion

This article introduced the porting engineer to the various tools available on the AIX platform to assist the engineer in building, debugging, and tuning applications ported to AIX. Future articles will explore more deeply the porting process of Build, Debug, and Tune.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=449411
ArticleTitle=AIX as a porting platform
publish-date=11242009