JPS63167940A - Multi-programming directional cpu - Google Patents

Abstract

PURPOSE:To realize a history trace of a system call instruction in a real time by providing a means for informing a fact that information is outputted onto an external data bus at the time of executing the system call instruction, to the outside of a CPU. CONSTITUTION:A CPU being an object is a multi-programming CPU 106, and realizes the execution of a system call in a program as an exclusive instruction by a microprogram of the CPU. A debug device (in a dotted line) has a host CPU 101, a host memory 102, and a display device 105, and provided with a trace memory address generating part 103 for generating an address to a trace memory 104, in order to store a data on a date bus in the trace memory 104 by synchronizing with a latch clock 109 outputted from the CPU 106. In such a way, the debug device can trace only information of a system call instruction by a timing of generation of the latch clock 109.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a multiprogramming-oriented CPU having a debugging function for a multiprogramming system in which a plurality of programs run in parallel while being synchronized.

[Conventional technology]

A conventional debugging function for sequential processing programs will be explained with reference to FIG. 6, which shows an example of a conventional CPU and its debugging device. As shown in FIG. 6, the conventional debugging device for sequential processing programs uses a CPU (hereinafter referred to as host CPU10) for managing the depacking function.
It is equipped with a CPU (hereinafter referred to as target CPU), memory, peripheral circuits, etc.
The depacking function is realized while monitoring the operation of the device (referred to as 601). Furthermore, conventional debugging devices only implement versatile functions that do not exist in the application program on the target CPU 601 side, such as memory manipulation, break functions, and tracing of program instructions.

This example explains the operation of the function of tracing an application program on the target CPU 601 side. This device is broadly divided into the target CPU 601, a memory section, and a depacking device section, and the debugging device section has various debugging devices. Host C to realize the function
PUl0I, the host program memory 102 in which the host program resides, and the current address at the same time as receiving a read signal (hereinafter referred to as RD signal 604) or a write signal (hereinafter referred to as WR signal 605) generated from the target CPU 601. Trace memory 10 that stores addresses on the bus and data on the data bus
4, and an address generation unit 10 for the trace memory 104.
3, and a display device 105 for displaying trace results and the like.

Next, we will explain the trace function of this device step by step. In this system, the timing at which trace data is stored in the trace memory 104 is when the target CPU 601 performs bus access and the RD signal 604 or WR signal 605 is output.
The trace memory address generation unit 103 receives these strobe signals and writes the trace memory 1 at this timing.
An address is generated at 04. 60 multiplexers at the same time
3 to select either the address data stored in the address latch 602 or the data on the data bus. Through the above processing, the timing at which the target CPU 601 accesses the bus is captured and address information and data information are stored in the trace memory 104. The trace memory address generation unit 103 generates a trace memory 104.
When overflow occurs, a trace end signal 110 is sent to the post CPU 10I, and tracing is stopped until a trace start signal 111 is sent from the host CPU 10I.

Next, upon receiving the trace end signal 110, the host CPU I0I reads the trace data stored in the trace memory 104, transmits it to the display device 105, and displays it. After the host CPU l01 finishes outputting all the trace data stored in the trace memory 104,
A trace start signal 111 is transmitted to the trace memory address generation section 103. During this trace output processing, the target CPU 601 continues to execute the application program. Trace memory address generator 1
03 restarts the trace process upon receiving the trace start signal 111. Hereafter, the same process is repeated0
The trace function in the conventional debug function has been described above, but in the conventional debug function, the instruction trace of the application program is generally performed at the timing of the generation of the RD signal 604 or the WR signal 605, and the trace memory 104 is also generally handled in this conventional example. Regarding the data to be traced, in addition to the contents of the address bus and data bus, there are also functions to trace the contents of the boat and other terminal states depending on the functions of the target CPU. In the conventional example, only the address bus and data buzz were mentioned.

[Problem that the invention seeks to solve]

The trace processing function used in the conventional example is a debug function that traces the instructions one by one when an application program is executed.

