JPH01207824A - Module coupling control system - Google Patents

Abstract

PURPOSE:To attain a system to make a dynamic coupling high speed by batch- loading without changing the relative inter-information positional relation in a load module library. CONSTITUTION:A load module library stored in a load module library 14 is not loaded independently on executing, and the whole library 14 is batch-loaded at a batch loading processing part 12. Then, the relative positional relation between respective information areas on the medium of an external storage 13 is not changed. Since a dynamic coupling is made possible, the entry point address of a module substance part 17B is found from a module substance part 17A of a calling source through a module information part 16B of a calling destination load module B, and a branch instruction is embedded in a linkage part 19. When the information part 16B referred on calling does not exist inside the library on the preparing of a load module A, only the frame of the information part 16B is prepared on the preparing of the substance part 17A.

Description

[Detailed Description of the Invention] [Summary] This invention relates to a module coupling control method that speeds up dynamic coupling by loading information in a load module library all at once without changing the relative positional relationship between each piece of information. .

The purpose is to increase the independence of individual modules and to provide a means to improve the execution performance of dynamic linkage. A library editing section that creates a load module library that has a plurality of module entity sections storing module information sections, and a batch loading module that loads a plurality of module information sections and module entity sections without changing the relative positional relationship between each information area. It is equipped with a loading processing section and a linkage section that has an instruction code in the module entity section that refers to the module information section corresponding to the called module and directly or indirectly branches to the called destination. Configure for dynamic joins.

[Industrial application field]

The present invention relates to a module combination control method in a data processing system that dynamically combines a program developed by dividing it into a large number of modules at the time of execution. The present invention relates to a module connection control method that speeds up dynamic connection by loading all at once without changing relationships.

[Conventional technology]

FIG. 12 shows an example of conventional module combination.

Programs in the information processing field are developed by being divided into a large number of modules. These divided modules are 2 e.g. COB OL.

They are translated separately using a language to machine language translation program such as FORTRAN, and further converted into a load module that is an executable format.

The combination of these separately developed modules includes:
Traditionally, there are two types of reviews.

One of them is a form in which modules A and B in load module 1 shown in FIG. 12 are previously combined into one load module by a combination editing program (linker) before execution. The other method is to search for load modules necessary during operation, such as load module 1 and load module 2 shown in FIG.

It is a form of loading and combining. The former is called static binding, and the latter is called dynamic binding. The characteristics of static binding and dynamic binding are as follows.

(・]) When executing static binding, the address of the module at the destination of one branch has already been determined, so there is no intervention by the supervisor.

Therefore, it is fast. On the other hand, each time a module is modified, it is necessary to recombine it, including modules that have not been modified, which makes it difficult to develop or modify a program.

(bl) Dynamic coupling causes branching between different modules, so the program management functions of the supervisor such as searching for a load module and loading the load module are required at runtime, resulting in poor execution performance.On the other hand, when modifying a module, etc. is easy to use because it does not affect other modules.

[Problem to be solved by the invention]

An object of the present invention is to solve the problems in the conventional static coupling and dynamic coupling described above, to increase the independence of individual modules, and to provide a means for improving the execution performance of dynamic coupling.

[Means to solve the problem]

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

In FIG. 1, 10 is a processing device including a CPU and memory, 11 is a library editing section that creates a load module library, 12 is a bulk loading processing section that loads the contents of the load module library all at once, and 13 is a magnetic disk device. 14 is a load module library storing a plurality of separately developed modules, 15 is a space management unit containing space management information in the load module library 14, 16A, 16B, . . . are each module Module information with entry point address information 'Full, 1
7A, 17B, ... are the programs of each module.
A module entity part 18 has code information, a loading area on memory, and a linkage part 19 has an instruction code for branching to another module.

The library editing section 11 has a function equivalent to a conventional combination editing program, and the load module library 14 that can store a large number of load modules is not in the format of a single partitioned file.

It has a processing function that creates sequential files.

The load module library 14 in the present invention has a module information section and a module entity section for each module, and the module information section stores information such as module attributes, entry point address 5 module name, etc. It has become so. In particular, the entry point address that is a branch destination from another module is set as an in-file relative address in the zero-to-module library 14.

