Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-12-03
2001-10-16
Powell, Mark R. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000, C717S152000
Reexamination Certificate
active
06305009
ABSTRACT:
TECHNICAL FIELD
This invention relates generally to programming languages and, more particularly, to macro languages and object oriented programming.
BACKGROUND OF THE INVENTION
The use of macro languages is increasingly common in software engineering. Many industrial control systems incorporate one or more such languages for the logical processing of sensory inputs and the setting of outputs. A built-in macro language can perform high level manipulations with relatively simple statements, because of the special assumptions underlying the environments in which they operate. The ultimate value of a macro language in a software product is that it affords the end-user the ability to tailor the product to specific needs that could not be foreseen directly by the designer. The benefits of this accrue both to the designer, who need not maintain myriad versions of the product, and to the end-user, who can obtain specialized benefits from the software without requesting a special development of the designer.
In software engineering, a macro language is simply a procedural language, with its own rules of syntax, in a structured environment. A language such as Java, commonly used for Internet “applets”, could also be considered to be a macro language from this standpoint. What is common to virtually all of these situations is that, usually, the language is executed by an interpreter. That is, the program text is parsed at run time, and then, based on the branches taken by the parser, a so-called “interpreter engine” performs the specified logic. There can be advantages to an interpreted language. First, the complexity of the program is defined by the complexity of the parser. The interpreter engine can be written in a higher level language. Second, since text can be ported easily between computer platforms, an interpreted language program can be run without change, on any computer platform or operating system for which there exists an interpreter engine. The primary disadvantage to an interpreted language is slow execution. An alternative and more traditional approach is a so-called “compiled” language. In a compiled language, a pre-processor, called a compiler, parses the program text and produces a so-called “binary executable file” which consists of a sequence of machine language statements that can be executed directly by the CPU. That is, the binary executable file stands alone at execution time. It executes itself. The primary disadvantages of a compiled language are the opposite of the advantages of an interpreted language. First, the machine language syntax that should replace a parsed phrase can be extremely difficult to design. Second, the very nature of the binary executable file is to be computer platform and operating system dependent. The primary advantage of a compiled language over an interpreted one is speed of execution, often by at least an order of magnitude. This can be a critical factor for a procedure.
An intermediate alternative approach is to substitute integer codes (also called byte codes) for different statement types. In this case, a pre-processor performs the language syntax parsing task once and replaces text (or symbolic) statements with the coded versions. This approach requires that an execution “engine” read the integer codes and perform the required actions based on the actual code values. While this algorithm retains platform independence and is faster than an interpreted program, it is somewhat slower than a true compiled version, because of the number of cases that must be traversed during execution of the program.
SUMMARY OF THE INVENTION
In accordance with the invention, there is provided an object compiler and associated object execution engine. The object compiler is used to compile source code into persistent objects that can be stored as a machine and operating system-independent file and that can be read and executed by the object execution engine. The object compiler carries out the following steps. First, it parses the statements of source code and converts each statement into one or more pre-defined, persistent instruction objects, each of which has at least one virtual function associated therewith. Then, it orders the instruction objects to thereby generate a sequence of the instruction objects. Finally, the sequence of instruction objects are stored on non-volatile storage, such as a hard disk or other magnetic media. Ordering of the instruction objects can be accomplished by providing an index for each instruction object that is indicative of its position within the sequence, with the indices being stored along with, or as part of, the instruction objects. Preferably, the instruction objects each have a virtual initialize method, a virtual execute method, and an index indicative of the next instruction object in the sequence. Data used in the statements can be represented as persistent data objects, each of which has an index that is used to access the data when needed. The instruction objects and data objects can be stored in separate stacks (i.e., as linked lists), with their indices indicating their position within the stack.
The object execution engine executes the compiled instruction objects using the execute method of each instruction object. This execute method operates to execute at least one machine language instruction and to provide a return value that identifies another of the instruction objects. Thus, the object execution engine can execute a sequence of instruction objects by calling the execute method of each of the instruction objects and using the return value to access the next instruction object. For C++, the object execution engine could be written as:
Statement* next;
next = InstructionList [0];
while (TRUE) {
next = next->Execute ();
}
The execute methods are provided as a part of a set of instruction object definitions that define each type of instruction object as a different class. These object definitions will typically be machine-dependent and can therefore be provided along with the object execution engine. Each instruction object definition can include a pointer, with the initialize method being used to assign the pointer to a dynamically allocated memory address that points to the instruction object identified by its index. Then, the return value provided by the execute method can be the pointer to the next instruction object.
This arrangement provides speed characteristics close to a true compiled version. The advantages of such an approach are design simplicity and operational speed, without compromising portability between platforms or operating systems. The object compiler abstracts many of the structural features of a binary executable, but at the same time incorporates higher level building blocks that embody the assumed environment of the particular language. Since the building blocks are all compiled using a true (optimized) binary compiler, the assemblage of them can execute with the speed of a compiled language, yet the data required to invoke the building blocks can be machine independent.
REFERENCES:
patent: 5613122 (1997-03-01), Burnard et al.
patent: 5652884 (1997-07-01), Palevich
patent: 5953524 (1999-09-01), Meng et al.
patent: 6195774 (2001-02-01), Jacobson
Temte, “A Compiler Construction Project for an Object-Oriented Language”, ACM, pp. 138-141, Mar. 1992.*
Temte, “Let's Begin Introducing the Object-Oriented Paradigm”, ACM, pp. 73-77, Mar. 1991.*
Hagimont et al., “Persistent Shared Object Support in the Guide System: Evaluation & Related Work”, ACM, pp. 129-144, Oct. 1994.*
Wu et al., “An Object-Oriented Specification and its Generation for Compiler”, ACM, pp. 323-330, Mar. 1992.*
Rogue Wave Software, “Tools.h++, Foundation Class Library for C++ Programming, User's Guide”, Rogue Wave, Inc., Corvallis, Oregon, 1996, pp. 123-159.
Shepherd, George and Scot Wingo, “MFC Internals”, Addison Wesley Developers Press, Reading, Massachusetts, 1996, pp. 162-174.
Powell Mark R.
Reising Ethington, Barnes, Kisselle, Learman & McCulloch, P.C.
Vo Ted T.
LandOfFree
Compiler design using object technology with cross platform... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Compiler design using object technology with cross platform..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Compiler design using object technology with cross platform... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2588312