Hereinafter, a debugging method using the trace function on the address and data buses shown in the conventional example will be explained using a multiprogramming example shown in FIG.

In the example of multiprogramming shown in FIG. 7, a plurality of programs synchronize to construct one programming system. This multiprogramming system is an operating system (hereinafter referred to as O8).
Although there are some differences depending on the type of OS (called OS), O8 in this example is considered to be common among real-time OS for control. The individual programs that make up a multiprogramming system are called tasks, and each has a priority, and execution can be started by using the CPU's free time that is created while one task is waiting for some event to occur. Select one task from among other tasks waiting to be executed.
Select one and put it into execution state. This process of replacing tasks is called dispatching, and dispatching occurs by issuing a group of instructions called system calls that are issued to interrupts and O8.

Therefore, in such a multiprogramming system, what is particularly important for debugging is how to monitor the state transition of this task in real time.

Therefore, we will discuss the problems with the conventional technology in Section 6 below.
This will be explained with reference to the configuration diagram of the conventional example shown in the figure and the state transition of multiprogramming shown in FIG. In the conventional trace function, information on memory accesses is sequentially stored in the trace memory 104 when an application program to be debugged is executed.
When memory becomes full, trace processing is interrupted. While the trace processing is suspended, the content of the trace memory 104 is displayed, and the application program continues to be executed even during the suspension of the trace processing. When the display processing of the trace memory 104 is completed, the trace processing is restarted. Therefore, it is not possible to grasp the execution state of the application program while this trace processing is suspended.Moreover, if the capacity of the trace memory 104 is increased in order to grasp this state transition, the display processing will take more time.
Since the interval between trace interruptions also increases, the allowable capacity of the trace memory 104 is naturally subject to appropriate limitations. Here, the multiprogramming system shown in Figure 7 is
The case of debugging using the conventional trace function will be explained. At this time, the trace process is set to start from address A, and the address where the trace memory 104 is full and the trace is interrupted is address B.
Next, assume that the address at which the display process is finished and the trace process is restarted is address C. The state transition of the task caused by each system call instruction during the suspension of trace processing from address B to address C is as follows. First, by system call S[1S-TSK issued from task (B), task (B)
puts the self-task into an execution-suspended state and switches the task to task (C).

Next, task (C) calls system call 5ND-111s
The data is sent to another task by G, and the task is switched to the task (A) which was waiting to receive data from the other task. However, when the external interrupt shown in FIG. 7 occurs at address X on task (C), the state transition during that time changes depending on the system call issued in the external interrupt processing routine. That is, system call RSM- changes task (B) from a suspended state to an executable state.
TSK is issued, control is switched to task (B),
When task (B) issues a system call SND-MSG to transmit data, the task is switched to task (A) which has been waiting to receive data from another task. Such changes in the flow of control due to interrupts have frequently occurred even in sequential processing programs that were targeted for debugging in the prior art. However, due to the structure of multiprogramming, task state transitions occur frequently, especially when interrupts or system calls are issued, so it is difficult to follow the flow of the entire system by simply sequential tracing. Recently, these types of multiprogramming systems have become widespread, but debugging functions using conventional technology can be expected to be somewhat effective for normal sequential processing programs. For these reasons, multiprogramming systems that switch tasks one after another have the disadvantage that the execution status cannot be fully grasped.

In order to realize a multiprogramming system, the present invention provides a CPU that implements various system call functions as dedicated instructions in the control program O8.
In particular, with consideration given to efficient programming debugging of multiprogramming systems, the book has original content that adds special functions for debugging to the CPU, making it possible to easily construct a debugging system.

[Means to solve the lock problem]

The multiprogramming oriented CPU of the present invention manages the processing of an overwrite system for realizing multiprogramming, and transmits information regarding the multiprogramming system onto an external data bus of the CPU when executing a system call instruction. and means for notifying the outside of the CPU that the information has been output onto the external data bus.

[Embodiment 1] In a multiprogramming system, the state transition of each task occurs by executing a system call in a program issued to O8. Execution of a system call is usually realized by a combination of instructions, but
The CPU to which the present invention is applied is based on the premise that the execution of the system calls in a program is not realized by a combination of instructions, but is executed by a microprogram of the CPU as a dedicated instruction. Hereinafter, the dedicated instruction will be referred to as a system call instruction, and a CPU equipped with this system call instruction will be referred to as a multiprogramming CPU.

The debug function for the multiprogramming-oriented CPU of the present invention will be explained with reference to FIGS. 1 to 4.

FIG. 1 is an overall configuration diagram showing a first embodiment of a multiprogramming-oriented CPU and a debugging device thereof according to the present invention. The CPU targeted by the present invention is the multiprogramming CPU 106. The multiprogramming/debugging device in this embodiment also includes a host CPU 101, a host memory 102, and
In addition to the display device 105, a multi-programming CPU
In order to store the data on the data bus in the trace memory 104 in synchronization with the latch clock 109 output from l06, a trace memory address generation section 103 is provided which generates an address in the trace memory 104.

FIG. 2 is a diagram showing the internal structure of the multi-program CPU 106 of the present invention. The multiprogramming CP
U106 includes an arithmetic logic unit (hereinafter referred to as ALU) 106-1, a general-purpose register group 106-9, a temporary register group 106-8, and a bus for i\iIIm address bus and data bus. An interface control unit 106-2, an instruction register 106-10 that temporarily stores instructions taken in via a data bus, an instruction decoder 106-3 that decodes the instructions, and a microprogram that executes processing corresponding to each instruction. a microprogram memory 106-4 in which is stored, a task management unit 106-6 that manages task control information in a multiprogramming system, and a mailbox management unit that manages mailboxes as one of the synchronization mechanisms between tasks. 1
06-5. It also includes a latch clock generating section 106-7 for generating a notification signal to the outside of the CPU when a system call instruction is executed under the control of a microprogram.

Figure 3 is a flowchart showing the processing of the RCV-MliG command, which receives a message from a mailbox, as an example of various system call commands.Normally, data is exchanged between tasks. In this case, the data is managed using a shared buffer between each task, with the data sending task sending data to the shared buffer and the receiving task receiving data from the shared buffer. Under the control of O8,
This data is generally referred to as a message, and the shared buffer is generally referred to as a mailbox.

The process first involves checking whether a message is registered in the specified mailbox (step 201).
), if there is a registered message, pass a pointer pointing to this message storage area to the reception request task (step 20).
2) At the same time, delete the same message and the registration from the specified mailbox (step 203), and if the message is not registered in the specified mailbox, change the status of the message reception request task from the execution state to the message waiting state (step 203). Step 204), and at the same time, register it as a message waiting task in the designated mailbox (Step 205). After completing the above processing, dispatching is performed. In the disk batching process, as a result of the above process, the status of the message reception request task and
Tasks are swapped based on the status of other tasks, the priority of each task, etc.

