JP3131098B2 - Simulator - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a simulator for performing a simulation (simulation test) of the operation (execution of a program) of a computer system such as an electronic exchange and verifying the operation.

[0002]

2. Description of the Related Art In the development of a computer system, a simulator is used for an evaluation test or debugging of a program. This simulator has various problems as described below due to the configuration of a computer system to be simulated (simulation test).

(1) Program simulation method of a multiprocessor computer system The operating environment of a program of a multiprocessor computer system (hereinafter, simply referred to as a multiprocessor system) operating on a plurality of processors is changed to a single workstation by a cross debugger. It is a method of simulating by using the above method. FIG. 25 is a diagram conceptually showing a configuration of a conventional simulator for performing program simulation of this multiprocessor system. This simulator is realized by a single workstation 10 shown in the figure. The computer system to be simulated by the simulator has a plurality of processors P _{i to} P _n , and communication between the processors P _{i to} P _n is performed by an information communication device, and the processing is performed by a multi-processor configuration. It is carried out.

[0004] In FIG. 25, 1 is a main control process PC _c, 2 for controlling the entire operation of the simulator is a processor simulation process groups, each process PC _i to PC _n, respectively constituting the processor simulation process unit 2 This is a process for executing programs of the processors P _{i to} P _{n to be} simulated, and performs a self-contained operation by itself. That is, in this system, processes for performing the simulated operation are generated for each single processor by the number of processors, and the multiplex operation is performed. The inter-processor communication simulation process PC _P is a process for simulating a processor P _p of an information communication device that performs inter-processor communication in an actual multiprocessor system, and a process PC _i corresponding to each of the processors P _{i to} P _n in a simulator. by performing communication between to PC _n and a main control process PC _c by interprocess communication, it is intended to simulate the inter-processor communication between actual processor P _i to P _n. An operating system (OS) 4 executes a process.

In this simulator, a plurality of processes are generated for each processor of a multiprocessor system to be simulated such that one process corresponds to one processor in the simulator. Each process simulates the operation of the target system by simulating the operation of the corresponding processor.
Such a method is simple to implement because the simulation of the operation of the processor can be executed in a self-contained manner for each process, and can be simulated in a manner close to the operation of an actual multiprocessor system.

However, this type of simulator has the following problems. Since a plurality of processes are operated on a single workstation, the load on the OS that controls the execution of the processes is large, and the overhead of the execution operation time is large. Although the communication between the processors in the actual system is simulated by the communication between the processes, the processing load for executing the communication between the processes is generally large. For this reason, for example, in a computer system that loads programs via an information communication device between processors, each processor loads a huge amount of files at the time of file startup, etc. In the case of simulation, this loading is performed by inter-process data exchange, and as a result, the amount of the loading becomes enormous and the processing time also becomes enormous.

(2) Execution level In a multiprocessor system such as an electronic exchange, usually,
Each processor executes a plurality of program processes in parallel, and these program processes are given an execution priority. Therefore, the execution of the processor is performed for a certain time t.
An interrupt is generated every (for example, 8 ms), during which time the program processing from the upper-level execution level to the lower-level execution level is performed. If all the processing is completed within a predetermined time t, the HALT state is set thereafter. Then, the processing is suspended until the next interrupt occurs.

FIG. 26 is a diagram for explaining this state. Here, in a multiprocessor system, a plurality of processors P
_i , P _j , and P _k are present, and the program processing executed by each processor is an upper execution level H, a middle execution level L,
There are three types of lower execution level B. Then, a certain time t
Every time a clock interrupt occurs, each processor executes the program processing of the upper execution level H in response to this clock interrupt, and when it completes one section, further executes the lower program processing sequentially. When the program processing of the above is completed, a halt state is set.

When such a multiprocessor system is simulated by a simulator, it is meaningless and unnecessary to simulate all the processors in a halt state, and the processing time of the simulator is unnecessarily long. Therefore, it is desirable that the simulation of the state in which all the processors are in the halt state be skipped and not performed. However, in the above-described simulation method in which a process is generated for each processor to be simulated in the simulator, in order to know that all the processors are in the halt state, it is necessary to communicate between the processes that the respective processes are in the halt state. Must notify each other at
Processing becomes complicated. (3) Processing Skip FIG. 27 shows a conceptual diagram of a simulator according to a conventional method. In the figure, 27 is a backup memory as a secondary storage device, 28 is a main memory in the simulator, 29 is a test target memory for holding the test target program A, and 30 is a simulation test of the program A in the test target memory 29. This is a simulator program to be performed.

The backup memory 27 stores a simulation target program A including a main program, sub-programs AAA, BBB, CCC and the like. Test target memory 29 from backup memory 27
In order to pull up the program A, the program A in the backup memory 27 is sequentially pulled up to the main memory 28 by a pull-up instruction of the bootstrap program loaded in the main memory, and the same program A is 29 is also held. The simulator program 30 performs simulation by sequentially executing the program A in the test target memory 29. By the way, when the simulation is executed by the simulator program 30,
A specific function in the program A may not be executed for the following reason.

Since it is desired to test only a specific part of the program A to be tested, the processing of the remaining unnecessary part is skipped to speed up the simulation. Some parts of the program A cannot be simulated because the simulator cannot simulate the hardware part of the actual simulation target system. Plan.

The above-mentioned skipping part may be a subroutine or a part in the main program. Conventionally, the processing in the program A is skipped by the following method.

(A) Before the program A is moved to the main memory, the contents of the program A are rewritten in the backup memory 27 so that the skip processing is executed at a specific portion. (B) Monitor the trigger (for example, a subroutine call instruction when skipping a subroutine) for an instruction to skip processing to the main memory, stop the operation of the program A after the instruction is pulled up, and Rewrite.

However, this conventional method has the following problems. First, in the case of the above (a), since the program A is rewritten on the backup memory 27 side, the contents of the program A as original data are destroyed, and a serious obstacle that the program A stops operating depending on the rewritten contents is caused. There is a risk. Also, it is not easy to restore the contents once rewritten.

In the case of the above (b), for example, when a simulation test is performed while partially raising the program A, it is determined when a specific portion to be rewritten is raised to the main memory 28. The rewriting procedure on the main memory 28 becomes complicated, such as the need for monitoring, so that skip processing cannot be easily performed.

(4) Overlay system The simulator is used for evaluation tests and debugging of programs in the development of computer systems. In this method, the target program is simulated, the execution of the program is stopped at a desired address, the program is traced from a desired address (for example, display, file storage, etc.), or a predetermined address is passed. By doing so, program debugging and the like are performed efficiently.

By the way, many computer systems adopt an overlay method for storage management. In this overlay method, a program is configured in an overlay structure including a plurality of program units (for example, program segments), the overlay program is stored in a secondary storage device, and the overlay program is transferred to main storage. Is to load an overlay region of main memory for each program unit.

A general overlay method in a computer system will be described with reference to FIG. In the figure, 2
7 is a large-capacity file memory (F
M) or a backup memory, and 28 is a main memory which is a high-speed temporary storage device. The overlay program is composed of a plurality of program units (here, program divisions having a predetermined number of words or less), and the backup memory 27 stores the program units at respective addresses.

The main memory 28 is provided with two overlay regions (surface A and surface B). When an overlay pull-up instruction (a type of SIO instruction) is generated,
A required program unit is read from the backup memory 27 and loaded (pulled up) on either the A-side or the B-side of the overlay area of the main memory 28, and the program unit on the main memory 28 is appropriately executed. To go.

On the other hand, in a simulator used for an evaluation test or debugging of a computer system, for example, when a program is stopped at a desired address as a test item, a stop address area and a program stopping means for stopping a simulated execution of the program are provided. The operator inputs and designates an address on the backup memory as an address at which the target program is to be stopped before or during program execution as necessary, so that the address is set in the stop address area, and the program execution is performed. When the execution address reaches the stop address during execution, the execution of the program is stopped by the program stopping means. Thereafter, by executing predetermined processing designated before or after by the operator, such as tracing addresses or displaying memory contents, data necessary for debugging or the like is collected.

However, when debugging a computer system employing the overlay method using a conventional simulator, the overlay area of the main memory in which the program unit of the overlay program is to be raised is determined when the program unit is raised. Therefore, the address on the main memory where the program unit is loaded cannot be recognized in advance.

For this reason, the operator cannot input or designate in advance the address on the main memory at which the target program is to be stopped. Therefore, every time a program unit in the overlay program is loaded, these addresses are not stored in the main memory. In this case, debugging is performed by checking the address and manually inputting / designating the address. However, this operation is very complicated.
In particular, there is a case where another program unit is started from one program unit in the overlay program, and in that case, the other program unit is further replaced with the secondary program unit in the overlay area of the main memory. In some cases, the work was overlaid from the storage device, which made the operation extremely complicated and inefficient.

(5) I / O device simulation For a simulation test of a program for controlling access to the I / O device, there is a simulator that can run the target program in a simulated manner without an actual I / O device. This simulator has a simulation means corresponding to the type of the actual input / output device, and the memory space of the input / output device to be simulated is realized by using the memory space on the storage device inside the simulator. Simulate an input / output device.

FIG. 29A shows a configuration example of such a simulator. The simulator includes an instruction execution unit and an input / output (IO) device simulation unit. The input / output device simulation unit has an input / output device memory space therein. The instruction execution means sequentially executes the target program, and when the target program accesses the memory space of the input / output device, the instruction execution means accesses the memory space of the input / output device pseudo unit instead of the actual input / output device. ing.

However, this pseudo method has the following problems. As shown in FIG. 29B, a memory space of the same size as the memory space of the input / output device to be simulated is required for the storage device inside the simulator. For this reason, if the input / output device to be simulated has a large memory space such as a magneto-optical disk device, it is practically difficult to secure an equivalent memory space in the storage device inside the simulator.

