JP3206559B2 - Software evaluation system - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software evaluation system, and in particular, confirms whether a subroutine program is called as specified or called as many times as specified when a subroutine program in an evaluation target program is called. In addition, the present invention relates to a software evaluation system capable of shortening the time for determining an illegal part of a target program when there is a difference from the specification of the target program.

[0002]

2. Description of the Related Art As a conventional software evaluation system of this type, a program to be evaluated is composed of a plurality of modules, one of which is accessed by a plurality of other modules. In the call operation of the subroutine program in the target program, it is checked whether the subroutine program according to the specification has been called or called as many times as the specification, and if there is a difference from the specification of the target program, the target There is a need for an evaluation system that enables the determination of unauthorized portions of a program. Such an evaluation system is shown in a block diagram of FIG. In the figure, a comparison unit 404 holds a specific address specified by a host (not shown), compares it with an address from a CPU (not shown) that executes the evaluation target program, and outputs COMP to the control unit 401. The control unit 401 receives an address from the CPU, a JUMP of a signal indicating a branch instruction, a host address, and host data. Then, various signals described later are output to the counter (CNT) 402, and the CNT 402 counts the number of executed branch instructions. The memory 403 records the count number of the branch instruction.

That is, in the system shown in FIG. 4, when the same address as a specific address specified in advance is input from the CPU to the comparison unit 404, the COMP output from the comparison unit 404 becomes valid. Then, when a signal indicating that the branch instruction has been executed, JUMP, and the COMP are input to the control unit 401, the counting of the designated branch instruction is started. The address “A” of the memory 403 is an address mapped on the evaluation system, and “1” is written as data “D” at the start of measurement. When the branch to the specific address is performed for the second time and thereafter, the CONTUP signal from the control unit 401 becomes valid, and the control unit 401 reads the Dbak, which is the data at that time, in the memory 403 and sets the CNT 403 as a Dorg. Pass to. CNT402 becomes effective CO
The data incremented by NTUP is written to the memory 403 as “D”. Therefore, the number of executed branch instructions for a specific address is recorded in the memory 403.

[0004]

As described above, in the conventional evaluation system, a specific address after branching is determined and only how many times the specific address has been accessed is measured. If the result differs from the specification, it takes a lot of time to identify where the fraud was. That is, when the program to be evaluated is composed of a plurality of modules, and one of the modules is accessed by a plurality of other modules, the above-described specific address is replaced by the head address of the one module. When the measurement is performed as follows, it is possible to measure how many times the one module has been accessed, but if the measurement result is different from the specification, where the access was made, how many times it was performed, and where the access was made Cannot be determined. Therefore, in order to specify the fraud, it is necessary to determine the fraud while measuring, for example, for each access, which takes a lot of time.

[0005] It is an object of the present invention to provide a software evaluation system capable of promptly judging an illegal result when an operation result of a program to be evaluated differs from a specification.

[0006]

The present invention SUMMARY OF THE INVENTION includes means to check the number of calls subroutine program on evaluation object program, means for confirming the branch source address of the subroutine program, the branch source address every confirmed And means for storing the number of calls. That is, a CPU that executes an operation based on software to be evaluated, a comparing unit that receives a branch instruction output from the CPU and compares an address at that time with a specific address of a branch destination specified by the host, A holding unit for holding a branch source address when the comparing unit detects the address match and outputting the branch instruction, a memory unit for storing a branch source address input from the holding unit, A counter that counts the number of addresses of the branch source input to the memory unit, wherein the memory unit stores a value counted by the counter in an area corresponding to the address of the branch source.
It is characterized in that it is configured to be stored every time .

Here, it is preferable that a decoder be provided which invalidates the subsequent counting operation of the counter when the count value stored in the memory section reaches a predetermined value. Further, it is preferable that the memory unit sets a branch source address on the evaluation target software as an address of the memory unit, and stores the count value of the counter at the set address in the memory unit.

According to the present invention, the branch source address of the branch instruction in the program to be evaluated and the branch source address thereof
By confirming and storing the number of branches for each program, it is possible to determine where access has been made, how many times it has been performed, and where no access has been made. It is possible to clarify whether the execution has been performed on the path, and to significantly reduce the time required for finding a problem when a branch different from the specification (expected value) is taken.

[0009]

Next, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram of the evaluation system of the present invention. The CPU 101 is an execution unit of the program to be evaluated. The holding unit 102 synchronizes with a program read strobe signal (PRD) from the CPU 101,
Holds the address one instruction before. The comparing unit 103 compares the address specified by the host (supervisor) with the address and the branch instruction from the CPU 101, and outputs a COMP signal to the synchronizing unit 104 when they match. The synchronizer 104 divides a bus cycle into a first half and a second half to read a strobe signal (MR) for a memory.
D) and a write strobe signal (MWR). The memory unit 105 holds the number of calls corresponding to the call address. The decoder unit 106 includes the memory unit 1
When all the values of the DOUT signal from D05 become "1", that is, when the maximum value that can be held in the memory is reached, M
An AX signal is output. The counter unit 107 outputs +1 to the memory unit 105 each time the caller address is read at the read timing in the memory unit 105. If the decoder unit 106
If the MAX signal from is valid, the data is written back to the memory unit 105 without performing the +1 operation. Although FIG. 1 does not show a portion related to the host CPU that controls the entire system, it is naturally necessary for controlling the system.

