JP2000112770A - Program translating device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To avoid incorporating unnecessary information of an executing time type in an execution form program. SOLUTION: In compiling, an executing time type information preparing part 805 generates the section of a specific name storing executing time type information and an executing time type information use discriminating part 804 discriminates whether a reserved word for referring to execution time type information is included in a source program and in the case of being included, a tag generation part 806 generates a tag showing that it is included and incorporate it in an object module. When linked, a tag recognizing part 811 discriminates whether a tag is respectively included in all the object modules being the object of linking and in the case of discriminating that any object module does not include the tag, an execution time type information section erasing part 812 removes the section of the specific name included in them.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a program translator for compiling and linking a source program.
In particular, the present invention relates to a translation device for object-oriented programming that can refer to runtime type information.

[0002]

2. Description of the Related Art In object-oriented programming represented by the C ++ language, runtime type information (RTTI: Run
-Time Type Information) makes it possible to create programs with various functions. Here, the runtime type information refers to type information of an object determined at the time of execution, and specifically, information indicating to which class the referenced object belongs. Hereinafter, an example in which the runtime type information is used will be described with reference to FIGS.

FIG. 12 is a program list defining three classes, and FIG. 13 is a tree diagram showing the inheritance relationship of the classes. Base class A and its base class A
Are derived classes B and C that inherit from. In the base class A, one member variable a and three virtual functions (override methods) f, g, and h are defined. In the derived class B, one member variable b and a virtual function g are further defined, and the derived class C is defined. Then, one more member variable c
And a virtual function g are defined.

FIG. 14 shows an example of a program using the classes defined in FIG. 12, and is a list of programs showing typical examples of using virtual functions. The function x is a class A
With a pointer obj to the object of
The member function (method) g of the object pointed to by bj is called. Here, since the argument obj can be not only a class A but also a pointer to an object of a class B or class C that is a derived class thereof, and the function g is defined as a virtual function, Function x
Is the content for calling the function g of any of the classes A, B and C depending on the value of the argument obj at the time of execution.

FIG. 15 shows an example of a program that uses the classes defined in FIG. 12, and is a list of programs that refer to runtime type information. The function y takes a pointer obj to an object of the class A (and its derived class) as an argument, and a member variable a of the object indicated by the argument obj.
After assigning 1 to, it is determined whether or not the argument obj is a pointer to the class B. If so, 2 is assigned to the member variable b of the object indicated by the argument obj. Here, the operator typeid (ptr) is one of the reserved words referring to the runtime type information, and information for specifying the class to which the object pointed to by the pointer ptr belongs, that is, the runtime type of the object pointed to by the pointer ptr. Const typein that stores information
This function returns an fo type object.

A function z shown in FIG. 15 takes a pointer obj to an object of class A (and its derived class) as an argument, converts the argument obj to a pointer to an object of class C (cast), and Only when the conversion is successful, the function w is called using the converted pointer cp as an actual argument. Such a judgment is required because the function w receives the pointers to the class A and class B objects as the actual arguments because the function w uses the pointer obj to the object of the class C (and its derivative class) as an argument. This is because it is not possible to do so and prior judgment is required.

Here, the operator dynamic_cast <T> (ptr) is
One of the reserved words that refer to runtime type information, and a pointer
Cast ptr to type T, ie, convert pointer ptr to class T
Converts to a pointer to an object, returns the pointer if successful, otherwise a null pointer (zero)
return it. Note that the process is successful when the class to which the object indicated by the pointer ptr belongs is the class T or a derivative class thereof. Also, this operator dynamic_cast <T> (ptr)
The function itself is a function created using the above-mentioned operator typeid (), and can be said to be one of the reserved words for referring to the runtime type information.

In order to make it possible to refer to such runtime type information, a conventional program translator represented by the C ++ language generates an object module or an executable program by compiling or linking.
Runtime type information is also generated in association with a virtual function table and the like. Here, the virtual function table is a table created for each class. In the C ++ language, a pointer to runtime type information is stored together with a pointer to a virtual function defined in the class. I have.

