Software development infrastructure

The technical field relates to software development, especially architecture to facilitate the creation of software development tools.

Many programming languages are available to provide programmers with programming benefits that are specific to each language. Similarly, a number of processors are available to provide the benefit of performing tasks specific to each processor. For example, embedded processors are particularly well suited to handle explicit tasks within electronic devices, while general purpose processors such as Intel® Pentium® processors are more flexible and perform complex tasks. Can be processed. In addition, there are various tool types created to help programmers meet the ever-increasing demand for software reliability, security, and high performance. As such, there is increasing diversity in computing environments, configurations, and devices. Therefore, software developers are faced with adapting and working in a series of fast-paced and diverse software development scenarios.

The need to deal with such diversity complicates the already highly complex field of software development tool construction. Such software development tools may include various components such as assemblers, disassemblers, decoders, encoders, instruction selection components, and instruction legalization components. Often, such components have duplicate requirements, and the components themselves can appear in multiple development tools (eg in compilers and debuggers).<nplcit num="1"><text>BACON, "Fast and Effective Optimization of Statically Typed, Object-Oriented Languages", PhD thesis, Computer Science Division, University of California, Berkeley, 3 pages of introduction and pp. I-141, 1997.</text></nplcit><nplcit num="2"><text>DEAN et al., "Optimizations of Object-Oriented Programs Using Static Class Hierachy Analysis", European Conference on Object-Oriented Programming, pp. 77-101, 1995.</text></nplcit><nplcit num="3"><text>GAY et al., "Fast Escape Analysis and Stack Allocation for Object-Based Programs", Proceedings of the 2000 International Conference on Compiler Construction, 12 pages, 2000.</text></nplcit><nplcit num="4"><text>MUELLER et al., "Avoiding Unconditional Jumps by Code Replications", Proceedings of the SIGPLAN '92 Conference on Programming Language Design and Implementation, pp. 322-330, June 1992.</text></nplcit><nplcit num="5"><text>RUF, "Effective Synchronization Removal for Java", ACM SIGPLAN Conference on Programming Language Design and Implementation, pp.208-218, BC, Canada, 2000.</text></nplcit><nplcit num="6"><text>KNOOP et al., "Partial Dead Code Elimination," In Proceedings of the ACM SIGPLAN '94 Conference on Programming Language Design and Implementation, 12 pages, June 1994.</text></nplcit>

<p> Despite the widespread need for similar component functionality, it has been difficult to develop tool components that share design and implementation, especially among a set of programming languages and other program representations. In many cases, each component of each tool has its own implementation, resulting in a lot of verbose work and duplicate code. Also, there can be little uniformity between architectures, even within the same source base. Therefore, improvements made in the code of one component improve a particular implementation, but the improvements are not automatically propagated to other tools or architectures that implement the same functionality. Finally, even if you spend your efforts dealing with a particular software development scenario (scenario), you usually have to start over to deal with a different scenario.</p>

<p> A Software Development Architecture (SDA) is provided for building various components of software development tools. Components are available for programs written with computer-readable input, such as one or more source languages or binary executable files. These components can then be combined to create software development tools. SDA includes various aspects. The various aspects may be used independently and independently, or the various aspects may be used in different combinations (couplings) or subcombinations (couplings).</p><p> In one aspect, the SDA is an intermediate representation capable of representing other computer-readable program formats (formats) such as multiple programming languages and binary executables, and multiple programming languages or other computer-readable program formats. One or more exception handling models that can support and type representations of multiple source languages or other computer-readable program formats. Use a type system that can represent (representation). The intermediate representation can also represent binary executables for multiple execution architectures. Therefore, components written using this intermediate representation can be used for programs written in various programming languages, computer-readable representations of programs such as binary executables or object files, and programs for specific target architectures. Applicable. By allowing component sharing in this way, the development cost of software tools is reduced. It also facilitates improved analysis and optimization of programs consisting of dissimilar components. Components can include data flow analysis, control flow analysis, program transformation, data representation optimization, register allocation, and instruction scheduler.</p><p> In one aspect, a method of creating components of a software development tool is provided by integrating a specification for implementing a functional specification in a software development scenario into a software development scenario-independent framework. Such software development scenarios can relate to programming languages, target execution architectures, intermediate representation levels, and so on.</p><p> In yet another aspect, computer executable software is provided for generating software development tools consisting of intermediate representations and extended versions of shared components. The software accepts one choice of multiple configurations for the software that describes the target software development tool, and is able to incorporate the data specifications into the intermediate representation in the target software development tool and is consistent with the configuration and data. It is possible to generate a component with a targeted software development tool. In this way, components and intermediate representations are used in new and unexpected situations, such as new demands on existing tools, new types of tools, new or improved programming languages, and new computer architectures. Can be extended to</p><p> These and other aspects will become apparent from the following detailed description with reference to the accompanying drawings.</p>

SDA (Software Development Architecture) is provided to build the components of various software development tools and combine those components to form the tools. SDA can build a variety of software development tools that can take any number of programming languages as input and output code for any number of target execution architectures.

<u style="single">Illustrative target execution architecture</u> The target execution architecture described herein can include any of a variety of hardware or virtual machines. The target execution architecture can include any environment for executing code. Such target execution architectures include Intel® x86, AMD, IPF, ARM and MIPS architectures, as well as other architectures, including those implemented below.

Intel® x86 architectures include, but are not limited to, Intel® such as 80x86, 80x88, Intel186, Intel286, Intel386, Intel486, and Pentium® processors available from Intel Corporation. ) Includes any processor based on the x86 architecture. AMD architectures include, but are not limited to, AMD64 and AMD32 architectures available from Advanced Micro Devices (AMD), Inc. The IPF (Itanium processor family) architecture is not limited to the following, but includes the IA64 architecture available from Intel Corporation. ARM architectures include a number of 16-bit and 32-bit embedded RISC microprocessors available from ARM Ltd. The MIPS architecture is not limited to the following, but MIPS Technologies There are MIPS64 and MIPS32 architectures available from Inc.

<u style="single">Illustrative software development tools</u> The software development tools described herein may include any of a variety of tools useful for developing software. Such tools include native code compilers, just-in-time (JIT) compilers, debuggers, simulators, analysis tools, defect detection tools, compiler development kits (CDKs) and optimizers.

Such software development tools may include components such as program transformation components, program analysis components, assemblers, disassemblers, decoders, encoders, instruction selection components, instruction legalization components, and the like. In some cases, the component itself can act as a tool.

