JPH04117523A - Program editing device - Google Patents

Abstract

PURPOSE:To attain the direct execution of the common modules formed into a single piece based on a real address stored in ROM by describing a call instruction, a jump instruction, etc., which define the real addresses of the common modules as their call destinations. CONSTITUTION:The MS-DOS stored in a system disk 8 is loaded into a RAM, and a source file stored in a file disk 9 is evolved to a RAM 3 under the back-up of the MS-DOS. The source file is successively converted into an object file, an EXE practicable file and then a HEX file. In this case, 'tool1' of lists 2 and 5 and 'tool2' of lists 3 and 6 are identical with the jobs common to two jobs. Thus these functions are deleted out of an EXE file B and remain only in an EXE file A in the form of a single piece respectively. As a result, the common modules are quickly carried out.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a program editing device suitable for concatenating a plurality of executable files (hereinafter referred to as EXE files) and creating a ROM.

[Summary of the Invention] The present invention provides a program editing device in which a plurality of EX
E files are concatenated to create a ROM image file (hereinafter referred to as
When creating a HEX file (called a HEX file), multiple E
When duplicating modules in an XE file are combined into a single shared module, and the shared module is executed in the file where the module was deleted, it is called using the real address on the ROM of the shared module, By jumping to a real address, shared modules can be executed easily and quickly.

[Prior art] Conventionally, for example, a system equipped with a multitasking O8 was
When converting to M, each job is created as an EXE file in order to ensure the independence of each job, and these multiple EXE files are concatenated to create an EXE file.

However, when simply connected, as shown in Figure 11,
The HEX file has duplicate modules that are common to each EXE file, which is disadvantageous in terms of ROM capacity.

Therefore, conventionally, as shown in Figure 12, common modules were combined into one, and arbitrary EXE files were imported.
Other EXE files whose modules were deleted for unification were shared by calling the unified common module, but in the conventional calling method, a series of Nα was applied to each common module. As shown in FIG. 13, the allocation method was to call using software included. That is, the calling side puts Nα corresponding to the common module into a register, and calls with software interrelated. Then, on the receiving side, based on the interwoven function created in advance, the address corresponding to Nα is retrieved from the address table in which the addresses of the common module are registered, and the common module is called.

[Problem to be solved by the invention] However, the conventional method has the following problems.

In other words, adding a unique number on the calling side,
The process of registering modules for shared use was complicated, such as adding an INT call section on the calling side and adding an address table on the receiving side.

Further, for example, if a module that is not to be used jointly is accidentally registered and deleted, the subsequent sequence must be corrected, and this correction work is troublesome.

Furthermore, as can be inferred from the above explanation, "caller" [
The number of steps in the conversion part of the receiver side is large, resulting in large overhead, and it is also disadvantageous in terms of ROM capacity.

This is due to the fact that the real address on the ROM of the common module is obtained through a series of companies.

It is clear that the above problem can be solved if the common module can be executed directly based on its real address on the ROM.

An object of this invention is to enable a unified common module to be directly executed based on its real address on the ROM.

[Means to solve the problem] The means of this invention are as follows.

The first control means (see the functional block diagram of FIG. 1, the same applies hereinafter) a consolidates modules that exist redundantly in a plurality of executable files into one.

When creating a ROM image file, the second control means a creates a library in which real addresses on the ROM are registered for the modules unified by the first control means a.

RO
When converting to an M image file, the second control means writes an instruction whose execution destination is the real address of the unified module instead of the deleted module, based on the library created.

[Work] The operation of the means of this invention is as follows.

The first control means a is configured to leave a common module that exists redundantly in multiple executable files in one executable file and delete it from other executable files, or to delete only the common module. The collected executable files are newly created, the common module is deleted from all the original executable files, etc., and the file is unified into a single file, which is used as a shared module between each file.

Then, when converting an executable file containing a shared module into a ROM image file, the second control means is configured to create a library in which the real address of the shared module is registered on a ROM image file, since the real address of the shared module on the ROM is determined. create.

Therefore, when the first control means a converts the executable file from which the common module has been deleted for unification into a ROM image file, the third control means C creates a ROM image file using the second control means. Referring to the real address in the library that was deleted, write a call instruction that calls the real address of the shared module instead of the deleted common module, a jump instruction that uses the real address as the jump destination, etc.

Therefore, the unified common module can be directly executed based on the real address on the ROM.

[Example] An example will be described below with reference to FIGS. 2 to 10.

FIG. 2 is a block diagram of the program editing device, which actually includes CPU, ROM2, RAM3, input section 4,
It is realized by a normal personal computer having a display section 5, a printing section 6, and a transmission section 7.

In this embodiment, an 8o-based cPU is used as the CPU, but of course, other CPUs can also be used.
This CPLJl performs various editing processes according to the editing program preset in the ROM 2. At this time, MS-DO 9 in the system disk 8 is loaded into the RAM,
Kono Ms-D.

With the support of S, the source file in the file disk 9 is developed into the RAM 3, and this source file is sequentially converted into an object file, an EXE executable file, and a HEX file.

The transmitter 7 transfers the I(EX file to the ROM writer 11 in order to write it into the ROM 10.

In this embodiment, the source file is written in C language, as can be inferred from the function rmain4 shown in FIG. In FIG. 3, one job is composed of lists 1 to 3, another job is composed of lists 4 to 6, and a separate EX
E file A and EXE file B are created. In this case, "too11" in List 2.5, "t" in List 3.6
.

o12'' is a function common to the two jobs, so it is deleted from, for example, EXE file B, and left only in EXE file A, making it a single function.

Next, the program editing operation will be explained.

First, an outline of the operation will be explained according to the general flowchart shown in FIG.

Common modules that exist redundantly in each source file (
Figure 1 List 2.3.5.6) Function name (tool
1.2) is extracted and written into a definition file as a common function, and each source file is compiled to create an object file (step Sl in FIG. 4).

Originally, it would be sufficient to have only the function name in this definition file, but in this embodiment, as shown in Figure 5, r ext
It is written in the format "ern int far function name". The reason is MS-D.

Most of the C language on S supports far-type function description, and this is because common functions can be called using far addresses simply by incorporating such a description as a header.

Then, when linking each object file, decide which object file will leave the common functions as is, and convert this object file to an EXE file by linking subroutines for input/output control, etc.
Step s2).

Then, a library of common functions registered in the definition file is created (step s3). This library will be referred to as a tool BOX library.

Next, use the toolbox library to convert other object files to EXE files (step S
4) That is, by linking with the tool BOX library, the entity of the same function as the common function registered in the tool BOX library is replaced with a jump instruction for jumping to the same remaining common function. Note that the jump destination address of this jump instruction is a predetermined dummy address because the actual address when the common function is expanded into the ROM is undetermined at this point.

Then, the EXE file containing the common function is converted into an IEX file (step S5).The actual address on the ROM of the common function is determined by the conversion process to the HEX file. Register in the tool box library.

Next, the EXE file that does not include common functions is converted into a HEX file (step S6). At this time, tool BO
The dummy address of the replaced jump instruction is converted into a real address by referring to the X library.

Note that when creating an EXE file, a map file is also created in which the position of each function included in the EXE file is registered from the beginning of the EXE file, that is, the offset address from the beginning of the file is registered.

Next, the tool BOX library creation process in step S3 will be described in detail with reference to FIG.

Using the fib command in the C language for creating and managing libraries, the contents of the definition file are first read out in predetermined units (step 531 in Figure 6), and it is determined whether or not the end of the file has been reached (step 532). As a result, if it is the end of the file, it ends.

On the other hand, if it is not the end of the file, it is determined whether the read data is a function name (step 833), and as a result, if it is not a function name, the process returns to step S31. If it is a function name, an interface label is created (step 534), and this interface label has the form (function name): JMPF $ (where °$” is data indicating the address of the own file). It has become.

Then, assemble this interface label and register it in the tool box library.
Return to step S31.

Next, the process of converting an EXE file containing a common function into a HEX file in step S5 will be explained in detail with reference to FIG.

The addresses of the common functions registered in the tool box library are taken out from the map file, and a map table containing only the common functions is created (step 551 in FIG. 7).

Next, the header information of the EXE file is read and a table regarding relocation items is created (step 55).
2).

Then, read data from the EXE file (step 953), and determine whether the file has reached the end (step 953).
Step 554), if the result is the end of the file, the process ends. If it is not the file end, it is determined whether it is a relocation item (step 555). If it is a relocation item, a relocate process is performed (step knob 556) and the process proceeds to step S57. If it is not a relocation item, the process skips the relocate process and proceeds to step S57.

