JP3675166B2 - Program processing apparatus and recording medium - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a program processing apparatus and a recording medium including a compiler that generates object code from a high-level language, and a linker that generates a executable code by concatenating and editing a plurality of object codes. The present invention relates to a code optimization technique for reducing the code size of an executable code, and a technique for arranging variables and programs in a storage area.
[0002]
[Prior art]
In recent years, programs to be processed by a microcomputer have become more complex and sophisticated. Along with this, a method is often used in which a program is created in a high-level language such as C language and then converted into a format that can be executed by a microcomputer by a compiler and a linker.
[0003]
Especially in recent years when the program is becoming enormous, the program is divided into several source code files from the viewpoint of development efficiency, and these are compiled separately and then linked and edited by the linker to generate the final machine language code. Separate compilation is generally used.
[0004]
The cooperation between the compiler and the linker in this divided compilation is important.
[0005]
The conventional compiler and linker will be described below.
Japanese Patent Application Laid-Open No. 9-212369 describes a technique for checking the size of variables used at the time of compiling and arranging the variables on a memory after arranging them in order of increasing size. As a result, the sum of offsets from the base address is kept to a minimum, so that the storage area can be reduced. This publication also describes a method of using profile information to arrange variables on a memory after arranging variables in the order in which the number of dynamic accesses is large, that is, in the order in which the number of executions is large. As a result, a variable with a large number of accesses can be accessed with a small offset, and an access instruction size for a variable with a large number of accesses is reduced, resulting in a reduction in code size.
[0006]
[Problems to be solved by the invention]
However, the conventional method has a problem in that optimal memory allocation cannot be realized from the viewpoint of code size reduction when divided compilation is performed.
[0007]
That is, since there is only one external variable or static variable in the final machine language code, it is not possible to realize the optimum arrangement in the final machine language code by the alignment in each file.
[0008]
In addition, the alignment based on the dynamic access number obtained from the profile information generally provides a result different from the alignment based on the number of appearances of the memory operation instructions in the program. In order to reduce the code size, it is clear that the code size of the entire program will be smaller if the code size of the program has a large number of instructions, that is, if the code size of the instruction with many occurrences in the program is reduced. There is room for code size improvement.
[0009]
Furthermore, in order to obtain profile information, the compiler needs to generate code for obtaining the profile, which increases the compilation time and storage capacity required for compilation, and pre-executes the program to obtain the profile. As a result, the program development period increases.
[0010]
Further, in the above method, no consideration is given to the arrangement of the program modules, so that the subprogram call instruction is not optimized at all.
[0011]
The present invention has been made in view of such problems, and realizes optimal storage area allocation of variables even for a separately compiled program without preliminary execution of the program, and optimal program allocation. Accordingly, an object of the present invention is to provide a program processing device and a recording medium that can reduce the final code size.
[0012]
[Means for Solving the Problems]
  The program processing apparatus of the present invention
An apparatus for converting a program composed of a plurality of source codes described in a high-level language into executable code,
  SaidpluralSource codepluralConvert to object codeFirstConversion handStepped,
  SaidpluralConvert object code into the executable codeSecondConversion handSteppedWith
  The first converting means includes a measuring means for measuring the number of appearances of unresolved symbols included in the plurality of object codes when the plurality of source codes are converted into the plurality of object codes,
SaidSecondConversion handStage,
SaidIn order of appearance of unresolved symbolsIncluded in the plurality of object codesA storage area assigning means for assigning a storage area to the unresolved symbol is provided.
[0015]
  In the program processing device of the present invention, the storage area allocating means is a program.The value is preserved throughout the runA storage area may be allocated to the unresolved symbols in descending order of the number of appearances of the unresolved symbols that are variables.
[0018]
Further, the program processing apparatus of the present invention is characterized in that the storage area allocating means allocates storage areas to the unresolved symbols in descending order of the number of occurrences of the unresolved symbols whose entities are subprograms. .
[0019]
  The program processing apparatus of the present inventionFirstConversion handStageThe measuring handStepsIncluding frequency information output means for outputting the frequency of occurrence of the measured unresolved symbol as a frequency information file,SecondConversion handStageAnd a frequency information input unit that receives the plurality of frequency information files output by the frequency information output unit and totals the frequency for each of the unresolved symbols.
[0020]
  Moreover, the program processing device of the present invention provides the aboveFirstConversion handStageThe measuring handStepsIncluding object code output means for outputting the measured number of occurrences of the unresolved symbol added to the object code,SecondConversion handStage, Including frequency information input means for receiving the plurality of object codes output by the object code output means, taking out the number of appearances added to the object code, and totaling the frequency for each unresolved symbol be able to.
