Virtual type interpretation, interaction and detection Number:7,434,205 from the United States Patent and Trademark Office (PTO) owispatent Interpretation of virtual types in a software development, debugging, or monitoring environment. Display and modification of variables having virtual types. Detection of virtual types.<H interpretation, interaction, Virtual, type, in, 7434205.html, Patent, pto, 7434205

Title: Virtual type interpretation, interaction and detection

Abstract: Interpretation of virtual types in a software development, debugging, or monitoring environment. Display and modification of variables having virtual types. Detection of virtual types.

Patent Number: 7,434,205 Issued on 10/07/2008 to Steenhagen, et al.

Inventors: Steenhagen; Shawn K. (Cottage Grove, WI), Trantow; Jerry J. (Cross Plains, WI), Allie; Mark C. (Stoughton, WI)
Appl. No.: 11/061,113

Filed: February 18, 2005

Related U.S. Patent Documents


Application Number	Filing Date	Patent Number	Issue Date
60546450	Feb., 2004

Current U.S. Class: 717/124 ; 717/105; 717/113; 717/117

Current International Class: G06F 9/44 (20060101)

Field of Search: 717/100-135

References Cited [Referenced By]

U.S. Patent Documents


5228039	July 1993	Knoke
5479652	December 1995	Dreyer
5488688	January 1996	Gonzales
5524244	June 1996	Robinson
5557557	September 1996	Frantz
5590354	December 1996	Klapproth
5768152	June 1998	Battaline
5771240	June 1998	Tobin
5828824	October 1998	Swoboda
5884023	March 1999	Swoboda
5933641	August 1999	Ma
5941991	August 1999	Kageshima
5950000	September 1999	O'Leary
5968188	October 1999	Rana
5983017	November 1999	Kemp
6041406	March 2000	Mann
6079032	June 2000	Peri
6185732	February 2001	Mann
6240549	May 2001	Hamada
6249909	June 2001	Russo
6311292	October 2001	Choquette
6327703	December 2001	O'Donnell et al.
6338025	January 2002	Bowen
6493868	December 2002	DaSilva
6543048	April 2003	Kuzemchak
6553502	April 2003	Hurd
7107578	September 2006	Alpern
2001/0042069	November 2001	Petrov et al.
2002/0129337	September 2002	Evans et al.
2003/0115584	June 2003	Fahs et al.
2003/0145310	July 2003	Thames et al.
2004/0003385	January 2004	Kushlis
2004/0158812	August 2004	Dye et al.
2006/0064673	March 2006	Rogers et al.
2006/0143570	June 2006	Washington et al.

Other References

Presence in virtual environments as a function of visual and auditory cues, Hendrix, C.; Barfield, W., Virtual Reality Annual International Symposium, 1995. Proceedings, Mar. 11-15, 1995, IEEE, pp. 74-82. cited by examiner .
Virtual Data Visualizer, van Teylingen, R.; Ribarsky, W.; van der Mast, C., Transactions on Visualization and Computer Graphics, vol. 3 Issue: 1 Jan.-Mar. 1997, IEEE, pp. 65-74. cited by examiner .
The general variables concept: a simple step from single- to multi-user environment, Masa, M.; Zara, J.; 2001, IEEE, pp. 584-588. cited by examiner .
An object oriented model of behavior encoded virtual tools, Kesavadas, T.; Subramanium, H.V., 1998 IEEE, vol. 1, pp. 338-343. cited by examiner .
Stevenson, "Texas Instruments Application Report, Q-Values in the Watch Window," literature No. SPRU321, Feb. 2002. cited by other .
Code Composer Studio Application Programming Interface (API) Reference Guide (Texas Instruments literature No. SPRU321) (Oct. 2001). cited by other .
Code Composer Studio Software Developer's Kit User's Guide (Texas Instruments literature No. SPRU320) (Oct. 2001). cited by other .
Siegel, CORBA Fundamentals and Programming, (John Wiley & Sons 1996). cited by other .
Chappell, Understanding ActiveX and OLE, (Microsoft Press 1996). cited by other .
Brockschmidt, Inside OLE (2d ed. Microsoft Press 1995). cited by other .
Denning, OLE Controls Inside Out (Microsoft 1995). cited by other .
IQ Math Library, Module User's Guide v. 1.4.1 (Texas Instruments, Jun. 2002). cited by other.

Primary Examiner: Zhen; Wei Y.
Assistant Examiner: Rampuria; Satish S

Parent Case Text

CROSS REFERENCE TO PROVISIONAL APPLICATION

This application claims the benefit of provisional application Ser. No. 60/546,450 (entitled "Virtual Type Interpretation, Interaction, and Detection"), filed Feb. 19, 2004, and which is hereby fully incorporated by reference.

Claims

What is claimed is:

