Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
2000-07-07
2004-05-18
Das, Chameli Chaudhuri (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S136000, C717S151000, C717S153000, C717S154000
Reexamination Certificate
active
06738966
ABSTRACT:
This application is based on an application No. 11-195717 filed in Japan, the content of which is hereby incorporated by reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a compiling device translating a source program into an object program such as a machine language program or an assembler program, and in particular, to improvements achieved when the source program includes a section written in high-level programming language and a section written in assembly language.
2. Description of the Background Art
Recent developments in high-performance integrated microprocessors have led to such microprocessors being used in information processing devices performing multimedia processing such as communication, video processing and audio processing.
The design of programs used in multimedia processing has become increasing unwieldy, so that problems regarding the development cost, maintenance and portability of such programs have multiplied in recent years. Consequently, there is a great demand for developmental environments using high-level programming languages, of which C and C++ have become particularly popular. However, a look at the current state of affairs regarding developmental environments for multimedia processing reveals that multimedia processing is often written using assembly language, which is close to machine language. This seems to go against the prevailing demand for developmental environments written in high-level programming language. Sections of the program that are frequently executed and require a short execution time are written in assembly language. Such sections form the bulk of the mass data processing functions occurring in multimedia processing.
There are several reasons for writing sections of the program in assembly language. First, the translation ability of the compiler is limited. In addition, microprocessors have some machine language instructions which achieve a plurality of functions. Such instructions are increasingly found as multimedia processing instructions, and cannot be efficiently written in high-level programming language, nor be efficiently translated into machine language instructions by the compiler.
Suppose that the microprocessor targeted by the compiler uses a load/store method (a method in which addressing of operands is performed using only transfer instructions as memory-to-memory calculation instructions), and a division instruction div is as shown in FIG.
1
D. In
FIG. 1D
, the division result is stored in a register rn, and a result of remainder calculation in a register mdr. This means that the division instructions used in a majority of microprocessors can perform division and remainder calculation simultaneously using one instruction.
In contrast, when the high-level programming language C is used, and the division and remainder results of variables a and b are to be set respectively as variables c and d, this process can only be written as shown in FIG.
1
A. As a result, many compilers generate separate div instructions for each of ‘/’ calculation and ‘%’ calculation, as shown in
FIG. 1B
, (1) and (2). Conventionally, execution of a div instruction requires a greater number of execution cycles than other instructions, so that ideally only one div instruction should be used to perform simultaneous division and remainder calculation, as shown in FIG.
1
D. In
FIGS. 1B and 1D
, registers r
2
, r
3
, r
4
and r
5
are allocated to variables a, b, c and d respectively, and ‘mov rm, rn’ signifies that the value in register rm is to be transferred to register rn.
Consequently, in the case of most C compilers, a programmer uses asm statements as extended language specifications, so that program description written in C is mixed with description written in assembly language. The example program sections shown in
FIG. 1
may be written as assembler statements following the keyword asm, as shown in FIG.
2
. Here, parts of the asm statements written using variables at a level equivalent to C may be written into registers and memory allocated by the compiler. For example, if registers r
2
, r
3
, r
4
and r
5
are allocated to variables a, b, c and d respectively, as in
FIG. 1
, the output of the compiler is as shown in FIG.
2
B.
FIG. 2B
has two more transfer instructions than the ideal situation of
FIG. 1D
but, since it has only one div instruction, requires less execution time than FIG.
1
B. In addition, if conventional copy propagation is optimized (this technique is described in reference 1, listed later in this specification) for
FIG. 2B
, the program section shown there can be changed to one similar to FIG.
1
D.
Furthermore, if it is desirable to insert instructions capable of performing both division and remainder calculation at a plurality of places in the program, a macro is defined as in
FIG. 3A
, and if this macro is used as shown in
FIG. 3B
efficiency is increased. Furthermore, the descriptor is the same kind as that used to call a function, so the program becomes easier to read. Note that
FIG. 3B
shows a situation in which a microprocessor targeted by a C language compiler replaces x, y, z and w with a, b, c and d, as in FIG.
2
A. Replacement of variables by a C compiler in this way is known as macro generation. Descriptors that are macro-defined assembler statement sequences having a special function, such as dm in
FIG. 3A
, are known as ‘inline assembly routines’.
However, if inline assembly routines are used in a conventional compiler, a programmer needs to carry out first and second check operations (described below). As a result, programmers are somewhat reluctant to include inline assembly routines when programming.
The program includes a plurality of variables. When a value of a certain variable x is valid for an entire inline assembly routine, the first check operation involves thoroughly checking the object program generated by the compiler to determine whether the value of the variable x has been destroyed. A register r is allocated to the variable x by a process performed by the compiler, so that if the inline assembly routine defines the register r, the value of the register r will differ before and after the inline assembly routine.
Suppose, as shown in
FIG. 3C
, that a value for a variable a defined at definition point (
1
) is used at use point (
2
) and variable a has a live range which extends over the inline assembly routine dm. A register r
1
is allocated to the variable a, and if the value of register r
1
is changed during the inline assembly routine dm, a value of a which differs from that defined at definition point (
1
) will be used at use point (
2
) in FIG.
3
C.
In the second check operation, the programmer makes a careful check to determine whether values of parameters have been destroyed, after determining how such values are defined by the inline assembly routine.
In some parameters, values are transferred using specified registers r. The live ranges of such parameters may extend over the inline assembly routine. Here, if a register r is defined by the inline assembly routine, the value of the parameter will be different before and after the inline assembly routine. For example, if, as in
FIG. 3D
, a parameter p is referenced after the use point of the inline assembly routine dm, and the parameter p is passed to a register r
0
, it is clear that the value of the register r
0
will be destroyed by the inline assembly routine dm, and the value used when the parameter p is referenced will be inaccurate.
These kinds of checks generally create a heavy workload for the programmer, and in an attempt to lighten this burden, many programmers write programs including various restrictions. For example, programmers only use inline assembly routines for functions including variables that can definitely be judged as being allocated to memory or a specified register prior to compiling (global variables and the like). In addition, registers used by parameters are not defined in the inline assembly routine.
Programmers would
Das Chameli Chaudhuri
Matsushita Electric - Industrial Co., Ltd.
LandOfFree
Compiling device, computer-readable recording medium on... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Compiling device, computer-readable recording medium on..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Compiling device, computer-readable recording medium on... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3229940