JPH0444292B2 - - Google Patents

Description

[Detailed Description of the Invention] (Industrial Application Field) The present invention relates to a debugging device for a microprocessor that tests the operation of a target CPU, and in particular performs real-time tracing (so-called monitoring) of a program written in a high-level language. Regarding the improvement of time functions.

(Prior Art) In recent years, in the development of microprocessor application equipment, programs have been increasingly written using high-level languages (eg, C, Pascal, PL/M, etc.). Under these circumstances, the final program completion (work from debugging to evaluation) is carried out by running the program on the actual device and combining it with peripheral devices. In this situation, a debugging device must be compatible with high-level languages, and the current support for high-level languages (hereinafter referred to as HLL) is as follows.

Debugging equipment is basically assembler-based, and uses assembler-level execution trace data and corresponding HLL information (for example, line numbers,
(function or variable name, etc.)
It is HLL compatible.

An example of this situation is shown in FIGS. 8 to 10. Figure 9 shows assembler level data.
Figure 10 shows the result with HLL information added to it. The part surrounded by a square frame is HLL information.
Note that these HLL sources are shown in FIG.

(Problem to be Solved by the Invention) However, in order to obtain a display with added HLL information as shown in Figure 10, all data in Figure 9 must be checked and replaced (or added) with HLL information.
I'm deciding whether to do it or not. However, adding HLL-level information to a large amount of assembler-level information would take a long time to process, even if it was only for one screen, making it impractical.

It is also possible to store HLL information in memory in advance and process it at high speed, but if you try to replace HLL information (source line information) that is more detailed than that shown in Figure 10, the memory capacity will be enormous and this cannot be realized. Nakatsuta. Such information is generally stored in a storage device such as a floppy disk device, and therefore there is a problem in that it takes time to access.

In this way, the higher the speed, the larger the memory capacity, and on the other hand, if the memory capacity is kept constant, more detailed HLL information will be missing. The root cause of these problems is that the assembler information contains data that is not required at the HLL level, so it is necessary to judge whether or not all lines of assembler level data correspond to HLL information. It is.

In view of these points, an object of the present invention is to perform the process of replacing assembler level data with high level language level information at high speed, to obtain a high level language screen at a virtually problem-free processing speed, and to obtain a high level language screen of a certain size. By obtaining more high-level language information in the trace memory than before, it is possible to debug a wider range with a single operation of the debugging device, improving debugging efficiency. The purpose of this invention is to provide a debugging device.

(Means for Solving the Problem) In order to achieve such an object, in the present invention, a mark (data) is attached in advance to a part of the assembler information that requires conversion, and only the part with the mark is used by the assembler. It is characterized by being configured to convert information into high-level language information.

(Example) The present invention will be explained in detail below using the drawings. Figure 2 is an example of a program created using PL/M, and when the parts surrounded by square frames (line numbers 636 to 641) are made to correspond to the assembler, the list shown in Figure 3 is obtained. In the list shown in Figure 3, in order to obtain HLL information from assembler information, it is only necessary to focus on the asterisked and underlined parts (approximately 1/3 of the total) as shown. In other words, by marking the required assembler information in advance, it is possible to omit exchanging assembler information/HLL information for each line, and therefore, the assembler information/HLL information can be converted most efficiently.

The present application is based on such a technical idea, and FIG. 1 shows an example of a configuration for implementing it. In the figure, reference numeral 1 denotes a target central processing unit (abbreviated as target CPU) to be debugged, and the memory and peripheral devices of the target system (not shown) are connected to this target CPU.

2 is a target CPU address bus, 3 is a target CPU data bus, and 4 is a target CPU control bus, which are connected to three-state buffers 5, 6, and 7, respectively. The output terminal of the buffer 5 is connected to the sampling bus (for address) 8 for the debugging device, the output terminal of the buffer 6 is connected to the sampling bus (for data) 9 for the debugging device, and the output terminal of the buffer 6 is connected to the sampling bus (for data) 9 for the debugging device.
The output terminals of each are connected to a sampling bus (for control) 10 for a debugging device.

11 is an address generator that generates an address for the sampling memory 14, and targets the write address ADDR of the sampling memory 14.
It is designed to occur sequentially in synchronization with the bus timing of CPU1.

12 is a three-state buffer, and 13 is a write signal generation circuit that generates a sampling memory write signal WR.

Sampling memory usually consists of RAM (RAM is random access memory) (hereinafter referred to as sampling RAM).

15 is a 3-state buffer group, 16 is a debugging device internal data bus, and 17 is a sample point.
memory; 18 is a debugging device internal address bus;
19, 20, and 22 are 3-state buffers, and 21 is a bidirectional 3-state buffer.

23 is a debugging device CPU address bus, 24
25 is the debugging device CPU data bus, 25 is the debugging device CPU control bus, 26 is the debugging device CPU, 27 is the CRT, keyboard, ROM,
Debug device peripheral devices such as RAM are shown.

The debugging device CPU 26 can access the memories 14, 17, etc. via each bus.

The operation in such a configuration will be explained next.

(1) Initialization The sample point memory 17 is initialized as follows. This process is carried out by the debugging device CPU.
26 is performed by executing the program of the debugging device. The command is input from a keyboard or the like.

Data (addresses) that require tracing (sampling) are collected in advance from outside the debugging device.
For example, it is provided as data to a debugging device from a communication means or a floppy disk device.

With this information, sample point memory 17 is initialized as shown in FIG. Fourth
In the figure, D ₀ and D ₁ are the data bits of the sample point memory 17, and in this example, 2
Bits provided. The address of the sample point memory 17 is set to be the same as the address of the program of the target CPU, and the part of the running target program where a sample is required is set to "1", and the other parts are set to "0".

The two bits D ₀ and D ₁ are provided because one bit (D ₀ ) indicates the assembler instruction corresponding to the beginning of the line, and the other bit (D ₁ )
This is because the bit indicates an instruction that refers to a variable.

(2) Trace When the target CPU 1 executes the target program, the execution address at that time is stored in the sample point memory 17 via the buffer 5.
is input. At this time, the sample point memory 17 has been initialized according to the pattern explained in (1) above, and D ₁ and D ₀ according to the instruction run address are initialized.
Data is output to the debug device internal data bus 16. In other words, when D ₀ data is "1", it indicates that the corresponding assemble instruction was executed at the beginning of the HLL line, and when D ₁ data is "1"
In the case of , it indicates that an assembler instruction corresponding to HLL variable access was executed.

The debug device internal data bus 16 is also connected to the address generator 11 and the write signal generator 13. The address generator 11 receives a control signal from the target CPU 1 via a buffer 7 and a debugging device internal data bus 1.
6 Sample point memory 1 from the above data
7, when data to be sampled is generated, sequentially increasing addresses are generated and applied to the sampling RAM 14 via the buffer 12.

Further, the write signal generation circuit 13 has a buffer 7
It receives a control signal from the target CPU 1 and data on the debugging device internal data bus 16, generates a write signal WR, and outputs it. As a result, sampling RAM1
4, the information to be sampled on the buses 8, 9, 10, 16 at the address generated by the address generator 11 is written.

In particular, in the write signal generation circuit 13, D ₀ is “1”
In this case, the data to be sampled needs to be data read/written to memory rather than an instruction, so this is also controlled.

The contents of the sampling RAM 14 when the program shown in FIG. 4 is executed are as shown in FIG. 5.

(3) Sample result processing As shown in Figure 5, the sampling RAM 14 has line number access (when E ₀ = 1) and variable access (access when reading and writing; at this time, E ₀ = 0). Both information is included. It is easy to construct HLL level information from assembler level information.

This processing is performed by the debugging device CPU 26, and the sampling
The contents of the RAM 14 are read out via the debugging device CPU data bus 24, and the processing flow shown in FIG. 6 is performed.

Note that the present invention is not limited to the above embodiments, and various embodiments are possible.

In the above embodiment, the sampling targets are limited to line numbers and variables, but functions and the like may be added. In this case, the sample point memory only needs to be increased by one bit for each address.

In this example, the work from assembler to HLL conversion is performed in a debugging device, but in recent years the configuration of debugging devices has changed to include a dedicated debugging machine and a workstation (more advanced than the debugging device), as shown in Figure 7. There is an increasing trend in the number of cases in which a debugging environment is constructed using two devices (having processing capabilities such as arithmetic operations), and the present invention can be applied to such systems as well.

In such systems, all HLL compilation is done on the engineer workstation (EWS).
Do it with Therefore, all replacement data regarding HLL is in EWS. On the other hand, all information at the assembler level resides in the general-purpose emulator (its functions are provided in the debugging device). When constructing information for conversion from assembler to HLL, assembler level information is transferred from the general-purpose emulator to the EWS side via an RS232C (standardized communication standard) communication line, and converted to HLL level information on the EWS. Displayed on the EWS console. At this time, the RS232C line has a lower transfer rate than the internal bus of the debugging device and takes time to transfer. Therefore, the less data (assembler level information) that passes through this line, the faster the processing speed will be. In short, according to the present invention, the data sampled on the general emulator side does not include unnecessary data, so only the minimum necessary data passes through the communication line, resulting in faster operation than the conventional method. becomes possible.

(Effects of the Invention) As explained above, the present invention has the following effects.

When creating HLL level information from assembler level information, it is possible to improve the conversion speed by limiting the sampling of assembler level data to that necessary for conversion to HLL. In terms of unit size, more HLL information can be obtained compared to sampling all information at the assembler level, and sampling memory can also be saved.

[Brief explanation of the drawing]

FIG. 1 is a configuration diagram showing one embodiment of the present invention, and FIG.
Figure 3 and Figure 3 are diagrams showing an example of a list for explaining assembler information/HLL information conversion, and Figure 4 shows an example of a list for explaining assembler information/HLL information conversion.
5 and 5 are explanatory diagrams for explaining the operation,
Figure 6 is a flowchart showing the processing flow;
FIG. 8 is a block diagram showing an application example of the present invention, and FIGS. 8 to 10 are diagrams showing an example of a list for explaining conventional assembler information/HLL information conversion. 1...Target CPU, 2-4, 8-10,
1, 6, 18, 23-25... bus, 5-6, 1
2, 15, 19-22...Buffer, 11...Address generation circuit, 13...Write signal generation circuit,
14... Sampling memory, 17... Tuple point memory, 26... Debugging device CPU,
27... Debugging device peripheral device.

Claims (1)

[Scope of Claims] 1. A microprocessor debugging device for inspecting the operation of a target CPU, which is capable of adding corresponding high-level language information to assembler-level execution trace data. In the device, for the address corresponding to the execution address of the target program, data indicating whether the execution address that requires a sample corresponds to the start of a line in a high-level language or a variable access in a high-level language is stored. A sampling memory that stores information such as information indicating whether to write or read memory, bus information, information indicating whether high-level language variable access or line number access, etc., and control of the target CPU. Target the write address of the sampling memory from the signal and the contents of the sample point memory.
an address generation circuit that sequentially generates an address in synchronization with the bus timing of a CPU; a write signal generation circuit that generates a write signal for the sampling memory from a control signal of a target CPU and the contents of the sample point memory;・Equipped with a means for determining high-level language line number replacement or variable name replacement according to the contents of the memory and replacing it with appropriate information, and converting from assembler level information to high-level language level information after limiting the target of conversion in advance. A debugging device for a microprocessor, characterized in that it is capable of converting into a microprocessor.