When executing a program, the batch loading processing unit 12 stores the contents of the load module library 14 in memory without changing the relative positional relationship between each information area.
In the second loading area 18.

It performs the process of loading all files at once.

As shown in FIG. 1(A), the module information section 16A has the population point address of the module entity section 17A as an 8-file relative address, and the module information section 16B has the entry point address of the module entity section 17B. . When load module A calls 5m1-to module B, the module entity section 17A contains the following information by referring to the entry point address in the module information section 16B.
A linkage unit 19 is provided that has an instruction code that branches to the population point of load module B directly or via an instruction in a memory fixed area. At the time of execution, by branching from this linkage section 19 to the load module B of the module entity section 17B.

Perform dynamic joins.

[Effect]

The load modules stored in the load module library 14 are not individually loaded during execution, but the entire load module library 14 is loaded at once by the -batch loading processing unit 12. Therefore, the relative positional relationship between each information area on the medium of the external storage device 13 remains unchanged even after loading. Based on this, in order to enable dynamic coupling, the entry point A)/response of the module entity section 1713 is sent from the calling module entity section 17A via the module information section 16B of the called load module B. Find and branch instructions.

It is embedded in the linkage part 19.

If the module information section 16B referred to at the time of calling does not exist in the library when creating the load module, only the frame for the module information section 16B is created when the module entity section 17A is created. This results in
Even if each load module is developed individually, the entry point address can be referenced from the linkage unit 19.

The positions of the module information section 16A, module information section 16B, etc. do not change even if the modules in the module entity section are replaced. Therefore, the impact of module modification is
You can take advantage of the advantage of dynamic binding, which does not affect other calling modules.

For example, as shown in FIG. 1(B), suppose that the module entity section 17B is moved to the module entity section 17B1 due to modification of the 5 load module B.

-8= At this time, if only the contents such as the population point address are changed without changing the position of the module information section 16B, there is no need to modify the module entity section 17A which is the calling source.

If the called destination is configured in a write-protected section, for example, there is no need to go through the supervisor during execution, so dynamic linking can be achieved with an overhead of about 10 steps at most. Even when the call destination is a writable section, there is no need to perform Ilo to the external storage device 13 during execution, so speeding up is possible.

Note that even if the load module library 14 is a sequential file, the user view can be made no different from that of a conventional load module library.

〔Example〕

FIG. 2 is a configuration example of a module information section, and FIG. 3 is an explanatory diagram of an entry point address according to an embodiment of the present invention.

4 and 5 are explanatory diagrams of module creation according to an embodiment of the present invention, FIG. 6 is an explanatory diagram of module replacement according to an embodiment of the present invention, and FIG. 7 is an explanatory diagram of module replacement according to an embodiment of the present invention. FIGS. 8 to 11 are explanatory diagrams for explaining the process of the linkage part, and are diagrams for explaining the dynamic coupling according to an embodiment of the present invention.

The configuration of the module information section provided for each module is as shown in FIG. 2, for example. This module information section 16 includes storage areas for module attribute information, entry point address information, module name information, and the like.

In the module attribute field, there is a flag indicating whether the entry point is a write-protected section or a writable section with initial values, and a flag indicating whether the module entity is in the library or not. . If the section including the entry point is a write-prohibited section, it is protected on virtual memory 4Q. On the other hand, if it is @readable, it cannot be shared with programs running on other CPU execution rights on the virtual memory. In other words, when operating in multitask mode, the program cannot be shared with other tasks, so in this case, control must be passed to the program management section of the operating system (O8) supervisor, and the decision-making process is For this purpose, the attribute's flags are referenced. Also, when the attribute indicates that there is no entity, control is transferred to the program management section.

The entry point address in the module information section 16 is as shown in FIG.
It is set as an in-file relative address (displacement) α from the beginning or a predetermined position in the load module library 14.

In order to increase the independence of modules that are created separately, in the process of link editing (linker), how can the connections between load modules that are created in random order be made without contradiction?
The problem is how to combine them in the processing at each time, but in the present invention, the problem is solved as explained in accordance with FIGS. 4 to 6.

The following description will be made assuming that the calling module is CALLING, and the calling modules are CALI and ED.

In Figure 4, CALLING is created first and CA is created later.
An example of creating LLnD is shown.