1. A method of displaying information using a development tool in a software development environment, the method comprising the acts of: determining a virtual type for each of a plurality of variables in a development project, each of the plurality of variables also having a native type, and where for each of the plurality of variables, the virtual type is interpreted differently than the native type; storing associations between the plurality of variables and their determined virtual types; providing a graphical user interface for displaying one or more of the variables in the development project, wherein the graphical user interface displays the interpreted value of information stored at a memory location associated with each of the one or more variables as determined by the virtual type associated with each of the one or more variables; detecting that the user has interacted with the graphical user interface to change the virtual type associated with a displayed variable to a new virtual type; in response to detecting that the user has interacted with the graphical user interface to change the virtual type associated with the displayed variable to the new virtual type, storing an association between the displayed variable and the new virtual type; and updating the graphical user interface to reflect the new interpretation of the information stored at the memory location associated with the displayed variable; and enabling the user to interact with the graphical user interface to change the information stored at the memory location associated with the displayed variable, where the information stored at the memory location associated with the displayed variable is changed by the user specifying a new value for the displayed variable as interpreted by its virtual type, thereby causing the information stored at the memory location associated with the displayed variable to be updated so that the displayed variable is interpreted according to its virtual type, the displayed information is consistent with the new value specified by the user.

2. The method of claim 1, further comprising the act of: detecting that the user has interacted with the graphical user interface to change information stored at a memory location associated with a displayed variable, where the information stored at the memory location can be modified through the user specifying a new value for the displayed variable as it is to be interpreted in the virtual type associated with the displayed variable, and where the information stored at the memory location is stored so that when the stored information is interpreted according to its virtual type, the displayed variable has a value consistent with the new value specified by the user.

3. The method of claim 2, where the user specifies a new value for the displayed variable as a floating point value in the Q-type associated with the displayed variable.

4. The method of claim 1, where the new virtual type associated with the displayed variable is a Q-type having an associated Q value.

5. The method of claim 1, where the operation of providing a graphical user interface for displaying one or more of the variables in the development project includes the operation of: displaying a watch window during a debug mode in the software development environment so that the value of the one or more variables can be monitored during debug execution of a computer program.

6. The method of claim 1, where the operation of determining a virtual type for each of a plurality of variables includes the operation of: accepting input from the user specifying the appropriate virtual type for one of the plurality of variables.

7. The method of claim 1, where the one or more variables includes a Q-type variable, where the graphical user interface displays the floating point equivalent of the Q-type variable, and where more than one Q value is represented among a plurality of Q-type virtual types for the plurality of variables.

8. A computer that is operated by a user, where the computer is programmed to be capable of carrying out operations comprising: determining a virtual type for each of a plurality of variables in a development project, where each of the plurality of variables also has a native type that is interpreted differently than its virtual type; storing associations between the plurality of variables and the determined virtual types for each of the plurality of variables; providing a graphical user interface for displaying a first variable being used in the development project, where the graphical user interface displays information stored at a memory location associated with the first variable, where the information is displayed in a format that reflects the value of the information at the memory location as interpreted by the virtual type associated with the first variable; detecting that the user has interacted with the graphical user interface to change the virtual type associated a virtual type with a second variable; in response to detecting that the user has interacted with the graphical user interface to change the virtual type with the second variable, storing an association between the second variable and its virtual type; and updating the graphical user interface to reflect the new interpretation of the information stored at the memory location associated with the second variable according to the virtual type associated with the second variable; and enabling the user to interact with the graphical user interface to change the information stored at the memory location associated with the second variable, where the information stored at the memory location is changed by the user specifying a new value for the second variable as interpreted by the virtual type associated with the second variable, causing the information stored at the memory location to be updated so that when the information is interpreted according to its virtual type, the information has a value consistent with the new value specified by the user.

9. The computer of claim 8, where the virtual type associated with the first variable is a Q-type variable, and where the graphical user interface displays the floating point equivalent of the first variable.

10. The computer of claim 8, where the operation of enabling the user to interact with the graphical user interface to change the information stored at the memory location associated with the first variable includes the operation of: properly saturating the new value if it is beyond the mathematical range of the first variable's Q-type.

11. The computer of claim 8, where the graphical user interface simultaneously displays the information stored at the memory location associated with the first variable in a format showing the binary representation of the information stored at the memory location.

12. The computer of claim 8, where the user has associated a Q-type with the second variable that is displayed by the graphical user interface.

13. The computer of claim 8, where the operation of determining a virtual type for each of a plurality of variables includes the operation of: accepting input from the user specifying the appropriate virtual type for at least one of the plurality of variables.

14. The computer of claim 8, where the operation of determining a virtual type for each of a plurality of variables includes the operation of: automatically determining a virtual type for at least one of the plurality of variables by using a default virtual type that is associated with the native type associated with the at least one variable.

15. The computer of claim 8, where the operation of determining a virtual type for each of a plurality of variables includes the operation of: automatically determining a virtual type for at least one of the plurality of variables by evaluating the name of the at least one variable as used in the development environment.

16. The computer of claim 8, where the operation of determining a virtual type for each of a plurality of variables includes the operation of: automatically determining a virtual type for at least one of the plurality of variables by comparing the at least one variable's declared type to one or more typedef names that are mapped to a specific Q type.

17. The computer of claim 8, where the operation of determining a virtual type for each of a plurality of variables includes the operation of: automatically determining a virtual type for at least one of the plurality of variables by accessing stored type information in a file that contains debug information.

