In this post we’ll merge these concepts by creating a version of the CMYK to RGB conversion code strictly in raw SSE and assembly. The upshot is you’ll see how we can take existing, real-world C++ code and use GCC’s Extended Assembly syntax to interweave raw assembly code for potential performance gains.

This means this tutorial is not just about extended assembly or sse coding, it’s about using both in a real-world application. We’ll learn many concepts including data retrieval, loop processing, SSE processor instructions, floating point number representation, and much more!

Let’s start our tutorial by taking a quick look at the core algorithm logic we’ll be implementing (for a more in-depth refresher this is covered in some detail here ):

c = 1.0 - (bits / 255f)
m = 1.0 - (bits / 255f)
y = 1.0 - (bits / 255f)

k = the min of c/m/y

if k != 1
c = (c - k) / (1 - k)
m = (m - k) / (1 - k)
y = (y - k) / (1 - k)

c = c * 255
m = m * 255
y = y * 255
k = k * 255

The data source (the incoming image data) is a call to Qt’s QImage::bits() function, which returns a pointer to a uchar array containing the raw image data-stream.

The destination, that is, the RGB converted data, is a heap-based uchar array created via:

uchar *cmyk_temp = new uchar[(wt * ht) * 4];

In other words we already have a source and a destination set in C++. (To put it simply, the point of this tutorial is to write assembly to mange the data in-between these two places.) This means the first big task in creating an assembly version is knowing how we ‘hook’ into those existing data structures.

A key point in this regard is that while we’ll manage loops and data access in our assembly code, we do not want to think about managing the stack. Thus, we can think of these two arrays as places we’ll get the address to via pointers, but never create and manage in assembly on our own.

So how do we access this data from GCC Extended Assembly?

The answer is we, in extended assembly syntax, use these pointer variables as input and output parameters. (please see here for a brief primer on GCC inline assembly)

For example, lets say we have the following C++:

int a = 1;

__asm__ __volatile__(

"mov %0, %%ebx \n\t"

: /* output parameters */

: "m"(a)

: ebx /* clobbers */

);

This code says that we’ll take the int a variable and push it to ebx. The key is behind the scenes CGG will actually rewrite this mov instruction to something like:

mov -0x20(%rbx), %ebx

In other words, we let GCC manage the stack. Using Extended Assembly like this means we don’t care where on the stack int a comes from, we just want to make sure we have access to it. The extended assembly syntax allows for this easy manipulation of data.

For our code, this means the start of our implementation will actually be a series of C++ variable declarations that we’ll end up passing into the __asm__ call.

One item of note here is along with simple arrays pointers and ints, we also declare two __m128 objects for easy double quad-word storage of constants we’ll need for our calculations, those being vectors of 1.0f and 255.0f.

“Talking” to these __m128 items is accomplished in much the same as our example above, only now we use the movaps mnemonic as in:

"movaps %5, %%xmm14 \n\t" // 255.0

In other words, bytes, chars, floats, __m128′s — we can create whatever we need and pass it to the assembly routine, which means we don’t need to worry about the stack.

Register Pressure

This takes us to one of the main goals of this exercise: use as many CPU registers as possible during the conversion process. This means one of the explicit assumptions of this code is it only runs on 64-bit machines. That is, it’s hard-coded to use the full register set available to x86_64.

This means we have an extended range of 64-bit (quad-word) general purpose registers (r8-r15), as well as the full set of 128-bit (double quad-word) SSE registers, xmm0-xmm15.

Obviously the assumption here is the fewer trips to main memory we can make, the faster our code will be.

And so, the first ‘preparatory’ part of our assembly code is spent mapping various constants to known registers so we can refer back to them as often as needed without making expensive trips to main memory.

The interesting bit here is not all of our mov’s are for the same purpose. Some moves, as in above, are to store 128 bit values to an SSE register. Others are for setting up bit masks, and still others are set up for loops counters.

Of course key is that this logic happens outside of our main conversion loop. Once we enter the loop we do as much as we can to avoid reads and writes to main memory.

With that said, let’s jump strait into the code and see how it works!

Part 1 – Initialization.

In this section we perform the essential task of initializing the variables we’ll pass to the extended asm routine.

Note the *bits array, this is the source of the values being used. This is an example of a standard link to a variable, though we also create a few float arrays and zero out their initial values for easier debugging.

