JPS61837A - Program overlay loading system - Google Patents

Abstract

PURPOSE:To shorten the loading time of a program module having high using frequency and to make best use of a memory area, by providing a program resident buffer area to an internal memory in addition to a user program area. CONSTITUTION:A program resident buffer 8 is provided to a main memory 2 for residence of plural program modules 9. An INDEX part 7 is also provided to show a specific program module 9 that is loaded to the buffer 8. The name of the module 9 loaded to the buffer 8 is registered to the part 7. The module 9 stored in an external file 1 is loaded to the buffer 8 or a user program area 5 via a data bus 10 under the control of a CPU11 according to a program storing area map of the memory 2.

Description

[Detailed Description of the Invention] [Field of Application of the Invention] The present invention relates to a program overlay system.
In particular, the present invention relates to a program overlay loading method that can shorten the loading time of frequently used program modules and make effective use of a limited memory program area.

[Background of the invention]

Language programs that operate only within a limited range of memory addressing can be provided with many functions by using an overlay program structure. In this case, even if the system has sufficient memory, overlay structures cannot be avoided, and overlay loading time affects system performance. Of course, if the system does not have internal memory, the user
You must use the overlay loading method when loading programs.

Generally speaking, the user program area is limited within a certain range, so the entire program stored in the external file will exceed that area. In that case, there is a way to effectively use the memory area.7 After loading and executing a certain program, when it is no longer in use, there is a method of loading the next program over it, that is, a method using overlay load pressure. It will be done. However, in this method, the program loader overlay loads the external file into the memory area each time it is necessary, which takes time and is extremely inefficient.

Furthermore, if overlay loading is performed using only programs that use the class l1rc, the program that has been deleted must be repeatedly loaded, further reducing efficiency.

It is desirable to keep frequently used programs resident in memory, or due to memory limitations, after performing a certain overlay load, loads beyond the resident memory must be made externally. Since overlay loading from a file is required, it is not possible to select frequently used program modules and make them resident.

[Purpose of the invention]

The purpose of the present invention is to eliminate such drawbacks, reduce the loading time of frequently used program modules, and
Another object of the present invention is to provide a program overlay loading method that can make the most effective use of a limited memory area.

[Summary of the invention]

In order to achieve the above object, the program overlayload method of the present invention stores user programs in internal memory.
A program resident buffer area is provided separately from the area, and the root module attaches priority specification information and makes a load request to the program loader, so that the program/loader is attached with priority specification information. program·
When the program module is not available in the program resident buffer area, K loads the program module from the external file into the user program area. After loading the program module into the resident buffer area and registering the module name in the index, the program module is loaded into the user program area.

[Embodiments of the invention]

Embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 is a system block and memory map diagram illustrating one embodiment of the present invention.

! In FIG. 1, numeral 1 is an external file that stores program modules, and specifically, it is a 7 lexiple disk device or a fixed disk device. 2 is the main memory, and the OS (Op@rating
A system storage area 6, a user program area 5, and a program resident buffer area 8 are set. 9 is a program module loaded onto the main memory 2 or stored on an external file 1; 10 is a data bus; 11 is a CPU; 12 is a CRT display which is an output device; and 16 is an input device. It's a keyboard. A CRT display device 12 and a keyboard 16 connect to the CPU 1 via a data bus 10.
1 and operates as the operator's console. The O8 storage area 6 of the main memory 2 contains the OS module 14 that constitutes the O8 section and these modules #.
14 and communicates with the operator.
5 is stored. In the OS module group 14, a root module 6, which is a user program resident part, and a plurality of program modules 9, which are user program non-resident parts, are used to store user business processing programs. There is a program loader 4 that loads into the user program area 5. The root module 6 loads the program loader 4 via the monitor 15 in response to a program load command from the operator.
The program is loaded into the user program area 5 as a business processing program. Once the root module 6 is loaded, it is made resident in the second program area 5, and thereafter, the program loader 4 is started to transfer the program module 9 to the user program area 5. The program module 9 is loaded and performs user business processing together with the program module 9.

In the main memory 2 in FIG. 1, a new I! A program resident buffer 8 is provided for making several program modules 9 resident, and an index (INDEX) part 7 indicating which program module 9 is stored in this program resident buffer 8 is also resident. let In the index section 7, the names of the program modules 9 loaded into the program resident buffer 8 are registered.

According to such a program storage area map of the main memory 2, the program module 9 stored in the external file 1 is transferred to the CPU 1 via the data path 10.
1 is loaded into the program resident buffer 78 or the user program area 5.

In the embodiment of FIG. 1, as described above, 1 main memory 2
In the program resident buffer 8 above, a program storage area and an index section area for a plurality of a's worth of programs are prepared, and first, the root module 6 attaches priority designation information and requests the program loader 4 to perform a program overlay load. do. Here, the priority designation information is attached to the
As for the gram, one that is frequently used and requires 1 ft is selected. It would be most dangerous if all programs to which priority designation information is attached can be loaded into the program resident buffer 8, but if priority designation information is added that exceeds the capacity of the resident buffer 8, they will be loaded in the order of use. Resident buffer 8
The program that exceeds the capacity of the resident buffer 8 is stored in the external file 1, and is seeded directly from the external file 1 into the user program area 5 in the same way as a general program.

Overlay program from root module 6
Each time a load request is made, the program loader 4 determines the presence or absence of priority designation information, and if there is eugenic designation, refers to the index section and loads the corresponding program module 9.
If there is, the corresponding program module 9 is loaded from the program resident buffer 8 to the user program area 5, and if the corresponding program module 9 is k,
After seeding the program resident buffer 8 from the external file 1 and registering in the index unit 7 that it is ready to be loaded, the program is loaded into the user program area 5. As a result, even if the number of overlay program modules that can be made resident is limited due to the capacity limit of the program resident buffer 8, frequently used program modules, that is, modules with high proficiency can be made resident. This makes it possible to make the most effective use of the memory capacity and to shorten the p-do time.6 FIG. 2(a) <b) is a processing flowchart of FIG. 1.