Even if a memory space of the same size as the memory space of the magneto-optical disk device can be secured on the storage device inside the simulator, the memory space is huge, so that it takes time to search for an address. Take
The processing speed of the simulation test decreases.

In the simulation test of the target program by the simulator, the memory space of the input / output device to be simulated may not be used in some cases. It is necessary to secure a memory space of the same size in the storage device inside the simulator, which puts a strain on the memory capacity that can be used by the simulator, and causes a shortage of memory capacity and a reduction in processing speed.

(6) Correct verification of normality of program logic In a conventional simulator, the following method is used to verify the normality of program logic (that is, whether or not there is a logic inconsistency). Incorporate a support program for verification into the test target program. The running of the test target program is monitored by a monitoring device (monitor) added outside the simulator, and the running information (running history and the like) is collected.

However, according to the above method, it is necessary to create a support program for each test target program, which requires a large number of manufacturing steps. Further, in the method (1), it is necessary to purchase or borrow a monitoring device, and there is a problem in preparing a simulator test environment. Usually, the collected driving information is enormous, and it is not easy to find out the cause of the fault from this driving information, and if the analyst is not experienced in analyzing the fault,
Determining the cause of a failure is often difficult in practice.

As an example, a case where there is a logical contradiction due to competition between program execution levels will be described. FIG. 30 is a diagram for explaining the conflict between the program execution levels. The computer system may execute the same program A in parallel at the high level and the low level. In this case, if the high level program is activated while the low level program is being processed, the high level program is In this case, the processing of the low-level program is interrupted, and after the processing of the high-level program is completed, the low-level program resumes the interrupted processing.

FIG. 30A shows a case where such a conflict between program execution levels is normally processed. The program A reads and writes data using the same memory at the high level and the low level. For this reason, when the low-level program A accesses the memory, interrupt inhibition is set so that the processing is not interrupted by the high-level program A while using the memory, and the interrupt inhibition is released after the use is completed. This prevents the high-level program A from using the memory redundantly.

If the interrupt is not prohibited (masked) as described above, the low-level program A stores the data "0" in the memory as shown in FIG.
Is written, the high-level program A interrupts and starts processing, and changes the contents of the memory from “0” to “1”.
When the low-level program A resumes processing due to the end of the processing of the high-level program A, even if the contents of the memory are read, the contents are changed from true “0” to the low-level program. Since the data has been rewritten to “1” which is fake data, a system error due to data value inconsistency may occur.

The conventional simulator employs the following method to determine the cause of the logical inconsistency when detecting a system abnormality due to the competition between the program running levels.

From all the traveling history information collected by the program traveling history collection device provided outside the simulator,
The program executed at both the high and low levels is traced to check whether or not a process for inhibiting (masking) the interruption of the program with the high execution level is incorporated.

Focusing on the system state at the time of system abnormality (for example, the destruction state of the memory contents) or the destructed data, the tester can determine the cause based on the trace results and the like collected by the external traveling history collection device based on the experience and know-how. Guess that is a level conflict.

However, in the above method, the running history of all programs is required, but the amount is enormous, and it is necessary to detect the lack of the interrupt mask processing of the program from the enormous amount of data. Therefore, quick investigation of the cause is substantially difficult. Further, in the above method, it is still practically difficult for an inexperienced tester to find out that the cause is a lack of interrupt mask setting processing when a system error occurs. Therefore, a quick response cannot be taken, which hinders an improvement in test efficiency. Further, since the above method is to investigate the cause after a system abnormality has occurred, the memory contents have been destroyed at that point, and it may be difficult to recover the contents.

(7) Conflicting Processing Speed and Debug Function At present, in the program simulation method, the following two performances are emphasized by the user. High processing speed (processing capacity) of the simulator itself. Have various debugging functions (program trace function, data trace function, etc.).

Here, there is a contradictory surface, and
If the number of types of debugging functions is increased to enhance debugging, the processing capability of the simulator itself decreases in proportion to the enhancement.

FIGS. 31 and 32 are diagrams for explaining the conventional system. The conventional simulator program mainly includes a simulator command control function 60 'and a system under test pseudo function 62' as shown in FIG. 31, and the system under test pseudo function 62 'includes a system under test pseudo function,
Includes machine instruction pseudo function, debug function, and simulation stop function. As shown in FIG. 32, the simulator command function performs the command processing of the simulator, and the system under test pseudo function 62 ′ has a required debugging function after the system under test pseudo processing is performed and after the machine instruction is executed. 1, 2,... I, n are determined to be operated, and when they are operated, the corresponding debugging function is implemented. The system under test 62 'performs debugging while performing the above-described determination processing one machine instruction at a time.

As described above, in the conventional method, each time one machine instruction is executed, it is determined whether or not to activate the debug function for the one machine instruction. However, it takes a long time to perform the process of determining whether or not to perform the process. For this reason, especially when the number of types of debugging functions increases, the speed of the simulator is reduced due to the time required for the determination process regardless of whether the debugging function is actually performed.

In particular, in the conventional method, the control route (the feedback loop of the process in FIG. 32) of the pseudo part of the system under test on which each debugging function operates is a part that always operates each time a machine instruction is executed one by one. Therefore, even if one step of the judgment processing is added, it is repeatedly executed for each machine instruction. Therefore, when testing the entire program, the total count becomes large, and the response (processing Ability).

Further, when starting up the system under test,
Usually, it is not necessary to use the various debug functions because the program at the start-up part has already been debugged. For this reason, it was inefficient, and the shortening of the start-up time was a great requirement of the user.

The present invention has the above problems (1) to (5).
The present invention has been made in view of (7), and has as its object to provide a simulator that solves each of these problems (1) to (7).

[0044]

According to the present invention, there is provided a simulator for simulating the operation of a multiprocessor system in order to solve the above-mentioned problem (1). A processor instruction simulating means for sequentially executing a predetermined amount of instructions of each processor in a time-division manner; an inter-processor communication simulating means for simulating an inter-processor communication operation of the multi-processor system; Simulated resource management means for allocating resources corresponding to each other and managing switching of each processor's access to its own resources, sequential execution of instructions of each processor by the processor instruction simulating means, and inter-processor communication by the inter-processor communication simulating means The execution of the operation instruction is actually simulated by the simulated resource management means. While sequentially allocates resources to the processor running, and a main control means for controlling so that periodically performed, the execution of the above means simulator configured to be performed by a single process is provided.

In this simulator, since the simulation test of the operation of each program is performed in a single process, the load on the OS can be reduced.

In the above-described simulator, the inter-processor communication simulating means can be configured to realize inter-processor communication between processors by copying data between memory resources allocated to the processors.

As a result, it is not necessary to simulate the inter-processor communication by the inter-process communication unlike the conventional method, and the inter-processor communication can be simulated at high speed and easily.

In order to solve the above problem (2), in the simulator described above, the main control means generates an interrupt when all the processors of the simulated multiprocessor system are in the halt state. Then, the simulation of each processor can be restarted.

Thus, even if all the processors are in the halt state, it is possible to prevent the state from being simulated and wasting time.

In the present invention, in order to solve the above-mentioned problem (3), a first address storage table for storing in advance the address information on the main memory of the subroutine which is not desired to be executed in the simulation target program. In response to the subroutine call instruction in the main program, before the execution of the subroutine is executed, the first address storage table is referred to, and if there is a subroutine corresponding to the subroutine call instruction, A simulator is provided which includes subroutine call instruction processing means for returning the control to the main program after rewriting the contents of the subroutine on the main memory to the contents not executing the subroutine based on the address information.

Thus, when the simulation target program calls a subroutine that does not require a simulation test during the simulation test, the subroutine is substantially executed by the subroutine call instruction processing means. Since the subroutine is rewritten to no content, the subroutine is not substantially executed, so that the simulation test can be performed efficiently.

Further, in the present invention, in order to solve the above-mentioned problem (3), the second address for storing in advance the address information on the main memory of the specific program which is not desired to be executed in the simulation target program. In response to the program pull-up instruction from the secondary storage device to the main storage, the program refers to the second address storage table before the execution of the program pulled up by the instruction is executed. And a program pull-up instruction processing means for rewriting the contents of the specific program in the main memory to contents that do not execute the specific program based on the address information of the specific program if the specific program is within the range of the program raised in the step. Simulator is provided.

Thus, when the simulation target program executes a specific program which does not require the simulation test during the simulation test, the contents of the specific program are substantially converted to the specific program by the program pull-up instruction processing means. Since the specific program is not rewritten, the specific program is not substantially executed, so that the simulation test can be performed efficiently.

In the above-described simulator, when a program portion that is not desired to be executed is rewritten once in the main memory, the corresponding item in the address storage table is deleted.

As a result, it is possible to shorten the search time of the address storage table in the subsequent processing, and to prevent the same processing from being performed again on a subroutine or a specific program which has been rewritten once. Can be improved.

According to the present invention, there is provided a simulator for simulating an overlay program having an overlay structure in order to solve the above-mentioned problem (4).
A secondary storage device for storing a plurality of program units constituting the overlay program, a main storage for overlaying the program units of the overlay program, and a point of interest in the overlay program registered by an address on the secondary storage device Address information registering means, address information storing means for storing storage address information on the secondary storage device in units of programs pulled up from the secondary storage device to the main storage, and storage address information of the address information storage means. Address conversion means for converting the address on the secondary storage device of the noted address registration means into an address on main storage based on the address information on the main storage for loading the program unit; Store as the address of the processing point of the overlay program on the main memory Provided is a simulator comprising a physical address storage means and configured to perform a predetermined process when the execution address of the overlay program raised to the main memory reaches the address of the processing point stored in the processing address storage means. .

In this simulator, if the operator registers the address of a point of interest (such as a program stop point or a trace start point) in the test target program as an address on the secondary storage device, the address conversion means The address is converted from the address on the secondary storage device to the address on the main storage device, and is stored in the processing address storage means as the address of the processing point. When the address is reached, a predetermined process can be started.