In step S57, it is determined whether the read data is a common function registered in the tool BOX library. As a result, if the common function is registered, the real address of the common function on the ROM is registered in the tool box library by referring to the map table (step 85).
8), for example, the offset address of the common function registered in the map table is address 100OH (8th
(See figure (a)), if the EXE file containing the relevant common function is written from address 30000)1 of the ROM,
Address 310008 is registered as the real address of the common function (see FIG. 8(b)).

Then, write the read data to a HEX file (
Step 559), return to step 853. Note that if the read data is not a common function, step S58 is skipped and the process proceeds to step S59.

In this way, when converting an EXE file containing a common function into a HEX file, the real address of the common function on the ROM is registered in the tool BOX library.

Next, another E that does not include the common function in step S6
The process of converting an XE file to a HEX file is explained in Part 9.
This will be explained in detail with reference to the drawings.

First, let's start with other EXE files that do not contain common functions and have not been converted to HEX files.
It is determined whether the file exists (step 561 in FIG. 9), and if the EXE file does not exist, the process ends.

On the other hand, if the above EXE file exists, the EXE file
The header information of the E file is read and a table regarding solo cage items is created (step 562).

Then, data is read from the EXE file (step 863), and it is determined whether or not it is the end of the file (step 564). If it is the end of the file, the process ends. If it is not the end of the file, it is determined whether it is a relocation item (step 565). If it is a relocation item, it performs relocation processing (step 566) and proceeds to step S67. If it is not a relocation item, it performs relocation processing. Skip and proceed to step S67.

