JPH03177930A - Compiling code generation processing method - Google Patents

Abstract

PURPOSE:To ensure the reference to the names of arguments at debugging without deteriorating the program executing speed by allocating a table holding the names and values of arguments and a table holding the names and values of variables to the different areas respectively. CONSTITUTION:A function definition table 11 for compiling codes consists of a function header 1 which holds the definition information on the functions, a variable table 2 which holds the names of variables, an argument table 3 which holds the names of arguments, and the execution codes 4 which describe the processings carried out by the functions. When the function of a list processor Lisp is compiled, the index value showing a symbol is registered into the table 3 as long as an argument is included in a declaration sentence of a function source code. Meanwhile the index value showing a symbol is registered into the table 2 if a variable is included into the declaration sentence respectively. In such a constitution, an argument is transferred at a high speed for call of a function at execution. Furthermore the labor and the time can be reduced at debugging since the easy reference is possible to the names of arguments.

Description

[Detailed Description of the Invention] [Industrial Application Field] This invention is based on Li5p (List Process
The present invention relates to a compiled code generation processing method when compiling functions of a functional language such as er).

[Conventional technology]

Li5p is a functional programming language developed for the purpose of list processing, and is mainly used in the field of artificial intelligence research. Recently, it has also attracted attention as a description language for expert systems. The basic structure of Li5p is a binary tree consisting of two branches, and by combining these binary trees, a list of data (
information storage format). Therefore, all relationships between data are expressed by lists. L
Functions (programs) created by i5p are processed by a compiler to generate compiled code (object program).

[Problem to be solved by the invention]

By the way, in the compiled code generated by conventional compilers, addresses for referencing the values of arguments that are local variables are saved, but the names of the arguments are not saved. Therefore, the user has to check the name of the argument in the part where the error occurred while looking at the source program, which poses a problem in that debugging requires a lot of effort and time.

Although the name of the argument can be saved in the compiled code, the volume of the compiled code increases, resulting in a decrease in the execution speed of the program.

SUMMARY OF THE INVENTION An object of the present invention is to provide a compiled code generation processing method that makes it possible to refer to argument names during debugging without reducing program execution speed.

[Means for Solving the Problems] and [Operation] The compiled code generation processing method according to the present invention includes a table that holds names and values of arguments that are local variables in the definition information of a function such as Li5p; Tables that hold the names and values of variables, which are entry variables, are allocated to different areas.

To refer to the value of an argument at runtime, refer to the pointer in the argument area of the stack frame, and refer to the object pointed to by that pointer. To refer to the value of a variable, refer to the pointer in the variable area of the stack frame, and then refer to the object pointed to by that pointer.

On the other hand, during debugging, the value of the argument refers to the pointer to the argument in the stack frame. The name of the argument refers to the table of arguments in the function definition, and the index to the symbol refers to the symbol table. Also, the value of the variable refers to the pointer to the variable in the stack frame. The variable name refers to the variable table of the function definition corresponding to the stack, and the symbol table is referenced based on the index to the symbol. The name field in the symbol table is the name of the variable.

〔Example〕

An embodiment of the compiled code generation processing method according to the present invention will be described below. Note that in the following explanation, local variables are referred to as arguments, and entry variables are referred to as variables.

FIG. 1 is an explanatory diagram showing an overview of compiled code generated when a Li5p function is compiled in the compiled code generation processing method according to the present invention. The function definition table 11 in the compiled code is
A function header 1 that holds function definition information, a variable table 2 that holds variable names, an argument table 3 that holds argument names, and an execution code 4 that describes the processing that the function executes. It is configured. When compiling a Li5p function, first determine whether the declaration statement of the function source code contains arguments or variables, and if it contains arguments, add symbols to argument table 3. The index value (pointer) indicating the symbol is registered, and when a variable is included, the index value indicating the symbol is registered in the variable table 2.

There is a symbol table 12 as information generated together with the function definition table 11. The symbol table 12 is a table for storing the name, property (attribute), value, and function definition of each symbol (in other procedural languages, the symbol name is equivalent to the name of a variable). handle). Also, properties are data attached to a symbol, and values are data obtained when the symbol is evaluated (same as the value of a variable in a procedural language).