<u style="single">Illustrative software development scenario</u> Any of the many software development scenarios can affect the functionality of the SDA. For example, software development scenarios for a particular software development tool include various target execution architectures (eg, IPF, X86, AMD, ARM, etc.) targeted by the software development tool. Software development scenarios can also relate to the type of compilation performed (eg, JIT or native optimizing compiler). Software development scenarios can also relate to other types of functionality performed by software development tools, such as types of analysis, optimization, simulation, debugging, code generation, and so on. Yet another software development scenario is one in which the software development tools may be related to a particular programming language (eg, JAVA®, C ++, C #, etc.) in which they can be specially configured. Such languages may have different exception handling models. In addition, software development scenarios allow tools to run in a managed execution environment (eg Microsoft .NET). It can also be related to whether it is used in the Microsoft CLR environment provided by the Framework). Other scenarios are possible.

SDA can be used to create components of tools that address any one or more software development scenarios. For example, SDA can be used to create components of tools that can accept any one or more programming languages and generate code for any of multiple target execution architectures, etc. is there.

<u style="single">Software development architecture</u> Figure 1 shows a block diagram of the SDA used as the basis for building various software development tools by building any number of components in any of multiple configurations using the SDA. There is. A set of 100 components represents a module that can be used with any configuration. These modules are built using the core features provided by SDA. SDA Core 100 may be provided as a set of object files or source code. SDA Core 100 presents multiple managed and / or native application program interfaces 102 (APIs). Each block surrounding the SDA core and API 102 represents a possible software development tool built with SDA. These tools include the native compiler 104, the Pre-JIT compiler 106, the JIT compiler 108, the optimization tool 110, the defect detection tool 112, the analysis tool 114, and the compiler development kit (CDK) 116.

Native compiler 104 represents one or more compilers of native machine code for multiple target execution architectures and multiple source languages. For example, the native compiler 104, built with SDA, can compile programs written in the C ++ programming language into native code for execution on the x86 target execution architecture.

The Pre-JIT compiler 106 optimizes and generates native code from architecture-independent program representations such as Microsoft's Common Intermediate Language (CIL) on the .NET platform before running an application on any number of target execution architectures. be able to. The Pre-JIT compiler can run cached on the server during installation or run on the fly (or in the background) on load on the client. For example, SDA's Pre-JIT usage 106 might be to create a Pre-JIT compiler designed to compile CIL into native code to run on an x86 target execution architecture.

JIT compiler 108 can compile code from architecture-independent representations such as CIL on the target execution architecture at runtime (just-in-time) as needed. For example, a JIT compiler 108 built using an interface from SDA may be designed to compile CIL into native code at runtime on the AMD target execution architecture.

The defect detection tool 110 can statically detect defects (before the program is executed) in code written in one or more languages. Defect detection tools can be built to run on any number of target execution architectures. For example, SDA defect detection usage 110 may take code written in the C ++ programming language as input and create a defect detection tool designed to detect defects in that code. Defect detection tools can be designed to run, for example, on x86 target execution architectures.

The analysis tool 112 analyzes code written in one or more languages. Analysis tools can be built to run on any number of target execution architectures. For example, SDA's analysis tool usage 112 takes code written in the C # programming language and determines which modules or lines of source code can be affected by changes in one particular module. I have something to do. This is known as program slicing and is useful when modifying large systems.

Optimizer Tool 114 optimizes code written in multiple languages. For example, SDA's optimization tool usage 114 is to take code written in the C ++ programming language and create an optimization tool designed to optimize the layout of fields based on profile data. I have something to use. Alternatively, it is possible to create an optimization tool designed to optimize CIL from Microsoft .NET languages such as managed C ++.

The use of CDK 116 allows third parties to independently develop compilers. As a CDK, some or all binaries of SDA components, some or all libraries of SDA components, and some or all of the components that allow third parties to modify certain aspects of the system. All source code is listed. For example, CDK tools 116 built with SDA are from chip vendors who are interested in creating compilers for devices that use WinCE quickly and cost-effectively.

The tools described herein use all or part of the elements of SDA Core 100. In addition, the tools described herein can include additional components that are not present in the SDA core. You can add or remove phases and components to the configuration based on throughput, footprint, host, target, and code quality requirements.

For example, the native compiler 104 may be expected to have the highest budget (expense, budget) in terms of compilation time and memory footprint (memory footprint) and produce the best code quality. Therefore, this configuration tool may improve code optimization. In contrast, the JIT compiler 108 may require faster compilation times and a smaller memory footprint configuration, while still producing some optimized code. Therefore, this tool may maintain data structures such as flow graphs, loop graphs and SSA graphs as much as possible and avoid costly reconstructions. In addition, the number of passes to process the intermediate representation can be minimized.

Figure 2A is a flowchart of how to create a software development tool using SDA. Block 200 represents one or more specifications received by the SDA. At block 202, create a software development component from the specification (for example, by generating and then compiling the source code). At block 204, create a customized software development tool by linking the component to the SDA. Alternatively, you can add custom code that provides additional functionality to the specification and integrate it into the component. In that case, software development tools can be created from a combination of SDA and components.

Alternatively, Figure 2B shows another flowchart of how to create a software development tool using an executable version of SDA. At block 206, software development components are provided. At block 208, create a customized software development tool (eg dynamically at runtime, without access to the source code) by linking the component to the SDA.

The specification is in any computer-readable language or format (eg, object or executable code, source code, or custom language) suitable for specifying information for implementing the functional specification in one or more software development scenarios. There may be.

Figure 3 is a high-level block diagram of a system that uses SDA300 to create components for software development tools. One or more specifications 302 are created to describe the details of the target specifications for the software development scenario. For example, specification 302 states which programming language the target tool is in (eg Visual). It may indicate whether NET (network) languages such as Basic, C #, CIL, or C ++) can be taken as input. Similarly, the specification may dictate the target execution architecture of the target software development tool (eg, x86, AMD, MIPS, or IPF architecture). In addition, the specification may include other information such as a set of rules for type checking the input language and a set of class extension declarations for configuring the SDA core data structure to be extensible. Then, using specification 302, a software development component that can be linked to SDA300 is created. The linked components 304 and SDA300 can be used in combination to create any number of tools 306, such as software development tools such as JIT compilers, Pre-JIT compilers, and native compilers. Alternatively, custom code may be added to implement additional functionality for the target software development tool 304.

Thus, from a single source base, such as SDA in a particular configuration, simply provide target specific data to customize the target software development tools for one or more software development scenarios. Allows you to create any number of components in your software development tools. Therefore, software development tools can be considered to be divided into both target specific modules and target agnostic modules. Figure 4 illustrates this concept. Figure 4 shows JIT, Pre-JIT, and Microsoft® Visual for each of the three target execution architectures (x86, AMD, MIPS) created using the system as shown in Figure 3. A block diagram of a C ++® native compiler, debugger, and optimizer. Since the various tools for the execution architecture are built from the common SDA and specifications, the target specification code for software development tools supplied by the specification or custom code is separated from the target-independent code that can be supplied by the common SDA. To. Therefore, the components of the target execution architecture are created from the same specifications and can be the same for different types of software development tools.

Software development tools only need to change the target specification components, so they can be easily retargeted between different execution architectures. Also, bugs found in either the target specification code or the unquestioned target code can be fixed on a large scale.

For example, a developer wants to retarget the JIT compiler 400 for the Intel® x86 architecture to work on the AMD or MIPS architecture. Developers only need to write the appropriate specifications, including the data specifications, in the AMD or MIPS execution architecture. It then integrates the target specification data into the same or similar common SDA used to create the JIT compiler 400 for the Intel® x86 architecture. Then, using the integrated SDA and specifications, create a JIT compiler 402 for AMD architecture or a JIT compiler 404 for MIPS architecture.

Next, suppose a developer finds a software flaw in the optimizer 406 built with specifications written for the Intel® x86 architecture. If a software flaw is found in the target unquestioned code, that code is most likely part of a common SDA. Therefore, the software flaw can appear throughout the tool shown in Figure 4.

The 15 tools illustrated by implementing the modifications in one source code base (component or common SDA) once the improvements in the components built with the common SDA or the common SDA itself have been built. You can start improving (3 compilers, 2 tools for each of the 3 different architectures) at the same time. Updated corrected versions of the 15 tools are created either by simply recompiling the specifications for each target execution architecture with the updated SDA, or by distributing new binaries for the SDA and components. can do.

Similarly, if a software defect is found in the target specification code for Optimizer 406 on the Intel® x86 Execution Architecture, the software flaw may be in a specification written for the Intel® x86 Execution Architecture. highest. Again, to fix software flaws across the tool for the Intel® x86 execution architecture, correct one source code (Intel® x86 specification) and update the updated specifications in a common SDA. All you have to do is recompile.

In addition to allowing rapid retargeting (retargeting, aiming for new goals) to alternative execution architectures, the software development tools shown in Figure 4 should accept another programming language as input. Can be quickly redesigned. For example, for the purposes of this example, suppose the debugger 408 is created from a specification that directs the debugger 408 to take C ++ as input and target the MIPS execution architecture. Redesigning the debugger 408 to take C # as input and still run on the MIPS architecture is as easy as rewriting the spec to point to a different input language. The new spec can then be integrated into the same or similar SDA, and a new debugger with C # as input will be generated.

<u style="single">SDA core data structure and abstraction</u><u style="single">Machine Model-Abstract Retargeting</u> To support rapid retargeting of software development tools created using the SDA described herein, the SDA core is divided into a target unquestioned part and a target specification part. Whenever possible, incorporate a common target specification code into the target-independent SDA and provide a call to the target specification code to retrieve information or perform conversions. By way of example only, the following sections describe the implementation details of one embodiment of the SDA core. Alternative SDA cores may use any combination of the following, or other features:

register By accessing the machine register file via API, the number of register files (eg general purpose, floating point, prefix) is queried to determine which machine type (eg int32, float64, MMX) can be processed. And you can get the object that represents the machine register (eg EAX, r0, p3). Register objects are derived from the Layout class and can add the following information: internal enumeration numbers such as data flows; register names in text strings; attributes; binary encoding; extensibility objects.

Machine-dependent opcode By accessing the machine opcode table via API, it is possible to inquire about the number of opcodes (operation codes) and obtain an object representing the opcodes (for example, ADD, MOVZX). Opcode objects can encapsulate the following information: internal opcode enumerations, opcode names by text strings, attributes, and extensibility objects.

Calling rules Calling conventions can be made explicit by the lowering phase and can be implemented through the application binary interface (ABI) specification callbacks in the untargeted framework. The framework can include subroutines for common actions such as assigning parameters to registers and demoting register operands to memory operands (for stack passing).

Multiple invocation conventions can be supported by annotating each invocation instruction with a target specification attribute that describes the type of invocation convention used in that invocation. This attribute can be maintained and propagated through high-level and machine-independent optimization phases.

Exception handling model Various exception handling (EH) models can be implemented in a target-independent manner. However, it is necessary to include machine model queries and callbacks in the target specification code. Exception handling will be discussed in more detail later in another section.

Code generation In this embodiment, code generation consists of instruction selection / low leveling, intrinsic / switch / question op expansion, and instruction legalization. Register allocation and scheduling can be considered as separate phases. Code generation will be discussed in more detail later in another section.

Encode Encoding is the process of translating a compiler IR (intermediate representation) into binary machine code. There can be a machine-independent framework for encoding that involves a lot of work that occurs in the produced target specification code.

Scheduling table Scheduling tables can be used for global and local scheduling. The machine scheduling table can include the instruction latency (latency, call time) and functional units required by each machine instruction. The table can be generated by the retargeting tool used in code generation.

Disassembler The deassembly can be driven by a code generation file. Inverse assembly can be implemented as a linker using a common interface and a DLL (dynamic link library) shared by a debugger.

Prologue / Epilogue Function prologues (prefaces) and epilogues (conclusions) can be generated using target-specific callbacks in the target-independent framework. The prologue may contain some or all of the following items: frame pointer initialization; stack alignment; stack allocation; non-volatile register saves; exception handling structure initialization; runtime checking and initialization. The epilogue may contain some or all of the following items: non-volatile register restore; stack deallocation; frame pointer restore; runtime check. There can be two frame pointers for each function, a local pointer and a parameter pointer. These can be machine-dependent and function-dependent.

Endian support In cross-targeting scenarios, the SDA must be aware of endianness (the type of byte order). The specification can describe the endianness of the target execution architecture. Accordingly, emission routines can be designed to uphold this endianness.

Stack allocation Specifications can include stack alignment and extension direction information. The stack allocation package can be responsible for calculating the maximum required local alignment and the total stack space used. In addition, stack offsets can be assigned to local variables without stack packing optimization.

<u style="single">Type system</u> The type system for IR serves many important purposes. This will be explained in more detail later in another section.

<u style="single">function</u> A Function or Method object can write code that makes up a single procedure. The following attributes can be considered when writing function objects: 1) Function ID: Unique identifier for the method. 2) Function name 3) Return type 4) Calling rules 5) Function signature or argument list 6) Exception information Functions can contain items that are laid out discontinuously. Exceptional information and other data structures that have information that follows the layout of the function can be modified accordingly.

