Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1996-11-18
2001-02-06
Le, Dieu-Minh T. (Department: 2785)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S038110, C714S025000
Reexamination Certificate
active
06185700
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a function of executing only one machine instruction for a program evaluation device, and more particularly, to a procedure step execution for executing a called sub-program together.
In the case of executing program development, one program is made up of a large number of sub-programs (sub-routines). There are many cases in which each sub-program is processed by calling further another sub-program therefrom, thus providing nestings several times over. The procedure for debugging of the program thus structured is not to debug the entire large program from the beginning, but to debug a sub-program from a lower stack of the nesting toward higher stacks sequentially. In this case, because the sub-programs in the lower stacks have been debugged, they need not be called when the higher sub-program is debugged.
For debugging a program, a method of executing steps for each instruction is frequently used, however, it is unnecessary to execute the steps for the sub-program which has been debugged. For that reason, the program evaluation device for debugging the program has a function called “procedure step execution” for executing steps within the sub-program together.
2. Description of the Related Art
A conventional procedure step execution function is to count the number of executions of sub-program call instructions (hereinafter referred to as “CALL”) and the number of executions of reset instructions (hereinafter referred to as “RET”) from the sub-program, respectively, and to judge that the execution of the sub-program has been terminated when the former is coincident with the latter. Hereinafter, a description will be given of the flow of the respective steps (
1
) to (
7
) illustrated in FIG.
9
.
In step (
1
), it is judged whether an instruction to be executed is CALL, RET or another instruction, and in case of CALL, CALL is executed and its occurrence is counted in steps (
2
) and (
3
). If it is judged that the instruction is RET, RET is executed and its occurrences is counted in steps (
5
) and (
6
). If it is judged that the instruction is neither CALL nor RET, the instruction is executed in step (
4
), and control returns to step (
1
) for the execution of the succeeding instruction.
If the executed instruction is CALL or RET, in step (
7
), the number of occurrences of CALL is compared with that of RET, and if the former is coincident with the latter, it is judged that the execution of the sub-program which has been called initially has been terminated. In this situation, if the former is inconsistent with the latter, it is judged that the execution of the sub-program which has been called initially has not yet been terminated, and control returns to step (
1
) for the execution of the succeeding instruction.
Subsequently, the conventional procedure step execution will be described in detail with an example of the program shown in
FIG. 10. A
method of judging the termination of a sub-program which will be described below is slightly different from the method of judging the completion shown in FIG.
9
. The method of
FIG. 10
substitutes the number of CALL executions for a variable which is COUNT, and COUNT is increased by the execution of CALL but decreased by the execution of RET so that when COUNT is 0, it is judged that the sub-program is terminated.
FIG. 10
shows a program for calling and processing sub-programs SUB1 and SUB2 in a program of MAIN, and
FIG. 11
shows a schematic diagram of the processing, and a change in COUNT. In
FIG. 11
, CALL and RET in steps (
1
) to (
5
) correspond to steps (
1
) to (
5
) in FIG.
10
.
First of all, in the case where CALL of (A) is executed, COUNT is increased with the result of COUNT=1; in the case of CALL of (B), COUNT=2; in the case of RET of (C), COUNT=1; in the case of CALL of (D), COUNT=2; in the case of RET of (E), COUNT=1; and in the case of RET of (F), COUNT=0. Thus, the termination of the sub-program is determined.
A circuit for executing the above-mentioned method of judging the sub-program termination will be described with reference to
FIGS. 2 and 12
.
FIG. 2
is a diagram showing the entire system for conducting program evaluation. Reference numeral
200
denotes a program evaluation device;
218
, a host computer for controlling the program evaluation device
200
; and
216
, a target system controlled by a debugged program. Hereinafter, the respective components of the program evaluation device
200
will be described.
A CPU
202
controls the respective components of the program evaluation device using a ROM
204
and a RAM
203
in which a control program is stored. An evaluation processor
205
has two operation modes consisting of a user mode that executes a program to be debugged and a supervisor mode that conducts debugging. The evaluation processor
205
uses a ROM
207
and a RAM
206
in which the supervisor program is stored at the time of the supervisor mode, and a ROM
209
and a RAM
208
in which a program to be debugged is stored at the time of the user mode. Those ROMs
204
,
207
,
209
and RAMs
203
,
206
,
208
are connected to each other through a variety of buses such as an address bus
210
, a data bus
211
or a control bus
212
. The evaluation bus
205
and a target system
216
are connected through a bus
217
. A termination judging circuit
201
determines whether the sub-program has terminated.
For the evaluation of a program, the host computer
218
stores the control program in the ROM
204
, the supervisor program in the ROM
207
and the program to be debugged in the ROM
209
, respectively, in advance. Needless to say the ROMS may be EPROMs or RAMs. Then, the evaluation processor
205
starts the supervisor program according to the control program to prepare program evaluation. When the evaluation processor
205
is in the supervisor mode, the ROM
209
and the RAM
208
in which the program to be debugged is programmed, a value of an inner register in the evaluation processor
205
according to the execution result of the program to be debugged, and a state within the target system
216
as occasion demands are monitored so that they can be confirmed by the host computer
218
.
Upon starting the evaluation of program, the evaluation processor
205
allows a reset signal
213
to be generated from the CPU
202
in the supervisor mode, to initiate a flip flop circuit
1
and an up/down counter
16
(shown in FIG.
12
). Then, referring to the ROM
209
, it is judged whether an instruction to be executed by the program to be debugged is CALL or other instructions. In the case of an instruction other than CALL, the CPU
202
makes a step execution control terminal
214
active. When a step execution control terminal
10
becomes active, the evaluation processor
205
executes one instruction of the program to be debugged in the user mode, and returns to be in the supervisor mode again. It should be noted that since the step execution control signal
214
is latched by an I/O port
222
, the CPU
202
makes the step execution control signal
214
inactive when the evaluation processor
205
returns to be in the supervisor mode.
In the case where the program to be debugged is CALL, the step execution control signal
214
is not made active and executes CALL in the user mode. In this case, the program to be debugged is executed continuously even after CALL is executed. The CALL strobe terminal
11
and the RET strobe terminal
12
of the evaluation processor
205
output 1 level when executing a normal instruction, but when executing CALL or RET, outputs 0 level from corresponding strobe terminals, respectively. This is conducted by microprograms of CALL and RET of the evaluation processor
205
.
The flip flop circuit
1
outputs 1 level to a supervisor interrupt request (SVIRQ) terminal
9
since it is reset in advance as described above. An up/down counter
16
up-counts at the rising of a CALL strobe and down-counts at the rising of RET strobe.
Niwa Kunio
Takahashi Kouichi
Le Dieu-Minh T.
NEC Corporation
Young & Thompson
LandOfFree
Method and device for evaluating a program does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and device for evaluating a program, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and device for evaluating a program will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2578654