JPH06250828A - Module managing system for library - Google Patents

Abstract

PURPOSE:To prevent memory occupation and overhead from being increased at the time of execution by efficiently connecting a library to an application program at the time of compiling. CONSTITUTION:This module managing system is constituted of a compiler 2 for converting a program 1 into an executable object code 5, a library 3 for sorting and storing modules to be connected to the program 1 as the 1st and 2nd module groups F1, F2 in accordance with a difference in using frequency to be forecasted and a connection control part 4 for connecting a module to the program 1 at the time of compiling or executing the program 1. The control part 4 loads only the 1st module group F1 supposed to have high using frequency from the library 3 at the time of initial compiling and connects the module group F1 to the program 1. When a connection request for a module included in the 2nd module group F2 is outputted from the program 1 at the time of executing the program 1, the necessary module is loaded from the 2nd module group F2 in the library 3 and connected to the program 1.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a technique effectively applied to a technique of combining a library with an application program at the time of compilation.

[0002]

2. Description of the Related Art In an application program, as a method of combining function library modules at the time of compilation,
The following are known: (1). Static link (combination before execution) This is a method in which all modules that may be executed are combined before execution. According to this method, the necessary modules are already combined in advance at the time of execution, so there is an advantage that the execution processing can be performed at high speed. (2) Dynamic link (execution request combination) method Each module is required at execution time. When it becomes, it is a method to load and combine it in the memory (as requested). According to this method, modules are loaded as needed at the time of execution, so expensive memory resources are not occupied by the modules that are rarely needed, and there is no freedom when writing application programs. The degree can be improved.

[0003]

However, both the static link system and the dynamic link system have the following technical problems with respect to the above advantages.

That is, in the static link system,
Since all modules are combined with the application program in advance, there is a problem that the amount of memory increases and the flexibility of program design is impaired.

On the other hand, in the dynamic link method, the module is loaded as needed, so that the memory amount can be suppressed as compared with the static link method, but the overhead of loading the module at the time of execution increases,
Execution speed could be reduced.

In Japanese Patent Laid-Open No. 2-2714030, which is one form of the dynamic link method, when a program is compiled and executed in a system in which a program and data, such as LISP, have the same syntax format, the source code is preliminarily set. It is necessary when the information about the program code that can be executed by the compiler is obtained from the program and the newly generated module is executed during the execution of the program code, and there is no newly required module in the information. There is disclosed a technique for locating such a module from a library and connecting it to the program code being executed.

According to the above-mentioned publication, a program such as LISP is limited to a language having the same syntax format as data, and a system which is originally executed under the interpreter is assumed and dynamically generated. It is designed to be compatible with the programs that are used.

Therefore, it cannot be applied to a normal compiler language such as FORTRAN or C language in which an object operates directly under the OS without control by an interpreter.

The present invention has been made in view of the above problems, and an object thereof is to efficiently combine library modules with a general-purpose application program in a compiler format.

[0010]

According to the present invention, as shown in the principle diagram of FIG. 1, a compiler 2 for converting a program 1 into an executable object code and a compiler 2 for connecting to the program 1 when the program 1 is executed. The module of
A library 3 that is classified and stored into a first module group and a second module group according to the expected difference in usage frequency.
And a coupling control unit 4 for coupling the module to the program 1 at the time of compiling or executing the program 1, and the coupling control unit 4 expects a high usage frequency from the library 3 at the time of initial compilation. Loaded only the first module group (F1) to be linked to the program 1, and
When a program included in the second module group (F2) is requested to be combined by the program 1 at the time of executing the program thereafter, a necessary module is loaded from the second module group of the library 3 to execute the program 1 To be combined with.

[0011]

As described above, the library 3 is preliminarily expected to be frequently used in the first module group (F1) and the second module group (F1) is expected to be relatively infrequently used.
2), and only the first module group (F1) is connected to the program 1 at the time of initial compilation, and the modules not connected at the time of program execution (second module group (F2)). (Modules belonging to the same), a necessary module is appropriately loaded from the second module group (F2) and coupled to the program 1 to prevent an increase in the amount of memory at the time of execution. The flexibility of can be secured.

Further, a frequently used module (F1)
Is linked to the program 1 at the time of initial compilation, it is possible to suppress an increase in the overhead of frequently loading the module when the program is executed.

Further, according to the present invention, an address table for registering each entry of the module stored in the library 3 is provided to distinguish the module group, so that the usage stored in this file can be used even though it is one library file. Modules with different frequencies (F1, F
2) can be distinguished.

In the present invention, the following modes may be prepared in advance when modules are combined, and the combination mode may be selected at the time of initial compilation. First mode: all modules of the library 3 are loaded and linked to the program 1 at the initial compilation of the program 1, second mode: modules are not linked at the initial compilation of the program 1, When there is a request from the program 1 to combine the modules included in the library 3 when the program is executed, the necessary modules are loaded from the library 3 each time the program 1 is executed.
Third mode: At the time of initial compilation by the compiler 2, only the first module group (F1), which is expected to be frequently used, is loaded from the library 3 and coupled to the program 1, and the program is executed. The second module group (F2) from the program 1
Only when there is a request to combine the modules included in the above, the necessary modules are loaded from the second module group (F2) of the library 3 and combined with the program 1.