18. A data storage medium having computer program instructions stored on it, where the computer program instructions are executable on a computer that is operated by a user, and where the computer program instructions configure the computer to be capable of carrying out operations comprising: providing a development environment for a project having a plurality of variables associated with it, each of the variables having a native type, and where one or more of the variables has an associated virtual type; storing an association between a first variable and a virtual type associated with the first variable, where the first variable is one of the plurality of variables associated with the project; providing a graphical user interface for displaying in a window information stored at a memory location associated with the first variable in a format that reflects the information stored at the memory location associated with the first variable as interpreted by the virtual type associated with the first variable, rather than the native type of the first variable; detecting that the user has interacted with the window within the graphical user interface to associate a virtual type with a second variable; in response to detecting that the user has interacted with the window within the graphical user interface to associate a virtual type with the second variable, storing an association between the second variable and its virtual type; updating the displayed information in the window within the graphical user interface to reflect the interpretation of the information stored at a memory location associated with the second variable according to the virtual type associated with the second variable; and enabling the user to interact with the window within the graphical user interface to change the information stored at the memory location associated with the second variable, where the information stored at the memory location associated with the second variable is changed by the user specifying a new value for the second variable as interpreted by its virtual type, thereby causing the information stored at the memory location associated with the second variable to be updated so that when the second variable is interpreted according to its virtual type, the displayed information is consistent with the new value specified by the user.

19. The data storage medium of claim 18, where the development environment enables development of software for a processor that more efficiently processes fixed point operations than floating point operations, where the virtual type associated with the second variable is a Q-type variable, and where the window within the graphical user interface displays the floating point equivalent of the second variable.

20. The computer of claim 18, where the operation of storing an association between the first variable and the virtual type associated with the first variable includes the operation of: accepting input from the user specifying the appropriate virtual type for the first variable.

Description

COMPUTER PROGRAM LISTING APPENDIX

Submitted as part of this disclosure are three compact discs, each containing the files listed in one of the Appendices A, B, and C. Each compact disc is submitted in duplicate. The material on these compact discs is hereby fully incorporated by reference.

BACKGROUND AND SUMMARY

For years, hardware and software design tools, including software development kits, emulators, debuggers, and other tools have incorporated various tools and features for improving the efficiency of the operation, design, test, and development process. Often, modern tools include various debugging features, including "watch" or "memory" windows to inspect and/or modify variables and memory locations within a target software application. While modern tools make the design, test, and emulation of hardware and software more efficient than ever before, various enhancements, improvements, and/or efficiencies may be desirable. This disclosure describes various implementations of methods and/or systems relating to the interpretation of, interaction with and/or detection of virtual types, as well as relating to other inventions disclosed herein.

In one embodiment, the invention relates to a method of interpreting the value of a variable having a raw or native type and a virtual type, wherein the method comprises the act of interpreting the value of the variable in a format that is consistent with its virtual type. In another embodiment, the invention relates to a system for interacting with a variable having a raw or native type. In another embodiment, the invention relates to a method of detecting the virtual type of a variable. Other embodiments, features and uses of the systems, methods, and subject matter disclosed herein may be understood by reference to the full extent of this disclosure, including the following detailed description, the claims, the appendices, and the several drawings herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The following brief description of the drawings should be read and interpreted with the understanding that the Figures illustrate specific implementations of one or more of the inventions disclosed herein. These descriptions may therefore apply only to some embodiments of the inventions disclosed in this application. No part of this brief description should be interpreted as limiting the scope of any claimed invention in a manner not specifically required by the issued claims of this patent.

FIG. 1 is a block diagram of a software development environment.

FIGS. 2a and 2b are screen displays showing a "watch"-type window.

FIGS. 3a and 3b are screen displays showing a "watch"-type window.

FIGS. 4a and 4b are screen displays showing a "watch"-type window.

FIG. 5 is a flow chart illustrating some operations relating to a "watch"-type window.

FIG. 6 is a flow chart illustrating the operation of the window shown in FIG. 2.

FIG. 7 is a screen display showing a "watch"-type window.

FIG. 8a is a flow chart illustrating the operation of determining a virtual type associated with a variable in one embodiment.

FIG. 8b is a flow chart illustrating the operation of determining a virtual type associated with a variable in another embodiment.

FIG. 9 is a block diagram of a software development environment.

FIG. 10 illustrates examples of a virtual type qualifier list and a naming convention form list.

FIG. 11 is a flow chart illustrating the operation of a virtual type processor in one embodiment.

FIG. 12 is a block diagram of a software development environment in one embodiment that uses "Q-type" virtual types.

FIG. 13 shows a block diagram of a software development environment in one embodiment.

FIG. 14 is a screen display showing an edit window in one embodiment displaying a variable interpreted as a "Q-type."

FIG. 15 is a flow chart illustrating the functionality of the Q-type detection logic in one embodiment.

FIG. 16 is a flow chart illustrating the logic for the ExtractQvalFromName( ) function.

FIG. 17 is a screen display showing an example of the operation of the edit window of FIG. 14.

FIG. 18 is a pseudo code listing.

FIG. 19 is a screen display showing a "watch" window in one embodiment.

FIG. 20 shows an alternate styling of the "watch" window of FIG. 19.

