JPWO2007108043A1 - ROM storage data generation method and ROM storage data generation program - Google Patents

Abstract

Common part candidates are extracted from a program composed of a plurality of sections, and the extracted common part candidates are compared with each other to generate difference information. If the sum of the information amount of the common part and the difference information amount is smaller than the original information amount, the information of the common part and the difference information are output as ROM storage data. If the sum of the information amount of the common part and the information amount of the difference is larger than the original information amount, the original information is directly output as ROM storage data without being divided into the common part information and the difference information.

Description

  The present invention relates to a ROM storage data generation method for generating data stored in a read only memory (ROM) and a ROM storage data generation program for causing a computer to execute the method.

  Conventionally, in an embedded asymmetric multiprocessor system incorporating a plurality of processors, an operating system (OS) and application programs are stored in different memory address areas of the ROM for each processor that executes them. For example, it is assumed that the first processor executes an OS and a program stored in the first section and the second section of the ROM.

  Further, it is assumed that the second processor executes the OS and programs stored in the third section and the fourth section of the ROM. In such a case, the binary image of the program for each processor may differ only in part such as the branch destination address and the value of the data pointer, and the remaining data and processing routine may be almost the same.

  For example, in the above example, it is assumed that the first section and the third section are almost the same. Even in such a case, conventionally, as shown in FIG. 23, the ROM 1 includes a boot loader (Boot loader) 2, a first section (Sec1) 3, a second section (Sec2) 4, and a third section (Sec3). ) 5, fourth section (Sec 4) 6,..., Each section is stored for each processor.

  When the multiprocessor system operates, the OS and application program for each processor are read from the ROM 1 and loaded in the main work memory. The same applies to a single processor system in which a single processor executes a plurality of OSs and programs.

  By the way, with respect to the boot loading method in the multiprocessor system, at least one loader ROM is shared, and when the power is turned on, the program is downloaded to the volatile memory of each processor by the program of the loader ROM. The method of doing is well-known (for example, refer patent document 1). In this method, the loader ROM program is composed of a portion common to each board and a portion that is different for each board.

  Further, a microcomputer system that executes an OS including a common unit and a plurality of additional units having different functions is known (for example, see Patent Document 2). In this system, a ROM that stores a common part of a plurality of OSs, a ROM group that stores a plurality of additional parts of the OS, a switch for selecting one additional part from the additional parts of the plurality of OSs, an OS Means for reading out from the ROM and the ROM group and storing them in the processing memory, respectively.

JP-A-62-272341 JP 63-58536 A

  However, as described above, in a multiprocessor system, if a plurality of OSs and application programs operating on each processor are simply stored in each ROM, a large-capacity ROM is required. For this reason, the cost of the system board constituting the multiprocessor system is increased, and equipment such as a computer and a home appliance in which the board is incorporated becomes expensive. Therefore, in order to provide these devices at a low cost, it is necessary to reduce the cost of the system board. To that end, it is necessary to reduce the capacity of a plurality of OSs and application programs stored in the ROM.

  The same applies to the system board constituting a single processor system. Further, Patent Document 1 does not describe how to generate data of a portion common to each board of the loader ROM program and data of a portion different depending on each board. Similarly, Patent Document 2 does not describe how to generate a common unit and a plurality of additional units of a plurality of OSs.

  The present invention has been made in view of the above, and an object thereof is to provide a ROM storage data generation method and a ROM storage data generation program capable of reducing the capacity of a ROM provided on a system board.

  In order to solve the above-described problems and achieve the object, the present invention extracts common part candidates from a program consisting of a plurality of sections, compares the extracted common part candidates with each other, and calculates a difference. It is characterized by generating information. If the sum of the information amount of the common part and the difference information amount is smaller than the original information amount, the information of the common part and the difference information are output as ROM storage data. If the sum of the information amount of the common part and the information amount of the difference is larger than the original information amount, the original information is directly output as ROM storage data without being divided into the common part information and the difference information.

  There are the following five methods for extracting common part candidates. The first method is a method in which a section name is acquired from information of each section, and an area having the same section name is used as a common part candidate. The second method is a method in which a section name is acquired from linkage editor output information at the time of program linking, and an area having the same section name is used as a common part candidate. The third method is a method in which an area designated by the user is used as a common part candidate. The fourth method is a method in which the entire binary data is divided into a plurality of regions of the same size and each region is used as a candidate for a common part. The fifth method is a method in which the entire binary data is divided into a plurality of regions based on the continuity of the data, and regions having the same or similar size are used as candidates for the common portion.

  You may make it extract the candidate of a common part combining 2 or more of the said 1st to 5th extraction methods. Here, as the difference information, the entire address and fixed length difference data may be generated, or a fixed length offset address and fixed length difference data may be generated. Alternatively, the common part information and the difference information may be compressed by a compression algorithm and then output as ROM storage data.

  When the present invention is applied to a multiprocessor system, the programs stored in the ROM include a plurality of programs that are expanded in a memory shared by a plurality of processors and are simultaneously executed by the plurality of processors. In this case, a candidate for a common part is extracted between programs executed by different processors. This is because the program or data binary image for each processor may be the same for most of the remaining data and processing routines, except for some differences such as the branch destination address and data pointer value. . When the present invention is applied to a single processor system, the program stored in the ROM includes a plurality of programs executed by a single processor, and common part candidates are extracted between different programs. .

  The ROM stored data generation method and the ROM stored data generation program according to the present invention have the effect that the capacity of the ROM provided on the system board can be reduced. Accordingly, it is possible to provide an inexpensive device such as a computer or home appliance in which the system board is incorporated.