FIG. 16 is a diagram showing the relationship between an object formed on a memory at the time of execution, a virtual function table, and runtime type information. A pointer vptr to a virtual function table is stored at the head of the object, and a pointer rptr to runtime type information is stored at the head of the virtual function table. FIG.
FIG. 13 is a diagram showing an example of a virtual function table for class A shown in FIG. 12 and runtime type information generated in association with the virtual function table. Here, in the virtual function table for the class A, an array of four-element data starting with the symbol _virtual_A, that is, the runtime type information of the class A, and pointers to the functions f, g, and h are stored. ing. The runtime type information is a sequence of 17 elements of data starting with the symbol _typeID_A.

As described above, when a program is executed, it is possible to refer to the runtime type information on the object by tracing the runtime type information via the virtual function table with the pointer to the object as a starting point. Become.

[0011]

However, according to the conventional translator, regardless of whether or not the runtime type information is referred to in the source program, it includes the runtime type information as shown in FIG. Since the object module is generated and linked, the finally obtained executable program always includes the runtime type information, and there is a problem that its size is enlarged. That is, there is a problem that even when the runtime type information is not used at all in the final executable program generated by the link, the runtime type information is always included therein. Such an increase in program size is a fatal problem, especially for a translation device for a microprocessor for embedded use used in an electronic device having a strict memory capacity such as a home appliance.

The reason why the conventional translator always generates the runtime type information at the time of compiling irrespective of whether or not the runtime type information is used in the source program is that other object linked with the object module is used. This is because the runtime type information may be referred to from a module. One method of avoiding such useless generation of runtime type information is whether to permit use of runtime type information for each class in the source program (whether to generate runtime type information or not). ) Is conceivable. That is, as in the class A shown in FIG. 18, the method is such that the runtime type information is generated for a class declared with the reserved word __rtti, and is not generated otherwise. However, such a method requires that at the time of writing the source program, the programmer definitely know that all other object modules that can be linked do not refer to the runtime type information of the class, Flexible program development is hindered, for example, it is difficult to create a general-purpose object module (an object module for which it is unknown which object module is linked to be used).

Accordingly, the present invention has been made in view of such a problem, and there is no need to explicitly indicate in a source program whether or not generation of run-time type information is necessary, so that an unnecessary execution is executed in an executable format program. It is an object of the present invention to provide a program translator that avoids the inclusion of time type information, that is, a program translator that avoids an unnecessary increase in program size.

[0014]

In order to achieve the above object, a translation apparatus according to the present invention comprises: a compiler for compiling a source program described in an object-oriented language to generate an object module; A translation unit for generating an executable program by linking, wherein the compiler unit generates a section that can be identified by a specific name and contains runtime type information, and A runtime type information generating unit to be included in the source program, a use determining unit for determining whether or not runtime type information is used in the source program, and a tag indicating that it is determined that the runtime type information is used. A tag generation unit for generating and including the generated object module in the object module; A tag determining unit that determines whether or not each of the target object modules includes the tag, and a tag determining unit that determines that none of the object modules includes the tag. A runtime type information deletion unit that excludes the section included in the module from a link target.

That is, at compile time, a section having a specific name containing runtime type information for each class defined in the source program is generated, and whether the source program refers to the runtime type information or not. It is determined whether or not the content is to be referred to, and a tag indicating that fact is generated, and these are included in the object module. Then, at the time of linking, it is determined whether a tag is included in each of all the object modules to be linked, and no tag is included in any of the object modules. , The section with the specific name included in the object module is excluded from the link targets.

[0016]

Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a functional block diagram showing a configuration of a program translation device according to the present invention. The present apparatus includes source programs 801 and 802 described in a general object-oriented language such as the C ++ language,
In other words, this is an apparatus that generates an executable file 814 for a specific microprocessor that does not include useless runtime type information by compiling and linking a source program created without specifying generation of runtime type information. It is roughly composed of two components, that is, a compiler unit 803 and a linker unit 810. The present device corresponds to a function of a conventional translator such as a C ++ language added with a function unique to the present invention, and is realized as a program executed on a general-purpose computer.