FIG. 4 shows the data flowing on the internal data bus in the process in which the multiprogramming CPU 106 decodes the RCV-MSG system call instruction taken as an example in FIG. 3 and processes it according to the instructions of the microprogram. Figure 0 Normally, the external data bus is driven only when a memory read or write strobe signal is generated, and is in a floating state for internal CPU operations. Among the data flowing on the internal data bus, only data that is valid for the multiprogramming debug device is placed on the external data bus, and also to notify the outside that valid data has been placed on the external data bus. It has a function of generating a latch clock 109 as a notification signal. When the multiprogramming CPU 106 detects and decodes the system call instruction RCV-MSGe, it starts processing the execution routine of the corresponding instruction in the microprogram memory 106-4. Valid data flowing on the internal data bus during processing includes a system call instruction identifier, a mailbox identifier, and a system call instruction R.
CV-MS (includes the issuing task identifier of i, the issuing task status, the identifier of the task selected in the dispatching process, etc.), and at the same time as these data are placed on the external data bus, the latch clock generator is activated at this timing. 106-7 and generates a latch clock 109 to the outside.The multi-programming CPU 106 thereby generates the latch clock 109 and trace data at the timing shown in the time chart of FIG.

In the form explained above, trace information is sent to the CPU.
106 occurs, and the multiprogramming/debugging device performs tracing processing for this. The trace memory address generation unit 103 receives the latch clock 109 and generates an address for the trace memory 104, so that the trace data on the data bus that the multiprogramming CPU 106 outputs simultaneously with the latch clock is transferred to the trace memory 104. Stored.

