SSE Performance Programming

Universal Binary Programming Guidelines

Intel Pentium References

What we are calling SSE in this document was actually delivered as three separate vector extensions to the IA-32 ISA, which appeared (in order over time) under the names SSE, SSE2 and SSE3. Each builds on the extension that went before it. The first two are defined to be part of the baseline hardware requirement for MacOS X for Intel. SSE3 has been recently introduced (first in the Prescott family of Pentium 4 processors) and may or may not be available on a machine running MacOS X for Intel. In addition, another vector extension, MMX, was available before SSE was introduced. It does packed integer arithmetic in a separate 64-bit register file that aliases to the x87 FPU register set, the scalar floating point unit (used only for long double on MacOS X for Intel.) It is also a defined part of the MacOS X for Intel, but for reasons explained later does not get as much use. All of these vector extensions are also defined for EM64T and AMD64.

AltiVec and SSE are quite similar at the highest levels. They are SIMD vector units with the same vector size (128-bits) and a similar general design. SSE adds several important new features compared to AltiVec. The single and double precision floating point engines are fully IEEE-754 compliant, which means that all four rounding modes, exceptions and flags are available. Misaligned loads and stores are handled in hardware. There is hardware support for floating point division and square root. There is a Sum of Absolute Differences instruction for video encoding. All of the floating point operations provided are available in both scalar and packed variants. These features will be described in more detail in later sections.

Hardware Overview

Registers

The Streaming SIMD Extensions define a set of 8 named 128-bit wide vector registers, called XMM registers. These are a flat register file like AltiVec. It is not stack based like the x87 register file. It has no special purpose registers like the x86 integer register file. On our ABI, all eight registers are volatile. For EM64T, the register file grows to 16 registers. (Note: Apple has not yet defined a ABI for 64-bit programming on MacOS X for Intel. 06/24/05)

In addition, there is a parallel set of 64-bit MMX registers that are used by the MMX extension to x86. The MMX register file aliases the x87 floating point register stack. Use of MMX causes an automatic x87 state save. The x87 unit will not function properly until you issue a EMMS instruction. (Use _mm_empty() for this.) Thus, MMX and x87 are mutually exclusive and may not be used at the same time. There is however no piece of hardware or software that is in place to prevent you from making this mistake. Unsurprisingly, failure to call _mm_empty() or use of MMX concurrently with x87 floating point code is a common mistake for people new to MMX. In certain cases, the paranoid may choose to use compiler devices like -mno-mmx flag to prevent unintentional MMX use, although such measures do not provide complete automatic protection. The flag does nothing to prevent use of those segments of SSE or SSE2 that use the MMX register file.

Pipelines, Latencies and Unrolling

There is quite a bit of variability between implementations of x86 based processors. Small parts of the design get regular tweaking even in minor updates to the processor. It is difficult to make sweeping generalization about the exact operation of various stages of the x86 pipelines: fetch, decode, dispatch, issue, execution and completion. Please see processor specific Intel documentation for a more complete description of the particular performance characteristics of each processor that you are targeting.

Generally speaking, the smaller register file on the x86 architecture compared to PowerPC is backed by a much larger reorder buffer, to reorder the execution of instructions to keep pipelines full. From the perspective of a developer experienced with AltiVec, it may initially appear difficult to keep pipelines full with eight registers. While this would be true of a strictly in-order architecture, the large reorder window allows the processor to pull future instructions forward to fill gaps in the pipelines to help make sure that the processor stays full. The processor may pull instructions forward from the next loop iteration. Indeed, in some cores it may not be uncommon to see several loop iterations unrolled in hardware in the reorder buffers. This process occurs transparently to the developer and may perform differently on different cores.

Utilizing a heavily out-of-order core may mean that your approach to unrolling your code may need to be different. Whereas in AltiVec it may have been a good idea to unroll up to eight-way in parallel, on SSE this will most likely overflow the register file. That will cause the compiler to spill temporary data onto the stack, introducing a large number of extra loads and stores into the critical code path, likely slowing things down dramatically.

Code example unrolled two-way in parallel:

for( i = 0; i < N - 1; i+= 2 )
{

float a0 = in[0];		float a1 = in[1];		in += 2;
float b0 = in2[0];		float b1 = in2[1];		in2 += 2;
a0 += b0;		a1 += b1;
a0 *= 3.14159f;		a1 *= 3.14159f;
out[0] = a0;		out[1] = a1;		out += 2;

}

It is important to minimize register spillage on x86. The right thing to do on x86 is usually to either not unroll at all (cores with a trace cache) or unroll serially (cores without a trace cache). Either approach should keep the pipelines full, presuming that the core of the loop is not so large that the distance that the processor needs to look ahead to find parallel calculation streams exceeds the size of the reorder buffer. Serial unrolling is a way to eliminate a few test and branch instructions. However, if the processor core has a trace cache, this advantage will often be more than offset by the cost of flushing more microcode out of the cache to make room for the unrolled loop.