FIG. 1 is a flowchart of an embodiment of a ROM storage data generation method according to the present invention. FIG. 2 is a diagram schematically showing a storage state of the ROM in which information generated by the ROM storage data generation method according to the present invention is written. FIG. 3 is a flowchart of a first method for extracting candidates for common parts in the ROM storage data generation method according to the present invention. FIG. 4 is a flowchart of a second method for extracting candidates for the common part of the ROM storage data generation method according to the present invention. FIG. 5 is a diagram for explaining the second method. FIG. 6 is a diagram illustrating an example of section information obtained from linker output information when a common part candidate is extracted by the second method. FIG. 7 is a diagram illustrating another example of the section information obtained from the linker output information when the common part candidates are extracted by the second method. FIG. 8 is a flowchart of a third method for extracting candidates for common parts in the ROM storage data generation method according to the present invention. FIG. 9 is a diagram for explaining the third method. FIG. 10 is a flowchart of a fourth method for extracting candidates for the common part of the ROM storage data generation method according to the present invention. FIG. 11 is a diagram for explaining the fourth method. FIG. 12 is a flowchart of a fifth method for extracting candidates for the common part of the ROM storage data generation method according to the present invention. FIG. 13 is a diagram for explaining the fifth method. FIG. 14 is a diagram illustrating an example of the data structure of the original information. FIG. 15 is a diagram illustrating an example of a data structure of common part information and difference information generated from the original information illustrated in FIG. 14. FIG. 16 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 17 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 18 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 19 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 20 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 21 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 22 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 23 is a diagram schematically showing a storage state of a conventional ROM.

Explanation of symbols