The compiler unit 803 converts, for each source program 801 (802), an instruction sequence described in a high-level language into a machine instruction sequence and data for the processor, thereby obtaining an object module 808 (80).
9), and further includes a runtime type information use determining unit 804, a runtime type information creation unit 805, a tag generation unit 806, and an instruction translation unit 807.

The runtime type information creating unit 805 generates a section having a specific name including runtime type information for each class for all classes defined in the input source program 801 (802). And the instruction translator 8
Hand over to 07. Here, the section refers to a logical unit (unit) of a machine language instruction sequence and data constituting the object module, and is used for transmitting the logical unit to the linker. Also, a specific name is
This is a unique section name that is distinguished from the machine language instruction string or section name that indicates data that corresponds to the program processing body. Here, a character string that combines the character string "_RTTI_" and the class name is used. . The runtime type information creation unit 805 is the same as the conventional translation apparatus in that runtime type information is generated for all classes defined in the source program, but has a specific name according to the above-described rules. This is different from the conventional translator that generates the instruction in the same section as the machine language instruction sequence in that it is generated in the section.

The run-time type information use determining unit 804 determines whether or not the run-time type information is used in the input source program 801 (802), specifically, the reserved word typeid or dynamic_cast in the source program. Is determined, and the result is transmitted to the tag generation unit 806. The tag generation unit 806 outputs the source program 801 (8
02), the tag (here, the pseudo-instruction ".0") for notifying the linker unit 810 that the reserved word is included from the runtime type information use determination unit 804 only when the notification is received. usertti ”) and passes it to the instruction translating unit 807.

