CS6397: Synthesis and Optimization of High-Performance Systems
The University of Texas at Dallas
Table of Contents
1 Introduction 3
2 Designing an Embedded System 4
3 Designing Compilers 7
4 Compilers Optimization Techniques for Embedded Systems 8
5 Retargetable Compilers 12
6 Features to be supported by compilers in Programming Language 14
7 Conclusion 18
8 References 18
A Compiler is a piece of software that performs translation from the source language to the target language . In most cases, the source language is the high-level language like C and the target language is the machine dependent executable binaries. An Embedded System is a specialized computer system which is dedicated to a specific task. It is combination of computer hardware and software, and or other parts, designed to perform a dedicated function. An embedded system is often subject to real-time constraints including timing, size, weight, power consumption, reliability, and cost [2, 10]. Most software for embedded systems is written in C. Compilers help programmers use high level constructs without performance loss. Compilers also help applications fully utilize architectural features. Since most embedded processors and architectures support features like pipelining and instruction level parallelism , it is the task of the compiler to fully use the architectural features to generate efficient code. Superscalar architectures are common and in processors based on the VLIW architecture up to eight instructions can be executed in parallel. Many DSP’s support special addressing modes like auto-increment, auto-decrement and special MAC (multiply-accumulate) instructions. Moreover, there are a variety of embedded processors designed to target different application areas and in most embedded systems, the instruction set differs between architectures.
This paper will discuss the importance of good compilers for embedded systems, the various high level and low level optimizations that are performed by compilers, the characteristics  and features supported by a good compiler and how compilers generate retargetable code.
2Designing an Embedded System
Embedded Systems design use hardware/software co-design which focuses on the efficient design and development of high quality hardware and software for embedded systems. In co-design, designers consider trade-off in the way hardware and software components of a system work together to achieve a specified task [10, 11]. The process of designing a good Embedded System can be broadly classified into the following 3 tasks.
Designing a good software system
Designing a good hardware system
Integrating the hardware and software systems
2.1Good Software Design
Figure 1: Designing good software The process of embedded software development  has matured over the years and good quality software can be developed using one of the many software engineering practices. For example, if designing software using object oriented methodology, the rational unified process  can be used for software development. The embedded software development process includes requirements engineering, analysis, high level and low level design. Once we have the design for the software, implementation can be done easily. Even large software projects can be developed using this well understood methodology to create good software. The process is mature enough that good software performance can be ensured for even software for complex and mission critical applications [Figure 1: Designing good software].
2.2Good Hardware Design
The process of designing good hardware is conceptually similar to designing good software . This also involves requirements engineering, analysis design and then development. A high level language like VHDL  is normally used for simulation and synthesis before generating the actual hardware. This process is also mature and even complex systems have been designed using this well understood process. The process is mature enough that most embedded systems are specialized processors and have special architecture to support the diverse needs of the application [Figure 2: Designing good hardware].
Figure 2: Designing good hardware
2.3System Integration - Compiler Bottleneck
Once efficient hardware and software has been designed, system integrators perform system integration to develop production quality systems. Given the software in a high level language like C, and a well designed hardware supporting features like pipelining and instruction level parallelism, the compiler converts the high level specification into high performance machine code. If the compiler is not good, then it will not be able to convert the input high-level code into efficient machine code. Hence, all the hard work spent in the design of hardware and software is wasted because of the inability of the compiler to efficiently convert the source code into target machine code . So, the design of efficient compilers is an indispensable part of the design of any software based system [Figure 3: Bad Compiler].
Figure 3: Bad Compiler Designing good compilers is very important in the case of embedded systems, since they are real time systems with strict performance deadlines. For example, a pace maker controlled by an embedded system cannot skip a heart beat! The development of good compilers is important to realize the characteristics of the hardware. As already mentioned, there are many embedded processors and architectures customized for specific embedded application. The instruction set for these processors differ and it complicates code generation in compilers.
Figure 4: Good Compiler
Hand-coded assembly code will probably have better performance than any assembly code generated by a compiler from a high level specification. To boost designer productivity and reduce time to market for new embedded systems, a transition from assembly to C must take place in the development of embedded software. This also means that the problems of compiler unavailability for new architectures and also poor code quality must be solved. Architecture-Compiler co-design is essential for high performance systems .
The design of compilers can be divided into two parts namely the design of front end and design of the back end . The front end of the compiler includes the lexical, syntactic and semantic analyzer. The front end of the compiler generates machine independent intermediate code (like three-address code). The design of a front-end of a compiler is fairly standard and most of it is automated. For example, in UNIX based environments, lex automates the process of lexical analysis and yacc automates the process of syntactic analysis. The back end of the compiler takes the machine independent intermediate code generated by the compiler and converts it into machine dependent assembly code or executable code.
The problem that most compilers for embedded systems face is efficient code generation. If the design of compiler back end for embedded system uses the traditional code generation techniques, the resulting code quality may be unacceptable . The process is complicated by the presence of many processor architectures with varied instruction sets. The common processor classes in embedded systems are Microcontrollers, RISC processors, DSP Processors, Multimedia Processors, Application Specific Processors .
4Compilers Optimization Techniques for Embedded Systems
Unlike traditional compilers, compilers for embedded systems have a lot more constraints that make it challenging to develop them. Compiler creation for traditional environments is reaching a stage of maturity after years of optimization and enhancements. Compiler creation for embedded systems, on the other hand, is still in its infancy and there are many research areas open for optimization. Constraints on embedded system applications like low power, low memory availability make optimization techniques all the more important.
Embedded systems have the flexibility of having custom defined memory architectures. Embedded system applications are special purpose and highly specific to a specific architecture. This is advantageous from compiler viewpoint because a high degree of memory optimizations can be obtained for specific memory architecture and specific application.
Optimization techniques for compilers can be broadly classified into two categories. Source level optimizations are those that can be done at a higher level without bothering about the hardware architecture being used. Assembly level optimizations are those that are platform dependent and make use of specific features of system architecture.
Optimization at this level can be easily visualized and they can be relatively easily exploited than at a platform dependent level. Also, optimization techniques at this level hold good for all possible embedded system architectures. The concept of code generation for embedded system is that by using time-intensive optimization techniques, it is possible to create very well optimized code than what traditional compilers create. This is made possible because the applications are special purpose and it is possible to exploit the uniqueness of the application. Listed below are some optimization strategies that are considered quite effective.
Loop transformations  are one of the most successfully researched optimization techniques at the source level. Several techniques  such as loop interchange, loop unrolling, loop fusion, software pre-fetching, loop tiling can be used to increase the parallelism in the program which can be effectively used in software and hardware pipelines.
Loop interchange is exchanging an inner loop with an outer loop; Loop fusion combines multiple, unrelated loops into a single loop; loop unrolling expands a loop with proper prologue and epilogue to increase parallelism in the code;
4.1.2Code rewriting technique for data reuse
Apart from loop transformations, another level at which optimized reuse of data can be achieved is by explicitly adding copies of the data in the source code. Even without knowing the memory hierarchy of the embedded system, copies can be made of loop values and stored in buffers to be conveniently used by inner loops. This compile-time approach to data reuse has not been much explored and there is no known formal way to obtain optimization by explicit copying of data. But such a technique can yield a high increase in performance due to high availability of data.
4.1.3Code size minimization techniques
Memory space in an embedded system is a scarce resource and it has to be cautiously used both for storing instructions and for data storage. Traditional compilers favor performance by sacrificing memory requirements. But this approach is not suitable for an embedded system environment. Memory is as important a criterion as performance. There is ongoing research in this area and some techniques that are analyzed are packing data more efficiently, optimized address computation, code size reduction and code compression.
Memory related issues have the potential to become a bottleneck for embedded system application development and there is increasing research interest in this area.
4.1.4Dynamic Memory Allocation
The use of memory allocation and de-allocation function calls in the source code can be logically mapped to the hardware language by extracting the semantic sense from such allocations and de-allocations. If the size of memory to be allocated is a compile-time constant, it is possible to obtain optimization by pre-allocating available memory in bigger chunks if possible.
Also, the use of a virtual memory manager and informing the manager when memory is allocated and de-allocated can help speedup the process of garbage collection and, hence, efficient usage of memory.
4.1.5Coarse grain transformations
Coarse grain transformation is the concept of performing source-to-source transformations for the purpose of increasing parallelism in multi-processor systems . The initial idea was migrating multi-processor optimization techniques for traditional systems to embedded systems. But they were heavily oriented towards performance enhancements and not optimized memory usage or optimized use of processor power. Recent research specifically aimed for coarse grain transformation for embedded systems involves task and data parallelism techniques for power reduction.
Function inlining  is the technique of replacing function call with the actual body of the function. This reduces the overhead of a function call and is widely used. One ill-effect of using this scheme is that it can lead to an increase in the code size which can act as a detrimental factor with respect to memory use. There is always a trade-off between memory use and performance increase. With proper analysis of the code growth estimation, an optimal level of function inlining can be achieved.
The application of source level optimization techniques can lead to an increase in the use of data elements. But care has to be taken such that the lifetime of these data elements are not increased more than is necessary. While designing the memory architecture for an embedded system, memory estimation is done based on the total number of data elements being used in the application. But this is a coarse estimate and is not a practical one. It is possible that not all data elements are needed to be alive at the same time and also, definitely, not all parts of a data array might be needed at the same time. If the data elements are scheduled such that there is minimal overlap in their time-of-life, estimation of the memory space can give a more accurate and smaller estimate.
This is a different level at which optimization can be achieved in embedded systems. The techniques used here describe ways in which the uniqueness of the system architecture can be exploited to achieve optimization. Knowledge about features of the architecture such as the number of memory banks, the hierarchy of memory banks, and the number of processors available can be used for optimization purposes.
4.2.1Memory Allocation Strategies
Memory allocation is one area in embedded systems where optimization can be achieved by proper analysis of the application. One such memory allocation problem is assigning variable values to registers. Graph coloring can be used to solve this problem. The register allocation problem can be converted into a graph-coloring problem by assigning a node for each variable that needs a register and having edges between the nodes that overlap in their lifetime, i.e., they cannot be assigned the same register at a given time. Graph coloring problem deals with assigning a color to each of the nodes in a graph such that adjacent nodes (which are connected by edges) do not have the same color. This problem is NP complete but a modification of the problem is solvable in polynomial time.
4.2.2Memory access optimization
Many DSPs use two banks of memory called X and Y which can be accessed in parallel . Naïve compiles use only one bank at a time or leave the choice of address allocation to the user to exploit parallelism. Advanced approaches include partitioning the data elements based on pre-scheduled assembly code. Having an in-depth knowledge of the memory hierarchy, instruction scheduling can be modified to use the full functionality of the memory structure. This can reduce the frequency of pipeline stalling and improve performance by as much as 25% .
4.2.3Address code optimization
Another area where maximal optimization can be obtained is at the address code generation stage. Several schemes like auto-increment, auto-decrement, XOR matching loops are being used for this purpose. Such schemes have been effective enough that commercial compilers use them.
Auto-increment and auto-decrement strategies  can be used where contiguous memory is available. In this scheme, the address of the next data element is obtained by just incrementing or decrementing a constant value from the previously accessed memory location. Another scheme that can be used in multiple loop lookup is the XOR matching loop scheme . If it is possible to assign addresses to two sets of loop-data-elements such that they are XOR compliments of each other, they can be accessed by XORing the address of one loop-data-element address.
DSPs and other VLIW-like processors have limited instruction-level parallelism . Hence scheduling algorithms that extract low-level parallelism without increasing the code size are critical. Global algorithms that increase parallelism by working on entire functions can be used in embedded systems but in the case of DSPs, such schemes might not be efficient because of the restriction on the amount of instruction-level parallelism that can be had.
4.2.5Task and Data Parallelism
There are two different styles of achieving parallelism in multi-processor embedded systems. One is task parallelism  where each processor is assigned a different part of the application task. The other is data parallelism  where each processor is assigned the same part of the task but with different part of the data. This is especially useful in processor-intensive loops where different processors can do the processing separately and the results can be merged at the end. This is similar to the concept of distributed programming.
In embedded system design where the application design drives hardware design, mapping logical memory to physical memory involves the issue of memory packing . Choosing proper types and number of physical memory component for the logical memory requirements has been researched with the constraints of total access delay, area and power dissipation.
In contexts like FPGA where the number and layout of the physical memory is fixed, scheduling logical memory to these physical memory components constitutes to the memory-packing problem. In such cases, multiple logical memories can be mapped to one physical memory using multiplexing which can improve access time performance.
Conventional memory in the case of embedded systems is typically DRAM that is not a part off the System-On-Chip (SOC) design. The memory unit is outside the SOC. This results in longer access time that is compensated by the use of embedded cache. Scratch pad  memory refers to the use of memory (SRAM) embedded in the chip. This memory is connected to the common bus but it uses a disjoint address space. The use of scratch pad demands more research into deciding which part of the data is deemed critical and can be put in the scratch pad.
The motivation in the area of retargetable compilers is the need to support quick and cost effective design of compilers for new processors and hence support new architecture exploration . Retargetable compilers can be changed to generate code for different target processors with few changes in the compiler. A retargetable compiler reads as an additional input the target architecture description and reconfigures itself to generate code for the current target machine. Retargetable compilers are cross-compilers. With retargetability, once a good compiler has been designed and developed, efficient code can be generated for all the possible target processors in embedded systems. Thus, it is kind of reuse of the compiler technology across the diverse platforms and architectures. A complete compiler in the loop process also requires assemblers, linkers, simulators, and debuggers .
Retargetable code generation is classified mainly into two categories. They are
Interpretive Code Generation
Pattern Matched Code Generation
5.1Interpretive Code Generation
In interpretative code generation, code is generated to a virtual machine and then the generated code for the virtual machine is interpreted by an interpreter. This is similar to how platform independence is achieved in Java  like languages. In the case of Java for example, the source code is compiled into platform independent byte code and then this byte code is interpreted by a platform dependent interpreter. That is there is an interpreter for each platform which is able to interpret the generated byte code. Such schemes use code generation languages which describe the code generation process . As mentioned in  this scheme has some limitations.
The limitations are
Since it is very hard to imagine and anticipate many machine organizations in one virtual machine, architectures have their own virtual machine.
Code generation languages are closely tied to the target architecture and so cannot be considered fully portable.
5.2Pattern Matched Code Generation
Pattern matched code generation approaches separate the machine description from the code generation algorithm. As stated in , code generation algorithms for ensuring portability has concentrated on separating the machine description from algorithm for generating code. The advantage of such an approach is that we could possibly use one code generation algorithm for use in a variety of different machines. Unlike interpretive code generation where we interpret the intermediate code, in this case, we use pattern matching.
The machine characteristics of the target architecture are encoded in a pattern tree. The output of the front end of the compiler is an intermediate representation in the form of a parse tree . The code generation algorithm basically is a tree traverser that takes the parse tree as input and stores tokens till a match is found with the pattern tree. To use the code generation scheme to a different target machine, a new pattern tree is generated which represents the new machine architecture.
There is another approach called table driven code generation approaches. These approaches are similar to that of pattern matched approaches but the difference being that these are automated enhancements of the pattern matched approaches.
There are some limitations in following this approach . They are,
It is not easy and sometimes impossible to create a tree structure depicting all the potential type of instruction patterns.
There may be cases in which no pattern in the pattern tree will match the structure of the parse tree.
If there are many instructions which can be used to perform the same action, then the choice of which instruction to use gets complicated.
6Features to be supported by compilers in Programming Language
There are various features ds to look for when selecting a compiler for an embedded system. These include the most important
6.1Packed Bitmap Support
One of the most important frequent uses of the embedded system is to access the embedded system registers. To do this accessing efficiently we need packed bitmap support . Packed Bitmap allows the program to directly map the memory mapped registers to C-data structures enabling fast access of the variables to the programs. This is a special requirement because most of the compilers by default align each variable in a structure to 32 bits. The packed data structure instead of aligning as 32 bits aligns them right next to each other. Thus any control register can be represented as control registers so that they can be copied directly to C data structure. The following illustration explains the packed bitmap technique. Consider a C program
unsigned int bit_field_1:10;
unsigned int bit_field_2:24;
unsigned int bit_field_3:14;
typedef struct bit_fields bit_fields;
int main ( )
printf ( “Size of unsigned int : %d\n”,
sizeof ( unsigned int ) );
printf ( “Size of bit_field structure : %d\n”,
sizeof ( bit_fields ) );
When this program is compiled with a compiler without packed bit-fields support then the output generated will be 12. This is due to the fact the structure defined will be represented in memory as follows:
Using packed bit-fields support the output generated will be 8. This is due to the fact the structure defined will be represented as follows:
6.2Special Assembly Language Support
Most of the projects require the important portion of the assembly language to be rewritten to make it more efficient than the generated code. This requires the functions represented in high level language such as C to be rewritten using assembly language. Since this provision is not in the standard “C”. Few additional non-standard C language features have to be added for embedded system programming. Though this is not in compliance to the standard, this is very important deciding factor because this represents the efficiency of the final product.
The overhead of adding this feature should be handled efficiently in the compiler so that the usage from the program is very easy. The overheads include the way to convert function arguments to low level assembly registers and then convert low level assembly registers to the return value of the function. This can be done by a feature where the compiler will take care of this conversion and the user can represent the variables in high level language.
The following is a snippet  which is used to access an I/O port in 80x86 processor:
#define LED_PORT 0xFF5E
mov dx, LED_PORT /* Load the address of the register. */
in al, dx /* Read the current LED state. */
mov old_mask, al /* Save the old register contents. */
mov al, new_mask /* Load the new register contents. */
out dx, al /* Modify the state of the LEDs. */
} /* setNewMask() */
The above example clearly depicts the usage of asm which improves the efficiency and also allows easy access of the registers from the C program. Although addition of asm might not be possible in general programming because they are target specific, mostly embedded system software are written with one particular target in mind and the asm part of the code has to be changed if the target is going to be written for some other hardware.
6.3Support of Interrupt Service Routine
Interrupt Service Routines (ISR) is also frequently used in embedded systems . There are 2 requirements with respect to ISR which include the special handling of stack and saving the register information and retrieving them later. Thus an efficient compiler should support these features. As already mentioned in the previous section this is also not a standard in C but a non-standard inclusion of a feature to be used only for embedded systems.
The efficiency of the ISR includes in the amount of operations within the ISR. Thus implementing them in C/C++ will result in time-sensitive issues. The only advantage of writing in C/C++ will be easy understanding of the programmer. Thus ISR should be written in assembly language for performance and timing issues.
ISR is supported by many compilers by the addition of the keyword “interrupt” which informs the compiler that the following function is an ISR and it requires special handling by the compiler. GNU GCC compilers support this feature with #pragma interrupt feature which informs the compiler that the next function is an ISR and it requires special handling. The only problem with the GCC compiler is that it supports this feature for only few targets. Few intelligent compilers also do not allow calling this ISR within the program.
Compliers for embedded systems is a very active area of research and conferences like LCTES  and CASES  are especially dedicated to research ideas in this field. Most of the research is focused in the area of code generation for the various types of target architectures for embedded systems which are subject to a variety of real time constraints. In this paper, we have briefly described the importance of efficient compilers and why generating efficient compilers is hard for embedded systems. We also discussed about some optimization techniques used in compilers, the characteristics of a good compiler, and the development of retargetable compilers.
. Alfred V. Aho, Ravi Sethi and Jefferey D. Ullman. Compilers – Principles, Techniques and Tools. Addison-Wesley Publishing Company.
. Embedded Systems - http://www.bbdsoft.com/glossary.html
. Nikil Dutt et.al. New directions in compiler technology for Embedded Systems. IEEE Proc. Asia and South Pacific Design Automation Conference, Yokohama, Japan (January 2001).
. Embedded Software: How to make it efficient? Proceedings of the Euromicro Symposium on Digital System Design, 2002.
. Rational Unified Process - http://www-306.ibm.com/software/awdtools/rup/
 VHDL standards and working groups -http://www.eda.org/rassp/vhdl/ standards/standards.html