For many SSE instructions, the second (non-destination) instruction argument may be a direct reference to memory instead of a register. Direct memory references are a good way to save registers, since they allow you to make use of data without first needing to load it into a named register. Make no mistake, the load still happens. The out-of-order processor core is probably doing a load behind the scenes. The key difference is that you don't need to sacrifice a named register to hold the loaded data. Also, the processor doesn't have to then get the data back out of the named register, a process which is more expensive on Intel than PowerPC, and which can actually cause processor stalls on Intel.

The good news is that these changes make life easy for you, the software developer. You may find that you don't need to unroll by hand at all. It is very easy for the compiler to unroll code serially, since it can do so without worrying about aliasing problems. Direct memory references reduce the work involved with making use of constants.

The latencies and throughputs for various instructions are listed in the Intel Pentium Processor Optimization Reference Manuals (Appendix C, see link at the top of this page). At the time of the announcement of MacOS X for Intel (June, 2005), a student of comparative architecture between PowerPC and x86 would observe that pipeline lengths are generally shorter on x86. Lower latencies make it possible to more easily fill pipelines with a modestly sized reorder window. In addition, then current architectures commonly have a vector throughput of one instruction per two cycles on vector execution units. This has the effect of halving the amount of instruction level parallelism required to saturate pipelines, at the cost of decreased throughput. All AltiVec instructions proceed with a throughput of one instruction per cycle.

ISA Overview

The instruction set architecture (ISA) for SSE is similar to other parts of the x86 ISA. No operations take more than two register operands. (Sometimes a third argument is present as an immediate operand set at compile/link time.) Typically, one of the register operands is used for both input and output data, which is to say that one of the two operands is destroyed and replaced with the instruction results. It is frequently necessary to copy data that is needed later to avoid having it destroyed. (If you are using a C compiler, the compiler will do this for you and provide the illusion of non-destructive operations.) The other argument frequently may be either a register or a direct memory reference, that takes its data straight from memory.

There are three major classes of data on the SSE vector unit: integer, single precision floating point and double precision floating point vectors, each of which may be serviced by separate parts of the processor, akin to the AltiVec VSIU, VCIU, VFPU, but for int, float and double. The three data types share the same XMM register file, so you can do one type operation directly on the result of an another type of operation (for example do a vector floating point add of the result of a vector integer computation). This is exactly like AltiVec. No conversions are done. The bits are just passed around unmodified. If you want to convert between types (e.g. convert an int to a float) with retention of value (e.g. 0x00000001 → 1.0f), there are special instructions for that.

However, unlike AltiVec, passing data back and forth between the three parts of the vector unit in this manner is frowned upon. In many cases, you will discover up to three seemingly redundant instructions that all do the same thing, one each for integer, single precision floating-point and double precision floating-point. Typical examples are vector loads and stores, certain permutes, and Boolean operations. There may be performance penalties for inter-unit data passing. It is recommended that, where possible, you use the appropriate instruction for the appropriate data type.

The Intel SIMD vector architecture was deployed over time as a series of four vector extensions to the x86 ISA. The first was MMX, followed by SSE, SSE2, and SSE3. SSE3 is the most recent, and is an optional feature of machines supported by MacOS X for Intel. The other three are guaranteed to be there, so you need only worry about SSE3. Details on each follow.

MMX

MMX, the first of the vector extensions provides a series of packed integer operators that utilize eight 64-bit registers described above. We do not describe MMX at length here because the operations defined by MMX are, generally speaking, also available in a 128-bit format in SSE2. Their use on SSE2 does not collide with the x87 unit, making SSE2 the generally preferred way to do these sorts of operations. MMX remains useful in a limited number of cases, especially those involving small data sets (particularly those 64 bits in size) and for some difficult to parallelize operations such as large-precision integer addition, but these cases are rare. MMX is sometimes used as a source of additional register storage area. However, since the vector ALU is shared with SSE2, there is likely no throughput advantage to using the two in parallel. Likewise since the cost of moving data to and from the MMX register file from XMM is likely to be larger than a simple aligned 128-bit load or store, such uses should be justified by real performance improvements.

MMX is enabled using the GCC compiler flag -mmmx. MMX is enabled by default on gcc-4.0. If MMX is enabled, the C preprocessor symbol __MMX__ is defined. MMX is disabled using the -mno-mmx flag on GCC.

Like AltiVec, there is a C Programming Interface for SSE. The two follow the same general design:

• The SIMD vector register is described in C as a special 128 bit data type.
• A series of function-like intrinsics are used to do SIMD style operations on those variables.

A notable difference is that many more intrinsics in the Intel C programming extensions do not correspond 1:1 with instructions in the ISA. Some developers may choose to limit their use of intrinsics to those that map 1:1 with ISA, so as not to introduce hidden expensive calculations.