The most important bit in this block is the _pack_lookup_table float array. The creation of this item (a classic lookup table) is to reduce the possible overhead of the uchar to float conversions we must make.

The idea is simple: because we only have 256 possible input values, instead of converting each in turn at run-time, lets just create a lookup table and map the input values to the IEE floating point representation created in the loop (whose values are calculated at compile, not run-time). This has a huge potential benefit as each pixel will require 3 conversions, and when you’re dealing with 8 million pixels per image these int to float conversions can really add up.

To be clear though, converting ints to floats on modern hardware isn’t a huge deal (around 8-16 cycles on most CPU’S), but this is still a handy way to learn about assembly coding. We will see in Part 4 however, that our lookup table may not be the best possible solution because of the extra memory trips we end up making.

Alas, this is also a good excuse to learn a bit more about assembly level addressing modes, which we’ll see a good deal of in many different places.

As such, the code below is just standard C++.

int t = 1;
int l = (char)t;

uchar *bits = imin.bits();

int count = (wt * ht) * 4; // link with loop counter byte size

int k_min_value;

float * _pack_loop_array = new float[4];
// zero out array for easier debugging
_pack_loop_array[0] = 0;
_pack_loop_array[1] = 0;
_pack_loop_array[2] = 0;
_pack_loop_array[3] = 0;

float * _mask_array = new float[4];
// zero out array for easier debugging
_mask_array[0] = 0;
_mask_array[1] = 0;
_mask_array[2] = 0;
_mask_array[3] = 0;

float * _pack_lookup_table = new float[256];
for(int i = 0; i <= 256; i++){
    _pack_lookup_table[i] = (float)i;
}

// mmx constants - use m128 to ensure aligned data
__m128 m_1 = _mm_set_ps1(1.0f);
__m128 m_255 = _mm_set_ps1(255.0f);

Part 2 – Initial __asm__ and Constant Creation

In this section we dive into the heart of our routines assembly code.

A good deal of space is for initialising loop constants and mapping values to registers–pretty standard stuff.

We do have one interesting bit though, which is the creation of the 128-bit sign-flip mask.

We’ve done this because in IEE single-precision floating point representation, the HO bit (bit 31) is always the sign bit. When the bit’s 0 the value is positive, when it’s a 1 negative.

We can exploit this fact to easily flip the sign of a float, or in our case, the packed floats. Problem is, in order to create a 32-bit string in the form of the proper sign-flip mask (0×80000000) we would have to resort to all sorts of trickery in C++. That is, how do you create the bit pattern of our mask without the compiler trying to turn it into something else, such as a float, int, or char? It sounds like an easy problem to address, but it isn’t.

Thus, as the value needs to be created anyway, we’ll just do so in assembly, where defining and populating memory locations with arbitrary bit-strings is easy.

In the end we push this mask value to xmm4 where it remains constant throughout the life of the conversion process.

