JP2009258796A - Program development device and program development method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a program development device performing detection only when a register existing astride a portion of an assembly language and a register designated in the portion of the assembly language actually butt each other. <P>SOLUTION: This program development device 1 has: a parsing part 11 parsing whether a source program for an object program executed on a target processor includes at least one assignment statement directly designating a register of the target processor or not; and a detection part detecting existing section information of a register allocated with the compiled source program, and detecting whether the register allocated based on the detected existing section information exists astride at least the one assignment statement or not. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a program development device and a program development method, and more particularly to a program development device and a program development method that can detect the occurrence of register destruction.

  Conventionally, a program development apparatus is used to convert a program written in a programming language into a machine language. When a programmer creates a program using a high-level programming language, optimization of the program development device and resource allocation means determine which registers and memory areas, which are resources of the microprocessor, are allocated to variables used in the program. The Therefore, the programmer can develop the program purely on the algorithm without being aware of the resources of the microprocessor.

  However, in program development for embedded devices, etc., not all processes are created in a high-level programming language, and the programmer may have to write an assembly language corresponding to machine language instructions. This is because in the translation from the high-level programming language of the compiler itself to the machine language instruction, it is not possible to translate the processor-specific instruction. Furthermore, machine language instructions that perform a plurality of functions with one instruction cannot be written in the microprocessor. For example, even if you want to use sophisticated functions such as multimedia-compatible instructions that are common in recent years, it is not possible to write instructions using high-level programming language grammars. Or, even if it can be described, depending on the compiler, it may be difficult to translate it into machine language instructions in an efficient form.

  Therefore, in such a case, the programmer describes the program by combining a high-level programming language and a machine language in one-to-one correspondence with an assembly language that allows detailed register designation.

  In such a case, the source program described in the high-level programming language is read from the compiler, and the assembler source file described in the assembly language is read from the relocatable object generating means to obtain each relocatable object file. One absolute object file is obtained by activating absolute object generation means for these relocatable object files.

  When it is desired to mix descriptions of high-level programming language and assembly language in one file, a programmer creates a source program using an extended function of the compiler and reads it from the compiler to obtain a relocatable object file. The extended function of the compiler is a function that can use an inline assembly statement, a machine instruction function, or an assembly language function described in the assembly language so as to behave like a C language function.

  However, when using an extended function of a compiler, a programmer explicitly specifies a register name and directly describes value passing. Therefore, the programmer must understand all the types and roles of the registers used in the program. When trying to describe complicated processing, it is a heavy burden to let the programmer know the types of registers. . In addition, since a register name is specified and a value is directly set, if a programmer unfamiliar with hardware specifications or compiler operation is used, it may cause a malfunction of the program.

  The C compiler is unaware of a description in which a programmer directly designates a register, such as a register used in an inline assembly statement written in C language or an assignment expression to a register pseudo variable. In other words, if a variable used in a C language program exists across inline assembly statements, the same register as that specified in the inline assembly statement may be assigned to the variable. There's a problem. For this reason, the programmer must visually check the assembly code generated by executing the compiler to find the problematic part, and it is very difficult to find an illegal register specification.

  Therefore, a compiling device that translates a program has been proposed so that a check is not imposed on the programmer when using an inline assembly statement (see, for example, Patent Document 1).

  According to this proposal, all used parts of the dummy arguments in the intermediate program are replaced with variables, and it is checked whether these variables are alive across the assembly routines. If this variable is alive across the assembly routine, all registers specified in the assembly routine are detected, and registers other than those specified in the assembly routine are assigned to the variable.

