WO2005006119A2 - An extensible type system for representing and checking consistency of program components during the process of compilation - Google Patents

An extensible type system for representing and checking consistency of program components during the process of compilation Download PDF

Info

Publication number
WO2005006119A2
WO2005006119A2 PCT/US2004/015964 US2004015964W WO2005006119A2 WO 2005006119 A2 WO2005006119 A2 WO 2005006119A2 US 2004015964 W US2004015964 W US 2004015964W WO 2005006119 A2 WO2005006119 A2 WO 2005006119A2
Authority
WO
WIPO (PCT)
Prior art keywords
type
checking
phx
language
rule
Prior art date
Application number
PCT/US2004/015964
Other languages
French (fr)
Other versions
WO2005006119A3 (en
Inventor
Mark Ronald Plesko
David Read Tarditi, Jr.
Original Assignee
Microsoft Corporation
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Microsoft Corporation filed Critical Microsoft Corporation
Priority to EP04752897A priority Critical patent/EP1639461A4/en
Priority to KR1020057025045A priority patent/KR101086082B1/en
Priority to JP2006517130A priority patent/JP4794437B2/en
Publication of WO2005006119A2 publication Critical patent/WO2005006119A2/en
Publication of WO2005006119A3 publication Critical patent/WO2005006119A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/43Checking; Contextual analysis
    • G06F8/436Semantic checking
    • G06F8/437Type checking

Definitions

  • the present invention relates to type systems, and particularly, to a type system that is extensible to new and updated programming languages.
  • a type system is a system used in programming languages to aid in the detection and prevention of run-time errors.
  • a programming language is "typed" if it contains a set of types that are declared for objects such as variables, functions, etc., and these types are checked versus a set of rules during compilation of a program written in the language. If the source code written in the typed language violates one of the type rules, a compiler error is determined.
  • Typed intermediate languages for use in compilers have received significant study in the research community over the past few years. They enhance the reliability and robustness of compilers, as well as provide a systematic way to track and check information needed by garbage collectors.
  • the idea is to have an intermediate representation that has types attached to it and that can be type-checked in a manner analogous to type-checking for source programs.
  • a typed intermediate language is more difficult to implement because types that represent items made explicit during the compilation process are necessary.
  • a typed intermediate language is even more difficult to implement if it must represent a number of different high-level programming languages.
  • the different languages not only have different primitive operations and types, but the high-level programming languages have different levels of typing. For instance, some languages, such as assembly languages, are generally untyped. In other words, they have no type system. Of the languages that are typed, some are strongly typed while others are more loosely typed.
  • C+ + is generally considered a loosely typed language
  • ML or Pascal are considered strongly typed languages.
  • some languages that are loosely typed have smaller sub-sets of the language that allow for a majority of the code sections within a program to be strongly typed, while other code sections are loosely typed.
  • C# and Microsoft Intermediate Language used in .NET (MSIL) allow this. Therefore, a typed intermediate language used to represent any of these high-level languages must be able to represent different types strengths.
  • the type system of such a typed intermediate language must be able to implement different rules depending on characteristics of the code being type checked. Another problem arises when a typed intermediate language is lowered throughout the process of compilation.
  • the lowering of a language refers to the process of changing the form of a language from a higher level form, such as what a programmer would write, to a lower level, such as to an intermediate language.
  • the language can then be further lowered from the intermediate language to levels closer to what a computer executes, such as machine- dependent native code.
  • a different set of rules must be used for each representation. Attempts to create typed intermediate languages often fall short of solving the problems discussed above. For instance, Cedilla Systems' Special J compiler uses a typed intermediate language. However, this compiler is specific to the Java source language and therefore did not need to process multiple languages that may, for instance, have non-type-safe code. Additionally, this compiler only uses one set of rules for type-checking and therefore could not be used for multiple levels of compilation. In the research community, typed intermediate languages often tend to be highly specific to the source language and difficult to engineer (and design the types) for the multiple stages of compilation.
  • a representation of types, type-checker, method and compiler are provided for checking consistency in various forms of an intermediate language.
  • the typed intermediate language is suitable for use in representing programs written in multiple (heterogeneous) source languages including typed and untyped languages, loosely and strongly typed languages, and languages with and without garbage collection.
  • the type checker architecture is extensible to handle new languages with different types and primitive operations.
  • the representation of types, type-checker, method and compiler include various aspects. The various aspects may be used separately and independently, or the various aspects may be used in various combinations and sub-combinations. In one aspect, a method of type-checking a programming language in a compiler is provided.
  • One or more rule sets is taken as input to a type-checker, which selects one or more of the rule sets based upon any one, or combination of two or more, of numerous criteria. Among them are stage of compilation, source language, architecture, and level of typing present in the language being type-checked. The language is then type-checked using the selected one or more rule sets.
  • a compiler is provided with a type-checker that constructs one or more sets of rules based on any one, or combination of two or more, of numerous criteria.
  • the rule sets can include one rule set corresponding to strong type-checking, one rule set corresponding to weak type-checking, and one rule set corresponding to representation type- checking.
  • the weak rule set can allow more flexibility in typing, such as allowing type casts, while the representation rule set can allow dropped type information in parts of the intermediate program representation.
  • a programming interface is provided for constructing a plurality of rules for checking the consistency of an intermediate representation of a program. Checking the consistency of the intermediate representation can include providing a plurality of rules to a type-checker that applies a first set of rules to a one intermediate representation, and a second set of rules to a another intermediate representation, based on predetermined criteria.
  • FIG. 1 is a flow diagram of a generic compilation process.
  • FIG. 2 is a table listing showing a conversion of a source code statement into an high- level representation, and then to a machine-dependent low-level representation.
  • FIG. 3 is a data flow diagram illustrating one embodiment of a compiler system for type-checking a typed intermediate language at various stages of compilation.
  • FIG. 4 is a block diagram of a type-checker for use in a compiler system.
  • FIG. 5 is a flowchart for one possible procedure for choosing a rule set to be applied by a type-checker.
  • FIG. 6 is a direct graph diagram showing a hierarchical relationship between types.
  • FIG. 1 is a flow diagram of a generic compilation process.
  • FIG. 2 is a table listing showing a conversion of a source code statement into an high- level representation, and then to a machine-dependent low-level representation.
  • FIG. 3 is a data flow diagram illustrating one embodiment of a compiler system for type-checking a
  • FIG. 7 is a direct graph diagram showing the addition of a type to a hierarchical relationship between types.
  • FIG. 8 is a flow chart of a method for checking an instruction against a type rule in a type-checking system.
  • FIG. 9 is a block diagram of an example of a computer system that serves as an operating environment for an embodiment of a type-checking system.
  • DETAD ED DESCRIPTION A representation of types, type-checker, and compiler are provided for checking consistency in various forms of an intermediate language.
  • the type-checker and compiler allow use of different types and type-checking rules, depending on the source language for a program component and/or the stage of compilation. For example, it may be desirable to have a high-level optimizer apply to programs written in a variety of languages.
  • These languages may have different primitive types and primitive operations.
  • One language may contain types and operations for complex arithmetic, for example, whereas another language may contain types and operations specific to computer graphics.
  • the optimizer can be used for languages with different primitive types and operations.
  • Another example can include a program where certain components are written in a strongly-typed subset of a language and other components are written in the full language, which is not type-safe. It is desirable to have more error checking for the first set of components. This can be accomplished by using different type-checking rules for the different components.
  • Yet another example is dropping type information during compilation. The type-checker and compiler can allow type information to be dropped at later stages, while forcing precise information to be maintained during earlier stages.
  • FIG. 1 shows a generic compilation process for a system utilizing a typed intermediate language with different levels of lowering for representing a number of different source languages.
  • Source code 100-106 is written in four different source languages that may or may not be typed and have differing levels of type strength. For instance, source code 100 written in C# will be typed much stronger than source code 106 written in C + 4- for instance.
  • Source code is first processed and entered into the system by a reader 108. The source language is then translated into a high-level intermediate representation of the typed intermediate language (HIR). The HIR can then optionally be analyzed and optimized at block 110.
  • HIR typed intermediate language
  • the HIR is then translated into a mid-level intermediate representation of the typed intermediate language (MIR). This representation is lower than the HIR but still machine independent.
  • MIR can optionally be analyzed and optimized as shown at block 112.
  • LIR machine-dependent low-level representation of the typed intermediate language
  • LIR can then optionally be analyzed and optimized at block 116, and supplied to an emitter at block 118.
  • the emitter will output code in one of many formats 120-126 representing the original source code read into the system.
  • the data necessary to complete the process is stored in some form of persistent memory 128.
  • the compilation process consists of transforming the intermediate language instructions from one level of representation to another.
  • Figure 2 shows the conversion of a source code statement into an HIR, as well as the conversion of the HIR to a machine-dependent LIR.
  • Source code statement 200 can be written in a number of high-level programming languages. These languages are designed to allow programmers to write and read code in a manner that is easily understood. Thus, the programmer is allowed to use characters like ' + ' for addition, and allowed use of more powerful forms, such as adding more than two operands as shown in statement 200.
  • Statements 202-206 are an HIR representation of statement 200 that represents the same functionality, but does so in a format closer to that as would be understood by a computer and yet still architecture independent.
  • Statement 202 uses an 'ADD' command to add a first and second variable and assigns the result to a first temporary variable tl.
  • Statement 204 uses another 'ADD' command to add tl to the third variable and assigns the result to a second temporary variable t2.
  • Statement 206 then assigns the value of t2 to the result variable z using an 'ASSIGN' instruction.
  • Statements 208-212 are a LIR of the intermediate language of the statements 202-206.
  • Statement 208 uses an add instruction specific to the x86 architecture to add the values of two variables stored at specified registers and stores the result in a register assigned to a temporary variable tl.
  • Statement 210 uses the add instruction specific to the x86 architecture to add the values of tl and a third variable stored at the specified registers and stores the result in the specified register (EAX) assigned to t2.
  • Statement 212 then uses a move instruction specific to the x86 architecture to move the value stored in EAX to the output variable z.
  • the typed intermediate language contains type representations expressed either explicitly or implicitly. An explicit type expression is declared directly in the representation. For example, the statement: int a; expressly defines the variable 'a' as type int.
  • a type representation can be expressed implicitly by defining a default type for certain statements of code. For instance, if the default return type for functions is int, then the statement: f_start (); would declare a function f_start that takes no arguments and returns a value of type int.
  • f_start a typed intermediate language suitable for use with multiple programming languages at multiple levels of representation.
  • Appendix A a number of type representations are defined in a type class hierarchy such that type systems of various languages can be represented by the typed intermediate language.
  • An abstract base class is defined as 'Phx::Type' for all types.
  • the base class can contain, for instance, size information in 'sizekind' for the various types, such as actual, symbolic or unknown (or variable) types.
  • the base class can also contain 'typekind' in order to designate type classification.
  • an external type can be provided as an abstract type that wraps an externally defined type in order to provide back mapping from the typed intermediate language to the original source code.
  • a class defined as 'Phx::PtrType' can represent pointer types. Various kinds of pointers can be defined as well.
  • a managed, garbage collected pointer points to a location within a garbage collected object
  • a managed, non-garbage collected pointer points to a location within a non-garbage collected object
  • an unmanaged pointer such as would be found in code written in C+ + , for instance
  • a reference pointer points to the base of a garbage collected object
  • null null.
  • a class defined as 'Phx::ContainerType' can represent container types, such as types that contain internal members. The internal members can have fields, methods and other types.
  • a class defined as 'Phx: :FuncType' can represent function types, including any necessary calling conventions, lists of arguments and lists of return types.
  • a class defined as 'Phx::UnmgdArrayType' can represent unmanaged array types. Under 'Phx::ContainerType' in the hierarchy, four more classes can be defined.
  • a class defined as 'Phx::ClassType' can represent class types, a class defined as
  • 'Phx::StructType' can represent struct types
  • a class defined as 'Phx: :InterfaceType' can represent interface types
  • a class defined as 'Phx: :EnumType' can represent enumerated types.
  • Thx::ClassType' in the hierarchy an additional class defined as 'Phx: :MgdArrayType' can represent managed array types.
  • a class 'primtype' is defined as a special instance of a struct type, 'primtype' can include various types such as int, float, unknown, void, condition code, unsigned int, xint, etc.
  • the representations can be used in both a HIR or LIR of the typed intermediate language. Additionally, target specific primitive types can be included in the type representation. Some languages have complex arithmetic types that can be handled efficiently if the type system is made aware of them. Take for instance an 'MMX' instruction. Such an instruction is one of a set of extra instructions built into some versions of x86 processors for supporting single instruction/multiple data operations on multimedia and communications data types. The type system can be customized to recognize and use these instructions with minimal alteration of the type representations.
  • the embodiment of the type representation of types shown in Appendix A also includes an "unknown" type, which can represent any type and optionally has a size associated with it. The size is the size of the machine representation of the value.
  • An unknown type allows a compiler to drop type information in a controlled manner by changing the type information from a specific type to an unknown type. It allows the compiler to generate code that depends on the size of the value being manipulated, even when the type is unknown. Other types may use unknown types, so the unknown type also allows the representation of partial type information (where some but not all information is known). For instance, assume a pointer to an int type. At some stage of lowering, it may be desirable to drop the type information, int. The unknown type allows the compiler to replace the int type with the unknown type. The type-checker then need not check that the pointer of interest is pointing to a correct type. It essentially takes the chance the value pointed to will be handed in such a manner as to not adversely affect the program functionality at runtime.
  • Another example of using an unknown type is for defining a type for a function. If a function with an argument of type pointer to unknown is called, where the argument previously had the type pointer to int, the compiler must trust that right type is being passed. The result of dereferencing the pointer may or may not be known to be an int; however, it will be used as an int.
  • a more complex example is the introduction of an intermediate temporary variable during the conversion from high-level to low-level intermediate representation of a virtual function call.
  • Virtual tables (vtables) are widely used to implement virtual calls in object-oriented languages.
  • the first step in making a virtual function call in the low-level intermediate representation is to fetch the first field of an object of memory. The first field contains a pointer to a viable.
  • FIG. 3 illustrates one embodiment of a compiler system for type-checking a typed intermediate language at various stages of compilation, and therefore, type-checking a typed intermediate language at various levels of lowering.
  • Source code 300 represents any one of a variety of source languages. The source code 300 is translated into a HIR of the typed intermediate language 302.
  • the types representations of the source language are translated into the type representations internal to the typed intermediate language.
  • the HIR as explained with respect to FIGs. 1 and 2, is lowered throughout the compilation process.
  • a high (HIR) 302, mid (MIR) 304, and low (LIR) 306 level representations are shown.
  • the embodiment is not so limited. Any number of stages of compilation may be type-checked.
  • the intermediate language at each level of representation may be type-checked by type-checker 308.
  • the type-checker 308 implements an algorithm or procedure for applying one or more rule sets 310 to each stage of the compilation process, and therefore to each representation of the intermediate language.
  • the rule sets 310 are a set of rules designed for varying properties of languages, such as the source language, stage of compilation, what strength of typing, etc.
  • source code 300 contains code authored in the C+ + programming language.
  • the C + + source code 300 is first translated into an HIR 302 of the typed intermediate language.
  • the type-checker 308 can interact with the HIR 302 in order to determine any number of properties.
  • properties might include the stage of compilation (HIR), the type of source code present (C+ +), whether or not the language is typed (yes), whether it is loosely or strongly typed (loosely), etc. Based on the properties, the type-checker can select an appropriate set of rules.
  • the type-checker type-checks the HIR according to that set of rules. Once the HIR is lowered to MIR or LIR, the properties will be accessed again and the same or a different set of rules may be appropriate.
  • three sets of type-checking rules can be supplied to the type- checker.
  • One set can correspond to "strong" type-checking, such as would be desirable to type-check C# or MSIL.
  • Another set can correspond to "weak" type-checking, which would be a looser type-checking than the "strong" type-checking.
  • the weak type- checking rule set could permit type casts.
  • a type cast is when a variable of one type is made to act like another for a single use. For instance, a variable of type int can be made to act like a char (character). The following code uses a type cast to print the letter 'P'.
  • a set can correspond to "representation" checking.
  • the "representation” checking can allow dropped type information in parts of the intermediate program representation, such as by using an unknown type, and can include rules that dictate when such type information can be dropped or when an unknown type can be substituted for another type. For instance, the result of a function that returns a value of type Void may be prohibited from being assigned to a variable of unknown type. Additionally, more than one set of rules can be used at a single stage of compilation.
  • FIG. 4 is a block diagram of a type-checker for use in a compiler system similar to that described in FIG. 3.
  • Type-checker 400 can accept as input any number of rules sets corresponding to different source languages and/or different stages of compilation. In FIG. 4, four rules sets 402-408 are provided to type-checker 400.
  • Rule set 402 represents a rule set for an HIR for languages with strong typing
  • rule set 404 represents a rule set for an HIR for languages with weak typing
  • rule set 406 represents a rule set for an HIR for languages with no typing
  • rule set 408 represents a rule set for an LIR.
  • Program module 410 represents a language with strong typing in a HIR
  • program module 412 represents program module 410 after being lowered to an LIR.
  • the type-checker 400 selects an appropriate rule set based on properties of the program module being type-checked and applies the selected rule set to the program module using an incorporated procedure or algorithm.
  • type-checker 400 may select rule set 402 (representing a rule set for an HIR for languages with strong typing) in order to type- check program module 410 (representing a language with strong typing in a HIR). Subsequently, the type-checker 400 may then select rule set 408 (representing a rule set for an LIR) in order to type-check program module 412 (representing a language with strong typing in a LIR).
  • FIG. 5 is a flowchart for one possible embodiment of a procedure for choosing a rule set to be applied by the type-checker.
  • a type-checker reads in a section of a typed intermediate representation of source code and must select a rule set for type-checking.
  • Decision 502 determines if the typed intermediate language is a HIR, MIR, or LIR. If it is a HIR or MIR, decision 504 is processed to determine if the original source code was loosely or strongly typed. If it was loosely typed, block 506 is processed to select a rule set corresponding to weak type-checking. If it was strongly typed, block 508 is processed to select a rule set corresponding to strong type-checking. If it is an LIR, decision block 510 is processed to select a rule set corresponding to representation type-checking. It should be noted that FIG. 5 is just one embodiment. Any number of rule sets can be selected, corresponding to and based on different properties.
  • the rule sets of the type-checking system described are easily extended to entirely new languages, and also to new features of existing languages. For instance, should a new language be introduced, a new rule set is simply authored for the new language. Since the rule sets are separate from the type-checker or compiler system itself and are designed to accept the rule sets as separate entities, new rule sets for new languages can be distributed without having to re-distribute or update existing type-checking systems or compilers. Likewise, if a new feature is added to an existing language, such as adding XML support to C + + for instance, the rule set corresponding to C+ + at the various stages of compilation can be easily reconfigured dynamically to handle the new feature. Again, no new core system need be updated or distributed.
  • the rule sets can also allow for constraints on types. For instance, whether sub- typing is allowed for a particular type when a class inherits from another may be a constraint described in the rules. Another constraint may be a boxed constraint, such as might be desired to indicate data can be converted into a virtual table containing the data. Others may include a size constraint, or a primitive type constraint indicating the necessity for identical types of primitives. Like any other part of the rule set, new constraints can be added as desired.
  • the set of rules used by the type-checker can be constructed through a programming interface to an application for authoring the rule sets. The application can construct the rules such that the rule set is represented in a hierarchy of type primitives with rules assigned to individual instructions of the typed intermediate language.
  • the hierarchy can be provided in the form of a type graph that will explicitly express various elements of types relevant to a particular program module or compilation unit.
  • the IR elements such as symbols and operations will be associated with elements of the type systems.
  • the type graph nodes will describe the primitive and constructed types and their relationships such as components, nested types, function signatures, interface types, elements of hierarchy and other information such as source names and references to module/assembly external type elements.
  • FIG. 6 shows the hierarchical relationship between these types.
  • Type N is at the top of the hierarchy.
  • the types F and X branch down from type N to form the subsequent level of the hierarchy.
  • types U and I branch down from the X type to form the lowest level of the hierarchy.
  • type rules have often been expressed programmatically using source code.
  • a type-checker may contain a large number of switch statements that implement the type-checker rules.
  • changing a rule required modifying the source code for the type-checker.
  • the hierarchical rule sets provide for much easier extensibility.
  • block 800 is processed to check the instruction syntactically.
  • the type-checker will ensure that the correct number of source and destination expressions exist according to the type rule for the ADD instruction (for example, in this case there are 2 source expressions and one destination expression). Each expression (and subexpression) may have an explicit type on it in the intermediate representation.
  • the type-checker will then actually verify that the explicit types for el, e2, and foo(e3) conform to the type rule for the ADD instruction.
  • the type-checker will traverse sub-levels if necessary to further type-check instructions. For instance, the type-checker can check that the expressions el, e2, and foo(e3) are consistent with their explicit types.
  • FIG. 9 illustrates an example of a computer system that serves as an operating environment for an embodiment of a type-checking system.
  • the computer system includes a personal computer 920, including a processing unit 921, a system memory 922, and a system bus 923 that interconnects various system components including the system memory to the processing unit 921.
  • the system bus may comprise any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using a bus architecture such as PCI, VESA, MicroChannel (MCA), ISA and EISA, to name a few.
  • the system memory includes read only memory (ROM) 924 and random access memory (RAM) 925.
  • ROM read only memory
  • RAM random access memory
  • the personal computer 920 further includes a hard disk drive 927, a magnetic disk drive 928, e.g., to read from or write to a removable disk 929, and an optical disk drive 930, e.g., for reading a CD-ROM disk 931 or to read from or write to other optical media.
  • the hard disk drive 927, magnetic disk drive 928, and optical disk drive 930 are connected to the system bus 923 by a hard disk drive interface 932, a magnetic disk drive interface 933, and an optical drive interface 934, respectively.
  • the drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer- executable instructions (program code such as dynamic link libraries, and executable files), etc. for the personal computer 920.
  • computer-readable media refers to a hard disk, a removable magnetic disk and a CD, it can also include other types of media that are readable by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, and the like.
  • a number of program modules may be stored in the drives and RAM 925, including an operating system 935, one or more application programs 936, other program modules 937, and program data 938.
  • a user may enter commands and information into the personal computer 920 through a keyboard 940 and pointing device, such as a mouse 942.
  • Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
  • serial port interface 949 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB).
  • a monitor 947 or other type of display device is also connected to the system bus 923 via an interface, such as a display controller or video adapter 948.
  • personal computers typically include other peripheral output devices (not shown), such as speakers and printers.
  • the personal computer 920 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 9 9.
  • the remote computer 949 may be a server, a router, a peer device or other common network node, and typically includes many or all of the elements described relative to the personal computer 920, although only a memory storage device 950 has been illustrated in FIG. 9.
  • the logical connections depicted in FIG. 9 include a local area network (LAN) 951 and a wide area network (WAN) 952.
  • LAN local area network
  • WAN wide area network
  • Such networking environments are commonplace in offices, enterprise- wide computer networks, intranets and the Internet.
  • the personal computer 920 When used in a LAN networking environment, the personal computer 920 is connected to the local network 951 through a network interface or adapter 953.
  • the personal computer 920 When used in a WAN networking environment, the personal computer 920 typically includes a modem 954 or other means for establishing communications over the wide area network 952, such as the Internet.
  • the modem 954 which may be internal or external, is connected to the system bus 923 via the serial port interface 946.
  • program modules depicted relative to the personal computer 920, or portions thereof, may be stored in the remote memory storage device.
  • the network connections shown are merely examples and other means of establishing a communications link between the computers may be used.
  • one embodiment herein describes one or more rule sets that can be supplied to a type-checker or compiler such that the compiler or type-checker chooses one or more of the rule sets to type-check a language based on the language and/or phase of compilation being type-checked.
  • a single set of rules can be supplied to a type-checker or compiler such that the compiler or type-checker constructs one or more subsets of rules from the single set of rules, either statically or dynamically at runtime, based on the language and/or phase of compilation being type-checked.
  • UnmgdArrayType public Type ⁇ public: // Public Static Constructors static Phx:: UnmgdArrayType * New Ph : TypeSystem * typeSystem, Phx: : BitSize bitSize, Phx :ExternalType * externalType, Ph -.Type * referentType ); public: // Public Properties DEFINE_GET_PROPERTY(int, Dim, dim); DEFINE_GET_PROPERTY(Phx::Type *, Referent, referent); private: // Private Fields int dim; Phx::Type * referent;
  • Phx: :PtrType * New Ph TypeSystem * typeSystem, Ph PtrTypeKind ptrTypeKind, Phx BitSize bitSize, Phx ExternalType * externalType
  • public // Public Properties DEFINE_GET_PROPERTY(Phx::PtrTypeKind, PtrTypeKind, ptrTypeKind); DEFINE_GET_PROPERTY(Phx::Type *, Referent, referent); private: // Private Fields Phx::PtrTypeKind ptrTypeKind; Phx::Type * referent; ⁇ ; till
  • ⁇ llegal 0, Class, Struct, Interface, Enum, MgdArray, UnmgdArray, Ptr, Func, Variable, Quantifier, Application, TypedRef,

