Abstract: A software transactional memory system is described which utilizes decomposed software transactional memory instructions as well as runtime optimizations to achieve efficient performance. The decomposed instructions allow a compiler with knowledge of the instruction semantics to perform optimizations which would be unavailable on traditional software transactional memory systems. Additionally, high-level software transactional memory optimizations are performed such as code movement around procedure calls, addition of operations to provide strong atomicity, removal of unnecessary read-to-update upgrades, and removal of operations for newly-allocated objects. During execution, multi-use header words for objects are extended to provide for per-object housekeeping, as well as fast snapshots which illustrate changes to objects. Additionally, entries to software transactional memory logs are filtered using an associative table during execution, preventing needless writes to the logs.

Abstract: A software transactional memory system is described which utilizes decomposed software transactional memory instructions as well as runtime optimizations to achieve efficient performance. The decomposed instructions allow a compiler with knowledge of the instruction semantics to perform optimizations which would be unavailable on traditional software transactional memory systems. Additionally, high-level software transactional memory optimizations are performed such as code movement around procedure calls, addition of operations to provide strong atomicity, removal of unnecessary read-to-update upgrades, and removal of operations for newly-allocated objects. During execution, multi-use header words for objects are extended to provide for per-object housekeeping, as well as fast snapshots which illustrate changes to objects. Additionally, entries to software transactional memory logs are filtered using an associative table during execution, preventing needless writes to the logs.

Abstract: A software transactional memory system is described which utilizes decomposed software transactional memory instructions as well as runtime optimizations to achieve efficient performance. The decomposed instructions allow a compiler with knowledge of the instruction semantics to perform optimizations which would be unavailable on traditional software transactional memory systems. Additionally, high-level software transactional memory optimizations are performed such as code movement around procedure calls, addition of operations to provide strong atomicity, removal of unnecessary read-to-update upgrades, and removal of operations for newly-allocated objects. During execution, multi-use header words for objects are extended to provide for per-object housekeeping, as well as fast snapshots which illustrate changes to objects. Additionally, entries to software transactional memory logs are filtered using an associative table during execution, preventing needless writes to the logs.

Abstract: Although GPUs have been harnessed to solve non-graphics problems, these solutions are not widespread because GPUs remain difficult to program. Instead, an interpreter simplifies the task of programming a GPU by providing language constructs such as a set of data types and operations that are more familiar to non-graphics programmers. The interpreter maps these familiar language constructs to the more difficult graphics programming resources such as DirectX®, OpenGL®, Cg®, and/or HLSL®.

Abstract: 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 can be implemented as a data structure that represents two or more sets of types with one or more sub-structures for representing classifications of types. Alternatively, the type system can be implemented as a base class at the top of a hierarchy and a plurality of classes hierarchically below the base class can be defined to represent a number of types such as pointer types, container types, and function types.

Abstract: Although GPUs have been harnessed to solve non-graphics problems, these solutions are not widespread because GPUs remain difficult to program. Instead, an interpreter simplifies the task of programming a GPU by providing language constructs such as a set of data types and operations that are more familiar to non-graphics programmers. The interpreter maps these familiar language constructs to the more difficult graphics programming resources such as DirectX®, OpenGL®, Cg®, and/or HLSL®.

Abstract: A software development architecture is provided for constructing a wide range of software development tools. A software development tool can be created by integrating a specification specifying functionality specific to a set of software development scenarios into a software development scenario-independent framework. The integrated specification can then be compiled to create the software development tool. Alternatively, integration can be achieved at runtime without access to source code. The architecture can use any combination of the following: a software scenario independent intermediate representation format, one or more exception handling models capable of supporting a plurality of programming language specific exception handling models, a type system capable of representing the type representations of a plurality of source languages, and a code generator capable of generating code targeted for a plurality of execution architectures.

Abstract: 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. An unknown type representation indicates that an element of the intermediate language is associated with an unknown type. A method of type-checking a code segment written in a programming language is provided using a rule set that contains rules for type-checking an unknown type. The unknown type allows for selectively retaining type information as the compilation process continues and allows multiple programming languages to be type-checked by the same type system.

Abstract: Existing methods for returning program state to a previous state are often too heavy weight. Often these methods attempt to guarantee a series of properties to a programmer across a distributed environment or multiple threads. Instead, a program state reversion mechanism provides a light weight and efficient runtime solution for general purpose programming languages. For example, a series of program statements (e.g., methods, instructions, etc.) are indicated by a programmer in a state reversion language construct, such as a TryAll block. If an exception is thrown anywhere from within the TryAll block, the program is reverted to the pre-TryAll block state.

Abstract: Although GPUs have been harnessed to solve non-graphics problems, these solutions are not widespread because GPUs remain difficult to program. Instead, an interpreter simplifies the task of programming a GPU by providing language constructs such as a set of data types and operations that are more familiar to non-graphics programmers. The interpreter maps these familiar language constructs to the more difficult graphics programming languages such as DirectX®, OpenGL®, Cg®, and/or HLSL®.

Abstract: Described herein are typed intermediate representations of object-oriented source code that preserve notions of class names, as well as add structure-based information related to classes in the source code. Types in the intermediate representation are divided into corresponding class name-based types and associated structure-based record types. The structure-based record type comprises a layout of objects that are instances of the corresponding class name-based types, where the object comprises one or more data fields and one or more virtual method members. Dynamic types can be abstracted in the form of existential types with sub-classing bounded quantifications. This makes type checking decidable. Existential types bind type variables with sub-classing bounds to represent dynamic types of objects. The layout of those objects can be approximated by structure-based record types.

Abstract: Methods and systems are described herein for extending configuration dependent extensible software programs. Classes of a core extensible software program may be extended by adding a configuration dependent extension. The extensions may be added statically prior to compiling the core version of a software program or dynamically at runtime. The declaration of extensible core classes may include an extensibility attribute with an indication of whether the class is statically extensible or dynamically extensible. An object description language is also described herein for appropriately declaring configuration dependent extensible classes. Also, a pre-processor is described herein for processing the object description language to generate a source code representation of the extensible class declarations and their extensions. The source code representation may then be used to generate the extended version of the core software program.

Abstract: Various intermediate representation techniques for software development tool scenarios are described. An intermediate representation format can be used for both high level and low level representations. The intermediate representation can be built from various operands and instructions types. Various annotations can be added to the intermediate representation without modifying its format. For example, flow control and data control can be explicitly represented by threading a graph through the intermediate representation.

Abstract: A representation of types, type-checker, and compiler are provided for checking consistency in various forms of an intermediate language. Type-checking a programming language in a compiler is accomplished by taking one or more rule sets 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. 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. 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.