In this simulator, when another program unit is overlaid on the overlay area of the main memory where one program unit is stored, the processing address storage means provided for the one program unit is Means for invalidating the processing point address may be further provided.

Thus, it is possible to prevent the other program unit from performing a predetermined process (for example, stopping the program) at the processing point address set for the one program unit.

In this simulator, the target address registering means further includes a target address adding means for adding an address of the target point of the overlay program later, and the target address of the overlay program is added by the target address adding means. When the processing is performed, the address conversion means may convert the address into an address on the main memory and then store the address in the processing address storage means.

As a result, it is possible to add an address at which a predetermined process is to be performed to the program to be subjected to the simulation test even afterwards.

According to the present invention, in order to solve the above-mentioned problem (5), there is provided a simulator for simulating a program for driving an input / output device, which simulates a memory space of the input / output device. Storage device, instruction execution means for executing the program, and the memory space of the input / output device is virtually divided into a plurality of blocks. Address / block conversion means for determining to which block the write address belongs, and storage area securing means for securing a storage area corresponding to the block of the block number obtained by the address / block conversion means on the storage device And configured to perform a simulation test of a program while simulating the input / output device using a storage area secured on the storage device. Regulator is provided.

Further, in the present invention, in order to solve the above-mentioned problem (5), when the program to be subjected to the simulation test accesses the input / output device by writing,
The block conversion means calculates a block number corresponding to the write address, and the storage area securing means secures a storage area corresponding to the block of the block number on the storage device. This makes it possible to simulate the input / output device using only the storage area secured on the storage device.

In this simulator, when a memory area of a block corresponding to the read address is not secured on the storage device when the target program reads and accesses the memory space of the input / output device, the program And a return unit for returning data with no write data to the device.

If the storage area of the block of the blog number corresponding to the read address is not secured, it means that nothing has been written yet at the read address, so that data without write data is returned.
This eliminates the need to secure an extra storage area on the storage device.

Also, in this simulator, the instruction execution unit accesses the storage device using an address belonging to each block number, so that a storage area corresponding to each block number in the storage device can be used or not used. May be further provided.

As a result, it is possible to manage the memory space of the storage device without providing a used / unused management table.

According to the present invention, there is provided a simulator for simulating a program for solving the above-mentioned problem (6), the execution monitoring means for monitoring the execution of the program and collecting execution history information. And a simulator provided with program logic checking means for checking the normality of the program logic using the execution history information of the execution monitoring means, and output means for outputting a check result of the program logic checking means.

As a result, it is possible not only to collect the primary data such as the execution history trajectory but also to check the normality of the program logic such as the presence or absence of program logic contradiction.

In this simulator, the program logic check means detects execution of the program based on execution history information of the execution monitoring means and execution level collection means for collecting execution level information of the program being simulated. Determining whether the started program is a program causing a conflict between program execution levels based on the collection information of the execution level collecting means, and interrupting the program if the program causes a conflict between program execution levels. Competition matching means for checking whether or not there is a mask process can be provided.

By checking whether or not an interrupt mask process is incorporated in the program in the conflict between the program execution levels by the conflict checking means, it is possible to check whether or not there is an execution level conflict as a program logic conflict.

According to the present invention, in order to solve the above-mentioned problem (7), a simulator for simulating a program is provided. The simulator executes simulated execution of each instruction of the program without performing a debugging function. The first system under test pseudo function means, the second system under test pseudo function means for simulating each instruction of the program while performing the debug function, and whether or not to execute the debug function are registered for each debug function. Debugging function registering means, and referencing the contents of the debugging function registering means to store the program in the first
Simulation by means of the system under test
And a simulator command control function means for controlling whether the simulation is performed by the system under test pseudo function means.

According to this configuration, the simulator command control function means selects the first or second system under test pseudo function means depending on whether or not to execute the debugging function according to the type of the program to be tested. The target program can be mock-tested. This selection is made before the target program is actually run for the simulation test. Therefore, when the first system under test pseudo function means is selected in order not to use the debug function, the following simulation test processing is performed. It is not necessary to determine the presence or absence of the debug function,
Therefore, the processing speed can be improved at the time of starting the system, which does not require the debugging function.

[0074]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Various embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing a configuration of a simulator as one embodiment of the present invention. This embodiment is a simulator for simulating the operation of a multi-processor system comprising a plurality of processors P _i to P _n, solves the aforementioned problems in such a multiprocessor system (1) and (2). In the multiprocessor system to be simulated, the exchange of information between the processors is realized by performing interprocessor communication by the information communication device. In the simulator, programs executed by each processor of the multiprocessor system to be simulated, necessary data, and the like are prepared in advance.

In FIG. 1, 1 is a main control unit, 2 is a processor instruction simulation unit, 3 is an inter-processor communication simulation unit, 4 is a simulation resource management unit, 5 is a storage unit, and 6 is a switching unit. Here, the processor instruction simulating unit 2 is composed of a program for sequentially executing the instructions of the respective processors of the simulated multiprocessor system by a predetermined amount (one instruction in this embodiment) in a time-division manner. The inter-processor communication simulation unit 3 includes a program for simulating the operation of inter-processor communication in a multiprocessor system. The simulated resource management unit 4 is composed of a program for allocating resources corresponding to each processor of the multiprocessor system and managing switching of each processor's access to its own resource. In addition, the main control unit 1
The processor instruction simulating unit 2 sequentially executes the instructions of each processor and the inter-processor communication simulating unit 3 executes the instruction of the inter-processor communication operation. The simulated resource managing unit 4 sequentially allocates resources to the processors that are currently executing the simulation. And a program that controls the operation to be performed periodically.

The storage unit 5 is a storage resource under the control of the simulated resource management unit 4, and includes a memory 5a and a register 5b. The memory 5a and the register 5b are respectively stored in the processors P _c and P _{i to} P _n . It is provided correspondingly,
Under the control of the simulated resource management unit 4, the switching unit 6 can switch appropriately. Here, the processors P _{i to} P _n are processors in the multiprocessor system to be simulated, and P _c is a virtual processor (a processor that performs the operation of the main control unit 1) that controls the overall simulation. Equivalent).

The main control unit 1 outputs simulation execution requests of the processors P _{i to} P _n to the processor instruction simulation unit 2,
Simulating the resource management unit 4 processor P _c the memory 5a and register 5b respect, to P _i to P currently outputs a request to switch to correspond to those of running out of _n, also the communication simulating section 3 between the processors And outputs a simulation execution request for inter-processor communication.

The processor instruction simulating unit 2 periodically simulates the instructions to be executed by the simulation target processors P _{i to} P _n by a predetermined amount on a simulation execution workstation by time division. The inter-processor communication simulation unit 3 includes processors P _c and P _i
ＰP _n Simulates the execution of inter-processor communication in response to inter-processor communication requests. The simulation of the inter-processor communication is realized by making a request to the simulated resource management unit 4 to copy data between the memory 5a and the register 5b corresponding to the processor performing the inter-processor communication, as described later. .

The simulated resource management unit 4 includes processors P _c and P _i
To manage the memory 5a and the register 5b corresponding to _Pn ,
The switching unit 6 is controlled so that the access is switched to the memory 5a and the register 5b corresponding to the processor being simulated by the processor instruction simulating unit 2, and the communication execution request from the inter-processor communication simulating unit 3 is transmitted. And control of data copying between the memory 5a and the register 5b corresponding to the processor. As described above, in the simulator of the present embodiment, in order to execute the simulation for each of the plurality of processors P _{i to} P _n in a single process, the resources of each processor such as the memory and the register are determined by the number of processors to be simulated. And the switching unit 6 switches between them for use.

FIG. 2 conceptually explains the operation of the embodiment.
FIG. This operation is performed when a plurality of processors P_i~ P_n
Of the operation of the processor and the communication device P between processors_pSimulation of
To run in a single process.
Sa P_c, Processor P_i~ P _nAnd interprocessor communication
Simulated processor P_pEach operation of
It is executed sequentially at a rate.

That is, first, after the main control processor P _c is executed by a predetermined unit amount (here, one instruction),
Execute the processor _Pi by a unit amount. The circle in the figure indicates the processing of this unit amount. Similarly, it runs in a time-division processor P _j to P _n sequentially unit quantity by, and finally executes communication simulated processor P _p between processors if required. That is, as the information communication requests between processors occurs by executing the processor P _i to P _n, the inter-processor communication between processors P _j and P _m, as shown in FIG example by inter-processor communication simulated processor P _p Perform a simulation. Instructions communication simulated processor P _p between processors when there is no information communication request is not executed.

The transfer of information in the simulation of the inter-processor communication is performed simply by copying the memory data of each processor since the simulation is executed in a single process. Processing can be performed at a very high speed as compared with the simulation method. In other words, by performing the simulation of the inter-processor communication by such data copy processing, the simulation of the multiprocessor system can be executed by a single process.

When the simulation execution of the processors P _{i to} P _n and the processor P _p is completed, the process returns to the main control processor P _c again to execute the unit amount. Repeat this operation periodically, simulating each operation of the processor P _i to P _n, and performs simulation of the interprocessor communication among their processors P _i to P _n.

Further, in order to solve the above-mentioned problem (2), in this embodiment, the clock interrupt control is performed in the mode illustrated in FIG. That is, as shown in FIG. 3, the original clock interrupt is generated at a fixed period t as shown in the upper part of FIG.
Occurs in Each of the processors P _i P _j and P _k is executed in the order indicated by the arrow in the figure by repeating the processing of each processor in unit of time in a time-division manner in the above-described manner. Within the period t, each processor performs processing from the program with the higher execution level, sequentially shifts the processing to the program with the lower execution level, and shifts to the halt state once the processing of all the programs is completed.