[0022]
  In the program processing device of the present invention, the instruction means may obtain a product of a code size of an instruction that operates the storage area assigned to the unresolved symbol in the storage area assignment means in an absolute address format and the number of appearances of the instruction. , A code of an instruction for operating a storage area allocated to the unresolved symbol in a relative address formatsizeAnd the number of occurrences of the instruction and the relative numberThe earthIn order to generate an instruction for operating the unresolved symbol in a relative address format when the sum of the code size of the instruction set in the register is exceeded.FirstConversion handIn stepsInstruct and saidFirstConversion handStageWhen there is an instruction from the instruction means, the unresolved symbol is set as a relative address.formatIt is possible to generate an instruction to be operated on.
[0023]
  The recording medium of the present invention is a recording medium recording a program for converting a program composed of a plurality of source codes written in a high-level language into an executable code,pluralSource codepluralChange to object codeA first step including a measurement step of measuring the number of appearances of unresolved symbols included in the plurality of object codes whenConversion stepAndThe abovepluralConvert object code into the executable codeAnd a second storage area allocation step of allocating a storage area to the unresolved symbols included in the plurality of object codes in descending order of the number of appearances of the unresolved symbols.Conversion stepTheIt is possible to record a program to be executed by a computer.
[0024]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, a program processing apparatus and a recording medium according to the present invention will be described with reference to the drawings.
[Explanation of terms]
First, terms used in this description will be explained.
・ Subprogram
A program called from the main routine. Specifically, it refers to a function or subroutine.
・ Unresolved symbols
A symbol that is not fixed until the object code is linked and edited. There are external variables and external labels (start addresses of subprograms).
·object
The entity that the symbol represents. For example, when C language is used as the high-level language, when A is a LONG type external variable, the entity is an 8-byte memory.
·section
Distinguishing when placing objects during concatenation editing. Objects in the same section are arranged together. Generally, a program is arranged as a code section and variables are arranged as a data section.
[1. Embodiment 1]
[Configuration of program processing device]
FIG. 1 is a block diagram showing the configuration of the program processing apparatus and related data.
[0025]
This program processing apparatus is roughly divided into two groups: (1) a group that generates object code 60 from source code 50 written in a high-level language (compiler upstream unit 10, code generation unit 11, frequency information output unit 12, (2) a group that concatenates and edits a plurality of object codes 60 to 61 to generate a final executable code 70 (symbol information collection unit 20, frequency information) A conversion unit 2 including an input unit 21, an arrangement optimization unit 22, and a storage area allocation unit 23, hereinafter referred to as a linker).
(Upstream compiler 10)
The compiler upstream section 10 reads the high-level language source code 50 stored in the file format, performs syntax analysis and semantic analysis, and generates an internal format code. Furthermore, as necessary, the internal format code is optimized so that the size of the executable code finally generated and the execution time thereof are shortened. The processing here is the same as the processing by the upstream compiler portion of the conventional compiler.
(Code generator 11)
The code generation unit 11 generates the object code 60 from the internal format code generated and optimized by the compiler upstream unit 10. Here, the “object code” is a machine language program for the target machine including relocatable information. The code generation unit 11 includes a frequency measurement unit 13. The frequency measurement unit 13 accesses the symbol frequency information table 14 and updates the appearance frequency of symbols when an unresolved symbol is included in the code generated by the code generation unit.
[0026]
Details of the processing of the code generation unit 11 are as follows.
FIG. 2 is a flowchart showing a processing procedure in the code generation unit 11.
[0027]
The code generation unit 11 repeats the following processing (steps S2 to S6) for all instructions of the internal format code generated by the compiler upstream unit 10 (steps S1 and S7).
[0028]
  First, the code generation unit 11 selects the internal format codeIn orderCorresponding machine language code instruction(Hereinafter, simply referred to as “target instruction”.)Is generated (step S2).
