Two important aspects of the code compilation  phase in embedded program development are register allocation and schedule.

Given a block of code, we want to choose assignments of variables (both declared and temporary) to registers to minimize the total number of required registers. Example 5-5 illustrates the importance of proper register allocation.

Example 5-5 Register Allocation
To keep the example small, we assume that we can use only four of the ARM's registers. In fact, such a restriction is not unthinkable - programming conventions can reserve certain registers for special purposes and significantly reduce the number of general-purpose registers available.

Consider the following C code:
w = a + b; /* statement 1 */
x = c + w; /* statement 2 */
y = c + d; /* statement 3 */

A naive register allocation, assigning each variable to a separate register, would require seven registers for the seven variables in the above code. However, we can do much better by reusing a register once the value stored in the register is no longer needed.

To understand how to do this, we can draw a lifetime graph that shows the statements on which each statement is used. Appearing below is a lifetime graph in which the x axis is the statement number in the C code and the y axis shows the variables.

A horizontal line stretches from the first statement where the variable is used to the last use of the variable; a variable is said to be live during this interval. At each statement, we can determine every variable currently in use. The maximum number of variables in use at any statement determines the maximum number of registers required.

In this case, statement two requires three registers: c, w, and x. This fits within the four registers limitation. By reusing registers once their current values are no longer needed, we can write code that requires no more than four registers. Appearing below is one register assignment.

 a r0
 b r1
 c r2
 d r0
 w r3
 x r0
 y r3

The ARM assembly code that uses the above register assignment follows:

If a section of code requires more registers than are available, we must spill some of the values out to memory temporarily. After computing some values, we write the values to temporary memory locations, reuse those registers in other computations, and then reread the old values from the temporary locations to resume work.

Spilling registers is problematic in several respects. For example, it requires extra CPU time and uses up both instruction and data memory. Putting effort into register allocation to avoid unnecessary register spills is worth your time.

We can solve register allocation problems by building a conflict graph and solving a graph coloring problem. As shown in Figure 5-19 below, each variable in the high-level language code is represented by a node. An edge is added between two nodes if they are both live at the same time.

The graph coloring problem is to use the smallest number of distinct colors to color all the nodes such that no two nodes are directly connected by an edge of the same color. The figure shows a satisfying coloring that uses three colors. Graph coloring is NP-complete, but there are efficient heuristic algorithms that can give good results on typical register allocation problems.

Figure 5-19. Using graph coloring to solve the problem of Example 5-5.

Lifetime analysis assumes that we have already determined the order in which we will evaluate operations. In many cases, we have freedom in the order in which we do things. Consider the following expression:

(a + b) * (c - d)

We have to do the multiplication last, but we can do either the addition or the subtraction first. Different orders of loads, stores, and arithmetic operations may also result in different execution times on pipelined machines.

If we can keep values in registers without having to reread them from main memory, we can save execution time and reduce code size as well. Example 5-6 illustrates how proper operator scheduling can improve register allocation.

Example 5-6.Operator Scheduling for Register Allocation
Here is sample C code fragment:

w = a + b; /* statement 1 */
x = c + d; /* statement 2 */
y = x + e; /* statement 3 */
z = a ' b; /* statement 4 */

If we compile the statements in the order in which they were written, we get the register graph below.

Since w is needed until the last statement, we need five registers at statement 3, even though only three registers are needed for the statement at line 3. If we swap statements 3 and 4 (renumbering them)we reduce our requirements to three registers. The modified C code follows:

 w = a + b; /* statement 1 */
 w = a - b; /* statement 2' */
 w = c + d; /* statement 3' */
 w = x + e; /* statement 4' */

The lifetime graph for the new code appears below.