FIG. 21 is a C code fragment.

FIG. 22 is a sample Q-typedef qualifier list.

FIG. 23 is a C code fragment.

FIG. 24 is a table showing the Q-type associated with a list of variables.

FIG. 25 is a flow chart illustrating the operation of one embodiment of the "build all" operation.

FIG. 26 is a block diagram of a Q-object file.

FIG. 27 is structure that might be used in a Q-object file.

FIG. 28 is a pseudo code listing illustrating symbol table management.

FIG. 29 is a screen display showing a window that displays information that may be stored in a Q-object file.

FIG. 30 is a screen display showing a window that displays information that may be stored in a Q-typedef qualifier list.

FIG. 31 is a block diagram of a Q-type support environment designed for operation in connection with a development environment.

FIG. 32 is a block diagram of a software development environment where a Q-type support environment is used as a stand-alone client.

DETAILED DESCRIPTION

This application relates to a variety of inventions as disclosed herein, and should be read and interpreted with the understanding that various inventions are disclosed herein by describing, illustrating, or otherwise disclosing specific implementations of those inventions. Thus, any features, procedures, methods, systems, brief descriptions of the drawings, or other aspects described or illustrated herein are not intended to limit the scope of any claimed invention in a manner not specifically required by the issued claims of this patent.

In addition, the following disclosure should be read and interpreted as providing an adequate disclosure and written description for any single feature, procedure, method, system or other aspect of any of the disclosed subject matter, whether or not such single feature, procedure, method, system or other aspect has been described as being implemented separately. Similarly, the following disclosure should be read and interpreted as providing an adequate disclosure and written description for any partial implementation of the methods, systems, and/or apparatuses disclosed herein, whether or not such partial implementations have been specifically described or illustrated. None of the features, procedures, methods, systems, or other aspects of these specific implementations are an essential or required aspect or element of any claimed invention unless explicitly required by the claim directed to that invention. No claim should be read to include subject matter described in this detailed description unless that claim explicitly recites such subject matter. For example, although this disclosure describes embodiments relating to the interaction with and/or detection of virtual types in a software development environment, it should be understood that implementation in a software development environment is not an essential element or required aspect of any claimed invention unless explicitly required by the claim directed to that invention. Further, any other methods, techniques, contexts, or subject matter disclosed herein are not essential elements or required aspects of any claimed invention unless explicitly required by the claim directed to that invention.

Further, the following disclosure should be read and interpreted with the understanding that any feature, procedure, method, system, aspect, invention, or combination thereof that is described and/or illustrated in this disclosure may be combined with any other feature, procedure, method, system, or other aspect described and/or illustrated in this disclosure, even if such a combination is not shown or specifically described. This disclosure should be interpreted as providing an adequate disclosure and written description of any claim directed to such combinations.

FIG. 1 is a block diagram of a software development environment 1. In the environment 1, a debugging tool 2 running on a host computer 3 is used to inspect and or modify variables and memory locations within a target software application (4). Source files (5) specify the functionality of the target application 4 and are processed by a set of build tools 6, creating the target application executable file 7. This executable file typically contains within it a symbol table 8 which lists the names, types and size of all the variables defined by source files 5. The target application executable file 7 also includes an embedded form 12 of the target application 4.

In the embodiment shown in FIG. 1, the target application 4 runs on a separate target hardware platform 10 that employs a specific microprocessor. The target application 4 may, in other embodiments, run on the host computer 3 itself (see the dotted line representation of the target application 4 in the box 2). In still other embodiments, it may run on a device simulator 9 (see dotted line representation of the target application 4 in the box 9) or elsewhere.

The debugging tool 2 is connected to the target hardware over an interface (11) which allows communication between the host computer 3 and the target hardware 10. The debugging tool 2 reads the target executable file 7 and symbol table 8 and in some cases it downloads the target application 4 to the target hardware 10 and launches it. The debugging tool 2 may use the source files 5 when setting break points and single stepping through the target application 4. Although the debugging tool 2 is shown separated from the build tools 6 in FIG. 1, in some embodiments, the debugging tool 2 and the build tools 6 are integrated.

One popular development environment is Microsoft's Visual C++ Studio. Another software development environment is Texas Instruments Code Composer Studio which uses a scan based emulator as its primary debugging tool and which is connected to the target hardware over a JTAG interface. Another such debugging tool is Applied Signal Processing's Live Data Exchange.TM. which communicates with the target device over a serial link. In general, Microsoft's development tools run the target application on the host computer itself. Others, such as Texas Instruments' Code Composer Studio (described in U.S. Pat. No. 6,493,868, which is hereby fully incorporated herein by reference), help debug target code that is intended to run on a specialized microprocessor such as a Digital Signal Processor. In the case of debugging code for a specialized microprocessor, the debugging tool normally runs on a host computer and either simulates the instruction set of the specialized microprocessor or is physically connected to target hardware using the specialized microprocessor.

In some situations, it is desirable for a particular variable having a "raw" or "native" variable type, such as an "int," "char," "long" or other type, to function as the basis for one or more other types. These other types, which are based on the raw type, may be called "virtual types." When a variable has one or multiple virtual types, it may be interpreted differently, depending on its "virtual type," and have a value that is a function of the virtual type associated with the variable.