In this case, when all the processors P _i , P _j , and P _k enter the halt state, the processor that is going to enter the halt state last (that is, the processor that is about to end the processing last) is clocked. Generate an interrupt. This is illustrated by
Second in FIG. 3, a third period t, the processor P _j is at the second cycle, the processor P _k is a third period respectively to generate a clock interrupt. As a result, an interrupt occurs at a cycle shorter than the original interrupt cycle t, and in the example shown in the figure, the time ΔT can be finally reduced.

If the processor P _i has not finished executing the program within the time t as in the first cycle t, a clock interrupt is generated when the time t elapses, and Shift to period t.

FIG. 4 is a flowchart showing the operation of the apparatus according to the embodiment. First, it is checked whether the processors P _c and P _{i to} P _n have completed the processing of the unit amount (step S1). As a result, if, for example, the processor P _{X and} subsequent processors have not finished the processing, whether the processing state of the program for the processor P _X is an execution state (one of the levels H, L, or B is being executed) or a halt state Check. In the case of the execution state, the unit amount (one instruction) is simulated (step S).
3). Next, the processing is repeated until the processor _Pn ends with the processor number incremented (step S
1 to S3).

As described above, when the processing of the unit amount is completed for all the processors P _{i to} P _n , it is checked whether or not there is an inter-processor communication request (step S4).
If there is an inter-processor communication request, data is copied from the memory and register corresponding to the communication request source processor to the memory and register corresponding to the communication destination processor (step S5).

Next, the clock interrupt condition is checked (step S6). This clock interruption condition is based on the fact that all of the processors P _{i to} P _n are in the halt state or that a certain time t has elapsed. If this condition is satisfied, a clock interrupt procedure is executed (step S7). As a result, all the processors P _{i to} P _n restart the processing of the program from the higher execution level H. Finally, it is checked whether or not the simulation test has been stopped by an external instruction or the like (Step S).
8) If it is a simulation stop, the process is terminated; otherwise, the process returns to step S1 and continues.

With the above arrangement, it is possible to easily realize the simulation of the program of the multiprocessor system at a high speed on a single workstation, and the ratio of the cross debugger can be greatly improved.

FIGS. 5 and 6 show another embodiment of the simulator of the present invention. These embodiments are for solving the above-mentioned problem (3), in which processing of a program part that is not desired to be executed in a simulation target program is skipped by rewriting an instruction in a main memory. is there. As described above, the method of rewriting the instruction in the main memory includes (a) rewriting the instruction of the subroutine in the main memory upon a subroutine call (call) instruction and skipping the subroutine, and (b) pulling up a backup program. There are two methods: rewriting the instruction of the relevant program part (including the subroutine) on the main memory upon the instruction and skipping the program part. FIG. 5 shows an embodiment corresponding to the former (a), and FIG. 6 shows an embodiment corresponding to the latter (b). Hereinafter, these examples will be described.

(A) Method for skipping a subroutine triggered by a subroutine call instruction In FIG. 5, reference numeral 20 denotes a program A to be simulated, 21 denotes a simulator program B for executing a simulation,
Reference numeral 3 denotes a subroutine skip address storage table provided in the simulator program B, and reference numeral 22 denotes a subroutine call instruction processing unit. This subroutine call instruction processing unit is provided as one function of the simulator program.

In this embodiment, the simulation target program A
Since the subroutine BBB originally executed in the simulator is unnecessary in the simulation, the simulator operates so as to skip this process. The processing procedure will be described below. Note that the sequence numbers to shown below correspond to the numbers in the figure.

In the simulation, the user does not want to execute a subroutine that is known to the user in advance, and since the storage address when the subroutine is pulled up to the main memory is defined in the original program A, the subroutine is not stored in the main memory. The address at is also known in advance. Under such circumstances, the user registers in advance in the subroutine skip address storage table 23 in the simulator program B the start address on the main memory of the subroutine to be skipped in the simulation target program A. In the illustrated example, the head addresses of the subroutines AAA, BBB, CCC,... Are registered.

When a subroutine call instruction is issued with the execution of the main program, the subroutine call instruction processing unit 22 detects the subroutine call instruction.

The subroutine call instruction processing section 22
Searches for a subroutine skip address storage table 23 immediately before control is passed from the main program to the subroutine when a subroutine call instruction is detected,
It is determined whether there is a head address of the subroutine corresponding to the subroutine call instruction. This determination can be made by searching whether the next address of the address immediately before jumping from the main program to the subroutine (that is, the head address of the jump destination subroutine) is in the subroutine skip address storage table 23.

If there is a corresponding head address in the subroutine skip address storage table 23, the subroutine call instruction processing unit 22 knows the storage location of the subroutine in the main memory based on the head address, and determines the start address of the subroutine. Return instruction (RET)
Rewrite to After performing this processing, the main program is executed. As a result, for example, when the head instruction of the subroutine BBB is rewritten to the return instruction, even if the simulated trajectory of the program A jumps to the subroutine BBB, there is a return instruction at the head address thereof. Control returns to the main program immediately without substantially executing subroutine BBB.

After performing the above-described rewriting processing, the item (subroutine) of the subroutine in which the instruction has been rewritten in the subroutine skip address storage table 23 is next.
The other items (for example, the n-th item) in the table 23 are overwritten on the BBB head address, and the number of items in the table 23 is set to (n-1). This is because after the return instruction is written at the head of the subroutine by the above process,
When the main program calls the subroutine again, it is not necessary to refer to the subroutine skip address storage table 23 and rewrite the return instruction.
The items of the rewritten subroutine are stored in the table 23
, The number of items is reduced, the reference time (search speed) of the table is reduced in the subsequent search processing, and the subroutine once rewritten by the return instruction is not rewritten again. This is for improving the processing speed.

Therefore, in the subsequent processing of the main program, if the same subroutine call instruction is generated and the subroutine is to be executed, a return instruction is written at the head address of the subroutine, so that the main program is immediately executed. Control returns.

In the above embodiment, the instruction at the head address of the subroutine is rewritten as a return instruction in order to skip a subroutine that is not desired to be executed. However, the present invention is not limited to this. If the subroutine is composed of numbers, all instructions of the subroutine may be rewritten as invalid instructions (for example, NO-OP instructions).

(B) Method of skipping a specific program (including a subroutine) triggered by a program pull-up instruction In FIG. 6, reference numeral 20 denotes a program A to be simulated, 21 denotes a simulator program B for executing a simulation,
5 is a processing skip address storage table provided in the simulator program B, and 24 is a program pull-up instruction processing unit. This program pull-up instruction processing unit 2
4 is provided as one function of the simulator program.

In this embodiment, the simulation target program A
Since the specific program (including subroutines) bbbb that is originally executed in the program is unnecessary in the simulation,
The simulator works so as to skip the processing of the specific program bbbb. The processing procedure will be described below. As described above, the following sequence numbers to correspond to the numbers in the figure.

In this embodiment as well, the specific program that the user does not want to execute in the simulation is known to the user in advance, and the address range on the main memory when the specific program is pulled up is also known in advance. Under such circumstances, the user stores the address range (for example, the start address and the end address) on the main memory of the specific program desired to be skipped in the simulation target program A in the skip address storage table 24 in the simulator program B. Register in advance. In the illustrated example, the address ranges of the specific programs aaaa, bbbb, cccc,... Are registered. The specific program may be a subroutine. In this case, the same processing skip address storage table 24 as the above-described subroutine skip address storage table 23 can be used.

When a program pull-up instruction is generated from the backup memory, the program pull-up instruction processing unit 24 detects this program pull-up instruction and performs the following processing.

The program pull-up instruction processing unit 24
After the program is pulled up to the main memory, a search is made as to whether or not the address range stored in the skip address storage table 23 is within the range of the pulled-up program within the range of the pulled-up program.

Processing Skip Address Storage Table 2
If the address range of the specific program in 5 is within the address range of the pull-up program, all instructions of the specific program are rewritten to invalid instructions. When the specific program is a subroutine, only the first instruction may be rewritten as a return instruction as described above. As the invalid instruction, for example, an instruction such as a “NO-OP” instruction can be used. Thus, when there is a specific program whose processing is to be skipped in the program pulled up by the program pull-up instruction, the content of the specific program is replaced with an invalid instruction.

As a result, even if a specific program to be skipped is included in the executed program when the raised program is executed, the specific program is skipped because the contents of the specific program are rewritten to invalid instructions when the program is pulled up. Is done.

After the above-described rewriting process is performed in the same manner as in the above-described embodiment, the rewritten item (address range of the program to be skipped) in the process skip address storage table 25 is next stored in another table in the table 25. Item (for example, the nth item) is overwritten, and the number of items is changed to (n
-1). Thus, as described above, the table reference time (search speed) in the subsequent processing is reduced, and the rewriting of the invalid instruction for the specific program once rewritten is eliminated, thereby improving the processing speed.

Further, the above processing is repeated for the remaining skip address range in the processing skip address storage table.

As described above, in this embodiment, when pulling up the program from the backup memory, the instruction contents of the specific program to be skipped are rewritten collectively. Since the programs can be sequentially executed, the processing can be speeded up.

As described above, according to the above-described method, it is possible to skip a desired program portion in the simulation execution without destroying (rewriting) the original data of the simulation target program stored in the backup memory. * The user can skip the processing of a specific program without being aware of the timing at which the instruction to be rewritten is raised. * Without stopping the program to be simulated for rewriting for skip processing, The program can be skipped. * The program portion to be skipped can be set arbitrarily and can be easily changed by reading from a file or the like.

Another embodiment of the simulator of the present invention is shown in FIGS. This embodiment is to solve the above-mentioned problem (4), and simulates a computer system employing an overlay method. In the following embodiment, a case will be described in which the program is stopped at a predetermined address of the program to be simulated (overlay program). However, the present embodiment can be diverted to, for example, start tracing from the predetermined address. It is.