The operation of the system will be described with reference to the timing chart of FIG. First, the PRD (204) in which the CPU 101 performs a fetch operation in the holding unit 102
At the timing of the current bus cycle address (20
3) is held only during the next bus cycle. At the same time, in the comparing unit 103, the branch instruction indicating that the call instruction from the CPU 101 has been executed is valid, and the specified address from the host (supervisor) and the CPU
When the comparison of the addresses from 01 coincides, that is, when it is determined that the address is called by the branch instruction, the COMP signal (205) is made valid only for the current one bus cycle. That is, when the COMP signal (205) is valid, the value of the holding unit 102 is the caller address (20
3), and the caller address is input to the address terminal of the memory unit 105. In the synchronization unit 104, the COM
The P signal (205) is valid, and in the first half of the bus cycle (defined as a read cycle), only the memory read strobe signal MRD (206) is valid, and in the second half (defined as a write cycle), a memory write is performed. Only the strobe signal MWR (207) is valid.
Here, the CPU operation clock (201) is two clocks per bus cycle, and the content of the memory unit 105 is +
The timing which is reasonable to increment to 1 is generated. The present invention can operate as long as there are two or more periods in one bus cycle. Even if one bus cycle has one clock, the present invention can be easily realized by making the CPU double the clock.

Next, the memory value output from the DOUT of the memory unit 105 by the MRD (206) is incremented by one at the timing of the rising edge of the MRD (206) in the counter unit 107, and the incremented value is stored in the memory as it is. The data is input to the DIN of the unit 105. And MWR (2
At the rising edge timing of 07), writing to the same address is performed again. However, when the MAX signal is valid, the +1 operation is not performed and the signal is directly input to DOUT. The decoder unit 106 receives the DOU from the memory unit 105.
When all the values of the T signal become “1”, a MAX signal is output. This is because when the number of calls exceeds the value that the memory unit 105 can hold, the maximum value that the memory unit 105 can hold is held. With this series of operations, the memory unit 105 can hold the caller address as the address value and the contents as the call count.

FIG. 3A shows a program source to be evaluated in the present invention applied to the above-described embodiment.
FIG. 3 (b) shows an example of the mapping of the image data 05. When the program shown in FIG. 3A is executed from address 100, "5" is set in COUNT,
COUNT is decremented by the DEC instruction,
This is a program that loops by the BNZ instruction until it becomes "0". Also, from address 200 of the main routine to SUB-A which is a subroutine, from address 300, SUB-A
-B. Assuming that it operates as specified, the subroutines SUB-A and S
Each of UB-B is called four times, and as shown in FIG. 3B, "4" is written at address 200 and "4" is written at address 300. If SUB-A, SU
When BB is called from a program other than the program shown here, a value other than "0" is held in the caller address portion. In such a case, the memory unit 1
By checking the contents of the subroutine 05, it is possible to easily specify a branch from an address different from the specification or a difference in the number of called subroutines.

In the present invention, when the branch in the above embodiment is changed to, for example, an interrupt signal, the interrupted original address is similarly described in the memory. Can be confirmed. Since such an interrupt is an asynchronous operation, it cannot be confirmed by the conventional technique as shown in FIG.

[0014]

As described above, according to the present invention, it is possible to determine the address of a branch source and the number of branches for each branch source address. In the above, when an unexpected operation is performed, it is possible to easily determine from where and how many times the part is called, and it becomes easy to find a problem. In particular, by recording the number of calls for each branch source address, it is possible to easily compare with the call cross-reference table that is usually built in assembler, C language or compiler, and to compare specifications and differences Can be performed promptly. Further, even if there is a difference between them, the difference can be easily found.

[Brief description of the drawings]

FIG. 1 is a block diagram of an evaluation system of the present invention.

FIG. 2 is a timing chart for explaining the operation of the system of FIG. 1;

FIG. 3 is a diagram showing an evaluation program and a memory map.

FIG. 4 is a block diagram of an example of a conventional evaluation system.

[Explanation of symbols]

 101 CPU 102 holding unit 103 comparing unit 104 synchronizing unit 105 memory unit 106 decoder 107 counter

──────────────────────────────────────────────────続 き Continuation of the front page (56) References JP-A-60-27961 (JP, A) JP-A-4-42330 (JP, A) JP-A-5-100903 (JP, A) JP-A 64-64 10347 (JP, A) JP-A-61-34635 (JP, A) JP-A-4-102940 (JP, A) JP-A-3-119435 (JP, A) (58) Fields investigated (Int. Cl. ⁷ , DB name) G06F 11/28-11/36

Claims (4)

(57) [Claims] 1. An evaluation system for at least software including a reading program of a subroutine program, wherein the evaluation system determines whether or not the reading operation of the subroutine program in the software is performed as specified. A software evaluation system comprising: means for confirming the number of calls of a program; means for confirming a branch source address of the subroutine program; and means for storing the number of calls for each confirmed branch source address. 2. A CPU that executes an operation based on software to be evaluated, and a comparing unit that receives a branch instruction output from the CPU and compares an address at that time with a specific address of a branch destination specified by the host. A holding unit for holding a branch source address when the branch unit outputs the branch instruction when the comparison unit detects a match of the address, and a memory unit for storing a branch source address input from the holding unit And a counter that counts the number of addresses of the branch source input to the memory unit,
The software evaluation system, wherein the memory unit stores the value counted by the counter for each area corresponding to the address of the branch source. 3. A decoder according to claim 2, further comprising a decoder for invalidating a subsequent count operation of said counter when the count value of each area stored in said memory section reaches a predetermined value. Software evaluation system as described. 4. The memory unit sets a branch source address on the evaluation target software as an address of the memory unit, and stores a count value of the counter at the set address in the memory unit. 3. The software evaluation system according to 3.