The development and debugging of computer software is one situation in which a variable's virtual type may have some significance. Most modern development and debugging tools allow a user to inspect and modify variables and memory locations within a target software application. Often, a debugging tool is provided with a "watch" or "memory" window to permit inspection and/or modification of variables and memory locations within a target software application.

FIG. 2a is a screen display showing a "watch"-type window 13 displaying a variable (Alpha) that can be interpreted as having different values, depending on its virtual type. A dropdown box 14 allows the user to select, using the cursor or mouse pointer 15, a variable to display, and a raw value window 16 displays the actual data that is stored in the memory location represented by variable Alpha. In this case, the raw value window 16 displays the data in hexadecimal format, but the data could be displayed in binary or other forms. A set of radio buttons 17 allow the user to select one of a choice of various virtual types. An interpreted value window 18 displays the value of the variable Alpha, as it is interpreted using the selected virtual type.

In FIG. 2a, the variable alpha is displayed in the interpreted value window 18 as having a value of 17 when it is interpreted as a "Virtual Type 1." As shown in FIG. 2b, that same variable Alpha is interpreted as having a value of 352 when interpreted as a "Virtual Type 2." Note that the data 16 stored in the memory location associated with the variable Alpha, which is a 16-bit quantity, has not changed. It has the same raw hexadecimal value in both FIG. 2a and FIG. 2b. The difference between these two Figures is that the variable is interpreted differently in FIGS. 2a and 2b, based on the change to the selected virtual type.

FIG. 3 is a screen display showing a window 19 illustrating another example. In this example, the variable "Beta," which is an 8-bit quantity, can be interpreted as one of two virtual types: (1) a binary coded decimal (where two decimal digits 0 to 9 are encoded using the high-order four bit quantity, and the low-order four bit quantity), and (2) its raw type or as an "integer" having the decimal value of the binary quantity associated with the variable Beta. (Thus, in this situation, the raw type is also considered a "virtual type.") As shown in FIG. 3a, when the raw value 00010010 is interpreted as having a virtual type that is a binary coded decimal, its value is interpreted as 12 (i.e., the high-order 4-bit quantity represents a decimal "1" and the low-order 4-bit quantity represents a "2"). When interpreted as a virtual type that is an "integer," its interpreted value is 18. As in FIGS. 2a and 2b, the data stored at the memory location represented by the variable Beta has not changed, and the raw type associated with the variable has not changed, yet the variable is interpreted differently, based on the selected virtual type.

In FIG. 3a and FIG. 3b, the user can also change the raw value of the variable in window 20, which causes (1) the memory location associated with the variable Beta to be changed accordingly, and (2) the interpreted value displayed in window 21 to be updated based on the selected virtual type.

The user may also change the interpreted value of Beta in window 21, which causes the memory location associated with the Beta variable to be changed accordingly, once the translation from virtual type to raw type is performed. For example, if the interpreted value in window 21 were changed in FIG. 3a to the value 11, the memory location associated with the Beta variable would change to 00010001, since that quantity has a binary coded decimal value of "11," and the selected virtual type in FIG. 3a is "binary coded decimal."

FIG. 4 illustrates another example involving the use of virtual types based on "Q arithmetic," in which a variable having a raw type of "int" or "long" has an implied number of fractional bits. In some situations, often involving systems using specialized microprocessors such as Digital Signal Processors, particular arithmetic operations are performed a certain way so the processor can be used more efficiently. Typically, digital signal processors are low cost fixed point devices, which means that their IC design and instruction sets are designed to efficiently process fixed point operations, but they may be inefficient at performing floating point operations. For this reason, it is common to develop software applications and algorithms, especially DSP algorithms, that use only fixed point arithmetic, so as to ensure that the processor is used efficiently.

A common technique in developing fixed point algorithms is to use "Q arithmetic," where the Q-type of a variable defines the number of implied fractional binary bits within the 16-bit (or 32-bit, or other bit quantity) fixed point raw representation of a value. A Q15 virtual type number has 15 implied fractional bits. A Q8 virtual type number has 8 implied fractional bits. To convert between the raw value and the represented value of a Qval number we use the following formulas: interpreted_value=raw_value/(2.sup.Qval) raw_value=interpreted_value*2.sup.Qval

For example, to represent the value 3.5 as a Q6 number in 16 bits, the raw value is 3.5*26=224=0x00E0 (hex).

In FIG. 4, the variable "Delta" can be interpreted according to a variety of Q-type virtual types. In FIG. 4a, the variable Delta has a 16-bit quantity 0x00E0, shown in hex format, stored at the memory location it represents (see 22), and it is interpreted as Q6 virtual type, which means that it uses 6 bits for the fractional portion of its value. Its interpreted value is 3.5, since 0x00E0=224 (integer or decimal), and 224/2.sup.6=3.5. In FIG. 4b, the virtual type associated with variable Delta is changed to a Q4 type, which means that its interpreted value is 224/2.sup.4=14.0 (see 23 in FIG. 4b).