As a function goes through various compiler stages, it can be the only entity (component, entity) that contains most of the information that is important to later stages. Also, a function object can be an object that withstands and persists most transformations, ie code separation, inlining, loop unrolling, and so on. Therefore, the information associated with each function can quickly become obsolete without a conscious effort to adapt to those transformations.

For data flow analysis to succeed across functions, it is desirable to be able to represent the entire function, even if the entire function is no longer physically contiguous.

Functions and methods In this embodiment, it may not be necessary to distinguish between functions and methods. This can simply be a difference in terminology when a class hierarchy is introduced.

<u style="single">class</u> A Class object can be a container for all functions or methods that belong to that class. The following attributes can describe class objects: 1) Class name 2) size 3) List of functions 4) Type / layout information for data members including virtual call tables

In this embodiment, the class definition may not be decomposed into a plurality of modules, so it is important to be able to rearrange the class internal representation for the purpose of optimization. An example of such a class sort involves working set shrinkage due to the presence of many data structures related to class objects. Their data structures may also have to be sorted to follow the class internal layout.

<u style="single">Phase control</u> Since it is desirable to provide the configurable and extensibility of the SDA described herein and a unified mechanism for connecting components, it is possible to provide phase control by data rather than hard coding. The phase order can be specified by generating a list of phase objects. The phase list can be modified by configuration, machine target, and user extensibility.

Each phase object has a debug precondition (debug check to be performed), a run precondition (compile flag that controls the execution of the phase, eg -Od for global optimization), prephase extensibility, phase entry point. , Post-phase extensibility, debug post-conditions, textual phase names, and pointers to the next and previous phases can be encapsulated.

The individual phases can be responsible for recognizing that the function is "big" and suppressing the transformation appropriately. For example, if the function has more than n IR nodes, the interference package may act conservatively to ensure accuracy and decide to give up thorough analysis. .. Alternatively, the optimization may be too expensive to perform for the entire function and may instead decide to act on each region or stop altogether.

<u style="single">Main driver</u> The main driver is responsible for initializing the SDA and attached extensibility modules. At boot time, various system packages can be initialized according to the compiler configuration (which primarily sets the phase list). You can then perform target specification initialization (which may provide extensibility functionality). You can then initialize the extensibility module (which allows you to modify the phase list, attach to various data structures, etc.). At this point, the command line processor may be called. Finally, if no errors occur, the compile manager (which may be configuration dependent) can take control.

<u style="single">Intermediate representation (IR)</u> One embodiment of the SDA for creating the components of a tool described herein provides a single common IR format for representing a user program in memory during the entire execution of the tool. .. The IR format can represent a variety of code, from high-level machine-independent operations to low-level target machine code, using a single unified format. Figure 5 shows a block diagram of an exemplary compilation process in a compiler created using SDA. The compiler can take multiple languages as input, output multiple languages, and target multiple execution architectures.

Source code 500-506 is written in four different source languages. For example, source code 500 is written in C #, while source code 506 is written in C ++. In addition, executable formats such as PE binaries can be accepted as input. First, the source code is processed by the reader 508 and input to the system. Next, translate the source language into high-level IR (HIR). Then, in block 510, HIR can be analyzed and optimized at will. Next, translate HIR into intermediate level IR (MIR). This expression is lower level than HIR, but still machine independent. At this point, block 512 can optionally analyze and optimize the MIR. The MIR is then translated into machine-dependent low-level IR (LIR) by code generation in block 514. The LIR can then be optionally analyzed and optimized at block 516 and supplied to the emitter at block 518. The emitter outputs the code in one of many formats 520-526 that represent the original source code loaded into the system. Throughout this process, the data needed to complete the process is stored in some form of persistent memory 528.

Thus, the compilation process involves translating instructions from one level or expression to another. In one embodiment, the process of translating an IR from a high-level operation into machine code is a set of optimization and code generation paths that simply attribute more and more information to the IR without changing the basic form at all. obtain. For example, FIGS. 6A-6D show step-by-step IR conversion from source loading through high-level machine-independent IR to low-level machine-dependent IR. As these figures show, IR is simply scaled by target machine details such as registers and real machine opcodes and given their attributes. However, the format remains substantially the same.

The IR can also be scaled for use in different SDA configurations. For example, just-in-time (JIT) compiler configurations have speed and memory constraints, so the IR format used by the JIT compiler created using the SDA's JIT configuration slows down compilation or It can be configured by adding or removing properties that tend to increase the memory footprint. In contrast, high-end, all-program-optimizing native compilers tend to consume very large amounts of resources and demand high code quality. Therefore, the IR format used by native compilers created using SDA's native compiler configuration adds or adds properties that tend to limit compilation speed or reduce the amount of memory available to the compiler. It can be configured by deleting it.

In this embodiment, the IR used in the SDA can be a graph data structure organized as a linear stream of data flow operations represented by operators, a set of data flow sources and a set of data flow destinations. Data flow information and side effects can be explicitly included in the data flow set. IRs may be strongly typed with source-level type information to allow robust code generation and type checking. The IR may also include some or all of the data and control flow links needed to fully describe the program. That is, if all the required links are present, no other data structures such as flow graphs or exception handling trees / graphs are needed.

In addition, any resource used or defined by an operation, whether explicit or implicit, may appear in the list of sources or destinations of the operation. Data flow analysis and compiler construction are generally simplified. This is because only the operands need to be analyzed to determine the complete side effects of the operation. Therefore, new operations are easy to add because they are implemented by simply recombining the same set of small operands in a new way.

The IR can include a single model for disambiguating memory and determining alias analysis through a single "tag" associated with the operand. The tags may be conservative or very rigorous through extensive analysis. All phases of the compiler simply follow the tags and can only query the "oracle" for side effects of the operation.