In FIG. 7, reference numeral 27 denotes a backup memory as a secondary storage device for storing an overlay program having an overlay structure. The overlay program is composed of a plurality of program units (for example, program segments). Each program unit is composed of a predetermined number of words or less, and these program units are stored in the backup memory 27 at predetermined addresses. In FIG. 7, one program unit i is “2000”.
The state stored in the address “000 ₍₁₆₎ ” to “20007FF ₍₁₆₎ ” is exemplified.

Reference numeral 28 denotes a main memory (MM) which is a high-speed temporary storage device of the simulator. In the main memory 28, two overlay areas A and B for overlaying program units are secured. I have. In this example, the A side is from "2000 ₍₁₆₎ " to "27FF ₍₁₆₎ "
The area B is assigned addresses from "2800 ₍₁₆₎ " to "2FFF ₍₁₆₎ ".

The program of the computer system to be simulated employs an overlay method. A required program unit stored in the backup memory 27 is stored in the overlay area A or B of the main memory 28 as necessary. Loaded (raised) by one or the other,
The raised program unit on the main memory 28 is appropriately executed.

Numerals 31, 32 and 33 are storage areas prepared in the simulator. Overlay stop address area 31
Is a storage area for the operator to register in advance the address at which execution during the overlay program is to be stopped,
This address is registered as an address on the backup memory 27 (that is, the secondary storage device). FIG. 7 illustrates a state in which the address “2000100 ₍₁₆₎ ” on the backup memory 27 is registered as the address to be stopped. The overlay start address area 32 is a storage area in which the start address of the program unit, which has been transferred from the backup memory 27 to the main memory 28, is stored as an address on the backup memory 27. The stop address area 33 is a storage area for storing an address at which the overlay program registered in the overlay stop address area 31 is to be stopped from an address on the backup memory 27 to an address on the main memory 28. The storage addresses of these areas 31, 32, 33 are associated with one another. That is, the start address of the overlay start address area 32 and the stop address of the stop address area 33 are stored in association with each address registered in the overlay stop address area 31.

In addition, the simulator of this embodiment has an overlay stop address registration function 34 and an overlay recognition function 3
5. It has an overlay address conversion function 36. The overlay stop address registration function 34 is a function for registering an address to be stopped in the program in the overlay stop address area 31. The overlay recognition function 35 has an address registered in the overlay stop address area 31 in the raised program unit. The overlay address conversion function 36 writes the start address of the program unit into the overlay start address area 32 if it exists.
Is a function of converting an address (address on the backup memory 27) registered in the main memory 28 into an address on the main memory 28.

The operation of the embodiment will be described below. FIG.
Before the start of the practice test, as shown in
Enter the stop address "2000100 ₍₁₆₎ " on the backup memory 27 where you want to stop the simulation target program.
When specified, the overlay stop address registration function 35 registers this in the overlay stop address area 31 and stores the dummy address “AAAAAAAAA ₍₁₆₎ ” in the storage location of the stop address area 33 corresponding to the stop address “2000100 ₍₁₆₎ ”. Is set. This dummy address is chosen to be a value that never stops the program, such as a value greater than the maximum address of the main memory.

Next, as shown in FIG. 8, a simulation test is started, and an overlay pull-up instruction (a type of SIO instruction) is generated during execution of the program (see FIG. 8). In this overlay pull-up, the program unit i stored in the backup memory 27 is raised to the overlay area A of the main memory 28. Therefore, the overlay pull-up instruction includes a read address “200000 ₍₁₆₎ ” which is a start address of the read of the program unit i from the backup memory 27, and a read word number “8”.
00 ₍₁₆₎ ”and the write address“ 2
000 ₍₁₆₎ ".

The overlay recognizing function 35 detects the overlay pull-up instruction and reads its overlay address “2000”.
000 ₍₁₆₎ "is set in the overlay head address area 32 (see FIG. 7). Although not shown, the number of read words and the write address are also set and held in a predetermined area of the overlay head address area 32.

After the processing by the overlay recognition function 35,
The overlay address conversion function 36 determines that the number of words to be read from the read address is within the number of words to be read, that is, "200000 ₍₁₆₎ ".
Until address "20007FF _(16)" from the address determines whether stop is registered in the overlay stop address area 31 address "2000100 _(16)" exists.

If it exists (ie, in the case of the example shown), the stop address “200010” on the backup memory 27 registered in the overlay stop address area 31
0 ₍₁₆₎ ”to the address on the main memory 28 of the program unit which is raised based on the read address“ 200000 ₍₁₆₎ ”from the backup memory 27 and the write address“ 2000 ₍₁₆₎ ”to the main memory 28. Convert. That is, [(2000100−200000) + 2000 = 2100] ₍₁₆₎ is performed, and the obtained stop address “210
0 ₍₁₆₎ "is set as the stop address on the main memory 28 in place of the dummy address in the stop address area 33 (see FIG. 3).

The above processing is performed by storing the program unit i in the main memory 2
When the processing is completed, the simulator performs a simulation test of the program by sequentially reading and executing the instructions of the program unit i from the main memory 28. During execution of the simulation test, as shown in FIG. 9, the address stop function 37 monitors the execution address of the program unit i under simulation test, and uses the stop address set in the stop address area 33. A certain "2100
_{(16) When the} address is executed, the execution of the program unit i is stopped.

Thereafter, data required for debugging can be collected by executing processing specified in advance or each time by the operator, such as tracing a program and displaying memory contents.

FIG. 10 shows another embodiment of the present invention which is an improvement of the above-described embodiment shown in FIGS. In the simulator of the above-described embodiment, one program unit is pulled up to the main memory 28, and is started from the one program unit, and another program unit is pulled up to the main memory 28 instead of the one program unit. In such a case, a problem occurs as described below.

For example, the program unit i has been raised to the overlay area A side of the main memory 28 and the program unit k has been raised to the plane B. The overlay stop address area 31 has the address “200010” included in the program unit i.
0 ₍₁₆₎ ", with the stop address specified, it is requested to pull up another program unit j on the backup memory 27 from the program unit i, which is the same as the main unit currently loaded with the program unit i. Memory 2
8 is overlaid on the overlay area A side.
That is, this is a case where the program unit i is replaced with the program unit j on the main memory 28.

In this case, the raised program unit j is stored in the addresses "2000 ₍₁₆₎ " to "27" in the main memory 28.
FF ₍₁₆₎ "instead of the program unit i.
On the other hand, the address “2100 ₍₁₆₎ ” in the main memory 28 for stopping the program unit i at a desired address is set in the stop address area 33 when the program unit i is pulled up. If it is executed as it is after pulling up, the execution will be stopped at the address "2100 ₍₁₆₎ ". However, even though the stop at this address is valid for the program unit i, the operator is not planning for the program unit j.

Therefore, in the embodiment of FIG. 10, the following processing is performed. That is, when there is a pull-up of the program unit j from the program unit i pulled up to the main memory 28, the overlay recognition function 35 sets the write address of the program unit i to the main memory 28 (in this example, "2000").
₍₁₆₎ ”and the write address of the program unit j to the main memory 28 (also“ 2000 ₍₁₆₎ ”) coincide with the stop address“ 2100 ”for the program unit i stored in the stop address area 33. ₍₁₆₎ ”and a dummy address“ AAAAAAAAA ₍₁₆₎ ”is set. By doing so, it is possible to prevent the program from being stopped at an address not planned by the operator.

FIG. 11 shows another embodiment of the present invention in which the simulator of the embodiment shown in FIGS. 7 to 10 is further improved. In this embodiment, not only the stop address of the simulation target program is registered in advance before the simulation test but also at any time after the program unit is pulled up.

In other words, depending on the specifications of the simulator, a new stop address may be specified when execution is stopped at the stop address registered in advance for the raised program unit. In this method, the stop address is registered at the time of pulling up the program unit, so that such a case cannot be dealt with.

That is, the overlay address conversion function 3
6 is performed in response to a program unit pull-up instruction, and if a program unit including a stop address to be newly input / designated has already been pulled up to the main memory 28, the new input is executed. -Execution of the program cannot be stopped at the specified stop address. This problem can be solved by performing the processing shown in FIG.

That is, the main memory 28 of the program unit i
After the pull-up to the stop address "20
002000 ₍₁₆₎ ”is newly input and designated. In this case, the overlay stop address registration function 34
Sets this additionally in the overlay stop address area 31 and reads the read address "200000 ₍₁₆₎ " from the overlay head address area 32 ₍ see FIG. 3).

Next, the stop address “2” additionally set in the overlay stop address area 31 from the read address to the number of words to be read, that is, from the address “200000 ₍₁₆₎ ” to the address “20007FF ₍₁₆₎ ”.
0002000 ₍₁₆₎ ”is present, and the stop address“ 2 ”is added to the overlay start address area 31.
0002000 ₍₁₆₎ read address "2000000 as the corresponding stored data" ₍₁₆₎ "and additionally set (see in the figure). Further, it is determined whether the program unit i is currently being raised to the overlay area. This can be determined based on whether or not the corresponding stop address in the stop address area 33 is a dummy address (see 'in the figure).

The additionally set stop address "2000020"
00 ₍₁₆₎ ] is the program unit i currently overlaid
If the address exists in the address range (address range on the backup memory 27), the overlay address conversion function 36 reads the read address “200000 _{(16 )} ” corresponding to the stop address “2000200 ₍₁₆₎ ” from the overlay head address area 32. ₎ ] And the stop address “2000200” from the overlay stop address area 31.
₍₁₆₎ "(see FIG. 10), and based on these and the write address" 2000 ₍₁₆₎ "which is the head address in the main memory 28 where the program unit i is written.
The stop address "2000200 ₍₁₆₎ " is converted into an address on the main memory 28. That is, [(2000200−200000) + 2000 = 2200] _{(16) is} calculated, and the obtained result “2200 ₍₁₆₎ ” is additionally set in the stop address area 33 as a stop address.
(Refer to the figure).