. Hardware Software Co-design group - http://www-cad.eecs.berkeley.edu/~polis/
. Hardware Software Co-design for Embedded Systems - http://faculty.cs.tamu.edu/rabi/cpsc689/
. R. Leupers. Code Generation For Embedded Processors. IEEE ISSS 2000, Spain
. Java Technology – http://www.java.sun.com
. LCTES: Language, Compiler and Tool Support for Embedded Systems http://portal.acm.org/browse_dl.cfm?linked=1&part=series&idx=SERIES117&coll=portal&dl=ACM
. CASES: International Conference on Compilers, Architectures and Synthesis for Embedded Systems
. Making Heads or Tails Out of choosing your next compiler and debugger, Mentor Graphics Embedded Software White Paper.
. Choosing the compiler: Little things http://www.embedded.com/1999/9905/9905sr.htm
. Code generation for embedded processors, Leupers, System Synthesis, 2000, Proceedings. The 13th International Symposium on 20-22 Sept. 2000, pages: 173 - 178
. New directions in compiler technology for embedded systems, Dutt, Nicolau, Tomiyama, Halambi, Design Automation Conference, 2001, Proceedings of the ASP-DAC 2001, Asia and South Pacific, 30 Jan.-2 Feb. 2001, pages: 409 - 414
. Data and memory optimization techniques for embedded systems P.R.Panda, F.Catthoor, N.D.Dutt, K.Danckaert, E.Brockmeyer, C.Kulkarni, A.Vandercappelle, P.G.Kjeldsberg, ACM Transactions on Design Automation of Electronic Systems (TODAES), Volume 6, Issue 2, pages: 149 - 206