Inferring operand types within an intermediate language

Details Inferring operand types within an intermediate language Inferring operand types within an intermediate language

1999-06-07

2002-11-19

Morse, Gregory (Department: 2762)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

Reexamination Certificate

active

06484312

ABSTRACT:

FIELD OF THE INVENTION
This invention relates generally to intermediate languages, and more particularly to inferring operand types within such intermediate languages.
BACKGROUND OF THE INVENTION
Intermediate language-type models for programming languages have become increasingly popular. In an intermediate language model, a source code is generally compiled into a desirably substantially platform-independent intermediate language. When the code is desired to be run on a particular platform, an execution engine on that platform then interprets or compiles the intermediate language to native code understandable by the platform. Examples of systems that use intermediate languages include the Java virtual machine.
As an example of native code, it is noted that processors such as x86-type processors known in the art generally require a separate instruction for an operation as the operation is applied to each different data type. For example, an “add” operation will usually have a separate “add integer” instruction for integer data types, and an “add real” instruction for real (i.e., floating point) data types. Other data types for which separate instructions may be required include “short” integers, “long” integers, etc.
Execution speed and code size are important considerations in the usability of code written in any programming language in general, and in an intermediate language in particular. These two metrics in general are at odds with one another. For example, because intermediate language code generally is compiled to native code as it is being executed, its execution speed is usually slower than comparable programs already pre-compiled into native code. On the other hand, intermediate language code is also more likely to be stored in small consumer electronics device and more likely meant for transmission over the Internet as compared with more traditional computer programs, rendering code size a more important metric in the intermediate language code's usability than compared with more native computer programs, which are usually stored, for example, on voluminous CD-ROM's and hard disk drives.
Like most computer languages, intermediate languages have instruction sets, with each instruction having a corresponding “opcode” that identifies the instruction. For expressiveness and ease of programming, a large number of instructions, and therefore corresponding opcodes, is desirable. However, having more than 256 instructions or opcodes means that more than one byte is necessary to identify each instruction. If more than 256 instructions are desired, then another byte must be added to uniquely identify each opcode.
Having more than 256 instructions, however, while allowing for a richer instruction set, is disadvantageous when execution speed and code size are considered. Having each instruction take up two bytes instead of one byte increases the size of the resulting code. Furthermore, the extra size implies more memory accesses (page faults) and thus generally takes longer than processing instructions that are shorter in length. There is a need, therefore, for a robust instruction set that nevertheless provides for the execution speed and code size advantages that one-byte opcodes provide. For these and other reasons, there is a need for the present invention.
SUMMARY OF THE INVENTION
The invention relates to inferring operand types within an intermediate language. In one embodiment, a computer-implemented method first inputs an intermediate language code that includes type-indefinite opcodes. The method transforms the input code into a second stream of opcodes, where the types of each type-indefinite opcode has been inferred contextually. The method finally generates native code from the type opcode stream.
In one embodiment, for example, a program already in intermediate language code may have an “add” instruction, to add two numbers like 4 and 5, or 4.5 and 5.5. In the former case, both of these numbers are integers, while in the latter case, both are real numbers. Therefore, one embodiment of the invention would note that in the first case the add instruction is adding two integers, and would resolve that instruction to a specific “add integer” instruction—while in the latter case, the embodiment would note that the add instruction is adding two real numbers, and would resolve the instruction to a specific “add real” instruction, which is a different instruction than the “add integer” instruction. When generating native code, which is the specific code that is executed by a computer's processor, for example, the method would thus generate a corresponding “add integer” native opcode for the typed “add integer” instruction, and a corresponding “add real” native opcode for the typed “add real” instruction.
The invention provides for advantages not found in the prior art. For example, the invention allows for a robust instruction set that still has a relatively small total number of opcodes. For example, rather than having an “add” instruction for each type of operand—e.g., an “add floating point (real)” instruction, an “add short (integer)” instruction, an “add long (integer)” instruction, an “add integer” instruction, etc.—an embodiment of the invention instead only needs a single “add” instruction, since the specific type of this instruction is later resolved by the invention. An instruction set can therefore still be robust, while nevertheless using only a single byte to identify each opcode—thus ensuring the speed and size advantages that result from using a single byte.
The invention includes computer-implemented methods, machine-readable media, computerized systems, devices and computers of varying scopes. Other aspects, embodiments and advantages of the invention, beyond those described here, will become apparent by reading the detailed description and with reference to the drawings.


REFERENCES:
patent: 5842017 (1998-11-01), Hookway et al.
patent: 5930509 (1999-07-01), Yates et al.
patent: 6021275 (2000-02-01), Horwat
patent: 6317872 (2001-11-01), Gee et al.
patent: 0 626 641 (1994-11-01), None
“Encyclopedia of Computer Science”, Third Edition, IEEE Press, Copyright 1993 by Van Nostrand Reinhold, pp. 728-729.
“The Computer Glossary, The Complete Illustrated Dictionary”, Seventh Edition by Alan Freedman, copyright 1995, pp. 201 and 319.
von H. Schauer, Architektur und Implementierung eines PASCAL-Systems fur Mikrocomputer, vol. 24 (19982), Jun., No. 3, Munich, Germany.
Ganapathi et al, Retargetable Compiler Code Generation, Computing Surveys, vol. 14, No. 4, Dec. 1982.
Cordy, Holt, Code Generation Using an Orthogonal Model, Software Practice & Experience, 20(1990) Mar., No. 3.
Shields, Sheard, Jones, Dynamic Typing as Staged Typed Interface, POPL '98. Proceedings of the 25th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pp. 289-302. 1998.

Affiliated with

Also associated with

Rating

Inferring operand types within an intermediate language does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Inferring operand types within an intermediate language, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Inferring operand types within an intermediate language will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2993722