When creating CALLING, CALLED does not exist in the load module library 14. Therefore, when creating CALLING, the module information section 16A and module entity section 17A are created, and only the module information section 16B for CALLED is created. The entry point address in the module information section 16B is set to "0", and the attribute is set to "no entity".

Then, from the linkage part 19 of CALI and TNG,
The module information section 16B is made referenceable.

Next, when creating the CAI ED, since the module information section 1.6B frame has already been created, create the module entity section 17B, and then create the module information section 16B.
The entry point address of is updated to β, which is the relative address of the entry point in the module entity section 17B, and the attribute is set to "substantive". Whether the module information section 16B has already been created or not can be determined by searching the library using the module name. Module information section 1
Since the position of 6B does not change, the relationship with CALLING will not collapse.

In contrast to FIG. 4, FIG. 5 shows an example in which CALLHD is created first and CALLING is created later.

Assuming that CAI and LED are not calling other modules, they create only their own module information section 1.6B and module entity section 17B, and set their entry point address in the module information section 16B. Next, CIIL
When creating a LING, the module to be called (CAL
Since the module information section 1'6A and the module entity section 17A are created, a pointer is set from the linkage section 19 to the module information IEt section 16B.

By the above processing-)7. CALLING and CALLE
No matter which one is created first, the connection relationship between them can be the same.

FIG. 6 shows an example in which an existing CALLED module is replaced with a new module for modification.

