how to write inline assembly codes about LOOP in Xcode LLVM?

Question

I'm studying about inline assembly. I want to write a simple routine in iPhone under Xcode 4 LLVM 3.0 Compiler. I succeed write basic inline assembly codes.

example :

int sub(int a, int b)
{
    int c;
    asm ("sub %0, %1, %2" : "=r" (c) : "r" (a), "r" (b));
    return c;
}

I found it in stackoverflow.com and it works very well. But, I don't know how to write code about LOOP.

I need to assembly codes like

void brighten(unsigned char* src, unsigned char* dst, int numPixels, int intensity)
{
    for(int i=0; i<numPixels; i++)
    {
        dst[i] = src[i] + intensity;
    }
}

Functions like this could also be implemented using OpenGL ES and a fragment shader. If this is applicable to your problem. That will give you parallelization "for free", similar to the usage of NEON as Matt suggested. — Arne, Dec 23 '11 at 11:20
Yeh you could definitely use OpenGL ES for sure. Depends a lot on what you're doing and if you want to pull that in as a dependency. — mattjgalloway, Dec 23 '11 at 12:25
OpenGL ES may not be fast enough if he needs to get the computed sum back to the CPU. The iPad GPU is not manufactured to perform this task efficiently. — Etan, Dec 23 '11 at 12:35

mattjgalloway · Answer 1 · 2011-12-23T12:21:29.477

Take a look here at the loop section - http://en.wikipedia.org/wiki/ARM_architecture

Basically you'll want something like:

void brighten(unsigned char* src, unsigned char* dst, int numPixels, int intensity) {
    asm volatile (
                  "\t mov r3, #0\n"
                  "Lloop:\n"
                  "\t cmp r3, %2\n"
                  "\t bge Lend\n"
                  "\t ldrb r4, [%0, r3]\n"
                  "\t add r4, r4, %3\n"
                  "\t strb r4, [%1, r3]\n"
                  "\t add r3, r3, #1\n"
                  "\t b Lloop\n"
                  "Lend:\n"
                 : "=r"(src), "=r"(dst), "=r"(numPixels), "=r"(intensity)
                 : "0"(src), "1"(dst), "2"(numPixels), "3"(intensity)
                 : "cc", "r3", "r4");
}

Update:

And here's that NEON version:

void brighten_neon(unsigned char* src, unsigned char* dst, int numPixels, int intensity) {
    asm volatile (
                  "\t mov r4, #0\n"
                  "\t vdup.8 d1, %3\n"
                  "Lloop2:\n"
                  "\t cmp r4, %2\n"
                  "\t bge Lend2\n"
                  "\t vld1.8 d0, [%0]!\n"
                  "\t vqadd.s8 d0, d0, d1\n"
                  "\t vst1.8 d0, [%1]!\n"
                  "\t add r4, r4, #8\n"
                  "\t b Lloop2\n"
                  "Lend2:\n"
                  : "=r"(src), "=r"(dst), "=r"(numPixels), "=r"(intensity)
                  : "0"(src), "1"(dst), "2"(numPixels), "3"(intensity)
                  : "cc", "r4", "d1", "d0");
}

So this NEON version will do 8 at a time. It does however not check that numPixels is divisible by 8 so you'd definitely want to do that otherwise things will go wrong! Anyway, it's just a start at showing you what can be done. Notice the same number of instructions, but action on eight pixels of data at once. Oh and it's got the saturation in there as well that I assume you would want.

these codes work very well! it was really helpful for my understanding. thanks very much for your advice~ — 이영보, Dec 27 '11 at 04:48

score -2 · Answer 2 · answered Dec 23 '11 at 10:45

Though this answer is not directly an answer to your question, it is more a general advice regarding use of assembler versus modern compilers.

You will generally have a hard time beating the compiler regarding optimazation of your C code. Of course by clever use of certain knowledge about how your data behave it's possible that you might tweak it just a few percents.

One of the reasons for this is that modern compilers use a number of techniques when dealing with code like the one you describe, e.g. loop unrolling, instruction reordering to avoid pipeline stalls and bubbles, etc.

If you really want to make that algorithm scream, you should consider redesigning the algorithm instead in C so you avoid the worst delays. For instance reading and writing to memory is expensive compared to register access.

One way of accomplishing this could be to have your code load 4 bytes at a time by using an unsigned long and then doing the math on this in registers before writing these 4 bytes back in one store operation.

So to recap, make your algorithm work smarter not harder.

Maybe he wants to do it as an exercise in learning though? Or wants to ensure that vector instructions from NEON are being used properly? It looks like he wants to do stuff with pixel data and that definitely benefits from some vector instructions. You can add and saturate 16 pixels at a time if you want, for instance. — mattjgalloway, Dec 23 '11 at 11:26
Especially on ARM, compilers are not yet at the level you imagine. SIMD instructions as well as bit field operations are optimized poorly and you can get big speedups by coding them directly in ARM. Note however that the AppStore only accepts apps which use only documented APIs. Not sure about how inline assembler affects AppStore eligibility. — Etan, Dec 23 '11 at 12:38
Inline assembly in no way affects App Store eligibility. That is not using an undocumented API. Inline assembly is a function of the compiler/assembler so it's nothing to do with the frameworks' APIs. — mattjgalloway, Dec 29 '11 at 10:20

how to write inline assembly codes about LOOP in Xcode LLVM?

2 Answers2

Linked