US5903759A - Software performance analysis using hardware analyzer - Google Patents
Software performance analysis using hardware analyzer Download PDFInfo
- Publication number
- US5903759A US5903759A US08/868,573 US86857397A US5903759A US 5903759 A US5903759 A US 5903759A US 86857397 A US86857397 A US 86857397A US 5903759 A US5903759 A US 5903759A
- Authority
- US
- United States
- Prior art keywords
- output
- computer code
- output terminal
- processor
- data bus
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/443—Optimisation
- G06F8/4434—Reducing the memory space required by the program code
- G06F8/4436—Exlining; Procedural abstraction
Definitions
- the present invention relates to methods for analyzing computer program performance, and more specifically to an apparatus and a method for analyzing computer program performance using a hardware analyzer, which detects output from sequences of code inserted into a computer program for purposes of performance measurement.
- processor emulators are programs which run on general purpose computers and emulate the performance of a processor running a specific program as input.
- processor emulators typically run hundreds to thousands of times slower than the computational systems that they emulate. Hence, a program of any significant length running on a processor emulator will take a prohibitively long time to simulate.
- Hardware analyzers such as logic analyzers or digital oscilloscopes have been used to aid in debugging code and to analyze the performance of computer programs.
- Hardware analyzers are typically used to analyze computer system performance by monitoring processor bus cycles looking for occurrences of particular addresses or data words on a processor's address and data bus. Analyzing computer program performance in this way is a difficult if not impossible task, because it is difficult to correlate particular program instructions with corresponding processor bus activity.
- This method has a number of disadvantages. It requires a logic analyzer to be connected to both a data bus and an address bus. In a 32bit system, this may require connecting a logic analyzer up as many as 80 pins. These pins may not be accessible in an embedded controller, in which address and data bus lines are not directly connected to external pins. Even if address and data bus lines are connected to external pins, such as in a microprocessor,the external pins may not be easily accessible if the microprocessor is housed in a standard pin grid array, in which hundreds of closely-spaced pins in a grid pattern protrude from the bottom of a semiconductor chip package.
- Connecting a logic analyzer to a pin grid array typically requires removing the pin grid array from its matching socket in the circuit board, inserting a special adaptor into the socket, and inserting the pin grid array into a matching socket on the opposite side of the adaptor. This process can be very time-consuming. It furthermore requires the computer system to be powered down and rebooted, which might destroy transitory computer system anomalies before they can be analyzed. Furthermore, monitoring a large number of pins requires time-consuming mapping of pins to address and data lines, as well as the complex process filtering of address patterns after triggering. Finally, buffer memory is typically limited in a logic analyzer, and recording the state of a large number of pins can consume a great amount of memory. Consequently, the logic analyzer can only record a limited number of data patterns.
- the method disclosed in the above-mentioned patent also requires specific locations at entry and exit points of software routines to be reserved for the possible insertion of markers. Consequently, the method is not flexible because it only allows markers to be inserted at particular locations. The method also consumes a significant amount of memory because locations must be reserved even if markers are not placed in the locations. Memory space is of particular concern in microcontroller systems, in which memory is often extremely scarce. Providing additional memory locations for possible insertion of code markers also requires recompilation, which may affect the performance of the program in unpredictable ways.
- the present invention makes it possible for programmers to analyze the performance of computer programs using a hardware analyzer in a manner that is both efficient and non-intrusive.
- the invention operates by inserting output sequences into a computer program. Those output sequences are sequences of computer instructions which cause the processor to send a pre-defined pattern through the data bus to an output terminal.
- a hardware analyzer or digital oscilloscope is connected to the output terminal through which it gathers data that is used to calculate the performance of the computer program. Output sequences can be inserted at almost any location in the computer program.
- Output sequences can also be inserted into executable code as well as source code versions of the program.
- an output sequence When an output sequence is inserted into executable code, it replaces a portion of the executable code with another piece of executable code which performs the same functions as the executable code that was replaced, and additionally causes the processor to send an output to the output terminal.
- executable code can be analyzed without the time-consuming and unpredictable process of recompiling the original source code from which the executable code was derived.
- output sequences are embedded into source code, the source code is first recompiled into executable code, and this executable code is then monitored analyzed.
- the present invention provides a number of advantages. (1) It facilitates accurate performance measurements in light of pre-fetching and caching operations. (2) It can operate on object code, so that no time-consuming and unpredictable recompilation of the source code is required. (3) The method operates by connecting a hardware analyzer, such as a logic state analyzer or a digital oscilloscope, to only a few external pins on the computer system instead of an entire address bus and data bus. This is convenient in embedded systems, device controllers or other microprocessor systems in which address and data bus lines are not accessible to a hardware analyzer. Furthermore, a simple hardware analyzer with only a few input lines can be used. (4) The present invention does not use large amounts of extra memory. This is an important feature in embedded systems in which extra memory may be unavailable. (5) The present invention allows output sequences to be located almost anywhere in the computer code, not just at entry and exit points to subroutines or functions. This allows a wider range of specific performance measurements to be taken.
- the present invention can be characterized as a method for analyzing the performance of a computer program which operates in a computer system including: a processor, a memory, an output terminal, an address bus and a data bus, the data bus coupled to the processor, the memory and the output terminal.
- the method operates by: inserting an output sequence into the computer code, the output sequence causing the processor to send an output through the data bus to the output terminal; connecting a hardware analyzer to the output terminal; running the computer code; monitoring the output terminal with the hardware analyzer to gather data; and calculating the performance of the computer code from the gathered data.
- the step of inserting the output sequence into the computer code includes replacing original instructions in the computer code with the output sequence.
- the output sequence can be inserted at any instruction in the computer code.
- the present invention can also be characterized as an apparatus for measuring performance of a computer code, comprising: a processor; a memory; an output terminal positioned and shaped to receive a connection to a hardware analyzer; and a data bus coupled to the processor, the memory, and the output terminal; wherein the memory includes resources for inserting at least one output sequence into the computer code, the output sequence causing the processor to send an output through the data bus to the output terminal.
- the output sent through the data bus to the output terminal includes information on the progress of the processor through subroutine and function calls in the computer code.
- the present invention can also be characterized as an apparatus for measuring performance of computer code, comprising: a processor, a memory, a data bus coupled to the processor and the memory, and an output terminal coupled to the data bus, the output terminal positioned and shaped to receive a connection from a hardware analyzer.
- the apparatus includes: an address decoder; an address bus coupled to the address decoder; and a selector coupled to the data bus, the address decoder and the output terminal, the selector establishing a signal path between the data bus and the output terminal when the address decoder detects a specific address on the address bus.
- FIG. 1 is a block diagram illustrating how a computer system is connected to a hardware analyzer in accordance with an aspect of the present invention.
- FIG. 2 is a flow chart illustrating the sequence of operations involved in analyzing performance of a computer program using a hardware analyzer in accordance with an aspect of the present invention.
- FIG. 3 is a diagram illustrating how a section of executable code is replaced with an output sequence, which sends an output through the data bus to an output terminal in accordance with an aspect of the present invention.
- FIG. 4 illustrates an example of how information regarding the progress of the processor through subroutines and functions can be passed through the output terminal to the hardware analyzer in accordance with an aspect of the present invention.
- FIG. 5 is a diagram illustrating the structure of a dedicated output terminal for performance measurement which is positioned and shaped to receive a connection from a hardware analyzer in accordance with an aspect of the present invention.
- FIG. 6 is a flow chart of a program which inserts output sequences into program code in accordance with an aspect of the present invention.
- FIG. 1 is a diagram illustrating how a computer system is connected to a hardware analyzer in accordance with an aspect of the present invention.
- Computer system 170 includes bus 110, which connects to CPU 100, register or LED 120 and memory 140.
- Computer system 170 is any type of computer system including a device controller, an embedded system, a microprocessor system, or any other general or special purpose computing system which includes a processor and memory.
- CPU 100 is any type of central processing unit, such as a central processor unit in a microprocessor, or a central processor unit implemented in another technology.
- Register or LED 120 is any type of register or other computer component, such as an LED, which can relay output from bus 110 to hardware analyzer 130.
- Register or LED 120 need not contain a memory element, such as a latch or a register. It only needs to drive the contents of a data bus line from bus 110 onto output terminals 160.
- Output terminals 160 can be any type of externally accessible pins or leads which are coupled to the data bus.
- One embodiment of the present invention uses reserved pins on a register, such as a control register, for output terminals.
- Another embodiment uses outputs to light emitting diodes (LEDs).
- register or LED 120 and output terminals 160 may take form of a specifically designed performance analysis output terminal which is described in more detail at a later point in this specification.
- Output terminals 160 connect to hardware analyzer 130.
- Hardware analyzer 130 is any type of hardware analyzer, including logic analyzers, digital oscilloscopes and analyzers which record analog data. The only requirement is that hardware analyzer 130 be able to receive performance information from register or LED 120.
- Memory 140 is any type of memory connected to a computer system. This includes semiconductor memory as well as memory on magnetic or optical storage devices. The only requirement is that memory 140 be able to store code which is executed by CPU 100. Inside memory 140 is code with inserted output sequences 150. This is the code that results after output sequences are inserted into a piece of computer code. In one embodiment of the present invention, memory 140 additionally includes software to perform the placement and insertion of output sequences into computer code to produce code with inserted outputs sequences 150. This software is described in more detail at a later point in this specification.
- FIG. 2 is a flowchart of the sequence of operations involved in measuring the performance of computer code in accordance with an aspect of the present invention.
- the systems starts at state 200, which is the start state.
- the system next proceeds to step 201.
- output sequences are inserted into the computer code. This can take place in a number of ways. If computer system 170 is a device controller or an embedded system without a display device or without sufficient memory space for the code to perform the insertion, the insertion takes place in a separate general purpose computing system. After the insertion is completed, the code with inserted output sequences 150 is loaded into memory 140. On the other hand, if computer system 170 has a display device and sufficient memory for software facilities to perform the insertion, this insertion can take place within computer system 170.
- this insertion takes place with the support of software to perform the insertion.
- the insertion is performed by a system user through a debugger program. The system user manually inserts and moves specific instructions to insert the output sequence.
- the insertion is performed by a system user through an in-circuit emulator (ICE). The system user selects strategic locations in the code, and subsequently executes the code using the in-circuit emulator. During the execution of the code, pre-defined patterns are written to output terminals when the strategic locations are reached.
- a special software tool for insertion is used to locate and insert the output sequences into the code. This tool is described in more detail at a later point in this specification. The system then proceeds to step 202.
- hardware analyzer 130 is connected to output terminals 160.
- output terminals 160 are any unused terminals of the computer system through which data can be outputted. This includes unused or reserved pins of a control register, or any other type of register.
- output terminals 160 are LED pins.
- hardware analyzer 130 is connected to specially designed performance analysis output terminals, which are coupled to bus 110, and are positioned and shaped to receive a connection from hardware analyzer 130. The system then proceeds to step 204.
- code with inserted output sequences 150 has been loaded into memory 140.
- Code with inserted output sequences 150 is then run with a test input in order to test the performance of the code. The system then proceeds to step 206.
- hardware analyzer 130 monitors the output from output terminals 160 while the code is running. Hardware analyzer 130 is set to trigger on specific outputs to output terminals 160, which are generated by the output sequences within the code. These output sequences cause particular outputs to be written to register or LED 120, and ultimately to appear on output terminals 160. The system then proceeds to step 208.
- hardware analyzer 130 gathers data received by monitoring output terminals 160, and stores this data within a local buffer memory inside hardware analyzer 130. The amount of data that can be gather is limited by the memory capacity of hardware analyzer 130. The system then proceeds to step 210.
- step 210 the data which has been gathered is used to calculate a performance of the computer program.
- This performance can include execution time through different portions of a program, as well as a mapping of the execution pathway through the program.
- the system then proceeds to step 212 which an end state.
- FIG. 3 illustrates a method for inserting an output sequence into a section of executable code in accordance with an aspect of the present invention.
- the original executable code is represented by the instructions on the left hand side of FIG. 3.
- Instructions BBB and CCC are replaced with an Instruction "jmp WWW.”
- "jmp WWW" takes the place of two instructions because the destination address WWW takes up an entire instruction word by itself.
- Instructions BBB and CCC are copied at location WWW, which is illustrated on the right-hand-side of FIG. 3.
- there is an instruction to write a specified value to the output terminal After the write operation, there is a jump to XXX, which is the location immediately following "jmp WWW.” This returns the program to the location immediately following the inserted code to continue with program execution.
- output sequences are inserted into the source code prior to compilation.
- replacement of executable instructions with output sequence instructions is not required because the compiler will rearrange the existing executable instructions to make room for the inserted output sequence instructions.
- FIG. 4 illustrates how data sent to the output terminal can include information on the progress of the program through the subroutine and function calls in accordance with an aspect of a present invention.
- A starts with a call to T1 -- HIGH, which causes output terminal T1 to assume a high value.
- Function A then executes other instructions including two calls to Function B.
- function A calls T1 -- LOW, which causes output terminal T1 to assume a low value.
- Function B starts with a call to T2 -- HIGH, which causes out terminal T2 to assume a high value. It then executes a number of instructions including a "for" loop, which repeatedly calls function C.
- function B calls T2 -- LOW, which causes output terminal T2 to assume a low value.
- Function C starts by calling T3 -- HIGH, which causes output terminal T3 to assume a high value. Function C then executes a number of instructions, and then calls function T3 -- LOW, which causes output terminal T3 to assume a low value.
- Output terminals T1, T2 and T3 are monitored by hardware analyzer 130 to produce the diagram at the bottom of FIG. 4.
- This diagram illustrates the progress of the program through functions A, B and C. At any point in this diagram, it is possible to determine the nesting of functions A, B and C at a particular point in the execution of the program. This is unlike other performance analysis techniques, which merely trigger on address locations, and consequently may not be able to determine the nesting of function calls during a particular address reference.
- FIG. 5 illustrates an implementation of an output terminal for performance analysis in accordance with an aspect of the present invention.
- FIG. 5 includes address decoder 500, which takes address bus 530 as an input and generates an output which feeds into selector 510.
- Selector 510 takes an additional input from data bus 520 and produces an output which feeds into output terminals 560 and 562.
- at least an output terminal is coupled to the data bus and the address bus through a combinatorial logic arrangement as known in the art.
- Output terminal 560 is positioned and shaped to receive a connection from probe 550, which connects to hardware analyzer 130.
- Output terminal 562 is positioned and shaped to receive a connection from connector 552, which also connects to hardware analyzer 130.
- FIG. 5 operates as follows.
- CPU 100 generates a write to the address of output terminals 560 and 562.
- Address decoder 500 recognizes the address of this write operation and activates selector 510 to output the contents of specific lines from data bus 520 to output terminals 560 and 562.
- Output terminals 560 and 562 connect to probe 550 and connector 552 respectively. These connections enable hardware analyzer 130 to record the output from data bus 520.
- selector 510 does not include a memory element, and a line from data bus 520 is driven onto output terminals 560 and 562, through probe 550 and connector 552, and into hardware analyzer 130 which records the output.
- selector 510 includes a memory element, which records outputs from data bus 520.
- FIG. 5 includes two differently-shaped output terminals, 560 and 562, connected to the same output line. This illustrates the fact that a number of different output terminal shapes can be used. The only requirement is that an output terminal be shaped to connect to a probe or connector from hardware analyzer 130. Other embodiments include only a single output terminal for each output line.
- selector 510 couples a plurality of lines from data bus 520 to a plurality of output lines and output terminals. These connect to a plurality of probes or connectors from hardware analyzer 130.
- FIG. 6 is a flowchart illustrating the operation of a program to insert output sequences into a program in accordance with an aspect of a present invention.
- the system starts at state 600 which is a start state.
- the system next proceeds to step 601.
- the system opens a code file and loads the opened file into memory.
- the system next proceeds to step 602.
- the system outputs the code to a display, so that a user can view the code.
- the system includes user interface facilities, which allow the user to navigate through and selectively view different portions of the code.
- the system next proceeds to step 604.
- the system accepts user input from a user. This user input specifies the location and pattern of output sequences to be inserted into the code.
- the system next proceeds to step 606.
- step 606 the system inserts the output sequence into the specified location in the code.
- step 608 the system determines if there are additional output sequences to be inserted into the code. If not, the system proceeds to step 610. If so, the system returns to step 602 to repeat the sequence of operations for an additional output sequence. Steps 602, 604, 606 and 608 are repeated as necessary to insert all of the desired output sequences. After steps 602, 604, 606 and 608 are complete, the system processed to step 610, in which the code with the inserted output sequences is saved back to the code file. The system next proceeds to step 612, which is an end state.
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
Abstract
The present invention provides a method and an apparatus for analyzing the performance of a computer program inn a way that is accurate in light of prefetching caching operations. The method operates by inserting output sequences into a computer program. An output sequence is a sequence of instructions which cause the program to send an output through the data bus to an output terminal. A hardware analyzer records the output from the output terminal, and this output is used to calculate performance of the computer program. The present invention provides facilities to insert output sequences into executable code, thereby allowing performance analysis to take place without time consuming recompilation. The present invention requires only a small number connections from a hardware analyzer to output terminals connected to the processor data bus. This greatly simplifies the process of gathering data with a hardware analyzer. The present invention also provides for sending information to the output terminals in a format that indicates the progress of the program through subroutine and function calls.
Description
The present invention relates to methods for analyzing computer program performance, and more specifically to an apparatus and a method for analyzing computer program performance using a hardware analyzer, which detects output from sequences of code inserted into a computer program for purposes of performance measurement.
In recent years, computer systems have grown increasingly more complicated as computer programmers add progressively more features to computer programs and as computer designers strive to squeeze ever-increasing performance from computer hardware. As computer programs and computers increase in complexity, it is becoming harder to analyze computer system performance, and consequently harder to identify bottlenecks in computer system performance.
A number of performance analysis techniques are presently employed, including processor emulators. Processor emulators are programs which run on general purpose computers and emulate the performance of a processor running a specific program as input. However, processor emulators typically run hundreds to thousands of times slower than the computational systems that they emulate. Hence, a program of any significant length running on a processor emulator will take a prohibitively long time to simulate.
Other methods for analyzing computer system performance include traditional debugging methods, such as inserting print statements into particular locations in a program. However, this approach is very time-consuming and can introduce inaccuracy into the performance measurement process by influencing the operation of the code being examined. Moreover, such print statements are difficult to use in embedded systems because the target processor on which the software is running must have an output port through which the print statements output their data.
Hardware analyzers, such as logic analyzers or digital oscilloscopes have been used to aid in debugging code and to analyze the performance of computer programs. Hardware analyzers are typically used to analyze computer system performance by monitoring processor bus cycles looking for occurrences of particular addresses or data words on a processor's address and data bus. Analyzing computer program performance in this way is a difficult if not impossible task, because it is difficult to correlate particular program instructions with corresponding processor bus activity.
One method for using a logic analyzer to debug computer program is disclosed in U.S. Pat. No. 5,450,586, entitled SYSTEM FOR ANALYZING AND DEBUGGING EMBEDDED SOFTWARE THROUGH DYNAMIC AND INTERACTIVE USE OF CODE MARKERS, by inventors Kuzara, et al. This patent discloses a system for inserting code markers into specific reserved locations at the entry and exit points of program modules. These code markers cause diagnostic data to be written to specific memory locations. A logic analyzer is connected to the address and data bus of a processor, and it records the references to the specific memory locations as the program runs on the processor.
This method has a number of disadvantages. It requires a logic analyzer to be connected to both a data bus and an address bus. In a 32bit system, this may require connecting a logic analyzer up as many as 80 pins. These pins may not be accessible in an embedded controller, in which address and data bus lines are not directly connected to external pins. Even if address and data bus lines are connected to external pins, such as in a microprocessor,the external pins may not be easily accessible if the microprocessor is housed in a standard pin grid array, in which hundreds of closely-spaced pins in a grid pattern protrude from the bottom of a semiconductor chip package. Connecting a logic analyzer to a pin grid array typically requires removing the pin grid array from its matching socket in the circuit board, inserting a special adaptor into the socket, and inserting the pin grid array into a matching socket on the opposite side of the adaptor. This process can be very time-consuming. It furthermore requires the computer system to be powered down and rebooted, which might destroy transitory computer system anomalies before they can be analyzed. Furthermore, monitoring a large number of pins requires time-consuming mapping of pins to address and data lines, as well as the complex process filtering of address patterns after triggering. Finally, buffer memory is typically limited in a logic analyzer, and recording the state of a large number of pins can consume a great amount of memory. Consequently, the logic analyzer can only record a limited number of data patterns.
The method disclosed in the above-mentioned patent also requires specific locations at entry and exit points of software routines to be reserved for the possible insertion of markers. Consequently, the method is not flexible because it only allows markers to be inserted at particular locations. The method also consumes a significant amount of memory because locations must be reserved even if markers are not placed in the locations. Memory space is of particular concern in microcontroller systems, in which memory is often extremely scarce. Providing additional memory locations for possible insertion of code markers also requires recompilation, which may affect the performance of the program in unpredictable ways.
Accordingly, prior art methods of analyzing computer program performance are excessively cumbersome, time-consuming, unreliable, or impracticable. What is needed is an efficient, non-intrusive method for measuring computer system performance, especially for embedded systems with limited memory resources.
The present invention makes it possible for programmers to analyze the performance of computer programs using a hardware analyzer in a manner that is both efficient and non-intrusive. The invention operates by inserting output sequences into a computer program. Those output sequences are sequences of computer instructions which cause the processor to send a pre-defined pattern through the data bus to an output terminal. A hardware analyzer or digital oscilloscope is connected to the output terminal through which it gathers data that is used to calculate the performance of the computer program. Output sequences can be inserted at almost any location in the computer program.
Output sequences can also be inserted into executable code as well as source code versions of the program. When an output sequence is inserted into executable code, it replaces a portion of the executable code with another piece of executable code which performs the same functions as the executable code that was replaced, and additionally causes the processor to send an output to the output terminal. In this way, executable code can be analyzed without the time-consuming and unpredictable process of recompiling the original source code from which the executable code was derived. Alternatively, if output sequences are embedded into source code, the source code is first recompiled into executable code, and this executable code is then monitored analyzed.
The present invention provides a number of advantages. (1) It facilitates accurate performance measurements in light of pre-fetching and caching operations. (2) It can operate on object code, so that no time-consuming and unpredictable recompilation of the source code is required. (3) The method operates by connecting a hardware analyzer, such as a logic state analyzer or a digital oscilloscope, to only a few external pins on the computer system instead of an entire address bus and data bus. This is convenient in embedded systems, device controllers or other microprocessor systems in which address and data bus lines are not accessible to a hardware analyzer. Furthermore, a simple hardware analyzer with only a few input lines can be used. (4) The present invention does not use large amounts of extra memory. This is an important feature in embedded systems in which extra memory may be unavailable. (5) The present invention allows output sequences to be located almost anywhere in the computer code, not just at entry and exit points to subroutines or functions. This allows a wider range of specific performance measurements to be taken.
Thus, the present invention can be characterized as a method for analyzing the performance of a computer program which operates in a computer system including: a processor, a memory, an output terminal, an address bus and a data bus, the data bus coupled to the processor, the memory and the output terminal. The method operates by: inserting an output sequence into the computer code, the output sequence causing the processor to send an output through the data bus to the output terminal; connecting a hardware analyzer to the output terminal; running the computer code; monitoring the output terminal with the hardware analyzer to gather data; and calculating the performance of the computer code from the gathered data.
According to one aspect of the present invention, the step of inserting the output sequence into the computer code includes replacing original instructions in the computer code with the output sequence. According to another aspect of the present invention, the output sequence can be inserted at any instruction in the computer code.
The present invention can also be characterized as an apparatus for measuring performance of a computer code, comprising: a processor; a memory; an output terminal positioned and shaped to receive a connection to a hardware analyzer; and a data bus coupled to the processor, the memory, and the output terminal; wherein the memory includes resources for inserting at least one output sequence into the computer code, the output sequence causing the processor to send an output through the data bus to the output terminal.
In one embodiment of the present invention, the output sent through the data bus to the output terminal includes information on the progress of the processor through subroutine and function calls in the computer code.
The present invention can also be characterized as an apparatus for measuring performance of computer code, comprising: a processor, a memory, a data bus coupled to the processor and the memory, and an output terminal coupled to the data bus, the output terminal positioned and shaped to receive a connection from a hardware analyzer. In one variation of this embodiment, the apparatus includes: an address decoder; an address bus coupled to the address decoder; and a selector coupled to the data bus, the address decoder and the output terminal, the selector establishing a signal path between the data bus and the output terminal when the address decoder detects a specific address on the address bus.
FIG. 1 is a block diagram illustrating how a computer system is connected to a hardware analyzer in accordance with an aspect of the present invention.
FIG. 2 is a flow chart illustrating the sequence of operations involved in analyzing performance of a computer program using a hardware analyzer in accordance with an aspect of the present invention.
FIG. 3 is a diagram illustrating how a section of executable code is replaced with an output sequence, which sends an output through the data bus to an output terminal in accordance with an aspect of the present invention.
FIG. 4 illustrates an example of how information regarding the progress of the processor through subroutines and functions can be passed through the output terminal to the hardware analyzer in accordance with an aspect of the present invention.
FIG. 5 is a diagram illustrating the structure of a dedicated output terminal for performance measurement which is positioned and shaped to receive a connection from a hardware analyzer in accordance with an aspect of the present invention.
FIG. 6 is a flow chart of a program which inserts output sequences into program code in accordance with an aspect of the present invention.
The following description is presented to enable a person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiments disclosed, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
FIG. 1 is a diagram illustrating how a computer system is connected to a hardware analyzer in accordance with an aspect of the present invention. Computer system 170 includes bus 110, which connects to CPU 100, register or LED 120 and memory 140. Computer system 170 is any type of computer system including a device controller, an embedded system, a microprocessor system, or any other general or special purpose computing system which includes a processor and memory. CPU 100 is any type of central processing unit, such as a central processor unit in a microprocessor, or a central processor unit implemented in another technology.
Register or LED 120 is any type of register or other computer component, such as an LED, which can relay output from bus 110 to hardware analyzer 130. Register or LED 120 need not contain a memory element, such as a latch or a register. It only needs to drive the contents of a data bus line from bus 110 onto output terminals 160.
FIG. 2 is a flowchart of the sequence of operations involved in measuring the performance of computer code in accordance with an aspect of the present invention. The systems starts at state 200, which is the start state. The system next proceeds to step 201.
At step 201, output sequences are inserted into the computer code. This can take place in a number of ways. If computer system 170 is a device controller or an embedded system without a display device or without sufficient memory space for the code to perform the insertion, the insertion takes place in a separate general purpose computing system. After the insertion is completed, the code with inserted output sequences 150 is loaded into memory 140. On the other hand, if computer system 170 has a display device and sufficient memory for software facilities to perform the insertion, this insertion can take place within computer system 170.
As mentioned above, this insertion takes place with the support of software to perform the insertion. In one embodiment, the insertion is performed by a system user through a debugger program. The system user manually inserts and moves specific instructions to insert the output sequence. In another embodiment, the insertion is performed by a system user through an in-circuit emulator (ICE). The system user selects strategic locations in the code, and subsequently executes the code using the in-circuit emulator. During the execution of the code, pre-defined patterns are written to output terminals when the strategic locations are reached. In yet another embodiment, a special software tool for insertion is used to locate and insert the output sequences into the code. This tool is described in more detail at a later point in this specification. The system then proceeds to step 202.
At step 202, hardware analyzer 130 is connected to output terminals 160. In one embodiment, output terminals 160 are any unused terminals of the computer system through which data can be outputted. This includes unused or reserved pins of a control register, or any other type of register. Alternatively, output terminals 160 are LED pins. In another embodiment, hardware analyzer 130 is connected to specially designed performance analysis output terminals, which are coupled to bus 110, and are positioned and shaped to receive a connection from hardware analyzer 130. The system then proceeds to step 204.
At step 204, code with inserted output sequences 150 has been loaded into memory 140. Code with inserted output sequences 150 is then run with a test input in order to test the performance of the code. The system then proceeds to step 206.
At step 206, hardware analyzer 130 monitors the output from output terminals 160 while the code is running. Hardware analyzer 130 is set to trigger on specific outputs to output terminals 160, which are generated by the output sequences within the code. These output sequences cause particular outputs to be written to register or LED 120, and ultimately to appear on output terminals 160. The system then proceeds to step 208.
At step 208, hardware analyzer 130 gathers data received by monitoring output terminals 160, and stores this data within a local buffer memory inside hardware analyzer 130. The amount of data that can be gather is limited by the memory capacity of hardware analyzer 130. The system then proceeds to step 210.
At step 210, the data which has been gathered is used to calculate a performance of the computer program. This performance can include execution time through different portions of a program, as well as a mapping of the execution pathway through the program. The system then proceeds to step 212 which an end state.
FIG. 3 illustrates a method for inserting an output sequence into a section of executable code in accordance with an aspect of the present invention. The original executable code is represented by the instructions on the left hand side of FIG. 3. In this example, Instructions BBB and CCC are replaced with an Instruction "jmp WWW." Note that "jmp WWW" takes the place of two instructions because the destination address WWW takes up an entire instruction word by itself. Instructions BBB and CCC are copied at location WWW, which is illustrated on the right-hand-side of FIG. 3. Additionally, after instructions BBB and CCC, there is an instruction to write a specified value to the output terminal. After the write operation, there is a jump to XXX, which is the location immediately following "jmp WWW." This returns the program to the location immediately following the inserted code to continue with program execution.
In another embodiment of the present invention, output sequences are inserted into the source code prior to compilation. In this case, replacement of executable instructions with output sequence instructions is not required because the compiler will rearrange the existing executable instructions to make room for the inserted output sequence instructions.
FIG. 4 illustrates how data sent to the output terminal can include information on the progress of the program through the subroutine and function calls in accordance with an aspect of a present invention. At the top of FIG. 4 are three functions: A, B and C. Function A starts with a call to T1-- HIGH, which causes output terminal T1 to assume a high value. Function A then executes other instructions including two calls to Function B. Finally, function A calls T1-- LOW, which causes output terminal T1 to assume a low value. Function B starts with a call to T2-- HIGH, which causes out terminal T2 to assume a high value. It then executes a number of instructions including a "for" loop, which repeatedly calls function C. Finally, function B calls T2-- LOW, which causes output terminal T2 to assume a low value. Function C starts by calling T3-- HIGH, which causes output terminal T3 to assume a high value. Function C then executes a number of instructions, and then calls function T3-- LOW, which causes output terminal T3 to assume a low value.
Output terminals T1, T2 and T3 are monitored by hardware analyzer 130 to produce the diagram at the bottom of FIG. 4. This diagram illustrates the progress of the program through functions A, B and C. At any point in this diagram, it is possible to determine the nesting of functions A, B and C at a particular point in the execution of the program. This is unlike other performance analysis techniques, which merely trigger on address locations, and consequently may not be able to determine the nesting of function calls during a particular address reference.
FIG. 5 illustrates an implementation of an output terminal for performance analysis in accordance with an aspect of the present invention. FIG. 5 includes address decoder 500, which takes address bus 530 as an input and generates an output which feeds into selector 510. Selector 510 takes an additional input from data bus 520 and produces an output which feeds into output terminals 560 and 562. In one embodiment, at least an output terminal is coupled to the data bus and the address bus through a combinatorial logic arrangement as known in the art. Output terminal 560 is positioned and shaped to receive a connection from probe 550, which connects to hardware analyzer 130. Output terminal 562 is positioned and shaped to receive a connection from connector 552, which also connects to hardware analyzer 130.
The structure illustrated in FIG. 5 operates as follows. CPU 100 generates a write to the address of output terminals 560 and 562. Address decoder 500 recognizes the address of this write operation and activates selector 510 to output the contents of specific lines from data bus 520 to output terminals 560 and 562. Output terminals 560 and 562 connect to probe 550 and connector 552 respectively. These connections enable hardware analyzer 130 to record the output from data bus 520. In one embodiment, selector 510 does not include a memory element, and a line from data bus 520 is driven onto output terminals 560 and 562, through probe 550 and connector 552, and into hardware analyzer 130 which records the output. In another embodiment, selector 510 includes a memory element, which records outputs from data bus 520.
Note that the embodiment illustrated in FIG. 5 includes two differently-shaped output terminals, 560 and 562, connected to the same output line. This illustrates the fact that a number of different output terminal shapes can be used. The only requirement is that an output terminal be shaped to connect to a probe or connector from hardware analyzer 130. Other embodiments include only a single output terminal for each output line. In another embodiment, selector 510 couples a plurality of lines from data bus 520 to a plurality of output lines and output terminals. These connect to a plurality of probes or connectors from hardware analyzer 130.
FIG. 6 is a flowchart illustrating the operation of a program to insert output sequences into a program in accordance with an aspect of a present invention. The system starts at state 600 which is a start state. The system next proceeds to step 601. At step 601, the system opens a code file and loads the opened file into memory. The system next proceeds to step 602. At step 602, the system outputs the code to a display, so that a user can view the code. The system includes user interface facilities, which allow the user to navigate through and selectively view different portions of the code. The system next proceeds to step 604. At step 604, the system accepts user input from a user. This user input specifies the location and pattern of output sequences to be inserted into the code. The system next proceeds to step 606. At step 606, the system inserts the output sequence into the specified location in the code. The system next proceeds to step 608. At step 608, the system determines if there are additional output sequences to be inserted into the code. If not, the system proceeds to step 610. If so, the system returns to step 602 to repeat the sequence of operations for an additional output sequence. Steps 602, 604, 606 and 608 are repeated as necessary to insert all of the desired output sequences. After steps 602, 604, 606 and 608 are complete, the system processed to step 610, in which the code with the inserted output sequences is saved back to the code file. The system next proceeds to step 612, which is an end state.
The foregoing description of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the invention to the forms disclosed. Many modifications and variations will be apparent to practitioners skilled in the art.
Claims (40)
1. A method for analyzing performance of a computer code, the method operating in a computer system including, a processor, a memory, an output terminal, an address bus, and a data bus coupled to the processor, the memory and the output terminal, the method comprising the steps of:
inserting at least one output sequence into the computer code, the output sequence including a plurality of instructions which cause the processor to send an output through the data bus to the output terminal;
connecting a hardware analyzer to the output terminal;
running the computer code without recompilation;
monitoring the output terminal with the hardware analyzer to gather data; and
calculating from the data a performance of the computer code.
2. The method of claim 1, wherein the step of inserting at least one output sequence into the computer code includes replacing an original instruction in the computer code with the at least one output sequence.
3. The method of claim 1, wherein in the step of inserting at least one output sequence into the computer code, the at least one output sequence can be inserted at any instruction in the computer code.
4. The method of claim 1, wherein in the step of inserting at least one output sequence into the computer code, the at least one output sequence is located at entry and exit points of functions in the computer code.
5. The method of claim 1, wherein the step of inserting at least one output sequence into the computer code is performed by a debugger program in the memory.
6. The method of claim 1, wherein the step of running the computer code is performed by an in-circuit emulator.
7. The method of claim 1, including the step of receiving user input into the computer system from a computer user, and wherein the step of inserting the at least one output sequence into the computer code uses the user input to determine where to insert the at least one output sequence into the computer code.
8. The method of claim 1, wherein the computer code is in executable form, and the step of inserting inserts the at least one output sequence into the computer code in executable form.
9. The method of claim 1, wherein:
the computer code is in executable form; and
in the step of inserting the at least one output sequence into the computer code, the inserting replaces an original instruction in the computer code with an output sequence which causes the processor to send an output to the output terminal and to execute the original instruction.
10. The method of claim 1, wherein:
the computer code is in executable form; and
in the step of inserting the at least one output sequence into the computer code, the inserting replaces an original instruction in the computer code with a part of an output sequence in the at least one output sequence, the output sequence including,
a first jump instruction to jump to an outside location outside of the computer code,
a copy of the original instruction at the outside location to perform the functions of the original instruction,
an output instruction at the outside location, which causes the processor to send an output to the output terminal, and
a second jump instruction at the outside location to jump back to a location immediately following the first jump instruction.
11. The method of claim 1, wherein the output terminal includes a plurality of output terminals.
12. The method of claim 1, wherein the output terminal includes fewer than eight output terminals.
13. The method of claim 1, wherein the output terminal connects directly to the data bus.
14. The method of claim 1, wherein the output terminal includes an unused output pin of a register coupled to the data bus.
15. The method of claim 1, wherein the output terminal is coupled to the data bus and the address bus through combinatorial logic.
16. The method of claim 1, wherein the output terminal is used only for purposes of performance analysis and debugging.
17. The method of claim 1, wherein the data gathered by the hardware analyzer includes timing information.
18. The method of claim 1, wherein the output sent through the data bus to the output terminal includes information on the progress of the processor through subroutine and functions calls in the computer code.
19. A method for analyzing performance of a computer code, the method operating in a computer system including, a processor, a memory, an output terminal, an address bus, and a data bus coupled to the processor, the memory and the output terminal, the method comprising the steps of:
inserting output sequences into the computer code, the output sequences including a plurality of instructions which cause the processor to send outputs through the data bus to the output terminal, wherein the output terminal is coupled to the data bus through a selector, the outputs including outputs regarding entry and exit of functions in the computer code;
connecting a hardware analyzer to the output terminal;
running the computer code;
monitoring the output terminal with the hardware analyzer to gather data; and
calculating from the data a performance of the computer code;
wherein:
the computer code is in source code form;
the step of inserting inserts the output sequences into the computer code in source code form; and
the method includes the step of compiling the computer code into executable form.
20. A method for analyzing performance of a computer code, the method operating in a computer system including, a processor, a memory, an output terminal, an address bus, and a data bus coupled to the processor, the memory and the output terminal, the method comprising the steps of:
inserting at least one output sequence into the computer code by replacing an original instruction in the computer code with the at least one output sequence, the output sequence including a plurality of instructions which cause the processor to send an output through the data bus to the output terminal;
receiving user input into the computer system from a computer user, the user input being used to determine where to insert the at least one output sequence into the computer code, connecting a hardware analyzer to the output terminal;
running the computer code without recompilation;
monitoring the output terminal with the hardware analyzer to gather data including timing information; and
calculating from the data a performance of the computer code.
21. An apparatus for measuring performance of a computer code, comprising:
a processor;
a memory;
an output terminal positioned and shaped to receive a connection to a hardware analyzer; and
a data bus coupled to the processor, the memory and the output terminal;
wherein the memory includes resources that insert at least one output sequence into the computer code, the output sequence including a plurality of instructions which cause the processor to send an output through the data bus to the output terminal;
wherein the resources that insert at least one output sequence into the computer code include resources that replace an original instruction in the computer code with the at least one output sequence.
22. The apparatus of claim 21, wherein the memory includes a semiconductor memory and disk drive.
23. The apparatus of claim 21, wherein the resources that insert at least one output sequence into the computer code include resources which allow the at least one output sequence to be inserted at any instruction in the computer code.
24. The apparatus of claim 21, wherein the resources that insert the at least one output sequence into the computer code include resources to locate the at least one output sequence at entry and exit points of functions in the computer code.
25. The apparatus of claim 21, wherein the resources that insert the at least one output sequence into the computer code are within a debugger program in the memory.
26. The apparatus of claim 21, wherein the resources that insert the at least one output sequence into the computer code are within an in-circuit emulator.
27. The apparatus of claim 21, including a user interface for receiving input into the computer system from a computer user, and wherein the resources that insert the at least one output sequence into the computer code include resources which use the user input to determine where to insert the at least one output sequence into the computer code.
28. The apparatus of claim 21, wherein the computer code is in executable form, and the resources that insert the at least one output sequence into the computer code include resources to insert the at least one output sequence into the computer code in executable form.
29. The apparatus of claim 21, wherein:
the computer code is in executable form; and
the resources that insert the at least one output sequence into the computer code include resources that replace an original instruction in the computer code with an output sequence which causes the processor to send output to the output terminal and to execute the original instruction.
30. The apparatus of claim 21, wherein:
the computer code is in executable form; and
the resources that insert the at least one output sequence into the computer code include resources to replace an original instruction in the computer code with an output sequence in the at least one output sequence, the output sequence including,
a first jump instruction to jump to an outside location outside of the computer code,
a copy of the original instruction at the outside location to perform the functions of the original instruction,
an output instruction at the outside location, which causes the processor to send an output to the output terminal, and
a second jump instruction at the outside location to jump back to a location immediately following the first jump instruction.
31. The apparatus of claim 21, wherein the output terminal includes a plurality of output terminals.
32. The apparatus of claim 21, wherein the output terminal includes fewer than eight output terminals.
33. The apparatus of claim 21, wherein the output terminal connects directly the data bus.
34. The apparatus of claim 21, wherein the output terminal includes an output pin of an unused bit in a register coupled to the data bus.
35. The apparatus of claim 21, wherein the output terminal is coupled to the data bus and the address bus through combinatorial logic.
36. The apparatus of claim 21, wherein the output terminal is used only for purposes of performance analysis and debugging.
37. The method of claim 21, wherein the output sent through the data bus to the output terminal includes information on the progress of the processor through subroutine and functions calls in the computer code.
38. An apparatus for measuring performance of a computer code, comprising:
a processor;
a memory;
an output terminal positioned and shaped to receive a connection to a hardware analyzer; and
a data bus coupled to the processor, the memory and the output terminal, wherein the output terminal is coupled to the data bus through a selector;
wherein the memory includes resources that insert output sequences into the computer code, the output sequence including a plurality of instructions which cause the processor to send outputs through the data bus to the output terminal, the outputs including outputs regarding entry and exit of functions in the computer code;
wherein:
the computer code is in the source form;
the resources that insert the output sequences into the computer code insert the output sequences into the computer code in source code form; and
including resources that compile the computer code into executable form.
39. An apparatus for measuring performance of a computer code, comprising:
a processor:
a memory;
a data bus coupled to the processor and the memory;
an output terminal coupled to the data bus, the output terminal positioned and shaped to receive a connection from a hardware analyzer;
an address decoder;
an address bus coupled to the, address decoder; and
a selector coupled to the data bus, the decoder and the output terminal, the selector establishing a signal path between the data bus and the output terminal when the address decoder detects a desired address on the address bus.
40. A method for analyzing performance of a computer code, the method operating in a computer system including, a processor, a memory, an output terminal, an address bus, and a data bus coupled to the processor, the memory and the output terminal, the method comprising the steps of:
inserting at least one output sequence into the computer code, the output sequence including a plurality of instructions which cause the processor to send an output through the data bus to the output terminal;
connecting a hardware analyzer to the output terminal;
running the computer code;
monitoring the output terminal with the hardware analyzer to gather data; and
calculating from the data a performance of the computer code;
wherein the step of inserting at least one output sequence into the computer code includes replacing an original instruction in the computer code with the at least one output sequence.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/868,573 US5903759A (en) | 1997-06-04 | 1997-06-04 | Software performance analysis using hardware analyzer |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/868,573 US5903759A (en) | 1997-06-04 | 1997-06-04 | Software performance analysis using hardware analyzer |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| US5903759A true US5903759A (en) | 1999-05-11 |
Family
ID=25351944
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| US08/868,573 Expired - Lifetime US5903759A (en) | 1997-06-04 | 1997-06-04 | Software performance analysis using hardware analyzer |
Country Status (1)
| Country | Link |
|---|---|
| US (1) | US5903759A (en) |
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6212652B1 (en) * | 1998-11-17 | 2001-04-03 | Sun Microsystems, Inc. | Controlling logic analyzer storage criteria from within program code |
| US6311327B1 (en) * | 1998-03-02 | 2001-10-30 | Applied Microsystems Corp. | Method and apparatus for analyzing software in a language-independent manner |
| US6389370B1 (en) * | 1999-09-14 | 2002-05-14 | Hewlett-Packard Company | System and method for determining which objects in a set of objects should be processed |
| WO2002056173A1 (en) * | 2001-01-10 | 2002-07-18 | Desoc Technology Inc. | Methods and apparatus for deep embedded software development |
| US20020198983A1 (en) * | 2001-06-26 | 2002-12-26 | International Business Machines Corporation | Method and apparatus for dynamic configurable logging of activities in a distributed computing system |
| US20030159133A1 (en) * | 2001-10-26 | 2003-08-21 | International Business Machines Corporation | Method and system for tracing and displaying execution of nested functions |
| WO2003088039A2 (en) * | 2002-04-15 | 2003-10-23 | Giesecke & Devrient Gmbh | Optimisation of a compiler generated program code |
| US20050066234A1 (en) * | 2003-09-24 | 2005-03-24 | International Business Machines Corporation | Method and system for identifying errors in computer software |
| US6973417B1 (en) | 1999-11-05 | 2005-12-06 | Metrowerks Corporation | Method and system for simulating execution of a target program in a simulated target system |
| US20060174072A1 (en) * | 2005-02-01 | 2006-08-03 | Mcfarland Bernard M | Electronic control unit analysis |
| US20090049340A1 (en) * | 2007-08-15 | 2009-02-19 | Oki Electric Industry Co., Ltd. | System analysis device and computer readable storage medium storing system analysis program |
| US20100257506A1 (en) * | 2004-09-20 | 2010-10-07 | The Mathworks, Inc. | Providing block state information for a model based development process |
| US20110214108A1 (en) * | 2010-02-26 | 2011-09-01 | Roland Grunberg | Architecture, system and method for generating visualizations from running executable code |
| US20160274991A1 (en) * | 2015-03-17 | 2016-09-22 | Qualcomm Incorporated | Optimization of Hardware Monitoring for Computing Devices |
| CN111813677A (en) * | 2020-07-09 | 2020-10-23 | 杭州优万科技有限公司 | Performance debugging method on embedded equipment |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5228039A (en) * | 1990-05-09 | 1993-07-13 | Applied Microsystems Corporation | Source-level in-circuit software code debugging instrument |
| US5371689A (en) * | 1990-10-08 | 1994-12-06 | Fujitsu Limited | Method of measuring cumulative processing time for modules required in process to be traced |
| US5450586A (en) * | 1991-08-14 | 1995-09-12 | Hewlett-Packard Company | System for analyzing and debugging embedded software through dynamic and interactive use of code markers |
| US5491793A (en) * | 1992-07-31 | 1996-02-13 | Fujitsu Limited | Debug support in a processor chip |
| US5581695A (en) * | 1990-05-09 | 1996-12-03 | Applied Microsystems Corporation | Source-level run-time software code debugging instrument |
| US5604895A (en) * | 1994-02-22 | 1997-02-18 | Motorola Inc. | Method and apparatus for inserting computer code into a high level language (HLL) software model of an electrical circuit to monitor test coverage of the software model when exposed to test inputs |
| US5611044A (en) * | 1993-11-01 | 1997-03-11 | Hewlett-Packard Company | System and method for cross-triggering a software logic analyzer and a hardware analyzer |
| US5615332A (en) * | 1993-12-21 | 1997-03-25 | Mitsubishi Denki Kabushiki Kaisha | Debugging aid apparatus |
| US5724505A (en) * | 1996-05-15 | 1998-03-03 | Lucent Technologies Inc. | Apparatus and method for real-time program monitoring via a serial interface |
| US5748878A (en) * | 1995-09-11 | 1998-05-05 | Applied Microsystems, Inc. | Method and apparatus for analyzing software executed in embedded systems |
| US5754759A (en) * | 1993-09-29 | 1998-05-19 | U.S. Philips Corporation | Testing and monitoring of programmed devices |
-
1997
- 1997-06-04 US US08/868,573 patent/US5903759A/en not_active Expired - Lifetime
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5228039A (en) * | 1990-05-09 | 1993-07-13 | Applied Microsystems Corporation | Source-level in-circuit software code debugging instrument |
| US5581695A (en) * | 1990-05-09 | 1996-12-03 | Applied Microsystems Corporation | Source-level run-time software code debugging instrument |
| US5371689A (en) * | 1990-10-08 | 1994-12-06 | Fujitsu Limited | Method of measuring cumulative processing time for modules required in process to be traced |
| US5450586A (en) * | 1991-08-14 | 1995-09-12 | Hewlett-Packard Company | System for analyzing and debugging embedded software through dynamic and interactive use of code markers |
| US5491793A (en) * | 1992-07-31 | 1996-02-13 | Fujitsu Limited | Debug support in a processor chip |
| US5754759A (en) * | 1993-09-29 | 1998-05-19 | U.S. Philips Corporation | Testing and monitoring of programmed devices |
| US5611044A (en) * | 1993-11-01 | 1997-03-11 | Hewlett-Packard Company | System and method for cross-triggering a software logic analyzer and a hardware analyzer |
| US5615332A (en) * | 1993-12-21 | 1997-03-25 | Mitsubishi Denki Kabushiki Kaisha | Debugging aid apparatus |
| US5604895A (en) * | 1994-02-22 | 1997-02-18 | Motorola Inc. | Method and apparatus for inserting computer code into a high level language (HLL) software model of an electrical circuit to monitor test coverage of the software model when exposed to test inputs |
| US5748878A (en) * | 1995-09-11 | 1998-05-05 | Applied Microsystems, Inc. | Method and apparatus for analyzing software executed in embedded systems |
| US5724505A (en) * | 1996-05-15 | 1998-03-03 | Lucent Technologies Inc. | Apparatus and method for real-time program monitoring via a serial interface |
Cited By (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6311327B1 (en) * | 1998-03-02 | 2001-10-30 | Applied Microsystems Corp. | Method and apparatus for analyzing software in a language-independent manner |
| US6658651B2 (en) | 1998-03-02 | 2003-12-02 | Metrowerks Corporation | Method and apparatus for analyzing software in a language-independent manner |
| US6212652B1 (en) * | 1998-11-17 | 2001-04-03 | Sun Microsystems, Inc. | Controlling logic analyzer storage criteria from within program code |
| US6389370B1 (en) * | 1999-09-14 | 2002-05-14 | Hewlett-Packard Company | System and method for determining which objects in a set of objects should be processed |
| US6973417B1 (en) | 1999-11-05 | 2005-12-06 | Metrowerks Corporation | Method and system for simulating execution of a target program in a simulated target system |
| WO2002056173A1 (en) * | 2001-01-10 | 2002-07-18 | Desoc Technology Inc. | Methods and apparatus for deep embedded software development |
| US20020198983A1 (en) * | 2001-06-26 | 2002-12-26 | International Business Machines Corporation | Method and apparatus for dynamic configurable logging of activities in a distributed computing system |
| US7120685B2 (en) * | 2001-06-26 | 2006-10-10 | International Business Machines Corporation | Method and apparatus for dynamic configurable logging of activities in a distributed computing system |
| US20030159133A1 (en) * | 2001-10-26 | 2003-08-21 | International Business Machines Corporation | Method and system for tracing and displaying execution of nested functions |
| US7120901B2 (en) * | 2001-10-26 | 2006-10-10 | International Business Machines Corporation | Method and system for tracing and displaying execution of nested functions |
| US7805718B2 (en) | 2002-04-15 | 2010-09-28 | Giesecke & Devrient Gmbh | Optimisation of a compiler generated program code |
| WO2003088039A3 (en) * | 2002-04-15 | 2004-11-04 | Giesecke & Devrient Gmbh | Optimisation of a compiler generated program code |
| US20050235268A1 (en) * | 2002-04-15 | 2005-10-20 | Michael Baldischweiler | Optimisation of a compiler generated program code |
| WO2003088039A2 (en) * | 2002-04-15 | 2003-10-23 | Giesecke & Devrient Gmbh | Optimisation of a compiler generated program code |
| US20050066234A1 (en) * | 2003-09-24 | 2005-03-24 | International Business Machines Corporation | Method and system for identifying errors in computer software |
| US7168009B2 (en) * | 2003-09-24 | 2007-01-23 | International Business Machines Corporation | Method and system for identifying errors in computer software |
| US8527941B2 (en) * | 2004-09-20 | 2013-09-03 | The Mathworks, Inc. | Providing block state information for a model based development process |
| US20100257506A1 (en) * | 2004-09-20 | 2010-10-07 | The Mathworks, Inc. | Providing block state information for a model based development process |
| US20060174072A1 (en) * | 2005-02-01 | 2006-08-03 | Mcfarland Bernard M | Electronic control unit analysis |
| US7296123B2 (en) * | 2005-02-01 | 2007-11-13 | Delphi Technologies, Inc. | Electronic control unit analysis |
| US20090049340A1 (en) * | 2007-08-15 | 2009-02-19 | Oki Electric Industry Co., Ltd. | System analysis device and computer readable storage medium storing system analysis program |
| US20110214108A1 (en) * | 2010-02-26 | 2011-09-01 | Roland Grunberg | Architecture, system and method for generating visualizations from running executable code |
| US9047399B2 (en) * | 2010-02-26 | 2015-06-02 | Red Hat, Inc. | Generating visualization from running executable code |
| US20160274991A1 (en) * | 2015-03-17 | 2016-09-22 | Qualcomm Incorporated | Optimization of Hardware Monitoring for Computing Devices |
| US9658937B2 (en) * | 2015-03-17 | 2017-05-23 | Qualcomm Incorporated | Optimization of hardware monitoring for computing devices |
| CN111813677A (en) * | 2020-07-09 | 2020-10-23 | 杭州优万科技有限公司 | Performance debugging method on embedded equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5903759A (en) | Software performance analysis using hardware analyzer | |
| US7478281B2 (en) | System and methods for functional testing of embedded processor-based systems | |
| KR100522193B1 (en) | Microprocessor-based device incorporating a cache for capturing software performance profiling data | |
| KR20210116604A (en) | Automated test equipment using on-chip-system test controllers | |
| US6032268A (en) | Processor condition sensing circuits, systems and methods | |
| EP0567722B1 (en) | System for analyzing and debugging embedded software through dynamic and interactive use of code markers | |
| US5748878A (en) | Method and apparatus for analyzing software executed in embedded systems | |
| US6430741B1 (en) | System and method for data coverage analysis of a computer program | |
| US6658651B2 (en) | Method and apparatus for analyzing software in a language-independent manner | |
| US5329471A (en) | Emulation devices, systems and methods utilizing state machines | |
| US8180620B2 (en) | Apparatus and method for performing hardware and software co-verification testing | |
| KR100546087B1 (en) | Trace cache for a microprocessor-based device | |
| US5265254A (en) | System of debugging software through use of code markers inserted into spaces in the source code during and after compilation | |
| US6704895B1 (en) | Integrated circuit with emulation register in JTAG JAP | |
| CA2332650C (en) | Software analysis system having an apparatus for selectively collecting analysis data from a target system executing software instrumented with tag statements and method for use thereof | |
| EP0084431A2 (en) | Monitoring computer systems | |
| US7404178B2 (en) | ROM-embedded debugging of computer | |
| JP4959941B2 (en) | Interactive software probing | |
| CN117787155B (en) | Chip testability code dynamic simulation test system and test method | |
| EP1782204A2 (en) | Emulation and debug interfaces for testing an integrated circuit with an asynchronous microcontroller | |
| US20040250150A1 (en) | Devices, systems and methods for mode driven stops notice | |
| US7441158B1 (en) | Embedded hardware debugging tool and associated method | |
| US6442725B1 (en) | System and method for intelligent analysis probe | |
| US6425122B1 (en) | Single stepping system and method for tightly coupled processors | |
| US20060074625A1 (en) | Program development suport device, program execution device, compile method and debug method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AS | Assignment |
Owner name: 3COM CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SUN, TSYR-SHYA JOE;LEU, DAR-REN;REEL/FRAME:008939/0043 Effective date: 19971119 |
|
| STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
| FPAY | Fee payment |
Year of fee payment: 4 |
|
| FPAY | Fee payment |
Year of fee payment: 8 |
|
| AS | Assignment |
Owner name: HEWLETT-PACKARD COMPANY, CALIFORNIA Free format text: MERGER;ASSIGNOR:3COM CORPORATION;REEL/FRAME:024630/0820 Effective date: 20100428 |
|
| AS | Assignment |
Owner name: HEWLETT-PACKARD COMPANY, CALIFORNIA Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE SEE ATTACHED;ASSIGNOR:3COM CORPORATION;REEL/FRAME:025039/0844 Effective date: 20100428 |
|
| FPAY | Fee payment |
Year of fee payment: 12 |
|
| AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:027329/0044 Effective date: 20030131 |
|
| AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: CORRECTIVE ASSIGNMENT PREVIUOSLY RECORDED ON REEL 027329 FRAME 0001 AND 0044;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:028911/0846 Effective date: 20111010 |
|
| AS | Assignment |
Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:037079/0001 Effective date: 20151027 |