Abstract

A representation of types, type-checker, and compiler are provided for checking consistency in various forms of an intermediate language (500 of fig. 5). Type-checking a programming language in a compiler is accomplished by taking one or more rule sets as input to a type-checker (502), which selects one or more of the rule sets based upon any one, or combination of two or more, of numerous criteria. Among them are stage of compilation, source language, architecture, and level of typing present in the language being type-checked. The language is then type-checked (502) using the selected one or more rule sets. The rule sets can include one rule set corresponding to strong type-checking (508), one rule set corresponding to weak type-checking (506), and one rule set corresponding to representation type-checking (510). In the alternative, a compiler can be provided with a type-checker that constructs the one or more sets of rules at runtime from a larger set of rules based on any one, or combination of two or more of the previously mentioned criteria.

Description

AN EXTENSIBLE TYPE SYSTEM FOR REPRESENTING AND CHECKING CONSISTENCY OF PROGRAM COMPONENTS DURING THE PROCESS OF COMPILATION TECHNICAL FIELD The present invention relates to type systems, and particularly, to a type system that is extensible to new and updated programming languages.
BACKGROUND A type system is a system used in programming languages to aid in the detection and prevention of run-time errors. A programming language is "typed" if it contains a set of types that are declared for objects such as variables, functions, etc., and these types are checked versus a set of rules during compilation of a program written in the language. If the source code written in the typed language violates one of the type rules, a compiler error is determined. Typed intermediate languages for use in compilers have received significant study in the research community over the past few years. They enhance the reliability and robustness of compilers, as well as provide a systematic way to track and check information needed by garbage collectors. The idea is to have an intermediate representation that has types attached to it and that can be type-checked in a manner analogous to type-checking for source programs. However, a typed intermediate language is more difficult to implement because types that represent items made explicit during the compilation process are necessary. A typed intermediate language is even more difficult to implement if it must represent a number of different high-level programming languages. The different languages not only have different primitive operations and types, but the high-level programming languages have different levels of typing. For instance, some languages, such as assembly languages, are generally untyped. In other words, they have no type system. Of the languages that are typed, some are strongly typed while others are more loosely typed. For instance, C+ + is generally considered a loosely typed language, whereas ML or Pascal are considered strongly typed languages. Further, some languages that are loosely typed have smaller sub-sets of the language that allow for a majority of the code sections within a program to be strongly typed, while other code sections are loosely typed. For example, C# and Microsoft Intermediate Language used in .NET (MSIL) allow this. Therefore, a typed intermediate language used to represent any of these high-level languages must be able to represent different types strengths. Likewise, the type system of such a typed intermediate language must be able to implement different rules depending on characteristics of the code being type checked. Another problem arises when a typed intermediate language is lowered throughout the process of compilation. The lowering of a language refers to the process of changing the form of a language from a higher level form, such as what a programmer would write, to a lower level, such as to an intermediate language. The language can then be further lowered from the intermediate language to levels closer to what a computer executes, such as machine- dependent native code. In order to type-check an intermediate language that is lowered to different levels during the compilation process, a different set of rules must be used for each representation. Attempts to create typed intermediate languages often fall short of solving the problems discussed above. For instance, Cedilla Systems' Special J compiler uses a typed intermediate language. However, this compiler is specific to the Java source language and therefore did not need to process multiple languages that may, for instance, have non-type-safe code. Additionally, this compiler only uses one set of rules for type-checking and therefore could not be used for multiple levels of compilation. In the research community, typed intermediate languages often tend to be highly specific to the source language and difficult to engineer (and design the types) for the multiple stages of compilation.
SUMMARY A representation of types, type-checker, method and compiler are provided for checking consistency in various forms of an intermediate language. Specifically, the typed intermediate language is suitable for use in representing programs written in multiple (heterogeneous) source languages including typed and untyped languages, loosely and strongly typed languages, and languages with and without garbage collection. Additionally, the type checker architecture is extensible to handle new languages with different types and primitive operations. The representation of types, type-checker, method and compiler include various aspects. The various aspects may be used separately and independently, or the various aspects may be used in various combinations and sub-combinations. In one aspect, a method of type-checking a programming language in a compiler is provided. One or more rule sets is taken as input to a type-checker, which selects one or more of the rule sets based upon any one, or combination of two or more, of numerous criteria. Among them are stage of compilation, source language, architecture, and level of typing present in the language being type-checked. The language is then type-checked using the selected one or more rule sets. In another aspect, a compiler is provided with a type-checker that constructs one or more sets of rules based on any one, or combination of two or more, of numerous criteria. The rule sets can include one rule set corresponding to strong type-checking, one rule set corresponding to weak type-checking, and one rule set corresponding to representation type- checking. The weak rule set can allow more flexibility in typing, such as allowing type casts, while the representation rule set can allow dropped type information in parts of the intermediate program representation. In another aspect, a programming interface is provided for constructing a plurality of rules for checking the consistency of an intermediate representation of a program. Checking the consistency of the intermediate representation can include providing a plurality of rules to a type-checker that applies a first set of rules to a one intermediate representation, and a second set of rules to a another intermediate representation, based on predetermined criteria. These and other aspects will become apparent from the following detailed description, which makes references to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a flow diagram of a generic compilation process. FIG. 2 is a table listing showing a conversion of a source code statement into an high- level representation, and then to a machine-dependent low-level representation. FIG. 3 is a data flow diagram illustrating one embodiment of a compiler system for type-checking a typed intermediate language at various stages of compilation. FIG. 4 is a block diagram of a type-checker for use in a compiler system. FIG. 5 is a flowchart for one possible procedure for choosing a rule set to be applied by a type-checker. FIG. 6 is a direct graph diagram showing a hierarchical relationship between types. FIG. 7 is a direct graph diagram showing the addition of a type to a hierarchical relationship between types. FIG. 8 is a flow chart of a method for checking an instruction against a type rule in a type-checking system. FIG. 9 is a block diagram of an example of a computer system that serves as an operating environment for an embodiment of a type-checking system. DETAD ED DESCRIPTION A representation of types, type-checker, and compiler are provided for checking consistency in various forms of an intermediate language. The type-checker and compiler allow use of different types and type-checking rules, depending on the source language for a program component and/or the stage of compilation. For example, it may be desirable to have a high-level optimizer apply to programs written in a variety of languages. These languages may have different primitive types and primitive operations. One language may contain types and operations for complex arithmetic, for example, whereas another language may contain types and operations specific to computer graphics. By allowing the intermediate representation to be parameterized by different type systems, the optimizer can be used for languages with different primitive types and operations. Another example can include a program where certain components are written in a strongly-typed subset of a language and other components are written in the full language, which is not type-safe. It is desirable to have more error checking for the first set of components. This can be accomplished by using different type-checking rules for the different components. Yet another example is dropping type information during compilation. The type-checker and compiler can allow type information to be dropped at later stages, while forcing precise information to be maintained during earlier stages. This can be accomplished by using an unknown type in combination with different type-checking rules for different stages of compilation. FIG. 1 shows a generic compilation process for a system utilizing a typed intermediate language with different levels of lowering for representing a number of different source languages. Source code 100-106 is written in four different source languages that may or may not be typed and have differing levels of type strength. For instance, source code 100 written in C# will be typed much stronger than source code 106 written in C + 4- for instance. Source code is first processed and entered into the system by a reader 108. The source language is then translated into a high-level intermediate representation of the typed intermediate language (HIR). The HIR can then optionally be analyzed and optimized at block 110. The HIR is then translated into a mid-level intermediate representation of the typed intermediate language (MIR). This representation is lower than the HIR but still machine independent. At this point, the MIR can optionally be analyzed and optimized as shown at block 112. The MIR is then translated into a machine-dependent low-level representation of the typed intermediate language (LIR) by code generation at block 114. LIR can then optionally be analyzed and optimized at block 116, and supplied to an emitter at block 118. The emitter will output code in one of many formats 120-126 representing the original source code read into the system. Throughout this process, the data necessary to complete the process is stored in some form of persistent memory 128. Thus, the compilation process consists of transforming the intermediate language instructions from one level of representation to another. For instance, Figure 2 shows the conversion of a source code statement into an HIR, as well as the conversion of the HIR to a machine-dependent LIR. Source code statement 200 can be written in a number of high-level programming languages. These languages are designed to allow programmers to write and read code in a manner that is easily understood. Thus, the programmer is allowed to use characters like ' + ' for addition, and allowed use of more powerful forms, such as adding more than two operands as shown in statement 200. Statements 202-206 are an HIR representation of statement 200 that represents the same functionality, but does so in a format closer to that as would be understood by a computer and yet still architecture independent. Statement 202 uses an 'ADD' command to add a first and second variable and assigns the result to a first temporary variable tl. Statement 204 then uses another 'ADD' command to add tl to the third variable and assigns the result to a second temporary variable t2. Statement 206 then assigns the value of t2 to the result variable z using an 'ASSIGN' instruction. Statements 208-212 are a LIR of the intermediate language of the statements 202-206.
Statement 208 uses an add instruction specific to the x86 architecture to add the values of two variables stored at specified registers and stores the result in a register assigned to a temporary variable tl. Statement 210 uses the add instruction specific to the x86 architecture to add the values of tl and a third variable stored at the specified registers and stores the result in the specified register (EAX) assigned to t2. Statement 212 then uses a move instruction specific to the x86 architecture to move the value stored in EAX to the output variable z. In order to implement type-checking, the typed intermediate language contains type representations expressed either explicitly or implicitly. An explicit type expression is declared directly in the representation. For example, the statement: int a; expressly defines the variable 'a' as type int. A type representation can be expressed implicitly by defining a default type for certain statements of code. For instance, if the default return type for functions is int, then the statement: f_start (); would declare a function f_start that takes no arguments and returns a value of type int. One embodiment of type representations for a typed intermediate language suitable for use with multiple programming languages at multiple levels of representation is shown in Appendix A. It should be noted that this is only an example of numerous possible embodiments. Referring to Appendix A, a number of type representations are defined in a type class hierarchy such that type systems of various languages can be represented by the typed intermediate language. An abstract base class is defined as 'Phx::Type' for all types. The base class can contain, for instance, size information in 'sizekind' for the various types, such as actual, symbolic or unknown (or variable) types. The base class can also contain 'typekind' in order to designate type classification. Additionally, an external type can be provided as an abstract type that wraps an externally defined type in order to provide back mapping from the typed intermediate language to the original source code. Below the base class, a class defined as 'Phx::PtrType' can represent pointer types. Various kinds of pointers can be defined as well. For instance, a managed, garbage collected pointer (points to a location within a garbage collected object), a managed, non-garbage collected pointer (points to a location within a non-garbage collected object), an unmanaged pointer (such as would be found in code written in C+ + , for instance), a reference pointer (points to the base of a garbage collected object), and null. At the same level in the hierarchy, a class defined as 'Phx::ContainerType' can represent container types, such as types that contain internal members. The internal members can have fields, methods and other types. A class defined as 'Phx: :FuncType' can represent function types, including any necessary calling conventions, lists of arguments and lists of return types. Also, a class defined as 'Phx::UnmgdArrayType' can represent unmanaged array types. Under 'Phx::ContainerType' in the hierarchy, four more classes can be defined. A class defined as 'Phx::ClassType' can represent class types, a class defined as
'Phx::StructType' can represent struct types, a class defined as 'Phx: :InterfaceType' can represent interface types, and a class defined as 'Phx: :EnumType' can represent enumerated types. Under Thx::ClassType' in the hierarchy, an additional class defined as 'Phx: :MgdArrayType' can represent managed array types. In the representations shown in Appendix A, a class 'primtype' is defined as a special instance of a struct type, 'primtype' can include various types such as int, float, unknown, void, condition code, unsigned int, xint, etc. These representations can be used in both a HIR or LIR of the typed intermediate language. Additionally, target specific primitive types can be included in the type representation. Some languages have complex arithmetic types that can be handled efficiently if the type system is made aware of them. Take for instance an 'MMX' instruction. Such an instruction is one of a set of extra instructions built into some versions of x86 processors for supporting single instruction/multiple data operations on multimedia and communications data types. The type system can be customized to recognize and use these instructions with minimal alteration of the type representations. The embodiment of the type representation of types shown in Appendix A also includes an "unknown" type, which can represent any type and optionally has a size associated with it. The size is the size of the machine representation of the value. An unknown type allows a compiler to drop type information in a controlled manner by changing the type information from a specific type to an unknown type. It allows the compiler to generate code that depends on the size of the value being manipulated, even when the type is unknown. Other types may use unknown types, so the unknown type also allows the representation of partial type information (where some but not all information is known). For instance, assume a pointer to an int type. At some stage of lowering, it may be desirable to drop the type information, int. The unknown type allows the compiler to replace the int type with the unknown type. The type-checker then need not check that the pointer of interest is pointing to a correct type. It essentially takes the chance the value pointed to will be handed in such a manner as to not adversely affect the program functionality at runtime. Another example of using an unknown type is for defining a type for a function. If a function with an argument of type pointer to unknown is called, where the argument previously had the type pointer to int, the compiler must trust that right type is being passed. The result of dereferencing the pointer may or may not be known to be an int; however, it will be used as an int. A more complex example is the introduction of an intermediate temporary variable during the conversion from high-level to low-level intermediate representation of a virtual function call. Virtual tables (vtables) are widely used to implement virtual calls in object-oriented languages. The first step in making a virtual function call in the low-level intermediate representation is to fetch the first field of an object of memory. The first field contains a pointer to a viable. The result of fetch is then assigned to a temporary variable. Constructing the type of the temporary variable (a type that represents a pointer to a vtable, where the vtable may have many fields), may be complex and burdensome to represent. Instead, the compiler may simply assign the intermediate temporary variable "pointer to unknown." Thus, the use of the unknown type simplifies latter stages of compilation where keeping detailed type information is unnecessary or may represent a significant burden to the compiler implementer. FIG. 3 illustrates one embodiment of a compiler system for type-checking a typed intermediate language at various stages of compilation, and therefore, type-checking a typed intermediate language at various levels of lowering. Source code 300 represents any one of a variety of source languages. The source code 300 is translated into a HIR of the typed intermediate language 302. In doing so, the types representations of the source language are translated into the type representations internal to the typed intermediate language. The HIR, as explained with respect to FIGs. 1 and 2, is lowered throughout the compilation process. For purposes of this illustration, a high (HIR) 302, mid (MIR) 304, and low (LIR) 306 level representations are shown. However, the embodiment is not so limited. Any number of stages of compilation may be type-checked. The intermediate language at each level of representation may be type-checked by type-checker 308. The type-checker 308 implements an algorithm or procedure for applying one or more rule sets 310 to each stage of the compilation process, and therefore to each representation of the intermediate language. The rule sets 310 are a set of rules designed for varying properties of languages, such as the source language, stage of compilation, what strength of typing, etc. For example, assume source code 300 contains code authored in the C+ + programming language. The C + + source code 300 is first translated into an HIR 302 of the typed intermediate language. If desired, at this point the type-checker 308 can interact with the HIR 302 in order to determine any number of properties. Such properties might include the stage of compilation (HIR), the type of source code present (C+ +), whether or not the language is typed (yes), whether it is loosely or strongly typed (loosely), etc. Based on the properties, the type-checker can select an appropriate set of rules. Once a rule set is selected, the type-checker type-checks the HIR according to that set of rules. Once the HIR is lowered to MIR or LIR, the properties will be accessed again and the same or a different set of rules may be appropriate. In one embodiment, three sets of type-checking rules can be supplied to the type- checker. One set can correspond to "strong" type-checking, such as would be desirable to type-check C# or MSIL. Another set can correspond to "weak" type-checking, which would be a looser type-checking than the "strong" type-checking. For instance, the weak type- checking rule set could permit type casts. A type cast is when a variable of one type is made to act like another for a single use. For instance, a variable of type int can be made to act like a char (character). The following code uses a type cast to print the letter 'P'.
int a; a = 80; cout< < (char) a;
Thus, even though 'a' is defined as type int and assigned the value 80, the cout statement will treat the variable 'a' as type char due to the type cast and therefore display a 'P' (ASCII value 80) rather than 80. Lastly, a set can correspond to "representation" checking. The "representation" checking can allow dropped type information in parts of the intermediate program representation, such as by using an unknown type, and can include rules that dictate when such type information can be dropped or when an unknown type can be substituted for another type. For instance, the result of a function that returns a value of type Void may be prohibited from being assigned to a variable of unknown type. Additionally, more than one set of rules can be used at a single stage of compilation.
For instance, assume the source code 300 contains a single language, but contains sections that are strongly typed and some sections that are loosely typed. The type-checker can use one set of rules for the HIR at certain strongly typed sections, and another set of rules for code sections that are loosely typed. FIG. 4 is a block diagram of a type-checker for use in a compiler system similar to that described in FIG. 3. Type-checker 400 can accept as input any number of rules sets corresponding to different source languages and/or different stages of compilation. In FIG. 4, four rules sets 402-408 are provided to type-checker 400. Rule set 402 represents a rule set for an HIR for languages with strong typing, rule set 404 represents a rule set for an HIR for languages with weak typing, rule set 406 represents a rule set for an HIR for languages with no typing, and rule set 408 represents a rule set for an LIR. Program module 410 represents a language with strong typing in a HIR, and program module 412 represents program module 410 after being lowered to an LIR. The type-checker 400 selects an appropriate rule set based on properties of the program module being type-checked and applies the selected rule set to the program module using an incorporated procedure or algorithm. For instance, type-checker 400 may select rule set 402 (representing a rule set for an HIR for languages with strong typing) in order to type- check program module 410 (representing a language with strong typing in a HIR). Subsequently, the type-checker 400 may then select rule set 408 (representing a rule set for an LIR) in order to type-check program module 412 (representing a language with strong typing in a LIR). FIG. 5 is a flowchart for one possible embodiment of a procedure for choosing a rule set to be applied by the type-checker. At block 500, a type-checker reads in a section of a typed intermediate representation of source code and must select a rule set for type-checking. Decision 502 determines if the typed intermediate language is a HIR, MIR, or LIR. If it is a HIR or MIR, decision 504 is processed to determine if the original source code was loosely or strongly typed. If it was loosely typed, block 506 is processed to select a rule set corresponding to weak type-checking. If it was strongly typed, block 508 is processed to select a rule set corresponding to strong type-checking. If it is an LIR, decision block 510 is processed to select a rule set corresponding to representation type-checking. It should be noted that FIG. 5 is just one embodiment. Any number of rule sets can be selected, corresponding to and based on different properties. The rule sets of the type-checking system described are easily extended to entirely new languages, and also to new features of existing languages. For instance, should a new language be introduced, a new rule set is simply authored for the new language. Since the rule sets are separate from the type-checker or compiler system itself and are designed to accept the rule sets as separate entities, new rule sets for new languages can be distributed without having to re-distribute or update existing type-checking systems or compilers. Likewise, if a new feature is added to an existing language, such as adding XML support to C + + for instance, the rule set corresponding to C+ + at the various stages of compilation can be easily reconfigured dynamically to handle the new feature. Again, no new core system need be updated or distributed. The rule sets can also allow for constraints on types. For instance, whether sub- typing is allowed for a particular type when a class inherits from another may be a constraint described in the rules. Another constraint may be a boxed constraint, such as might be desired to indicate data can be converted into a virtual table containing the data. Others may include a size constraint, or a primitive type constraint indicating the necessity for identical types of primitives. Like any other part of the rule set, new constraints can be added as desired. The set of rules used by the type-checker can be constructed through a programming interface to an application for authoring the rule sets. The application can construct the rules such that the rule set is represented in a hierarchy of type primitives with rules assigned to individual instructions of the typed intermediate language. The hierarchy can be provided in the form of a type graph that will explicitly express various elements of types relevant to a particular program module or compilation unit. The IR elements such as symbols and operations will be associated with elements of the type systems. The type graph nodes will describe the primitive and constructed types and their relationships such as components, nested types, function signatures, interface types, elements of hierarchy and other information such as source names and references to module/assembly external type elements. An example of a simple type rule is as follows: ADD N= add n, n Assume for purpose of this example that I is a signed integer type, U is an unsigned integer type, X is either type of integer, F is float, and N is any of the above. FIG. 6 shows the hierarchical relationship between these types. Type N is at the top of the hierarchy. The types F and X branch down from type N to form the subsequent level of the hierarchy. Lastly, types U and I branch down from the X type to form the lowest level of the hierarchy. Thus, for an 'ADD' intermediate language instruction, according to this rule only type N or lower in the hierarchy can be processed by the add instruction, and the operands must be no higher on the hierarchy than the result. For instance, two integers can be added to produce an integer (I=ADD i, i), or an integer and a float can be added to produce a float (F=ADD i, f). However, a float and an integer cannot be added to produce an integer (I=ADD i, f). Representing the type primitives as hierarchies allows the rule sets to be altered easily. In the past, type rules have often been expressed programmatically using source code. For example, a type-checker may contain a large number of switch statements that implement the type-checker rules. Thus, changing a rule required modifying the source code for the type-checker. However, the hierarchical rule sets provide for much easier extensibility. Consider the previous rule for the ADD instruction. If a developer wanted to add a type, for instance C for a complex type, it can simply be added under the N type in the hierarchy as shown in FIG. 7 and the rule for the ADD instruction need not be altered to function as desired. One method for checking an instruction in a type checking system against a type rule is shown in FIG. 8. First, block 800 is processed to check the instruction syntactically. Thus, considering the instruction at 806, the type-checker will ensure that the correct number of source and destination expressions exist according to the type rule for the ADD instruction (for example, in this case there are 2 source expressions and one destination expression). Each expression (and subexpression) may have an explicit type on it in the intermediate representation. At block 802, the type-checker will then actually verify that the explicit types for el, e2, and foo(e3) conform to the type rule for the ADD instruction. At block 804, the type-checker will traverse sub-levels if necessary to further type-check instructions. For instance, the type-checker can check that the expressions el, e2, and foo(e3) are consistent with their explicit types. For instance, the type-checker may check that foo has a function type. It may check that the result type of the function type is the same as the explicit type on foo(e3). It may further check that there is a single argument type and that the type e3 matches that type. This ensures that the type of the call to e3 is consistent with type rules. FIG. 9 illustrates an example of a computer system that serves as an operating environment for an embodiment of a type-checking system. The computer system includes a personal computer 920, including a processing unit 921, a system memory 922, and a system bus 923 that interconnects various system components including the system memory to the processing unit 921. The system bus may comprise any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using a bus architecture such as PCI, VESA, MicroChannel (MCA), ISA and EISA, to name a few. The system memory includes read only memory (ROM) 924 and random access memory (RAM) 925. A basic input/output system 926 (BIOS), containing the basic routines that help to transfer information between elements within the personal computer 920, such as during startup, is stored in ROM 924. The personal computer 920 further includes a hard disk drive 927, a magnetic disk drive 928, e.g., to read from or write to a removable disk 929, and an optical disk drive 930, e.g., for reading a CD-ROM disk 931 or to read from or write to other optical media. The hard disk drive 927, magnetic disk drive 928, and optical disk drive 930 are connected to the system bus 923 by a hard disk drive interface 932, a magnetic disk drive interface 933, and an optical drive interface 934, respectively. The drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer- executable instructions (program code such as dynamic link libraries, and executable files), etc. for the personal computer 920. Although the description of computer-readable media above refers to a hard disk, a removable magnetic disk and a CD, it can also include other types of media that are readable by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, and the like. A number of program modules may be stored in the drives and RAM 925, including an operating system 935, one or more application programs 936, other program modules 937, and program data 938. A user may enter commands and information into the personal computer 920 through a keyboard 940 and pointing device, such as a mouse 942. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 921 through a serial port interface 949 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). A monitor 947 or other type of display device is also connected to the system bus 923 via an interface, such as a display controller or video adapter 948. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The personal computer 920 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 9 9. The remote computer 949 may be a server, a router, a peer device or other common network node, and typically includes many or all of the elements described relative to the personal computer 920, although only a memory storage device 950 has been illustrated in FIG. 9. The logical connections depicted in FIG. 9 include a local area network (LAN) 951 and a wide area network (WAN) 952. Such networking environments are commonplace in offices, enterprise- wide computer networks, intranets and the Internet. When used in a LAN networking environment, the personal computer 920 is connected to the local network 951 through a network interface or adapter 953. When used in a WAN networking environment, the personal computer 920 typically includes a modem 954 or other means for establishing communications over the wide area network 952, such as the Internet. The modem 954, which may be internal or external, is connected to the system bus 923 via the serial port interface 946. In a networked environment, program modules depicted relative to the personal computer 920, or portions thereof, may be stored in the remote memory storage device. The network connections shown are merely examples and other means of establishing a communications link between the computers may be used. Having illustrated and described the principles of the illustrated embodiments, it will be apparent to those skilled in the art that the embodiments can be modified in arrangement and detail without departing from such principles. For instance, one embodiment herein describes one or more rule sets that can be supplied to a type-checker or compiler such that the compiler or type-checker chooses one or more of the rule sets to type-check a language based on the language and/or phase of compilation being type-checked. However, in the alternative, a single set of rules can be supplied to a type-checker or compiler such that the compiler or type-checker constructs one or more subsets of rules from the single set of rules, either statically or dynamically at runtime, based on the language and/or phase of compilation being type-checked. In view of the many possible embodiments, it will be recognized that the illustrated embodiments include only examples and should not be taken as a limitation on the scope of the invention. Rather, the invention is defined by the following claims. We therefore claim as the invention all such embodiments that come within the scope of these claims.
Appendix A ti-// ll Description: II II IR types II II II Type Class Hierarchy Description & Primary Properties Introduced II II Phx: :Type - Abstract base class for types II Phx::PtrType - Pointer types II Phx::ContainerType - Container types (types that have members) II Phx::ClassType - Class types II Phx: :MgdArrayType - Managed array types II Phx: :StructType - Struct types II Phx::InterfaceType - Interface types II Phx: :EnumType - Enumerated types II Phx: :FuncType - Function types II Properties: ArgTypes, ReturnType II II Phx::UnmgdArrayType - Unmanaged arrays II Properties: Dim, Referent II
II
//
//
// Description:
//
// Base class for IR types
//
// abstract public gc class Type : public Phx:: Object { public: // Functions for comparing types. virtual Boolean IsAssignable(Phx: :Type * srcType); virtual Boolean IsEqual(Phx::Type * type); public: // Public Properties DEFINE_GET_PROPERTY(Phx TypeKind, TypeKind, typeKind); DEFINE_GET_PROPERTY(Phx SizeKind, SizeKind, sizeKind); DEFINE_GET_PROPERTY(Phx BitSize, BitSize, bitSize); DEFINE_GET_PROPERTY(Symbols::ConstSym *, ConstSym, constSym); DEFINE_GET_PROPERTY(Phx::ExternalType *, ExternalType, externalType); DEFINE_GET_PROPERTY(Phx::PrimTypeKindNum, PrimTypeKind, primTypeKind); GET_PROPERTY(Phx::TypeSystem *, TypeSystem); protected: // Protected Fields Phx: -.TypeKind typeKind; // type classification Phx:: SizeKind sizeKind; // size classification Phx: :BitSize bitSize; // size in bits when constant Symbols:: ConstSym * constSym; // size in bits when symbolic Phx::PrimTypeKindNum primTypeKind; Phx: -.ExternalType * externalType; // optionally null };
//
//
// Description: //
// Container Type - Abstract class for types that have members.
//
// abstract public gc class ContainerType : public QuantifiedType, public IScope { DEFINE_PROPERTY(Symbols::FieldSym *, FieldSymList, fieldSymList); private: // Private Fields Symbols: :FieldSym * fieldSymList;
}; //
//
// Description: //
// Class Container Type //
// public gc class ClassType : public ContainerType { public: // Public Static Constructors static Phx:: ClassType * New ( Phx TypeSystem * typeSystem, Phx BitSize bitSize, Phx: ExternalType * externalType ); public: // Public Properties DEFINE_GET_PROPERTY(Phx::Type *, UnboxedType, unboxedType); DEFINE_PROPERTY( ClassType *, ExtendsClassType, extendsClassType); DEFINE_GET_PROPERTY(Phx: : Collections : :InterfaceTypeList * , Explicitlylmplements , explicitlylmplements) ; protected: // Protected Properties DEFINE_SET_PROPERTY(Phx: Collections: : Inter faceTypeList *, Explicitlylmplements , explicitlylmplements); private: // Private Fields Phx :Type * unboxedType; Phx : ClassType * extendsClassType; Phx Collections: :InterfaceTypeList * explicitlylmplements;
}; //
//
// Class: StructType //
// Description: //
// Type of structs. //
//
// public gc class StructType : public ContainerType { public: // Public Static Constructors static Phx:: StructType * New ( Phx:: TypeSystem * typeSystem, Phx::BitSize bitSize, Phx::ExternalType * externalType ); public: // Public Properties DEFINE_GET_PROPERTY(Phx:: ClassType *, BoxedType, boxedType); private: // Private Fields Phx::ClassType * boxedType;
}; //
//
// Class: PrimType //
// Description: //
// Primitive types
//
// public gc class PrimType : public StructType
{ public: // Public Static Constructors static Phx::PrimType * New ( Phx TypeSystem * typeSystem, Phx PrimTypeKindNum primTypeKind, Phx BitSize bitSize, Phx ExternalType * externalType ); public: // Public Methods static Phx: -.PrimType * GetScratch ( Phx::PrimType * type, PrimTypeKindNum kind, Phx: :BitSize bitSize ); Phx:: PrimType * GetResized ( Phx: -.BitSize bitSize ); public: // Public Properties DEFINE_GET_PROPERTY(Phx::TypeSystem *, TypeSystem, typeSystem); private: // Private Fields Phx: :TypeSystem * typeSystem;
};
//
// // Class: InterfaceType //
// Description: // // Interface types //
// public gc class InterfaceType : public ContainerType { public: // Public Static Constructors static Phx::InterfaceType * New ( Phx::TypeSystem * typeSystem, Phx: :ExternalType * externalType ); public: // Public Properties DEFINE_PROPERTY( Phx:: ClassType *, ExtendsClassType, extendsClassType); DEFINE_GET_PROPERTY(Phx: Collections: :InterfaceTypeList *, Explicitlylmplements , explicitlylmplements) ; protected: // Protected Properties DEFINE_SET_PR0PERTY(Phx: Collections: :InterfaceTypeList *, Explicitlylmplements , explicitlylmplements) ; private: // Private Fields Phx: ClassType * extendsClassType; Phx: Collections: :InterfaceTypeList * explicitlylmplements;
}; till
II Class: EnumType // // Description: // // Enumeration types
//
// public gc class EnumType : public ContainerType
{ public: // Public Static Constructors static Phx::EnumType * New ( Phx: :TypeSystem * typeSystem, Phx::ExternalType * externalType, Phx: :Type * underLyingType ); public: // Public Properties DEFINE_GET_PROPERTY(Phx: ClassType *, BoxedType, boxedType); DEFINE_GET_PROPERTY(Phx::Type *, UnderlyingType, underlymgType); private: // Private Fields Phx: -.Type * underlymgType; Phx: ClassType * boxedType;
}; //
//
// Class: MgdArrayType
//
// Description:
//
// Managed array types.
//
//
// public gc class MgdArrayType : public ClassType
{ public: // Public Static Constructors static Phx: :MgdArrayType * New ( Phx: TypeSystem * typeSystem, Phx ExternalType * externalType, Phx Type * elementType ); public: // Public Properties DEFINE_GET_PROPERTY(Phx::Type *, ElementType, elementType); private: // Private Fields Phx::Type * elementType;
};
//
//
// Class: UnmgdArrayType
//
// Description:
//
// Unmanaged array types.
//
//
//
_public gc class UnmgdArrayType : public Type { public: // Public Static Constructors static Phx:: UnmgdArrayType * New Ph : TypeSystem * typeSystem, Phx: : BitSize bitSize, Phx :ExternalType * externalType, Ph -.Type * referentType ); public: // Public Properties DEFINE_GET_PROPERTY(int, Dim, dim); DEFINE_GET_PROPERTY(Phx::Type *, Referent, referent); private: // Private Fields int dim; Phx::Type * referent;
};
//
//
// Description: //
// Pointer types //
//
// public gc class PtrType : public Type { public: // Public Static Constructors static Phx: -.PtrType * New ( Phx::TypeSystem * typeSystem, Phx::PtrTypeKind ptrTypeKind, Phx::BitSize bitSize, Phx:: Type * referent, Phx: : ExternalType * externalType ); // Constructor without type pointed to. static Phx: :PtrType * New ( Ph TypeSystem * typeSystem, Ph PtrTypeKind ptrTypeKind, Phx BitSize bitSize, Phx ExternalType * externalType ); public: // Public Properties DEFINE_GET_PROPERTY(Phx::PtrTypeKind, PtrTypeKind, ptrTypeKind); DEFINE_GET_PROPERTY(Phx::Type *, Referent, referent); private: // Private Fields Phx::PtrTypeKind ptrTypeKind; Phx::Type * referent; }; till
II Enum: CallingConvention //
// Description:
//
// A preliminary enum to represent calling convention types.
// //
BEGIN_ENUM(CallmgConventionKind)
{ llegal = 0, CLRCall, CDecl, StdCall, ThisCall, FastCall }
END_ENUM(CallingConventionKind);
//
// // Class: FuncType //
// Description: // // Function types. // // //- public gc class FuncType : public QuantifiedType
{ public: // Public Static Constructors public: // Public Methods Int32 CountArgsO; Int32 CountRetsO; Int32 CountAr gsForlnstr () ; Int32 CountRetsForlnstr 0 ; Int32 CountUserDefinedArgsO; Int32 CountUserDefinedRetsO ; Phx FuncArg * GetNthArgFuncArg(Int32 index); Phx: FuncArg * GetNthRetFuncArg(Int32 index); Phx FuncArg * GetNthArgFuncArgForInstr(Int32 index); Phx: FuncArg * GetNthRetFuncArgForInstr(Int32 index); Phx FuncArg * GetNthUserDefinedArgFuncArg(Int32 index); Phx: FuncArg * GetNthUserDefinedRetFuncArg(Int32 index); Phx Type * GetNthArgType(Int32 index); Phx: Type* GetNfhRetType(Int32 index); Type * GetNthArgTypeForInstr(Int32 index) ; Phx: Type * GetNthRetTypeForInstr(Int32 index); Phx Type * GetNthUserDefinedArgType(Int32 index) ; Phx Type* GetNthUserDefinedRetType(Int32 index) ; public: // Public Properties DEFINE_GET_PROPERTY(Phx:CallingConventionKind, CallingConvention, callingConvention) ; GET_PROPERTY(Phx::Type *, RetType); // True if this function type has an ellipsis funcarg. GET_PROPERTY(Boolean, IsVarArgs); GET_PROPERTY(Boolean, IsInstanceMethod) ; GET_PROPERTY(Boolean, IsClrCall); GET_PROPERTY(Boolean, IsCDecl); GET_PROPERTY(Boolean, IsStdCall); GET_PROPERTY(Boolean, IsThisCall); GET PROPERTY(Boolean, IsFastCall); // Not True if this function has a return value. GET_PROPERTY(Boolean, ReturnsVoid); protected: // Protected Fields Phx: : CallingConventionKind callingConvention; Phx::FuncArg * argFuncArgs; Phx: : FuncArg * retFuncArgs;
};
//
// // Description:
//
// The global type system used during compilation.
//
// // public gc class TypeSystem : public Phx:: Object
{ public: // Public Static Constructors static TypeSystem * New ( Phx: BitSize reglntBitSize, Phx BitSize nativelntBitSize, Phx: BitSize nativePtrBitSize, Ph BitSize nativeFloatBitSize, ); public: // Public Methods void Add(Type * type); public: // lists of created types DEFINE_GET_PROPERTY(Phx: :Type * , AUTypes , allTypes) ; private: // List of all types in the system. Phx::Type * allTypes;
};
// //
// Description: //
// Various enums to describe types. // //
// Classes and value types for IR types // The different kinds of types.
BEGIN_ENUM(TypeKind)
{ llegal = 0, Class, Struct, Interface, Enum, MgdArray, UnmgdArray, Ptr, Func, Variable, Quantifier, Application, TypedRef,
}
END_ENUM(TypeKind);
// The different kinds of type sizes.
BEGIN JENUM(SizeKind)
{ Jllegal = 0, Constant, Symbolic, Unknown
}
END_ENUM(SizeKind); // The different types of pointers
BEGIN_ENUM(PtrTypeKind)
{ Jllegal = 0, ObjPtr, // gc pointer to object whole. MgdPtr, // gc pointer to object interior. UnmgdPtr, // nogc pointer. NullPtr, // pointer to nothing. _NumPtrTypeKinds } END_ENUM(PtrTypeKind);
}