The following sections describe the implementation of one embodiment of IR suitable for use in the SDA embodiments described herein.

<u style="single">Illustrative IR</u> An exemplary IR of an SDA embodiment can be implemented as a linear stream of typed tuples. Each tuple can have a set of input operands (source list), operators, and a set of output operands (destination list). Side effects (eg, all side effects) can be explicit to the instruction, including information on the real or implicit register use / def and the symbol use / def. Interference information is attached to the indirection operator.

IR can exist with or without a flow graph, but global optimization may require a flow graph. Exception handling area graphs and optimization area graphs can also be used to enhance IR information. The IR must have sufficient information to build flow graphs, loop graphs, and reestablish mappings to exception handling area graphs. Flow graphs (and lesserly loop and exception handling area graphs) can almost always be present, so design is easy on these graphs, as in the case of systems where these graphs are part of the core IR. Access can be provided.

IRs can be designed to directly support tree-based and SSA-based optimization. This can be done by adding a def field to the leaf tuple. In its simplest form, expression temps can be stitched together to form an expression tree. This can be immutable for pre-lowered code. This expression threading can be ignored for analyzes that do not need to use expression views. The conversion can leave them in the correct state and may use the expression optimizer for cleanup. A full-fledged SSA can use the same def field and include special operations like the PHI instruction. Under SSA, expression temporary variables can simply be a subset of the entire SSA graph.

To support inline _code, the initial phase of the compiler can see "outline" instructions that summarize the dataflow effects of the _asm sequence. The actual _asm instruction sequence can be kept as a sidelist until the very later stages of low-leveling inline the sequence.

Although various examples of IR show low-level processes, IR can also be used in high-leveling processes. For example, a tool can take a binary as input and build an IR for that binary.

operand Operands can be leaf nodes of an instruction and can appear in the instruction's source and destination lists. Operands describe some or all, actual or potential resource usage, including immediate values, registers, memory, and condition codes, as all side effects can be explicit to the instruction. Exists for. Each leaf node can have an associated type that represents its abstract type. This is further mapped to the machine type for the low-level instruction.

register The register operand can specify either an actual physical register or a virtual register.

Temporary register Temporary operands can take one of two forms: 1) an expression temporary variable (ie temp reg) can be a single def, a single use temporary variable used in an expression; or 2) general Temporary variables (ie temp vars) can be introduced by the compiler for questionOp, CSE, scalar substitution, and induction variables, etc., and can have multiple defs and uses.

Expression temporary variables can only live in registers and never beyond basic block boundaries. General temporary variables can persist in registers or memory and can persist beyond basic block boundaries. Neither is addressed.

Physical register The physical register is the actual machine register. It includes integers, floating point, multimedia, vectors, and dedicated registers.

Named register The named register can be a candidate for a physical machine register or a user variable assigned to a physical machine register.

memory The memory operand can specify a value stored in memory or abstract memory. Abstract memory can be used for explicit interference calculations.

Named memory Named memory can specify user variables stored in memory.

Vector memory Vector memory can be used in vector operands of vector operations.

Indirect memory Memory indirect arithmetic can represent the most powerful address mode on any target machine. The indirect operation may include interference information.

Abstract memory Abstract memory can be used to annotate instructions with explicit memory use / def side effects (ie, interference information) other than by direct reference.

address The address operand can specify the location of the code or data.

Valid address The valid memory address operand can represent the most powerful address mode on any target machine.

Data address The data address can be a simple form of a valid address used to access the data.

Code address The code address can be a simple form of valid address used for nonlocal code.

label The label can be a simple form of valid address used for local code.

Condition code IR can use abstraction for condition code.

Register set Register sets can be used to represent kill sets and side effects.

immediate The immediate operand can specify a known value that can appear in the instruction. This value may always be known to the compiler, or it may only be determined at a later stage, including low-leveling, linking, and loading conditions.

Integer immediate value Integer immediate values can be normalized to the maximum integer size.

Floating point immediate value Floating point immediate values can be normalized to internal / portable format.

Symbolic immediate price A symbolic immediate value can be a symbol that represents a constant value that is calculated by the compiler or perhaps modified by the linker / at runtime.

Arithmetic (machine-independent opcode) Operations can be divided into several categories. These categories can be grouped or decomposed into different variable size types of instructions as follows: Arithmetic operation Arithmetic operation with overflow Logical operation Pointer operation Structure calculation Object operation Allocation Call (virtual, instance) Field access / update Array operation Allocation Reading and writing Reading and writing without boundary check Length calculation Vector operation Branch operation Call operation · Built-in (intrinsic) call operation Return operation Switch operation Exception operation -Type conversion (dynamic / static cast) Type test operation Security calculation -Threading operation Synchronous operation Check operation Null pointer check operation Boundary check operation Type test operation Outline pseudo operation Data calculation

block If a flow graph is present, special block pseudo-instructions can represent the start and end of the basic block.

label Labels may be user-defined or compiler-generated.

Pragma The pragma may be user-defined or compiler-generated.

Annotation The annotations may be user-defined or compiler-generated. Annotations typically convey additional semantic information that native and JIT compilers can use to improve code quality.

list The list IR node can be an auxiliary node used to create a link in the flow specified by the control instruction.

Branch list A branch list node can be attached to a label and represent all the branches reached.

Case list Case list nodes are attached to switch operations and can represent all case values and branches.

Debug information (rows and columns) Any instruction can have debug information that describes the source row and column information. This information can be maintained for debugging purposes when deploying / low-leveling or optimizing the code.

<u style="single">Type system</u> The IR can also include a type representation to check for consistency in various forms of IR. Specifically, written in multiple source languages, including typed and untyped languages, loosely typed and strongly typed languages, and languages with and without garbage collection. It is possible to provide a typed intermediate language suitable for use in expressing a program. In addition, SDA can provide a type checker architecture that allows the use of different types and type checking rules, depending on the source language and / or compilation stage for the program component.

For example, it would be desirable to have a high-level optimizer that applies to programs written in different languages. These languages can have different primitive (basic) types and primitive operations. One language may include types and operations, for example for complex arithmetic, while another language may include type and operation specifications for computer graphics. By allowing intermediate representations to be parameterized by different type systems, the optimizer can be used for languages with different primitive types and primitive operations.

Another example could be a program in which one particular component is written in a strongly typed subset of the language and the other component is written in a full language that is not type-safe. It would be desirable to have more error checking for the former set of components. This can be achieved by using different type checking rules for different components.

Yet another example is dropping type information during compilation. Type checkers and compilers may force the strict information to be maintained in the early stages, while allowing the type information to be lost in later stages. This may be achieved by using unknown types with different type checking rules for different compilation stages.

In one embodiment of the SDA, several type representations can be defined in the type class hierarchy so that typed IR can represent type systems in different languages. For all types, the abstract base class can be defined as "Phx :: Type". The base class can include size information "sizekind" for various types, such as real, symbolic or unknown (ie variable) types. The base class can also include "typekind" to specify the type classification. In addition, an external type can be provided as an abstract type that wraps an externally defined type to provide an inverse mapping from the typed IR to the source code.

Under the base class, a class defined as "Phx :: PtrType" can represent a pointer type. Various pointers can be defined in the same way. For example, a managed pointer that is garbage collected (pointing to a position in an object that is garbage collected), a managed pointer that is not garbage collected (pointing to a position in an object that is not garbage collected), an unmanaged pointer (for example, code written in C ++). There are reference pointers (pointing to the base of objects that are garbage collected), and nulls (such as those found in).

At the same level in the hierarchy, a class defined as "Phx :: ContainerType" can represent a container type, such as a type that contains internal members. Internal members can have types such as fields and methods. A class defined as "Phx :: FuncType" represents a functional type and contains the required call conventions, argument list and return type list. Also, the class defined as "Phx :: UnmgdArrayType" can represent an unmanaged array type. Four more classes can be defined under "Phx :: ContainerType" in the hierarchy. A class defined as "Phx :: ClassType" represents a class type, and a class defined as "Phx :: StructType" represents a struct type and is defined as "Phx :: InterfaceType". A class can represent an interface type, and a class defined as "Phx :: EnumType" can represent an enumeration. Under "Phx :: ClassType" in the hierarchy, another class defined as "Phx :: MgdArrayType" can represent managed array types.

The class "primtype" can be defined as a special instance of a structure type. The "primtype" can include various types such as int, float, unknown, void, condition code, unsigned int, xint and the like. These expressions can be used in both HIR and LIR of typed IR.