To explain the definition of the function in Figure 1, for example, “Plus
Suppose there is a function named (this function takes two arguments and uses one variable), the definition information for this function is in the function definition table 11,
The symbol “Plug” for calling this function is in the symbol table 12. Also, the symbol “Plus” is in the symbol table 12.
The “Function Definition” field is Function Definition Table 1.
1 "Plus" entry (the entrance part of the function definition of P 1 u s).

References from the function definition table 11 to the symbol table 12 include those pointing to definitions of symbols of function arguments and variables, that is, the "index to symbol" field in the argument and variable items. Also, from the symbol table 12 to the function definition table 1
1 in the symbol table 12.
There is a "Function Definition" field. However, if there is no function with the name of the symbol, the "Function Definition" field does not point to the function definition table.

For example, in the case of the symbol "X" in FIG. 1, there is no function named X, so the "Function Definition" field of the symbol "X" does not point to any field in the function definition table 1. Note that the reference from the symbol table 12 to the function definition table 11 occurs, for example, when the user inputs the formula 8 to directly call a function, or when a function is further passed as an argument to the function.

FIG. 2 is an explanatory diagram showing an overview of the stack when a function is executed. The stack is separated from the stack frame of the executing function and the work area of that function. Further, in the stack frame of a function, an argument area 5, a function definition and execution state area 6, and a variable area 7 are arranged in order from the bottom of the stack. FIG. 2 shows a state in which stack frames for function A and function day are stacked.

When a program is executed, each time a function is called, a stack frame for each function is placed on the stack. When a function is called, the function definition of the stack frame of the called function and the address of the start of the execution state area 6 (ALink in this example) are passed. Therefore, when a function is executed, the definition of the function and the address of the area 6 in the execution state are always known. Further, the number of fields included in the function definition and execution state area 6 is fixed, and which field corresponds to which element is also fixed.

Next, in the compiled code mentioned above, the processing procedure when referring to arguments and variables during program execution is explained in the first section.
The process will be explained based on the flowcharts in FIGS. 3 and 4 while referring to FIGS.

FIG. 3 is a flowchart showing a processing procedure when referring to argument values during execution. To access the argument, subtract 1 from the address of the start (ALink) of the function definition and execution state area 6 in the stack frame to obtain the address of the pointer to the "start of argument area" of argument area 5. (Step 101). Then, add the offset from the beginning of argument area 5 to "the beginning of argument area 6",
“Get the address of the pointer to the argument” (step 10
2). For example, for the first argument, the offset is O, so it is the "start of the argument area" + 0, and for the third argument, the offset is 2, so it is the "start of the argument area".
It becomes +2.

Next, from the address obtained in this way, refer to the "pointer to the argument" in the argument area 5.
03), refers to the object pointed to by the pointer to the argument (step 104). Note that the only information about the argument required during execution is its value, and the name is not referenced.

FIG. 4 is a flowchart showing the processing procedure when referring to variable values during execution. When referencing the value of a variable, first calculate the next address at the end of area 6 of the function definition and execution state in the stack frame (step 2).
01). For example, if the size of function definition and execution state area 6 is fixed and the size is F, then variable area 7
The first address is the first address 10F of the function definition and execution state area 6.

Next, to the address of the start of variable area 7 obtained in this way, add the offset from the start of variable area 7 depending on the number of the variable to obtain the address of the pointer to the variable ( Step 202). Then, the pointer to the variable is referenced from this address (step 203), and the object (data) pointed to by the pointer to the variable is referenced (step 204). Note that the only information about a variable required at runtime is its value, and the name is usually not referenced.

When debugging a function, a debugger looks inside the stack, follows pointers that indicate function call relationships, and refers to the stack frame of each function. A pointer indicating a function calling relationship points to the beginning of an area 6 of the function definition and execution state in the function stack frame. Therefore, when debugging, the definition of the function and the address of the execution state area 6 are always known.