Data Types

Intel defines three basic data types for SSE programming in C:

Any Packed Integer		float[4]		double[2]
__m128i		__m128		__m128d

These types are portable across the Gnu C Compiler, the Intel C Compiler and various x86 C compilers targeted towards the Windows™ operating system.

One shortcoming of this set of data types is that the __m128i type does not adequately describe the type and number of integer elements in the __m128i vector. Both Intel and Microsoft defined extensions to this subset to build in this information, and Apple is no exception. The Accelerate.framework defines a series of vector types that may be used for both AltiVec and SSE programming. It is recommended that you use these, since the extra information will make it easier to read your own code and make it possible for gdb and xcode to properly format vector data. In addition, it will allow you to share data types with AltiVec, which may simplify some programming tasks:

#include <Accelerate/Accelerate.h>

	8-bit	16-bit	32-bit	64-bit
signed	vSInt8	vSInt16	vSInt32	vSInt64
unsigned	vUInt8	vUInt16	vUInt32	vUInt64
floating point	-	–	vFloat	vDouble

Please note that while the 64-bit types (shown in red) are indeed defined for AltiVec by Accelerate.framework (and do work in the sense that you can load and store vectors full of 64-bit data types in and out of AltiVec register), there are no intrinsics (or instructions) defined by AltiVec itself to do SIMD style operations on elements of this size. The Accelerate.framework vBasicOps.h header declares some functions to allow you to do packed 64-bit integer operations. (These function using AltiVec intrinsics for smaller element sizes to build up larger operations — see available source code for vBasicOps.) Certain C language operators (e.g. +, -, *, /) may function with the vDouble type on GCC-4.0 and later on PowerPC. However these simply map the vector type to the scalar FPU and do standard arithmetic on the data using scalar code.

Intrinsics

Intel also defines a set of function-like intrinsics for programming SSE in C. These are similar to those provided by AltiVec, with some small differences. The Intel intrinsics use _mm_- instead of vec_- as the operator prefix. In addition, where AltiVec relies on C++ style function overloading to decide based on argument type which particular flavor of add to use among many, Intel has encoded this information as a suffix on the intrinsic:

AltiVec		SSE
vec_add( vSInt8, vSInt8 );		_mm_add_epi8( vSInt8, vSInt8 );
vec_add( vSInt16, vSInt16 );		_mm_add_epi16( vSInt16, vSInt16 );
vec_add( vSInt32, vSInt32 );		_mm_add_epi32( vSInt32, vSInt32 );
vec_add( vFloat, vFloat );		_mm_add_ps( vFloat, vFloat );
-		_mm_add_epi64( vSInt64, vSInt64 );
-		_mm_add_pd( vDouble, vDouble );
-		_mm_add_ss( vFloat, vFloat );
-		_mm_add_sd( vDouble, vDouble );

The suffixes are defined as follows:

suffix		description
-pi#		MMX (64-bit) vector containing packed #-bit integers
-pu#		MMX (64-bit) vector containing packed #-bit unsigned integers
-epi#		XMM (128-bit) vector containing packed #-bit integers
-epu#		XMM (128-bit) vector containing packed #-bit unsigned integers
-ps		XMM (128-bit) vector containing packed single precision floating point values
-ss		XMM (128-bit) vector containing one single precision floating point value
-pd		XMM (128-bit) vector containing packed double precision floating point values
-sd		XMM (128-bit) vector containing one double precision floating point value
-si64		MMX (64-bit) vector containing a single 64-bit int
-si128		XMM (128-bit) vector

The various intrinsics are available in one of four headers, one each for MMX, SSE, SSE2, and SSE3, when the corresponding ISA appeared:

MMX		mmintrin.h
SSE		xmmintrin.h
SSE2		emmintrin.h
SSE3		pmmintrin.h

The complete set of operations available for the Intel architecture is detailed in the Intel Architecture Software Developer's Manual (Volume 2, see link in the Introduction at top of page). There is a partial AltiVec to SSE translation table in the Universal Binary Programming Guide, Appendix B. More thorough conversion tables appear in various segments entitled Algorithms/Conversions in the part of this document to follow.

In addition, GCC has a set of GCC native non-portable intrinsics, described here. Please note that these are subject to change. GCC can and does regularly remove __builtins from the programming environment.

Sample function

Here is a function that calculates the distances from the origin {0,0} of a set of 4 {x,y} pairs in AltiVec:

#include <Accelerate/Accelerate.h> //contains data types used

vFloat Distance( vFloat x, vFloat y )
{

vFloat x2 = vec_madd( x, x, (vFloat) (-0.0f) ); //x * x
vFloat distance2 = vec_madd( y, y, x2 ); // x*x + y*y

return vsqrtf( distance2 ); //from Accelerate.framework

}

and here is the same thing in SSE (changes in red):

