JPH08179964A - Program checking method - Google Patents

Abstract

PURPOSE: To remarkably reduce quantity to be described additionally in a source program by inserting the processing of user procedure by which a routine or function of user definition is called into another routine or the just before position or immediately behind position of the function. CONSTITUTION: A user who desires to obtain information with respect to each routine or function inserts and defines only a specific routine or function (the routine or function of user definition) into the source program (100). When the routine or function of user definition is described, the processing of user procedure is inserted into another routine or the just before position or immediately behind position of the function (102). In such a way, the routine or function of user definition is called by the processing of user procedure, therefore, the user can confirm the information with respect to a sub-routine or function without describing processing for program check at every sub-routine or function.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION The present invention relates to a method for checking a program for debugging and tuning.

When a program is debugged or tuned, contents for outputting information on each routine and function existing in the program are described in the source program in advance.

[0003]

2. Description of the Related Art When the first arbitrary process (step 202) in FIG. 2 is completed, a preprocess (step 204) is performed, and then a subroutine (function) is called (step 206).

In the called subroutine, preprocessing (step 208) is performed, and then its main body processing (step 210) is started. When the main body processing (step 210) of the subroutine is finished, postprocessing of the subroutine (step 212). ) Is performed and then an arbitrary process (step 21)
4) is started.

Preprocessing of subroutine (step 204)
In the source program part regarding, the contents of performing the initialization of the preprocessing (step 208) in the subroutine by collecting the line number of the subroutine call, acquiring the elapsed time immediately before the subroutine call, are described.

In the source program portion related to the pre-processing (step 208) in the subroutine, the contents for outputting the subroutine name and arguments are described (see FIGS. 3 and 4), and the source program related to the post-processing of the subroutine (step 212). In the part, the contents of acquiring and outputting the elapsed time after calling the subroutine and the number of operations in the subroutine are described.

The user who created this program debugs and tunes the program using the output information.

[0008]

Conventionally, in debugging or tuning a program, a program check process (pre-processing, pre-processing in a subroutine, post-processing) is described in a source program in advance for each subroutine (function), In addition, since it is necessary to delete these unnecessary descriptions after that, time and labor are spent on the program development.

The present invention has been made in view of the above conventional circumstances, and an object thereof is to provide a method capable of significantly reducing the amount of additional description in a source program.

[0010]

In the first aspect of the invention shown in FIG. 1, a user-defined routine or function having a process of collecting information regarding a plurality of routines or functions included in a source program as to other routines or functions. (Step 100) and insert the processing of the user procedure in which the user-defined routine or function is called at the position immediately before and after the other routine or function (step 10).
2).

In the second aspect of the present invention shown in FIG. 1, a user-defined routine or function whose content is a process of collecting information about another routine or function is retrieved from a plurality of routines or functions included in the source program (step 10).
0), the process of the user procedure in which one or both of the user-defined routine or function and the performance evaluation process of the other routine or function is called according to the user instruction is performed to the position immediately before or after the other routine or function. Insert (step 102).

[0012]

A user who wants to obtain information about each routine or function inserts and defines only a specific routine or function (user-defined routine or function) in the source program.

When this user-defined routine or function is described, the processing of the user procedure is inserted at the position immediately before and after the other routine or function. In the first invention, the user-defined routine or function is called in the processing of the user procedure, and therefore the user confirms the information regarding the subroutine or function without describing the processing for program check for each subroutine or function. It becomes possible.

In the second aspect of the invention, either or both of the user-defined routine or function and the performance evaluation process of the other routine or function are called by the process of the user procedure according to the user's instruction.

The performance evaluation process has contents such as the time elapsed after calling the routine or the function and the number of operations in the routine or the function, and outputs the result. The user evaluates the routine or the function defined by himself and the performance evaluation. The processing can be arbitrarily selected.

The user procedure process and the performance evaluation process are prepared in advance in the form of source, object, etc., and can be inserted into the program file of the source, object by file process, compile process, etc.

When the program debugging or tuning work is completed, the program can be sped up by deleting the user-defined routine or function from the source program.

[0018]

EXAMPLE In FIG. 5, a keyboard 500, a display 502, and a hard disk 504 are connected to a computer main body 506, and a user operates the keyboard 500 to confirm the display on the display 502.

An editor, a compiler, and a library of dynamic link routines are prepared on the hard disk 504. The user starts up the editor to create a source program, uses the compiler to generate the load module from the source program, and loads it. The module references a dynamic link routine.

An example of the source program is shown in FIG. 6 and FIG. 7, and the user selects the subroutine USER_DEFI.
NED_PROC, function user_defined_p
Only loc_ (user-defined routine or function) is added and described in the source program in advance.

In FIGS. 6 and 7, the character strings N, n
Indicates a subroutine SUB and a function sub, and variables L and l
Indicates the line number, and integer flags F and f indicate the subroutine US
ER_DEFINED_PROC, function user_de
The operation mode (contents of display output) of fined_proc_ is determined.

In FIG. 8, the compile process in this embodiment is described with reference to a flowchart. In FIG. 8, it is first determined whether or not the debug compile switch is turned on (step 800).

When the judgment result indicating that the debug compile switch is turned on is obtained, the library call instruction is inserted at the entry position and the exit position of the subroutine (or function) (step 801: user procedure Processing is inserted immediately before and after other routines or functions).