The storage area of the module entity section 1.7B in the load module library 14 is
As shown in the figure, a size (C1) larger than the actual size ta+ is reserved in advance. This allows the module to be modified to a binary size (a size larger than 81 (b
Even if the storage area becomes 1, if it is smaller than the storage area size (C), the 1-element storage area can be used as is.

If the corrected entity becomes the size of the binary storage area (a size larger than C1 (dl), an even larger size x [
Load the storage area with el rc module live-7'
It is secured in another position within J14 and a new module entity part 17B1 is created there. The module information section 16B is used as is, and its entry point address information etc. are updated in accordance with the module entity section 17B1. The storage area of the original module information section 16B will be used as a storage area for other programs that will be created or modified later.

In either case, the module information section that may be referenced from other modules], 6B.

Since its position remains unchanged, modules can be replaced without conflict.

The files of the load module library 14 are:

For example, use Hyde's block on block 4 for example. The linker edits the library.

If you want to replace Hyde entirely in Part 4.

Write Hyde's data as is into Part 4. If only the - part is to be replaced, the corresponding block is input, the input block is updated, and then the entire block is replaced.

In this embodiment, branch processing via the linkage unit 19 is performed in two ways, depending on whether the program is an address-dependent program or not, according to the processing instructions shown in FIG. 7(a) or (b).

When the linkage section 19 is expanded into an address-dependent program, as shown in FIG. 7(a).

The linkage unit 19 has an instruction that first branches to the common linkage unit 30. The common linkage section 30b2 is provided, for example, in a page that can be accessed without a HAS register between address O and address 1000 (hexadecimal) in the main memory. The common linkage unit 30 calculates the branch destination address to the program management unit 31, which is the supervisor, and branches to the program management unit 31. In the program management section 31.

Performs processing such as various address settings, and branches to the called module. When the branch address to the called module is determined, the program management section 31 sets an instruction to directly branch to the called module in the linkage section 19. Thereby, when calling for the second time or later, it is possible to branch directly from the linkage unit 19 to the called module. Note that if the linkage unit 19 is in a write-protected section, the two-branch instruction cannot be rewritten, so the same processing as the first time is performed for the second and subsequent times.

When the linkage unit 19 is developed into an address-independent program, an instruction to branch to the second entry of the common linkage unit 30 is set in the 5 linkage unit 19, as shown in FIG. 7(b). In the common linkage section 30,
Call destination moji1. - Obtain the address of the file information section and determine whether it is writable or not and whether it exists or not based on its attributes. There is substance.

If writing is prohibited, calculate the branch destination address from the entry point address in the module information section.

Branch to the called module. In other cases, the address to the program management section 31 is calculated, and the copying process of the called module is performed. Note that most of the processing in the second program management section 31 can be carried out using conventional existing processing.

The common linkage section 30 is provided to avoid wasting memory due to multiple linkage sections 19 having duplicate instructions, and to simplify the interface with the program management section 31. In general, it is an extension of the linkage section 19, and can be considered to be a part thereof.

Dynamic coupling in one embodiment of the present invention will be described below with reference to FIGS. 8 to 11.

In FIG. 8, the called destination is "substantive".

For example, if the section is a write-protected section, in the calling module CALLING, CALLE
When the instruction to call D (CAI-L CALLED) is executed, control is passed to the linkage unit 19.

The linkage unit 19 has a branch instruction to the common linkage unit 30 and also has pointer information to the module information unit 16B. When control is passed to the linkage section 19, the process branches from here to the common linkage section 30 which describes an instruction code that can be used commonly by all linkage sections, and uses the instruction code to refer to the module information section 16B.
Determine its attributes. Here we have an entity to call.

Since the call destination is write-protected, the common linkage section 30 branches to the entry point of the module entity section 17B based on the entry point address held by the module information section 16B.

FIG. 9 shows an example where there is no entity to call.

Similarly to FIG. 8, after control is passed to the common linkage section 30, the common linkage section 30 controls the module information section 16B.
By determining the attributes in , it becomes clear that there is no entity to call. Therefore, the common linkage section 30
Control is then passed to the program management section 31 of the supervisor. When the program management unit 31 determines that the entity to be called does not exist and is not defined in any other file.

Recognize it as an error and take action.

FIG. 10 is an example of a case where there is a callee entity and the callee is writable.

Module information section 1.6 in common linkage section 30
When the attribute determination of B reveals that it is writable, control is passed to the program management section 3]. Program management department 3
1, the position of the module entity section 17B is confirmed by the module information section 16B, and the module entity section], 7B is copied to another address in the virtual memory and relocation is performed.

A module entity part 17C is created. And that A1
− Request a response and pass control.

The 11th example is almost the same as the example shown in FIG.

This is the case when the called entity exists in another file.

Many programs that use subroutine bunkage (including programs written in high-level languages that require runtime libraries) will perform the operations shown in FIG. 11. The user program is CALLING, →
The routine package corresponds to CALLED.

When the program management section 31 receives control from the common linkage section 30, it finds the entity from another file based on the name of the called destination and transfers control thereto. however,
In the example in Figure 11, CALLED is a write-protected section, but if it is writable, then
Similar to the example in Figure 1O.

It also performs copying and relocation processing, and passes control there.

〔Effect of the invention〕

As explained above, according to the present invention, the independence of modules is maintained which is almost the same as in conventional dynamic combinations, and the operability in developing and modifying modules is improved, and the execution performance during dynamic combinations is improved. can be significantly improved.

[Brief explanation of the drawing]

FIG. 1 is a diagram explaining the principle of the present invention. Figure 2 shows an example of the configuration of the module information section. FIG. 3 is an entry point address explanation window according to an embodiment of the present invention. FIG. 4 and FIG. 5 are explanatory diagrams for creating a module according to an embodiment of the present invention. FIG. 6 is an explanatory diagram of module replacement according to an embodiment of the present invention. FIG. 7 is an explanatory diagram of linkage section processing according to an embodiment of the present invention. FIGS. 8 to 11 are explanatory diagrams of dynamic coupling according to an embodiment of the present invention. FIG. 12 shows an example of conventional module combination. In the figure, 10 is a processing device, 11 is a library editing section 112
13 is the batch loading processing section, and 4. is the external memory. Qla location, 14 is the load module library. 15 is a space management section, 16A and 16B are module information sections, and 17A and 17B are module entity sections. 18 represents a loading area, and 19 represents a linkage section.

Claims (1)

[Claims] A data processing system that loads a modularized program into a memory and executes the module includes a module information section having an entry point address storage area in which an address to be called from another module is set as a relative address within a file. , and a module entity section in which program entities are stored (14).
a library editing section (11) that creates the plurality of module information sections and module entity sections;
a batch loading processing unit (12) that loads information areas all at once onto memory without changing the relative positional relationship between them; and a module information unit that references the module information unit corresponding to the called module in the module entity unit. , a linkage section (19) having an instruction code that directly or indirectly branches to a called destination, and dynamically connects a calling module and a called module. .