PE0-B1 to PE0-B6, PE1-B1 to PE1-B6 Area divided into the same size PE0-P1 to PE0-P4, PE1-P1 to PE1-P3 Area divided based on data continuity 1 ROM
3, 4, 5, 6 Section 7 Difference information 11, 12 Linkage editor output information 15, 16, 17, 18 User specified area 19, 20 Binary data 21 Entire address 22, 23, 24 Difference data 25, 26, 27, 28 Offset address

  Embodiments of a ROM storage data generation method and a ROM storage data generation program according to the present invention will be described below in detail with reference to the drawings. Note that the present invention is not limited to the embodiments. In this specification, the ROM is rewritable that can rewrite part or all of the program written in the manufacturing stage as well as the mask ROM in which the program written in the manufacturing stage cannot be rewritten later. Non-volatile memories such as EEPROMs such as EPROMs and flash memories are included.

  FIG. 1 is a flowchart of an embodiment of a ROM storage data generation method according to the present invention. As shown in FIG. 1, first, candidates for common parts are extracted from execution format load modules executed by the processors of the multiprocessor system (step S1). Details of this candidate extraction method will be described later. Next, the extracted common part candidates are binary compared with each other (step S2). And the information of the difference between the candidates of the compared common part is created (step S3). In FIG. 1, the common part C and the difference D are used to simplify the description.

  Next, it is determined whether the information amount of the sum of the common part information and the difference information is smaller than the total information amount of the original information (step S4). As a result, when the number is small (step S4: Yes), information on the expansion routine for restoring the common part information and the difference information is created (step S5). Next, it is determined whether or not the common part information, the difference information, and the decompression routine information (each information) are compressed by the compression algorithm (step S6). In the case of compression (step S6: Yes), the information is compressed (step S7). At that time, an existing compression algorithm can be used.

  Next, the compressed common part information, difference information, and decompression routine information are output (step S8), and the process ends. On the other hand, if compression is not performed in step S6 (step S6: No), the common part information, the difference information, and the decompression routine information are output as they are (step S8), and the process ends. In step S4, if the information amount of the sum of the common part information and the difference information is larger than the total information amount of the original information (step S4: No), the original information is output as it is. (Step S9), the process ends.

  The information on the common part, the difference information, the development routine information, or the original information output in step S8 or step S9 is written in the ROM mounted on the system board or the ROM mounted on the system board. FIG. 2 is a diagram schematically showing the storage state of the ROM in which the information on the common part, the difference information, and the development routine information are written. In the conventional storage state shown in FIG. 23, although the first section 3 and the third section 5 are almost the same, each section is stored in the ROM 1 independently. On the other hand, according to the embodiment shown in FIG. 2, the ROM 1 includes the boot loader 2, the first section 3, the second section 4, the fourth section 6, the first section 3, and the like third. Information of difference from the section 7 is stored as follows.

  Next, a common part candidate extraction method will be described. The extraction method is not particularly limited, but there are the following five methods. FIG. 3 is a flowchart of a first method of extracting common part candidates. As shown in FIG. 3, in the first method, first, a section name is acquired from section information in a load module executed by each processor (step S111). Next, an area having the same section name is registered as a common part candidate (step S112).

  In order to find an area having the same section name, for example, a section having the same name as a section name in a load module executed by the first processor, a second processor, a third processor,. What is necessary is just to search whether it exists in the load module to execute. Here, the section is an instruction code part of the program, a data part, or a set of routines into which they are divided in more detail.

  FIG. 4 is a flowchart of a second method for extracting common part candidates, and FIG. 5 is a diagram for explaining the second method. As shown in FIGS. 4 and 5, in the second method, first, when the programs of the respective processors are linked, the processor output from the linkage editor (linker) of binary data (PE # 0, PE # 1). Each section information 13 and 14 is acquired using the information 11 and 12 of each linker map list, and each section name is acquired (step S121). Next, an area having the same section name is registered as a common part candidate (step S122).

  For example, FIG. 6 shows an example of section information obtained from output information from the linker of the first processor. FIG. 7 shows an example of section information obtained from output information from the linker of the second processor. In the example shown in both figures, section names such as “kernel_code_sc” and “LIBCODE_A” are included in common. Therefore, these named sections are candidates for the common part.

  FIG. 8 is a flowchart of a third method for extracting common part candidates, and FIG. 9 is a diagram for explaining the third method. As shown in FIGS. 8 and 9, in the third method, first, information specified by the user is acquired (step S131). Then, the user's designated areas 15, 16, 17, and 18 are registered as common part candidates (step S132). In the example shown in FIG. 9, the user designation area 15 and the user designation area 16 are one of the common part candidates, and the user designation area 17 and the user designation area 18 are one of the common part candidates.

  FIG. 10 is a flowchart of a fourth method for extracting common part candidates, and FIG. 11 is a diagram for explaining the fourth method. As shown in FIGS. 10 and 11, in the fourth method, first, part or all of the binary data of the program of each processor is automatically divided into a plurality of regions of the same size (step S141). Then, each divided area is registered as a common part candidate (step S142).

  In the example shown in FIG. 11, the binary data (PE # 0) 19 of the first processor program is divided into PE0-B1, PE0-B2, PE0-B3, PE0-B4, PE0-B5, and PE0-B6. The binary data (PE # 1) 20 of the second processor program is divided into PE1-B1, PE1-B2, PE1-B3, PE1-B4, PE1-B5, and PE1-B6. In this case, PE0-B1 and PE1-B1 are one of the common part candidates, and PE0-B2 and PE1-B2 are one of the common part candidates. The same applies to PE0-B3 and PE1-B3 and later.

  FIG. 12 is a flowchart of a fifth method for extracting common part candidates, and FIG. 13 is a diagram for explaining the fifth method. As shown in FIGS. 12 and 13, in the fifth method, first, binary data is divided into a plurality of regions based on the continuity of data (step S151). Specifically, a part or all of the binary data of the program of each processor is focused on an address where information inside the binary data is stored, and divided into areas where data is continuously stored. Then, an area having the same or similar size of each divided area is registered as a common part candidate (step S152).

  In the example shown in FIG. 13, the binary data (PE # 0) 19 of the program of the first processor is divided into PE0-P1, PE0-P2, PE0-P3 and PE0-P4, and the program of the second processor Binary data (PE # 1) 20 is divided into PE1-P1, PE1-P2, and PE1-P3. PE0-P1 and PE1-P1 are similar in size. PE0-P4 and PE1-P3 have the same size. In this case, PE0-P1 and PE1-P1 are one of the common part candidates, and PE0-P4 and PE1-P3 are one of the common part candidates.

  In addition, you may make it extract the candidate of a common part combining 2 or more of the 1st-5th methods mentioned above. For example, when the third method and other methods are combined, the area designated by the user by the third method is given priority as a common part candidate. Then, the common portion candidates are registered by applying the first method, the second method, the fourth method, or the fifth method to the remaining regions other than the region designated by the user.

  Next, an example of the data structure of the common part information and the difference information generated from the original information will be described. 14 is a diagram showing an example of the data structure of the original information, and FIG. 15 is a diagram showing an example of the data structure of the common part information and the difference information generated from the original information of FIG. . For example, as shown in FIG. 14, it is assumed that the first section 3 and the third section 5 are almost the same and are candidates for the common part. The first addresses of the first section 3 and the third section 5 are B1 and B2, respectively.

  In the first section 3 and the third section 5, offset addresses from the respective head addresses B1 and B2 to the head of the address Addr1 of the first section 3 and the address Addr2 of the third section 5 are denoted as A1. To do. Similarly, in the first section 3 and the third section 5, offset addresses from the respective head addresses B1 and B2 to the head of the data Data1 of the first section 3 and the data Data2 of the third section 5 are A2 And

  In this case, according to the present embodiment, as shown in FIG. 15, the first section 3 becomes information of the common part. Therefore, for the first section 3, the head address is B1, and the offset addresses to the head of the address Addr1 and the data Data1 are A1 and A2, respectively. Then, as the difference information 7 of the third section 5 with respect to the first section 3, the information that the addresses and data starting from the offset addresses A1 and A2 from the start address B1 are set to Addr2 and Data2, respectively, is added. The

  Next, a specific example of the data structure of difference information will be described. 16 to 22 are diagrams illustrating an example of a detailed data structure of difference information. In the example shown in FIG. 16, the difference information 7 includes an entire address 21 of absolute addresses and 1-byte data (difference data) 22. In the example illustrated in FIG. 17, the difference information 7 includes an entire address 21 and 2-byte data (difference data) 23. In the example shown in FIG. 18, the difference information 7 includes an entire address 21 and 4-byte data (difference data) 24.

  In the example shown in FIG. 19, the difference information 7 includes a 4-byte offset address 25 and 4-byte data 24. In the example shown in FIG. 20, the difference information 7 includes a 3-byte offset address 26 and 1-byte data 22. In the example illustrated in FIG. 21, the difference information 7 includes a 2-byte offset address 27 and 2-byte data 23. In the example illustrated in FIG. 22, the difference information 7 includes a 1-byte offset address 28 and 1-byte data 22. Note that the number of bytes of the address and the number of bytes of data are not limited to those exemplified here.

  As described above, according to the embodiment, information on similar sections is reconfigured into information on the common part and information on the difference therebetween, so that the capacity of the program stored in the ROM can be reduced. Accordingly, it is possible to reduce the required capacity of the ROM of the system board incorporated in a computer, a home appliance or the like. As a result, a device in which the system board is incorporated can be provided at low cost. When the present invention is applied to a single processor system, the program stored in the ROM includes a plurality of programs executed by a single processor, and common part candidates are extracted between different programs. Is done.

  The ROM stored data generation method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. This program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer. Further, this program may be a transmission medium that can be distributed via a network such as the Internet.

  As described above, the ROM stored data generation method and the ROM stored data generation program according to the present invention are useful for a device in which a multiprocessor or a single processor is incorporated, and particularly for a computer, a computer peripheral device, or a home appliance. Is suitable.

  The present invention relates to a ROM storage data generation method for generating data stored in a read only memory (ROM) and a ROM storage data generation program for causing a computer to execute the method.

  Conventionally, in an embedded asymmetric multiprocessor system incorporating a plurality of processors, an operating system (OS) and application programs are stored in different memory address areas of the ROM for each processor that executes them. For example, it is assumed that the first processor executes an OS and a program stored in the first section and the second section of the ROM.

  Further, it is assumed that the second processor executes the OS and programs stored in the third section and the fourth section of the ROM. In such a case, the binary image of the program for each processor may differ only in part such as the branch destination address and the value of the data pointer, and the remaining data and processing routine may be almost the same.

  For example, in the above example, it is assumed that the first section and the third section are almost the same. Even in such a case, conventionally, as shown in FIG. 23, the ROM 1 includes a boot loader (Boot loader) 2, a first section (Sec1) 3, a second section (Sec2) 4, and a third section (Sec3). ) 5, fourth section (Sec 4) 6,..., Each section is stored for each processor.

  When the multiprocessor system operates, the OS and application program for each processor are read from the ROM 1 and loaded in the main work memory. The same applies to a single processor system in which a single processor executes a plurality of OSs and programs.

  By the way, with respect to the boot loading method in the multiprocessor system, at least one loader ROM is shared, and when the power is turned on, the program is downloaded to the volatile memory of each processor by the program of the loader ROM. The method of doing is well-known (for example, refer patent document 1). In this method, the loader ROM program is composed of a portion common to each board and a portion that is different for each board.

  Further, a microcomputer system that executes an OS including a common unit and a plurality of additional units having different functions is known (for example, see Patent Document 2). In this system, a ROM that stores a common part of a plurality of OSs, a ROM group that stores a plurality of additional parts of the OS, a switch for selecting one additional part from the additional parts of the plurality of OSs, an OS Means for reading out from the ROM and the ROM group and storing them in the processing memory, respectively.

JP-A-62-272341 JP 63-58536 A

  However, as described above, in a multiprocessor system, if a plurality of OSs and application programs operating on each processor are simply stored in each ROM, a large-capacity ROM is required. For this reason, the cost of the system board constituting the multiprocessor system is increased, and equipment such as a computer and a home appliance in which the board is incorporated becomes expensive. Therefore, in order to provide these devices at a low cost, it is necessary to reduce the cost of the system board. To that end, it is necessary to reduce the capacity of a plurality of OSs and application programs stored in the ROM.

  The same applies to the system board constituting a single processor system. Further, Patent Document 1 does not describe how to generate data of a portion common to each board of the loader ROM program and data of a portion different depending on each board. Similarly, Patent Document 2 does not describe how to generate a common unit and a plurality of additional units of a plurality of OSs.

  The present invention has been made in view of the above, and an object thereof is to provide a ROM storage data generation method and a ROM storage data generation program capable of reducing the capacity of a ROM provided on a system board.

  In order to solve the above-described problems and achieve the object, the present invention extracts common part candidates from a program consisting of a plurality of sections, compares the extracted common part candidates with each other, and calculates a difference. It is characterized by generating information. If the sum of the information amount of the common part and the difference information amount is smaller than the original information amount, the information of the common part and the difference information are output as ROM storage data. If the sum of the information amount of the common part and the information amount of the difference is larger than the original information amount, the original information is directly output as ROM storage data without being divided into the common part information and the difference information.

  There are the following five methods for extracting common part candidates. The first method is a method in which a section name is acquired from information of each section, and an area having the same section name is used as a common part candidate. The second method is a method in which a section name is acquired from linkage editor output information at the time of program linking, and an area having the same section name is used as a common part candidate. The third method is a method in which an area designated by the user is used as a common part candidate. The fourth method is a method in which the entire binary data is divided into a plurality of regions of the same size and each region is used as a candidate for a common part. The fifth method is a method in which the entire binary data is divided into a plurality of regions based on the continuity of the data, and regions having the same or similar size are used as candidates for the common portion.

  You may make it extract the candidate of a common part combining 2 or more of the said 1st to 5th extraction methods. Here, as the difference information, the entire address and fixed length difference data may be generated, or a fixed length offset address and fixed length difference data may be generated. Alternatively, the common part information and the difference information may be compressed by a compression algorithm and then output as ROM storage data.

  When the present invention is applied to a multiprocessor system, the programs stored in the ROM include a plurality of programs that are expanded in a memory shared by a plurality of processors and are simultaneously executed by the plurality of processors. In this case, a candidate for a common part is extracted between programs executed by different processors. This is because the program or data binary image for each processor may be the same for most of the remaining data and processing routines, except for some differences such as the branch destination address and data pointer value. . When the present invention is applied to a single processor system, the program stored in the ROM includes a plurality of programs executed by a single processor, and common part candidates are extracted between different programs. .

  The ROM stored data generation method and the ROM stored data generation program according to the present invention have the effect that the capacity of the ROM provided on the system board can be reduced. Accordingly, it is possible to provide an inexpensive device such as a computer or home appliance in which the system board is incorporated.

  Embodiments of a ROM storage data generation method and a ROM storage data generation program according to the present invention will be described below in detail with reference to the drawings. Note that the present invention is not limited to the embodiments. In this specification, the ROM is rewritable that can rewrite part or all of the program written in the manufacturing stage as well as the mask ROM in which the program written in the manufacturing stage cannot be rewritten later. Non-volatile memories such as EEPROMs such as EPROMs and flash memories are included.

  FIG. 1 is a flowchart of an embodiment of a ROM storage data generation method according to the present invention. As shown in FIG. 1, first, candidates for common parts are extracted from execution format load modules executed by the processors of the multiprocessor system (step S1). Details of this candidate extraction method will be described later. Next, the extracted common part candidates are binary compared with each other (step S2). And the information of the difference between the candidates of the compared common part is created (step S3). In FIG. 1, the common part C and the difference D are used to simplify the description.

  Next, it is determined whether the information amount of the sum of the common part information and the difference information is smaller than the total information amount of the original information (step S4). As a result, when the number is small (step S4: Yes), information on the expansion routine for restoring the common part information and the difference information is created (step S5). Next, it is determined whether or not the common part information, the difference information, and the decompression routine information (each information) are compressed by the compression algorithm (step S6). In the case of compression (step S6: Yes), the information is compressed (step S7). At that time, an existing compression algorithm can be used.

  Next, the compressed common part information, difference information, and decompression routine information are output (step S8), and the process ends. On the other hand, if compression is not performed in step S6 (step S6: No), the common part information, the difference information, and the decompression routine information are output as they are (step S8), and the process ends. In step S4, if the information amount of the sum of the common part information and the difference information is larger than the total information amount of the original information (step S4: No), the original information is output as it is. (Step S9), the process ends.

  The information on the common part, the difference information, the development routine information, or the original information output in step S8 or step S9 is written in the ROM mounted on the system board or the ROM mounted on the system board. FIG. 2 is a diagram schematically showing the storage state of the ROM in which the information on the common part, the difference information, and the development routine information are written. In the conventional storage state shown in FIG. 23, although the first section 3 and the third section 5 are almost the same, each section is stored in the ROM 1 independently. On the other hand, according to the embodiment shown in FIG. 2, the ROM 1 includes the boot loader 2, the first section 3, the second section 4, the fourth section 6, the first section 3, and the like third. Information of difference from the section 7 is stored as follows.

  Next, a common part candidate extraction method will be described. The extraction method is not particularly limited, but there are the following five methods. FIG. 3 is a flowchart of a first method of extracting common part candidates. As shown in FIG. 3, in the first method, first, a section name is acquired from section information in a load module executed by each processor (step S111). Next, an area having the same section name is registered as a common part candidate (step S112).

  In order to find an area having the same section name, for example, a section having the same name as a section name in a load module executed by the first processor, a second processor, a third processor,. What is necessary is just to search whether it exists in the load module to execute. Here, the section is an instruction code part of the program, a data part, or a set of routines into which they are divided in more detail.

  FIG. 4 is a flowchart of a second method for extracting common part candidates, and FIG. 5 is a diagram for explaining the second method. As shown in FIGS. 4 and 5, in the second method, first, when the programs of the respective processors are linked, the processor output from the linkage editor (linker) of binary data (PE # 0, PE # 1). Each section information 13 and 14 is acquired using the information 11 and 12 of each linker map list, and each section name is acquired (step S121). Next, an area having the same section name is registered as a common part candidate (step S122).

  For example, FIG. 6 shows an example of section information obtained from output information from the linker of the first processor. FIG. 7 shows an example of section information obtained from output information from the linker of the second processor. In the example shown in both figures, section names such as “kernel_code_sc” and “LIBCODE_A” are included in common. Therefore, these named sections are candidates for the common part.

  FIG. 8 is a flowchart of a third method for extracting common part candidates, and FIG. 9 is a diagram for explaining the third method. As shown in FIGS. 8 and 9, in the third method, first, information specified by the user is acquired (step S131). Then, the user's designated areas 15, 16, 17, and 18 are registered as common part candidates (step S132). In the example shown in FIG. 9, the user designation area 15 and the user designation area 16 are one of the common part candidates, and the user designation area 17 and the user designation area 18 are one of the common part candidates.

  FIG. 10 is a flowchart of a fourth method for extracting common part candidates, and FIG. 11 is a diagram for explaining the fourth method. As shown in FIGS. 10 and 11, in the fourth method, first, part or all of the binary data of the program of each processor is automatically divided into a plurality of regions of the same size (step S141). Then, each divided area is registered as a common part candidate (step S142).

  In the example shown in FIG. 11, the binary data (PE # 0) 19 of the first processor program is divided into PE0-B1, PE0-B2, PE0-B3, PE0-B4, PE0-B5, and PE0-B6. The binary data (PE # 1) 20 of the second processor program is divided into PE1-B1, PE1-B2, PE1-B3, PE1-B4, PE1-B5, and PE1-B6. In this case, PE0-B1 and PE1-B1 are one of the common part candidates, and PE0-B2 and PE1-B2 are one of the common part candidates. The same applies to PE0-B3 and PE1-B3 and later.

  FIG. 12 is a flowchart of a fifth method for extracting common part candidates, and FIG. 13 is a diagram for explaining the fifth method. As shown in FIGS. 12 and 13, in the fifth method, first, binary data is divided into a plurality of regions based on the continuity of data (step S151). Specifically, a part or all of the binary data of the program of each processor is focused on an address where information inside the binary data is stored, and divided into areas where data is continuously stored. Then, an area having the same or similar size of each divided area is registered as a common part candidate (step S152).

  In the example shown in FIG. 13, the binary data (PE # 0) 19 of the program of the first processor is divided into PE0-P1, PE0-P2, PE0-P3 and PE0-P4, and the program of the second processor Binary data (PE # 1) 20 is divided into PE1-P1, PE1-P2, and PE1-P3. PE0-P1 and PE1-P1 are similar in size. PE0-P4 and PE1-P3 have the same size. In this case, PE0-P1 and PE1-P1 are one of the common part candidates, and PE0-P4 and PE1-P3 are one of the common part candidates.

  In addition, you may make it extract the candidate of a common part combining 2 or more of the 1st-5th methods mentioned above. For example, when the third method and other methods are combined, the area designated by the user by the third method is given priority as a common part candidate. Then, the common portion candidates are registered by applying the first method, the second method, the fourth method, or the fifth method to the remaining regions other than the region designated by the user.

  Next, an example of the data structure of the common part information and the difference information generated from the original information will be described. 14 is a diagram showing an example of the data structure of the original information, and FIG. 15 is a diagram showing an example of the data structure of the common part information and the difference information generated from the original information of FIG. . For example, as shown in FIG. 14, it is assumed that the first section 3 and the third section 5 are almost the same and are candidates for the common part. The first addresses of the first section 3 and the third section 5 are B1 and B2, respectively.

  In the first section 3 and the third section 5, offset addresses from the respective head addresses B1 and B2 to the head of the address Addr1 of the first section 3 and the address Addr2 of the third section 5 are denoted as A1. To do. Similarly, in the first section 3 and the third section 5, offset addresses from the respective head addresses B1 and B2 to the head of the data Data1 of the first section 3 and the data Data2 of the third section 5 are A2 And

  In this case, according to the present embodiment, as shown in FIG. 15, the first section 3 becomes information of the common part. Therefore, for the first section 3, the head address is B1, and the offset addresses to the head of the address Addr1 and the data Data1 are A1 and A2, respectively. Then, as the difference information 7 of the third section 5 with respect to the first section 3, the information that the addresses and data starting from the offset addresses A1 and A2 from the start address B1 are set to Addr2 and Data2, respectively, is added. The

  Next, a specific example of the data structure of difference information will be described. 16 to 22 are diagrams illustrating an example of a detailed data structure of difference information. In the example shown in FIG. 16, the difference information 7 includes an entire address 21 of absolute addresses and 1-byte data (difference data) 22. In the example illustrated in FIG. 17, the difference information 7 includes an entire address 21 and 2-byte data (difference data) 23. In the example shown in FIG. 18, the difference information 7 includes an entire address 21 and 4-byte data (difference data) 24.

  In the example shown in FIG. 19, the difference information 7 includes a 4-byte offset address 25 and 4-byte data 24. In the example shown in FIG. 20, the difference information 7 includes a 3-byte offset address 26 and 1-byte data 22. In the example illustrated in FIG. 21, the difference information 7 includes a 2-byte offset address 27 and 2-byte data 23. In the example illustrated in FIG. 22, the difference information 7 includes a 1-byte offset address 28 and 1-byte data 22. Note that the number of bytes of the address and the number of bytes of data are not limited to those exemplified here.

  As described above, according to the embodiment, information on similar sections is reconfigured into information on the common part and information on the difference therebetween, so that the capacity of the program stored in the ROM can be reduced. Accordingly, it is possible to reduce the required capacity of the ROM of the system board incorporated in a computer, a home appliance or the like. As a result, a device in which the system board is incorporated can be provided at low cost. When the present invention is applied to a single processor system, the program stored in the ROM includes a plurality of programs executed by a single processor, and common part candidates are extracted between different programs. Is done.

  The ROM stored data generation method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. This program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer. Further, this program may be a transmission medium that can be distributed via a network such as the Internet. The following additional notes are disclosed with respect to the embodiment described above.

(Additional remark 1) The step which extracts the candidate of a common part from the program which consists of a plurality of sections, The step which compares the extracted candidate of the said common part mutually and produces | generates the information of a difference, The information of the said common part ROM storage data, comprising: outputting the common part information and the difference information as ROM storage data when the sum of the amount and the difference information amount is smaller than the original information amount. Generation method.

(Supplementary note 2) The ROM storage data according to supplementary note 1, wherein when the common part candidate is extracted, the section name is obtained from the information of each section, and the area having the same section name is used as the common part candidate. Generation method.

(Additional remark 3) When extracting a candidate for a common part, a section name is acquired from linkage editor output information at the time of linking a program, and an area having the same section name is used as a candidate for a common part. The ROM storage data generation method as described.

(Supplementary note 4) The ROM stored data generation method according to supplementary note 1, wherein when a common part candidate is extracted, an area designated by a user is used as a common part candidate.

(Supplementary note 5) The ROM stored data according to supplementary note 1, wherein when extracting a candidate for a common part, the entire binary data is divided into a plurality of areas of the same size, and each area is made a candidate for a common part. Generation method.

(Supplementary note 6) When extracting common part candidates, the entire binary data is divided into a plurality of areas based on the continuity of the data, and areas of the same or similar size are used as common part candidates. The ROM stored data generation method according to appendix 1.

(Supplementary note 7) The ROM storage data generation method according to supplementary note 1, wherein as the difference information, difference data of the entire address and fixed length is generated.

(Supplementary note 8) The ROM stored data generation method according to supplementary note 1, wherein a fixed-length offset address and a fixed-length difference data are generated as the difference information.

(Supplementary note 9) When outputting the common part information and the difference information as ROM storage data, the common part information and the difference information are compressed by a compression algorithm and then outputted. 2. The ROM storage data generation method according to 1.

(Supplementary Note 10) The program includes a plurality of programs that are expanded in a memory shared by a plurality of processors and are simultaneously executed by the plurality of processors, and a candidate for a common part between programs executed by different processors The ROM stored data generation method according to any one of appendices 1 to 9, wherein the data is extracted.

(Additional remark 11) The said program contains the several program run by a single processor, The candidate of a common part is extracted among different programs, Any one of Additional remark 1-9 characterized by the above-mentioned. The ROM storage data generation method as described.

(Additional remark 12) The ROM storage data generation program for making a computer perform the ROM stored data generation method as described in any one of the said additional remarks 1-11.

  As described above, the ROM stored data generation method and the ROM stored data generation program according to the present invention are useful for a device in which a multiprocessor or a single processor is incorporated, and particularly for a computer, a computer peripheral device, or a home appliance. Is suitable.

FIG. 1 is a flowchart of an embodiment of a ROM storage data generation method according to the present invention. FIG. 2 is a diagram schematically showing a storage state of the ROM in which information generated by the ROM storage data generation method according to the present invention is written. FIG. 3 is a flowchart of a first method for extracting candidates for common parts in the ROM storage data generation method according to the present invention. FIG. 4 is a flowchart of a second method for extracting candidates for the common part of the ROM storage data generation method according to the present invention. FIG. 5 is a diagram for explaining the second method. FIG. 6 is a diagram illustrating an example of section information obtained from linker output information when a common part candidate is extracted by the second method. FIG. 7 is a diagram illustrating another example of the section information obtained from the linker output information when the common part candidates are extracted by the second method. FIG. 8 is a flowchart of a third method for extracting candidates for common parts in the ROM storage data generation method according to the present invention. FIG. 9 is a diagram for explaining the third method. FIG. 10 is a flowchart of a fourth method for extracting candidates for the common part of the ROM storage data generation method according to the present invention. FIG. 11 is a diagram for explaining the fourth method. FIG. 12 is a flowchart of a fifth method for extracting candidates for the common part of the ROM storage data generation method according to the present invention. FIG. 13 is a diagram for explaining the fifth method. FIG. 14 is a diagram illustrating an example of the data structure of the original information. FIG. 15 is a diagram illustrating an example of a data structure of common part information and difference information generated from the original information illustrated in FIG. 14. FIG. 16 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 17 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 18 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 19 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 20 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 21 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 22 is a diagram illustrating an example of a detailed data structure of difference information. FIG. 23 is a diagram schematically showing a storage state of a conventional ROM.

Explanation of symbols

PE0-B1 to PE0-B6, PE1-B1 to PE1-B6 Area divided into the same size PE0-P1 to PE0-P4, PE1-P1 to PE1-P3 Area divided based on data continuity 1 ROM
3, 4, 5, 6 Section 7 Difference information 11, 12 Linkage editor output information 15, 16, 17, 18 User specified area 19, 20 Binary data 21 Entire address 22, 23, 24 Difference data 25, 26, 27, 28 Offset address

Claims (12)

  Extracting a candidate for a common part from a program composed of a plurality of sections; generating a difference information by comparing the extracted candidates for the common part with each other; and an information amount of the common part and the difference And outputting the information on the common part and the difference information as ROM storage data when the sum of the information amounts is smaller than the original information amount.   2. The ROM storage data generation method according to claim 1, wherein when the common part candidate is extracted, a section name is acquired from information of each section, and an area having the same section name is set as a common part candidate.   2. The ROM according to claim 1, wherein when the common part candidate is extracted, a section name is obtained from linkage editor output information when the program is linked, and an area having the same section name is used as a common part candidate. Stored data generation method.   2. The ROM storage data generation method according to claim 1, wherein when the common part candidate is extracted, an area designated by the user is set as a common part candidate.   2. The ROM storage data generation method according to claim 1, wherein when extracting the common part candidate, the entire binary data is divided into a plurality of areas of the same size, and each area is set as a common part candidate.   The common part candidate is extracted by dividing the entire binary data into a plurality of areas based on the continuity of the data, and an area having the same or similar size is used as a candidate for the common part. 2. The ROM storage data generation method according to 1.   The ROM stored data generation method according to claim 1, wherein as the difference information, difference data having an entire address and a fixed length is generated.   The ROM stored data generation method according to claim 1, wherein a fixed-length offset address and fixed-length difference data are generated as the difference information.   The information on the common part and the information on the difference are output as ROM storage data after being compressed by a compression algorithm when the information on the common part and the information on the difference are output as ROM storage data. ROM storage data generation method.   The program includes a plurality of programs which are expanded in a memory shared by a plurality of processors and are simultaneously executed by the plurality of processors, and a common part candidate is extracted between programs executed by different processors. The ROM storage data generation method according to claim 1, wherein:   The ROM according to any one of claims 1 to 9, wherein the program includes a plurality of programs executed by a single processor, and a common part candidate is extracted between different programs. Stored data generation method.   A ROM storage data generation program for causing a computer to execute the ROM storage data generation method according to any one of claims 1 to 11.

Images