JPH04317135A - Program storage execution system - Google Patents

Abstract

PURPOSE:To move a program only by means of compiling a source by preventing the entry address of the other object from changing even if an object size increases/decreases. CONSTITUTION:A compiling means 2 generates the object whose address is not solved at every sub-routine from a source file 1. A virtual address solution means 3 allocates the generated object to one virtual block. An object storage means 4 stores the object on the virtual block in a real storage device. A virtual address conversion means 12 executes the object on the virtual block while an execution address is converted.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a program storage and execution method, and more particularly to a program storage and execution method from a source file to program execution.

0002

2. Description of the Related Art In a conventional program storage/execution method, a source file is created or modified in program development work, then compiled, and then linked, and then the program is executed.

FIG. 9 is a block diagram showing an example of a conventional program storage and execution method.

In the conventional program storage/execution method, as shown in FIG. 9, first, a compiling means 92 generates an unresolved address object file based on a source file 91.

Next, an address resolution means 93 called a linker refers to the address resolution object list 95 and generates the address resolution result in another file called a load module.

FIG. 10 is a diagram showing an example of object arrangement in the conventional program storage and execution method.

[0007] Each object obj1, obj2, ob
As shown in FIG. 10, j3, . . . are arranged as load modules in the real address space. Further, the load module storage means 94 stores the created load module in a disk or the like as a normal file.

[0008] When the program is started, the memory loading means 96 loads the load module from the file into the memory and executes it. The problem here is that
The address resolution means 93 collects objects and places them on the address. Since they are arranged in areas with continuous addresses, if the size of the corresponding object changes due to a change in the source file 91, all entry addresses after the changed part will change. Therefore, the address resolution means 93 has to perform address resolution again from the beginning.

FIG. 11 is a diagram showing an example of the effect of changing the object size in the conventional program storage and execution method.

For example, suppose there are sources A1, B1, and C1 as shown in FIG. 11(a). and source A1
Assume that subroutine b of source B1 is called in subroutine a of , and subroutine c of source C1 is called in subroutine b. Furthermore, for the sake of clarity, it is assumed that sources A1, B1, and C1 have only subroutines a, b, and c, respectively.

Therefore, the compiling means 92 compiles these to generate objects A2, B2, and C2 whose addresses are unresolved as shown in FIG. 11(b). Further, when creating the load module D using these objects A2, B2, and C2, the address resolution means 93
As shown in FIG. 1(C), the objects A2, B2, and C2 are arranged without gaps at the addresses, and then the addresses of subroutine b and subroutine c are determined. Note that in the example of FIG. 11(c), objects A2, B2
, C2 are each set to have an object size of 1000.

Now, let us consider a case where a new process is added to subroutine a by modifying the program. Source A1
is changed and when it is compiled, object A2 becomes larger and the object size increases from 1000 to 1300. Then, load module D becomes
It is changed as shown in FIG. 11(d). What should be noted here is that the addresses of subroutines b and c have changed in load module D in FIG. 11(d);
00, CALL2000 to CALL1300, CAL
They have each changed to L2300. In other words, in the conventional program storage and execution method, changing one subroutine changes the entire load module.

[0013] In this way, in the conventional program storage and execution method, the linker has to review the entire object even if only a small part of the source file is changed, so in the case of a large program, the compilation time is small. Even if it can be done in 10 minutes, it takes a long time to link.

[0014]

[Problems to be Solved by the Invention] The first problem with the conventional program storage and execution method described above is that even if a single line in a source file is changed, the linking process takes time proportional to the size of the program. The shorter the time it takes from modifying the source file to confirming execution,
Despite the improvement in debugging efficiency, for large programs, even if the amount of modification is small, linking time is required proportional to the scale, which hinders the improvement of debugging efficiency. There is. Also, secondly,
Computers for program development have a problem in that they require a large amount of disk space because both object files and load module files have almost the same information.

[0015]

[Means for Solving the Problems] The program storage and execution method of the present invention includes a compiling means that generates an object whose address is unresolved for each subroutine from a source file, and a virtual block that allocates each of the generated objects onto one virtual block. an address resolution means; an object storage means for storing the object on the virtual block in an actual storage device; and a virtual address translation means for executing the object on the virtual block while converting an execution address. It is configured as follows.

[0016]

Embodiments Next, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram showing an embodiment of the program storage and execution method of the present invention.