In this manner, trace memory 104 continues to store information related to the processing of system call instructions until the memory capacity overflows. When the trace memory 104 overflows, the trace memory address generation unit 103 sends a trace end signal 110 to the host CPU I0I. The host CPU I0I reads the contents of the trace memory 104 and displays the system call instruction information on the display device 105. After displaying the system call instruction information in the trace memory 104, the host CPU l01
A trace start signal 111 is transmitted to the trace memory address generation section 103. The above series of processing is similar to conventional trace display processing. When the trace memory address generation unit 103 receives the I/race start signal 111, it restarts the system call trace processing that occurs when the latch clock signal 109 is received. Hereinafter, system call trace processing and trace output processing will be repeated in the same way. It is something.

[Embodiment 2] Next, a second embodiment of the debugging function for a multiprogramming-oriented CPU of the present invention will be described.

In this second embodiment, multiprogramming debugging enables tracing of information at the time of issuing a system call instruction in real time for application program processing.

I will explain the functions. FIG. 5 is a block diagram showing the second embodiment. The CPU targeted in this embodiment is the multiprogramming CPU 106 described in the first embodiment.
It is. In addition, the host CPU of conventional debug equipment
101. In addition to the host memory 102 and the display device 105, there are data latches (1) to data latches (1) for loading data on the data bus in synchronization with the latch clock 109 output from the multiprogramming CPU 106.
0) and a data latch control unit 501 that generates a latch signal for each data latch.

The multiprogramming CPU 106 has the same functions as those described in the first embodiment. Furthermore, the flow of processing of the system call instruction shown in FIG. 3, the trace data on the data bus output during the processing of the system call instruction shown in FIG. 4, and the timing of latch clock generation are also similar to the first embodiment. is the same as

An outline of the processing of the multiprogramming/debugging device shown in FIG. 5 will be explained below.

First, the multiprogramming CPU 106 detects and decodes the system call instruction RCV-MSG, and starts processing the corresponding execution routine in the microprogram memory 106-4. Valid data flowing on the internal data bus during processing includes a system call command identifier, a mailbox identifier, and a system call command RCV-
There are the issuing task identifier of the MSG, the issuing task status, the identifier of the task selected in the dispatch processing, etc., and at the same time as these data are placed on the external data bus, the latch clock generator 10
6-7 and generates a latch clock 109 to the outside. This allows multiprogramming CPU1
06 generates the latch clock 109 and trace data at the timing shown in the time chart of FIG. In the form explained above, trace information is
The multiprogramming CPU 106 generates a message, and the multiprogramming/debug device performs a trace process.The following trace process will be explained using the system call instruction RCV-MSG shown in FIG. 3 as an example.
The data latch control unit 501 controls the latch clock 109 generated by the processing of the multiprogramming CPU 106.
In response to this, the multiprogramming CPU 106 reads the trace data on the data bus output at the same time as the latch clock 109, and as a result of six readings, the number of trace data associated with the system call identifier is determined. Data latch! The II control unit 501 stores trace data in a different data latch every time the latch clock 109 is generated.The number of trace data output from the multiprogramming CPU 106 by executing one system call instruction The data latch control unit 501 has a system call command R.
When all the trace data accompanying the CV-MSG is stored in the data latch, the host controller sends a trace end signal 110 to notify that all the trace data has been stored.
Send to PUl0I. Upon receiving the trace end signal 110, the host CPU 101 stores the necessary number of trace data corresponding to each system call instruction in the data latch (
1) ~Receive from data latch (10). The above process is repeated every time a system call instruction is issued during execution of the application program to be debugged.