In this way, even after temporarily stopping at the address "2100 ₍₁₆₎ " on the main memory 28 and collecting predetermined data, execution is resumed by additionally specifying a new stop address. Then, the address stop function 37 causes the additionally specified stop address “2000200”
₍₁₆₎ "in the execution of the program in the main memory 28 on the address" 2200 ₍₁₆₎ "is stopped. Therefore, the program stop position can be flexibly set according to the request of the operator, and the efficiency of debugging can be improved.

As described above, according to the above-described embodiments of FIGS. 7 to 11, even when simulating a computer system employing the overlay method for storage management, the operator can stop the program to be simulated or start tracing. By simply specifying the address of the point of interest by the address on the secondary storage device, it is possible to stop the program pulled up on the main memory at the address of the point of interest.

FIG. 12 shows a simulator according to still another embodiment of the present invention. This simulator solves the above-mentioned problem (5) and is for performing a simulation test of a program for driving an input / output device. In this embodiment, the memory space of the input / output device is simulated by the storage device on the simulator side, but it is assumed that a magneto-optical disk device having a huge memory capacity is used as the actual input / output device.

In FIG. 12, reference numeral 40 denotes an instruction execution unit for sequentially executing a simulation target program; 42, an input / output device simulation unit for simulating an input / output device; The memory space of the storage device for simulating the memory space of the device is provided inside.

The memory space of the input / output device to be simulated is virtually divided into a plurality of blocks. The input / output device memory space shown in FIG. 12 shows a state where the memory space is virtually divided. The block size, which is a unit of division of the memory space, is divided by a logical size, and is set to be n times the minimum size at which the input / output device to be simulated accesses the memory. Here, n is a positive integer.

In this embodiment, a magneto-optical disk device is used as an input / output device. The access unit of this magneto-optical disk device is 1024 bytes, and the address of the magneto-optical disk is also assigned every 1024 bytes. Uses LBA (logical block address). That is, 1 LBA = 1024 bytes. And
In this embodiment, the size of a block is n = 16, one block is configured in units of 16 LBA (= 16, 384 bytes), and the entire memory space of the input / output device is divided by this block size. Shall be numbered.

Reference numeral 41 denotes an address / block converter.
The address / block conversion unit 41 includes an instruction execution unit 40
When the target program to be executed in the process accesses the memory space of the input / output device, it determines which block of the input / output device memory space the accessed address belongs to,
It has a function of converting the address into a serial number of the block to which the address belongs. For example, if the accessed address is 10
In the case of 0 LBA, the block size is 16 L as described above.
Since the block is a BA, the block to which the address “100 LBA” belongs can be calculated by the following equation. Block number = 100 LBA ÷ 16 LBA = 6.25 Here, singular numbers below the decimal point are discarded and determined to belong to the sixth block.

When notified of the block number from the address / block converter 41, the input / output device simulator 42 has a function of securing a storage area corresponding to the block of the block number in an internal storage device. If a storage area with the same block number has already been allocated on the storage device, the storage area is not duplicated. Further, the address accessed by the target program is converted into an address in the block to which the address belongs (an address on the internal storage device) so that the target program can access the pseudo memory space created on the storage device. ing.

The operation of this embodiment will be described below with reference to FIG. A simulation target program for executing access (writing and reading) to the magneto-optical disk is run by the instruction execution unit 40 of the simulator.

When a write command is issued to the magneto-optical disk in the same program, the write destination address of the magneto-optical disk is passed to the address / block converter 41 of the simulator as key information of the write command. Here, as described above, the write address is 100
LBA.

In the address / block converter 42,
The above-described operation is performed to determine which block number the address “100LBA” belongs to,
The block number to which the address belongs is obtained, and the block number is notified to the input / output device pseudo unit 42. This block number is the sixth as described above.

The input / output device pseudo unit 42 secures a storage area having a size corresponding to the block of the notified block number from the beginning in the memory space. At this time, the whole memory space of the storage device of the simulator is in use.
It is only for one block (= 16, 384 bytes).

The input / output pseudo device converts a write address (address on the input / output device) generated by the target program into a write address on the storage device, and enables the target program to access the storage area of the secured block. I do. Therefore, since the result of the write instruction is stored in the storage device of the simulator, the normality of the write instruction can be determined from the memory content in later debugging or the like.

Similarly, when, for example, the target program next issues a write command to the address “40 LBA” of the magneto-optical disk, the storage area corresponding to the third block is stored in the simulator as shown in FIG. Is secured on a storage device, and hereinafter, when a write instruction is issued,
The storage area of the block to which the write address belongs is sequentially secured on the storage device.

As a more specific example, a case will be described in which the above-described embodiment apparatus is applied to execution processing of a drive program of a magneto-optical disk drive for formatting a magneto-optical disk cartridge (OC). FIG. 16 shows an example of the format of a magneto-optical disk cartridge. It is assumed that the magneto-optical disk cartridge is formatted into a management area, an area 1, an area 2, and an area 3. The capacity of this magneto-optical disk cartridge is xLBA for the management area, yLBA for area 1, and zLB for area 2.
A, if area 3 is xxLBA, (x + y + z + x
x) LBA, here, 200 blocks.

When the drive program of the magneto-optical disk drive is run by the simulator and a command for formatting the magneto-optical disk cartridge is executed, the drive program first writes information such as a volume name in the management area, and Then, for each of the areas 1, 2, and 3, a write process is performed on the 1 LBA of the start portion and the 1 LBA of the end portion, and commands for formatting the magneto-optical disk cartridge are sequentially issued.

With this processing, as shown in FIG. 17, the address / block converter 41 of the simulator
Calculates a block serial number from an address (unit LBA) which is a key of each write position, and the input / output device pseudo unit 42 uses the block serial number to allocate a storage area in block units from the beginning of the memory space of the storage device of the simulator. Secure. As can be seen from FIG. 17, the actual capacity of the magneto-optical disk cartridge is (x + y + z + xx) × 1024 by.
Although te = 200 blocks, writing is actually performed in the pseudo memory space of the simulator apparatus for seven blocks, and only the storage area corresponding to this block needs to be secured in the pseudo memory space. This saves 193 blocks compared to securing the entire capacity of the cartridge.

According to the above-mentioned method, the memory space of the designated size unit required by the simulation target input / output device is stored on the simulator side only in the logical size unit and only when it is necessary. On the device,
Since a memory space that is not actually used by the simulation target input / output device is not secured in the storage device of the simulator, the environment where “the total memory space of the simulation target input / output device> the memory space size of the storage device of the simulator” is satisfied. In an environment where the condition of the memory space size actually used by the simulation target input / output device <the memory space size of the storage device of the simulator is satisfied, the simulation test of the target program can be performed by the simulator. .

FIG. 15 illustrates the manner in which the instruction execution unit 40 of the embodiment device accesses the input / output device pseudo memory space. FIG. 15A shows the case of the above-described write command, and only the storage area of the block number to which the write address belongs is secured in the input / output device pseudo memory space.

In FIG. 15B, although the simulation target program run by the simulator issues a read command to the input / output device, the storage area of the block number to which the read address belongs still has the input / output device pseudo memory space. Shows a case where it has not been secured. In this case, the fact that the storage area of the block number is not secured means that the block has not been written yet, and the read data should be "0". The output device simulating unit 42 returns to the instruction executing unit 40 data which guarantees that the read data is “0” or “no write data”.

(C) in FIG. 15 shows a method of managing the use / unused of the input / output device pseudo memory space on the simulator side by direct access from the instruction execution unit 40 without preparing a management table. . That is, the instruction execution unit 40 accesses a predetermined address in the pseudo memory space, and if the access is possible, it is understood that the storage area of the block number to which the address belongs is reserved (that is, used). On the other hand, if the access fails, it is known that the corresponding storage area is not secured (that is, the storage area is not used). Therefore, by sequentially accessing the addresses corresponding to the respective block numbers, the use / unuse of the pseudo memory space can be determined. Can be managed without management tables.

As described above, according to this embodiment, it is conventionally difficult to secure a simulated memory amount in a simulator for simulating a program for controlling access to an input / output device having a huge memory. However, in this method, the target program can be tested even when the storage device in the simulator cannot secure the same size as the memory space of the I / O device. Simultaneous simulation of input / output devices is also possible.The simulator can be used without capital investment such as additional memory.Since the memory space inside the simulator can be managed in blocks divided into logical sizes, Obtain effects such as the ability to suppress simulator delays caused by searching for access points Can be.

FIG. 18 shows a simulator according to still another embodiment of the present invention. The apparatus of this embodiment solves the above-mentioned problem (6), and is capable of checking for inconsistency of program logic in a program to be simulated.

In FIG. 18, reference numeral 45 denotes a simulation system, which includes a simulation execution unit 46 for executing a program 50 to be tested and an execution monitoring unit 47 for monitoring the execution of the program 50 being executed. A management table 48 is provided for holding program logic check mechanism data used in the chuck mechanism for checking for logic inconsistency.

In this embodiment, the simulation system 45 performs a simulation test of the test target program 50. The simulation system 45 performs the simulated execution of the test target program 50 by the execution unit 46, monitors the execution state by the execution monitoring unit 47 one instruction at a time, and collects the execution history X of the program 50. The execution history X is, for example, a locus indicated by an arrow in the test target program 50 in FIG. 18. The execution history X is obtained by jumping from the main program A to the subroutines B and C and performing the processing. This shows a state in which the program has returned to the original main program A.

The execution monitoring unit 47 checks the normality of the logic of the program by referring to each item data of the program logic check mechanism data 51 in the management table 48 based on the obtained execution history X. This check can be performed each time the program 50 is advanced by one instruction. Test items include execution level inconsistency, mask setting omission, data store area error, input parameter not set, output parameter not set, key information unmatch,
No corresponding program is called.

Obtained Program Logic Check Result 49
Is output by an output device such as a CRT display device and a printer. Check results include O for each item as shown.
K and NG types are indicated. The tester confirms the output program logic check result 49, corrects an error in the test target program 50, and increases the test accuracy while performing the simulation test again.