Compare the ARM assembly code for the two code fragments. We have written both assuming that we have only four free registers. In the before version, we do not have to write out any values, but we must read a and b twice. The after version allows us to retain all values in registers as long as we need them.

 Before version After version

 LDR r0,a LDR r0,a 
 LDR r1,b LDR r1,b 
 ADD r2,r0,r1 ADD r2,r1,r0 
 STR r2,w ; w = a + b STR r2,w ; w = a + b 
 LDRr r0,c SUB r2,r0,r1 
 LDR r1,d STR r2,z ; z = a ' b 
 ADD r2,r0,r1 LDR r0,c 
 STR r2,x ; x = c + d LDR r1,d 
 LDR r1,e ADD r2,r1,r0 
 ADD r0,r1,r2 STR r2,x ; x = c + d 
 STR r0,y ; y = x + e LDR r1,e 
 LDR r0,a ; reload a ADD r0,r1,r2 
 LDR r1,b ; reload b STR r0,y ; y = x + e 
 SUB r2,r1,r0 
 STR r2,z ; z = a " b

Scheduling
We have some freedom to choose the order in which operations will be performed. We can use this to our advantage—for example, we may be able to improve the register allocation by changing the order in which operations are performed, thereby changing the lifetimes of the variables.

We can solve scheduling problems by keeping track of resource utilization over time. We do not have to know the exact microarchitecture of the CPU - all we have to know is that, for example, instruction types 1 and 2 both use resource A while instruction types 3 and 4 use resource B.

CPU manufacturers generally disclose enough information about the microarchitecture to allow us to schedule instructions even when they do not provide a detailed description of the CPU's internals.

We can keep track of CPU resources during instruction scheduling using a reservation table. As illustrated in Figure 5-20 below, rows in the table represent instruction execution time slots and columns represent resources that must be scheduled.

Before scheduling an instruction to be executed at a particular time, we check the reservation table to determine whether all resources needed by the instruction are available at that time.

Upon scheduling the instruction, we update the table to note all resources used by that instruction. Various algorithms can be used for the scheduling itself, depending on the types of resources and instructions involved, but the reservation table provides a good summary of the state of an instruction scheduling problem in progress.

We can also schedule instructions to maximize performance. When an instruction that takes more cycles than normal to finish is in the pipeline, pipeline bubbles appear that reduce performance. Software pipelining is a technique for reordering instructions across several loop iterations to reduce pipeline bubbles. Software pipelining is illustrated in Example 5-7.

Figure 5-20. A reservation table for instruction scheduling.

Example 5-7 Software Pipelining in SHARC
Software pipelining can be illustrated with a small loop on the SHARC. Consider the following simple loop for a dot product computation:

 for (i = 0; i < N; i++) 
 sum += a[i] * b[i];

The SHARC can perform several operations in parallel. However, we can't perform the necessary loads and arithmetic operations on the same cycle.

Assume that we want to rewrite the loop so that we perform two loads, an addition, and a multiplication in one iteration. However, because the result of one operation depends on others, we can't do all these operations for the same iteration at the same time. Instead, the loop body will perform operations from the following three different iterations:

1. The two fetches of the array elements are performed for availability in the next cycle.
2. The multiplication a[i]*b[i] is performed on the operands fetched by the previous loop iteration.
3. The addition into the dot product running sum is performed using the result of the multiplication performed in the previous loop iteration.

When we rewrite the loop, we need to generate special header and trailer code that takes care of the first and last iterations that cannot be pipelined. The C code below is designed to show which operations can be performed in parallel on the SHARC.

In this code, none of the operations in the loop body depend on each other - remember that the p in p = ai*bi is writing a different value than is being used by sum += p, so they can operate in parallel. This allows all the operations to be performed in a single SHARC instruction that performs two data reads, a multiply, and an addition.

Instruction Selection
Selecting the instructions to use to implement each operation is not trivial. There may be several different instructions that can be used to accomplish the same goal, but they may have different execution times. Moreover, using one instruction for one part of the program may affect the instructions that can be used in adjacent code. Although we can't discuss all the problems and methods for code generation here, a little bit of knowledge helps us envision what the compiler is doing.

One useful technique for generating code is template matching, illustrated in Figure 5-21 below. We have a DAG that represents the expression for which we want to generate code. In order to be able to match up instructions and operations, we represent instructions using the same DAG representation. We shaded the instruction template nodes to distinguish them from code nodes.

Each node has a cost, which may be simply the execution time of the instruction or may include factors for size, power consumption, and so on. In this case, we have shown that each instruction takes the same amount of time, and thus all have a cost of 1. Our goal is to cover all nodes in the code DAG with instruction DAGs - until we have covered the code DAG we haven't generated code for all the operations in the expression.

