You can wrap usage of intrinsics with templates and create simd data types in C++ that use SSE when available and emulate it in software when not available. Doing so would be a boost library unto itself, which has been proposed many times and generally not well received because it favors which ever instruction set it chooses to target and is therefore not general. It would also be a maintanence headache because new revisions of the instruction set would require constant revisions of the library to keep up. For complicated reasons that become obvious once you comparatively study several vector instruction sets it is not practical (or really feasible for that matter) to target multiple instruction sets with such a library. You write your algorithms differently to take advantage of different instructions. <off topic> Except in fact, after a while you can just see all this as a real generic layer on top of register. I suggest you to get a hold of what we
Simonson, Lucanus J wrote: presented this year at Boost'Con. With the proper abstraction, we were able to handle all SSE flavors as well as AltiVec. The effort on maintenance is marginal. As an exercie we worked on a XOP binding. Took less than a week to get running. The main idea was to separate the low level, extensions pecific binding from a generic, EDSL based concept of "pack of N elements of type T" in which compile-time transform restructure simd expression toward their natural form for current extension. The error is to make a boost.SIMD stuff. You need a global overhaul of function for scalar and vector register, as scalar are baically vector register with one element. When you're there, everythign flow properly. As for the maitnenance, the IS doesn't change. New IS are made for new processor. At this either they are completely separate (altivec vs spu altivec) or they share an ancestry (SSE2,3,4,AVX for example). Both case are easily manageable. </off topic>