[0029]
Next, it is determined whether or not the instruction of interest includes an unresolved symbol (step S3). If an unresolved symbol is included, it is further determined whether or not the unresolved symbol has already been registered in the symbol frequency information table (step S4).
[0030]
If the unresolved symbol is not registered in the symbol frequency information table, an entry corresponding to the unresolved symbol is created in the symbol frequency information table (step S5). At that time, the use frequency of the symbol is initialized to zero.
[0031]
Next, 1 is added to the frequency of use of the symbol, and the symbol frequency information table is updated (step S6).
[0032]
In FIG. 2, a portion surrounded by a dotted line corresponds to the processing of the frequency measurement unit 13 included in the code generation unit 11.
(Frequency information output unit 12)
Returning to FIG. 1, the frequency information output unit 12 reads the symbol frequency information table 14 and outputs it as a symbol frequency information file 80.
[0033]
As described above, the object code 60 and the symbol frequency information file 80 corresponding to the source code 50 are generated from the source code 50 by the processing of the compiler 1. When there are a plurality of source codes, the object code 60 and 61 and the symbol frequency information files 80 and 81 corresponding to the source code 50 and 51 are generated by performing the processing of the compiler 1 for the source codes 50 and 51, respectively.
(Symbol information collection unit 20)
The symbol information collection unit 20 reads a plurality of object codes 60 to 61 and collects symbol information. Further, a symbol information table 24 is generated based on the collected symbol information. The processing here is the same as the processing performed by the symbol information collection unit of the conventional linker. Further, the generated symbol information table 24 is not different from the symbol information table 24 generated by the conventional linker at this stage.
(Frequency information input unit 21)
The frequency information input unit 21 reads the symbol frequency information files 80 to 81 output from the frequency information output unit 12 of the compiler 1. Symbol frequency information is added to the corresponding entry of the symbol information table 24 generated by the symbol information collection unit 20.
(Placement optimization unit 22)
The arrangement optimization unit 22 refers to the symbol information table 24 and optimizes the memory arrangement of variables. Specifically, paying attention to the frequency of use of symbols, variables with high frequency of use are arranged at positions close to the base address of the storage area. As a result, it is expected that the code for the frequently accessed memory is reduced, so that the code size as a whole can be reduced.
[0034]
Details of the processing of the placement optimization unit 22 are as follows.
FIG. 3 is a flowchart showing a processing procedure in the arrangement optimization unit 22.
[0035]
First, the arrangement optimization unit 22 arranges the symbol information tables in descending order of frequency (step T1). Alignment is done for each section.
[0036]
Next, an allocatable memory location used in the following processing is initialized to the top of the allocatable memory (step T2). A plurality of allocatable memory locations are prepared depending on the number of sections. In the present embodiment, two external and static variable allocable memory locations (hereinafter referred to as variable allocable memory locations) and program allocable memory locations are used.
[0037]
Next, while there is an allocation target according to the symbol information table, the layout optimization unit 22 repeats the following processing (steps T4 to T5) in the order arranged in step T1 (steps T3 and T6).
[0038]
An unresolved symbol is allocated to an allocatable memory location, and the allocated memory location is registered in the symbol information table 24 (step T4). At this time, if the unresolved symbol to be allocated is a variable, a variable allocatable memory location is used, and if it is a program, the program allocatable memory location is used.
[0039]
Next, the allocatable memory location is updated according to the size of the object allocated in step T4 (step T5). Specifically, the size of the object allocated in step T4 is added to the current allocatable memory location to obtain a new allocatable memory location. When the memory alignment is restricted due to the restriction of the target machine, the new allocatable memory location is adjusted in consideration of this. At this time, if the unresolved symbol assigned in step T4 is a variable, the variable allocatable memory location is updated, and if it is a program, the program allocatable memory location is updated.
(Storage area allocation unit 23)
Returning to FIG. 1, the storage area allocating unit 23 actually allocates the memory according to the content determined by the layout optimization unit 22 and generates the final executable code 70. The generated executable code 70 is written out as a file.
[Specific operation of program processing device]
Next, operations of characteristic components of the program processing apparatus will be described using specific instructions.
[0040]
First, the target machine targeted by the program processing apparatus will be described. In general, in a fixed-length instruction architecture, a memory range that can be accessed by one instruction is limited. FIG. 4A shows an example of a memory access instruction in the fixed-length instruction architecture. In a target machine having such a memory access instruction, the width for expressing an address for designating a memory is only 16 bits, and therefore, only an area of 65536 bytes from address 0 to address 65535 can be represented by one instruction ( Arrow a1). Memory exceeding this range must be expressed by two or more instructions (arrow a2). The subprogram call instruction can only be directly called up to a certain range (arrow a3). On the other hand, there are similar limitations in variable-length instruction architectures. FIG. 4B shows an example of an instruction in the variable length instruction architecture. In this example, a 2-byte instruction can access an address width of 8 bits, that is, an area of 256 bytes from address 0 to address 255 (arrow a4). Similarly, an area up to address 65535 (arrow a5) can be accessed with a 3-byte instruction, and address 4294967295 can be accessed with a 4-byte instruction (arrow a6). That is, in the variable-length architecture, all memory areas can be accessed with one instruction, but the code size increases as the accessed area moves away from address 0. Even in the case of a call instruction for a subprogram, a call instruction for a larger memory area is larger than the instruction size (arrows a7 and a8). Here, an absolute address format memory access instruction is taken as an example, but the same can be said even if this is a relative address format. In the case of the relative address format, the difference is that the reference is not the address 0 but the value of the base register, and the required code size increases as the distance from the base register increases.
[Example]
A case where a program is divided and compiled into three will be described with reference to an example. In this case, there are three source codes.
[0041]
First, the first source code is compiled. The source code input to the compiler is processed by the compiler upstream unit 10 and converted into an internal format code. Here, it is assumed that the internal format code of FIG. The internal format code is then input to the code generator 11. The operation of the code generation unit 11 will be described along the flowchart shown in FIG.
[0042]
The code generation unit 11 repeats steps S1 to S7 while there is an internal format code.
[0043]
First, the instruction c1 is converted into the machine language code m1 shown in FIG. 5B (step S2).
[0044]
Subsequently, it is determined whether or not this instruction includes an unresolved symbol (step S3). Since the symbol memory1 included in the machine language code m1 is an unresolved symbol, it is determined as Yes.
[0045]
Next, it is determined whether this symbol is already registered in the symbol frequency information table 14 (step S4). Since this machine language code m1 is the first instruction for processing this source code, nothing is registered in the symbol frequency information. For this reason, this branch is determined to be No.
[0046]
Next, the unresolved symbol memory1 is registered in the symbol frequency information table (step S5). Specifically, a symbol memory1 field is created in the symbol frequency information table 14 and the frequency is initialized to 0 (FIG. 6A).
[0047]
Finally, 1 is added to the usage frequency of the symbol memory1 currently handled, and the symbol frequency information table is updated (step S6). The symbol frequency information table 14 is as shown in FIG.
[0048]
The above steps are repeated while there is an internal format code (step S7).
The contents of the symbol frequency information table immediately after the internal format codes c2 and c3 are processed are shown in FIGS. 6 (c) and 6 (d). The internal format codes c2 and c3 are converted into machine language codes m2 and m3, respectively. FIG. 6E shows the contents of the symbol frequency information table after the processing of the first source code is completed. Here, the break above function1 in FIGS. 6 (d) and 6 (e) indicates that the symbol frequency information for the variable is above and the symbol frequency information for the subprogram is below. These form sections for variables and programs, respectively.
[0049]
When the process of the code generation unit 11 is finished, the control moves to the frequency information output unit 12. The frequency information output unit 12 refers to the symbol frequency information table and outputs the contents as a symbol frequency information file 80. The contents of the symbol information file 80 corresponding to the first source code are shown in FIG.
[0050]
Similar processing is performed for the second and third source codes. Assume that the contents of the symbol frequency information file corresponding to the second and third source codes are as shown in FIGS. Here, the break above function1 in FIGS. 7A to 7C indicates that the symbol frequency information for the variable is shown above and the symbol frequency information for the subprogram is shown below.
[0051]
Next, the processing contents of the linker will be described. First, the symbol information collection unit 20 reads a plurality of object files 60 to 61 output from the compiler. At this time, entries are generated in the symbol information table 24 in the order in which the symbols appear, and information (object size and alignment information) necessary for the link processing is taken in. Such information is generally contained in an object file. Since this processing is not different from the processing by the conventional linker, the details are omitted. In this example, three object codes corresponding to three source codes are read and formed in the symbol information table shown in FIG.
[0052]
Next, the frequency information input unit 21 is activated. The frequency information input unit 21 reads a plurality of symbol frequency information files 80 to 81 corresponding to the object file read by the symbol information collection unit 20, and reads the read frequency information in the frequency column of each symbol entry in the symbol information table 24. Add the values described in the file. In this example, the three symbol frequency information files shown in FIGS. 7A, 7B, and 7C are read. As a result, the symbol information table is as shown in FIG.
[0053]
When the processing of the frequency information input unit 21 is finished, the arrangement optimization unit 22 is activated. The operation of the placement optimization unit 22 will be described with reference to the flowchart shown in FIG.
[0054]
First, the symbol information table is arranged (sorted) in the order of the frequency number for each section (step T1). The sections are divided by a break above the function1 column in FIGS. 8A, 8B, and 8C, and there are two sections in total. As a result, the symbol information table 24 is as shown in FIG.
[0055]
Next, an allocatable memory location is initialized (step T2). Here, it is assumed that the program allocable memory location is initialized to address 0xF000 and the variable allocable memory location is initialized to 0x00F0. 0x indicates that the subsequent numerical value is in hexadecimal notation. The same applies to the following.
[0056]
While there are objects to be allocated, steps T4 to T5 are repeated (steps T3 and T6).
[0057]
Next, an unresolved symbol is allocated to the memory (step T4). Since the unresolved symbol at the top of the symbol information table is memory 3, it is assigned to address 0x00F0.
[0058]
Finally, the allocatable memory location is updated according to the size of the allocated object (step T5). Here, since the size of memory1 is 0x0008, the allocatable memory location is 0x00F8.
[0059]
While the allocation target remains, the above steps T3 to T6 are repeatedly executed. The allocation operation for the remaining objects will be briefly described.
[0060]
The second unresolved symbol is memory2. This is allocated to address 0x00F8 (step T4), and the allocatable memory location is updated to 0x0100 by adding the object size 0x0008 of memory2 (step T5).
[0061]
The third unresolved symbol is memory1. This is allocated to address 0x0100 (step T4), and the allocatable memory location is updated to 0x0108 by adding the object size 0x0008 of memory1 (step T5).
[0062]
The fourth unresolved symbol is function2. Since this is a program, it is allocated to address 0xF000 with reference to the program allocable memory location (step T4). The allocatable memory location is updated to 0xF120 by adding the object size 0x0120 of function2 (step T5).
[0063]
The fifth unresolved symbol is function1. Since this is also a program, it is assigned to address 0xF120 (step T4), and the allocatable memory location is updated to 0x11254 by adding the object size 0x2134 of function1 (step T5).
[0064]
The symbol information table at the end of the placement optimization unit 22 is as shown in FIG.
Finally, the storage area allocating unit 23 rewrites the unresolved symbol in the input object code with the arrangement destination address according to the contents of the symbol information table 24. This process is the same as that of the conventional linker.
[0065]
The final executable code is obtained by the above processing. In this example, executable code is generated by concatenating and editing three object codes generated from three source codes. Part of the generated executable code is shown in FIG. FIG. 5C shows a portion of the executable code corresponding to the first source code shown in FIGS. 5A and 5B expressed in mnemonics. In addition to this, the actual executable code includes portions corresponding to the second and third source codes. As can be seen from comparison with FIG. 5B, it can be seen that the unresolved symbols in FIG. 5B are replaced with actual memory addresses determined in the symbol information table (FIG. 9).
[0066]
Next, the code size of the executable code generated based on the first embodiment is shown. Assuming the variable length instruction architecture of FIG. 4B as the architecture of the target machine, the access instruction to the memory memory 3 that is most frequently accessed in the entire program including all of the first, second, and third source codes is Since memory memory 3 is located at address 0x00F0, it becomes a 2-byte instruction, and the total code of the memory access instruction is 20 bytes. Considering all the memory access instructions, in the first embodiment, 2 × 10 + 2 × 6 + 4 × 5 = 52 bytes.
[0067]
Also, in the arrangement of subprograms, calling function1 is a 4-byte instruction because function1 is allocated from address 0xF120, and calling function2 is also a 4-byte instruction because function2 is allocated from address 0xF000, and the entire calling instruction is 4 × 5 + 4. X7 = 48 bytes.
[0068]
In order to show the size of each instruction, FIG. 5C shows the code size of the portion corresponding to the first source code on the right side of each instruction mnemonic. The code size of the portion corresponding to the first source code is 30 bytes.
[0069]
In this embodiment, the content of the symbol frequency information table 14 is output as the frequency information file 80 and passed to the linker. However, the content of the symbol frequency information table 14 is added to the object code 60 generated by the code generation unit 11. You may hand it over to the linker.
[0070]
Further, as in the access instruction to memory1, the product (20 bytes) of the instruction code size (4 bytes) and the appearance frequency (5 times) is the code size of the relative address address format memory access instruction to memory1 (2 bytes, FIG. 4). (B) Sum of product (10 bytes) of arrow a9) and appearance frequency (5 times) and setting instruction to relative address address base register (6 bytes, FIG. 4 (b) arrow a10) (16 bytes) May exceed the above, the code generation unit 11 may be instructed to output the corresponding unresolved symbol (in this case, memory1) in the relative address format, and may be repeated from the code generation. This can further reduce the code size.
[Comparison with conventional program processing devices]
With the above processing, a final executable code is obtained. In order to clearly show the features of the present invention, a comparison is made with the case of a conventional program processing apparatus (compiler and linker).
[0071]
FIG. 13 is a block diagram showing the configuration of a conventional program processing apparatus in comparison with the embodiment of the present invention.
[0072]
This program processing apparatus does not include the frequency measurement unit 13, the frequency information output unit 12, the frequency information input unit 21, and the arrangement optimization unit 22 according to the present embodiment. Therefore, there is no means for obtaining the appearance frequency of unresolved symbols appearing in a plurality of object files, and when the linker performs processing, the memory is allocated in the order of appearance of the unresolved symbols. Therefore, the memory allocated to each symbol when the first to third source codes are processed is as shown in FIG. In FIG. 14, the appearance frequency is added for the following comparison, but the appearance frequency column does not exist in the conventional configuration.
[0073]
Next, the code size of the executable code generated based on the conventional program processing apparatus is shown. As in the first embodiment, assuming the variable-length instruction architecture of FIG. 4B as the architecture of the target machine, the most frequently accessed access instruction to the memory memory3 is that memory3 is arranged at address 0x0100. Since this is a 4-byte instruction and this instruction appears 10 times, the total code of the access instruction to this memory is 40 bytes. This is an increase of 20 bytes from the result of the program processing apparatus of the first embodiment. In consideration of all the memory access instructions, in the conventional example, 2 × 5 + 2 × 6 + 4 × 10 = 62 bytes, which is an increase of 10 bytes compared with 52 bytes which is the result in the first embodiment.
[0074]
Also, the same effect appears in the arrangement of subprograms. In the conventional example, the function 1 call is a 2-byte instruction because function 1 is allocated from address 0xF000, and the function 2 call is a 4-byte instruction because function 2 is allocated from address 0x11134. The entire call instruction is 4 × 5 + 6 × 7 = 62 bytes. It becomes. On the other hand, in the first embodiment, the code size of the entire call instruction is 48 bytes, so in the conventional example, the code size is increased by 14 bytes compared to the first embodiment.
[0075]
Even when a conventional program processing device is equipped with means for allocating storage areas for automatic variables based on the size of variables or the frequency of dynamic use, external variables of a program divided into a plurality of files as shown in this example Needless to say, storage area allocation cannot be optimized.
[2. Second Embodiment]
[Configuration of program processing device]
FIG. 10 is a block diagram showing a configuration and related data in the second embodiment of the program processing apparatus.
[0076]
This program processing apparatus is roughly divided into two groups: (1) a group for generating object code 160 from source code 150 written in a high-level language (compiler 101 including compiler upstream section 110 and code generation section 111); (2) A group that concatenates and edits a plurality of object codes 160 to 161 to generate a final executable code 170 (a linker comprising a symbol information collection unit 120, a frequency measurement unit 121, a layout optimization unit 122, and a storage area allocation unit 123) 102).
(Upstream compiler part 110)
This is the same as the compiler upstream section 10 in the first embodiment.
(Code generator 111)
The code generation unit 111 generates the object code 160 from the internal format code generated and optimized by the compiler upstream unit 110. Here, the “object code” is a machine language program for the target machine including relocatable information.
(Symbol information collection unit 120)
This is the same as the symbol information collection unit 20 in the first embodiment.
(Frequency measuring unit 121)
The frequency measuring unit 121 searches the plurality of object codes 160 to 161 read by the symbol information collecting unit 120 and measures the appearance frequency of each symbol in the symbol information table 124 generated by the symbol information collecting unit 120.
[0077]
Details of the processing of the frequency measurement unit 121 are as follows.
FIG. 11 is a flowchart showing a processing procedure in the frequency measurement unit 121.
[0078]
First, the frequency measurement unit 121 initializes all the frequency fields of the symbol information table 124 with 0 (step U1).
[0079]
Next, while there is a portion corresponding to the program in the object code, the following processing (steps U3 to U4) is repeated (steps U2 and U5).
[0080]
First, it is determined whether or not the currently processed instruction includes an unresolved symbol (step U3). If not included, the process proceeds to step U5 and the process of the next instruction is performed.
[0081]
When an unresolved symbol is included, 1 is added to the frequency column of the symbol line in the symbol information table (step U4).
[0082]
The above processing is repeated to obtain frequency information of each symbol for all object codes input to the linker.
(Placement optimization unit 122)
This is the same as the placement optimization unit 22 in the first embodiment.
(Storage area allocation unit 123)
This is the same as the storage area allocation unit 23 in the first embodiment.
[Specific operation of program processing device]
Next, operations of characteristic components of the program processing apparatus according to the second embodiment will be described using specific instructions. A case where a program is divided and compiled into three will be described with reference to an example. In this case, there are three source codes.
[0083]
Since the conversion means 1 is equivalent to a conventional compiler, its operation is omitted, and the same first to third source codes as in the first embodiment are processed and three object codes are obtained.
[0084]
The processing contents of the linker will be described. First, the symbol information collection unit 120 reads a plurality of object files 160 to 161 output from the compiler. At this time, entries are generated in the symbol information table 124 in the order in which the symbols appear, and information (object size and alignment information) necessary for the link processing is taken in. Such information is generally contained in an object file. Since this processing is not different from the processing by the conventional linker, the details are omitted. In this example, three object codes are read and formed in the symbol information table shown in FIG.
[0085]
Next, the frequency measurement unit 121 is activated. The frequency measuring unit 121 examines the program part of the multiple object file read by the symbol information collecting unit 120 and measures the static appearance frequency of each unresolved symbol. First, the frequency column of the symbol information table 124 is initialized to 0 (step U1, FIG. 12B). Next, an unresolved symbol is searched while there is a program part, and 1 is added to the corresponding frequency column every time an unresolved symbol appears (steps U2 to U5). The symbol information table 124 after the processing of all the program parts included in the three object codes is as shown in FIG.
[0086]
Next, the arrangement optimization unit 122 and the storage area allocation unit 123 are activated in order. Since FIG. 12C is exactly the same as FIG. 8B of the first embodiment, the processing in the placement optimization unit 122 and the storage area allocation unit 123 is also performed in the placement optimization unit 22 and the storage area in the first embodiment. The result is the same as the processing in the allocation unit 23, and finally, the same storage area allocation as that of the first embodiment is realized.
[3. Embodiment 3]
By inserting the program processing apparatus shown in the first and second embodiments into a recording medium such as a floppy disk, a hard disk, a CD-ROM, and an MO, the program processing apparatus shown in the first and second embodiments can be realized by a computer.
[0087]
【The invention's effect】
As is apparent from the above description, the program processing device according to the present invention is a device that converts a program composed of a plurality of source codes described in a high-level language into executable code, and converts the source code into a target code. Conversion means 1 that converts the object code into executable code, and the conversion means 2 includes storage area allocation means that assigns storage areas to the unresolved symbols in descending order of the number of appearances of the unresolved symbols. It is characterized by providing.
[0088]
As a result, variables and subprograms that are frequently manipulated in the source program are placed in an area close to the base address, so the size of the instruction that manipulates them is reduced, resulting in the code size of the entire program. Can be compressed.
[0089]
Here, the conversion unit 1 includes a measurement unit 1 that measures an appearance unit of unresolved symbols, and the storage area allocation unit is configured to determine the unresolved order in descending order of the number of appearances of the unresolved symbols measured by the measurement unit 1. A storage area can be allocated to the symbol.
[0090]
As a result, the frequency of appearance of unresolved symbols in each source program is measured at the same time as code generation at the time of compilation, so that the link processing that realizes the storage area optimization function can be completed without much additional time.
[0091]
In addition, the conversion unit 2 includes a measurement unit 2 that measures an appearance unit of an unresolved symbol, and the storage area allocation unit includes the unresolved symbols in descending order of the number of appearances of the unresolved symbols measured by the measurement unit 2. It is possible to allocate a storage area.
[0092]
As a result, the appearance frequency of unresolved symbols in the program can be measured from the object code output by the existing compiler, so the storage area can be used while utilizing the existing compiler and the object code output by the existing compiler. It is possible to reduce the code size by optimizing the arrangement.
[0093]
Further, the storage area allocating means may allocate the storage areas to the unresolved symbols in descending order of the number of occurrences of the unresolved symbols that are valid variables over a plurality of source codes constituting the program. .
[0094]
As a result, the instruction size of the operation instruction for the external variable that is frequently operated is shortened, so that the code size of the entire program can be reduced.
[0095]
Further, the storage area allocating means is configured to determine the unresolved symbols in descending order of the number of occurrences of the unresolved symbols that are valid variables over the entire source code file among a plurality of source codes constituting the program. It is possible to allocate a storage area.
[0096]
As a result, the instruction size of the operation instruction with respect to the in-file static variable that is frequently operated is reduced, so that the code size of the entire program can be reduced.
[0097]
Further, the storage area allocating means is a variable that is valid in a part of any one of the plurality of source codes constituting the program and that holds a value throughout the execution of the program. A storage area can be allocated to the unresolved symbols in descending order of the number of appearances of the unresolved symbols.
[0098]
As a result, the instruction size of the operation instruction for the frequently operated static variable is shortened, so that the code size of the entire program can be reduced.
[0099]
Further, the storage area allocating means can allocate storage areas to the unresolved symbols in descending order of the number of appearances of the unresolved symbols that are subprograms.
[0100]
As a result, the instruction size of the calling instruction for the frequently called subprogram is shortened, so that the code size of the entire program can be reduced.
[0101]
In the program processing device of the present invention, the instruction means may obtain a product of a code size of an instruction that operates the storage area assigned to the unresolved symbol in the storage area assignment means in an absolute address format and the number of appearances of the instruction. , When the sum of the code number of the instruction that operates the storage area allocated to the unresolved symbol in the relative address format and the number of times the instruction appears and the code size of the instruction that sets the relative address in the register The conversion means 1 is instructed to generate an instruction for operating the unresolved symbol in a relative address format, and the conversion means 1 converts the unresolved symbol into the unresolved symbol when there is an instruction from the instruction means. It is possible to generate a command to operate with a relative number terrain address formula.
[0102]
This makes it possible to accurately determine when the code size is smaller when the address is expressed in the relative address format than in the absolute address format, and the code size can be further reduced.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of a compiler and a linker and related data according to a first embodiment of the present invention.
FIG. 2 is a flowchart showing a processing procedure in the code generation unit 11 of the program processing apparatus.
FIG. 3 is a flowchart showing a processing procedure in the layout optimization unit 22 of the program processing apparatus.
FIG. 4 is a diagram showing an example of a fixed-length instruction set targeted by the program processing apparatus according to the present invention.
FIG. 5 is a diagram showing an example of an internal format code generated by the compiler upstream unit 10 of the program processing apparatus.
FIG. 6 is a diagram showing an example of a symbol frequency information table 14 in the process of generation
FIG. 7 is a diagram showing an example of a symbol frequency information file corresponding to first to third source codes.
FIG. 8 is a diagram showing an example of a symbol information table 24 during processing
FIG. 9 is a diagram showing an example of a symbol information table 24 that has been processed by the placement optimization unit 22;
FIG. 10 is a block diagram illustrating a configuration of a compiler and a linker and related data according to a second embodiment of the present invention.
FIG. 11 is a flowchart showing a processing procedure in the frequency measurement unit 121 of the program processing device according to the second embodiment of the present invention.
12 is a diagram illustrating an example of a symbol information table 124 generated by the symbol information collection unit 120. FIG.
FIG. 13 is a block diagram showing a configuration and related data of a conventional program processing apparatus.
FIG. 14 is a diagram showing an example of a symbol information table 980 after completion of processing by a symbol information collection unit 902 in a conventional program processing apparatus.
[Explanation of symbols]
1 Compiler
2 Linker
10 Compiler upstream
11 Code generator
12 Frequency information output section
13 Frequency measurement section
14 Symbol frequency information table
20 Symbol information collection department
21 Frequency information input section
22 Placement optimization section
23 Storage area allocation part
24 Symbol information table
50, 51 source code
60, 61 Object code
70 Executable code
80, 81 symbol frequency information
101 compiler
102 Linker
110 Compiler upstream
111 Code generator
120 Symbol information collection unit
121 Frequency measurement unit
122 Placement optimization unit
123 Storage area allocation unit
124 Symbol information table
150 source code
160, 161 Object code
170 Executable code
900 Compiler upstream
901 Code generator
902 Symbol information collection unit
903 Storage area allocation unit
950 source code
960, 961 Object code
970 executable code
980 symbol information table