A check method in the case of execution level inconsistency as an example of the above program logic check will be described below. The execution level contradiction is to check whether or not an interrupt mask processing instruction is incorporated in the program when a conflict occurs between program execution levels in which programs having two or more execution levels are simultaneously executed. Yes, if it is embedded, it is normal, otherwise it is a program logic inconsistency.

FIG. 19 shows a configuration of a simulator for checking the execution level contradiction. In this example, it is assumed that the program under test (X) includes programs A, B, and C, of which programs A and C operate at two high / low execution levels, respectively. In the figure, reference numeral 52 denotes a program-under-test execution level monitoring unit, which is a high-level program entry collection unit 53 for detecting that a high-level program has been entered, and a low-level program for detecting that a low-level program has been entered. Entry collection unit 5
4. It comprises a program execution conflict collation unit 55. Reference numeral 56 denotes a collation result output unit 56 that outputs a collation result from the competition collation unit 55 by a printer or the like.

The operation of this embodiment will be described below.
A simulation test of the program under test (X) is started by the simulator. The simulator performs a simulation test of the program under test (X) in the simulation execution unit 46, and as a result, the execution history X of the program under test is obtained. The high-level program entry collection unit 53 and the low-level program entry collection unit 54 of the execution level monitoring unit 52 determine the running programs A, B,
The start entry (start address of the start program) of C, the high-level execution program entry information H, and the low-level execution program entry information L are collected.

The program execution level conflict collation unit 55 checks whether there is a program logical contradiction according to the procedure shown in FIG. That is, it is determined whether the instruction being executed is a jump-type instruction from the program under test execution history X which is input information (step S1). If the instruction is a jump-type instruction, it can be determined that a new program has been started, such as the start of a subroutine, and the started program is checked for program logic inconsistency. Therefore, if the instruction is not a jump instruction, the check is not performed again.
K ”(step S5).

If it is determined that the instruction is a jump-type instruction, based on the high-level execution program entry information H and the low-level execution program entry information L collected by each of the level execution program entry collection units 53 and 54, the program is determined to be both. It is determined whether the program runs at the level (step S2). If the vehicle does not run on both levels, no conflict occurs between the program execution levels, so that the logical inconsistency of the program does not matter, so that the collation result is "OK" (step S5).

If the program runs at both levels, it is determined whether or not an interrupt mask process Y that inhibits (masks) an interrupt of a program executed at a higher level is incorporated in the program. The determination is made by pre-reading the machine instruction word of the program (step S3). If there is an interrupt mask process Y, there is no program logic inconsistency, so the collation result is set to "OK" (step S5). If there is no interrupt mask processing Y, it means that there is program logic contradiction, so the collation result is “NG”.

The collation result of the conflict collation unit is sent to the collation result output unit 56 and output as the program execution level collation result (r). By confirming the program execution level comparison result (r), the tester can detect an error (program logic contradiction) in the program under test before the system becomes abnormal due to data destruction.

According to this embodiment, the execution level of a program is collected in a simulator for simulating the program, and a mechanism for monitoring a conflict between different levels based on the collected result and the program processing content is added. When a simulation test is performed, a system abnormality due to data inconsistency caused by competition between different execution levels can be detected in advance. As a result, the time required to determine the cause of a system error in the past can be reduced, and even inexperienced testers can easily detect program errors. It is possible to stabilize the program (system) at an early stage and to improve its reliability.

FIGS. 21 to 24 show a simulator as still another embodiment of the present invention. This embodiment is intended to solve the above problem (7). In FIG. 21, reference numeral 60 denotes a simulator command control function in the simulator program, reference numeral 61 denotes a system under test pseudo function having no debug function, and reference numeral 62 denotes a system under test pseudo function having a debug function.

As shown in the flowchart of FIG. 24, the system under test pseudo function 61 is a functional part having no debug function for execution of each instruction in simulating execution of the system under test (program under test). When the debug function is not registered, the machine instruction of the system under test is repeatedly executed. On the other hand, the system under test pseudo function 62 is a function part having a debug function for each instruction execution in simulating execution of the system under test, and repeats the machine instruction of the system under test during "debug function registration" described later. Execute.

The simulator command control function is provided with a function of determining the presence or absence of a debugging function. This debug function presence / absence judgment is based on the type of the program under test when the debug function is not required and the debug function is not registered.
And This registration / non-registration is performed when the system under test pseudo function is stopped, and is performed, for example, by setting a corresponding bit in an AP flag (application flag).

As described above, in the apparatus of this embodiment, the control route of the system under test simulated portion is duplicated, and only the control route including various debug functions (the system under test simulated function 62 side) and the function under test simulated portion are duplicated. And the control route (on the system under test 61). That is, in the simulator command control function 60 portion that does not affect the response of the system under test (ie, the portion in which the determination process for each machine instruction is not performed), the device without the debug function according to the type of the program under test. By branching to the test system pseudo route (61) and the system under test pseudo route (62) having a debug function, only the system under test is performed for the program under test that does not require the debug function. It is possible not to reduce the processing capability of the simulator itself, while it is possible to add execution of various debugging functions to a program under test that requires a debugging function. The selection of the control route is performed according to the set value of the AP flag when the state shifts from the “simulator command execution state” to the “simulated state of the system under test”.

The operation of this embodiment will be described below with reference to FIGS. 22, 23 and 24. Note that the sequence numbers shown below correspond to the numbers in the figure.

(A) First, in the case where various debug functions are not registered, [initial state] → [simulation execution] →
The operation of transition to [simulation stop] will be described. The operation from the initial state (simulation stop state) to the execution of the simulation is as follows.

The simulator command control function 60 analyzes whether the debug function is registered in the AP flag 64. In this case, the debug function is not registered in the AP flag 64.

When the simulator command control function 60 detects “debug function not registered”, the simulator command control function 60 activates the system under test pseudo function 61 without the debug function. In the system under test pseudo function 61, as shown in FIG. 24, “determination of presence or absence of simulation stop”, “system test under test”, and “execution of machine instruction” are repeated for each machine instruction of the program under test. Is done and the debug function is not implemented.

To make a transition from the [simulation execution] state to the [simulation stop] state, the system under test 61 is stopped by a stop cause (for example, pressing a stop button, address stop, etc.), and simulator command control is performed. Function 60 is activated again.

(B) Next, in the case where various debug functions are registered, the transition is performed from [initial state] → [registration] → [simulation execution] → [simulation stop] → [deregistration] → [simulation execution] The operation to be performed will be described. The operations from the initial state (simulation stop state) to the registration and the execution of the simulation are as follows.

The simulator command control function 60 activates the debug function registration / cancellation function activation 63.

The debug function registration / release function 63 registers the debug function i. As a result, the debug function i is set and registered in the AP flag 64. Thus, AP
By performing writing to the flag 64 only with the simulator command control function 60 part, and by using the AP flag to manage the presence / absence of registration of the debug function type with a bit, the root of the system under test pseudo function part can be separated. Becomes

The simulator command control function 60 analyzes whether the debug function is registered in the AP flag 64. In this case, the AP flag 64 includes the debug function i
Is registered.

Upon detecting “debug function registration”, the simulator command control function 60 activates the system under test pseudo function 62 having the debug function.

As shown in FIG. 24, the system under test pseudo function 62 is registered with an AP flag together with “judgment of presence / absence of simulation stop”, “system test under test”, and “execution of machine instruction”. The "debugging function i" is repeatedly performed for each machine instruction of the program under test.

To transition from the [simulation execution] state to the [simulation stop] state, the system under test 62 is stopped by a stop cause (for example, pressing a stop button, address stop, etc.), and simulator command control is performed. Function 60 is activated again.

[Release] of the debug function from [Simulator stop] is performed in the following procedure. The debug command registration / cancellation function 63 is activated from the simulator command control function 60.

The operator issues a command to cancel the debug function by the debug function registration / cancel function 63, and A
The debug function i of the P flag 64 is released.

The simulator command control function 60 analyzes whether the debug function of the AP flag is registered.

(10) In this case, since the debug function is “unregistered” in the AP flag 64, the system under test pseudo function 61 without the debug function is started as the next step.

According to this embodiment: * By branching the system under test pseudo route in the simulator command control portion that does not affect the response of the system under test pseudo, without reducing the processing capability of the simulator itself, * It is possible to reduce the number of processing steps (judgment steps) per unit machine instruction in the system under test, thereby increasing the speed of simulation.

[0191]

As described above, according to the present invention,
The above-mentioned problems (1) to (7) can be solved respectively.

[Brief description of the drawings]

FIG. 1 is a diagram showing an embodiment of the present invention.

FIG. 2 is an explanatory diagram of the operation of the embodiment apparatus of FIG. 1;

FIG. 3 is an explanatory diagram of the operation of the embodiment apparatus of FIG. 1;

FIG. 4 is an operation explanatory diagram (processing flow) of the embodiment apparatus of FIG. 1;
It is.

FIG. 5 is a diagram showing another embodiment of the present invention.

FIG. 6 is a diagram showing still another embodiment of the present invention.

FIG. 7 is a view showing still another embodiment of the present invention.

FIG. 8 is an explanatory diagram of the operation of the embodiment apparatus of FIG. 7;

FIG. 9 is an explanatory diagram of the operation of the embodiment apparatus of FIG. 7;

FIG. 10 is a diagram showing still another embodiment of the present invention.

FIG. 11 is a view showing still another embodiment of the present invention.

FIG. 12 is a view showing still another embodiment of the present invention.

FIG. 13 is an operation explanatory diagram of the embodiment apparatus of FIG. 12;

FIG. 14 is an explanatory diagram illustrating the operation of the embodiment apparatus of FIG. 12;

FIG. 15 is a diagram illustrating the operation of the embodiment apparatus of FIG. 12;

FIG. 16 is a diagram illustrating an example of a format of a magneto-optical disk cartridge.