The instruction translator 807 converts the source program 801 (802) input to the present apparatus into the above-described machine language instruction sequence and data for the processor, Information creation unit 805
And the tag (may not be generated) generated by the tag generation unit 806 (the pseudo instruction “.use
rtti ") to complete the object module 808 (809) and output it to the outside. The conversion here is a syntax analysis of a source program, a conversion to an intermediate language, a resource allocation, a conversion to a machine language code, and the like, and has the same function as a compiler unit provided in a conventional translation apparatus.

Each of the object modules 808 and 809 generated by the compiler unit 803 in this way includes runtime type information corresponding to each class defined in the program, and executes the runtime type information in the program. When an instruction to refer to information is used, a tag indicating that fact is included.

The linker unit 810 is provided with the compiler unit 80
3, the object module 808 generated by
809, a link editing unit that generates one executable file 814 that can be directly executed by the processor by resolving and linking reference relationships (addresses) between the modules, and a tag identification unit. 811, a runtime type information section deletion unit 812 and a file connection unit 813.

The tag identification section 811 is provided by the linker section 810.
It is determined whether or not each of the object modules 808 and 809 input in the above includes the tag (pseudo-instruction “.usertti”), and the result is notified to the runtime type information section deletion unit 812. Based on the notification, the runtime type information section deletion unit 812 confirms that no tag is included in all the object modules to be linked, that is, the runtime type information Are not referred to, the object module 80
8, 809, deletes all the runtime type information included in each of the object modules 808, 8
09 to the file connection unit 813. If not, the object modules 808 and 809 input to the linker unit 810 are directly copied to the file connection unit 813.
Pass to.

The run-time type information section deletion unit 81
2 specifies a section having the above-mentioned specific name among sections constituting each object module, that is, a section having a name obtained by combining a character string "_RTTI_" and a class name, and placed in the section. By deleting (emptying) the data (run-time type information), the run-time type information is deleted.

The file linking unit 813 links all the object modules passed from the runtime type information section deleting unit 812 and resolves the reference relation between the modules while linking the machine language instruction sequence and data. One final executable file 814 is completed. The linking process here is the same as the function of the linker provided in the conventional translation device.

As described above, according to the present apparatus, at the time of compiling, it is determined whether or not the contents refer to the runtime type information for each source program, and the result of the determination is whether or not a tag is attached. If it is determined that reference to the runtime type information has not been made in all the linked object modules by verifying the existence of the tag at the time of linking, This prevents such useless runtime type information from being left in the executable file.
As a result, it is possible to prevent the size of the executable file from being unnecessarily enlarged without explicitly indicating in the source program whether or not the runtime type information is referenced.

Next, the time-series operation of the present apparatus configured as described above will be described using a specific sample program. First, the first case in which the runtime type information is referred to in the source program will be described as an example. FIGS. 2 and 3 are lists of one source program 801 to be input to the apparatus and object modules 808 generated by the compiler unit 803 of the apparatus in that case. Similarly, FIGS. 4 and 5 show another source program 802 to be input to the apparatus and an object module 8 generated by the compiler unit 803 of the apparatus in that case.
09 is a list. FIG. 6 shows a final executable file 8 generated by the linker unit 810 when the object modules 808 and 809 are input.
14 is a list.

As shown in FIG. 2, in a source program 801, a base class X having a variable a and a virtual function f as members, a derived class Y having a variable b and a virtual function f as members, and a class A virtual function f and a virtual function f of class Y are defined. On the other hand, as shown in FIG. 4, the source program 802 uses the same classes X and Y as the source program 801 and the pointer obj to the object of the class X as arguments and determines the class to which the object indicated by the argument belongs. Function to display printCla
An ssName is defined, as well as a main function main that calls such a function printClassName. As can be seen from the fact that the reserved word typeid is included, the source program 802 includes a process of referring to the runtime type information.

The object module 80
The meanings of main notations in the list of 8, 809 and the execution format file 814 are as follows. sction _TEXT_vir
tual_X commom: A machine instruction sequence placed after this declaration is stored in section _TEXT_virtual_X.
And a pseudo-instruction indicating that the attribute of section_TEXT_virtual_X is commom. When the attribute is commom, when multiple object files contain a commom attribute section with the same name, when those object modules are linked, only the contents contained in the section of the first loaded object module are linked. This means that sections of the same name existing in the subsequent object modules are excluded from the link target.

_Virtual_X: Label indicating the top of the class X virtual function table. dd value: A pseudo-instruction that defines the data (area) indicated by value. _virtual_X: Label indicating the top of the class X virtual function table. sction _TEXT_virtual_Y commom and _virtual_Y
: Has the same meaning as above for class Y.

Section_TEXT: A pseudo-instruction indicating that a machine instruction sequence placed after this declaration is stored in section_TEXT. _X_f $ qv: Label indicating the address of virtual function void f (void) of class X. mov A0, Label: A transfer instruction for loading the address represented by Label into register A0.

Call Label: A subroutine call instruction that branches to the address represented by Label. ret: Return instruction from a function. _Y_f $ qv: Label indicating the address of the virtual function void f (void) of class Y.

Ds string: A pseudo-instruction that defines character string data represented by string. db 0: Pseudo-instruction that defines the end of a character string. section_RTTI_X commom: A pseudo-instruction indicating that the machine instruction sequence placed after this declaration is stored in section_RTTI_X, and that the attribute of section_RTTI_X is commom.

_TypeID_X: A label indicating the start address of the area containing the runtime type information of class X. section _RTTI_Y commom and _typeID_Y: Same meaning as above for class Y. .usertti: A pseudo-instruction indicating that the program in this object module uses runtime type information.

_Obj: label indicating the address where the static object obj is stored. _printClassName $ qp1X: Function printClassName (X *)
This is a label indicating the start address of. mov A0, A1: The contents of register A0 are stored in register A1
Transfer instruction to be loaded into

Mov (A1), A1: A transfer instruction for loading the contents of the memory whose address is the contents of the register A1 into the register A1. mov Label, A1: A transfer instruction for loading the value placed on the label Label into the register A1. call _typeinfo_ $ beq1 $ xqrx8typeinfo: This is a subroutine call instruction that branches to a function that compares typeinfo type structures.

Beq Label: A conditional branch instruction that branches to the Label if the immediately preceding operation result is 0 (comparison is found). main: A label indicating the start address of the function main (). mov (A1,4), A0: A transfer instruction for loading the contents of the memory having the address obtained by adding 4 to the register A1 into the register A0.

Call (A0): A subroutine call instruction that branches to a function starting from the address indicated by the contents of the register A0. First, the operation of the compiler unit 803 will be described. FIG.
5 is a flowchart illustrating an operation procedure of a compiler unit 803 of the present device. Now, assuming that the source program 801 (802) shown in FIG. 2 is input to this apparatus (step S1401), first, the runtime type information creating unit 805
Detects all classes (classes X and Y) defined in the source program 801 (802) and sequentially obtains class information on the classes, thereby obtaining a specific name containing runtime type information. A section is generated (steps S1402 to S1404).

More specifically, by combining each of the character strings "_RTTI_" and "_typeID_" with the class name (for example, X), the section designation pseudo instruction "section_RTTI_"
After generating "X common" and a label "_typeID_X", and further generating runtime type information uniquely determined from the contents of the class definition, a pseudo instruction "dd" for declaring them as data is generated. The sections generated in this way are as shown in sections _RTTI_X and _RTTI_Y arranged at the end of the object module 808 shown in FIG.

Subsequently, the runtime type information use judging section 804 of the compiler section 803 outputs the input source program 8
01, it is determined whether any of the reserved words typeid and dynamic_cast have been used at least once (step S14).
05), if used, tag generator 806
Generates a pseudo instruction ".usertti" indicating that (step S1406). Since the above reserved word is not used in this source program 801, the pseudo instruction ".usert
ti "is not generated.

