A Programming Language for Processor Based Embedded Systems
Akihiko Inoue
Hiroyuki Tomiyama
Eko Fajar Nurprasetyo
Hiroto Yasuura
Department of Computer Science and Communication Engineering,
Kyushu University
6–1 Kasuga-koen, Kasuga, Fukuoka 816-8580 Japan
f
inoino, tomiyama, eko, yasuura
g@c.csce.kyushu-u.ac.jp
Hiroyuki Kanbara
Advanced Software Technology & Mechatronics Research Institute of KYOTO (ASTEM RI)
17 Minamichou, Chudouji, Shimogyou-ku, Kyoto 600-8813 Japan
[email protected]
Abstract
Since embedded software is becoming more and more complex, software reuse is an important issue in processor-based embedded system design. However, many embedded programs can not be reused on various kinds of architectures because the correctness of programs strongly depends on both compilers and processor architectures. In order to overcome the limited reusability, we have proposed an embedded programming language, called C. In Valen-C, programmers can explicitly specify the required bit length of each variable in programs. Valen-C enables programs to be independent of processor architectures and can expand the opportunity of reusing the programs.
In this paper, the effectiveness of Valen-C is discussed by clarifying the difference of it from existing languages, and the syntax and semantics of Valen-C are described. The structure of the Valen-C retargetable compiler which we have developed and how to preserve the correctness of programs are also described.
1. Introduction
In embedded system design, processor-based systems have become popular because they give high flexibility to modification of design. System designers can modify the functionality of the systems by rewriting software only, which leads to rapid implementation. Due to the great pressure of time-to-market, the processor-based approach will be more important to reduce the design period.
Software reuse is a key technology as well as hardware reuse to design embedded systems in a short period
be-cause software design is often a great burden to system designers. In order to efficiently reuse software, program-ming languages need to be independent of target processor architectures and the correctness of programs should be pre-served on various kinds of architectures. However, many existing programming languages do not support such soft-ware reusability. For example, C programs written for a processor with 32-bit datapath width may not run correctly on 16-bit processors.
Similar problem arises when generating ASICs from software. Several parts of software are processed in ASICs rather than a processor to enhance the performance of in-tended systems. The ASICs which are directly generated from software often have the redundant area and power consumption in the combinational logics and the storage units. The reason is as follows: Many software program-ming languages have the limited word-length support. For example, only a few data sizes, which are 8 bits, 16 bits, and 32 bits, are supported in C [1]. If the size of the type
short is 16 bits, variables whose value is in [0,2000]1may be declared as short type while 11 bits are enough to hold it. In this case, upper 5 bits make no sense. Such a redundancy in ASICs may not be acceptable in cost-efficient embedded systems.
In order to overcome the limitation on software reuse and to reduce the redundancy in ASICs, we have developed the
Valen-C (Variable Length C) language and the retargetable
compiler [2]. Valen-C is a language which incorporates a concept of computational accuracy into its semantics. The accuracy is introduced in the way programmers specify the required bit length of each data type explicitly. The retargetable compiler translates a Valen-C program into
1If
assembly code for the target processor with preserving the computational correctness. Using Valen-C, programmers can write programs without assuming a particular processor, and, as the result, the opportunity of software reuse is improved. Furthermore, ASICs can be generated efficiently since the minimum required size of each variable is specified explicitly.
In [2], a design methodology for embedded systems using Valen-C is presented. In this paper, the syntax, semantics, and the effectiveness of Valen-C are discussed in detail. The structure of the Valen-C retargetable compiler and how the correctness of Valen-C programs is preserved are also described. This paper is organized as follows: In Section 2, some commonly used programming languages are discussed. In Section 3, the syntax and semantics of the Valen-C language are described. The section also presents how the retargetable compiler preserves the correctness of Valen-C programs. In Section 4, a system design example with Valen-C is provided. An experimental result is shown in Section 5. We conclude the paper in Section 6.
2. Embedded Programming Language
In embedded software design, programming languages should be selected carefully so that embedded programs have to satisfy some requirements such as high portability, high performance, and high memory efficiency. In this sec-tion, advantages and drawbacks of some existing languages are discussed.
2.1 Existing Programming Languages
A. C and C++
C is a high-level language widely used in embedded system design. C programs can satisfy the requirements of both high memory efficiency and high performance owing to good compilers. However, Paulin et al. mentioned that C has some limitations as an embedded programming language [1]. One of them is the limited word-length support. Only a few data sizes, which are 8 bits, 16 bits, and 32 bits, are supported in C. It is insufficient for many applications such as audio processing in which 24-bit data is typical. In this case, 32-bit data types may be used instead, therefore, memory cost may increase. A more serious problem is that the portability of C programs is not high because semantics of C programs depends on both compilers and processor architectures.
C++ is a language which supports object oriented soft-ware design. While the portability of programs are im-proved, extra information such as virtual tables, which must be carried at run-time, causes the overhead of performance and the memory area. These drawbacks are not often acceptable in real-time system design.
B. Java
Java has been receiving the attention as an embedded pro-gramming language because of the high portability. Java programs are once mapped into machine independent in-struction set, called bytecode, and then interpreted into each machine code. Therefore, Java programs can be run on any machine with a Java interpreter [3].
Rosenstiel et al. clarified several drawbacks of Java as an embedded programming language [4]; Java can not access hardware resources directly; The interpretation of a Java program is slower than the execution of compiler generated native code for a processor; The large amount of memory is required for complete Java execution environment. A solution of these problems is also discussed in [4]. Unfortu-nately, to the best of our knowledge, we have seen no work which quantitatively evaluates the required memory size for the execution of Java programs and the computation time.
C. Assembly Language
Assembly language is the most widely used in embedded system design. It satisfies the requirements of both good memory efficiency and high performance. However, it has quite low productivity. Furthermore, assembly pro-grams can be reused only on same architectures since it is completely machine dependent. This becomes a serious problem in designing hardware and software concurrently.
2.2 Common Drawbacks in Existing
Lan-guages
Semantics of C programs depend on both processor architectures and compilers. The size of each data type is fixed by compilers. Therefore, the portability of C programs is limited. For example, C programs written for a 32-bit processor may not run correctly on 16-bit processors.
The size of data type in Java is fixed by the language specification. For example, integral types are byte, short,
int, and long, whose size are 8 bits, 16 bits, 32 bits, and
64 bits, respectively. It is difficult to run Java programs on 24-bit processors.
Because of above reasons, it is difficult to reuse pro-grams written in an existing language with preserving the correctness of computation.
2.3 Valen-C
The bit length of each variable in an application program is originally independent of the length of the datapath width. However, in existing languages, the relation between them are determined implicitly. Let us clarify who decides the relationship. In C and C++, compiler designers define the relationship. A variable in C programs is declared using one of data types whose sizes are fixed for a datapath width.
Valen-C : System Designer
(Programmer and/or HW Designer) Java : Language Designer
C, C++ : Compiler Designer Assembly : HW Designer
Figure 1. Who decides the relationship be-tween the datapath width and the bit length of each variable in programs?
Therefore, the variable size changes according to the data-path width change. The size of each data type is determined by compiler designers. In Java, language designers give the definition as a part of the language specification. Since Java assumes that the size of byte is 8 bits, the relationship is implicitly defined by the language specification. In assem-bly languages, processor architectures induce the length of variables. Valen-C supports the definition of the relation-ship supplied by system designers who write application programs and specify the processor architecture (See Figure 1).
Valen-C enables system designers to explicitly specify the required bit length of each variable in programs. Even if system designers customize the datapath width for their application, the Valen-C compiler preserves the semantics of the program. Therefore, Valen-C programs can be reused on processors with various datapath widths. Valen-C is one solution for the problem of word-length support in C.
In the following section, the syntax and semantics of Valen-C along with the structure of the Valen-C retargetable compiler are described.
3. Valen-C and The Retargetable Compiler
3.1 The Valen-CProgramming Language
Valen-C is an extension of the C language. As mentioned before, in Valen-C, programmers can specify the required bit length of each variable in a program. The control structures in Valen-C, such as “if” and “while” statements, are same as C.
C provides for three integer sizes, declared using the keywords short, int and long. The sizes of these integer types are determined by the compiler designer. In many processors, the size of short is 16 bits, int is 16 or 32 bits, and
long is 32 bits. On the other hand, in Valen-C, programmers
can use more kinds of data types. For example, if a variable
x needs a precision of 11 bits, x will be declared as “int11 x”.
Similar to C, the sign and unsign qualifiers can be specified in Valen-C. The char type also exists in Valen-C, and it is
assumed to have a length of larger than 8 bits. The struct type and the array type are also available as well.
A floating point variable which has the precision of a 5-bit exponent and a 10-5-bit mantissa is declared as “float5.10
x”.
3.2 Retargetable Valen-CCompiler
In this section, the retargetable compiler2 which trans-lates a Valen-C program into assembly code of a target machine is described.
The Valen-C compiler uses SUIF (Stanford University Intermediate Format) library [5]. SUIF is an intermediate format of programs, and the SUIF library is a set of functions and classes which provide the interface to SUIF.
The Valen-C compiler preserves the correctness of pro-grams in the following manner: If a variable has a n-bit precision, the Valen-C compiler allocates the storage of not less than nbits for the variable. If an operation in a Valen-C program requires then-bit precision, the operation is performed with the precision of not less than n bits. For example, an addition of two 13-bit variables may be calculated with a precision of 20 bits on 20-bit processors. In case that the precision of an operation is larger than the datapath width, it is performed with a certain number of machine instructions. For example, an addition with a 20-bit precision is performed with two addition instructions of lower 10 bits and upper 10 bits on a 10-bit processor. Floating point data types have not been supported yet.
The Valen-C compiler is retargetable by modifying the machine description. The machine description includes the datapath width, the number of registers, the instruction set, the sizes and alignments of the program and data memories, the minimum addressable size of the data memory, and so on. The current implementation assumes RISC architectures as the target.
Figure 2 shows the compilation flow of the Valen-C compiler. The compilation flow consists of 5 stages. Details of each stage are described below.
A. Valen-C to C Translation
At the first phase, a Valen-C program is translated into a C program by appropriately assigning each data type in the Valen-C program to one of the four data types, short, int,
long and long long3. The sizes of short, int, long and long
long must be defined in the machine description file, and
the int type must have the same size as the datapath width. For most processors, short has the half size or the same size of int, long has the double size of int, and long long has the
2The Valen-C compiler is now available via
http://kasuga.csce.kyushu-u.ac.jp/˜codesign.
3The long long data type has the double size of long. The long long
data type is not defined in the C language, however, many C compilers assume it.
Valen-C Program C Program SUIF Assembly Code Valen-C to C Translation C to SUIF Translation
Register Allocation and Code Generation SUIF
Machine Independent Optimization
SUIF Precision Translation
Figure 2. Compilation Flow of the Valen-C Compiler
triple or quadruple size of int. For example, a data type of Valen-C which is larger than int but not larger than long is assigned to long. If long long is four times larger than int whose width isnbits, data types of at most 42nbits can be used in Valen-C programs.
The developed Valen-C compiler accepts both Valen-C and C programs. If C programs are given to the compiler, this phase is skipped.
B. C to SUIF Translation
Having translated the Valen-C program into the C program, syntax analysis is performed. At this stage, a parser in the SUIF library package is used.
C. Machine Independent Optimization
Machine independent optimizations such as dead-code elim-ination and copy propagation are performed using a tool in the SUIF package.
D. Precision Translation
Multi-precision operations are divided into a certain number of machine instructions. If the processor has no multi-precision multipliers and dividers, multi-multi-precision multipli-cation and division operations are replaced by function calls in order to prevent excessively increasing the code size. The function libraries are assumed to be designed by the machine description designers. Automatic generation of the function libraries remains as one of our future works.
E. Register Allocation and Code Generation
At the final phase, each variable is allocated to registers. If a variable is larger than the datapath width, more than one registers are allocated to the variable. After register allocation, operations are mapped to machine instructions by tree pattern matching.
4. System Design with Valen-C
4.1 Design Flow
Using Valen-C, system designers can easily design a dedicated single-chip system which consists of a core pro-cessor, instruction and data memories, and some ASICs. System design is performed as an iterative manner. First of all, designer write a Valen-C program which exhibits an intended algorithm. The program is compiled for a processor, i.e. full software implementation. Then the area, performance, and power consumption of the system, which has no ASICs, are evaluated. If the design does not meet design constraints, redesign is invoked. There are two ways to redesign. One is modifying the core processor. In our design environment, designers can use parameterized core processors for easy modification [2]. A dedicated processor can be obtained by appropriately determining the parame-ters. In the parameters, the datapath width especially has a strong effect on area and performance of systems [6]. Since Valen-C is independent of the datapath width, designers can freely change it without modifying the program. The other way is the use of ASICs each of which performs a part of the program. On generating ASICs from a Valen-C program, many redundancy can be eliminated because the required bit length is specified in the program. Valen-C plays a significant role in our design flow.
4.2 Design Example
This section provides a design example to demonstrate the effectiveness of Valen-C and the retargetable compiler. Figure 3 shows two ways to implement a Valen-C program. In software implementation, we assume a 10-bit pro-cessor. The Valen-C compiler maps each data type in the Valen-C program into one of the four data types in the ma-chine description. The int1 type is replaced the short data type whose size is 5 bits. Other two data types, int14 and
int20, correspond to the long data type. Code generation
is performed to obtain the assembly code for the 10-bit processor. In the assembly code, long type variables are divided into two words of lower 10 bits and upper 10 bits. If a designer changes the datapath width from 10 bits to 32 bits, the areas both of the processor and the data mem-ory increase because some redundancies are introduced in size of variables. Conversely, since variables which are treated as two words on the 10-bit processor become single word variables on the 32-bit processor, the area of the pro-gram memory decreases and the performance is improved. Shackleford et al. have discussed the trade-off in detail [6]. The Valen-C program can be implemented in hardware. Figure 3 also shows an example of the hardware implemen-tation. The Valen-C program is translated into a VHDL
Valen-C to VHDL Translator
Valen-C Program
main(){
unsigned int1 flag; int14 x, y; int20 z, w; if (flag == 1) { z = x + y; }else{ z = w; } ... }
Machine Description File Datapath width = 10 bits short int long long long : 5 bits : 10 bits : 20 bits : 30 bits ENTITY adder IS PORT(clk : IN std_logic; flag : IN std_logic; x,y : IN SIGNED(0 to 13); w : IN SIGNED(0 to 19); z : OUT SIGNED(0 to 19)); END adder; ARCHITECTURE rtl OF adder IS BEGIN PROCESS VARIABLE a: SIGNED(x’range); VARIABLE b: SIGNED(y’range); VARIABLE c: SIGNED(w’range); BEGIN
WAIT UNTIL clk’STABLE and clk = ’1’; IF flag = ’1’ THEN z <= conv_signed(a + b, z’length); ELSE z <= c; END IF; a := x; b := y; c := w; END PROCESS; END rtl; VHDL Program 20 bit register 14 bit registers 14 bit ALU MUX a b z w flag 20 bit register Assembly Code zl : lower bits of z zu : upper bits of z
sne : set conditinal if two operands are NOT equal each other addc : add with carry bnez : branch not equal zero
L2:
sne tmp, flag, 1 bnez tmp, L1 add zl, xl, yl; addc zu, xu, yu; jmp L2: move zl, wl; move zu wu; L1: Code Generation C Program Valen-C Retargetable Compiler
main(){
unsigned short flag; long x, y; long z, w; if (flag == 1) { z = x + y; }else{ z = w; } ... } Valen-C to C Translation Software implementation Hardware implementation
Figure 3. Hardware or software implementation of a Valen-C Program
program which has the same functionality as the Valen-C program. This figure shows that the hardware cost is held minimum.
5. Experiment
This section shows a system optimization using Valen-C and the retargetable compiler. In the experiment, hardware (ASICs) implementation is not assumed. Application pro-gram is the CCITT G.721 32Kbps ADPCM encoder in the DSPstone benchmark suite [7]. It is written in Valen-C with about 530 lines. The distribution of the variable size is shown in Table 1.
A non-pipeline processor with a simple RISC architecture is employed as a core processor [2]. ROM and SRAM are also used as instruction memory and data memory, respectively. The chip area is measured in 2-input NAND gates. A conversion rule of commercial gate array products shown in [6] is adopted to measure the gate count of ROM and RAM. The system performance is measured by the number of execution cycles under a typical input data set. Energy consumed by processors is estimated based on gate
switching count per cycle. Memory energy is obtained by multiplying the access count by energy per access,
The experimental result is shown in Figure 4. The 20% area reduction is achieved compared with the 32-bit processor. The minimum energy is 13% smaller than that of the 32-bit processor. During the experiment, we never change the Valen-C program. That is, system designers only determine design parameters to optimize the system with trading cost, performance, and energy consumption. This is because Valen-C is a reusable language owing to its independence of processor architectures.
6. Conclusions
In this paper, we have discussed the effectiveness of Valen-C. Due to the following reasons, Valen-C is superior to existing languages.
Valen-C can expand the opportunity of software reuse. It making software independent of the processor archi-tectures by capturing the ability to specify the exact computational precisions in software.
Table 1. Distribution of Variables Variable Length 1 3 4 5 9 # of Variables 7 1 7 1 1 Variable Length 10 11 12 13 14 # of Variables 7 9 33 4 14 Variable Length 15 16 17 19 yD w # of Variables 24 7 1 1 8 yD w: pointer variable 50 60 70 80 90 100 110 120 10 15 20 25 30 4e+09 5e+09 6e+09 7e+09 8e+09 9e+09 1e+10 1.1e+10 45 50 55 60 65 70 75 80 85 90 Cycle Energy Area
Execution Cycle Count [cycles] Total Energy Consumption [J]
Total System Area [kiro gates]
Datapath Width [bits]
Figure 4. Design curve for various datapath widths
Valen-C can be applied on the efficient generation of hardware modules since the redundant bits in the datapath can be eliminated.
Valen-C is one challenge to let programmers specify computational accuracy. The reason we selected C is nothing but its popularity. Many other languages can be candidates for the extension. We have concluded that specifying computational accuracy in system descriptions reduces the design cost and time, and supplies freedom for embedded system designers to optimize the systems for various applications.
References
[1] C. Liem and P. Paulin. Hardware/Software Co-Design
Prin-ciples and Practice, chapter 5, pages 149–191. Kluwer Academic Publishers, 1997.
[2] H. Yasuura, H. Tomiyama, A. Inoue, and F. N. Eko. “Embed-ded System Design Using Soft-Core Processor and Valen-C”. In Proc. of Asia Pacific Conf. on Hardware Description
Lan-guages, pages 121–130, 1997.
[3] J. Gosling, B. Joy, and G. Steele. The Java Language
Specifi-cation. Addison-Wesley, 1996.
[4] W. Ronsenstiel and C. Weiler. “Using Java in Embedded System Design”. In Proc. of Workshop on Synthesis and
System Integration of Mixed Technologies (SASIMI’97), pages
69–74, 1997.
[5] SUIF Compiler Group. The SUIF Library Version 1.0, 1994. [6] B. Shackleford, M. Yasuda, E. Okushi, H. Koizumi,
H. Tomiyama, A. Inoue, and H. Yasuura. “Embedded Sys-tem Cost Optimization via Data Path Width Adjustment”.
IEICE Trans. Information and Systems, E80–D(10):974–981,
October 1997.
[7] V. ˇZivojnovi´c, J. M. Velarde, C. Schlager, and H. Meyr. “DSPstone: A DSP-oriented Benchmarking Methodology”. In Int’l Conf. on Signal Processing and Technology, 1994.