Claims (7)

An apparatus for converting a program composed of a plurality of source codes described in a high-level language into executable code,
A first conversion means to convert said plurality of source code into a plurality of object codes,
And a second conversion means to convert said plurality of object code to the executable code,
The first converting means includes a measuring means for measuring the number of appearances of unresolved symbols included in the plurality of object codes when the plurality of source codes are converted into the plurality of object codes,
The second conversion hand stage,
Program processing apparatus characterized by having a storage area allocation means for allocating a storage area in the unresolved symbols the included in the plurality of object codes in the order number of occurrences of unresolved symbols often. The storage region assignment unit, the sequentially number of occurrences of unresolved symbols often value throughout the program execution is a variable that is held, according to claim 1, characterized in that allocating a storage area in the unresolved symbol Program processing device. The program processing apparatus according to claim 1, wherein the storage area allocating unit allocates storage areas to the unresolved symbols in descending order of the number of appearances of the unresolved symbols that are subprograms. The first conversion hand stage,
Includes frequency information output means for outputting the number of occurrences of the unresolved symbols the measuring hand stage was measured as frequency information file,
The second conversion hand stage,
Receiving said frequency information output means are a plurality of the frequency information file output, the according to any one of claims 1 to 3, characterized in that it comprises a frequency information input means for summing the frequency for each unresolved symbol Program processing equipment. The first conversion hand stage,
It includes object code output means for adding the number of occurrences of the unresolved symbols the measuring hand stage measured object code,
The second conversion hand stage,
Receiving a plurality of the object codes outputted by the object code output means, taking out the number of appearances added to the object code, and adding a frequency information input means for totaling the frequency for each unresolved symbol. The program processing device according to any one of claims 1 to 3 . The instruction means includes
The product of the code size of the instruction that operates the storage area assigned to the unresolved symbol in the absolute address format in the storage area allocating means and the number of appearances of the instruction is the relative address of the storage area assigned to the unresolved symbol. An instruction that manipulates the unresolved symbol in the relative address format when the sum of the code size of the instruction that operates in the format and the number of occurrences of the instruction exceeds the sum of the code size of the instruction that sets the relative address in the register to generate an instruction to the first conversion hand stage,
The first conversion hand stage,
Wherein when there is an instruction from the instruction means, a program processing apparatus according to any one of claims 1 to 5, characterized in that to generate an instruction for operating the unresolved symbols in relative numbers terrain type. A recording medium recording a program for converting a program composed of a plurality of source codes described in a high-level language into an executable code,
When convert said plurality of source code into a plurality of object code, a first conversion steps comprising the step of measuring the number of occurrences of unresolved symbols included in the plurality of object codes,
A second storage step of converting the plurality of object codes into the executable code and allocating a storage area to the unresolved symbols included in the plurality of object codes in descending order of the number of appearances of the unresolved symbols; a computer-readable recording medium storing a program for executing the conversion steps on a computer.

Images