Finally, the instruction translator 807 converts the source program 801 into a machine language instruction sequence and data, thereby forming three sections _TEXT_virtual_X and _TEXT_vir
After generating tual_Y and _TEXT (step S140
7), by combining them with the two sections _RTTI_X and _RTTI_Y generated by the runtime type information creating unit 805, an object module 808 as shown in FIG.
Is completed and output (step S1408). The object module 808 of FIG. 3 generated in this way is different from that generated by the conventional translation device in that the runtime type information is the same as the section (such as the machine language instruction sequence forming the processing body of the program). _TEXT) instead of being stored in a section with a specific name (such as _RTTI_X).

Following the compilation of the source program 801 described above, this time, the source program 802 shown in FIG. 2 is input to the apparatus (step S1401).
The basic operation is the same as when the source program 801 is input, but the processing in the runtime type information use determination unit 804 and the tag generation unit 806 (steps S1405, S1
406) are different. That is, the runtime type information use determining unit 804 of the compiler unit 803 determines that either the reserved word typeid or dynamic_cast is used at least once in the input source program 802 (step S1405). The tag generation unit 806 generates a pseudo instruction ".usertti" indicating that (step S1).
406). This corresponds to the pseudo-instruction “.usertti” being placed at the head position of the object module 809 shown in FIG.

The difference between the object module 809 shown in FIG. 5 and the object module 809 generated by the conventional translator is that (i) the runtime type information is the same as the section (such as the machine language instruction sequence forming the program body) _TEXT), rather than a section with a specific name (such as _RTTI_X)
And (ii) a tag indicating that the object module 809 has an instruction that refers to the runtime type information, that is, a pseudo instruction “.usertti” is added.

Next, the operation of the linker 810 will be described.
FIG. 8 is a flowchart showing an operation procedure of the linker unit 810 of the present apparatus. Now, it is assumed that the object module 808 shown in FIG. 3 and the object module 809 shown in FIG. 5 have been input to the linker unit 810 (step S1501).

Then, the tag identifying section 811 determines whether or not the tag (pseudo-instruction “.usertti”) is attached to each of the object modules 808 and 809, and notifies the execution-time type information section deleting section 812. (Step S1502). As a result, when the runtime type information section deletion unit 812 can confirm that there is no tagged object module, that is, it can confirm that no object module refers to the runtime type information. In this case (step S1502), the contents of all the sections with the specific names (sections starting with _RTTI_) included in the object modules 808 and 809 are emptied (step S1503,
S1504).

Here, as shown in FIG. 5, the pseudo instruction “.use
Since “rtti” is placed, this is detected by the tag identifying unit 811 (step S1502). as a result,
Since the runtime type information section deletion unit 812 recognizes that an object module with a tag exists, the execution type information section deletion unit 812 does not perform any processing, and the object module
9 is passed to the file connection unit 813 as it is. Therefore, the file linking unit 813 ends up with the object modules 808, 809 when input to the linker unit 810.
Is linked (step S1505), and finally, an executable file 814 shown in FIG. 6 is generated and output (step S1506).