In step S67, it is determined whether the read data is a common function registered in the tool BOX library. As a result, if it is a registered common function, the dummy jump destination address "°$" of the jump instruction read together with the common function is rewritten to the real address of the common function registered in the tool box library (step 3
68).

Then, write the read data to a HEX file (
Step 569), return to step S61.

Note that if the read data is not a common function, step S68 is skipped and the process proceeds to step S69.

In this way, in an EXE file that does not include the entity of a common function, the dummy jump destination address of the jump instruction is converted into a real address.

Therefore, the receiver can immediately execute a desired common function without going through an interwoven function or the like on the receiver side.

That is, the usage pattern of the common function in this embodiment is schematically shown in FIG. 10, and the overhead is smaller than that in the conventional example shown in FIG. 13. Therefore,
It is possible to save ROM capacity and speed up processing.

Also, complicated operations such as assigning a series of functions to a common function can be omitted.

It is also possible to create an EXE file for the tool box alone, and the interface label is (function name) + r
It is also possible to set it as etf.

[Effects of the Invention] According to the present invention, the unified common module can be directly executed based on the real address on the ROM, the common module can be easily unified, and the common module can be quickly executed. become executable. Furthermore, ROM capacity can be saved.

[Brief Description of the Drawings] Figure 1 is a functional block diagram of the present invention, Figure 2 is a block diagram of an embodiment, Figure 3 is a diagram showing an example of a program file to be edited, and Figure 4 is a program editing operation. Fig. 5 is a flowchart showing an example of the contents of a definition file, Fig. 6 is a flowchart showing the creation operation of a tool box library, Fig. 7 is a conversion for converting an EXE file containing common functions into a HEX file. Flowchart showing the operation, Figure 8 is a diagram for explaining an example of registering a real address, Figure 9 is an EXE file that does not include common functions.
A flowchart showing a conversion operation for converting to an X file,
FIG. 10 is a diagram schematically showing how the common function is used in this embodiment, and FIGS. 11 to 13 are diagrams for explaining the prior art. l...CPU, 2...ROM, 3...RAM, 8
...System disk, 9...File disk. Figure Figure Figure Figure Figure 10 Figure Figure

Claims (1)

[Claims] In a program editing device for creating a ROM image file for linking a plurality of executable files and converting them into a ROM, there is provided a first method for combining modules existing redundantly in a plurality of executable files into one. a second control means for creating a library in which real addresses on the ROM are registered for the modules unified by the first control means when creating a ROM image file; When converting an executable file in which a module has been deleted for unification into a ROM image file by the control means, the executable file is converted into a ROM image file in place of the deleted module based on the library created by the second control means. 1
A program editing device comprising: third control means for writing an instruction to be executed at a real address of the converted module.