Reliable programming in ARM assembly language

Sometimes it's necessary to use both assembly and high-level programming languages when working in the ARM architecture. This paper from ARM TechCon explains why and how.

This article is from class ATC-150 at ARM Technology Conference. Click here for more information about the conference.

The ARM architecture, like most 32-bit architectures, is well-suited to a using a C or C++ compiler. The majority of control code is written using high-level programming languages like C and C++ instead of assembly language. There are good reasons for this. High-level programming languages are inherently safer and less error prone than programming in assembly. Code written in high-level programming languages can also be written to be portable across different architectures.

Some people use assembly language for writing device drivers, but this is usually unnecessary. Most device driver code can be written by mapping a C structure or a C++ class onto the hardware device. However, it is sometimes necessary to use a little bit of assembly code. This paper will describe how to best do this.

What is assembly
Assembly, or assembly code, is roughly used to refer to the instruction set that runs on the target processor. In reality, processors read a sequence of binary words that encode the instructions. Assembly is a step up from binary in that the instructions can be expressed in a human-readable form.

For example, consider a simple C function:

int add2(int a, int b)
{ 
    return a + b; 
} 

When compiled, this code will likely turn into something like the following assembly code:

    .text 
     .global add2
add2: 
    add r0, r0, r1
    bx lr
    .type add2, function
    .size add2, 8

When assembled, this assembly turns into the following two binary words:

    0xe0810000 
    0xe12fff1e 

An assembler is the tool that converts assembly code into binary. However, the assembler doesn't output binary directly. Instead, it encapsulates the binary into an ELF object file that is usable by a linker.

Unfortunately, on the ARM architecture there is no standard format for assembly language. The ARM tools use a unique syntax that, although expressive, does not resemble the format used by most assemblers. Most assemblers use a format similar to the UNIX and GNU assemblers. The remainder of this paper will use examples in the UNIX style of assembly for ARM.

Types of assembly
There are three primary ways to write assembly: intrinsic functions, inline assembly, and assembly files.

Intrinsic functions are functions that have a special meaning to the implementation. Many intrinsic functions are used to provide assembly functionality to the user.

Consider an operation that is not efficiently expressible in C. We will use the ARM CLZ instruction as such as example. This instruction returns the number of zeros starting from the most significant bit of the source.

To code this operation in C, it might look something like this:

static int count_leading_zeros(uint32_t src)
{
    for (int i = 31; i >= 0; i--) {
        if ((src & ((uint32_t)1 << i)) != 0) {
               return 31-i; 
        }
     }
     return 32; 
} 

Or it could be coded like this:

static int count_leading_zeros(uint32_t src)
{ 
    uint32_t bit = 0x80000000;
    int i = 0;
    while (bit != 0) {
         if ((src & bit) != 0) {
             break; 
         }
         i++; 
         bit >>= 1; 
     }
     return i;
}

This could be coded any number of different ways, and it's not clear which way is the most natural. It is probably a matter of personal preference. It is a cumbersome matter for the compiler to recognize just one of these forms. So, it would be nearly impossible to recognize all of the ways that a human might express the operation. As a result, it would be nearly impossible for the compiler to automatically identify opportunities to substitute the CLZ instruction for loops that are functionally equivalent unless a standard way of writing the loop was established.

Rather than documenting a standard way to write this loop, an elegant solution is to document an intrinsic function that the compiler will recognize and convert to the CLZ instruction. For example, a compiler might recognize:

int __CLZ32(uint32_t src);

as an intrinsic function corresponding to the ARM CLZ instruction. So, whenever the user calls __CLZ32(),rather than actually making a function call to some routine, the compiler will inline a CLZ instruction in place of the call.

An intrinsic function is known to the compiler, and the compiler can understand the form of the resulting assembly code. Semantically, this behaves as one of the above functions would, but the implementation is streamlined. An intrinsic function provides a natural and efficient interface to assembly instructions.

The second approach is inline assembly. One might write something like:

static int count_leading_zeros(uint32_t src)
{ 
    int ret;
    asm("CLZ ret, src");
    return ret;
}

To properly handle this, the compiler must understand a few things. For example, it must understand that this represents an instruction that has two operands. The first operand is a destination that is written by the instruction, the operand must be allocated to a register, and the operand should correspond to the "ret" variable. The second operation is a source that is read by the instruction, the operand must be allocated to a register, and the operand should correspond to the "src" parameter. This instruction does not read or write any other objects other than the operands. Such built-in knowledge can not be complete. There must be limits to the types of assembly that the compiler can safely recognize, but these limitations are hard to describe. May the user define a label in one instance of inline assembly and branch to it from another? Which temporary registers may the user modify? Must all input operands be in unique registers even if the values of these operands are the same?