__asm__ __volatile__(

    // set sse constants

    "movaps %5, %%xmm14 \n\t" // 255.0
    "movaps %4, %%xmm15 \n\t" // 1.0

    // init sign SSE sign-flip mask
    "xorps %%xmm4, %%xmm4 \n\t"

    "xor %%rax, %%rax \n\t"
    "xor %%r11, %%r11 \n\t"
    "mov $0x80000000, %%r11 \n\t"
    "mov %9, %%rbx \n\t"

    // populate mask values

    "mov %%r11,(%%rbx, %%rax, 1) \n\t"
    "add $0x4, %%rax \n\t"
    "mov %%r11,(%%rbx, %%rax, 1) \n\t"
    "add $0x4, %%rax \n\t"
    "mov %%r11,(%%rbx, %%rax, 1) \n\t"
    "add $0x4, %%rax \n\t"
    "mov %%r11,(%%rbx, %%rax, 1) \n\t"

    // populate sse reg
    "movaps (%%rbx), %%xmm4 \n\t"

    // init loop constants

    "xor %%rax, %%rax \n\t" /* init i array counter */

    "xor %%rdx, %%rdx \n\t" /* set array counter upper bounds */
    "mov %2, %%edx \n\t"

    "xor %%rcx, %%rcx \n\t" /* get base address of source array */
    "mov %1, %%rcx \n\t"

    "xor %%rbx, %%rbx \n\t" /* get base address of dest array */
    "mov %3, %%rbx \n\t"

    "xor %%r14, %%r14 \n\t" /* get base address of _pack_loopup array */
    "mov %7, %%r14 \n\t"

    "xor %%r9, %%r9 \n\t" /* L_PACK_LOOP Bounds Check ($0x10) */
    "mov $0x10, %%r9 \n\t" // init with decimal 16 -  4 bytes x 4 loops

    "xor %%r10, %%r10 \n\t" /* get base address of _pack_loop_array */
    "mov %6, %%r10 \n\t"

    // init logic constants

    "xor %%r13, %%r13 \n\t"
    "mov $0x1, %%r13 \n\t" // 1 value for k_min compare

Part 3 – Initial Loop Logic

The following block of code mainly just resets r8 and r15 for loop counting and addressing purposes.

Again, the point of this exercise is to use as many registers as possible. Part of this means we also need to carefully manage how and where registers are used.

Moving (copying of course) rax to r15 for example, means r15 points to important locations we need to index from, but can be incremented without fear of “breaking” the main index register, which for our code is rax. We’ll see this type of activity in a few other places as well.

The point being of course that we’re not hitting main memory, just registers.

".L_MAIN_LOOP:" // convert each value to float, push to xmm0

    // subroutine - created packed data from single loop

    "xor %%r8, %%r8 \n\t" // inner loop counter
    "mov $0x0, %%r8 \n\t"

    "xor %%r11, %%r11 \n\t"
    "xor %%r12, %%r12 \n\t"

    "xor %%r15, %%r15 \n\t"
    "mov %%rax, %%r15 \n\t" // PACK_INDEX

Part 4 – Converting Ints To Floats – Two methods

With the main loop initialisation done we’re now free to start processing data. We start by grabbing the current CMYK value from the source array and placing it into r11, then masking it to leave only the LO byte.

This sets us up for the next step, which is converting the int values into proper floats for the xmm registers. Let’s look at two ways of accomplishing this step:

Method 1 – Memory Dependent And Slightly Slower – A Lookup Table In Action
Per above, the first step in both methods is to move and mask the raw int value to r11. Crucially this number will always be between 0-255. We exploit this fact in the mov call where r14 is the base address of the _pack_lookup_table array we created in C++, and r11, (also always between 0 and 255), acts as the index.

This is a common optimization known as a lookup table. In essence, instead of converting ints to floats (at a cost of around 8 cycles per conversion on my machine), we instead use simple memory moves to place a pre-computer floating point bit-string value created via the _pack_lookup_table array.

This is an intellectually pleasing way to handle the conversion step but it comes with an unfortunate side-effect. The problem is x86_64 provides no instruction for moving r32 values directly into xmm registers. We can however, move memory values to xmm, only this presents another problem: In order for our lookup table to work we access main memory twice: once for the lookup table value, then once again to store the floating point bit string in an aligned __m128 memory location (which is later used as the argument to movaps). Such repeated memory access can be devastatingly slow, and when compared to just doing a relatively speedy direct conversion, becomes tough to justify.

All told, in my tests the lookup table code would be a touch faster than GCC’s output if it were not for these mov instructions. Without those institutions though, we’d have no lookup table!

".L_PACK_LOOP:"

    "nop \n\t"

    "mov (%%rcx, %%r15, 1), %%r11 \n\t" // get source array value

    "and $0x00000000000000ff, %%r11 \n\t" // mask unwanted bits

    // use lookup table to push pre-converted float val
    "mov (%%r14, %%r11, 4), %%r12 \n\t" // indexed value

    // this is slow!
    "mov %%r12, (%%r10, %%r8, 1) \n\t" // push to _pack_loop_array

    "add $0x1, %%r15 \n\t" // 1 pixel per loop iteration

    "add $0x4, %%r8 \n\t"

    "cmp %%r8, %%r9 \n\t"

    "jne .L_PACK_LOOP \n\t"

"xor %%r8, %%r8 \n\t" // clear r8 index for push to xmm

"movaps (%%r10, %%r8, 1), %%xmm0 \n\t" /* move packed values into mmx */

You’ll notice the last instruction sets our 128-bit xmm0 register with the value of the pack_loop_array.

All told this works, and again, is somewhat intellectually pleasing. The question is can this be made faster? The answer is yes it can, and the secret is to avoid memory access at all costs. Unfortunately, this means we must rid ourselves of the lookup table, as described in Method 2…

Method 2 – Using Hardware Conversion & Avoiding Memory Access
The second attempt at this logic turns out to be better in terms of performance, even though we ditch the lookup table.

The basic idea is instead of worrying about the conversion costs, we embrace them and use an unrolled conversion block where each value is simply run through CVTSI2SS, then shuffled to make room for the next value. It should be said that the unroll logic provided no discernible speed-up–the improvements come from fewer costly memory access steps.

// c

"add $0x2, %%r15 \n\t" // index for c value

"mov (%%rcx, %%r15, 1), %%r11 \n\t" // get source array value

"and $0x00000000000000ff, %%r11 \n\t" // mask unwanted bits

"CVTSI2SS %%r11, %%xmm0 \n\t"

"shufps $0xC4, %%xmm0, %%xmm0 \n\t" // flip #2 and #4 11000110

// m

"sub $0x1, %%r15 \n\t" // index for m value

"mov (%%rcx, %%r15, 1), %%r11 \n\t" // get source array value

"and $0x00000000000000ff, %%r11 \n\t" // mask unwanted bits

"CVTSI2SS %%r11, %%xmm0 \n\t"

"shufps $0xE1, %%xmm0, %%xmm0 \n\t" // flip last two to get m 11100001

// y

"sub $0x1, %%r15 \n\t" // index for y value

"mov (%%rcx, %%r15, 1), %%r11 \n\t" // get source array value

"and $0x00000000000000ff, %%r11 \n\t" // mask unwanted bits

"CVTSI2SS %%r11, %%xmm0 \n\t"

The big difference here is memory access is kept to a bare minimum. With this simple change my implementation runs around the same speed as GCC’s -02.

Part 5 – CMY Conversion Step 1

Now that we have a series of 4 floating point numbers in xmm0 (our packed data) we can begin the conversion process.

The code starts with what has to be one of the more satisfying parts of SSE coding. As we now have a 128-bit packed string we can divide and subtract our constant values from the working value in two easy calls to divps and subps. It’s getting a lot of work done in two quick instructions, which is always a good feeling!

Things gets a bit more interesting after that though. At this point we most likely have a series of negative numbers, something that doesn’t play well with the next step of the algorithm.

This is because we need to find the lowest value of bunch to create our k value, but when we have the possibility of negative numbers this task becomes impossible.

Thus, before we can advance we need to flip the 31st bit of each packed float to 0 so the value comparison is valid and we find the ‘true’ lowest value. Think of this as the assembly equivalent of an abs() call.

This is where our mask comes in. The idea of masking is simple enough, though unfortunately it becomes more of a chore when dealing with packed values.

The basic problem is their is no ‘default’ mask we can create that will safely mask only the 31st bit of the 4 packed values without also knowing which values in the packed string are already positive. This is because XOR will flip negative to positive, but also positive to negative. We don’t want that of course, we only want the former.

Thus, we first need to modify our mask (known as a selection mask), to ignore positive values so they aren’t accidentally converted to negative values.

To do so means we must copy our mask and working xmm0 value to new registers. We then call psrad against the xmm0 copy to create a selection mask where values that have the 31st bit set (meaning it’s negative), become all 1′s ($0xffffffff). When then logically AND this value with the default selection mask copy to turn the double-words with positive values back to 0.

This new, modified mask can now be safely xor‘d with the original value to only flip negatives to positives.

// perform cmy conversion

// divide by 255
"divps %%xmm14, %%xmm0 \n\t"

// subtract 1
"subps %%xmm15, %%xmm0 \n\t"

// mask back to positive values for min processing

// copy mask for modifier change into xmm5 (xmm4 is mask constant)
"movaps %%xmm4, %%xmm5 \n\t"

// copy raw value for min to xmm6
"movaps %%xmm0, %%xmm6 \n\t"

// create selection mask modifier
"psrad $0x31, %%xmm6 \n\t" // for every negative value, makes item all $0xffffffff

// modify mask copy (xmm5) to mask only negative values
"andps %%xmm6, %%xmm5 \n\t"

// now mask sign bits to 0 with modified mask
"xorps %%xmm5, %%xmm0 \n\t"

Part 6 – CMY Conversion – Find Min

Finding the minimum value in assembly is very similar in practise to the last section where we manipulate masks, only now we’re also shuffling values around too.

Granted we also had to shuffle values around in the SSE intrinsics version as well, but here we need to think a bit harder about our bit-masks, as we no longer have the benefit of using Intel’s handy _MM_SHUFFLE helper. This type of coding is, I can safely say, a bit more complex.

After we find the minimum value we call cmpeqps and then store the LO result in k_min_value, which as we can see from the first code block is a simple int we pass into the asm block as a memory value. This may seem like a wasted step, but if we look back a bit we can see that movss can only write to a memory location.

We then use this value in a cmp block and if ‘true’, perform a bit of extra processing on our image data.

// find min value
"movaps %%xmm0, %%xmm1 \n\t"
"shufps $0x4E, %%xmm0, %%xmm1 \n\t" // reorder values (mask first)

"minps %%xmm0, %%xmm1 \n\t" // find first min, put in xmm1

"movaps %%xmm1, %%xmm2 \n\t"
"shufps $0xB1, %%xmm1, %%xmm2 \n\t"

"minps %%xmm1, %%xmm2 \n\t" // min (k) in xmm2

// process min logic (is min value == 1? - true = cmpeqps creates mask of all 1's)
"movaps %%xmm15, %%xmm12 \n\t" // move 1's to xmm12
"cmpeqps %%xmm2, %%xmm12 \n\t" // mask now in xmm12

"movss %%xmm12, %8 \n\t" // move mask to memory value for cmp

"cmp %8, %%r13 \n\t" // is k == 1?

"jne .L_MULTIPLY_ALL \n\t" // anything but 1, skip this block

// save 1 - k value
"movaps %%xmm15, %%xmm13 \n\t" // xmm13 is temp storage for 1.0f
"subps %%xmm2, %%xmm13 \n\t" // 1-k in xmm13

// subtract k from all
"subps %%xmm2, %%xmm0 \n\t"

// c-k / 1-k
"divps %%xmm13, %%xmm0 \n\t"

".L_MULTIPLY_ALL:"

"mulps %%xmm14, %%xmm0 \n\t" // cmy * 255
"mulps %%xmm14, %%xmm2 \n\t" // k * 255

Part 7 – Export Values

With the conversion process done we can now write our values back to the destination buffer.

At this point the question becomes: how do we move these packed floats back into an unsigned char array?

This is a surprisingly serious question, as their is (strangely) no native machine instruction for doing so.

Thus, we need to be a bit creative. To that end, the general solution is we extract the LO double-word from the source vector converting it to a truncated int in the process. We then grab the LO byte of that value and store it in an indexed position in the destination buffer. Next we shuffle the vector to place a new value in the LO double-word and repeat the process. In the end we store each value back in turn as opposed to sending all back to main memory in one shot (which would be far better in terms of performance).

As far as the exact implementation in our code: to start, the first instruction is for performance reasons, in that when we call CVTTSS2SI to covert our float values to truncated ints, they come back as double-words, but we only want bytes. As there are no such instructions for this type of conversion, it becomes apparent their must be some way to get byte values back. Sure enough, CVTTSS2SI stores the LO byte of the conversion result into the destination register’s 8 bit ‘shadow’ register (which is to say, just the LO single byte of the full ecx register–this is not a ‘different’ register by any means).

Thus, in our code we push our index register rcx to r11 so it can be restored, because if we use rcx as the destination register for CVTTSS2SI, the LO byte value of the result is saved to the ‘shadow register’ cl, which is exactly the value we need (an unsigned int between 0 and 255). We must do this in rcx as r11 has no such 8 bit equivalent.

The next instruction is to push the main loop counter, rax, to r15. Again, it’s all about saving registers, which means because rax contains the same offset address as our other arrays, we can use that along with rbx to create our indexed address for the output array population step.

Of course this means we need to manipulate this register with the proper byte offset our values need to be pushed to, which is the reason for the add and sub calls.

We do this as the LittleCMS engine process our output buffer is created filled for expects CMYK byte order, but our xmm0 values are currently in YMCK. Instead of issuing shuffles we simply increment and decrement our r15 register with the appropriate byte offsets depending on which color we’re writing to the destination array. This is how we rearrange YMCK into CMYK, which is simple and effective.

// conversion done, export values

"mov %%rcx, %%r11 \n\t" // save rcx so we can convert dwords to words using cl

"mov %%rax, %%r15 \n\t" // pointer for insert values (r15)

// y - truncate and export values to array
"CVTTSS2SI %%xmm0, %%rcx \n\t" // y

"add $0x2, %%r15 \n\t" // add 2 for y value insert
"mov %%cl, (%%rbx, %%r15, 1) \n\t"

// m
"shufps $0xE1, %%xmm0, %%xmm0 \n\t" // flip last two to get m
"CVTTSS2SI %%xmm0, %%rcx \n\t" // m

"sub $0x1, %%r15 \n\t" // subtract 1 for m value insert
"mov %%cl, (%%rbx, %%r15, 1) \n\t"

// c
"shufps $0x4E, %%xmm0, %%xmm0 \n\t" // flip #2 and #4
"CVTTSS2SI %%xmm0, %%rcx \n\t" // c

"mov %%cl, (%%rbx, %%rax, 1) \n\t" // rax is base address, no need to sub

// k
"CVTTSS2SI %%xmm2, %%rcx \n\t" // m

"add $0x2, %%r15 \n\t" // add 3 for k value insert
"mov %%cl, (%%rbx, %%r15, 1) \n\t"

"mov %%r11, %%rcx \n\t" // restore rcx

Part 8 – Closing The Loop and __asm__ Logic

The closing assembly bits are simply to increment our loop counter.

The last part is of course the extended assembly closing bit where we set input, output, and clobbers.

    "addq $0x4, %%rax \n\t" // increment main loop counter
    "cmpq %%rdx, %%rax \n\t"

    "jne .L_MAIN_LOOP \n\t"

    : "=m" (cmyk_temp)  /* destination */
    : "m" (bits), "m" (count), "m" (cmyk_temp), "m" (m_1), "m" (m_255), "m" (_pack_loop_array), "m" (_pack_lookup_table), "m" (k_min_value), "m"(_mask_array) /* source */
    : "ebx", "ecx", "edx", "memory" /* clobbers */

); // asm