Although FIGS. 3 and 4 are described in connection with particular examples of virtual types, other virtual types taking different forms may be applicable in some embodiments. For example, some embodiments of the inventions disclosed herein may be applicable to packed vs unpacked strings (e.g., characters encoded as one byte or two bytes), radians vs. Hz virtual types (a radian variable is sometimes hard to understand without the conversion to HZ), ASCII vs. decimal virtual types (e.g., a value may be an ASCII string of numbers only), and virtual types involving quantities with encryption or check sum and parity bits (e.g., a 16-bit interpreted or real world value may be stored in a 32-bit word, with the upper 16 bits including encryption or check sum information).

FIG. 5 is a flow chart illustrating some basic operations relating to the FIGS. 2, 3, and 4. FIG. 5a illustrates the operation of displaying a variable in its virtual type format, which involves determining the variable's virtual type. FIG. 5b illustrates the operation of changing the data associated with the variable by allowing the user to enter an interpreted value to be represented by the variable's virtual type. Once the virtual type for the variable is determined, the interpreted value is translated into a raw or binary value that matches (or best matches) the interpreted value entered by the user. The memory associated with the variable may also optionally be changed. FIG. 5c illustrates the operation of detecting that the user has changed the virtual type associated with a variable, which may prompt the new virtual type associated with the variable to be saved for later use or reference.

FIG. 6 is a more detailed flow chart illustrating the operation of the window shown in FIG. 2. FIGS. 3 and 4 may operate in a similar manner. At 24, when the window 19 is displayed, the data stored at the memory location associated with the Alpha variable is retrieved from memory. The virtual type associated with the variable is then determined 25, which can be done in a number of ways. For example, the user may select a particular radio button 17 or otherwise indicate the virtual type associated with the Alpha variable. Other methods may also be used, including those disclosed in this patent. Once the virtual type is determined, the value of the variable Alpha, as interpreted by the virtual type associated with it, is displayed 26. If the user changes the raw value of the variable 27, the new interpreted value is updated and displayed 26. If the user changes the interpreted value 28, the new raw value that matches (or most closely matches) the interpreted value is determined and may also be stored in the memory location associated with the Alpha variable (206), and the display is also updated 26. If the user changes the virtual type associated with the variable Alpha 29, the display is updated 26. The virtual type associated with the variable Alpha may also be saved 30 so that the Alpha variable may default to the selected new virtual type in future operations. The virtual type may be stored in any location, including in a workspace file or symbol table. This process may continue until the window 13 is closed or otherwise terminated.

Once the virtual type for a particular variable is known, the proper interpreted value typically can be readily determined, usually through some type of formula. In the case of Q-types, for example, the pertinent formulas have been described above. However, if the virtual type for a variable is not known, it may be difficult to properly display its value in a form that is readily understandable to the user.

For example, in FIG. 7, the window 31 illustrates a watch or edit window in a development or debugging environment where the virtual type for the Q-type variable Delta is not known. In the case of FIG. 7, the debugging environment associated with window 31 only sees that the variable Delta is of type "int" and it does not know that the variable Delta is a virtual Q-type. It therefore assumes that the Delta variable is to be interpreted as an integer, and displays its value as simply 224, which is the integer value of 0x00E0 (see window 32 in FIG. 7). This may not be a very useful way to display the data for the user of the debugging tool associated with window 31, since the value 224 often will have little meaning to the user because it is not the value that the Delta variable is intended to represent. Instead, the value the variable represents may be quite different (the value is actually 3.5 if Delta is a Q6 variable). To translate the value 224 to its proper interpreted value, the user is left to determine its virtual type (i.e., its Q-type), and the user must also do the math (e.g., 224/(2^6)=3.5) to determine the properly interpreted value of the variable. The converse is also true. If the user wants to change the value of the Delta variable in FIG. 7 to 12.78, and thereby modify the memory associated with the Delta variable, the user may have to (1) first calculate the Q6 raw_value equivalent of 12.78 (raw_value=12.78*2A6=817.9200 =818) and then (2) enter the value 818 in window 32.

The process of determining a virtual type (25 in FIG. 6) for a variable therefore can be, in some cases, useful or important. Yet in many situations, the virtual type of a variable is not readily apparent. For a Q-type, the native or raw type is typically int (16 bit) or long (32 bit). Normally, software development environments or even debugging tools cannot readily determine, based on a conventional processing of the project source files, whether a particular int or long variable should be interpreted as an integer, or whether it should be interpreted in another way, such as a Q-type virtual type. Typically, the development environment views Q-types and integers as the same. Therefore, a debugging environment may have difficulty displaying the proper interpreted value for a particular variable if it is unable to ascertain if a particular variable has a virtual type associated with it.

FIG. 8a is a flow chart illustrating the operation of determining a virtual type associated with a variable (25 in FIG. 6) in one embodiment. At 33, if the variable does not have a raw type that is associated with a virtual type, the variable is interpreted according to the format indicated by its raw value (see 143). For example, in some situations, virtual types are only applicable to "int" type variables, so a variable that has a different type, such as a "float" or a pointer type, may not be susceptible to being interpreted as a virtual type. If the variable does have a raw type that is associated with a virtual type, then it is determined whether the user or developer has specified in some way a virtual type for the variable 35. For example, if the user has changed the virtual type for a particular variable in a watch or edit window, such as that in FIG. 2, for example, the virtual type association may have been saved (see 30 in FIG. 6). Alternatively, in some embodiments, the user's input may even be requested. If the user has specified a virtual type for the variable, the variable is associated with the virtual type specified by the user (see 34) and interpreted (see 36) according to the associated virtual type.

