Codeplay's Sieveā„¢ technology is a system for taking existing C++ software and transforming it so that it can be compiled with multiple different C compilers and distributed across multiple processor cores.

Key benefits of Sieve technology:

  1. Works with existing C++ software and existing C and C++ compilers for multiple different processor cores.
  2. Allows data structures to be shared across multiple different processor cores, different C and C++ compilers and different memory spaces.
  3. Allows some memory accesses to be "sieved out" and treated differently to other memory accesses, thereby allowing parallelization techniques and software caches to be added to existing, large C++ software.

The core principal behind the Sieve technology is that to distribute software across multiple cores in a system, there needs to be shared access to shared data structures, and fast access to local data. The system therefore separates existing variables and objects between local and shared memory and ensures that shared data structures are binary compatible between different cores in the system.

Sieve works by having a compiler tool that takes in existing C++ source code and outputs C source files. The C source files can be passed through different processor cores in the system, and contain macros to access shared data. The macros can be defined to use whatever shared data access the programmer wants to use, but for the Codeplay Offload system, a software cache is used for shared data structures.

The Sieve tool has calculated the data structure layout for each C++ class, in a way that is compatible with existing C++ compilers (e.g. GCC 4.x.) The C source files can then be compiled with other C compilers that do not have to have the ability to match C++ class layouts, because the Sieve tool has already calculated this.

The Sieve system consists of:

  1. The compiler tool, that takes in C++ source and outputs multiple C source files, and (optionally) make files, and DWARF 2 debugging information.
  2. A runtime system that can be linked with the object files to distribute work safely between different processors
  3. A set of header files that define macros for all of the operations that each individual processor core can perform (including DMA, if any, and vector SIMD operations, if any)
  4. A configuration file defining which processor cores and which compilers support which DMA and SIMD operations.
  5. A built tool that links together all of the object files and debug information into a single executable
  6. Eclipse and Visual Studio IDE integration
  7. A source-level debugger