delete _pack_lookup_table;
delete _pack_loop_array;
delete _mask_array;

Performance Notes

One of the main reasons I was interested in pursuing this task was to see if I could write code that had some parity with GCC’s -02 output. In all I’m relatively happy, with performance generally being only a few hundred milliseconds slower over the course of 120 images:

== || Total Process Time Elapsed (milliseconds): 21228 SSE 2 (unrolled intrinsics)
== || Total Process Time Elapsed (milliseconds): 23252 Raw Assembly
== || Total Process Time Elapsed (milliseconds): 21344 Raw Assembly
== || Total Process Time Elapsed (milliseconds): 21125 SSE 1 (intrinsics)
== || Total Process Time Elapsed (milliseconds): 20747 SSE 2 (unrolled intrinsics)

As fun as creating this code was, the lesson here is if you can use intrinsics do it. There is simply no reason to slave over this type of coding if you can possibly avoid it, as in the end you’ll have a very hard time besting your compiler anyway. Yes you may get lucky every now and then, but my guess would be most of the time, not so much. Intrinsics rock, use em!

The one thing I would say though is there are some holes in the current intrinsic line-up which make raw assembly attractive. One glaring example is the inability to deal with packed values in a horizontal fashion. That is, it should be very simple to find the min of four packed floats using one intrinsic–but no such intrinsic exists. There are plans for one, but nothing as of yet.