However, the register assigned to the variable straddling the inline assembly may not be batting with the register specified in the inline assembly. For this reason, the process according to this proposal may be a useless process.
JP 2001-22591 A

  Therefore, the present invention detects only when a register that lives across the assembly language part and a register specified in the assembly language part actually batting in a program in which high-level programming language and assembly language are mixed. An object of the present invention is to provide a program development apparatus and a program development method capable of performing the above.

  According to one aspect of the present invention, it is analyzed whether or not a source program for a target program executed on a target processor includes one or more assignment statements that directly specify a register of the target processor. An analysis unit, and detecting a live range information of a register in which the source program is compiled and allocated, and whether the allocated register is alive across the one or more assignment statements based on the detected live range information It is possible to provide a program development device including a first detection unit for detection.

  According to one aspect of the present invention, it is analyzed whether or not a source program for a target program executed on a target processor includes one or more assignment statements that directly specify a register of the target processor. Detecting the live range information of a register to which the source program is compiled and allocated, and detecting whether the allocated register is alive across the one or more assignment statements based on the detected live range information A program development method characterized by the above can be provided.

  According to the present invention, in a program in which high-level programming language and assembly language are mixed, detection is performed only when a register that survives across the assembly language part and a register specified in the assembly language part actually perform batting. It is possible to realize a program development apparatus and a program development method capable of

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
(First embodiment)
First, based on FIG. 1, the structure of the program development apparatus which concerns on the 1st Embodiment of this invention is demonstrated. FIG. 1 is a block diagram showing the hardware configuration of the program development apparatus according to the first embodiment of the present invention.

  The program development device 1 according to the present embodiment is a computer device, and includes a main body device 101, a display unit 102 that displays execution results of various processes, a keyboard 103, and a mouse 104. The main unit 101 includes a central processing unit (hereinafter referred to as a CPU) 105 and a storage device 106. The storage device 106 stores a source program written in C language and assembly language. The user can designate the above-mentioned primitive program as input data by operating the input unit such as the keyboard 103 and the mouse 104 for giving various instructions to the CPU 105. By executing the program using such a program development apparatus 1, an object file to be described later can be generated from the original program.

  FIG. 2 is a block diagram for explaining a functional configuration of the program development apparatus according to the present embodiment. The program development apparatus 1 includes a syntax analysis unit 11, an intermediate code generation unit 12, an optimization / resource allocation unit 13, a debug information generation unit 14, an assembly instruction generation unit 15, a relocatable object generation unit 16, and an absolute An object generation unit 17 is included.

  The syntax analysis unit 11 performs lexical analysis, syntax analysis, and semantic analysis on the input source program 21, and stores data analyzed in a predetermined format in a part of the storage device 106. The intermediate code generation unit 12 generates the intermediate code 22 based on the result of the data analyzed by the syntax analysis unit 11.

  The optimization / resource allocation unit 13 performs optimization processing on the generated intermediate code 22 for the purpose of reducing the code size of the program and improving the execution speed, such as deletion of unnecessary code, convolution of constants, optimization of induction variables, and the like. And determine CPU resources to be allocated during program execution. The user can instruct the program development apparatus 1 for optimization items such as code size reduction and execution speed improvement by specifying options.

  The debug information generation unit 14 generates debug information from the intermediate code processed by the optimization / resource allocation unit 13 and holds the generated debug information. The debug information stored in the debug information generation unit 14 includes layout information, line number information that associates the line number of the source program 21 with each assembly instruction, names and types of functions and variables described in the source program 21, and the like. There are information on the life span information indicating the section until the variable described in the source program 21 and the variable described in the source program 21 is allocated to the CPU resource and is finally referred to. In a debug system to be described later, debug information generated by the debug information generation unit 14 is used.

  The assembly instruction generation unit 15 converts the intermediate code processed by the optimization / resource allocation unit 13 into an assembly instruction sequence that can be executed by the target processor, and generates an assembler source file 23. The assembly instruction generation unit 15 outputs the debug information generated by the debug information generation unit 14 as a data string to a corresponding location in the assembler source file 23. The assembly instruction generation unit 15 may perform optimization at the assembler level, and when optimization is performed, the debug information is also corrected.

  The relocatable object generation unit 16 generates a relocatable object file 24 from the assembler source file 23 generated by the assembly instruction generation unit 15.

  The absolute object generation unit 17 appropriately links a plurality of relocatable object files 24a generated by the above-described processing, performs final determination of symbol and variable placement addresses, and generates an absolute object file 25. The absolute object file 25 is a final type object file that can be executed on the target processor. The object file can include debug information by the user specifying an option. When debugging, the absolute object file 25 including the debug information is read into the debug system. Hereinafter, the syntax analysis unit 11 to the assembly instruction generation unit 15 are referred to as a compiler.

  FIG. 3 is a diagram showing an example of a source program written in C language. FIG. 4 is a diagram showing an example of an assembler source file obtained by compiling the source program of FIG.

  As shown in FIG. 3, the function func () is called in the main function in the source program 21 written in the C language. By compiling the original program 21 with the above-described compiler, an assembler source file 23 shown in FIG. 4 is obtained. In the assembler source file 23, a register is allocated for each variable described in the source program 21.

  $ 12 shown in FIG. 4 is a register used for the purpose of temporarily holding the calculation result. $ 1, $ 2, and $ 3 are registers that are used to pass the value set in the argument. $ 8 is a register whose value is guaranteed before and after the function func () is called. Hereinafter, a register whose value is guaranteed is called a value guarantee register. $ 0 is a register used to return a function value.

  As described above, the registers to be assigned to the variables by the compiler are not selected in order from the registers that can be used at the time of compiling, and the registers are assigned in accordance with the register usage rules defined in advance by the purpose. FIG. 5 is a diagram illustrating an example of register usage rules of the compiler.

  The register group 31 shown in FIG. 5, specifically, $ 9, $ 10, $ 11, and $ 12 are used for applications in which intermediate results of operations are temporarily placed. For these registers, if the function is called within the lifetime, the contents of the registers are not guaranteed and the values may be rewritten.

  On the other hand, the register group 32 shown in FIG. 5, specifically, $ 5, $ 6, $ 7, and $ 8 is used for the purpose of guaranteeing the contents of the register even if the function is called in the life cycle. When these registers are used in a function, the operation is such that the values of these registers are saved in the stack at the beginning of the function, and the values saved in the stack are returned to the register at the end of the function. When compiling, the compiler automatically selects an appropriate register according to the register usage rules described above. Further, when there is a value guarantee register, the compiler generates save and return codes for protecting the value.

  However, when using an inline assembly statement, an assembly language function, or the like, the compiler does not know about a description in which a user directly specifies a register. Therefore, the user must memorize the register usage rules of the compiler and write a program according to the register usage rules.

  FIG. 6 is a diagram illustrating an example of a program described using assembly language functions. As shown in FIG. 6, in the assembly language function, a register pseudo variable is used for data transfer. The register pseudo variable is R10 in the row indicated by the arrow C11. Using this register pseudo variable, the user can directly specify a register of the target processor and set a value in the specified register.

  FIG. 7 is a diagram showing an example of a source program written in C language that calls the assembly language function of FIG. As shown in FIG. 7, in the function func1 described in the C language, the function user_func () defined by the assembly language function described above is called in the line indicated by the arrow C12.

  FIG. 8 is a diagram showing an example of an assembler source file obtained by compiling the source program of FIG. This assembler source file is a file obtained by compiling the source program of FIG. 7 by the user. At this time, the compiler automatically assigns an appropriate register to the variable in the source program in accordance with the register usage rule.

  In the function user_func () shown in FIG. 6, according to the register usage rules of the compiler, the temporary registers $ 9, $ 10, $ 11, $ 12 and the value guarantee registers $ 5, $ 6 before and after the function call are changed by the user. It is specified. Therefore, when another function that calls this function user_func () uses the registers $ 5 and $ 6, the contents of the registers $ 5 and $ 6 are destroyed when this function user_func () is called. That is, when compiling for a program that calls the function user_func (), if the compiler allocates a register of $ 5 or $ 6 to a certain variable, within the called function user_func (), $ 5 and $ 6 are placed on the stack. Since the saving is not performed, the contents of the registers of $ 5 and $ 6 are destroyed by using the register specified by the user. Since $ 5 and $ 6 are value guarantee registers before and after the function call, if $ 5 or $ 6 is alive across the function user_func (), a malfunction of the program occurs.

  Therefore, when the user executes compilation, the program development apparatus 1 analyzes the source program in the syntax analysis unit 11 and detects whether there is a register pseudo variable designated by the user. When the register pseudo variable exists, the function call information obtained by the function call analysis unit is referred to and the caller function is detected. Thereafter, all registers used in each of the function in which the register pseudo-variable is used and the function that calls this function are detected.

  FIG. 9 shows the relationship between functions detected in this way and registers. FIG. 9 is a diagram illustrating an example of function call information and register usage information. FIG. 9 conceptually shows the function call structure and the used registers of the program shown in FIG. As shown in FIG. 9, the function func1 () is called from the function main (), and the function func2 () and the function user_func () are called from the function func1 (). In the function func1 (), $ 1, $ 2, $ 3, $ 5, $ 6, $ 8, $ 9, $ 12, $ 15 registers are used, and in the function func2 (), $ 1, $ 2, $ 8, $ 15 registers are used. Yes. In the function user_func (), a register specified by the user and a register allocated by the compiler are used. The register allocated by the compiler is a register used for forming a stack frame, processing a return value, and the like, and the compiler automatically generates a code. The registers specified by the user in the function user_func () are $ 5, $ 6, $ 9, $ 10, $ 11, $ 12, and the registers allocated by the compiler are $ 0, $ 1, $ 8, $ 15.

  Next, the lifetime information of all registers used in the caller function func1 () is detected. Note that the lifetime information to be detected may be only the value guarantee register. The lifetime information of this register is obtained by the debug information generator 14 as described above. FIG. 10 is a diagram illustrating an example of register lifetime information of a caller function. In this example, only the lifetime information of registers of $ 5 and $ 6 is shown. As shown in FIG. 10, the register of $ 5 is alive across the function user_func (). Therefore, if the user specifies a $ 5 register in the function user_func (), the contents of the register will be destroyed.

  In such a case, the program development device 1 performs a process of notifying the user using the display unit 102 that there is a register that is alive across the function user_func () in which the register pseudo variable is used.

  Here, the flow of processing for notifying register destruction will be described. FIG. 11 is a flowchart illustrating an example of a flow of processing for notifying register destruction.

  First, when a user designates a source program using the mouse 104 or the like and executes compilation, syntax analysis is performed from the beginning of the function (step S1), and substitution in which the user directly designates a register in the source program is performed. It is detected whether there is a sentence (step S2). Specifically, as indicated by an arrow C11 in FIG. 6, a description in which the user directly designates a register and sets a value in the designated register is detected.

  If there is no assignment statement in which the user directly specifies a register, the determination is NO and the process ends. If there is an assignment statement in which the user directly specifies the register, the answer is YES, the function call information obtained by the function call analysis unit is referred to, and the caller function is detected (step S3).

  Next, the live range of the register of the caller function is detected from the intermediate code (step S4), and it is detected whether or not the user directly designates a register in the detected live range (step S5). If the user does not directly specify a register within the life of the register of the caller function, the result is NO and the process ends. If the user directly designates a register within the lifetime of the register of the caller function, the determination is YES and the user is notified of the destruction of the register (step S6).

  As a result of the above processing, when there is a register that survives across the function for which the user directly designates the register, the program development device 1 notifies the user of the occurrence of the register destruction by calling the function. I made it. As a result, the user can recognize that the register directly designated by the user and the register that lives across the register are batting.

  Therefore, according to the program development apparatus of the present embodiment, in a program in which a high-level programming language and an assembly language are mixed, the registers that live across the assembly language part and the registers specified in the assembly language part are actually It can be detected only when batting.