FIG. 17 is a diagram illustrating an operation of formatting an optical disk cartridge according to the embodiment of FIG. 12;

FIG. 18 is a view showing still another embodiment of the present invention.

FIG. 19 is a view showing still another embodiment of the present invention.

20 is a flowchart showing an operation procedure of a conflict collation unit in the apparatus of the embodiment in FIG. 19;

FIG. 21 is a view showing still another embodiment of the present invention.

FIG. 22 is an explanatory diagram of the operation of the embodiment apparatus of FIG. 21;

FIG. 23 is an explanatory diagram of the operation of the embodiment apparatus of FIG. 21;

FIG. 24 is an explanatory diagram (process flow) of the operation of the embodiment apparatus of FIG. 21;

FIG. 25 is a conceptual diagram of a conventional system.

FIG. 26 is a diagram showing a conventional method.

FIG. 27 is another conceptual diagram of the conventional system.

FIG. 28 is an explanatory diagram of an overlay processing method.

FIG. 29 is a diagram showing a conventional method.

FIG. 30 is an explanatory diagram of contention between program execution levels.

FIG. 31 is a diagram showing a conventional processing method.

FIG. 32 is a diagram showing a conventional processing method (processing flow).

[Explanation of symbols]

 REFERENCE SIGNS LIST 1 simulation control unit 2 processor instruction simulation unit 3 interprocessor communication simulation unit 4 simulation resource management unit 5 storage unit 5a memory 5b register 6 switching unit 20 program under test 21 simulator program 22 subroutine call instruction processing unit 24 program pull-up instruction processing unit 27 Backup memory 28 Main memory 31 Overlay stop address area 32 Overlay start address area 33 Stop address area 34 Overlay stop address registration function 35 Overlay recognition function 36 Overlay address conversion function 37 Address stop function 40 Instruction execution unit 41 Address / block conversion unit 42 Input Output device simulation unit 46 Simulation execution unit 47 Program under test execution monitoring unit 48 Management table 49 Program logic check result 50 Program under test 52 Test program execution level monitoring unit 53 High-level program entry collection unit 54 Low-level program entry collection unit 55 Program execution level conflict comparison unit 56 Matching result output unit 60 Simulator command control function 61 Simulated system under test without debug function 62 Debug function Tested system pseudo function with test 63 Command registration / cancellation function 64 Application flag

──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Masami Suzuki 1015 Ueodanaka, Nakahara-ku, Kawasaki-shi, Kanagawa Prefecture Inside Fujitsu Limited (72) Inventor Kaneko ▲ Tak ▼ 3-9-1, Shin-Yokohama, Kohoku-ku, Yokohama-shi, Kanagawa Fujitsu Communication Systems Co., Ltd. (72) Inventor Hiroko Kitayama 3-9-1-18 Shin-Yokohama, Kohoku-ku, Yokohama, Kanagawa Prefecture Fujitsu Communication Systems Co., Ltd. (72) Inventor Kazumasa Takeda Nakahara-ku, Kawasaki City, Kanagawa Prefecture 1015 Kamiodanaka Inside Fujitsu Limited (72) Inventor Kiyoshi Ogawa 3-9-1-18 Shin-Yokohama, Kohoku-ku, Yokohama, Kanagawa Prefecture Inside Fujitsu Communication Systems Limited (72) Inventor Yumi Kawabe Kamihara-ku, Kawasaki City, Kanagawa Prefecture 1015 Odanaka Inside Fujitsu Limited (7 2) Inventor Sakae Asaoka 1015 Uedanaka, Nakahara-ku, Kawasaki City, Kanagawa Prefecture, Fujitsu Limited (72) Inventor Tamotsu Inoue 1015, Ueodanaka, Nakahara-ku, Kawasaki City, Kanagawa Prefecture, Fujitsu Limited (56) References JP2 -294864 (JP, A) JP-A-3-150641 (JP, A) JP-A-3-255565 (JP, A) JP-A-4-35690 (JP, A) IEICE Technical Report Vol. 95, 267 1995, pp. 85-90 Tsutomu Ikejiri, et al. "Regarding Switch Development Methods by Simulation" The Procedures of the 1988 Summer Computer Simulation Conference July 1988 352-357 CHANG, C.E. K. "UICPBX: A distributed simulator of switching systems" CHANG, C .; K. "UICPB X: A distributed simulator of switching systems" (58) Fields investigated (Int.Cl. ⁷ , DB name) G06F 15/16 620 G06F 9/455 G06F 11/28 340 INSPEC (DIALOG (JALOG) JIC file) JOIS) WPI (DIALOG)

Claims (15)

(57) [Claims] 1. A simulator for simulating the operation of a multiprocessor system, comprising: a processor instruction simulating means for sequentially executing a predetermined amount of instructions of each processor of the simulated multiprocessor system in a time-division manner; Inter-processor communication simulation means for simulating the operation of inter-processor communication of the processor system; and simulated resource management means for allocating resources corresponding to the respective processors of the multi-processor system and managing switching of access to the respective resources of the respective processors. And sequentially executing the instruction of each processor by the processor instruction simulating means and executing the instruction of the inter-processor communication operation by the inter-processor communication simulating means, sequentially by the simulated resource managing means to the processor currently executing the simulation. Control to perform periodically while assigning And control means, constructed as the execution of the above means is carried out by a single process simulator. 2. The simulator according to claim 1, wherein said inter-processor communication simulation means is configured to realize inter-processor communication between processors by copying data between memory resources allocated to said processors. 3. The system according to claim 1, wherein said main control means is configured to generate an interrupt and restart the simulation of each processor when all the processors of the simulated multiprocessor system are all in a halt state. 2. The simulator according to 2. 4. A first address storage table in which address information of a subroutine not desired to be executed in a simulation target program on a main memory is stored in advance, and in response to a subroutine call instruction in the main program,
Before shifting to the execution of the subroutine, the first address storage table is referred to. If there is a subroutine corresponding to the subroutine call instruction, the contents of the subroutine in the main memory are read based on the address information of the subroutine. A simulator comprising subroutine call instruction processing means for returning control to the main program after rewriting the contents to not execute the subroutine. 5. A second address storage table for storing in advance the address information on a main memory of a specific program which is not desired to be executed in a simulation target program, and responding to a program pull-up instruction from a secondary storage device to the main memory. Before the execution of the program raised by the instruction, the second address storage table is referred to, and if the specific program is within the range of the program raised by the program pull-up instruction, the address of the specific program is determined. A program pull-up instruction processing means for rewriting the content of the specific program on the main memory to the content that does not execute the specific program based on the information. 6. The simulator according to claim 4, wherein, when a part of the program not desired to be executed is rewritten once in the main memory, the corresponding item in the address storage table is deleted. 7. A simulator for simulating an overlay program having an overlay structure, a secondary storage device for storing a plurality of program units constituting the overlay program, and a main memory for overlaying program units of the overlay program. An attention address registering means for registering an attention point in the overlay program by an address on the secondary storage device; and a storage address on the secondary storage device of a program unit which has been retrieved from the secondary storage device to the main storage. Address information storage means for storing information; and an address on the secondary storage device of the noted address registration means based on the storage address information of the address information storage means and the address information on the main memory for loading the program unit. Address translation means for translating to an address on storage; Processing address storage means for storing a conversion result of the conversion means as an address of a processing point of the overlay program on the main storage, wherein an execution address of the overlay program transferred to the main storage is stored in the processing address storage means. A simulator configured to perform predetermined processing when the address of the processed processing point is reached. 8. A processing point of the processing address storage means provided for one program unit when another program unit is overlaid on an overlay area of a main memory storing one program unit. The simulator according to claim 7, further comprising means for invalidating the address. 9. The system according to claim 1, further comprising a target address adding means for adding a target point address of the overlay program to the target address registering means later, wherein the target address of the overlay program is added by the target address adding means. 9. The simulator according to claim 7, wherein said address conversion means converts said address into an address on main memory and stores it in said processing address storage means. 10. A simulator for simulating a program for driving an input / output device, comprising: a storage device for simulating a memory space of the input / output device; an instruction execution means for executing the program; Address / block conversion means for virtually dividing the memory space of the device into a plurality of blocks and determining to which block the write address belongs when the program makes a write access to the memory space of the input / output device And a storage area securing means for securing a storage area corresponding to the block of the block number obtained by the address / block conversion means on the storage device, wherein the storage area is secured using the storage area secured on the storage device. A simulator configured to perform a simulation test of a program while simulating an output device. 11. When a memory area of a block corresponding to the read address is not secured in the storage device when the memory space of the input / output device is read and accessed by the target program, 11. The simulator according to claim 10, further comprising a return means for returning data without write data. 12. The storage device according to claim 12, wherein
12. The simulator according to claim 10, further comprising means for managing use / non-use of a storage area corresponding to each block number in the storage device by accessing using an address belonging to each block number. 13. A simulator for simulating a program, comprising: execution monitoring means for monitoring execution of the program and collecting execution history information; and normality of program logic using the execution history information of the execution monitoring means. A simulator comprising: a program logic check unit for checking the program logic; and an output unit for outputting a check result of the program logic check unit. 14. The program logic checking means collects execution level information of the program being simulated, an execution level collection means, and a program start detected based on execution history information of the execution monitoring means. A determination is made as to whether or not the started program is a program causing a conflict between program execution levels based on information collected by the execution level collecting means. If the started program is a program causing a conflict between program execution levels, interrupt mask processing is performed on the program. 14. The simulator according to claim 13, further comprising: conflict checking means for checking whether or not there is any. 15. A simulator for simulating a program, comprising: a first system-under-test simulated function means for simulating each instruction of the program without performing a debug function; and a debug function for executing each instruction of the program. A second system under test simulated function means for simulating execution while executing, a debug function registration means for registering whether or not to execute a debug function for each debug function; and A simulator command control function means for controlling whether the program is simulated by the first system under test simulated function means or by the second system under test simulated function means.