It would also be nice to have a native machine instruction to perform packed sign flips. If we did the above code could be a touch shorter.

Finally, it has to be said this algorithm is really not the best for SSE optimizations. This is because at it’s heart the vectors we create are non-uniform which means we end up treating each vector as 4 separate values instead of a single block. Actually, this severely limits us in terms of performance gains, which is why we’ll see non-SSE versions of GCC’s -O2 come very close if not best the SSE versions.

The good news is the techniques covered in this tutorial are still valid. Just keep in mind not all data structures are well suited for SSE.

General hints

Along the way I tried to keep note of the various idiosyncrasies of this type of coding.

Of course the best piece of advice is to just see what your own assembler is doing in a debug session.

The problem with this approach however, is that unlike Intel syntax, GCC’s Gas syntax adds many rules and formatting requirements that are not present in raw assembly output. For example, you’ll notice that Gas requires that we end each line with \n\t.

With that said, here are a few hints:

CGG Reversed Syntax
Ha ha. But seriously, GCC (AT&T syntax) reverses the order of operands in specific ways, meaning many pieces of documentation you’ll read won’t work unless we first reverse them. It’s important to note it’s not just the operands in two operand instructions, but also 3 operand ones too.

A good example is this guy from my code:

shufps $0xe4,%xmm1,%xmm0