Claims

We Claim:
1. A method of type-checking a programming language in a compiler according to one or more rule sets comprising: selecting one or more of the rule sets based upon the present stage of compilation; and type-checking the programming language based on the selected one or more rule sets.
2. The method of claim 1 wherein selecting one or more of the rule sets is based upon a characteristic of the programming language rather than the stage of compilation.
3. The method of claim 2 wherein the characteristic of the programming language describes the type system of the language.
4. The method of claim 1 wherein type-checking the programming language comprises type-checking each of a plurality of intermediate representations of the programming language.
5. The method of claim 4 wherein the selected one or more rule sets are different for each representation.
6. The method of claim 4 wherein selecting one or more of the rule sets is based upon a characteristic of the representation being type-checked rather than the stage of compilation.
7. The method of claim 1 wherein the programming language includes a type that indicates an element of the programming language can be one of a plurality of types.
8. The method of claim 7 wherein the one or more rule sets contains rules for type-checking a type that indicates an element of the programming language can be one of a plurality of types.
9. The method of claim 1 wherein the one or more rule sets comprise a plurality of rules in a hierarchical format.
10. The method of claim 1 wherein the one or more rule sets comprise one rule set corresponding to strong type-checking, one corresponding to weak type-checking, and one corresponding to representation type-checking.
11. The method of claim 10 wherein the representation type-checking will allow dropped type information for elements of the programming language.
12. The method of claim 10 wherein the weak type-checking will allow type casting.
13. A compiler for compiling source code written in a source language comprising: a plurality of type rules; a type-checker that selects a subset of type rules from the plurality of type rules based upon the source language to construct a rule set.
14. The compiler of claim 13 wherein the subset of type rules is selected based upon an intermediate representation of the source code rather than the source language.
15. The compiler of claim 13 wherein subset of type rules is selected based upon a stage of compilation rather than the source language.
16. The compiler of claim 13 wherein three rule sets are constructed: one corresponding to strong type-checking, one corresponding to weak type-checking, and one corresponding to representation type-checking.
17. The compiler of claim 16 wherein the representation type-checking will allow dropped type information for elements of the source code.
18. The compiler of claim 16 wherein the weak type-checking will allow type casting.
19. A type-checking system for type-checking source code authored in a plurality of source languages comprising: a plurality of rule sets; and a type-checker, wherein the type-checker selects one or more rule sets to apply to the source code at each of a plurality of representations.
20. The system of claim 19 wherein the selected one or more rule sets is selected based on one or more characteristics of the source language.
21. The system of claim 19 wherein the type-checker is part of a compiler.
22. The system of claim 19 wherein each of the plurality of rule sets corresponds to a specific source language.
23. The system of claim 19 wherein each of the plurality of rule sets corresponds to a specific strength of type-checking.
24. A method of analyzing source code represented as a typed intermediate representation in a compiler comprising: selecting a rule set from among different rule sets based on the typed intermediate representation; and analyzing the typed intermediate representation based on the selected rule set.
25. The method of claim 24 wherein selecting a rule set is based on which step in a series of steps in a compilation process produced the typed intermediate representation.
26. The method of claim 24 wherein selecting a rule set is based on a source language from which the typed intermediate representation was produced.
27. The method of claim 24 wherein selecting a rule set is based on a processor architecture.
28. The method of claim 24 wherein selecting a rule set is based on a whether the typed intermediate representation represents verified or unverified code.
29. The method of claim 24 wherein selecting a rule set is based on a whether the typed intermediate representation represents type-safe code or code that is not type-safe.
30. The method of claim 24 wherein selecting a rule set is based on a whether the typed intermediate representation represents typed or untyped code.
31. The method of claim 24 wherein selecting a rule set is based on a whether the typed intermediate representation represents strongly or weakly typed code.
32. A computer-readable medium containing computer-executable instructions for implementing the method of claim 24.
33. A programming interface comprising: a means for constructing a plurality of rules for checking the consistency of an intermediate representation of a program, wherein checking the consistency of the intermediate representation of a program comprises providing a plurality of rules to a type- checker operable to apply a first set of the plurality of rules to a first intermediate representation, and a second set of the plurality of rules to a second intermediate representation.
34. A computer-readable medium containing computer-executable instructions for implementing the method of claim 1.
PCT/US2004/015964 2003-06-27 2004-05-21 An extensible type system for representing and checking consistency of program components during the process of compilation WO2005006119A2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP04752897A EP1639461A4 (en) 2003-06-27 2004-05-21 An extensible type system for representing and checking consistency of program components during the process of compilation
KR1020057025045A KR101086082B1 (en) 2003-06-27 2004-05-21 An extensible type system for representing and checking consistency of program components during the process of compilation
JP2006517130A JP4794437B2 (en) 2003-06-27 2004-05-21 An extended system for representing and checking the integrity of program components during the editing process

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/607,601 2003-06-27
US10/607,601 US7086041B2 (en) 2003-06-27 2003-06-27 Extensible type system for representing and checking consistency of program components during the process of compilation