Next, the processing procedure when referring to arguments and variables when debugging a program will be explained based on the flowcharts of FIGS. 5 and 6.

FIG. 5 is a flowchart showing the processing procedure when referring to the name of an argument during debugging. When referencing the name of an argument, first add 2 to the address of the function definition and execution state area 6 in the stack frame to obtain the address of the "pointer to the function definition" (step 301). Then, from this address, the "pointer to function definition" is referenced (step 302), and the definition of the function pointed to by the "pointer to function definition" is referenced (step 303).

Next, the function header size (fixed value) and the number of variables x 2 are added to the start address of the function definition to obtain the start address of argument table 3 (step 304). Next, an offset is added to the first address of argument table 3 to obtain the address of the index to the symbol of the argument to be referenced (step 305). Furthermore, refer to the index to the symbol of the argument you wish to refer to in step 306.
), the definition in the symbol table pointed to by the index is referenced (step 307). Then, the name area of the symbol definition is referred to (step 308). Note that when referring to the value of an argument during debugging, the same processing as during execution (FIG. 3) is performed.

FIG. 6 is a flowchart showing the processing procedure when referring to variable names during debugging. To refer to the name of a variable, first set a fixed offset (
-2) to obtain the address of the "function definition pointer" (step 401). From this address, refer to the "pointer to function definition" (step 402), and refer to the definition of the function pointed to by the "pointer to function definition" (step 402).
Step 403). Then, the size (fixed value) of the header of the function is added to the start address of the function definition to obtain the start address of variable table 2 (step 404). Next, an offset is added to the first address of variable table 2 to obtain the address of the index to the symbol of the variable to be referenced (step 405). Furthermore, refer to the index to the symbol of the variable you want to refer to in step 4.
06), refers to the definition in the symbol table pointed to by the index (step 407). Then, refer to the name area of the symbol definition (step 408).
. In addition, when checking the value of a variable during debugging,
The same processing as during execution (Fig. 4) is performed.

According to the above method, for example, when calling function B from function A, the argument of function B is evaluated, the result is placed on the stack, and function B is activated. Function B is evaluated in the work area after the stack frame of function A (see FIG. 2). When an argument is evaluated using the stack, the result (pointer to the argument) remains in the Top of 5tack. When the arguments of function B are evaluated in order, the result is that the argument pointers are arranged on the stack in order. This can be used as the stack frame argument area for function B, and there is no need to add new arguments to the stack. Therefore, there is no need to copy extra arguments, making it possible to speed up function calls.

〔Effect of the invention〕

As explained above, according to the compiled code generation processing method according to the present invention, a table that holds argument names and values and a table that holds variable names and values are allocated to different areas in the compiled code. Therefore, at runtime, passing arguments when calling a function can be passed faster. Furthermore, since the name of the argument can be easily referenced during debugging, it is possible to significantly reduce the effort required during debugging.

[Brief explanation of drawings]

Figure 1 is an explanatory diagram showing an overview of the compiled code generated when a Lisp function is compiled, Figure 2 is an explanatory diagram showing an overview of the stack when the function is executed, and Figure 3 is an explanatory diagram showing the outline of the stack when the function is executed. Figure 4 is a flowchart showing the processing procedure when referring to a value, Figure 4 is a flowchart showing the processing procedure when referring to the value of a variable in the execution samurai, and Figure 5 is the processing when referring to the name of an argument during debugging. Flowchart showing the procedure. FIG. 6 is a flowchart showing the processing procedure when referring to variable names during debugging. 1...Function header, 2...Variable table, 3...
・Argument table, 4...Execution code, 5...Argument area, 6...Function definition and execution state area, 7...
Variable area, 11...Function definition table, 12...
symbol table. Figure 3 Figure 4

Claims (1)

[Claims] In a compiled code generation processing method for generating compiled code by compiling functions of a functional language, a table holding argument names and values and a table holding variable names and values are included in the compiled code. A compiled code generation processing method characterized in that the compiled code is allocated to different areas within the code.