In addition, target specification primitive types can be included in the type representation. Some languages have complex arithmetic types that can be processed efficiently if the type system recognizes the complex arithmetic types. For example, consider the "MMX" instruction. Such an instruction is one instruction in an additional instruction set built into several versions of x86 processors to support single-instruction / multiple-data operations on multimedia and communication data types. The type system can be customized to recognize and use these instructions with minimal changes to the type representation.

Embodiments of the type representation of the above types can also include "unknown" types. It can represent any type and optionally has a size associated with it. The size may be the size of the machine representation of the value. Unknown types allow the compiler to drop type information in a controlled manner by changing the type information from a particular type to an unknown type. This allows the compiler to generate code that depends on the size of the value being manipulated, even if the type is unknown. Unknown types also allow partial representation of type information (in which case some, if not all, information is known), as other types may use unknown types.

For example, consider a pointer to an int type. At some stage of low leveling, it may be desirable to drop the type information, that is, the int. The unknown type allows the compiler to replace the int type with an unknown type. In that case, the type checker does not need to check that the pointer points to the correct type. This is essentially expected to be passed at runtime without adversely affecting program functionality.

Another example of using an unknown type is to define a function type. If a function with an unknown argument type is called and the argument type was previously a pointer to an int, the compiler must trust that the correct type is being passed. You may or may not know that the result of back-referencing that pointer is an int, but it is used as an int. A more complex example is the introduction of intermediate temporary variables during the conversion of intermediate representations from high-level to low-level virtual function calls. Virtual tables (vtables) are widely used to implement virtual calls in object-oriented languages. The first step in making a virtual function call in a low-level intermediate representation is to fetch the first field of an object in memory. The first field contains a pointer to the vtable. Next, the fetch result is assigned to a temporary variable. Building a type of a temporary variable (a type that represents a pointer to a vtable, where vtable can have many fields) can be complicated and cumbersome to represent. Instead, the compiler can simply assign "pointer to unknown" to an intermediate temporary variable. Thus, when it is not necessary to retain detailed type information or when it is a heavy burden for the compiler developer (implementer), using the unknown type simplifies the later compilation stage.

FIG. 7 shows an embodiment of a compiler system that types-checks IR at various stages of compilation and thus types-checks typed IR at various levels of low leveling. Source code 700 represents one of a variety of source languages. The source code 700 is translated into the typed IR HIR702. At that time, the type representation of the source language is translated into the type representation inside the typed IR.

HIR is lowered throughout the compilation process. For the purposes of this description, representations for the high (HIR) 702, medium (MIR) 704, and low (LIR) 706 levels are given. However, this embodiment is not so limited. Type checking is possible at any number of compilation stages.

The IR at each level of representation can be type checked by the type checker 708. The type checker 708 implements an algorithm or procedure for applying one or more ruleset 710 at each stage of the compilation process, and thus at each representation of the IR. Ruleset 710 is chosen based on various properties such as source language, compilation stage, degree of typing strength, and so on.

For example, suppose source code 700 contains code written in the C ++ programming language. The C ++ source code 700 is first translated into the typed IR HIR702. If desired, the type checker 708 can at this point interact with the HIR702 to determine any number of properties. Such properties include the compilation stage (HIR), the type of source code given (C ++), whether the language is typed (yes), and whether it is loosely or strongly typed (loosely). (Typed) and the like. Based on these properties, the type checker can select the appropriate set of rules. After selecting a ruleset, the type checker types-checks HIR according to that ruleset. After the HIR has been lowered to MIR or LIR, those properties are re-accessed and the same ruleset may or may not be appropriate.

In one embodiment, three sets of type check rules can be supplied to the type checker. One set may correspond to the desired "strong" type checking for type checking C # and CIL. Another set can accommodate "weak" checks, which are looser checks rather than "strong" checks. For example, a weak type check rule set can tolerate type casting. A type cast is when you want a variable of one type to behave like another type for one-time use. For example, a variable of type int can behave like char. The following code uses a typecast to print the letter "P".

int a; a = 80; cout &lt;&lt; (char) a;

Thus, even if "a" is defined as a type int and a value of 80 is assigned, the cout statement treats the variable "a" as a type char by typecasting, so "P" (ASCII) instead of 80. The value 80) will be displayed.

Finally, the third set may correspond to a "representation" check. The "representation" check makes it possible to drop the type information in a part of the intermediate program representation by using the unknown type, etc., when such type information can be dropped, or when the unknown type is changed to another type. It can contain rules that specify whether it can be replaced. For example, the result of a function that returns a value of type Void may be prohibited from being assigned to a variable of type unknown.

In addition, multiple rulesets can be used in a single compilation stage. For example, suppose source code 700 contains a single language, but contains strongly typed sections and several loosely typed sections. The type checker can use one rule set for the HIR of one particular strongly typed section and another rule set for the loosely typed code section.

FIG. 8 is a block diagram of a mold checker for use with the IRs described herein. The type checker 800 can accept any number of rulesets as input that correspond to different source languages and / or different compilation stages. In Figure 8, four rule sets 802-808 are provided for the mold checker 800. Ruleset 802 represents the ruleset for HIR in strongly typed languages, ruleset 804 represents the ruleset for HIR in weakly typed languages, and ruleset 806 represents the ruleset for HIR in untyped languages. And rule set 808 represents the rule set for LIR. Program module 810 represents a strongly typed language in HIR, and program module 812 represents program module 810 after being lowered to LIR.

The type checker 800 selects the appropriate ruleset based on the nature of the type-checked program module and applies the selected ruleset to the program module using built-in procedures or algorithms. For example, the type checker 800 can select ruleset 802 (representing a ruleset for HIR in a strongly typed language) to typecheck program module 810 (representing a strongly typed language in HIR). .. The type checker 800 can then select ruleset 808 (representing the ruleset for LIR) to typecheck program module 812 (representing a strongly typed language in LIR).

The ruleset of the type checking system described herein can be easily extended to entirely new languages as well as new features of existing languages. For example, when a new language is introduced, a new ruleset is simply created for that new language. A new ruleset for a new language redistributes or updates an existing type-checking system or compiler, because the ruleset is separate from the type checker or compiler system itself and is designed to accept the ruleset as a separate entity. Can be distributed without the need to do. Similarly, when a new feature is added to an existing language, for example when adding XML support to C ++, the C ++-aware ruleset at various compilation stages behaves to handle the new feature. Can be easily reconstructed. Again, there is no need to update or distribute the new core system.

Rulesets also allow constraints on types. For example, whether subtyping for a particular type is allowed when a class inherits another class can be a constraint described in that rule. Another constraint can be a boxed constraint, such as when it is desirable to indicate whether the data can be converted to a virtual table containing that data. Other constraints include size constraints and primitive type constraints that indicate the need for primitives of the same type. Like the rest of the ruleset, new constraints can be added as needed.

The ruleset used by the type checker can be built through a programming interface to the application for creating the ruleset. The application can build rules so that the ruleset is represented in a hierarchy of type primitives with the rules assigned to the individual instructions in the typed IR. This hierarchy can be provided in the form of a type graph that explicitly represents the various elements of the type associated with a particular program module or compilation unit. IR elements such as symbols and operations are associated with type system elements. Type graph nodes are primitive types and constructed, such as components, nested types, function signatures, interface types, hierarchical elements and other information (eg references to source names and module / assembly external type elements). Describe the types and their relationships.

<u style="single">Exception handling</u> The IRs described herein for use with the SDA support a variety of language-specific exception handling models, such as C ++, Microsoft CLR, and Microsoft Windows® Structured Exception Handling (SEH). be able to.