Some of the program modules 9 are frequently used, and others are used less frequently, and this can be determined at the time of creating a user program and converting it into an overlay module. Therefore, the root module z-A/6 knows in advance which program module 9 is to be prioritized. Figure i2 (&) is the process 7-chart by the route module 6, and Figure 2 (b) is the load process 4-chart by the program loader 4, which is the root module loaded by activation from the operator. 6 seeds the overlay program module 9 necessary for executing business processing in the second program area 5. At this time, Fig. 2(a)
As shown in step 21), it is first determined whether or not it is necessary to give priority to the frequently used program module 9. If necessary, a priority code is assigned to the startup information for starting the program loader 4. Step 22) Start the program loader (Step 2)
6).

The program module 9 which is used less frequently is not given priority and the program module 4 is activated (step 2L23').

■ in the 21st ffl(b) is a process that refers to the index section 7 of the resident area 8, ■ is a load process when the resident area 8 is full, or a process when there is no priority designation, and ■ is a process that refers to the index section 7 of the resident area 8. This is a load process when the resident area 8 is not full and there is space, and {circle around (2)} is a load process when the program is resident in the resident area 8.

The program loader 4 determines whether there is a priority designation, and if there is a priority designation, searches the index section 7 and finds that the program module name of the program module 9 requested to be loaded exists in the index section 7. It is checked whether or not (steps 25, 26, 27). If it does not exist in the index s7, check whether the resident area (here, the second area) 8 is full from the contents of the index [7 (step 29) If it is not full, the data is transferred from the external file 1. Applicable program module 9
is first written into the resident buffer (second area) 8, and its program module name is registered in the index section 7. (Steps 30, 31.).

Next, the corresponding program is transferred from the resident buffer (second area) 8 to the user program area (tuna 1 area) 5.
The Moginy A/9 is moved and the process ends (step 62).

Furthermore, when the regularization buffer 78 is full, the corresponding program module 9 is loaded directly from the external file 1 into the program area (first area) 5 (step 6).
6).

In addition, if the resident buffer 8KS corresponding program/module 9 exists, the resident buffer (
2nd area) From 8 Program area (1st area)
5, it can be loaded (step 28).

As a result of this process, the same program module 9 is requested to be loaded by the root module 5.
Since it is already registered in the index section 7, it is only necessary to load it from the external file 1. In addition, the program module 9 requested to be loaded without priority specification is directly loaded from the external file 1 to the user program→
is loaded into program area 5 (step 66).

In this way, in this embodiment, the program module 9 with priority designation is seeded from the external 7-eye A〆1 only at the time of the first b-do request, but from the second @ onward, it is only moved between memories. Since the p-doctor function can be performed in a single step, the time required for the program is shortened, and the limited program resident buffer 8 can be utilized to the maximum extent possible.

〔Effect of the invention〕

As explained above, according to the present invention, a program resident buffer area separate from the second program area is provided in the internal memory of the PG program, and priority programs resident in this resident buffer area are stored in the program resident buffer area. Add a boogram to the second
You can conduct raids just by moving to the program area, so use jp! 0 that can shorten the loading time of highly sophisticated programs and make effective use of the limited memory area.

[Brief explanation of the drawing]

18 is a boot diagram of a system showing an embodiment of the present invention, and FIG. 2 is a process 712-chart of FIG. 1. 1: External file, 6: O8 storage area, 4 Nibushidaram award-da, 5: User program area, 6: Root module, 7: Index section, 8 Nib p-gram resident buffer, 9 Nibudaram. module, 14
! 08% Ji-le group, 151 Kina Yu. Figure 1 Figure 2 (a) -23 [

Claims (1)

[Claims] (1) In a method in which a root module and a program loader read a requested program module from an external file and overlay load the program module into a user program area of internal memory, the user program is loaded into the internal memory. - A program resident buffer area is provided separately from the area, and the root module requests the program loader to load the program with priority designation information, so that the program loader loads the priority-designated program. Loads a module from the program resident buffer area into the user program area, and if the program module does not exist in the program resident buffer area, loads the program module from an external file into the program resident buffer area. A program overlay loading method characterized in that the program module is loaded into the user program area after the module name is registered in an index.