As described above, the multiprogramming/debugging device of the second embodiment traces the information of the system call instruction in parallel with real-time processing, without going through the trace memory, every time the system call instruction appears in the application program. This makes it possible to display this information at the time a system call instruction occurs.

〔Effect of the invention〕

As described above, by using the multiprogramming-oriented CPU of the present invention, it is possible to realize history tracing of system call instructions in real time in a multiprogramming/debugging device.

Below is the 8th Q? The effects of the present invention will be explained with reference to the display examples shown in I(1) and (2).

This display example is for the multiprogramming example shown in FIG. The first line (A) in the same figure (1) is the identifier of the task that issued the system call instruction, RCV-MSG is the identifier of the system call instruction, Ml is the parameter of the system call instruction, → From here on, As can be determined from the example of displaying 0 indicating the identifiers of the tasks to which control has been transferred after the date batch, it is possible to grasp the flow of the entire program, which could not be sufficiently followed by sequential tracing based on address information. The example in (1) in the same figure shows the case where no interrupt occurs at address X, and the example in (2) in the same figure shows the case in which an interrupt occurs at address X. Therefore, each task state transition between address B and address C, which could not be seen by tracing in the prior art, becomes clear. In this way, tracking the status of each task is most important in multiprogramming, and as a result of focusing on issuing system call instructions according to the present invention,
Trace processing is very effective in debugging programs. In addition, especially when depacking a program that is used in conjunction with a device@, it is not possible to use the conventional break processing of the depack function to temporarily stop the control flow and check the program execution status at that point. It is required to trace the execution status while the machine is running. Programs that are subject to these restrictions are
If the program is constructed using a multiprogramming system targeting the CPU of the present invention, the debugging functions of the first and second embodiments can be used for multiprogramming without interrupting the flow of control. The CPU of the present invention is particularly excellent in that it can trace the state transitions of tasks, which is important for debugging.The CPU of the present invention provides technologies such as these two embodiments, and significantly improves the efficiency of debugging multiprogramming. It has the effect of

[Brief explanation of the drawing]

FIG. 1 is an overall configuration diagram of a first embodiment of a multiprogramming-oriented CPU and its multiprogramming/debugging device according to the present invention, FIG. 2 is a configuration diagram of a multiprogramming-oriented CPU according to the present invention, and FIG. 3 is a message FIG. 4 is a flowchart showing the processing of the receiving system call. FIG. 4 is a timing chart of data on the data bus and latch clock generation during processing of the message receiving system call. FIG.
FIG. 6 is an overall configuration diagram of a second embodiment of U and its multiprogramming/depacking device; FIG. 6 is an overall configuration diagram of a conventional depacking device for a CPU; FIG. 7 is a state transition diagram of the multiprogramming system; FIG. 8 (1), (2)
FIG. 3 is a diagram showing an example of displaying trace processing according to the present invention. 101 is a host CPU, 102 is a host memory, 103
104 is a trace memory address generator, 104 is a trace memory, 105 is a display device, 106 is a multiprogramming CPU, 107 is a target memory, 108 is a multiplexer, 109 is a latch clock, 110 is a trace end signal, 111 is a trace start signal, 106 is ALU
, 106-2 is a bus interface control unit, 106-3
1 is an instruction decoder, 106-4 is a microprogram memory, 106-5 is a mailbox management section, 106-6 is a task management section, 106-7 is a latch clock generation section, 1
06-8 is a temporary register group, 106-9 is a general-purpose register group, 106-10 is an instruction register, 501 is a data latch control unit, and 502 to 511 are data latches (1)
~(10), 601 is a target CPU, 602 is an address latch, and 603 is a multiplexer.

Claims (1)

[Claims] A multiprogramming-oriented CP that controls operating system processing to realize multiprogramming.
U outputs information regarding the multiprogramming system onto an external data bus of the CPU when executing a system call instruction, and notifies the outside of the CPU that the information has been output onto the external data bus. A multiprogramming-oriented CPU characterized by being equipped with means for.