Publications (2)

Publication Number Publication Date
WO2005006119A2 true WO2005006119A2 (en) 2005-01-20
WO2005006119A3 WO2005006119A3 (en) 2005-12-29

Family

ID=33540309

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2004/015964 WO2005006119A2 (en) 2003-06-27 2004-05-21 An extensible type system for representing and checking consistency of program components during the process of compilation

Country Status (7)

Country Link
US (2) US7086041B2 (en)
EP (1) EP1639461A4 (en)
JP (1) JP4794437B2 (en)
KR (1) KR101086082B1 (en)
CN (1) CN100474252C (en)
TW (1) TWI416412B (en)
WO (1) WO2005006119A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7870542B1 (en) 2006-04-05 2011-01-11 Mcafee, Inc. Calling system, method and computer program product

Families Citing this family (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7086041B2 (en) * 2003-06-27 2006-08-01 Microsoft Corporation Extensible type system for representing and checking consistency of program components during the process of compilation
US7818729B1 (en) * 2003-09-15 2010-10-19 Thomas Plum Automated safe secure techniques for eliminating undefined behavior in computer software
US7810080B2 (en) * 2003-09-15 2010-10-05 Thomas Plum Automated safe secure techniques for eliminating undefined behavior in computer software
US7856624B2 (en) * 2003-09-15 2010-12-21 Thomas Plum Automated safe secure techniques for eliminating undefined behavior in computer software
US7657874B2 (en) * 2004-08-24 2010-02-02 Microsoft Corporation Pattern types as constraints on generic type parameters
US7730465B2 (en) * 2004-10-22 2010-06-01 Microsoft Corporation Mixed types
US7512938B2 (en) * 2005-03-18 2009-03-31 Microsoft Corporation Typed intermediate representation for object-oriented languages
US20060212847A1 (en) * 2005-03-18 2006-09-21 Microsoft Corporation Type checker for a typed intermediate representation of object-oriented languages
US7702686B2 (en) * 2005-07-29 2010-04-20 Microsoft Corporation Retrieving and persisting objects from/to relational databases
US20070044083A1 (en) * 2005-07-29 2007-02-22 Microsoft Corporation Lambda expressions
US20070027905A1 (en) * 2005-07-29 2007-02-01 Microsoft Corporation Intelligent SQL generation for persistent object retrieval
US7685567B2 (en) * 2005-07-29 2010-03-23 Microsoft Corporation Architecture that extends types using extension methods
US20070027849A1 (en) * 2005-07-29 2007-02-01 Microsoft Corporation Integrating query-related operators in a programming language
US7631011B2 (en) * 2005-07-29 2009-12-08 Microsoft Corporation Code generation patterns
US7353504B2 (en) * 2005-12-09 2008-04-01 Bea Systems, Inc. System and method for efficiently generating native code calls from byte code in virtual machines
US7958493B2 (en) * 2006-01-20 2011-06-07 Kevin Edward Lindsey Type inference system and method
US8171461B1 (en) * 2006-02-24 2012-05-01 Nvidia Coporation Primitive program compilation for flat attributes with provoking vertex independence
US8225294B2 (en) * 2006-04-27 2012-07-17 Oracle America, Inc. Method and apparatus for expressing and checking relationships between types
US8365157B2 (en) * 2006-11-09 2013-01-29 Oracle International Corporation System and method for early platform dependency preparation of intermediate code representation during bytecode compilation
US8255887B2 (en) * 2006-11-29 2012-08-28 International Business Machines Corporation Method and apparatus for re-using memory allocated for data structures used by software processes
US20080141230A1 (en) * 2006-12-06 2008-06-12 Microsoft Corporation Scope-Constrained Specification Of Features In A Programming Language
US8850414B2 (en) * 2007-02-02 2014-09-30 Microsoft Corporation Direct access of language metadata
US7805456B2 (en) * 2007-02-05 2010-09-28 Microsoft Corporation Query pattern to enable type flow of element types
US7865533B2 (en) * 2007-02-05 2011-01-04 Microsoft Corporation Compositional query comprehensions
US8490051B2 (en) * 2007-02-28 2013-07-16 Microsoft Corporation Generic interface for numeric types
US8079023B2 (en) * 2007-03-22 2011-12-13 Microsoft Corporation Typed intermediate language support for existing compilers
US20080282238A1 (en) * 2007-05-10 2008-11-13 Microsoft Corporation Static type for late binding
US8321847B1 (en) 2007-05-17 2012-11-27 The Mathworks, Inc. Dynamic function wizard
US8060868B2 (en) * 2007-06-21 2011-11-15 Microsoft Corporation Fully capturing outer variables as data objects
US8032870B2 (en) * 2007-06-25 2011-10-04 Microsoft Corporation Transacting accesses via unmanaged pointers
US8196121B2 (en) * 2007-08-23 2012-06-05 International Business Machines Corporation Modular integration of distinct type systems for the compilation of programs
US8914774B1 (en) 2007-11-15 2014-12-16 Appcelerator, Inc. System and method for tagging code to determine where the code runs
US8954989B1 (en) 2007-11-19 2015-02-10 Appcelerator, Inc. Flexible, event-driven JavaScript server architecture
US8260845B1 (en) 2007-11-21 2012-09-04 Appcelerator, Inc. System and method for auto-generating JavaScript proxies and meta-proxies
US8566807B1 (en) 2007-11-23 2013-10-22 Appcelerator, Inc. System and method for accessibility of document object model and JavaScript by other platforms
US8719451B1 (en) 2007-11-23 2014-05-06 Appcelerator, Inc. System and method for on-the-fly, post-processing document object model manipulation
US8806431B1 (en) 2007-12-03 2014-08-12 Appecelerator, Inc. Aspect oriented programming
US8756579B1 (en) 2007-12-03 2014-06-17 Appcelerator, Inc. Client-side and server-side unified validation
US8819539B1 (en) 2007-12-03 2014-08-26 Appcelerator, Inc. On-the-fly rewriting of uniform resource locators in a web-page
US8938491B1 (en) 2007-12-04 2015-01-20 Appcelerator, Inc. System and method for secure binding of client calls and server functions
US8527860B1 (en) 2007-12-04 2013-09-03 Appcelerator, Inc. System and method for exposing the dynamic web server-side
US8335982B1 (en) 2007-12-05 2012-12-18 Appcelerator, Inc. System and method for binding a document object model through JavaScript callbacks
US8285813B1 (en) 2007-12-05 2012-10-09 Appcelerator, Inc. System and method for emulating different user agents on a server
US8639743B1 (en) 2007-12-05 2014-01-28 Appcelerator, Inc. System and method for on-the-fly rewriting of JavaScript
US8181167B2 (en) * 2008-01-09 2012-05-15 Kan Zhao Method and system for presenting and analyzing software source code through intermediate representation
US8291079B1 (en) 2008-06-04 2012-10-16 Appcelerator, Inc. System and method for developing, deploying, managing and monitoring a web application in a single environment
US8880678B1 (en) 2008-06-05 2014-11-04 Appcelerator, Inc. System and method for managing and monitoring a web application using multiple cloud providers
US7596620B1 (en) 2008-11-04 2009-09-29 Aptana, Inc. System and method for developing, deploying, managing and monitoring a web application in a single environment
US20100088686A1 (en) * 2008-10-06 2010-04-08 Microsoft Corporation Programming language with extensible syntax
US8276111B2 (en) * 2008-12-19 2012-09-25 Microsoft Corporation Providing access to a dataset in a type-safe manner
US8955043B2 (en) * 2010-01-27 2015-02-10 Microsoft Corporation Type-preserving compiler for security verification
US8739118B2 (en) 2010-04-08 2014-05-27 Microsoft Corporation Pragmatic mapping specification, compilation and validation
US9183014B2 (en) 2011-02-16 2015-11-10 Intel Corporation Enabling virtual calls in a SIMD environment
US9104795B2 (en) * 2011-06-28 2015-08-11 International Business Machines Corporation Integrating compiler warnings into a debug session
CN102520963B (en) * 2011-12-26 2014-10-01 重庆新媒农信科技有限公司 Method and system for realizing service logic processing based on strongly-typed relation mapping
US9256410B2 (en) 2012-08-09 2016-02-09 Apple Inc. Failure profiling for continued code optimization
US9524175B2 (en) 2012-11-14 2016-12-20 Oracle International Corporation Target typing of overloaded method and constructor arguments
US9600256B2 (en) * 2013-10-18 2017-03-21 Microsoft Technology Licensing, Llc Incrementally compiling software artifacts from an interactive development environment
US9772828B2 (en) * 2014-04-22 2017-09-26 Oracle International Corporation Structural identification of dynamically generated, pattern-instantiation, generated classes
US10216501B2 (en) * 2015-06-04 2019-02-26 The Mathworks, Inc. Generating code in statically typed programming languages for dynamically typed array-based language
CN108376070A (en) 2016-10-28 2018-08-07 华为技术有限公司 A kind of method, apparatus and computer of compiling source code object
US10423397B2 (en) 2016-12-29 2019-09-24 Grammatech, Inc. Systems and/or methods for type inference from machine code
CN110308908B (en) * 2018-03-20 2023-07-18 北京小米移动软件有限公司 Method and device for generating configuration file of application and displaying application page and storage medium
US10530662B2 (en) 2018-05-11 2020-01-07 Cisco Technology, Inc. Machine learning method to validate run-time rules and detect software/hardware consistency errors for network elements
WO2022030796A1 (en) * 2020-08-06 2022-02-10 고려대학교 산학협력단 Bintyper: type confusion bug detection for c++ program binaries

Family Cites Families (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4734854A (en) * 1985-10-08 1988-03-29 American Telephone And Telegraph Company System for generating software source code components
CA1248238A (en) * 1985-10-17 1989-01-03 Francis D. Lawlor Compiler including retargetable data generation
IL100989A (en) * 1991-02-27 1995-10-31 Digital Equipment Corp Analyzing inductive expressions in a multilanguage optimizing compiler
US5659753A (en) * 1991-02-27 1997-08-19 Digital Equipment Corporation Interface for symbol table construction in a multilanguage optimizing compiler
US5598560A (en) 1991-03-07 1997-01-28 Digital Equipment Corporation Tracking condition codes in translation code for different machine architectures
JP3602857B2 (en) * 1991-04-23 2004-12-15 株式会社日立製作所 Multi-model compatible information processing system and method
US5488727A (en) * 1991-09-30 1996-01-30 International Business Machines Corporation Methods to support multimethod function overloading with compile-time type checking
US5805885A (en) * 1992-12-24 1998-09-08 Microsoft Corporation Method and system for aggregating objects
CA2102089C (en) 1993-10-29 1999-05-25 David M. Gillies Recompilation of computer programs for enhanced optimization
US5628016A (en) 1994-06-15 1997-05-06 Borland International, Inc. Systems and methods and implementing exception handling using exception registration records stored in stack memory
US5742828A (en) 1994-08-03 1998-04-21 Microsoft Corporation Compiler and method for evaluation of foreign syntax expressions in source code
US5754858A (en) * 1996-05-01 1998-05-19 Microsoft Corporation Customizable application project generation process and system
US6151703A (en) * 1996-05-20 2000-11-21 Inprise Corporation Development system with methods for just-in-time compilation of programs
US6421667B1 (en) 1996-06-11 2002-07-16 Edgar F. Codd Delta model processing logic representation and execution system
US6463581B1 (en) * 1996-10-03 2002-10-08 International Business Machines Corporation Method for determining reachable methods in object-oriented applications that use class libraries
US6041179A (en) * 1996-10-03 2000-03-21 International Business Machines Corporation Object oriented dispatch optimization
US6247169B1 (en) 1996-11-04 2001-06-12 Sun Microsystems, Inc. Structured exception-handling methods, apparatus, and computer program products
US5943499A (en) 1996-11-27 1999-08-24 Hewlett-Packard Company System and method for solving general global data flow predicated code problems
US5937195A (en) 1996-11-27 1999-08-10 Hewlett-Packard Co Global control flow treatment of predicated code
US5857105A (en) 1997-02-05 1999-01-05 Hewlett-Packard Company Compiler for reducing number of indirect calls in an executable code
US6212672B1 (en) * 1997-03-07 2001-04-03 Dynamics Research Corporation Software development system with an executable working model in an interpretable intermediate modeling language
US5918235A (en) 1997-04-04 1999-06-29 Hewlett-Packard Company Object surrogate with active computation and probablistic counter
US6149318A (en) 1997-04-15 2000-11-21 Samuel C. Kendall Link-time and run-time error detection, and program instrumentation
US6009273A (en) 1997-05-29 1999-12-28 Hewlett-Packard Company Method for conversion of a variable argument routine to a fixed argument routine
US5999739A (en) 1997-05-29 1999-12-07 Hewlett-Packard Company Method and apparatus for elimination of redundant branch instructions from a program
US6085035A (en) * 1997-09-09 2000-07-04 Sun Microsystems, Inc. Method and apparatus for efficient operations on primary type values without static overloading
US6070011A (en) 1997-10-21 2000-05-30 Hewlett-Packard Co. Compiler for performing a loop fusion, dependent upon loop peeling and/or loop reversal
US5966702A (en) 1997-10-31 1999-10-12 Sun Microsystems, Inc. Method and apparatus for pre-processing and packaging class files
US6148302A (en) 1998-02-26 2000-11-14 Sun Microsystems, Inc. Method, apparatus, system and computer program product for initializing a data structure at its first active use
US6330717B1 (en) * 1998-03-27 2001-12-11 Sony Corporation Of Japan Process and system for developing an application program for a distributed adaptive run-time platform
US6249910B1 (en) 1998-05-04 2001-06-19 Hewlett-Packard Company Apparatus and method for incrementally update static single assignment form for cloned variable name definitions
US6578090B1 (en) * 1998-06-08 2003-06-10 Ricoh Company, Ltd. System and method for interfacing two modules supporting various applications
JP3320358B2 (en) * 1998-06-18 2002-09-03 インターナショナル・ビジネス・マシーンズ・コーポレーション Compiling method, exception handling method, and computer
US6247172B1 (en) * 1998-07-02 2001-06-12 Hewlett-Packard Company Method for a translation system that aggressively optimizes and preserves full synchronous exception state
US6131187A (en) * 1998-08-17 2000-10-10 International Business Machines Corporation Method and system for translating exception handling semantics of a bytecode class file
US6289446B1 (en) 1998-09-29 2001-09-11 Axis Ab Exception handling utilizing call instruction with context information
US6182284B1 (en) 1998-09-30 2001-01-30 Hewlett-Packard Company Method and system for eliminating phi instruction resource interferences and redundant copy instructions from static-single-assignment-form computer code
US6292938B1 (en) * 1998-12-02 2001-09-18 International Business Machines Corporation Retargeting optimized code by matching tree patterns in directed acyclic graphs
US6412109B1 (en) 1999-01-29 2002-06-25 Sun Microsystems, Inc. Method for optimizing java bytecodes in the presence of try-catch blocks
US6353924B1 (en) 1999-02-08 2002-03-05 Incert Software Corporation Method for back tracing program execution
US6526570B1 (en) * 1999-04-23 2003-02-25 Sun Microsystems, Inc. File portability techniques
US6286134B1 (en) * 1999-04-23 2001-09-04 Sun Microsystems, Inc. Instruction selection in a multi-platform environment
US6374368B1 (en) 1999-05-21 2002-04-16 Microsoft Corporation Weakest precondition analysis
US6484312B1 (en) * 1999-06-07 2002-11-19 Microsoft Corporation Inferring operand types within an intermediate language
US20020166115A1 (en) 1999-06-10 2002-11-07 A.V.S. Sastry System and method for computer program compilation using scalar register promotion and static single assignment representation
US6481008B1 (en) 1999-06-30 2002-11-12 Microsoft Corporation Instrumentation and optimization tools for heterogeneous programs
US6662356B1 (en) 1999-06-30 2003-12-09 Microsoft Corporation Application program interface for transforming heterogeneous programs
US6460178B1 (en) 1999-06-30 2002-10-01 Microsoft Corporation Shared library optimization for heterogeneous programs
US6381738B1 (en) * 1999-07-16 2002-04-30 International Business Machines Corporation Method for optimizing creation and destruction of objects in computer programs
US6629312B1 (en) * 1999-08-20 2003-09-30 Hewlett-Packard Development Company, L.P. Programmatic synthesis of a machine description for retargeting a compiler
US6560774B1 (en) * 1999-09-01 2003-05-06 Microsoft Corporation Verifier to check intermediate language
US6487716B1 (en) * 1999-10-08 2002-11-26 International Business Machines Corporation Methods and apparatus for optimizing programs in the presence of exceptions
US6625808B1 (en) 1999-12-10 2003-09-23 Microsoft Corporation Method and apparatus for facilitating memory management in a program comprised of heterogeneous components
US6598220B1 (en) * 1999-12-17 2003-07-22 Dell Products L.P. System and method for allowing registerable runtime modification of object behaviors
US6745383B1 (en) 1999-12-29 2004-06-01 Veritas Operating Corporation Early warning mechanism for enhancing enterprise availability
US6804814B1 (en) 1999-12-29 2004-10-12 Veritas Operating Corporation Method for simulating back program execution from a traceback sequence
US6748584B1 (en) 1999-12-29 2004-06-08 Veritas Operating Corporation Method for determining the degree to which changed code has been exercised
US6738967B1 (en) * 2000-03-14 2004-05-18 Microsoft Corporation Compiling for multiple virtual machines targeting different processor architectures
JP3974742B2 (en) * 2000-04-14 2007-09-12 インターナショナル・ビジネス・マシーンズ・コーポレーション Compile device, optimization method, and recording medium
US6981249B1 (en) * 2000-05-02 2005-12-27 Microsoft Corporation Methods for enhancing type reconstruction
US6678805B1 (en) 2000-05-25 2004-01-13 Microsoft Corporation Structure organization for improved cache performance
US6625804B1 (en) * 2000-07-06 2003-09-23 Microsoft Corporation Unified event programming model
CA2321018A1 (en) 2000-09-27 2002-03-27 Ibm Canada Limited-Ibm Canada Limitee Optimizing compilation by forward store movement
US6854110B2 (en) 2000-12-21 2005-02-08 Microsoft Corporation System and method for obtaining scratch registers in computer executable binaries
US6925639B2 (en) 2001-02-23 2005-08-02 Microsoft Corporation Method and system for register allocation
US6993751B2 (en) * 2001-05-14 2006-01-31 Microsoft Corporation Placing exception throwing instructions in compiled code
US7013460B2 (en) * 2001-05-15 2006-03-14 Hewlett-Packard Development Company, L.P. Specifying an invariant property (range of addresses) in the annotation in source code of the computer program
JP3790683B2 (en) * 2001-07-05 2006-06-28 インターナショナル・ビジネス・マシーンズ・コーポレーション Computer apparatus, exception handling program thereof, and compiling method
US6961932B2 (en) * 2001-08-15 2005-11-01 Microsoft Corporation Semantics mapping between different object hierarchies
US7117488B1 (en) * 2001-10-31 2006-10-03 The Regents Of The University Of California Safe computer code formats and methods for generating safe computer code
US6834383B2 (en) 2001-11-26 2004-12-21 Microsoft Corporation Method for binary-level branch reversal on computer architectures supporting predicated execution
US7426719B2 (en) 2001-11-29 2008-09-16 Microsoft Corporation Method and system for rewriting unwind data in the presence of exceptions
US7346901B2 (en) * 2001-12-18 2008-03-18 Microsoft Corporation Efficient generic code in a dynamic execution environment
US20030126590A1 (en) * 2001-12-28 2003-07-03 Michael Burrows System and method for dynamic data-type checking
US7600222B2 (en) * 2002-01-04 2009-10-06 Microsoft Corporation Systems and methods for managing drivers in a computing system
US6934940B2 (en) * 2002-01-30 2005-08-23 International Business Machines Corporation Source code transformation-temporary object reduction
JP4202673B2 (en) * 2002-04-26 2008-12-24 株式会社東芝 System LSI development environment generation method and program thereof
US7228540B2 (en) 2002-05-14 2007-06-05 Microsoft Corporation Preparation for software on demand system
US7213245B2 (en) 2002-05-14 2007-05-01 Microsoft Corporation Software on demand system
US7185328B2 (en) 2002-05-30 2007-02-27 Microsoft Corporation System and method for improving a working set
US7243342B2 (en) * 2002-06-11 2007-07-10 Intel Corporation Methods and apparatus for determining if a user-defined software function is a memory allocation function during compile-time
US7055132B2 (en) * 2002-06-28 2006-05-30 Microsoft Corporation System and method for associating properties with objects
US7367022B2 (en) 2002-09-05 2008-04-29 Intel Corporation Methods and apparatus for optimizing the operating speed and size of a computer program
US7370321B2 (en) 2002-11-14 2008-05-06 Microsoft Corporation Systems and methods to read, optimize, and verify byte codes for a multiplatform jit
US7472400B2 (en) * 2003-02-28 2008-12-30 Bea Systems, Inc. Method for dynamically generating a wrapper class
US7380242B2 (en) * 2003-05-14 2008-05-27 Mainsoft Israel Ltd. Compiler and software product for compiling intermediate language bytecodes into Java bytecodes
DE20307903U1 (en) * 2003-05-19 2003-08-21 Trilux Lenze Gmbh & Co Kg Rope suspension for lights
US7086041B2 (en) * 2003-06-27 2006-08-01 Microsoft Corporation Extensible type system for representing and checking consistency of program components during the process of compilation
US7559050B2 (en) * 2003-06-30 2009-07-07 Microsoft Corporation Generating software development tools via target architecture specification
US7120898B2 (en) * 2003-06-26 2006-10-10 Microsoft Corporation Intermediate representation for multiple exception handling models
US7305666B2 (en) * 2003-07-23 2007-12-04 Microsoft Corporation Description language for an extensible compiler and tools infrastructure
US7269718B2 (en) * 2004-04-29 2007-09-11 International Business Machines Corporation Method and apparatus for verifying data types to be used for instructions and casting data types if needed

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GORDON A D ET AL.: "ACM SIGPLAN NOTICES", vol. 36, 17 January 2001, ASSOCIATION FOR COMPUTING MACHINERY, article "TYPING A MULTI-LANGUAGE INTERMEDIATE CODE", pages: 248 - 260
MORRISETT G ET AL.: "From System F to typed assembly language", ACM TRANSACTIONS ON PROGRAMMING LANGUAGES AND SYSTEMS ACM USA, vol. 21, no. 3, May 1999 (1999-05-01), pages 527 - 568
See also references of EP1639461A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7870542B1 (en) 2006-04-05 2011-01-11 Mcafee, Inc. Calling system, method and computer program product

Also Published As

Publication number Publication date
TWI416412B (en) 2013-11-21
CN100474252C (en) 2009-04-01
WO2005006119A3 (en) 2005-12-29
US7086041B2 (en) 2006-08-01
EP1639461A4 (en) 2010-12-22
US20060242628A1 (en) 2006-10-26
KR101086082B1 (en) 2011-11-25
KR20060026896A (en) 2006-03-24
TW200508973A (en) 2005-03-01
EP1639461A2 (en) 2006-03-29
CN1875345A (en) 2006-12-06
JP4794437B2 (en) 2011-10-19
JP2007521567A (en) 2007-08-02
US20040268328A1 (en) 2004-12-30

Similar Documents

Publication Publication Date Title
US7086041B2 (en) Extensible type system for representing and checking consistency of program components during the process of compilation
US7685581B2 (en) Type system for representing and checking consistency of heterogeneous program components during the process of compilation
JP4841118B2 (en) Software development infrastructure
US20170228223A1 (en) Unified data type system and method
US7380242B2 (en) Compiler and software product for compiling intermediate language bytecodes into Java bytecodes
US5418964A (en) System and method for parent class shadowing in a statically linked object hierarchy
US5339438A (en) Version independence for object oriented programs
US7757225B2 (en) Linktime recognition of alternative implementations of programmed functionality
US7992140B2 (en) Compiler supporting programs as data objects
US5361350A (en) Object oriented method management system and software for managing class method names in a computer system
US5421016A (en) System and method for dynamically invoking object methods from an application designed for static method invocation
US5692195A (en) Parent class shadowing
US6738968B1 (en) Unified data type system and method
US7788652B2 (en) Representing type information in a compiler and programming tools framework
EP0546683A2 (en) Language neutral objects
US20050022161A1 (en) Description language for an extensible compiler and tools infrastructure
US8527946B2 (en) Declarative object identity using relation types
US6378003B1 (en) Method and system for deriving metaclasses in an object oriented system
CN111767033A (en) Programming system for mechanical arm program development and function extension method
Espák Japlo: Rule-based Programming on Java.
Java et al. R/Cpp: Interface classes to simplify using R objects in C++ extensions
To Fictitious imperative language system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 6067/DELNP/2005

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2004752897

Country of ref document: EP

Ref document number: 20048181124

Country of ref document: CN

Ref document number: 2006517130

Country of ref document: JP

Ref document number: 1020057025045

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 1020057025045

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2004752897

Country of ref document: EP