US7216332B2 - Software object library selection - Google Patents

Software object library selection Download PDF

Info

Publication number
US7216332B2
US7216332B2 US10/378,658 US37865803A US7216332B2 US 7216332 B2 US7216332 B2 US 7216332B2 US 37865803 A US37865803 A US 37865803A US 7216332 B2 US7216332 B2 US 7216332B2
Authority
US
United States
Prior art keywords
library
source code
execution environment
entities
machine code
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime, expires
Application number
US10/378,658
Other versions
US20030182650A1 (en
Inventor
Lee D. Smith
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ARM Ltd
Original Assignee
ARM Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ARM Ltd filed Critical ARM Ltd
Priority to US10/378,658 priority Critical patent/US7216332B2/en
Assigned to ARM LIMITED reassignment ARM LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SMITH, LEE D.
Publication of US20030182650A1 publication Critical patent/US20030182650A1/en
Application granted granted Critical
Publication of US7216332B2 publication Critical patent/US7216332B2/en
Adjusted expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management

Definitions

  • This invention relates to the field of data processing systems. More particularly, this invention relates to techniques for generating machine code entities based upon source code entities using libraries of machine code entities.
  • the different libraries of machine code entities cater for different build options that may be selected by a user. As an example, a user may wish to use the same source code entities to generate machine code entities for differing target processor instruction set versions or for target processors having different hardware capabilities.
  • the machine code entities within the different libraries are matched to the different build options to which they relate to produce the most efficient processing for those build options.
  • machine code entity libraries provided in a software development tool system should be usable with all possible build options that a user might select.
  • One solution might be to provide a software library for every possible combination of build options.
  • the large number of possible combinations of build options make this impractical.
  • a related problem is how a user is to select the correct library to use from among a large number of libraries.
  • the present invention provides apparatus for generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said apparatus for generating comprising:
  • the invention recognizes that lattice theory techniques can be applied to the characterization of build option parameters to rigorously model execution environment requirements so that a library selector may be generated for a group of source code entities representing the maximum execution environment requirements of that group of source code entities (object code) and then this library selector may be used to identify a suitable library of machine code entities (such as files, sections or symbols)
  • This rigorous approach allows the selection of the most suitable library of machine code entities (for generating an executable image) to be automated whilst ensuring that the selected library will be compatible with the execution environment requirements and be an efficient library.
  • incompatibility is indicated by the detection of a lattice top in one or more of the independent components of the library selecting vector.
  • preferred embodiments of the invention embed more than one minor variant of some machine code entities within a library with the final selection of the machine code entity being made amongst these minor variants using the build option parameters for the specific source code entity requiring that machine code entity. See Section 3.3.1 of the attached Appendix.
  • source code entities could be formed from many different computer programing languages, However, the present invention is particularly well suited to systems in which the source code entities are formed from C or C++ or assembly language source code entities for the target data processor.
  • the different build options that may be specified by a user of the software development tools include an instruction set identifier for the target data processing system, the identification of any optional instruction processing hardware present (e.g. a floating point unit, a vector floating point unit etc), the endianness, position independence, stack checking status, memory system capabilities and procedure call options.
  • the invention is particularly well suited to systems in which those build options giving rise to the greatest demands on the execution environment have significant advantages (such as greater performance or smaller size) since the system allows the library best matched to those more demanding options to be selected rather than the most compatible library that might be significantly sub-optimal in that execution environment.
  • the present invention provides a method of generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said method of generating comprising the steps of:
  • the present invention provides a computer program carrier, e.g., such as a computer readable medium, bearing (storing) a computer program for controlling a data processing apparatus to perform a method of generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said method of generating comprising the steps of:
  • the present invention provides a method of forming a set of libraries of machine code entities for use in generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said method of forming comprising tie steps of:
  • This aspect of the invention exploits the ability of a lattice theory model of execution environment requirements (compatibility) to enable a rigorous determination to be made that at least one library that will work is provided for every possible combination of build option parameters.
  • FIG. 1 schematically illustrates the process of generating a group of machine code entities from source code using libraries of machine code entities.
  • FIG. 2 schematically illustrates a target data processing apparatus having various build option parameters
  • FIG. 3 is a flow diagram illustrating the operations performed by the linker of FIG. 1 ;
  • FIG. 4 is a schematic of how build options may be specified.
  • FIG. 1 illustrates the use of a software development tool system for forming machine code for a target processing apparatus from source code.
  • a software developer may write a mixed program comprising some C or C++ source code 10 and some assembly language source code 12 .
  • This source code 10 , 12 together with the user selected build option parameters are supplied as inputs to a compiler 14 and an assembler 16 respectively. If a user does not specify the build option parameters to be used with a particular source code object, then the compiler 14 or the assembler 16 may use its own default values for those particular build option parameters.
  • the compiler 14 and assembler 16 translate the input source code 10 , 12 to source code entities 18 , 20 (i.e. the entity derived from the corresponding source code such as a file, section or symbol).
  • source code entities 18 , 20 represent the primitive structures from which the computer program as a whole is formed.
  • the groups of source code entities 18 , 20 have their respective build options associated with them.
  • a “source code entity” represents an entity explicitly specified as an input by the user (or by an IDE or “make” system acting as the user's agent), in contrast to entities located automatically by the linker.
  • the groups of source code entities 18 , 20 are supplied as one input to a linker 22 .
  • the linker 22 serves the function of identifying an appropriate library of machine code entities within a collection of libraries 24 and then matching the different source code entities to the appropriate machine code entities within the selected library.
  • the output from the linker 22 is a machine code image 25 (group of machine code entities) that forms an executable program upon the target processor apparatus.
  • FIG. 2 schematically illustrates a theoretical example target processor apparatus.
  • a processor core 26 such as an ARM core produced by ARM Limited of Cambridge, England, is provided at the heart of the system.
  • the processor core 26 will have a particular instruction set architecture that it supports, e.g. the ARM Instruction Set Architecture Version 4.
  • a vector floating point unit 28 is provided in association with the processor core 26 to provide hardware support for vector floating point instructions.
  • the memory system 30 coupled to the processor core 26 is in this instance a burst mode memory.
  • the memory includes a stack memory area 32 , which for the program being produced, has been specified by the programmer to be an unchecked stack memory.
  • the data storage and transfer between the processor 26 and the memory 30 is big-endian.
  • a crude software development tool system could simply provide one library of machine code entities for each major variant assuming the least possible execution environment requirement build options for all minor variants covered by that library, e.g. assume the earliest instruction set architecture knowing that later instruction set architectures will be compatible with this.
  • Compatibility lattices tend to be broad and shallow, so there are many incompatible major variants that are least in the lattice (i.e. above bottom, but not above any other non-bottom element). As an example, there is no least element between big-endian and little-endian, libraries for each must be provided if both are to be supported.
  • a crude software development system that provided only one major variant library would necessarily have to deny build options able to create other major variant.
  • a system that provided no vector floating point library would have to preclude generating vector floating point instructions that could take advantage of the vector floating point unit 28 .
  • processor core 26 in the illustrated system supports Version 4 of the instruction set architecture.
  • a later more sophisticated instruction set architecture namely, Version 5 is supported by different processor cores. If Version 5 were supported by the processor core 26 , then more efficient and desirable machine code entities could be used. However, such code would not run on the illustrated target processor.
  • the lattice theory compatibility modelling allows a library containing Version 4 machine code entities to be selected thereby making the most of the capabilities of the system by not merely reverting to a less desirable Version 3 instruction set architecture assumption that would work in all cases.
  • system may be arranged such that one major variant is selected that contains Version 3 Version 4 and Version 5 machine code entities (minor variants).
  • minimum variants machine code entities
  • minor variants are “interface compatible”, i.e. there is some execution environment in which any of them could be used, e.g. in the above example a Version 5 environment.
  • Major variants are “interface incompatible”, i.e. there is no execution environment in which the variants are interchangable, e.g. big-endian and little-endian are not mixed within an environment.
  • the stack memory 32 has been user specified as unchecked. If some of the source code objects assume a checked stack, then the linker 22 will flag all incompatibility before the machine code is produced. The user can then adjust the build option parameters or source code accordingly to rectify this incompatibility.
  • FIG. 3 schematically illustrates a flow diagram showing the operation of the linker 22 of FIG. 1 (the linker is in practice embodied as software controlling a general purpose computer).
  • Each machine code entity has an associated attribute vector encoding its build option parameters in accordance with a lattice theory model of their compatibility and relative desirability.
  • the linker 22 joins (in the lattice of all build option related attributes) the input attributes of all of the source code entities.
  • This joined vector becomes the library selector (e.g. using a library selecting vector or a list mechanism) as it specifies the maximum execution environment requirements of the source code entities.
  • Step 36 serves to identify any incompatibilities amongst the build option parameters specified. As an example, if one source code entity specified an unchecked stack and another a checked stack, then this incompatibility would need to be resolved before the machine code program could be properly produced. In practice incompatibilities might be detected by detecting within the library selecting vector a lattice top in some of its independent components.
  • Step 38 uses the library selecting vector produced at step 34 to select the particular library of machine code entities within the library collection 24 that is to be used.
  • the particular library selected is the one having the best level of component vector values that are compatible with the component values for the library selecting vector produced at step 32 .
  • each library various minor variants may be provided for by providing different machine code entities for those different minor variants. These are detected and selected at step 40 .
  • step 42 the executable machine code is generated using the machine code entities from the selected library of machine code entities including selected minor variants.
  • the library selecting vector discussed above could have a wide variety of different forms and may be properly considered to be a library selector.
  • the library selector could utilise various coding mechanisms, such as, for example, a list mechanism as will be familiar to those skilled in this technical field.
  • the block of code may preferably execute using its maximum instruction set architecture version encoding, it is capable of executing in lower instruction set architecture version environments and so the characteristic to determine regarding its dynamic characteristics is the minimum execution environment requirements concerned and this is done with a lattice theory meet operation as opposed to a lattice theory join operation which is utilised to identify a maximum.

Abstract

A software development system is described in which lattice theory is used to model the compatibility and desirability in the target execution environment of various build option parameters selected by a user. A library selector is formed by combining the build option parameters of each source code entity to produce a selector having the maximum level of execution environment requirements needed among the group of source code entities being compiled. This library selector may be used to select a particular library of machine code entities compatible with these execution environment requirements whilst providing the most desirable machine code entities to exploit the capabilities of the target data processing system.

Description

This application is a continuation-in-part of application Ser. No. 09/503,485, filed Feb. 14, 2000 now abandoned, the entire content of which is hereby incorporated by reference in this application.
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of data processing systems. More particularly, this invention relates to techniques for generating machine code entities based upon source code entities using libraries of machine code entities.
2. Description of the Prior Art
It is known to provide software development tools including a plurality of libraries of machine code entities. The different libraries of machine code entities cater for different build options that may be selected by a user. As an example, a user may wish to use the same source code entities to generate machine code entities for differing target processor instruction set versions or for target processors having different hardware capabilities. The machine code entities within the different libraries are matched to the different build options to which they relate to produce the most efficient processing for those build options.
The number of user specified options in such systems is increasing. As a consequence, the number of possible different combinations of build options is rapidly increasing to become a large number of possible combinations
It is desirable that the machine code entity libraries provided in a software development tool system should be usable with all possible build options that a user might select. One solution might be to provide a software library for every possible combination of build options. However, the large number of possible combinations of build options make this impractical. A related problem is how a user is to select the correct library to use from among a large number of libraries.
SUMMARY OF THE INVENTION
Viewed from one aspect the present invention provides apparatus for generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said apparatus for generating comprising:
    • (i) library selector forming logic responsive to said at least one build option parameter of each source code entity for forming a library selector, wherein.
      • (a) build option parameters of each source code entity are combined in accordance with lattice theory whereby each build option parameter has a value indicative of position within a partially ordered lattice chain representing relative execution environment requirements for that build option parameter, and
      • (b) said library selector is formed with components corresponding to a limiting level of execution environment requirements among said group of source code entities;
    • (ii) library selecting logic responsive to said library selector for selecting, from among a plurality of libraries of machine code entities, a selected library of machine code entities having a best level of execution environment requirements compatible with said limiting level of execution environment requirements indicated by said library selector; and
    • (iii) machine code entity generating logic for generating said group of machine code entities from machine code entities within said selected library of machine code entities to dependence upon said group of source code entities.
The invention recognizes that lattice theory techniques can be applied to the characterization of build option parameters to rigorously model execution environment requirements so that a library selector may be generated for a group of source code entities representing the maximum execution environment requirements of that group of source code entities (object code) and then this library selector may be used to identify a suitable library of machine code entities (such as files, sections or symbols) This rigorous approach allows the selection of the most suitable library of machine code entities (for generating an executable image) to be automated whilst ensuring that the selected library will be compatible with the execution environment requirements and be an efficient library.
The use of lattice theory modeling techniques for the execution environment requirements of the source code entities also allows incompatibilities between source code entities to be identified in a rigorous manner.
In preferred embodiments incompatibility is indicated by the detection of a lattice top in one or more of the independent components of the library selecting vector.
In order to reduce the total number of libraries that need to be provided preferred embodiments of the invention embed more than one minor variant of some machine code entities within a library with the final selection of the machine code entity being made amongst these minor variants using the build option parameters for the specific source code entity requiring that machine code entity. See Section 3.3.1 of the attached Appendix.
It will be appreciated that the source code entities could be formed from many different computer programing languages, However, the present invention is particularly well suited to systems in which the source code entities are formed from C or C++ or assembly language source code entities for the target data processor.
The different build options that may be specified by a user of the software development tools include an instruction set identifier for the target data processing system, the identification of any optional instruction processing hardware present (e.g. a floating point unit, a vector floating point unit etc), the endianness, position independence, stack checking status, memory system capabilities and procedure call options.
The invention is particularly well suited to systems in which those build options giving rise to the greatest demands on the execution environment have significant advantages (such as greater performance or smaller size) since the system allows the library best matched to those more demanding options to be selected rather than the most compatible library that might be significantly sub-optimal in that execution environment.
Viewed from another aspect the present invention provides a method of generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said method of generating comprising the steps of:
    • (i) in response to said at least one build option parameter of each source code entity, forming a library selector, wherein:
      • (a) build option parameters of each source code entity are combined in accordance with lattice theory whereby each build option parameter has a value indicative of position within a partially ordered lattice chain representing relative execution environment requirements for that build option parameter, and
      • (b) said library selector is formed with components corresponding to a limiting level of execution environment requirements among said group of source code entities;
    • (ii) in response to said library selector, selecting, from among a plurality of libraries of machine code entities, a selected library of machine code entities having a best level of execution environment requirements compatible with said limiting level of execution environment requirements indicated by said library selector; and
    • (iii) generating said group of machine code entities from machine code entities within said selected library of machine code objects in dependence upon said group of source code entities.
Viewed from a further aspect the present invention provides a computer program carrier, e.g., such as a computer readable medium, bearing (storing) a computer program for controlling a data processing apparatus to perform a method of generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said method of generating comprising the steps of:
    • (i) in response to said at least one build option parameter of each source code entity, forming a library selector, wherein:
      • (a) build option parameters of each source code entity are combined in accordance with lattice theory whereby each build option parameter has a value indicative of position within a partially ordered lattice chain representing relative execution environment requirements for that build option parameter, and
      • (b) said library selector is formed with components corresponding to a limiting level of execution environment requirements among said group of source code entities;
    • (ii) in response to said library selector, selecting, from among a plurality of libraries of machine code entities, a selected library of machine code entities having a best level of execution environment requirements compatible with said limiting level of execution environment requirements indicated by said library selector; and
    • (iii) generating said group of machine code entities from machine code entities within said selected library of machine code entities in dependence upon said group of source code entities.
Viewed from a still further aspect the present invention provides a method of forming a set of libraries of machine code entities for use in generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said method of forming comprising tie steps of:
    • (i) associating a library selector with each library of machine code entities, wherein:
      • (a) supported build option parameters for each machine code entity within a library are combined in accordance with lattice theory whereby each build option parameter has a value indicative of position within a partially ordered lattice chain representing relative execution environment requirements for that build option parameter, and
      • (b) said library selector is formed with components corresponding to a limiting level of execution environment requirements needed by said library of machine code objects; and
    • (ii) determining from said library selectors that at least one compatible library of machine code entities is present for each possible combination of build option parameters of said source code entities.
This aspect of the invention exploits the ability of a lattice theory model of execution environment requirements (compatibility) to enable a rigorous determination to be made that at least one library that will work is provided for every possible combination of build option parameters.
The above, and other objects, features and advantages of this invention will be apparent from the following detailed description of illustrative embodiments which is to be read in connection with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 schematically illustrates the process of generating a group of machine code entities from source code using libraries of machine code entities.
FIG. 2 schematically illustrates a target data processing apparatus having various build option parameters;
FIG. 3 is a flow diagram illustrating the operations performed by the linker of FIG. 1; and
FIG. 4 is a schematic of how build options may be specified.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
FIG. 1 illustrates the use of a software development tool system for forming machine code for a target processing apparatus from source code. A software developer may write a mixed program comprising some C or C++ source code 10 and some assembly language source code 12. This source code 10, 12 together with the user selected build option parameters are supplied as inputs to a compiler 14 and an assembler 16 respectively. If a user does not specify the build option parameters to be used with a particular source code object, then the compiler 14 or the assembler 16 may use its own default values for those particular build option parameters.
Specifically, in this embodiment all objects have “build option parameters” associated with them. These are derived in 3 ways:
    • Objects built by attribute aware object producers have a BuildAttributes$ . . . string. Entries in it correspond to:
      • Options explicitly requested by a user.
      • Options implicitly assumed by the object producer.
    • Objects built by attribute-oblivious object producers (older releases of the SDT (Software Development Toolkit) for example), nonetheless get build option parameters associated with them based on what can be inferred about their build options from, for example, the library requests they make.
The whole system has been designed so that, in general, if an object is completely devoid of build attributes—built by an alien, attribute-oblivious object producer—it will link in the most common modes of usage (most common choices of build option parameters) by virtue of have a “bottom” as the relevant components of its selecting vector. Of course, such linkage is at the user's risk, and little can be diagnosed about it, so it cannot be guaranteed to produce a working binary!
The compiler 14 and assembler 16 translate the input source code 10, 12 to source code entities 18, 20 (i.e. the entity derived from the corresponding source code such as a file, section or symbol). These groups of source code entities 18, 20 represent the primitive structures from which the computer program as a whole is formed. The groups of source code entities 18, 20 have their respective build options associated with them. In the context of a linker a “source code entity” represents an entity explicitly specified as an input by the user (or by an IDE or “make” system acting as the user's agent), in contrast to entities located automatically by the linker.
The groups of source code entities 18, 20 are supplied as one input to a linker 22. In relation to the mechanism of at least the preferred embodiments of this invention the linker 22 serves the function of identifying an appropriate library of machine code entities within a collection of libraries 24 and then matching the different source code entities to the appropriate machine code entities within the selected library. The output from the linker 22 is a machine code image 25 (group of machine code entities) that forms an executable program upon the target processor apparatus.
FIG. 2 schematically illustrates a theoretical example target processor apparatus. A processor core 26, such as an ARM core produced by ARM Limited of Cambridge, England, is provided at the heart of the system. The processor core 26 will have a particular instruction set architecture that it supports, e.g. the ARM Instruction Set Architecture Version 4. In the illustrated system a vector floating point unit 28 is provided in association with the processor core 26 to provide hardware support for vector floating point instructions. The memory system 30 coupled to the processor core 26 is in this instance a burst mode memory. The memory includes a stack memory area 32, which for the program being produced, has been specified by the programmer to be an unchecked stack memory. The data storage and transfer between the processor 26 and the memory 30 is big-endian.
It will be appreciated that a crude software development tool system could simply provide one library of machine code entities for each major variant assuming the least possible execution environment requirement build options for all minor variants covered by that library, e.g. assume the earliest instruction set architecture knowing that later instruction set architectures will be compatible with this. Compatibility lattices tend to be broad and shallow, so there are many incompatible major variants that are least in the lattice (i.e. above bottom, but not above any other non-bottom element). As an example, there is no least element between big-endian and little-endian, libraries for each must be provided if both are to be supported.
A crude software development system that provided only one major variant library would necessarily have to deny build options able to create other major variant. Thus, a system that provided no vector floating point library would have to preclude generating vector floating point instructions that could take advantage of the vector floating point unit 28.
Another example is that the processor core 26 in the illustrated system supports Version 4 of the instruction set architecture. A later more sophisticated instruction set architecture, namely, Version 5, is supported by different processor cores. If Version 5 were supported by the processor core 26, then more efficient and desirable machine code entities could be used. However, such code would not run on the illustrated target processor. The lattice theory compatibility modelling allows a library containing Version 4 machine code entities to be selected thereby making the most of the capabilities of the system by not merely reverting to a less desirable Version 3 instruction set architecture assumption that would work in all cases.
As an alternative the system may be arranged such that one major variant is selected that contains Version 3 Version 4 and Version 5 machine code entities (minor variants). The lattice theoretic modelling allows the most desirable minor variant to be chosen
It should be noted that minor variants are “interface compatible”, i.e. there is some execution environment in which any of them could be used, e.g. in the above example a Version 5 environment. Major variants are “interface incompatible”, i.e. there is no execution environment in which the variants are interchangable, e.g. big-endian and little-endian are not mixed within an environment.
The stack memory 32 has been user specified as unchecked. If some of the source code objects assume a checked stack, then the linker 22 will flag all incompatibility before the machine code is produced. The user can then adjust the build option parameters or source code accordingly to rectify this incompatibility.
FIG. 3 schematically illustrates a flow diagram showing the operation of the linker 22 of FIG. 1 (the linker is in practice embodied as software controlling a general purpose computer). Each machine code entity has an associated attribute vector encoding its build option parameters in accordance with a lattice theory model of their compatibility and relative desirability. At step 34 the linker 22 joins (in the lattice of all build option related attributes) the input attributes of all of the source code entities. This joined vector becomes the library selector (e.g. using a library selecting vector or a list mechanism) as it specifies the maximum execution environment requirements of the source code entities.
Step 36 serves to identify any incompatibilities amongst the build option parameters specified. As an example, if one source code entity specified an unchecked stack and another a checked stack, then this incompatibility would need to be resolved before the machine code program could be properly produced. In practice incompatibilities might be detected by detecting within the library selecting vector a lattice top in some of its independent components.
Step 38 uses the library selecting vector produced at step 34 to select the particular library of machine code entities within the library collection 24 that is to be used. The particular library selected is the one having the best level of component vector values that are compatible with the component values for the library selecting vector produced at step 32.
Within each library various minor variants may be provided for by providing different machine code entities for those different minor variants. These are detected and selected at step 40.
Finally at step 42 the executable machine code is generated using the machine code entities from the selected library of machine code entities including selected minor variants.
An alternative view of the invention is set out in the following Appendix.
It will be appreciated that the library selecting vector discussed above could have a wide variety of different forms and may be properly considered to be a library selector. The library selector could utilise various coding mechanisms, such as, for example, a list mechanism as will be familiar to those skilled in this technical field.
There are circumstances where the maximum level of execution environment requirement which is sought to be determined and managed by the present technique can more properly be considered to be a limiting level of execution environment requirement. In particular, there are circumstances in which a minimum level of execution environment requirement is what it is appropriate to identify and manage. As an example, a block of code which tests its operating environment to determine a version level of an instruction set architecture supported in that environment and then runs a version of itself appropriate to the operating environment can be considered to have a static type of execution environment requirement and a dynamic type of execution environment requirement. Whilst the block of code may preferably execute using its maximum instruction set architecture version encoding, it is capable of executing in lower instruction set architecture version environments and so the characteristic to determine regarding its dynamic characteristics is the minimum execution environment requirements concerned and this is done with a lattice theory meet operation as opposed to a lattice theory join operation which is utilised to identify a maximum.
Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims.

Claims (24)

1. A programmed computer apparatus for generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said apparatus for generating comprising:
(i) library selector forming logic responsive to said at least one build option parameter of each source code entity for forming a library selector, wherein:
(a) build option parameters of each source code entity are combined in accordance with lattice theory whereby each build option parameter has a value indicative of position within a partially ordered lattice chain representing relative execution environment requirements for that build option parameter, and
(b) said library selector is formed with components corresponding to a limiting level of execution environment requirements among said group of source code entities;
(ii) library selecting logic responsive to said library selector for selecting, from among a plurality of libraries of machine code entities, a selected library of machine code entities having a best level of execution environment requirements compatible with said limiting level of execution environment requirements indicated by said library selector; and
(iii) machine code entity generating logic for generating said group of machine code entities from machine code entities within said selected library of machine code entities in dependence upon said group of source code entities.
2. Apparatus as claimed in claim 1, wherein said library selector forming logic uses said partially ordered lattice chains to detect if any incompatibilities are present between said source code entities.
3. Apparatus as claimed in claim 2, wherein a lattice top in an independent component of said library selector indicates an incompatibility.
4. Apparatus as claimed in claim 1, wherein said selected library of machine code entities contains at least two minor variants corresponding to at least one source code entity and said machine code entity generating logic selects between said at least two minor variants in dependence upon build option parameters associated with said at least one source code entity.
5. Apparatus as claimed in claim 1, wherein said source code entities are objects formed from one or more of:
C source code;
C++ source code; and
target data processor assembly language source code.
6. Apparatus as claimed in claim 1, wherein at least one said build option parameter include an instruction set identifier for a target data processing apparatus.
7. Apparatus as claimed in claim 1, wherein said at least one build option parameter include an identification of optional instruction processing hardware within a target data processing apparatus required by a source code entity.
8. Apparatus as claimed in claim 1, wherein said at least one build option parameter include one or more of:
whether a source code entity treats data words as big-endian or little-endian;
position independence of a source code entity;
whether a source code entity is stack checking or non-stack checking;
what memory system capabilities are required by a source code entity; and
what procedure call options are required for a source code entity.
9. Apparatus as claimed in claim 1, wherein those of said at least one build option parameters giving rise to greater demands upon an execution environment have associated advantages.
10. Apparatus as claimed in claim 1, wherein said library selector uses a list mechanism.
11. Apparatus as claimed in claim 1, wherein said limiting level of execution environment requirements is a minimum or maximum level of execution environment requirements.
12. Apparatus as claimed in claim 1, wherein said selected library has a greatest level of execution environment requirements that do not exceed those of the library selector.
13. A method of generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said method of generating comprising the steps of:
(i) in response to said at least one build option parameter of each source code entity, forming a library selector, wherein:
(a) build option parameters of each source code entity are combined in accordance with lattice theory whereby each build option parameter has a value indicative of position within a partially ordered lattice chain representing relative execution environment requirements for that build option parameter, and
(b) said library selector is formed with components corresponding to a limiting level of execution environment requirements among said group of source code entities;
(ii) in response to said library selector, selecting, from among a plurality of libraries of machine code entities, a selected library of machine code entities having a best level of execution environment requirements compatible with said limiting level of execution environment requirements indicated by said library selector; and
(iii) generating said group of machine code entities from machine code entities within said selected library of machine code entities in dependence upon said group of source code entities.
14. A method as claimed in claim 13, wherein said library selector uses a list mechanism.
15. A method as claimed in claim 13, wherein said limiting level of execution environment requirements is a minimum or maximum level of execution environment requirements.
16. A method as claimed in claim 13, wherein said selected library has a greatest level of execution environment requirements that do not exceed those of the library selector.
17. A computer readable medium storing a computer program for controlling a data processing apparatus to perform a method of generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said method of generating comprising the steps of:
(i) in response to said at least one build option parameter of each source code entity, forming a library selector, wherein:
(a) build option parameters of each source code entity are combined in accordance with lattice theory whereby each build option parameter has a value indicative of position within a partially ordered lattice chain representing relative execution environment requirements for that build option parameter, and
(b) said library selector is formed with components corresponding to a limiting level of execution environment requirements among said group of source code entities;
(ii) in response to said library selector, selecting, from among a plurality of libraries of machine code entities, a selected library of machine code entities having a best level of execution environment requirements compatible with said limiting level of execution environment requirements indicated by said library selector; and
(iii) generating said group of machine code entities from machine code entities within said selected library of machine code entities in dependence upon said group of source code entities.
18. A computer readable medium as claimed in claim 17, wherein said library selector uses a list mechanism.
19. A computer readable medium as claimed in claim 17, wherein said limiting level of execution environment requirements is a minimum or maximum level of execution environment requirements.
20. A computer readable medium as claimed in claim 17, wherein said selected library has a greatest level of execution environment requirements that do not exceed those of the library selector.
21. A method of forming a set of libraries of machine code entities for use in generating a group of machine code entities for execution upon a target data processing apparatus from a group of source code entities, each source code entity having at least one build option parameter, said method of forming comprising the steps of:
(i) associating a library selector with each library of machine code entities, wherein:
(a) supported build option parameters for each machine code entity within a library are combined in accordance with lattice theory whereby each build option parameter has a value indicative of position within a partially ordered lattice chain representing relative execution environment requirements for that build option parameter, and
(b) said library selector is formed with components corresponding to a limiting level of execution environment requirements needed by said library of machine code entities; and
(ii) determining from said library selector that at least one compatible library of machine code entities is present for each possible combination of build option parameters of said source code entities.
22. A method as claimed in claim 21, wherein said library selector uses a list mechanism.
23. A method as claimed in claim 21, wherein said limiting level of execution environment requirements is a minimum or maximum level of execution environment requirements.
24. A method as claimed in claim 21, wherein a selected library has a greatest level of execution environment requirements that do not exceed those of the library selector.
US10/378,658 2000-02-14 2003-03-05 Software object library selection Expired - Lifetime US7216332B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/378,658 US7216332B2 (en) 2000-02-14 2003-03-05 Software object library selection

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US50348500A 2000-02-14 2000-02-14
US10/378,658 US7216332B2 (en) 2000-02-14 2003-03-05 Software object library selection

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US50348500A Continuation-In-Part 2000-02-14 2000-02-14

Publications (2)

Publication Number Publication Date
US20030182650A1 US20030182650A1 (en) 2003-09-25
US7216332B2 true US7216332B2 (en) 2007-05-08

Family

ID=28042193

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/378,658 Expired - Lifetime US7216332B2 (en) 2000-02-14 2003-03-05 Software object library selection

Country Status (1)

Country Link
US (1) US7216332B2 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060004895A1 (en) * 2004-06-07 2006-01-05 Samsung Electronics Co., Ltd. Apparatus and method for creating a binary file for function-based data storage and a computer-readable storage medium for storing the method
US20080127057A1 (en) * 2006-09-01 2008-05-29 The Mathworks, Inc. Specifying implementations of code for code generation from a model
US20080184202A1 (en) * 2007-01-26 2008-07-31 Microsoft Corporation Extensible action sequences coordinating independently created components
US20090037933A1 (en) * 2007-08-02 2009-02-05 Shajith Chandran Method and apparatus for accessing a compatible library for an executable
US20100100249A1 (en) * 2008-10-17 2010-04-22 Vestas Wind Systems A/S Configuration of software for a wind turbine
US9158536B2 (en) 2012-12-06 2015-10-13 International Business Machines Corporation Program code library consolidation in an integrated development environment
US9569183B2 (en) 2015-02-25 2017-02-14 Red Hat, Inc. Contract based builder

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040205730A1 (en) * 2001-06-11 2004-10-14 Week Jon J. System and method for building libraries and groups of computer programs
US7412411B2 (en) * 2004-04-26 2008-08-12 Qualcomm Inc Methods and apparatus for gifting over a data network
US7962788B2 (en) * 2004-07-28 2011-06-14 Oracle International Corporation Automated treatment of system and application validation failures
US7536599B2 (en) * 2004-07-28 2009-05-19 Oracle International Corporation Methods and systems for validating a system environment
US7937455B2 (en) * 2004-07-28 2011-05-03 Oracle International Corporation Methods and systems for modifying nodes in a cluster environment
US7802228B2 (en) * 2004-08-19 2010-09-21 Microsoft Corporation Systems and methods for varying software build properties using primary and supplemental build files
US20070022028A1 (en) * 2005-07-21 2007-01-25 Caterpillar Inc. System design tool according to reusable asset specifications
US20070022126A1 (en) * 2005-07-21 2007-01-25 Caterpillar Inc. Method and apparatus for updating an asset catalog
US9342809B2 (en) * 2010-08-25 2016-05-17 International Business Machines Corporation Method and apparatus to populate asset variant relationships in repositories
US9619214B2 (en) 2014-08-13 2017-04-11 International Business Machines Corporation Compiler optimizations for vector instructions
US10169014B2 (en) 2014-12-19 2019-01-01 International Business Machines Corporation Compiler method for generating instructions for vector operations in a multi-endian instruction set
US9588746B2 (en) 2014-12-19 2017-03-07 International Business Machines Corporation Compiler method for generating instructions for vector operations on a multi-endian processor
US9880821B2 (en) 2015-08-17 2018-01-30 International Business Machines Corporation Compiler optimizations for vector operations that are reformatting-resistant
US9594668B1 (en) 2015-09-04 2017-03-14 International Business Machines Corporation Debugger display of vector register contents after compiler optimizations for vector instructions

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5307492A (en) * 1991-03-07 1994-04-26 Digital Equipment Corporation Mapping assembly language argument list references in translating code for different machine architectures
US5408665A (en) * 1993-04-30 1995-04-18 Borland International, Inc. System and methods for linking compiled code with extended dictionary support
US5583983A (en) * 1994-11-17 1996-12-10 Objectware, Inc. Multi-platform object-oriented software development and deployment system
US5854929A (en) * 1996-03-08 1998-12-29 Interuniversitair Micro-Elektronica Centrum (Imec Vzw) Method of generating code for programmable processors, code generator and application thereof
US5920723A (en) * 1997-02-05 1999-07-06 Hewlett-Packard Company Compiler with inter-modular procedure optimization
US5923882A (en) * 1995-08-29 1999-07-13 Silicon Graphics, Inc. Cross-module optimization for dynamically-shared programs and libraries
US6003095A (en) * 1996-10-31 1999-12-14 International Business Machines Corporation Apparatus and method for demand loading a dynamic link library
US6021272A (en) * 1995-10-04 2000-02-01 Platinum Technology, Inc. Transforming and manipulating program object code
US6202205B1 (en) * 1998-07-21 2001-03-13 Hewlett-Packard Company System and method for profile-based, on-the-fly optimization of library code
US6212673B1 (en) * 1997-03-31 2001-04-03 International Business Machines Corporation Component-neutral builder interface
US6370685B1 (en) * 1999-01-06 2002-04-09 Intel Corporation Data-flow method of analyzing definitions and uses of L values in programs
US20030070159A1 (en) * 2000-08-04 2003-04-10 Intrinsic Graphics, Inc. Object decription language
US6898788B2 (en) * 1998-10-30 2005-05-24 Segasoft, Inc. System for modifying the functionality of compiled computer code at run-time
US6961932B2 (en) * 2001-08-15 2005-11-01 Microsoft Corporation Semantics mapping between different object hierarchies

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5307492A (en) * 1991-03-07 1994-04-26 Digital Equipment Corporation Mapping assembly language argument list references in translating code for different machine architectures
US5408665A (en) * 1993-04-30 1995-04-18 Borland International, Inc. System and methods for linking compiled code with extended dictionary support
US5583983A (en) * 1994-11-17 1996-12-10 Objectware, Inc. Multi-platform object-oriented software development and deployment system
US5923882A (en) * 1995-08-29 1999-07-13 Silicon Graphics, Inc. Cross-module optimization for dynamically-shared programs and libraries
US6021272A (en) * 1995-10-04 2000-02-01 Platinum Technology, Inc. Transforming and manipulating program object code
US5854929A (en) * 1996-03-08 1998-12-29 Interuniversitair Micro-Elektronica Centrum (Imec Vzw) Method of generating code for programmable processors, code generator and application thereof
US6003095A (en) * 1996-10-31 1999-12-14 International Business Machines Corporation Apparatus and method for demand loading a dynamic link library
US5920723A (en) * 1997-02-05 1999-07-06 Hewlett-Packard Company Compiler with inter-modular procedure optimization
US6212673B1 (en) * 1997-03-31 2001-04-03 International Business Machines Corporation Component-neutral builder interface
US6202205B1 (en) * 1998-07-21 2001-03-13 Hewlett-Packard Company System and method for profile-based, on-the-fly optimization of library code
US6898788B2 (en) * 1998-10-30 2005-05-24 Segasoft, Inc. System for modifying the functionality of compiled computer code at run-time
US6370685B1 (en) * 1999-01-06 2002-04-09 Intel Corporation Data-flow method of analyzing definitions and uses of L values in programs
US20030070159A1 (en) * 2000-08-04 2003-04-10 Intrinsic Graphics, Inc. Object decription language
US6961932B2 (en) * 2001-08-15 2005-11-01 Microsoft Corporation Semantics mapping between different object hierarchies

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Johnson, et al, "Building an evolution transformation library", IEEE, pp. 238-248, 1990. *
Philip R. Banks, ARM Chip List, Oct. 1998, ARMLtd. *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060004895A1 (en) * 2004-06-07 2006-01-05 Samsung Electronics Co., Ltd. Apparatus and method for creating a binary file for function-based data storage and a computer-readable storage medium for storing the method
US20080127057A1 (en) * 2006-09-01 2008-05-29 The Mathworks, Inc. Specifying implementations of code for code generation from a model
US7900188B2 (en) * 2006-09-01 2011-03-01 The Mathworks, Inc. Specifying implementations of code for code generation from a model
US20080184202A1 (en) * 2007-01-26 2008-07-31 Microsoft Corporation Extensible action sequences coordinating independently created components
US7743076B2 (en) * 2007-01-26 2010-06-22 Microsoft Corporation Extensible action sequences coordinating independently created components
US20090037933A1 (en) * 2007-08-02 2009-02-05 Shajith Chandran Method and apparatus for accessing a compatible library for an executable
US8104049B2 (en) * 2007-08-02 2012-01-24 International Business Machines Corporation Accessing a compatible library for an executable
US20100100249A1 (en) * 2008-10-17 2010-04-22 Vestas Wind Systems A/S Configuration of software for a wind turbine
US9038058B2 (en) * 2008-10-17 2015-05-19 Vestas Wind Systems A/S Configuration of software for a wind turbine
US9158536B2 (en) 2012-12-06 2015-10-13 International Business Machines Corporation Program code library consolidation in an integrated development environment
US9569183B2 (en) 2015-02-25 2017-02-14 Red Hat, Inc. Contract based builder

Also Published As

Publication number Publication date
US20030182650A1 (en) 2003-09-25

Similar Documents

Publication Publication Date Title
US7216332B2 (en) Software object library selection
CN103069385B (en) System and method for dynamic load calculating based on figure
JP4950454B2 (en) Stack hierarchy for test automation
US8910117B2 (en) Customizing and performing policy in version control
US6334193B1 (en) Method and apparatus for implementing user-definable error handling processes
US8739190B2 (en) Determining an extension to use to process an input object to a call in a program
CA2037708C (en) General purpose compound apparatus for instruction-level parallel processors
US7127707B1 (en) Intellisense in project upgrade
EP2245532B1 (en) Method and apparatus for generating virtual software platform based on component model and validating software platform architecture using the platform
CN1224903C (en) Module-by-module verification
US9632916B2 (en) Method and apparatus to semantically connect independent build and test processes
US8850388B2 (en) Controlling application features
US20080127054A1 (en) Connecting with an application instance
US7797684B2 (en) Automatic failure analysis of code development options
US20100281463A1 (en) XML based scripting framework, and methods of providing automated interactions with remote systems
US20080127055A1 (en) Application proxy
CN112765023A (en) Test case generation method and device
JP2007304840A (en) Compilation method, debugging method, compilation program, and debugging program
US20230289187A1 (en) Method and apparatus for rectifying weak memory ordering problem
KR20030044916A (en) Modular computer system and related method
JP4975222B2 (en) Multilingual user interface for operating system
US7640421B1 (en) Method and system for determining context switch state
US8719778B2 (en) Interconnection interface for flexible online/offline deployment of an n-layered software application
US20080034349A1 (en) Incremental program modification based on usage data
US6922735B2 (en) Management of co-processor information by integrating non-program information with program information

Legal Events

Date Code Title Description
AS Assignment

Owner name: ARM LIMITED, UNITED KINGDOM

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SMITH, LEE D.;REEL/FRAME:014143/0330

Effective date: 20030325

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12