In Intel documentation it looks like:

SHUFPS xmm1, xmm2/m128, imm8

Thus, not only are operands reversed (source/destination), so too is the immediate value.

Using 64-bit? Use 64-bit Register Names
This one sounds obvious, but it can be easy to forget that this won’t work:

"mov %%r15, %%eax \n\t"

Whereas this will:

"mov %%r15, %%rax \n\t"

Conclusion

And that’s it, hopefully you’ve learned a bit more about assembly coding : )

If you have any questions, please post ‘em below!

Full Code Listing

__asm__ __volatile__(
    "movaps %5, %%xmm14 \n\t"
    "movaps %4, %%xmm15 \n\t"
    "xorps %%xmm4, %%xmm4 \n\t"
    "xor %%rax, %%rax \n\t"
    "xor %%r11, %%r11 \n\t"
    "mov $0x80000000, %%r11 \n\t"
    "mov %9, %%rbx \n\t"
    "mov %%r11,(%%rbx, %%rax, 1) \n\t"
    "add $0x4, %%rax \n\t"
    "mov %%r11,(%%rbx, %%rax, 1) \n\t"
    "add $0x4, %%rax \n\t"
    "mov %%r11,(%%rbx, %%rax, 1) \n\t"
    "add $0x4, %%rax \n\t"
    "mov %%r11,(%%rbx, %%rax, 1) \n\t"
    "movaps (%%rbx), %%xmm4 \n\t"
    "xor %%rax, %%rax \n\t"
    "xor %%rdx, %%rdx \n\t"
    "mov %2, %%edx \n\t"
    "xor %%rcx, %%rcx \n\t"
    "mov %1, %%rcx \n\t"
    "xor %%rbx, %%rbx \n\t"
    "mov %3, %%rbx \n\t"
    "xor %%r14, %%r14 \n\t"
    "mov %7, %%r14 \n\t"
    "xor %%r9, %%r9 \n\t"
    "mov $0x10, %%r9 \n\t"
    "xor %%r10, %%r10 \n\t"
    "mov %6, %%r10 \n\t"
    "xor %%r13, %%r13 \n\t"
    "mov $0x1, %%r13 \n\t"
    ".L_MAIN_LOOP:"
    "xor %%r8, %%r8 \n\t"
    "mov $0x0, %%r8 \n\t"
    "xor %%r11, %%r11 \n\t"
    "xor %%r12, %%r12 \n\t"
    "xor %%r15, %%r15 \n\t"
    "mov %%rax, %%r15 \n\t"
    ".L_PACK_LOOP:"
    "mov (%%rcx, %%r15, 1), %%r11 \n\t"
    "and $0x00000000000000ff, %%r11 \n\t"
    "mov (%%r14, %%r11, 4), %%r12 \n\t"
    "mov %%r12, (%%r10, %%r8, 1) \n\t"
    "add $0x1, %%r15 \n\t"
    "add $0x4, %%r8 \n\t"
    "cmp %%r8, %%r9 \n\t"
    "jne .L_PACK_LOOP \n\t"
    "xor %%r8, %%r8 \n\t"
    "movaps (%%r10, %%r8, 1), %%xmm0 \n\t"
    "divps %%xmm14, %%xmm0 \n\t"
    "subps %%xmm15, %%xmm0 \n\t"
    "movaps %%xmm4, %%xmm5 \n\t"
    "movaps %%xmm0, %%xmm6 \n\t"
    "psrad $0x31, %%xmm6 \n\t"
    "andps %%xmm6, %%xmm5 \n\t"
    "xorps %%xmm5, %%xmm0 \n\t"
    "movaps %%xmm0, %%xmm1 \n\t"
    "shufps $0x4E, %%xmm0, %%xmm1 \n\t"
    "minps %%xmm0, %%xmm1 \n\t"
    "movups %%xmm1, %%xmm2 \n\t"
    "shufps $0xB1, %%xmm1, %%xmm2 \n\t"
    "minps %%xmm1, %%xmm2 \n\t"
    "movaps %%xmm15, %%xmm12 \n\t"
    "cmpeqps %%xmm2, %%xmm12 \n\t"
    "movss %%xmm12, %8 \n\t"
    "cmp %8, %%r13 \n\t"
    "jne .L_MULTIPLY_ALL \n\t"
    "movaps %%xmm15, %%xmm13 \n\t"
    "subps %%xmm2, %%xmm13 \n\t"
    "subps %%xmm2, %%xmm0 \n\t"
    "divps %%xmm13, %%xmm0 \n\t"
    ".L_MULTIPLY_ALL:"
    "mulps %%xmm14, %%xmm0 \n\t"
    "mulps %%xmm14, %%xmm2 \n\t"
    "mov %%rcx, %%r11 \n\t"
    "mov %%rax, %%r15 \n\t"
    "CVTTSS2SI %%xmm0, %%rcx \n\t"
    "add $0x2, %%r15 \n\t"
    "mov %%cl, (%%rbx, %%r15, 1) \n\t"
    "shufps $0xE1, %%xmm0, %%xmm0 \n\t"
    "CVTTSS2SI %%xmm0, %%rcx \n\t"
    "sub $0x1, %%r15 \n\t"
    "mov %%cl, (%%rbx, %%r15, 1) \n\t"
    "shufps $0x4E, %%xmm0, %%xmm0 \n\t"
    "CVTTSS2SI %%xmm0, %%rcx \n\t"
    "mov %%cl, (%%rbx, %%rax, 1) \n\t"
    "CVTTSS2SI %%xmm2, %%rcx \n\t"
    "add $0x2, %%r15 \n\t"
    "mov %%cl, (%%rbx, %%r15, 1) \n\t"
    "mov %%r11, %%rcx \n\t"
    "addq $0x4, %%rax \n\t" // increment main loop counter
    "cmpq %%rdx, %%rax \n\t"
    "jne .L_MAIN_LOOP \n\t"

    : "=m" (cmyk_temp)  /* destination */
    : "m" (bits), "m" (count), "m" (cmyk_temp), "m" (m_1), "m" (m_255), "m" (_pack_loop_array), "m" (_pack_lookup_table), "m" (k_min_value), "m"(_mask_array) /* source */
    : "rax", "rbx", "rcx", "rdx", "r9", "r10", "r11", "r12", "r13", "r14", "r15", "memory" /* clobbers */

); // asm