If you wish to tie yourself to GCC specific features, you may investigate GCC's unified vector programming interfaces. That would allow you to write the following and compile for both platforms:

Since this is a new feature, it is suggested that you inspect generated code thoroughly. In addition, there are clearly other ways to do the same thing, using some inline functions or macros using more traditional interfaces, that may preserve your compiler independence.

Detecting SSE3

SSE3 is an optional hardware feature on MacOS X for Intel. If you wish to use SSE3 features, you must detect them first, similar to how you are required to check for AltiVec. The same interfaces are used, just a different sysctlbyname() selector:

#include <sys/sysctl.h>

int IsSSE3Present( void )
{

int hasSSE3 = 0;
size_t length = sizeof( hasSSE3 );
int error = sysctlbyname("hw.optional.sse3", &hasSSE3, &length, NULL, 0);
if( 0 != error ) return 0;
return hasSSE3;

}

Similar selectors exist for MMX, SSE and SSE2, but since those are required features for MacOS X for Intel, it is not required that you test them before using those vector extensions, in software intended solely for MacOS X for Intel. (SSE is not available in any format for MacOS X for PowerPC and AltiVec is not available for MacOS X for Intel. When writing code for Universal Binaries to run on MacOS X, you should conditionalize your code using appropriate symbols like __VEC__ and __SSE2__ to prevent the compiler from seeing vector code for unsupported architectures for each fork of the universal binary.)

Translating AltiVec to SSE

Floating Point

Both AltiVec and SSE do single precision floating point arithmetic. SSE2 also does double precision floating point arithmetic. Finally, for each packed vector floating point operation on SSE or SSE2, there is also a scalar version that can be done by the vector unit that operates on only one element in the vector:

	packed vector	scalar on vector
float	AltiVec + SSE	SSE
double	SSE2	SSE2

The scalar-on-vector feature is used by MacOS X on Intel to do most scalar floating point arithmetic. So, if you write a normal floating point expression, such as "float a = 2.0f;" that will be done on XMM. (For compiler illuminati, the GCC compiler flag, -mfpmath=sse, is on by default.) Single and double precision scalar floating point arithmetic is done on the SSE unit both for speed and also so as to deliver computational results much more like those obtained from PowerPC. The legacy x87 scalar floating point unit is still used for long double, because of its enhanced precision.

Please note that the results of floating point calculations will likely not be exactly the same between PowerPC and Intel, because the PowerPC scalar and vector FPU cores are designed around a fused multiply add operation. The Intel chips have separate multiplier and adder, meaning that those operations must be done separately. This means that for some steps in a calculation, the Intel CPU may incur an extra rounding step, which may introduce 1/2 ulp errors at the multiplication stage in the calculation. Please note that in cases involving catostrophic cancellation, this may give results that are vastly different after the addition or subtraction has completed.

SSE Floating Point Environment