As described above, by selecting one of the three modes in the compiling process, the modules can be loaded and combined according to the characteristics of the program, and the compiling process and the program execution process can be made efficient.

[0016]

EXAMPLE This example will be described below with reference to the drawings. FIG. 2 is a block diagram showing the functional configuration of this embodiment.

In the figure, the compiler 2 and the connection control unit 4 are normally used in a computer system.
It is set in the main control unit 6 such as a microprocessor operated by predetermined compilation software.

The application program 1 is sequentially loaded into a main storage unit (not shown) through an external storage unit such as a magnetic storage unit or an optical storage unit. The library 3 and the address table 5 are also loaded into the main storage unit (described later) by the binding control unit 4 as necessary and are linked with the application program 1.

When the application program 1 is developed, a process of modularizing a predetermined function library 3 into the application program 1 (main body) and combining them is performed. The relationship between the application program 1 and the modules is shown in FIG. Here is a brief description.

In the figure, for convenience, there are modules f1 to f4 for the application program 1 (main body).
Of these, the first module group (F1: f2, f3) is composed of modules having a relatively high possibility of being executed (frequency). Here, as the module having relatively high executability (frequency), for example, an input / output function module,
An execution area management function module and the like are included.

The second module group (F2: f1,
f4) is composed of modules having a relatively low possibility of being executed (frequency). For example, it is an exception processing function module, a special function module, or the like.

The modules (f1 to f4) described above
Can be treated as a single module file by using the address table 5 described later. In this embodiment, the following three modes are prepared as to how to handle the module when compiling the application program 1. (1). First mode (Fig. 4) This is a mode in which all possible modules (f1, f2, f3, f4) are combined before execution, regardless of the possibility of execution (frequency). Therefore, it is suitable for the application program 1 configured with relatively small steps or the application program 1 requiring high-speed processing at the time of execution. The concept of the executable (object) program 1 after compilation is as shown in FIG. (2). Second mode (FIG. 5) In this mode, the modules are combined with the application program 1 as needed at the execution stage of the application program 1 without combining any modules before execution. It is suitable for the application program 1 which has a relatively large number of steps and does not require a high processing speed at the time of execution. The concept of the executable (object) program 1 after compilation is as shown in FIG. (3). Third Mode (FIG. 6) This is a characteristic mode in the present invention. That is, at the time of compilation, only the modules (f2, f3) belonging to the first module group (F1) having a high executability (frequency) are combined with the application program 1 in advance. This mode is suitable for general application programs 1, and the modules (f1, f4) that are relatively unlikely to be executed are not combined at compile time, so valuable memory resources are used by modules that are rarely used. It can prevent being occupied. In addition, modules with high feasibility (f2, f3)
Since is already bound to the application program at compile time, it is possible to suppress the increase in overhead at the time of program execution.

In the present embodiment, when the mode selection is not designated as an option, the compile processing is performed in this mode. The concept of the executable (object) program 1 after compilation in this mode is as shown in FIG.

Which of the above three modes should be selected can be determined, for example, by adding an argument (parameter) to the compile instruction. The number of steps, the number of function call instructions, the memory occupation rate of the application program 1 and the like may be statistically processed and determined. In order to perform such statistical processing, a statistical processing section 7 may be provided in the connection control section 4 as shown in FIG.

The difference between the above-mentioned modes is specifically that each module (f1 to f1) of the address table 5 as shown in FIG.
It appears in how to rewrite the entry of fn).

This will be described with reference to the rewriting processing flow of the address table 5 at the time of compilation in FIG. First, the combination controller 4 updates (resets) the registered values of all the entries of f1 to fn in the address table 5 to "0" (step 701).

Next, the combination processing unit 4 determines which of the above-mentioned modes is selected. This mode selection is the argument (parameter) following the compile instruction as described above.
May be read to branch the process, or the process may be branched based on the output value from the statistical processing unit 7 shown in FIG.

Here, when the first mode is selected (702), at this time, f1 to f of the address table 5 are selected.
The address of each module is written in all the entries of n (703), and the executable (object) program 1 is output (704). The module whose address is registered in the entry in this manner means “with reference” for the module when the application program 1 is executed.

Next, when the second mode is selected (705), at this time, no module combination is performed at the time of compilation, so that the module remains updated in step 701, that is, all entries of f1 to fn are ". The executable (object) program 1 is output in the state of "0".

Finally, if neither the first mode nor the second mode is selected, it is determined that the third mode is selected, and the modules (f2, f2) belonging to the first module group (F1) of the address table 5 are selected. Each address is written only in the entry of f3) (706). As a result, the module (f2,
Only f3) is in the “referenced” state.