The executable file 814 generated in this way is not different from the file generated by the conventional translator in that the runtime type information is eventually left. In this example, at least one of the object modules to be linked includes a process of referring to the runtime type information. Therefore, it is necessary to leave the runtime type information in the final executable file 814. Because there is.

Next, the operation of the present apparatus will be described with reference to the second case in which the runtime type information is not referred to in any of the source programs. In this case, one source program 801 is the same as the one described above (shown in FIG. 2), but the other source program 802 is different from the above and does not refer to the runtime type information (FIG. 9). ). Hereinafter, the points different from the first case will be mainly described.

FIGS. 9 and 10 show a source program 802 and a compiler 80 of the present apparatus, respectively.
3 is a list of object modules 808 generated by the third module. FIG. 11 is a list of executable files 814 that are finally generated by the linker unit 810 when the object modules 808 and 809 are input.

As can be seen from FIG. 9, this source program 802 has the same classes X and Y as the source program 801 and pointers obj to objects of class X.
, The function printClassName that calls the function f of the object pointed to by the argument, and the function pr
The main function main that calls intClassName is defined, but does not include processing that refers to runtime type information.

The operation of the compiler unit 803 when such a source program 802 is input to the present apparatus is the same as the case of the source program 801 in Case 1 described above. That is, since the runtime type information is not referred to in the source program 802, an object module 809 not including the tag (pseudo-instruction “.usertti”) is generated as shown in FIG.

However, the object module 808
And 809 are different from the first case in the operation of the linker unit 810. That is, in this case, since the tag (pseudo-instruction “.usertti”) is not included in any of the object modules 808 and 809, no tag is detected by the tag identifying unit 811 (step S1502).

As a result, the runtime type information section deletion unit 812 recognizes that there is no tag-attached object module to be linked (step S150).
2) Emptying the contents of all sections with specific names (sections starting with _RTTI_) included in the object modules 808 and 809 to make the file connection unit 8
13 (steps S1503, S1504). Therefore, the file linking unit 813 links the two object modules having no runtime type information, and outputs an executable file 814 as shown in FIG. 11 (steps S1505 and S1506).

As shown in FIG. 11, the executable file 814 generated in this manner has, at the end thereof, only a pseudo-instruction for declaring a section having a specific name (_RTTI_X, _RTTI_Y). Is empty. That is, in the second case, unlike the case of the conventional translator, useless runtime type information is prevented from being left in the executable file.

As described above, according to the present apparatus, if there is no instruction that refers to the runtime type information in any object module, the link process will
Such useless data (execution-time type information) that is not used is excluded, and is prevented from being left in the final executable file. As a result, the size of the executable program is prevented from increasing without the programmer explicitly indicating whether or not the runtime type information is referenced. In addition,
Since the runtime type information is generated for each class defined in the program, when many types of classes are applied to the defined program, the effect (reduction of the program size) exerted by this device is achieved. ) Becomes more pronounced.

In the object module generated by the compiler unit 803 of the present apparatus, in addition to the contents of the object module generated by the conventional translator, an instruction for referring to the runtime type information exists in the module. A tag indicating whether or not the module is attached can be referred to from the outside, so it can be said that the module is highly versatile. That is, it can be said that the module is useful not only for the linker unit 810 of the present embodiment but also for various processes such as optimizing a program with reference to such tags.

Although the translation apparatus according to the present invention has been described based on the embodiments, it goes without saying that the present invention is not limited to this embodiment. For example, in the present embodiment, the tag is attached to the object module only when the runtime type information is referred to in the source program. (For example, a pseudo-instruction “.no_usertti”) may be added only when reference is not made. In such a case, the runtime type information may be deleted only when it is determined that such a tag is included in all the object modules at the time of linking. Similarly, any of two types of pseudo-instructions (“.usertti” and “.no_usertti”) may be attached to all object modules.