If the user has not specified a virtual type for the variable, the variable's name is evaluated to determine whether it has a naming convention that suggests a particular virtual type 37. If it does, the variable is associated with the virtual type indicated by the naming convention 38 and interpreted accordingly 36. If no naming convention is detected, the variable is interpreted according to the default virtual type associated with the raw variable 39. For a variable that has a raw type of "int," this may simply mean interpreting the variable as an integer, but other default interpretations or virtual types could also be used (e.g., binary coded decimal, or Q8). The user or developer may then continue to be monitored 40 to determine whether the user is associating, though input or otherwise, a virtual type with the variable. In some embodiments, later actions by the user may override earlier virtual type determinations.

FIG. 9 is a block diagram of a software development environment utilizing a debugging tool 41 that includes a virtual type processor 42. The virtual type processor 42 in the embodiment shown scans the source files 5 and detects the virtual types associated with the variables declared in the source files 5. A number of items assist the virtual type processor 42 in determining the virtual type that is associated with a particular variable declaration, including a naming convention form list 43, a virtual type qualifier list 44, and/or other virtual type sense logic or information 45. Associations between variables and virtual types are stored in one or more symbol table files 46. In some embodiments, the virtual type symbol table files 46 may be stored in other locations, or integrated with other files, such as the target executable 7 or symbol table 8, or elsewhere. It should be understood that any appropriate method of storing and/or tracking this information is contemplated.

The operations performed by the processor 42 may be carried out at any time. For example, in some embodiments, the processor may act as a preprocessor that scans various project files when a project is loaded and attempts to determine the virtual types associated with one or more variables in the project. In other embodiments, the processor may also operate periodically or upon certain events occurring during a given development, emulation, or debugging session. The processor 42 may also operate only as needed in some embodiments, attempting to determine a virtual type for some variables only when needed, or on-demand. In other embodiments, the processor may operate in other ways, or in a combination of ways, and it need not be limited to only those techniques or methods of operation specifically described.

In FIG. 9, the debugging tool 41 is shown interacting with a number of files 43, 44, and 46 and other logic 45, and is shown separate from the build tools 6. In other embodiments, some or all of the functionality of the debugging tool 41 may be integrated into the build tools 6, so that a combined build tool/debugging object is interacting with the files and logic shown in FIG. 9. In general, any particular module shown in FIG. 9 or elsewhere may be integrated into one or more other modules, as appropriate, and it should be understood that the present disclosure encompasses such combinations and integrated modules.

FIG. 10a illustrates a virtual type qualifier list that may be used by the virtual type processor 43 to determine virtual types for given variables. The first value shown, to the left of the colon, is a virtual type, followed by all of the type definitions that should be associated with that virtual type. For example, if a variable type is defined in some way in the source files for a given project, and that type is named "bcd_long," then the variables declared using that type are to have binary coded decimal virtual types. Similarly, if a particular type named "q2" is defined in the source files, then all variables declared with that type are to have a virtual Q-type of Q2.

FIG. 10b illustrates a naming convention form list where virtual types are listed with the form of one or more variable naming conventions that may be associated with various virtual types. Like FIG. 10a, the first value shown is a virtual type. The expressions following the colon represent the form of a variable naming convention that should be associated with that virtual type. For example, variable starting with the letters "bcd" or ending with the letters "_bcd" or including the letters "_bcd_" are to have binary coded decimal virtual types. Similarly, variables starting with "q2" or including the characters "_q2_" are to have a virtual Q-type of Q2.

In general, any information or logic (45 in FIG. 9) that may be employed to enable the virtual type processor 42 to effectively discern whether and what type of virtual type may be associated with a given variable may be used by the virtual type processor 42. In some situations, other information or logic may usefully employed, and is contemplated within the scope of some embodiments of the invention.

FIG. 11 is a flow chart illustrating the operation, in one embodiment, of the virtual type processor of FIG. 9. At 47 a source code file is opened, and each line of the file is scanned for variable declaration(s) 48. If a variable declaration is found, and if it uses a predefined virtual type, as defined in the virtual type qualifier list, the defined virtual type is associated with the variable 49, and that association is saved in a symbol table 50. Otherwise, if the raw variable type is susceptible to interpretation as a variable type (e.g., it is an integer, where virtual types may use raw types as integers), then the variable name is evaluated to determine whether it uses a naming convention that indicates its virtual type 51,52. If so, the indicated virtual type is associated with the variable 53, and that association is saved in the symbol table 50. Otherwise, the variable is interpreted using a default virtual type 54, or in some embodiments, using the raw type. When line scanning is complete 55, the symbol table is saved as a file 56 (see file 46 in FIG. 9), if it has not already been saved as a file. The process illustrated in FIG. 11 may be repeated for each source file in the development project.