When the judgment result indicating that the debug compile switch is not turned on is obtained, the library call instruction is not inserted at the entry position and the exit position of the subroutine (or function) and the user-defined Routine or function (subroutine U in FIGS. 6 and 7)
SER_DEFINED_PROC, function user_d
Regardless of whether "defined_proc_) is additionally described in the source program, the normal load module generation processing is simply performed (step 803).

When the result of the judgment indicating that the compile switch for debugging is turned on is obtained and the library call instruction is inserted, it is judged whether or not the static link should be performed (step 804).

When a judgment result indicating that static linking should be performed is obtained, a debug function prepared in advance on the compiler side (processing for performance evaluation: time elapsed after calling routine or function or routine or function A process of combining the contents such as obtaining and outputting the number of operations is performed (step 805).

Further, it is judged whether or not the user-defined routine or function exists in the form of the source or the object (step 806), and if the judgment result indicating the existence is obtained, the load module including the judgment result is included. Is generated (steps 807 and 803).

Further, when the judgment result indicating that there is not exists, the load module including the routine or function having the name assigned to the user-defined routine or function, which has the contents that no processing is performed, is executed. It is generated (steps 808 and 803).

When the result of the judgment that the dynamic link is to be obtained is obtained (step 804), the user-defined routine or function is compiled separately from the main body of the source program (step 803), and the dynamic link Routine.

In FIG. 9, the load module execution processing is explained using a flowchart.
First, it is determined whether dynamic linking is performed (step 900).

If dynamic linking is not performed, it is determined whether or not the library debug switch is turned on when the program is started (step 901). When it is turned on, the debug function is set. When it is not turned on, the debug function is set by the user. A routine or function is selected (steps 902, 903).

Even when dynamic linking is performed, it is determined whether the library debug switch is turned on when the program is started (step 904), and the existence of a dynamic link routine generated from a user-defined routine or function. Presence / absence is determined (step 905).

When dynamic linking is performed,
When the library debug switch is turned on when the program is started, the debug function of the dynamic link routine is referred to (step 906).

When dynamic linking is performed,
If the library debug switch is turned on when the program is started and there is a dynamic link routine generated from a user-defined routine or function, this user-defined routine is referred to (step 907).

When dynamic linking is performed,
If the library debug switch is turned on when the program is started, and there is no dynamic link routine generated from the user-defined routine or function, the contents of the user-defined routine or function will not be processed. The dynamic link routine with the given name is referred to (step 908).

FIG. 10 illustrates the operation of this embodiment (see FIG. 2). In FIG. 10, when the subroutine process (step 210) is called (step 20).
6) Before the subroutine processing (step 210), the user-defined subroutine (step 1002) or the debug processing (step 1004) is started in the library entry processing (library call instruction / user procedure processing: step 1000). To be done.

The subroutine process (step 210) is started after the user-defined subroutine (step 1002) or the debug process (step 1004) is completed, and when the subroutine process (step 210) is completed, the library exit process (library) is started. Call command / user procedure processing: In step 1006), a user-defined subroutine (step 1002) or debug processing (step 1004) is started.

As described above, only a specific routine or function (user-defined subroutine or function) is to be added and described in the source program in order to obtain information on each routine or function in the program. As a result, the burden on the user during debugging and tuning work is greatly reduced (see FIGS. 2 and 10).
reference).

Furthermore, it is possible to select whether to display and output the information regarding each routine or each function or whether to display and output the execution time or the number of operations of each routine or each function with an option switch at the time of starting the program.

Then, only by changing the compile switch, it becomes possible to speed up the program while suppressing these outputs. Further, by changing the flag values in FIGS. 6 and 7, each routine can change the display content of the information regarding each function to an appropriate one.

[0041]

As described above, according to the present invention, the source program for displaying and outputting the information regarding each routine or each function in the program and for displaying the execution time and the operation number of each routine or each function are displayed. Since only a specific routine or function (user-defined subroutine or function) should be additionally described, which is a small amount, the burden on the user during debugging or tuning work can be significantly reduced and the program It is possible to significantly improve the development efficiency.

Further, in order to execute a high-speed program, it is only necessary to retranslate the program, so that the burden on the user can be reduced in that respect as well.

[Brief description of drawings]

FIG. 1 is a diagram illustrating the principle of the invention.

FIG. 2 is an explanatory diagram of a conventional technique.

FIG. 3 is an explanatory diagram of a conventional source program.

FIG. 4 is an explanatory diagram of a conventional source program.

FIG. 5 is a diagram illustrating the configuration of the embodiment.

FIG. 6 is an explanatory diagram of a source program according to the embodiment.

FIG. 7 is an explanatory diagram of a source program according to the embodiment.

FIG. 8 is a flowchart illustrating a compiling process according to the embodiment.

FIG. 9 is a flowchart illustrating a program execution process of the embodiment.

FIG. 10 is an explanatory view of the operation of the embodiment.

[Explanation of symbols]

 500 keyboard 502 display 504 hard disk 506 computer body

Claims (2)

[Claims] 1. A user procedure routine or function having a process of collecting information on transition / return from a plurality of routines or functions included in a source program to another routine or function is searched, and the user procedure routine or function is searched. A program check method, characterized in that a called process of a routine or function is inserted at a position immediately before and after another routine or function. 2. The program check method according to claim 1, wherein the information collection process is a performance evaluation process.