The trifecta of ARM, Assembly, and C

ARM needs no introduction to any modern-day embedded developer. Just to be shy in words ARM stands for Advance RISC Machine which develops Application Grade, Real-Time Grade, and eMbedded Grade processors designs. These designs are licensed by hardware designers for further utilization by the end user. In the design ARM also releases the Instruction Set Architecture (ISA). We would be discussing one such processor named ARM Cortex-A8 which uses ARMv7-A architecture.

The readable format of binary instructions executing on any compute-capable hardware is known as mnemonic. All the instructions we can execute on any hardware are usually given by the hardware manufacturers in a set referred to as the ‘Instruction set’ of that hardware. The programs written with these mnemonics are considered Assembly Programs and mnemonics are Assembly Instructions.

C is a language close to the heart of all low-level programming and the go-to language for embedded systems and OS design. The below Figure-1 highlights the trifecta and intermediate step for the execution of desired compute logic to dedicated hardware. C requires a compiler to convert the source to executable code. There are various compilers are available for C, However, we mostly will focus on GNU Compiler Collection or GCC. Also, if the targeted hardware (SoC/Embedded Chip – ARM/RISC based hardware) is different than the development machine (Laptop/PC – x86 based hardware) we would need a cross compiler. GCC-based cross-compilers are also available as freeware, usually provided by hardware vendors.

Why are we here?

In the world of expedited software delivery and fast-paced newer versions of hardware still, there is a chance that hardware of enhanced capacity may be available in the market tomorrow. However, all such hardware capacity is exposed to the user by compiler implementations or new libraries for that hardware. This capacity may not be available for users instantly or may have rigid implementations. In such extreme scenarios if we want to utilize the hardware feature we need to interact with the hardware on the base level i.e. Assembly Codes (mnemonics). We have a mechanism provided to us by GCC and ARM which helps developers in the interworking C and Assembly in various manners.

A detailed read on the syntax of GCC Asm can be found here. The basic info which is borrowed is it supports a more convenient format for integration with regular C variables and old style Assembly of code.

A simple example of multiline and inline assembly code in C. To be noted all the examples below are written for BeagleBone Black.

void main() {

asm volatile (
	"F1:\n\t"   // This is assembly equivalent Label - visible in disassembly
	"MOV v1, #10 \n\t" // Move 10 to v1 registers (R4)
	"MOV v2, #11 \n\t" // Move 10 to v1 registers (R5)
        "ADD v3, v2, v1 \n\t" // Add v1(R4) v2(R5) and store in v3(R6)
	); 
}

Below is the disassembly of the above program. Check the F1 label and how it helps in the identification of code blocks. This label can help one in debugging. We will be discussing this in the near future posts.

000103a0 <main>:
   103a0:	b480      	push	{r7}
   103a2:	af00      	add	r7, sp, #0

000103a4 <F1>:
   103a4:	f04f 040a 	mov.w	r4, #10
   103a8:	f04f 050b 	mov.w	r5, #11
   103ac:	eb05 0604 	add.w	r6, r5, r4
   103b0:	bf00      	nop
   103b2:	46bd      	mov	sp, r7
   103b4:	f85d 7b04 	ldr.w	r7, [sp], #4
   103b8:	4770      	bx	lr

A caution for assembly and C interworking – ARM defines restriction in the use of certain registers (here) and so does GCC (here). One restriction which was discovered by us experientially is R7 is used to maintain the stack and if we modify R7 or V4 this may lead to crashes in the program. This may vary on the compiler version and compiler vendor. The point here is if certain code is not behaving as expected, it’s better to examine the compiler optimizations/modifications introduced with C and Assembly interworking.

Upcoming Next: How pointers are handled in Assembly.