In this embodiment, two types of operators (“typeid” and “dynamic_cas”) are included in the source program.
t)), the runtime type information was determined to have been referenced, but the runtime type information was referenced in the intermediate language or machine instruction sequence generated during the compilation process. It may be determined that the run-time type information is being referred to when the process to be performed is included.

For example, in the machine language instruction sequence, (i) the content pointed to by the pointer (argument) to the object, such as the head of the label _printClassName $ qp1X in the list of FIG. 5, is read from the memory (mov (A1) , A1), and (ii) read the content again from memory as the read content (mov
When machine instructions such as (A1) and A0) are consecutive, it may be determined that the runtime type information is being referred to. This means that, as can be seen from FIG. 16, step (i) means reading the pointer vptr to the virtual function table, and step (ii) means reading the pointer to the runtime type information. It is based on the fact that the presence of the two steps (i) and (ii) sufficiently supposes that the runtime type information will be accessed in the subsequent processing. As described above, by determining whether or not to refer to the runtime type information for the machine language code, it is possible to change only the code generation portion without changing the lexical analysis portion in the conventional translator, and thereby achieve the present invention. A translation device can be realized.

In this embodiment, the runtime type information itself (data called runtime type information) is generated in the compilation process, and the runtime type information itself is deleted in the linking process. Instead of the information itself, a function that generates a class instance using runtime type information as member data may be used. That is,
Generates a function that generates run-time type information instead of generating run-time type information at compile time, and deletes a function that generates run-time type information instead of deleting run-time type information during the linking process May be used. As a result, the translation device of the present invention can be realized by effectively utilizing the resources of the conventional translation device that previously provides a function for generating runtime type information.

As described above, the translation device of the present invention can be realized as a program executed on a general-purpose computer. Therefore, it goes without saying that the program according to the present invention can be distributed via a computer-readable recording medium such as a CD-ROM or a transmission medium such as a network.

[0062]

As is apparent from the above description, the translation apparatus according to the present invention links the object module with compiler means for compiling a source program described in an object-oriented language to generate an object module. A linker for generating an executable program, wherein the compiler generates a section identifiable by a specific name and containing runtime type information, and includes the section in the object module. A runtime type information generating unit, a use determining unit for determining whether or not runtime type information is used in the source program, and generating a tag indicating that when it is determined to be used, A tag generation unit to be included in the object module, wherein the linker means
A tag determination unit that determines whether or not the tag is included in each of all the object modules to be linked; and when it is determined that none of the object modules includes the tag. A runtime type information deletion unit that excludes the sections included in the object modules from linking targets.

Here, the meaning of the tags can be reversed. That is, when it is determined that the runtime type information is not used, the tag generation unit generates a tag indicating that fact, and the runtime type information deletion unit transmits the tag to any of the object modules. May be excluded from the links when the object module is determined to be included.

As a result, when the runtime type information is not referenced in all the object modules to be linked, useless runtime type information that is not used is left in the final executable format file. Is avoided, and enlargement of the program size is prevented. Further, the runtime type information generating unit generates a section containing a function for generating a class instance having the runtime type information instead of the section containing the runtime type information, and causes the section to be included in the object module. The runtime type information deletion unit may exclude the section containing the function from the link target. As a result, a translation device that generates an object module or an executable program similar to a conventional translation device that provides a function for generating runtime type information is realized.

Further, the use determining unit may perform the determination based on whether or not a reserved word using runtime type information is included in the source program. This makes it possible to determine whether or not the runtime type information is used by a simple process of character string matching in the source program. The use determining unit may perform the determination based on whether the object module includes a machine language instruction that refers to a section generated by the runtime type information generating unit. This makes it possible to realize the translation device of the present invention by changing only the code generation portion without changing the lexical analysis portion of the conventional translation device.

As described above, the present invention prevents a program size from becoming uselessly enlarged, and in particular, a translation apparatus for embedded microprocessors used in electronic devices such as home appliances which have severe memory capacity restrictions. The practical effect is extremely large.

[Brief description of the drawings]

FIG. 1 is a functional block diagram showing a configuration of a program translation device according to the present invention.

FIG. 2 is a list of source programs 801 input to the apparatus.

FIG. 3 is a list of object modules 808 corresponding to the source program 801 shown in FIG.