Next, the processing when the application program is executed will be described with reference to FIGS. 9 and 10. When the reference instruction of the library 3 is detected during execution of the application program 1, the main control unit 6 activates the coupling control unit 4. When the predetermined combining process is completed, the execution state of the application program 1 is restored again (FIG. 9).

FIG. 10 shows the processing flow of the connection control section 4 when the application program 1 is executed.
In order to make this processing easy to understand, it is assumed that the application program 1 in which the third mode is selected at the time of compilation and the modules (f2, f3) are combined is being executed.

First, the connection control unit uses the address table 5 of the module to which the reference instruction is given in the application program 1.
Find an entry for. Then, it is determined whether the address of the module is registered or "0" is registered in this registration value.

Here, when "0" is registered in the entry, it means that the reference of the relevant module at the time of compilation is "none", so the module of the relevant library 3 is loaded ( 102).

As in the above assumption, for example, the module to which the reference instruction is applied is compiled (before the program is executed).
If the module (f1) is not coupled to the module (f1), this module (f1) is newly loaded from the library 3 (102), and its address is registered in the corresponding entry (f1) of the address table 5. Branch to this address and execute the module (1
03).

On the other hand, in step 101, when the address of the module (for example, f2) is already registered in the entry (in the case of "with reference"), the process jumps to step 103 and is registered at the time of compilation (Fig. 7: Step 706) Branch to the address and the relevant module already linked to the application program 1 is executed (103).

According to the present embodiment, various coupling modes can be realized by changing the registration method of the address table without changing the concrete coupling means (OS) such as the linker.

Further, since the binding process is managed by the binding control means and the address table independent of the OS, the degree of freedom is higher than that when the binding process is controlled by the management mechanism under the interpreter.

[0039]

According to the present invention, the library modules of the application program in the compiler format can be efficiently combined according to the characteristics of the program.

[Brief description of drawings]

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

FIG. 2 is a block diagram showing a functional configuration of an embodiment.

FIG. 3 is an explanatory diagram showing a relationship between an application program and modules in the embodiment.

FIG. 4 is an explanatory diagram showing the concept of an executable (object) program in the first mode of the embodiment.

FIG. 5 is an explanatory diagram showing the concept of an executable (object) program in the second mode of the embodiment.

FIG. 6 is an explanatory diagram showing the concept of an executable (object) program in the third mode of the embodiment.

FIG. 7 is a flowchart showing an address table rewriting process at the time of compilation in the embodiment.

FIG. 8 is an explanatory diagram showing an address table in the embodiment.

FIG. 9 is an explanatory diagram showing a processing relationship between the application program and the connection control unit in the embodiment.

FIG. 10 is a flowchart showing the processing of the join processing unit in the embodiment.

FIG. 11 is a block diagram showing a modification of the functional configuration of the embodiment.

[Explanation of symbols]

 1-Program 2-Compiler 3-Library 4-Coupling control unit 5-Address table 6-Main control unit 7-Statistical processing unit

Claims (4)

[Claims] 1. A compiler (2) for converting a program (1) into an executable object code, and a module for coupling the program (1) at the time of execution of the program (1) with a difference in expected frequency of use. The first module group (F1) and the second module group (F
A library (3) classified and stored in 2), and a coupling control unit (4) for coupling the module to the program (1) when the program (1) is compiled or executed. The section (4) loads only the first module group (F1) which is expected to be frequently used from the library (3) at the time of compilation by the compiler (2) and combines it with the program (1). , Required from the second module group (F2) of the library (3) when the program (1) requests the combination of the modules included in the second module group (F2) during the subsequent program execution. Module management method of library (3) that loads various modules and combines them with program (1). 2. The combination control unit (4) loads the all modules of the library (3) at the time of compiling the program (1) in the following combination mode, that is, the first mode: 2nd mode: The module (1) is not linked at the time of compiling the program (1), and a request to link the modules included in the library (3) is issued from the program (1) when the program is executed. Whenever there is, a necessary module is loaded from the library (3) and combined with the program (1). Third mode: a high usage frequency is expected from the library (3) when compiling by the compiler (2). Only the first module group (F1) to be loaded and linked to the program (1), Only when there is a request from the program (1) to combine the modules included in the second module group (F2) during execution of the program, the necessary modules are loaded from the second module group of the library (3). 2. The library module management method according to claim 1, wherein the connection processing is executed in any one of the modes by executing the connection processing according to any one of the modes. 3. The combination control unit (4) comprises an address table (5) for registering each entry of a module stored in the library (3), and the address table (5) registers the entry value of the entry at the time of execution of a program. 3. The library module management method according to claim 1, wherein it is determined whether or not to load the module. 4. The connection control unit (4) comprises a statistical processing unit (7) for monitoring the characteristics of the program (1), and the address table (5) is output according to the output result of the statistical processing unit (7). 4. The module management method of the library according to claim 3, wherein the registered value of the entry of [1] is changed.