(Second Embodiment)
Next, a second embodiment will be described. The first embodiment is a case where a function in which register designation by the user exists is called from a certain function. In the second embodiment, a function in which register designation by the user exists is obtained from a plurality of functions. This is the case.

  Since the configuration of the program development apparatus according to the present embodiment is the same as that of the program development apparatus according to the first embodiment, description thereof is omitted.

  FIG. 12 is a diagram illustrating an example of an assembler source file obtained by compiling with a source program described in the C language. As shown in FIG. 12, three functions of func1 (), func3 (), and func4 () call a function user_func () including a register pseudo variable.

  When the user executes the compilation, the function call information obtained by the function call analysis unit is referred to, and the function including the register pseudo variable and all the functions calling this function are detected. Thereafter, the registers used in each of the function including the register pseudo variable and all the functions calling this function are detected.

  FIG. 13 shows the relationship between functions detected in this way and registers. FIG. 13 is a diagram illustrating an example of function call information and register usage information. In this example, functions func1 (), func3, and func4 are called from the function main (). A function func2 () is called from the function func1 (), and a function user_func () including a register pseudo variable is called from each of the functions func1 (), func3 (), and func4 (). As shown in FIG. 13, the registers specified by the user in the function user_func () are $ 5, $ 6, $ 9, $ 10, $ 11, and $ 12. The registers used in the function func1 () that calls the function user_func () are $ 1, $ 2, $ 3, $ 5, $ 6, $ 8, $ 9, $ 12, and $ 15. Similarly, the registers used in the function func3 () are $ 1, $ 2, $ 3, $ 6, $ 8, $ 12, $ 13, $ 15, and the registers used in the function func4 () are $ 1, $ 2, $ 3, $ 11. , $ 12.

  By executing the processing for notifying the occurrence of register destruction described in the first embodiment for each of the functions func1 (), func3 () and func4 () detected in this way, a program development apparatus 1 can notify the user of the occurrence of register destruction.

  Next, a description will be given of a process for notifying the user that when a register is destroyed, it is necessary to save and restore the destroyed register. Here, in the function func1 (), the function user_func () is called in the lifetime of the register of $ 5, in the function func3 (), the function user_func () is called in the lifetime of the register of $ 6, and in the function func4 () Assume that the value guarantee register was not used before and after the function user_func () was called.

  In this case, in all the functions that call the function user_func (), the value guarantee registers that live across the function user_func () are only $ 5 and $ 6. In the function user_func (), since the user specifies the registers of $ 5 and $ 6, when the function user_func () is called, an operation failure due to register destruction occurs.

  Therefore, save and return codes are inserted for $ 5 and $ 6. There are two methods for inserting the save and return codes. The first is a method of inserting a save code at the beginning of the function to be called and inserting a return code at the end. In this case, $ 5 and $ 6 save codes are inserted at the beginning of the function user_func (), and $ 5 and $ 6 return codes are inserted at the end of the function user_func ().

  For example, even though the registers $ 7 and $ 8 are used in the function user_func (), the registers $ 7 and $ 8 are not used in the functions func1 (), func3 () and func4 (). $ 7 and $ 8 save and return codes are not required. Therefore, according to the first method described above, unnecessary save and restore processing can be suppressed.

  The second is a method in which a save code is inserted immediately before calling a function and a return code is inserted immediately after the function call is finished in the function caller function. In this case, in the function func1 (), a saving code of $ 5 is inserted immediately before calling the function user_func (), and a return code of $ 5 is inserted immediately after the calling of the function user_func () is completed. Similarly, in the function func3 (), a saving code of $ 6 is inserted immediately before calling the function user_func (), and a return code of $ 6 is inserted immediately after the calling of the function user_func () is completed. In the function func4 (), since the value guarantee register is not used, the save and return codes are unnecessary.

  According to the first method, when the function func4 () calls the function user_func (), the save and return codes of $ 5 and $ 6 inserted in the function user_func () are unnecessary codes. However, according to the second method, since only necessary save and return codes are inserted in the caller function, unnecessary save and restore processing can be suppressed compared to the first method.

  Here, a process for notifying whether the value guarantee register needs to be saved and restored will be described. FIG. 14 is a flowchart showing an example of the flow of processing for notifying whether saving and restoring of the value guarantee register is necessary or unnecessary. Steps S1 to S5 are the same as those in the first embodiment described above, and thus the description thereof is omitted.

  In step S5, it is detected whether or not the user directly specifies a register in the detected live range, and if the user directly specifies a register in the live range of the register of the caller function, save and restore Is notified to the user (step S11). When the user recognizes that register saving and restoring processing is necessary, the user can select an appropriate method from the above-described two saving and restoring code insertion methods, and execute the saving and restoring code insertion.

  Finally, it is detected whether all the caller functions have been checked (step S12). If all the caller functions are not checked, the determination is NO, the process returns to step S4, and the same processing is repeated. If all the caller functions have been checked, the determination is YES and the process is terminated.

  As a result of the above processing, when there is a register that exists across the function for which the user directly designates the register in the caller function, the program development device 1 causes the destruction of the register by calling the function. The user is informed that processing for saving and returning to prevent this is necessary. As a result, the user may recognize that the register directly specified by the user and the register that lives across the register are batting, and insert a save and return code to prevent the destruction of the register. it can.

  Therefore, according to the program development apparatus of the present embodiment, in a program in which a high-level programming language and an assembly language are mixed, the registers that live across the assembly language part and the registers specified in the assembly language part are actually It can be detected only when batting.

  Note that when there is a register that survives across the function for which the user directly designates the register, the program development apparatus 1 may automatically insert save and return codes for preventing the destruction of the register. Good.

