Using the Intel® IPP Library in an Embedded System - on Non-Standard Operating Systems

The Intel IPP 9.0 library is currently delivered on numbers operating system platforms: Microsoft* Windows*, Linux*, OS X* as host systems, and Windows , Linux, OS X, Android*, Tizen*, WindRiver* and Yocto Project as target systems. Application of the Intel IPP library to a "non-standard" operating system requires the following: 

• Single-threaded variant of the library,
• Access to a standard C library for the standard memory allocation routines (malloc/free)
• Tools that are compatible with one of the ABIs defined by the "standard" Intel IPP operating systems

In essence, operating system environments that follow the ABI rules used by Linux OS and the gcc compiler or the Windows OS and Microsoft* Visual C/C++ compiler are candidates for application of the Intel IPP library. Only the single-threaded variant of the Intel IPP library should be used on a non-standard operating system because  multi-threaded variants of the library require the OpenMP* library. (Obviously, if your embedded OS is directly derived from the Microsoft Windows and Linux OS, these rules will likely be satisfied.)

Support for the Standard C ABI

The Intel IPP library binaries are built using the Intel® C/C++ compiler; this does not mean that you must also use the Intel® compiler to build your code in if you will utilize the Intel IPP library in your application. Since the library is a C library it uses a standard C calling interface; meaning there are no name mangling complexities to contend with (standard C name mangling rules apply). Likewise, the call-return interface is compatible with the popular compilers and linkers used on the standard operating system platforms mentioned above (Windows and Linux). It is quite common for developers to use the Microsoft Visual Studio* compiler to create Intel IPP Windows applications and the gcc compiler for developing Intel IPP Linux applications.

Link with a Standard C Library

Only a few functions within the standard C library are needed to satisfy the needs of the Intel IPP library. The library primitives make no direct calls to operating system services and make no assumptions about the type of services that may be available within the underlying operating system. Memory allocation is the only significant operating system service required. As an option, memory allocation requests can be fielded by your own intermediate interface – further removing the operating system dependencies.

The IPP library functions use no locks, semaphores or static memory; they rely only on the calling application’s stack and the standard C library memory allocation routines (malloc/free) for temporary and static memory storage. To completely eliminate the Intel IPP library’s dependency on these C library memory allocation functions you can use the i_malloc interface to substitute your own memory allocation routines for the standard C library routines (see the Intel IPP i_malloc sample for details).

Limit Use to the Single-threaded Static Library (no OpenMP*)

If you restrict your application to the non-threaded static variant of the Intel IPP library, operating system requirements are minimized. Limiting yourself to a single-threaded variant of the library is not a dramatic compromise. Approximately 80% of the functions in the library are single-threaded (only 20% are multi-threaded). You need to use the single-threaded static variant because multi-threading within the Intel IPP library functions is implemented using the OpenMP* multi-threading library. For more information about threading within the Intel IPP library see this KB article: OpenMP and the Intel® IPP Library. In Intel® IPP 8.1 all multi-threaded libraries are deprecated and a number of new APIs are developed as a substitution for internally threaded ones: new FIR function in signal processing, filtering and morphology functions with "Border" suffix in image processing and computer vision domains. These functions can be threaded externally at the application level, that is significantly more efficient from the performance and usability point of view. You can use any threading tool for these functions: from pThreads and Windows API up to high-level OpenMP* and Intel® Threading Building Blocks (Intel® TBB).

The Intel's OpenMP* library is tightly coupled to the underlying operating system and the Intel® C and Fortran compilers. While Intel's OpenMP* library is compatible with OpenMP* standards, one cannot guarantee that OpenMP* libraries from different vendors are interchangeable. See the Intel compiler documentation section entitled OpenMP* Source Compatibility and Interoperability with Other Compilers for more information. So even if your embedded OS and compiler include an OpenMP library, it is safest to not use it with your Intel IPP application on a non-standard operating system.

Using the Intel® IPP Library with an RTOS

Applications that use the Intel IPP library can also be successfully applied to an RTOS. The lack of locks and semaphores within the library, and the atomic nature of the functions within the library, means the library is safe to use with many deterministic applications. The primitives in the library have not been “characterized” for deterministic applications; that is, they have not been defined to meet a guaranteed minimum execution time, so you should characterize the execution time of the functions you intend to use before deciding if they are suitable for use inside your time-critical code. The ippGetCpuClocks function from the ippCore domain, can be used to make these timing measurements.

An example of the value of applying the Intel IPP library to an RTOS can be illustrated with the TenAsys* INtime RTOS* for Windows. The INtime RTOS is a special-purpose operating system designed to run alongside Windows, allowing two operating systems to run side-by-side on a single hardware platform (Windows and the INtime RTOS).

One can build Intel IPP applications for the INtime RTOS because it implements an ABI that is compatible with the 32-bit Microsoft Windows ABI (note that the INtime RTOS has a unique API, but uses Windows-compatible function calling and return rules) and uses the Microsoft* Visual Studio development environment as its build and debug platform. Likewise, the Windows CE operating system can also support Intel IPP applications (for use on IA-32 Windows CE platforms only), for similar reasons (see the Intel IPP Windows CE sample for more information).

Another good example is VxWorks* OS by Wind River* - Intel IPP library for Linux is fully compatible with VxWorks user-mode applications (real-time processes).

Combining the Intel IPP library with an RTOS gives you a means to easily add the raw performance gains of SIMD instructions to the real-time determinism of an RTOS. In some applications displacing a DSP requires both performance and determinism. See the TenAsys white paper for more information about applying the Intel IPP library to an RTOS application.

How do you get started with the Intel IPP library? If you already own the Intel Compiler Pro compiler or one of the new Intel Parallel Studio products you've probably already got a copy of the Intel IPP library on your development system! If you don't have one of those tools you can always download an evaluation copy of the library. While the Intel compiler is a great tool for use with the Intel IPP library, the Intel compiler is not a requirement for building applications with the library. The Intel IPP library can be used with your favorite compiler for tremendous performance improvements.

Download a free evaluation copy of the IPP library at the main IPP product page.