FIG. 4 is a list of source programs 802 input to the apparatus.

FIG. 5 is a list of object modules 809 corresponding to the source program 802 shown in FIG.

FIG. 6 shows an object module 808 shown in FIG.
6 is a list of executable files 814 generated by linking the object module 809 shown in FIG.

FIG. 7 is a flowchart showing an operation procedure of a compiler unit 803 of the apparatus.

FIG. 8 is a flowchart showing an operation procedure of a linker unit 810 of the apparatus.

FIG. 9 shows another source program 80 input to the apparatus.
2 is a list.

FIG. 10 is a list of object modules 809 corresponding to the source program 802 shown in FIG.

11 is an object module 80 shown in FIG.
8 is a list of executable files 814 generated by linking the object module 809 shown in FIG.

FIG. 12 is a program list that defines three classes.

FIG. 13 is a tree diagram showing inheritance relationships of classes defined in FIG.

FIG. 14 is a list of programs showing typical usage examples of virtual functions.

FIG. 15 is a list of programs that refer to runtime type information.

FIG. 16 is a diagram illustrating the relationship between an object formed on a memory at the time of execution, a virtual function table, and runtime type information;

17 is a diagram showing an example of a virtual function table for class A shown in FIG. 12 and runtime type information generated in association with the virtual function table.

FIG. 18 is a list of programs that clearly indicates whether use of runtime type information is permitted for each class.

[Description of Signs] 801, 802 Source program 803 Compiler section 804 Runtime type information use determination section 805 Runtime type information creation section 806 Tag generation section 807 Instruction translation section 808, 809 Object module 810 Linker section 811 Tag identification section 812 Execution Time type information section deletion unit 813 File connection unit 814 Executable file

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Seiichi Urushibara 1006 Kazuma Kadoma, Osaka Pref. Matsushita Electric Industrial Co., Ltd. Term (reference) 5B081 AA09 CC51

Claims (7)

[Claims] 1. A translation apparatus comprising: a compiler for compiling a source program described in an object-oriented language to generate an object module; and a linker for linking the object modules to generate an executable program. The compiler means includes a runtime type information generation unit that generates a section that can be identified by a specific name and stores runtime type information and includes the section in the object module. A use determining unit that determines whether or not the tag is used; and a tag generating unit that generates a tag indicating that the tag is determined to be used and includes the tag in the object module. The tag is included in each object module to be linked. A tag determining unit that determines whether or not the tag is included in any of the object modules; and when it is determined that the tag is not included in any of the object modules, the section included in the object module is linked from the link target. A program translation device, comprising: a runtime type information deletion unit to be excluded. 2. A translation apparatus comprising: a compiler for compiling a source program described in an object-oriented language to generate an object module; and a linker for linking the object modules to generate an executable program. The compiler means includes a runtime type information generation unit that generates a section that can be identified by a specific name and stores runtime type information and includes the section in the object module. A use determining unit that determines whether or not the tag is used; and a tag generating unit that generates a tag indicating that the tag is not used and includes the tag in the object module. The tag is attached to each object module to be linked. A tag determining unit that determines whether or not the tag is included; and when it is determined that the tag is included in any of the object modules, the section included in the object module is a link target. And a runtime type information deleting unit for excluding from the program. 3. The runtime type information generating section generates a section containing a function for generating a class instance having the runtime type information in place of the section containing the runtime type information, and includes the section in the object module. The program translation device according to claim 1, wherein the runtime type information deletion unit excludes a section containing the function from link targets. 4. The method according to claim 1, wherein the use determining unit performs the determination based on whether or not a reserved word using runtime type information is included in the source program.
The program translation apparatus according to any one of claims 1 to 3. 5. The method according to claim 1, wherein the use determining unit performs the determination based on whether the object module includes a machine language instruction that refers to a section generated by the runtime type information generating unit. The program translation device according to claim 1. 6. The program translation device according to claim 4, wherein the object-oriented language is C ++, and the reserved words include typeid and dynamic_cast. 7. A computer-readable recording medium on which a program for causing a computer to function as the means according to claim 1 is recorded.