The source file 1 and address resolution target object list 52 shown in FIG. 1 are created and specified by the user. Note that the source file 11 is assumed to contain C language source code, and will be described in terms of C language hereinafter. Source file 1 defines several subroutines called functions.

Furthermore, the compiling means 2 generates one object for each function requested to be compiled by the user. The generated object is similar to a conventional object except that it has only one function. In other words, the generated object has an unresolved address and one symbol that can be referenced from external objects.

On the other hand, the virtual address resolution means 3 only needs to process objects that have been changed. To do this, we need to know which objects have changed. There are three ways to know this: (1) When compiling and linking a program for the first time, i.e., making it, ask the user to specify all objects except the libraries that make up the program. (2) For the second and subsequent make, ask them to specify a list of changed function names. (3) Have the user specify the changed object using a utility that automatically determines the name of the changed function by comparing the timestamps of the file before the change and examining the differences in the changed file.

[0021]The virtual address resolution means 3 first allocates one virtual block to an object to which a virtual block has not yet been allocated from among the objects included in the address resolution target object list 5. Further, after the object assignment is completed, the virtual address resolution means 3 sequentially resolves the addresses of the objects in the address resolution target object list 5. In other words, virtual address resolution involves finding the entry address of the object that has the function that the object calls, that is, the start virtual address of the virtual block where the object is located, from the symbol table 6, and writing it at the call instruction of the object that is calling the function. This is done by

FIG. 2 is a diagram showing an example of objects allocated on the virtual address space in this embodiment. In addition, FIG. 3 shows the address resolution target object list 5 in FIG. 1.
It is a figure showing an example. The virtual address resolution means 3 resolves addresses within the range of objects in the address resolution target object list 5 of FIG.

FIG. 4 is a diagram showing an example of the symbol table 6, which is a correspondence table between object names and virtual block numbers assigned in this embodiment.

Each time the virtual address resolution means 3 allocates a virtual block to an object, it creates a symbol table 6, which is a correspondence table between the allocated object and the virtual block, as shown in FIG. Furthermore, when allocating a new virtual block to a new object, the virtual address resolution means 3 allocates a used virtual block, but when there is no used virtual block, the virtual block allocation and release means 7 allocates a new virtual block. obtain. The virtual block allocation release means 7 is
A free virtual block information table 10 is used to manage free virtual blocks.

Next, the object storage means 4 allocates the object allocated to the virtual block to the real address space and stores it on the memory or the secondary storage device.

FIG. 5 is a diagram showing an example of the correspondence between virtual blocks and real address blocks in this embodiment.

The real address space is handled in units of real address blocks, and its size is 2 raised to the m power. Here, if the size of the virtual block is 2 to the nth power, it is assumed that n>m. That is, as shown in FIG. 5, 2(n−m) real address blocks are allocated to one virtual block.

FIG. 6 is a diagram showing an example of the map table 9 for converting virtual addresses to real addresses in this embodiment.

Real address block allocation release means 8
As shown in FIG. 6, in the case of the k-th real address block from the top of the virtual address space, the real address block allocated by Address is set.

When the real address block allocation release means 8 is requested to allocate a real address block from the object storage means 4, it refers to the free real address block information table 11 and assigns the free real address block to the object. It is passed to storage means 4. The real address block allocate and release means 8 also registers the real address block in the free real address block information table 11 when the object storage means 4 requests the release of a real address block.

Therefore, the object storage means 4 stores the object allocated to the virtual block by the virtual address resolution means 3 in the allocated real address block. Furthermore, the object storage means 4 stores only the portion of the virtual address space where the object exists in the real address block, and writes a NULL pointer in the map table 9 without allocating the real address block corresponding to the portion where the object does not exist. do.

Furthermore, the virtual address conversion means 12
The address from the PU is regarded as a virtual address, and the corresponding real address is accessed. By this, C.P.
U can execute virtual addresses as if they were real addresses. That is, the virtual address translation means 12
uses map table 9 to translate from virtual addresses to real addresses.

Next, a description will be given of how each case of adding or deleting a function and increasing or decreasing the object size of a function is handled.

First, when adding a function, the virtual address resolution means 3 searches the symbol table 6 and
If it is not found, it is determined that it is a new function. Then, one virtual block is allocated for the new function. The object obtained by compiling the new function is stored in the allocated virtual block. Then, the correspondence between the new object and the virtual block number is added to the symbol table 6.

Furthermore, when a function is to be deleted, the function is deleted by the user's object deletion designation. Then, the deletion function is deleted from the symbol table 6, and the virtual block containing the object of the deletion function is released.