(Modification)
As a modification of the second embodiment, when there is a shortage of temporary registers in the function user_func (), and unavoidably saving to the stack memory, registers that are not used before and after the function call are temporarily stored. It may be diverted as a register for use. Here, the above-described value guarantee register is used as a temporary register as a register that is not used before and after the function call. The configuration of the program development apparatus according to the present modification is the same as that of the program development apparatus according to the second embodiment, and a description thereof will be omitted.

  The temporary registers $ 9, $ 10, $ 11, $ 12 are registers whose contents may be discarded. However, since these four registers are defined as temporary registers, if four or more temporary registers are to be used, a description of a code for saving and restoring the register contents, that is, an arrow C13 in FIG. You must add the line indicated by and use four registers.

  However, if there is an unused value guarantee register in the function of the caller that calls the function user_func (), the value guarantee register can be diverted as a temporary register in the function user_func (). In addition, even if a value guarantee register is used in the caller function, if the register does not survive across the function user_func (), the value used in the caller function is similarly used. The guarantee register can be diverted as a temporary register in the called user_func () function.

  FIG. 15 is a flowchart illustrating an example of a flow of processing for diverting a value guarantee register as a temporary register. Steps S1 to S12 are the same as those in the above-described second embodiment, and thus description thereof is omitted.

  When all the caller functions are checked in step S12, it is checked whether there are any temporary registers missing in the user function, that is, in the function user_func () (step S21). If there is no insufficient temporary register, NO is returned and the process is terminated. If there is an insufficient temporary register and there is a value guarantee register that is not used in the caller's function, the information is YES and the value guarantee register can be used as a temporary register. The user is notified (step S22).

  In the example of the second embodiment described above, since the value guarantee registers $ 7 and $ 8 are not used in the caller functions func1 (), func2 () and func3 (), the functions user_func () $ 7 and $ 8 can be diverted as temporary registers. Therefore, the user recognizes that the value guarantee register can be diverted as a temporary register. As a result, the user can correct the function user_func () into an optimal code based on the notified information.

  FIG. 16 shows an example of an assembly language function program in which such processing is applied to the assembly language function program of FIG. FIG. 16 is a diagram showing an example of an assembly language function program optimized from FIG.

  In FIG. 16, a saving code for $ 5 and $ 6 as value guarantee registers is added at the beginning of the function user_func (), and a return code for $ 5 and $ 6 as value guarantee registers at the end of the function user_func (). Has been added. Further, in the line indicated by the arrow C14, a value guarantee register that is not used in the caller function is used as a temporary register. Therefore, the temporary register save and return code indicated by the line indicated by the arrow C13 in FIG. 6 can be reduced, and optimal code generation can be realized.

  Therefore, according to the program development device of this modification, unnecessary save and return codes can be reduced.

  When the value guarantee register can be diverted to a temporary register, the program development apparatus 1 may divert the value guarantee register to a temporary register and automatically correct the code to an optimum code. .

  Furthermore, this modification may be applied to the first embodiment. That is, after executing the process of step S6 shown in FIG. 11, the processes of steps S21 and S22 shown in FIG. 15 are executed. As a result, unnecessary save and return codes can be reduced as in this modification.

  The present invention is not limited to the above-described embodiments, and various changes and modifications can be made without departing from the scope of the present invention.