Figure 9 shows a system 900 that implements unified exception handling in IR (Language Cost Dependent Intermediate Representation) 930 for multiple source languages (905-908) with a compiler backend 940. As shown in FIG. 9, system 900 includes intermediate language (IL) representations 910-913 for each of the plurality of source code representations 905-908. Intermediate Language (IL) representations 910-913 are parsed or read by the IL reader 920. The IL reader 920 translates multiple IL representations 910-913 into a single IR930. The IL representation is a higher level intermediate representation than the IR930, CIL (Microsoft CLR) (for C #, Visual Basic, JScript, C, and FORTRAN) and C ++. It can be expressed in any number of well-known intermediate languages such as IL (for C ++) . System 900, which produces a unified exception handling framework for multiple languages, has been shown to have a single IR reader process for multiple source languages, but implemented multiple such readers, each with its own. It is also possible to accommodate one or more IL representations 910-913.

Figure 10A shows a general overall method 1000 using the IL Reader 920 to generate a unified set of intermediate representations for exception handling constructs expressed in multiple different source languages. At 1010, the reader 920 receives an intermediate representation of the software (eg, an intermediate representation of the source code file). At 1015, the file is read or parsed to identify the exception handling construct in the IL code stream (1020). Then, at 1030, reader 920 (which can also be considered a virtual machine) generates a single unified IR of the exception handling construct previously identified at 1020. You can then use such an exception-handling framework to simplify compiler back-end processes such as code optimization and code generation.

A unified IR of software with an exception handling construct can explicitly represent the exception handling control of the software. Figure 10B shows 1050 how to generate an executable file from a unified IR of software. Such a method can be used, for example, when a software development tool such as a compiler generates an executable version of software (for example, object code such as machine specification code).

At 1060, read the unified IR (eg with a software development tool such as a compiler). For example, a unified IR generated by the method of Figure 10A can be used. Other conversions, translations, or optimizations to unified intermediate representations can be performed as needed.

At 1070, generate a computer-executable version of the software (eg with a software development tool such as a compiler). The computer-executable version of the software implements the software's exception handling control flow based on a unified IR.

Figure 11 shows another embodiment of a system that produces a simple, unified IR of exception handling constructs in multiple source languages, represented in the form of multiple IL representations. First, convert the source language groups 1110 supported within Microsoft's .NET framework (eg C #, C, Microsoft Visual Basic, Jscript, and FORTRAN) to CIL representation 1140, as shown in Figure 11. However, due to differences from other source languages, C ++ is represented in another intermediate language known as CIL1130. Control flows and exception handling models within C ++ IL and CIL are represented in essentially different ways, so it may be necessary to provide separate IL readers (1135 and 1145) for C ++ IL and CIL representations. ..

Both readers 1135 and 1145 parse or read their respective intermediate language code streams using the appropriate algorithms implemented within their respective readers. This represents an exception handling construct or instruction or representation 1150 in an intermediate language code stream using a unified framework of exception handling instructions, which is provided to the compiler backend 1160.

<u style="single">Code generation</u> To generate software development tools for any number of execution architectures using SDA, the SDA can include a code generator that can generate any number of machine-dependent representations from a common IR. FIG. 12 shows an embodiment of a system for such code generation. In this example, the target execution architecture specification 1200 with the target specification data is fed to the retargeting tool 1202. Alternatively, a specification 1200 and a second specification 1204 with unquestioned data can be supplied to the retargeting tool 1202.

Retargeting Tool 1202 is software that parses specification 1200/1204 for data related to one or more code generation components. Based on the data in specification 1200/1204, the retargeting tool creates one or more components. Each component provides the data that creates the code generation component.

For example, in the embodiment of FIG. 12, tokenization (splitting strings, etc.) grammar 1206 (eg, lex format), and parser (parsing) grammar 1208 (eg, yacc format), and a set of C source and header files. 1210 is generated.

In the example using lex, the tokenization syntax 1206 is provided to the lex compiler 1212 to create the source code and header files 1214 needed to generate the lexical analysis components of the compiler. lex is a language specifically designed to create compiler lexical analysis components.

In the example using yacc, parser syntax 1208 is provided to yacc compiler 1216 to create the source code and header files 1214 needed to generate the parsing components of the compiler. yacc provides a general tool for specifying the structure of source code input and the code to be called when each such structure is recognized.

The source code that is ultimately responsible for generating the components needed to build the software development tool is a set of C source and header files 1210/1214 generated by the retargeting tool in the SDA's configuration. Generated by integrating with the included common framework 1218. For example, the lexical and parsing components are generated by compiling a set of C source and header files 1214 integrated with the common framework source code and header files 1218. Similarly, other software development tool components can be generated by compiling a set of C source and header files 1210 integrated with the common framework source code and header files 1218.

In this way, by providing the compiler 1222 with the source code 1220, which represents the integration of the C source and header file 1210/1214 and the source code and header file 1218 of the common framework, it complies with the common framework in SDA. A compiler 1224 is generated that targets the target execution architecture described in specification 1200.

As mentioned above, the software development tool component contains a legalization table. Such a table contains enough information to identify a particular form of target instruction. The legalization framework can provide the form index used by instruction selection, instruction legalization, encoding, and listing components.

FIG. 13 is a flow chart of an embodiment of a method implemented in software for code generation suitable for use with the techniques described herein. At 1302, we create some components represented by the source code by processing the target execution architecture specification. Then, in 1304, the source components are integrated to form the framework represented by the source code. The framework can be provided by the SDA core or included with the SDA core. Custom code can also be included in block 1306 if desired. Then, in block 1308, create a software development tool from the code generation component by compiling the integrated source code.

<u style="single">Extension of core data structure</u> Another embodiment of the SDA provides methods and systems for extensiblely configuring SDA core data structures. The extended fields of the SDA core data structure may depend on the software development scenario, which SDA configuration is built, or other factors depending on the individual desired characteristics of the target software development tool. Figure 14A shows the overall process of extending the core class definition to build tools by extending the core framework. First, in 1402, it receives the data instructing the extension (extension), and in 1404, it extends the class of the software development tool as instructed by the extension.

Figure 14B shows the overall process of building software development tools by using software scenario-dependent extensions to extend the SDA core framework. In 1410, core classes can be defined using the Simplified Object Definition Language (ODL). The 1420 can then determine the configuration for a particular SDA based on any number of factors, such as software development scenarios. The software development scenario may indicate the type of software development tool being created, the target execution architecture, the target input language, and the like. Then, in 1430, by defining extensions using the object description language, based on some or all of the factors considered, additional or different class members needed to extend the core class. Express.

In 1440, the core class definition can be extended appropriately by associating the extension with the core class. The syntax of the object description language should define whether a core class is extensible and should be associated with a particular set of extension class members as an extension of the selected core class. In addition, preprocessor translation programs can be used to translate data or object description languages into programming languages. After such preprocessing, in 1450 it is possible to further compile the extended class definition and use it to implement other software development tools for a particular configuration by extending the core framework. it can.

Using the above process, multiple different definitions of extensions can be provided separately. Each extension can simply extend the core or base class as needed, without having to maintain complex inheritance relationships. Programmers who provide a particular extension of a core class do not need to know about other extensions of the core class. Not only does this simplify the task of defining extensions, but users of the extended core class only need to know the core class name to use the extended core class. Therefore, programmers can be freed from the task of memorizing complex hierarchical relationships between class definitions when using extended class definitions.

One way to extend a core framework program is to gain access to the core program's source code files and statically extend the core class as needed by defining extensions using the object description language. There can be something to do. After that, by processing this extension, the extension can be automatically injected into the core class and the extended class can be generated. Alternatively, you may generate an extended class by manually adding an extension directly to the source code in the source code language. Figure 15A shows that this technique adds extensions 1520, 1530, and 1540 to the core framework file 1510 to extend the core framework file 1510, and the extension 1520, as part of the thus extended core framework file 1510. It shows how to compile 1530 and 1540.

However, this method is not suitable for all purposes. This is because programmers who provide definition of extensions like 1520, 1530 and 1540 need to have access to the source code of the core framework 1510. This may not be desirable in situations where the core framework 1510 provider wants to keep the core framework source code secret. In that case, the second method shown in FIG. 15B can be used. According to this, the core compiler framework 1550 is compiled as a separate file from the extensions 1560, 1570, and 1580.

In this second approach, extensions 1560, 1570 and 1580 and the core framework 1550 are adapted to have links to each other so that at runtime the extensions are linked to the core framework and the core framework is appropriate. Can be extended to. Links may be implemented as a simple linked list that specifies which extensions should be used to extend a particular core class. This can also be achieved by using a simple naming convention that properly associates extensions with core classes when needed. Compared to the first method, this second method may require additional overhead processing related to the aspect of linking at runtime, which may result in a slower implementation. There is. On the other hand, this second approach provides the flexibility to allow developers who do not have access to the core framework source code to extend their core classes.

Figure 16 shows how to statically extend the classes involved in the core framework program before compile time, as shown above with reference to Figure 15A. Core classes and their extensions can be defined using the object description language. Definitions of core classes and extensions need not be generated at the same time or together. However, adding an extension requires access to the core program source code.

After getting such a class definition, in 1610, the ODL preprocessor processes the core class and its extension definitions together. The ODL preprocessor can translate object description language representations into source code representations. Then, in 1620, the result of the preprocessing by the ODL preprocessor is a header file or other code that represents the definition of the core class and its extensions in a source code language like C ++. It was then custom-configured in 1630 by compiling a header file with extended class definitions containing core class members and extended class members, along with the rest of the code associated with the thus extended core framework. Generate software development tools.

FIG. 17 shows an exemplary system that implements the process of FIG. As shown in Figure 17, multiple definitions 1710 of extensions for core class definition 1720 can be stored as object description language files. It is possible to provide an ODL preprocessor 1730 capable of receiving files 1710 and 1720 corresponding to the core class definition and extension definition, respectively. The preprocessor must also be able to translate files 1710 and 1720 from their object description language format into source code representation 1740. The source code representation can be any language that can be finally compiled into a format that can be executed by a computer processor. Source code 1740 generated by the preprocessor 1730 includes header files that typically store class definitions. A source code compiler 1750 suitable for the language of source code 1740 output by the preprocessor 1730 can be provided. The source code compiler 1750 compiles the source code representation 1740 to create a customized extended version 1760 of a core software program, such as a software development tool such as a compiler.

Figure 18 shows how to extend the core class definition of an extensible core framework software program by linking the extension to the appropriate core class at runtime. Core class definitions and extensions can be represented separately using the object description language. The description language may be suitable for expressing that the core class definition is dynamically extensible. Also, such languages may be suitable for expressing the association between a particular core class definition and its extensions. The syntax of one such preferred language is described in more detail below. After the definition is expressed, the ODL preprocessor can be used in 1810 to translate the definition in the object description language representation into a source code representation in 1820. However, unlike the static process (Figure 16), in the dynamic process of Figure 18, the core class definition is not processed by the ODL preprocessor along with its extension definition. Instead, a source code header file corresponding to the core class definition and a source code header file corresponding to the class extension definition are generated separately. These may be generated by different ODL preprocessors, but not necessarily. In addition, 1830 creates a separate computer-executable file by compiling the header file containing the core class definition and the header file containing the extension definition separately. However, in 1840, at runtime, you can extend a core class as defined by linking the class extension definition to the appropriate core class definition.

FIG. 19 shows an exemplary system that implements the process of FIG. As shown in Figure 19, the class extension definition is provided in the object description language and stored in file 1910. Each extension does not necessarily have to be stored as a separate file as shown. Core class definitions are also provided in the object description language and are stored in file 1920. According to the process described in Figure 18, the ODL preprocessor 1925 is provided to process the core class definition by translating it from the object description language representation to the source code language representation and store it as a header file 1935. To. Similarly, yet another ODL preprocessor 1930 can be provided to generate the source code header file 1940 containing the extension by processing the class extension file 1910. A source code compiler 1945 can be provided to generate a computer executable file 1960 containing class extension definitions by compiling the class extension header file 1940. Similarly, a source compiler 1950 can be provided to generate a computer executable file 1955 containing a core class definition by compiling a header file 1935 containing the core class definition. Then, at runtime, when the executable file 1955 corresponding to the core class and the executable file corresponding to the extension class are executed, the core class can be appropriately extended by the link 1970 provided in the core and extension class. it can.

<u style="single">Software deliverables</u> FIG. 20 is a block diagram of a computer software deliverable of the techniques described herein. Software Deliverable 2000 includes SDA2002. SDA2002 may include source code or objects for implementing one or more of the IRs, exception handling models, type systems, code generators, or core data structure extension techniques described herein. SDA2002 can be configured to generate any of a variety of software development tools in any number of software development scenarios. The configurations are not limited to the following, but are limited to the native compiler configuration 2004, JIT compiler configuration 2006, Pre-JIT compiler configuration 2008, analysis tool configuration 2010, defect detection configuration 2012, and optimizer configuration 2014. , Or CDK configuration 2016.

The software artifacts can be run on a suitable computer system to generate the target software development tools. Component 2018 will be provided for Software Deliverable 2000 / SDA2002 on computer systems. Component 2018 includes, but is not limited to, data 2020 related to the target execution architecture, set 2022 of class extension declarations, data 2024 related to the input language of the target software development tool, and one or more type rule sets. Can include one or more of 2026.

Software artifacts can generate software development rules based on selected configurations and components 2018. For example, FIG. 21 is a block diagram showing a specific example of the software execution file shown in FIG.

Software Deliverable 2100 includes SDA2102 in the optimizer configuration. Component 2104 contains data 2106 related to x86, set 2108 of class extension declarations consistent with the optimizer configuration, data 2110 related to the input language C ++, and three rule sets 2112 for type checking (for example, one). The set corresponds to a strong type check, one corresponds to a weak type check, and one corresponds to a phenotypic check). Optimizer 2114 is created by linking component 2104 to software deliverable 2100 / SDA2102. Optimizer 2114 takes source code written in the C ++ language as input and targets the x86 architecture.