In some embodiments, the determination at 51 in FIG. 11 of whether a raw type is susceptible to interpretation as a virtual type may be optional, or it may be applied prior to determining whether the variable declaration uses a defined virtual type 57.

The virtual type processor 42 of FIG. 9 thus provides an additional way in which a variable's virtual type can be determined. FIG. 8b is a flow chart illustrating the operation of determining a virtual type associated with a variable (25 in FIG. 6) in another embodiment. This embodiment involves determining whether the virtual type processor 42 has associated a virtual type with the variable (see 148 in FIG. 8b). Determining a variable's virtual type may simply involve accessing the information generated by the virtual type processor. Accessing this information may involve loading the virtual type symbol table 46 generated by the virtual type processor, or accessing this information from any other location where that information may be stored. Such information may be stored in memory or in another file, such as the symbol table 8 shown in FIG. 9 or in a workspace file.

If the virtual type processor has associated a virtual type with the variable, then the variable is interpreted according to the virtual type determined by the virtual type processor (see 149). Otherwise, the variable is interpreted according to its raw type (see 150). In other embodiments, where the variable has not been associated with a virtual type by the processor 42, one or more the procedures undertaken in FIG. 8a may be carried out, instead of interpreting the variable as a raw type (as in 150 in FIG. 8b). Normally, determining the virtual type of a variable from the information generated by the processor 42, may be the preferred method, since it requires little or no input from the user.

FIG. 12 is a block diagram of a software development environment 1 in one embodiment that uses "Q-type" virtual types. Included within the environment shown are source files 5, build tools 6 and a target application 4. A debugging tool 58 interacts with various components of the system in FIG. 12 and supports debugging a target application 4 that uses Q-type variables.

In operation, the enhanced debugging tool (58) is used to inspect and/or modify variables and memory locations of various Q-types contained within the target software application (4). The tool 58 provides methods for determining, tracking, viewing and modifying variables of various Q-types in an intuitive and user friendly manner. Source files (5) specify the functionality of the target application 4 and are processed by a set of build tools 6, creating the target application executable file 7. The enhanced debugging tool (58) can initiate or be called from the standard build tools over a tools interface (60) or certain aspects of the functionality of 58 can be incorporated within the standard build tools 6. The executable file 7 typically contains within it a symbol table 8 which lists the name, raw type and size of all the variables defined by source files 5. The debugging tool scans the set of source files (5) looking for key words which will determine a variable name and associated Q-type. This association is saved by the tool for later use, perhaps in the symbol table 8 or in a separate file (not shown). The debugging tool is connected to the target application over an interface (11) which allows communication between the enhanced debugging tool and the target application 4. This communication allows the debugging tool to inspect, display and modify specific variables and memory locations within the target application.

FIG. 12 in some embodiments includes logic that is able to maintain and track the association of variable names and their Q-type. Further, logic that enables easy viewing and modification of Q-type variable values as their floating point equivalent may also be implemented, thereby providing an easy, intuitive approach to entering new variable values, and allowing the user to change the value of a Q-type variables by entering a floating point equivalent. Also, in some embodiments, the debugging tool 58 allows variables of different Q-types to be inspected and modified within the same window view, and provides saturation protection for new values which are entered by the user.

In some embodiments, the debugging tool 58 of FIG. 12 is capable of automatically detecting a variable's Q-type. The Q-type of the variable can be determined in a number of ways. For example, the Q-type of variables can be determined by reading the Q-type associated with each variable from a "Q-type object file" which has a list of variable names in the target application and their associated Q-type. Another method involves extracting the Q-type from the variable name by looking certain naming conventions, such as variables containing the string fragment q?? anywhere in the name. Another method involves receiving input from the user that indicates the Q-type for one or more variables. In this last approach, the Q-type could be manually entered by the user through, for example, the use of a dropdown or edit field.

In embodiments employing the use of a Q-object file, various methods for creating and maintaining such an object file may be employed. For example, in some embodiments, a compile time Q-type preprocessor scans all target application project files to identify the virtual Q-types of all variables and creates the Q-object file. Derived or virtual typedef qualifiers may be used to declare each variable, such as: "q15 myvariable."

In other embodiments, a user interface tool may be used to load an existing Q-object file or the symbol table (8) from the target executable file (7), thereby listing target application variable names, providing the user with the opportunity to enter/change the associated Q-type for each variable. In such an embodiment, the Q-object file may be automatically updated as the user makes changes.

Also, in some embodiments, as the user manually enters variable names or a new Q-type for a specific variable name in the target application during a debugging session or the like, the associated Q-object file is automatically updated. If necessary, the variable name may also be added to the object file, and the new associated Q-type updated and stored.

FIG. 13 shows a detailed block diagram of a software development environment, such as one similar to that described in connection with FIG. 12. FIG. 13 creates a Q-type support environment providing methods for determining, tracking, viewing and modifying variables of various Q-types. A Q-type watch/edit tool 61 in FIG. 13 provides the user with a means to view and/or modify--entirely in the "floating point" domain--variables or expressions running in the target application 4. A Q-type compiler tool 62 creates an initial variable name and Q-type association for some or all variables (typically just Q-type variables) within the target applic