On the other hand, when the object size of a function increases, it is stored in the virtual block where the object before the change was stored. When storing, use the real address block where the object was before the change,
A new real address block is allocated for the shortage.

FIG. 7 is a diagram showing an example of the arrangement of real address blocks when the object size increases in this embodiment.

As shown in FIG. 7, since the number of real address blocks to be allocated increases, a new address block is inserted after the real address space. For example, when object obj1 in FIG. 5 increases by two real address blocks, real address blocks #2 and #3 are added later.

On the other hand, when the object size of a function is decreased, it is stored in the virtual block where the object before the change was stored.

FIG. 8 is a diagram showing an example of the arrangement of real address blocks when the object size is reduced in this embodiment.

As shown in FIG. 8, the real address blocks that are allocated are reduced and become empty. For example, object obj2 in Figure 5
When the number decreases by two real address blocks, real address blocks #6 and #7 are empty and NULL.

In this embodiment, the address space used as the real address may be the main memory space of the computer or the virtual storage area of the computer. Alternatively, it may be an auxiliary storage space (mapped IO) such as a disk. Further, in this embodiment, the entry pointer of a function has been described, but the entry pointer of data, that is, a variable, can be handled in the same way. The data entry pointer can store a plurality of variables in one virtual block, and can also allocate a virtual block to each variable.

[0043]

Effects of the Invention The program storage and execution method of the present invention has the following three effects.

The first effect is that even if the object size increases or decreases, the entry addresses of other objects always remain the same, so the program can be run simply by compiling the modified source. However, there is a restriction that the object size of one function cannot exceed the size of the virtual block.

The second effect is that the auxiliary storage device of a conventional program development computer has three sources: a source file, an object file, and a load module file. This means that the amount of storage space used can be saved.

Furthermore, the third effect is that all programs are stored in the real address space and executed directly from the program entry, so as long as there is a real address space, it is possible to This can also be applied to computers with different architectures.

If the real address space is the main memory, then
This method saves memory because only binary programs exist in memory. Additionally, since there is no process to load at startup, the program can start instantly. Even when the real address space is used as a virtual storage area, not only does it save space, but only a portion of the program is loaded, allowing even large programs to start quickly. Even when the real address space is used as the auxiliary storage space, this can be realized by devising memory buffering, and in this case as well, the auxiliary storage device can be used efficiently in this method where there are only objects.

Note that the program storage and execution method of the present invention is useful in situations where a large-scale program is executed and adjusted many times while changing some of its parameters, and it can be easily patched. Even if it is not possible,
Another advantage is that the development period can be significantly shortened.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing an embodiment of a program storage and execution method according to the present invention.

FIG. 2 is a diagram showing an example of objects allocated on a virtual space in this embodiment.

[Figure 3] Address resolution target object list 5 in Figure 1
It is a figure showing an example.

FIG. 4 is a diagram showing an example of a symbol table 6 that is a correspondence table between object names and virtual block numbers assigned in this embodiment.

FIG. 5 is a diagram showing an example of the correspondence between virtual blocks and real address blocks in this embodiment.

FIG. 6 is a diagram showing an example of a map table 9 for converting virtual addresses to real addresses in this embodiment.

FIG. 7 is a diagram illustrating an example of the arrangement of real address blocks when the object size increases in this embodiment.

FIG. 8 is a diagram illustrating an example of the arrangement of real address blocks when the object size is reduced in this embodiment.

FIG. 9 is a block diagram showing an example of a conventional program storage and execution method.

FIG. 10 is a diagram showing an example of object arrangement in a conventional program storage and execution method.

FIG. 11 is a diagram illustrating an example of the effect of changing an object size in a conventional program storage and execution method.

[Explanation of symbols]

1, 91 Source file 2, 92 Compilation means 3 Virtual address resolution means 4 Object storage means 5, 95 Address resolution target object list 6 Symbol table 7 Virtual block allocation release means 8
Real address block allocation release means 9 Map table 10 Free virtual block information table 11
Free real address block information table 12 Virtual address conversion means 93 Address resolution means 94 Load module storage means 96 Loading means into memory

Claims (1)

[Claims] 1. Compilation means for generating an object with an unresolved address for each subroutine from a source file; virtual address resolution means for allocating each of the generated objects onto one virtual block; A program storage/execution method comprising: an object storage means for storing in an actual storage device; and a virtual address translation means for executing the object on the virtual block while converting an execution address.