FIG. 22 shows another embodiment of the computer software deliverables of the techniques described herein. In this embodiment, the software artifact 2200 can be a computer executable file version, such as a binary of SDA2210. In that case, the software development component 2220 can be linked (eg dynamically) to the software artifact 2200 (eg, at runtime without accessing the source code). The software development tool 2230 can be created from the combination of the resulting components and software deliverables.

Alternatively, the existing software development tool 2300 can be modified, as shown in Figure 23. Software development tool 2300 can be generated using SDA2310 in various methods and the like described herein. You can then create a new component 2320 and link it to SDA2310 to create a modified version 2330 of the software development tool.

In yet another embodiment, SDA can be used to create inter-compatible software tools. FIG. 24 is a block diagram of the first software development tool 2400 generated using the SDA2410. The second software development tool 2440 can then be formed by creating one or more new components 2420 containing the functionality of the second software tool and linking it to SDA2430 in an executable format such as binary. it can. The first and second software tools 2400/2440 are interchangeable because they share the characteristics of SDA (like common IR).

<u style="single">Extensibility of exemplary IR format</u> Since the core classes defined for SDA are extensible, the IR format itself is also extensible. For example, you can add a new class member to your core class and represent it in IR format. Such a configuration can be beneficial for scalability purposes. For example, it may be desirable to use lightweight (lightweight) data structures for the JIT compiler (for performance reasons, for example). On the other hand, a more comprehensive data structure may be appropriate for an optimizing compiler for all programs.

The core class can be extended by the object description language mechanism described herein. Therefore, a core class can be extended either during development or runtime of the appropriate software component or tool (eg, without accessing the core class source code). In this way, the system can support runtime extensibility in IR format.

<u style="single">Illustrative software development scenario independence</u> Software development scenario independence can be demonstrated in a variety of ways. For example, independence for one or more software development scenarios. For example, the implementation can be independent of a programming language (eg input language), software execution architecture (eg processor or virtual machine), exception handling model, managed code scenario, etc., or any combination thereof.

<u style="single">Illustrative operating environment</u> FIG. 25 shows an example of a computer system that acts as an operating environment for one embodiment of SDA. The computer system includes a personal computer 2520, which includes a processing unit 2521, a system memory 2522, and a system bus 2523 that interconnects various system components, including system memory, with the processing unit 2521. The system bus may include any of several types of bus structures, including memory buses or memory controllers, peripheral buses, and local buses. Bus architectures used by bus structures include, to name a few, PCI, VESA, Microchannel (MCA), ISA and EISA. System memory includes read-only memory (ROM) 2524 and random access memory (RAM) 2525. The ROM 2524 contains a basic I / O system 2526 (BIOS) that contains basic routines that help transfer information between elements in the personal computer 2520, such as during boot. The personal computer 2520 also has a hard disk drive 2527, a magnetic disk drive 2528 (for example, reading and writing removable disk 2529), and an optical disk drive 2530 (for example, reading and writing a CD-ROM disk 2531 or reading and writing other optical media). including. The hard disk drive 2527, the magnetic disk drive 2528, and the optical disk drive 2530 are connected to the system bus 2523 by the hard disk drive interface 2532, the magnetic disk drive interface 2533, and the optical drive interface 2534, respectively. The drives and their associated computer-readable media provide non-volatile storage such as data, data structures, computer executable instructions (dynamic link libraries, and program code such as executable files) for the personal computer 2520. The above compute

