Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
1999-09-29
2004-08-31
Chavis, John (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C714S038110
Reexamination Certificate
active
06785884
ABSTRACT:
FIELD OF THE INVENTION
The present invention is related generally to computers. More specifically, the present invention is related to debugging software for debugging computer code.
BACKGROUND OF THE INVENTION
Computers have a history and current scope extending much further than the personal computers which are more visible to the general public. Mid-range and large mainframe computers are far from obsolete, having many advantages over personal computers. Some advantages can include well tested operating systems, special purpose operating systems, robust fault tolerant operating systems, multiple processor support, redundancy support, reliability, real time operating systems, high throughput transaction processing support, multiple busses, and built in support for database management functionality.
One example of mainframe use includes transaction processing for banking transactions, automatic teller machine transactions, and electronic commercial transactions. Transaction processing requires robust, accurate, and predictable execution of tasks to avoid performing a task more or less than the desired number of times in the case of a failure. Real time processing can require graceful degradation of services when a component fails. Many of these features are promised for personal computers but have not been delivered, as evidenced by less than graceful and less than infrequent personal computer hangs and crashes.
Over a long period, even 20 or 30 years, many utilities and tools have been developed and incrementally improved upon to aid the users and vendors of such legacy computers. One set of tools includes simulators and debuggers. Simulators can simulate the execution of computer code, including machine code. Sometimes it is advantageous to provide a simulator a legacy computer to simulate the execution of the native machine code, rather than running the code directly on the legacy computer.
Simulation or emulation often involves step-by-step simulation of execution of native machine code by a typically larger number of machine code instructions. For example, 4 bytes of machine code, 0106 A34F, representing LOAD REGISTER 6 with the literal 16 bit hex number A34F may be simulated by 2 lines of a higher level language such as “C” and executed by 50 bytes of machine code. The simulator may include routines for accepting the machine code 0106 A34F and decompiling to generate a text string such as “LDIR6 0xA34F”. The text string generation can provide a meaningful text string for any human using the tools. A compiler having symbolic debugging support can generate a cross-reference table relating high level source code to machine code.
Single-stepping a mainframe can be highly impractical, given the number of users normally supported. Even momentary use of an actual machine, having the state saved and restored, can require momentary use of the entire machine as the task to be debugged is single-stepped through one machine instruction. This can require a relatively large amount of overhead to save the entire machine state, execute one machine instruction, and restore the machine state. By using a simulator, the simulation task can be run as any other, non-privileged task, as the actual CPU and memory is not being executed, only a simulated version of the CPU and memory. Thus, even when machine code is being debugged on the same machine on which it is eventually to be run, use of a simulator allows for less intrusive access to the machine, which may be running other tasks.
Personal computers and workstations are ubiquitous and relatively inexpensive compared to legacy computers. The large numbers of machines sold creates a market enabling large numbers of software titles to be sold. In particular, pleasing and user friendly graphical window systems and graphical user interfaces (GUIs) have been developed and the cost spread over several million machines and computer programs sold. The large personal computer market makes development of programming and debugging tools economically feasible. In particular, symbolic debuggers and simulators having pop-up windows have been developed for personal computers and workstations. Debugging and single-stepping of computer programs can be performed in a cubicle on an inexpensive personal computer, and the results saved into files and even e-mailed or shared on a network, using other tools commonly found on a personal computer.
In contrast, debugging and simulator tools written for legacy computers have not been able to take advantage of the large number of tools for the personal computer. For example, a financial transaction processing mainframe typically does not run compatible with the Microsoft Windows™ operating system. While a windows type environment could be developed for the mainframe, the cost would have to be spread over a smaller number of machines and would not likely be a high priority project in any case. While a mainframe compiler and simulator could be developed to generate and simulate mainframe machine code on a personal computer, the cost would have to be spread over a small number of users, likely internal users. Such a product is not likely to be developed due to lack of market interest and market priorities.
What would be desirable therefore, is a system for utilizing existing personal computer tools and GUIs in combination with existing mainframe compilers, symbolic debuggers, and simulators. What would be advantageous are methods and software tools for debugging mainframe computer code on a personal computer or workstation using debugging tools residing on the mainframe.
SUMMARY OF THE INVENTION
The present invention includes a system for simulating a computer program in a first computer while controlling the simulation in a second computer. The first computer can include a compiler for compiling a high level source language module to a machine code binary module and a decompiler for decompiling the machine code binary module into human readable computer machine language text. The computer machine language can also be referred to as assembly language or a register transfer language. The computer machine language text can be assembled into the machine code binary in some embodiments and exists only for human reading in other embodiments. In some cases, the high level source language is compiled into a machine language, and is then compiled into a machine code binary. In these embodiments, a decompiler may not be desired unless decompilation to computer machine language on the fly is desired.
The first computer can also include an interactively driven simulator-debugger capable of simulating or emulating the execution of the machine code instructions in the machine code binary module. The simulator-debugger preferably includes a message receiver for receiving externally generated commands for controlling the simulator. Commands can include commands referencing either high level source language position, machine language position, or machine code binary position. In one embodiment, commands can be received referencing either high level language position or computer machine language position and respond in both high level language position and machine language position. This can enable windows displaying either high level or machine language to follow the simulated execution of the machine code binary. In one application, break point positions are received in either a high level language position or a machine language position, and, after the breakpoint is set, the status is reported back referencing both high level and machine language positions.
Preferably, a graphical user interface (GUI) is used to generate computer display windows including a high level language debugging window, a machine language debugging window, and a batch command window, primarily for initiating file transfers and loading of the simulator-debugger. In one embodiment, the GUI resides on the same computer as the simulator-debugger. In another embodiment, the GUI resides on a computer different from the computer executing the simulator debugger. In
Chavis John
Crompton Seager & Tufte LLC
Johnson Charles A.
Starr Mark T.
Unisys Corporation
LandOfFree
Symbolic debug interface for register transfer simulator... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Symbolic debug interface for register transfer simulator..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Symbolic debug interface for register transfer simulator... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3268812