It is a block diagram which shows the structure of the hardware of the program development apparatus which concerns on 1st Embodiment. It is a block diagram for demonstrating the function structure of the program development apparatus which concerns on 1st Embodiment. It is a figure which shows the example of the primitive program described by C language. It is a figure which shows the example of the assembler source file obtained by compiling the source program of FIG. It is a figure which shows the example of a register usage rule of a compiler. It is a figure which shows the example of the program described using the assembly language function. FIG. 7 is a diagram illustrating an example of a source program written in C language that calls the assembly language function of FIG. 6. It is a figure which shows the example of the assembler source file obtained by compiling the source program of FIG. It is a figure which shows the example of function call information and register usage information. It is a figure which shows the example of the register lifetime information of the caller function. It is a flowchart which shows the example of the flow of a process which notifies destruction of a register | resistor. It is a figure which shows the example of the assembler source file obtained by compiling with the original program described by C language. It is a figure which shows the example of function call information and register usage information. It is a flowchart which shows the example of the flow of a process which notifies whether the saving and restoring of a value guarantee register | resistor are necessary or unnecessary. It is a flowchart which shows the example of the flow of a process which diverts a value guarantee register as a temporary register. It is a figure which shows the example of the program of the assembly language function which optimized FIG.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Program development apparatus, 11 Syntax analysis part, 12 Intermediate code generation part, 13 Optimization / resource allocation part, 14 Debug information generation part, 15 Assembly instruction generation part, 16 Relocatable object generation part, 17 Absolute object generation part, 101 Main body Device, 102 display unit, 103 keyboard, 104 mouse, 105 CPU, 106 storage device

Claims (5)

An analysis unit for analyzing whether or not the source program for the target program executed on the target processor includes one or more assignment statements that directly specify the registers of the target processor;
First detection of whether or not the allocated register is alive across the one or more assignment statements based on the detected life interval information. A detector of
A program development apparatus comprising:   The program development apparatus according to claim 1, wherein a code for saving and restoring the allocated register is generated based on a detection result of the first detection unit.   2. The apparatus according to claim 1, further comprising: a second detection unit that detects a code that uses a storage unit other than the register in the one or more assignment statements; and an output unit that outputs information on unused registers. The program development apparatus according to claim 2.   The storage unit in the code detected by the second detection unit is diverted to the unused register based on information on the unused register output from the output unit. 3. The program development apparatus according to 3. Analyzing whether or not the source program for the target program executed on the target processor includes one or more assignment statements that directly specify the registers of the target processor;
Detecting the lifetime information of a register to which the source program is compiled and allocated, and detecting whether or not the allocated register is alive across the one or more assignment statements based on the detected lifetime information. A featured program development method.

Images