Multiple program modules can be stored in the drive and RAM 2525. Such program modules include operating system 2535, one or more application programs 2536, other program modules 2537, and program data 2538. The user can enter commands and information into the personal computer 2520 through a pointing device such as a keyboard 2540 and a mouse 2542. Other input devices (not shown) include microphones, joysticks, gamepads, satellite dishes, scanners and the like. These and other input devices are often connected to processing unit 2521 through a serial port interface 2546 coupled to the system bus, but are connected by other interfaces such as a parallel port, game port or universal serial bus (USB). May be done. Monitor 2547 or other types of display devices are also connected to system bus 2523 via an interface such as a display controller or video adapter 2548. In addition to monitors, personal computers typically include other peripheral output devices (not shown) such as speakers and printers.

The personal computer 2520 may operate in a network environment with a logical connection to one or more remote computers, such as the remote computer 2549. The remote computer 2549 may be a server, router, peer device or other ordinary network node and typically includes many or all of the elements mentioned above with respect to the personal computer 2520. However, only the memory storage device 2550 is illustrated in FIG. The logical connections shown in Figure 25 include a local area network (LAN) 2551 and a wide area network (WAN) 2552. Such networking environments are common in offices, enterprise-scale computer networks, intranets, and the Internet.

When used in a LAN networking environment, the personal computer 2520 is connected to the local network 2551 through a network interface or adapter 2553. When used in a WAN networking environment, the personal computer 2520 typically includes means such as a modem 2554 for establishing communication over a wide area network 2552 such as the Internet. Modem 2554, whether internal or external, is connected to system bus 2523 via serial port interface 2546. In a network environment, the program module illustrated for personal computer 2520 or a portion thereof may be stored in a remote memory storage device. The network connections shown are merely examples, and other means of establishing communication links between computers may be used.

<u style="single">Alternative form</u> The principles of exemplary embodiments have been illustrated and described above, but as will be apparent to those skilled in the art, embodiments can be modified in configuration and detail without departing from such principles.

Given the many possible embodiments, it will be recognized that the illustrated embodiments merely include examples and should not be construed as a limitation to the scope of the invention. Rather, the invention is defined by the claims. Therefore, the inventors claim all such embodiments within the scope of the claims as the present invention.

<figref num="1">It is a block diagram which shows SDA for building various software development tools.</figref><figref num="2A">It is a flowchart which shows the method of creating a software development tool using SDA.</figref><figref num="2B">It is a flowchart which shows another method of creating a software development tool using SDA.</figref><figref num="3">It is a high-level block diagram of a system that creates components of software development tools using SDA.</figref><figref num="4">It is a block diagram showing a compiler, a debugger, and an optimizer for each of the three target execution architectures created using a system as shown in FIG.</figref><figref num="5">It is a block diagram which shows an exemplary compilation process in a compiler created using SDA.</figref><figref num="6A">It is a diagram of the first stage showing step by step the IR conversion from the source loading to the low-level machine-dependent IR through the high-level machine-independent IR.</figref><figref num="6B">It is a subsequent figure which shows step by step the IR conversion from the reading of a source through the high level machine independent IR to the low level machine dependent IR.</figref><figref num="6C">It is a further subsequent figure which shows step by step the IR conversion from the source reading to the low level machine dependent IR through the high level machine independent IR.</figref><figref num="6D">It is a diagram of the final stage showing step by step the IR conversion from the source loading to the low-level machine-dependent IR through the high-level machine-independent IR.</figref><figref num="7">It is a block diagram of an embodiment of a compiler system that types-checks IR at various stages of compilation.</figref><figref num="8">It is a block diagram of a mold checker for use with IR.</figref><figref num="9">It is a figure which shows the system which implements unified exception handling in IR.</figref><figref num="10A">It is a figure which shows the method of generating a unified set of intermediate representations for an exception handling construct using an IL reader.</figref><figref num="10B">It is a figure which shows the method of generating the executable file from the unified IR of software.</figref><figref num="11">It is a block diagram of a system that generates a simple and unified IR of exception handling constructs in multiple source languages expressed in the form of multiple IL representations.</figref><figref num="12">It is a block diagram of a system for code generation.</figref><figref num="13">It is a flowchart of one Embodiment of the method implemented in software for code generation.</figref><figref num="14A">It is a diagram showing the whole process of extending the core class definition to build a tool by extending the core framework.</figref><figref num="14B">It is a diagram showing the overall process of building software development tools by using software scenario-dependent extensions to extend the SDA core framework.</figref><figref num="15A">It is a figure which shows the method of adding an extension to the core compiler framework to extend the core compiler framework.</figref><figref num="15B">It is a figure which shows the method in which a core compiler framework is compiled as a file separate from an extension.</figref><figref num="16">It is a figure which shows the method of statically extending a class related to a core framework program before compile time.</figref><figref num="17">FIG. 5 illustrates an exemplary system that implements the process of FIG.</figref><figref num="18">It is a figure which shows the method of extending the core class definition of an extensible core framework software program by linking an extension to an appropriate core class at runtime.</figref><figref num="19">FIG. 5 illustrates an exemplary system that implements the process of FIG.</figref><figref num="20">It is a block diagram of a computer software product.</figref><figref num="21">It is a block diagram which shows a specific example of the software execution file shown in FIG.</figref><figref num="22">Another embodiment of the computer software deliverable is shown.</figref><figref num="23">It is a figure which shows the computer software artifact for modifying an existing software development tool.</figref><figref num="24">It is a figure which shows the creation of the intercompatible software tool from SDA.</figref><figref num="25">It is a figure which shows an example of the computer system which acts as an operating environment for one Embodiment of SDA.</figref>

Code description

100 SDA core 102 Managed and / or Native Application Program Interface (API) 104 Native compiler 106 Pre-JIT compiler 108 JIT compiler 110 Optimization tool 112 Defect detection tool 114 Analysis tool 116 Compiler Development Kit (CDK) 300 SDA 302 specifications 304 component 306 Tool 700 source code 702 HIR 704 MIR 706 LIR 708 type checker 710 rule set 800 type checker 802,804,806,808 rule set 810,812 Program module 905 ~ 908 Source language 910 ~ 913 Intermediate Language (IL) Representation 920 IL reader 930 IR 940 compiler backend 1110 Source language group 1130 CIL 1135,1145 IL reader 1160 back end 1200,1204 specifications 1202 Retargeting Tool 1206 Tokenization grammar 1208 parser grammar 1210 C source and header files 1212 lex compiler 1214 Source code and header files 1216 yacc compiler 1218 Common framework source code and header files 1220 source code 1222,1224 compiler 1510 core framework file 1520,1530,1540 Extension 1550 Core Compiler Framework 1560,1570,1580 Extension 1710 Extension definition 1720 core class definition 1730 ODL preprocessor 1740 Source code representation 1750 source code compiler Customized enhanced version of the 1760 core software program 1925, 1930 ODL preprocessor 1935,1940 Header file 1945,1950 Source code compiler 1955 Computer executable file containing core class definitions 1960 Computer executable file containing class extension definitions 1970 link 2000 Software Deliverable 2002 SDA 2004 native compiler configuration 2006 JIT compiler configuration 2008 Pre-JIT compiler configuration 2010 Analysis Tool Configuration 2012 defect detection configuration 2014 optimizer configuration 2016 CDK configuration 2018 components 2020 Data related to the target execution architecture 2022 Set of class extension declarations 2024 Data related to the input language of the target software development tool 2026 type rule set 2100 Software Deliverable 2102 SDA 2104 component Data related to 2106 x86 2108 Set of class extension declarations 2110 Data related to input language C ++ 2112 rule set 2114 optimizer 2200 Software Deliverable 2210 SDA 2220 Software Development Components 2230 Software Development Tools 2300 Software Development Tools 2310 SDA 2320 component 2330 Modified version of software development tools 2400 First software development tool 2410,2430 SDA 2420 component 2440 Second software development tool 2520 personal computer 2521 Processing unit 2522 system memory 2523 System bus 2524 Read-only memory (ROM) 2525 Random access memory (RAM) 2526 Basic I / O System (BIOS) 2527 hard disk drive 2528 magnetic disk drive 2529 Removable disk 2530 optical disk drive 2531 CD-ROM disc 2532 hard disk drive interface 2533 Magnetic disk drive interface 2534 Optical drive interface 2535 operating system 2536 application program 2537 Other program modules 2538 Program data 2540 keyboard 2542 mouse 2546 Serial port interface 2547 monitor 2548 video adapter 2549 remote computer 2550 memory storage device 2551 Local Area Network (LAN) 2552 Wide Area Network (WAN) 2553 Network interface (adapter) 2554 modem