The floating point environments on SSE and AltiVec are very similar. Both vector floating point units are heavily influenced by IEEE-754. Both units store their data in IEEE-754 floating point format, though, in memory, the Intel architecture stores the bytes in little endian order. Both deliver nearly the same feature set of correctly rounded basic operations, such as addition, subtraction and multiplication. (Intel is slightly richer.) For more complicated functions such as the vector versions of the standard libm transcendental operations (sin(), cos(), pow(), etc.), look to Accelerate.framework. (#include <Accelerate/Accelerate.h>). Accelerate.framework actually provides this class of operations in two different flavors:

• For simple long array computation, look to vForce.h, new for MacOS X.4.
• For vector transcendentals involving 128-bit SIMD vectors, look to vfp.h (available on all MacOS X versions).

When it comes to other aspects of IEEE-754 compliance, SSE is a bit of a step up. While AltiVec delivers the Java subset of IEEE-754, the Intel vector unit is a fully IEEE-754 compliant machine, delivering full rounding modes, exceptions and flags.

A feature comparison chart follows:

		AltiVec		SSE
Rounding modes		round to nearest only		All four (nearest, zero, Inf, -Inf)
Exceptions		denormals		All IEEE-754 + denormals
Flags		none		ALL IEEE-754 + denormals
Square root		Software		Hardware
Divide		Software		Hardware
compare bounds		yes		no
log2(x) and 2x estimates		yes		no
reciprocal estimate		yes		yes
reciprocal sqrt estimate		yes		yes
scalar on vector		no		yes

All hardware supported operations (that aren't estimates) are correctly rounded to 24 bits (float) or 53 bits (double) of precision. (The other 9/12 bits are used for exponent and sign information, exactly like PowerPC.) The accuracy of the estimates is very close to that of AltiVec, approximately 12 bits for reciprocal estimate and reciprocal square root estimate.

Just as PowerPC has a separate scalar floating point engine (the G5 has 2!), the Intel architecture also has a legacy scalar floating point unit, called the x87 floating point unit. The x87 calculates results to 64 bits of precision, using an 80-bit extended precision floating point engine. It is used for long double calculations on MacOS X for Intel.

Denormal Handling

Neither AltiVec or SEE currently provide fast hardware support for denormals. In each case, a vector status and control register is available, with some bits that can be changed to turn on and off denormal handling. If denormal handling is turned on on a PowerPC machine and a denormal is encountered, the calculation is handled in a fast kernel trap. On a SSE enabled Intel chip the denormal is handled in hardware. As shown below, the denormal is expensive to handle in both cases:

		G5		Pentium 4 (P4 660)
By default, denormals are:		OFF		ON
Cost for handling a denormal:		1100 cycles		1550 cycles

OFF = denormals not handled (flushed to zero)
ON = denormals handled (1100-1550 cycle penalty)

If one turns off denormal handling, then the two machines flush the denormals to zero and proceed as if the data they are operating on is zero. This path operates at the same cost as arithmetic on normalized numbers, at the expense of incorrect results for denormalized inputs or outputs (which are flushed to zero).

Historical use of denormals has been varied. Under MacOS 9, operating system handling of denormals was on by default, meaning that ever time you hit a denormal on MacOS 9, the machine would take a large stall while the correct result was calculated for the vector unit by the operating system. MacOS X for PowerPC ships with denormals off for AltiVec by default. (We did explore turning them on briefly in the safety and comfort of our own test labs in order to deliver more correct results for MacOS X.3, but found we were breaking some 3rd party audio code with real time data delivery needs.) However, denormal handling is on by default for PowerPC scalar floating point, where denormals are handled in hardware at no additional cost.

Under MacOS X for Intel, denormal handling is back ON by default. This is required for standards compliant operation of normal scalar floating point code, which, if you will recall, is being done by the vector unit. Since the SSE vector status and control register (MXCSR) does not differentiate between scalar and vector operations done on the vector engine, this means that the denormal handling is on by default for packed vector arithmetic too.

If you are writing code with real time delivery needs, especially audio code, you may consider turning denormals off. Please be aware that if you do so, your code, both scalar and vector (except long double) will flush denormals to zero, meaning that strictly speaking, the results will be incorrect for the set of denormalized numbers. For certain classes of computations, particularly audio, this is generally not a problem — listeners are likely unable to hear the difference between the range of denormalized numbers (0 < x < 2^-126) and zero. For others, it is a problem. Proceed wisely. We recommend leaving denormal handling enabled unless you actually have a problem. Generally speaking, denormals do not happen often enough to cause trouble. However, certain classes of algorithms (most notably IIR filters) may produce nothing but denormals in certain situations (input gain goes to zero). If that occurs in a real time thread, system responsiveness may be adversely affected. Results may not be delivered on time.

To turn denormals off on AltiVec, set the Non-Java bit in the AltiVec VSCR. To turn denormals off on SSE, turn on the Denormals Are Zero and Flush to Zero (DAZ and FZ) bits in the MXCSR:

#include <xmmintrin.h>

int oldMXCSR = _mm_getcsr(); //read the old MXCSR setting
int newMXCSR = oldMXCSR | 0x8040; // set DAZ and FZ bits
_mm_setcsr( newMXCSR ); //write the new MXCSR setting to the MXCSR

... // do your work with denormals off here

//restore old MXCSR settings to turn denormals back on if they were on
_mm_setcsr( oldMXCSR );

You may also use the C99 Standard fenv.h, with the MasOS X for Intel specific default denormals-off floating point environment.

#include <fenv.h>
#pragma STDC FENV_ACCESS ON

fenv_t oldEnv;

//Read the old environment and set the new environment using default flags and denormals off
fegetenv( &oldEnv );
fesetenv( FE_DFL_DISABLE_SSE_DENORMS_ENV );

... //do work here

//Restore old floating point environment
fesetenv( &oldEnv );

Note: Both of the above code examples lose track of floating point status flag changes that occur while denormals are turned off. Rather than simply swapping floating point environments, it is possible to preserve floating point state across this series of operations by doing various bitwise boolean operations to copy information between states. This may be required if you are relying on floating point state flags for diagnostic information or are using SIGFPE.

Setting and checking other bits in the MXCSR will allow you to take an exception if you hit a denormal (DM) and check to see whether you have previously hit a denormal (DE) in the vector unit, in addition to the typical IEEE-754 exceptions and flags.

Denormals also cause large stalls on the x87 scalar floating point unit. Simply loading and storing denormals in and out of the x87 unit may cause a stall. The processor has to convert them to 80-bit extended format and back during these operations. There is no way to disable denormal handling on x87.

Algorithms / Conversions

Here is a table of standard conversions for floating point operations in AltiVec and SSE:

AltiVec		SSE
vec_add(a, b)		_mm_add_ps(a, b)
vec_and(a, b)		_mm_and_ps(a, b)
vec_andc(a, b)		_mm_andnot_ps(b, a)
vec_ceil(a)		see below
vec_expte(a)		none (use vexpf in Accelerate.framework, vfp.h)
vec_floor(a)		see below
vec_loge(a)		none (use vlogf in Accelerate.framework, vfp.h)
vec_madd(a,b,c)		_mm_add_ps( _mm_mul_ps(a,b), c)
vec_max(a, b)		_mm_max_ps(a, b)
vec_min(a, b)		_mm_min_ps(a, b)
vec_nmsub(a,b,c)		_mm_sub_ps(c, _mm_mul_ps(a,b))
vec_nor(a,b)		_mm_xor_ps( _mm_or_ps(a,b), 0xFFFFFFFF )
vec_or(a,b)		_mm_or_ps(a, b)
vec_re(a)		_mm_rcp_ps(a)
vec_round(a)		see below
vec_rsqrte(a)		_mm_rsqrt_ps(a)
vec_sel(a,b,c)		_mm_or_ps(_mm_andnot_ps(c,a), _mm_and_ps(c,b) )
vec_sub(a,b)		_mm_sub_ps(a,b)
vec_trunc(a)		see below
vec_xor(a,b)		_mm_xor_ps(a,b)

Don't forget to convert all of those vec_madd( a, b, -0.0f) to _mm_mul_ps(a, b). It will save an instruction.

The most notable missing conversion in the table above is explicit floating point rounding to integer. In many cases, this can be solved by setting the appropriate rounding mode in the MXCSR and converting the vFloat to a vSInt32. This process is covered more in depth in the conversions section below. However, that only works if the floating point value is representable as a 32-bit integer. Since many do not fit into the 32-bit signed integer range, it may be necessary to use a full precision floor function. The basic operation involves adding a large magic number to the vFloat, then subtracting it away again. The number is chosen such that the unit in the last place of the magic number corresponds to the 1's binary digit. This value is 2²³, 0x1.0p23f. This causes rounding at that position according to the processor's rounding mode after the addition. When 2²³ is subtracted away again, the value will be restored, but correctly rounded to integer value.

There are some tricks to this process. Negative numbers may require that you reverse the order of the add and subtract, or use 2²⁴. With some clever programming you may be able to avoid toggling the MXCSR to set rounding modes and come up with an algorithm that works for all four rounding modes. Depending on your specific application, you may be able to avoid some or all of these steps. In the simplest case, it is just an add and a subtract. Here is some sample code for floor and trunc.

static inline vFloat _mm_floor_ps( vFloat v ) __attribute__ ((always_inline));
static inline vFloat _mm_floor_ps( vFloat v )
{

static const vFloat twoTo23 = (vFloat){ 0x1.0p23f, 0x1.0p23f, 0x1.0p23f, 0x1.0p23f };
vFloat b = (vFloat) _mm_srli_epi32( _mm_slli_epi32( (vUInt32) v, 1 ), 1 ); //fabs(v)
vFloat d = _mm_sub_ps( _mm_add_ps( _mm_add_ps( _mm_sub_ps( v, twoTo23 ), twoTo23 ), twoTo23 ), twoTo23 ); //the meat of floor
vFloat largeMaskE = (vFloat) _mm_cmpgt_ps( b, twoTo23 ); //-1 if v >= 2**23
vFloat g = (vFloat) _mm_cmplt_ps( v, d ); //check for possible off by one error
vFloat h = _mm_cvtepi32_ps( (vUInt32) g ); //convert positive check result to -1.0, negative to 0.0
vFloat t = _mm_add_ps( d, h ); //add in the error if there is one

//Select between output result and input value based on v >= 2**23
v = _mm_and_ps( v, largeMaskE );
t = _mm_andnot_ps( largeMaskE, t );

return _mm_or_ps( t, v );

}

static inline vFloat _mm_trunc_ps( vFloat v ) __attribute__ ((always_inline));
static inline vFloat _mm_trunc_ps( vFloat v )
{

static const vFloat twoTo23 = (vFloat){ 0x1.0p23f, 0x1.0p23f, 0x1.0p23f, 0x1.0p23f };
vFloat b = (vFloat) _mm_srli_epi32( _mm_slli_epi32( (vUInt32) v, 1 ), 1 ); //fabs(v)
vFloat d = _mm_sub_ps( _mm_add_ps( b, twoTo23 ), twoTo23 ); //the meat of floor
vFloat largeMaskE = (vFloat) _mm_cmpgt_ps( b, twoTo23 ); //-1 if v >= 2**23
vFloat g = (vFloat) _mm_cmplt_ps( b, d ); //check for possible off by one error
vFloat h = _mm_cvtepi32_ps( (vUInt32) g ); //convert positive check result to -1.0, negative to 0.0
vFloat t = _mm_add_ps( d, h ); //add in the error if there is one

//put the sign bit back
vFloat sign = (vFloat) _mm_slli_epi31( _mm_srli128( (vUInt32) v, 31), 31 );
t = _mm_or_ps( t, sign );

//Select between output result and input value based on fabs(v) >= 2**23
v = _mm_and_ps( v, largeMaskE );
t = _mm_andnot_ps( largeMaskE, t );

return _mm_or_ps( t, v );

}

Integer

Most integer operations on SSE are in the SSE2 segment of the vector extensions. Packed vector integer arithmetic first debuted on the Intel platform in MMX. The same operations were later redeployed on the XMM register file in SSE2. All vector integer instructions generally start with the letter P (for packed). Most integer instructions come in two flavors with the same name, one for MMX and one for XMM. For a complete list, please see the Intel Architecture Software Developer's Manual, Volumes 2. (Link available at the top of this page.) Because the two share the same name and use of MMX can damage x87 floating point state, it may be advisable in certain circumstances to employ GCC compiler flags such as -mno-mmx, to avoid inadvertently using MMX.

Add / Subtract / Min / Max

You will find the full complement of modulo adds and subtracts on SSE2. In addition, SSE2 also does 64-bit modulo addition and subtraction. The AltiVec vec_addc and vec_subc for large-precision unsigned integer addition and subtraction do not have SSE counterparts, however. It is suggested that you use the 64-bit adder to handle your extended integer precision.

SSE2 supports saturated addition for 8- and 16-bit element sizes only. Min and Max functions are available for vUInt8 and vSInt16, only.

Multiplication

One of the more difficult problems to solve when translating AltiVec to SSE is what to do about integer multiplication. There is almost no overlap between AltiVec and SSE for integer multiplication. The AltiVec vec_mladd() operation is a little bit like _mm_mullo_epi16(), and vec_msum() is a little bit like _mm_madd_epi16(), but they are by no means a close match. There are 5 integer multipliers on SSE2:

_mm_mullo_epi16(a,b)		v(S/U)Int16		low 16-bits of the product of two 16-bit integers
_mm_mulhi_epi16(a,b)		vSInt16		high 16-bits of the product of two 16-bit signed integers
_mm_mulhi_epu16(a,b)		vUInt16		high 16-bits of the product of two 16-bit unsigned integers
_mm_mul_epu32(a,b)		vUInt32		64-bit product of two vUInt32's (odd elements)
_mm_madd_epi16(a,b)		vSInt16		sum of adjacent signed 32-bit products of int16_t

One shared calculation motif that works reasonably well between AltiVec and SSE is the concept of full precision multiplies, where two vectors with element of size N, multiply to create two product vectors with element size 2N. On AltiVec, this is done with vec_mule and vec_mulo, followed by vec_merge to interleave even and odd results. On SSE, you can use the low and high 16 bit multiplies, with a merge operation (see _mm_unpack(lo/hi)_epi16() ).

The other shared calculation motif that works well is to exploit commonalities between _mm_madd_epi16() and vec_msum( vSInt16, vSInt16, vSInt32 ). Finally, in a very small number of cases, you can use _mm_mullo_epi16(a,b) interchangeably with vec_mladd(a,b,0).

Algorithms / Conversions

Here is a table of simple AltiVec to SSE translations for integer arithmetic:

AltiVec	Type	SSE2
vec_abs(a)	vSInt8	vSInt8 t = _mm_cmpgt_epi8(0,a); return _mm_sub_epi8(_mm_xor_si128( a, t), t);
vec_abs(a)	vSInt16	_mm_max_epi16( a, _mm_sub_epi16( 0, a ) )
vec_abs(a)	vSInt32	vSInt8 t = _mm_srai_epi32(a,31); return _mm_sub_epi32(_mm_xor_si128( a, t), t);
vec_abss(a)	vSInt8	vSInt8 t = _mm_cmpgt_epi8(0,a); return _mm_subs_epi8(_mm_xor_si128( a, t), t);
vec_abss(a)	vSInt16	_mm_max_epi16( a, _mm_subs_epi16( 0, a ) )
vec_abss(a)	vSInt32	none
vec_add(a,b)	vSInt8	_mm_add_epi8(a,b)
vec_add(a,b)	vUInt8	_mm_add_epi8(a,b)
vec_add(a,b)	vSInt16	_mm_add_epi16(a,b)
vec_add(a,b)	vUInt16	_mm_add_epi16(a,b)
vec_add(a,b)	vSInt32	_mm_add_epi32(a,b)
vec_add(a,b)	vUInt32	_mm_add_epi32(a,b)
vec_adds(a,b)	vSInt8	_mm_adds_epi8(a,b)
vec_adds(a,b)	vUInt8	_mm_adds_epu8(a,b)
vec_adds(a,b)	vSInt16	_mm_adds_epi16(a,b)
vec_adds(a,b)	vUInt16	_mm_adds_epu16(a,b)
vec_adds(a,b)	vSInt32	none
vec_adds(a,b)	vUInt32	none
vec_and(a,b)	any int type	_mm_and_si128(a,b)
vec_andc(a,b)	any int type	_mm_andnot_si128(b,a)
vec_avg(a,b)	vSInt8	none
vec_avg(a,b)	vUInt8	_mm_avg_epu8(a,b)
vec_avg(a,b)	vSInt16	none
vec_avg(a,b)	vUInt16	_mm_avg_epu16(a,b)
vec_avg(a,b)	vSInt32	none
vec_avg(a,b)	vUInt32	none
vec_madds(a,b,c)	vSInt16	none. see [1]
vec_max(a,b)	vSInt8	vSInt8 t = _mm_cmpgt_epi8(a,b); return _mm_or_si128( _mm_andnot_si128(t,b), _mm_and_si128(t,a));
vec_max(a,b)	vUInt8	_mm_max_epu8(a,b)
vec_max(a,b)	vSInt16	_mm_max_epi16(a,b)
vec_max(a,b)	vUInt16	none
vec_max(a,b)	vSInt32	vSInt32 t = _mm_cmpgt_epi32(a,b); return _mm_or_si128( _mm_andnot_si128(t,b), _mm_and_si128(t,a));
vec_max(a,b)	vUInt32	none
vec_min(a,b)	vSInt8	vSInt8 t = _mm_cmpgt_epi8(a,b); return _mm_or_si128( _mm_and_si128(t,b), _mm_andnot_si128(t,a));
vec_min(a,b)	vUInt8	_mm_min_epu8(a,b)
vec_min(a,b)	vSInt16	_mm_min_epi16(a,b)
vec_min(a,b)	vUInt16	none
vec_min(a,b)	vSInt32	vSInt32 t = _mm_cmpgt_epi32(a,b); return _mm_or_si128( _mm_and_si128(t,b), _mm_andnot_si128(t,a));
vec_min(a,b)	vUInt32	none
vec_mladd(a,b,c)	v(U/S)Int16	_mm_add_epi16( _mm_mullo_epi16(a,b),c)
vec_mradds(a,b,c)	vSInt16	none. see [1]
vec_msum(a,b,c)	v(U/S)Int8	none.
vec_msum(a,b,c)	vSInt16	_mm_add_epi32( _mm_madd_epi16(a,b), c )
vec_msum(a,b,c)	vUInt16	none
vec_msums(a,b,c)	v(U/S)Int16	none. Saturated 32-bit add missing.
vec_mule(a,b)	any	none. see [2]
vec_mulo(a,b)	any	none. see [2]
vec_nor(a,b)	any	_mm_xor_si128( _mm_or_si128(a,b), -1)
vec_or(a,b)	any	_mm_or_si128(a,b)
vec_sel(a,b,c)	any	_mm_or_si128( _mm_and_si128(c,b), _mm_andnot_si128(c,a))
vec_sub(a,b)	v(U/S)Int8	_mm_sub_epi8(a,b)
vec_sub(a,b)	v(U/S)Int16	_mm_sub_epi16(a,b)
vec_sub(a,b)	v(U/S)Int32	_mm_sub_epi32(a,b)
vec_subs(a,b)	vSInt8	_mm_subs_epi8(a,b)
vec_subs(a,b)	vUInt8	_mm_subs_epu8(a,b)
vec_subs(a,b)	vSInt16	_mm_subs_epi16(a,b)
vec_subs(a,b)	vUInt16	_mm_subs_epu16(a,b)
vec_subs(a,b)	vSInt32	none
vec_subs(a,b)	vUInt32	none
vec_sum4s(a,b)	any	none
vec_sum2s(a,b)	vSInt32	none
vec_sums(a,b)	vSInt32	none
vec_xor(a,b)	any	_mm_xor_si128(a,b)

[1] Something similar can be done with _mm_mulhi_epi16() and vec_add(s)_epi16(). However, _mm_mulhi_epi16 shifts right by 16, and the AltiVec instruction shifts right by 15, so some change in fixed point format will be required.

[2] Mule and mulo are often better thought of in the larger context of one of two ways to do N-bit * N-bit = 2N-bit multiplication. The even/odd paradigm is used so that an instruction doesn't have to return two vectors as a result, which is architecturally impermissible. SSE uses the high/low paradigm instead. To get the full 2N bit precise result in both cases, you do the even/odd multiply or high/low multiply first, then use a pair of merge high/low operations to interleave the results. Example:

//AltiVec: multiply a * b and return double wide result in high and low result
void vec_mul_full( vSInt32 *highResult, vSInt32 *lowResult, vSInt16 a, vSInt16 b)
{

vSInt32 even = vec_mule( a, b );
vSInt32 odd = vec_mulo( a, b );
*highResult = vec_mergeh( even, odd );
*lowResult = vec_mergel( even, odd );

}