In the previous post we wrote a short C++ program that loaded two numbers. Despite its simplicity in C++, we saw how the assembly version was comprised of several dozen individual instructions in a rather cryptic format. Much of this complexity stems from the fact that in our sample program we called a function to perform our addition. Calling functions means dealing with a stack, base pointers, and the setup and maintenance of that stack. It means dealing with memory offsets, relative positions, and several other factors. The good news is that at this point we can safely ignore these details. In fact, we will do well to ignore them and focus on just the core competencies of function implementation code. In other words, we’ll let gcc create the function shells, calls, and stack management, we’ll focus on the core logic.

The general idea is that we want to write assembly that adds two numbers together. There is a direct assembly instruction for doing so, add, and in this post we’ll implement it.

One of the key things to remember about writing assembly is that we’re dealing with very few abstractions. In C++:

Has a very specific meaning, but its true meaning to the machine it runs on is hidden. It’s only after gcc compiles the code that int, t, and 10 mean anything to the processor. In assembly we free ourselves from these abstractions and deal with the very direct process of moving bits around.

Thus, our first step in writing assembly to add two numbers is to realize that the add instruction we’ll be using expects two parameters, neither of which can be memory locations. They can however, be registers. Thus, our first steps in code must be to load two registers with the values we want to add.

To load a value into a register we use the mov instruction, which for us in AT&T syntax takes the form of:

This moves the immediate value (2) into the %rax register. Please keep in mind %rax is a 64-bit register, it would be %eax on 32-bit systems.

We then push our second number:

And finally, call the add instruction, passing in our two registers:

The whole function in extended assembly looks like:

Should we run this in our IDE, we would watch the rax and rcx register’s end up with 0×1 and 0×3, respectively.

Thing is, this is not a very useful construct, as immediate values means we’ve hard coded the return in by default. It’s much more realistic to accept parameters.

To do so, we take advantage of gcc extended syntax like so:

Will output:

While we now have plenty of control over implementation, it’s still a bit heavy on syntax. Thus, we can further optimize by letting gcc have full control over register assignment:

Here we let gcc decide which registers to use, which leads to slightly faster code generation, but we may lose the exacting control we need.

At this point we now have a functioning addition routine. Of course we already know it’s not the most efficient, as we could/should be using lea. This is because while our actual hand-written assembly is shorter, we still need to place values in registers and use the two-step addition instruction.