In this case, the lowest-cost covering uses the multiply-add instruction to cover both nodes. If we first tried to cover the bottom node with the multiply instruction, we would find ourselves blocked from using the multiply-add instruction. Dynamic programming can be used to efficiently find the lowest-cost covering of trees, and heuristics can extend the technique to DAGs.

Figure 5-21. Code generation by template matching.

Understanding and Using Your Compiler
Clearly, the compiler can vastly transform your program during the creation of assembly language. But compilers are also substantially different in terms of the optimizations they perform. Understanding your compiler can help you get the best code out of it.

Studying the assembly language output of the compiler is a good way to learn about what the compiler does. Some compilers will annotate sections of code to help you make the correspondence between the source and assembler output. Starting with small examples that exercise only a few types of state-ments will help.

You can experiment with different optimization levels (the -O flag on most C compilers). You can also try writing the same algorithm in several ways to see how the compiler's output changes. If you can't get your compiler to generate the code you want, you may need to write your own assembly language. You can do this by writing it from scratch or modifying the output of the compiler.

If you write your own assembly code, you must ensure that it conforms to all compiler conventions, such as procedure call linkage. If you modify the compiler output, you should be sure that you have the algorithm right before you start writing code so that you don't have to repeatedly edit the compiler's assembly language output. You also need to clearly document the fact that the high-level language source is, in fact, not the code used in the system.

Figure 5-22. Structure of a program interpretation system

Interpreters and JIT Compilers
Programs are not always compiled and then separately executed. In some cases, it may make sense to translate the program into instructions during execution. Two well-known techniques for on-the-fly translation are interpretation and just-in-time (JIT) compilation. The trade-offs for both techniques are similar. Interpretation or JIT compilation adds overhead - both time and memory - to execution.

However, that overhead may be more than made up for in some circumstances. For example, if only parts of the program are executed over some period of time, interpretation or JIT compilation may save memory, even taking overhead into account. Interpretation and JIT compilation also provide added security when programs arrive over the network.

An interpreter translates program statements one at a time. The program may be expressed in a high-level language, with Forth being a prime example of an embedded language that is interpreted. An interpreter may also interpret instructions in some abstract machine language.

As illustrated in Figure 5-22 above, the interpreter sits between the program and the machine. It translates one statement of the program at a time. The interpreter may or may not generate an explicit piece of code to represent the statement.

Because the interpreter translates only a very small piece of the program at any given time, a small amount of memory is used to hold intermediate representations of the program. In many cases, a Forth program plus the Forth interpreter are smaller than the equivalent native machine code.

JIT compilers have been used for many years, but are best known today for their use in Java environments. A JIT compiler is somewhere between an interpreter and a stand-alone compiler.

A JIT compiler produces executable code segments for pieces of the program. However, it compiles a section of the program (such as a function) only when it knows it will be executed. Unlike an interpreter, it saves the compiled version of the code so that the code does not have to be retranslated the next time it is executed.

A JIT compiler saves some execution time overhead relative to an interpreter because it does not translate the same piece of code multiple times, but it also uses more memory for the intermediate representation. The JIT compiler usually generates machine code directly rather than building intermediate program representation data structures such as the CDFG. A JIT compiler also usually performs only simple optimizations as compared to a stand-alone compiler.

Next in Part 6, Analysis and optimization of execution time.
To read Part 1, go to "Program design and analysis."
To read Part 2 , go to " Models of program, assemblers and linkers."
To read Part 3, go to "Basic Compilation Techniques"
To read Part 4, go to "The creation of procedures"

Used with the permission of the publisher, Newnes/Elsevier, this series of six articles is based on copyrighted material from "Computers as Components: Principles of Embedded Computer System Design" by Wayne Wolf. The book can be purchased on line.

Wayne Wolf  is currently the Georgia Research Alliance Eminent Scholar holding the Rhesa "Ray" S. Farmer, Jr., Distinguished Chair in Embedded Computer Systems at Georgia Tech's School of Electrical and Computer Engineering (ECE). Previously a professor of electrical engineering at Princeton University, he worked at AT&T Bell Laboratories. He has served as editor in chief of the ACM Transactions on Embedded Computing and of Design Automation for Embedded Systems.