Abstract:
A system and method for providing a persistent function server is provided. A multi-processor environment uses an interface definition language (idl) file to describe a particular function, such as an “add” function. A compiler uses the idl file to generate source code for use in marshalling and de-marshalling data between a main processor and a support processor. A header file is also created that corresponds to the particular function. The main processor includes parameters in the header file and sends the header file to the support processor. For example, a main processor may include two numbers in an “add” header file and send the “add” header file to a support processor that is responsible for performing math functions. In addition, the persistent function server capability of the support processor is programmable such that the support processor may be assigned to execute unique and complex functions.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Technical Field  
         [0002]     The present invention relates in general to a system and method for providing a persistent function server. More particularly, the present invention relates to a system and method for providing a support processor that is persistently programmed to support a particular software application&#39;s requirements in a heterogeneous processor environment.  
         [0003]     2. Description of the Related Art  
         [0004]     Computer systems are becoming more and more complex. The computer industry typically doubles the performance of a computer system every 18 months (e.g. personal computer, PDA, gaming console). In order for the computer industry to accomplish this task, the semiconductor industry produces integrated circuits that double in performance every 18 months. A computer system uses integrated circuits for particular functions based upon the integrated circuits&#39; architecture. Two fundamental architectures are 1) microprocessor-based and 2) digital signal processor-based.  
         [0005]     An integrated circuit with a microprocessor-based architecture is typically used to handle control operations whereas an integrated circuit with a digital signal processor-based architecture is typically designed to handle signal-processing manipulations (i.e. mathematical operations). As technology evolves, the computer industry and the semiconductor industry realize the importance of using both architectures, or processor types, in a computer system design.  
         [0006]     Many computer systems use a multi-processor architecture in order to provide a substantial amount of processing power while attempting to support a wide range of software applications. For example, many computer systems use a math co-processor to perform particular functions, such as adding and subtracting two numbers. A challenge found, however is that these co-processors are hardwired to perform specific functions, regardless of what an application requires.  
         [0007]     In addition, these co-processors are designed to support a broad range of software applications. A challenge found with this approach, however, is that these processors do not perform unique, complex tasks. For example, if a software program wishes to add one million numbers, the software program individually adds the numbers together instead of performing parallel addition processing operations in order to minimize time. As computers begin incorporating a multi-processor type, or heterogeneous, computer architecture, a challenge found is customizing one of the processor types to perform unique and complex tasks in order to support another processor type.  
         [0008]     What is needed, therefore, is a system and method to provide a support processor in a heterogeneous processor environment that is persistently programmed based upon a software application&#39;s requirements.  
       SUMMARY  
       [0009]     It has been discovered that the aforementioned challenges are resolved by using an interface definition language (idl) file to dynamically describe functions and specify a processor type for executing each function&#39;s corresponding instruction. A compiler uses an idl file to generate source code for use in marshalling and de-marshalling data between a first processor type and a second processor type. A header file is created whereby the first processor type includes parameters in the header file, and sends the header file to the second processor type, which is assigned to perform the function. For example, a first processor type may include two numbers in an “add” header file and send the “add” header file to the second processor type, which is responsible for performing math functions.  
         [0010]     An application includes a plurality of instructions that correspond to particular functions (e.g. add, subtract, etc.) whereby each instruction is executed on a particular processor type that share a common memory area (e.g. a first processor type or a second processor type). The first processor type is a main processor and is responsible for executing the application. The second processor type is different than the first processor type, and supports the first processor type by executing particular instructions that are included in an application. For example, the application may include an instruction to add one million numbers together. In this example, the second processor type may be programmed to add one million numbers together using a parallel addition approach.  
         [0011]     Prior to execution, each of the application&#39;s instructions is compiled in a manner that is based upon which processor type is assigned to execute the instruction (e.g. first processor type or second processor type). Instructions that are compiled for the second processor type are sent to the second processor type, in which the second processor type makes persistently available for the application. Instruction identifiers are included in an interface definition language (idl) file for instructions that are sent to the second processor type.  
         [0012]     While executing the application, the first processor type identifies instructions in the application and accesses the instruction identifiers that are included in the idl file in order to determine whether the instructions are executed on either the first processor type or the second processor type. When the first processor type identifies an instruction to execute on the second processor type, the first processor type generates a message and sends the message to the second processor type. The message includes the instruction and may include a pointer. The pointer corresponds to a location in a shared memory that includes data for which the second processor type uses during instruction execution. For example, an instruction may correspond to adding one million numbers to each other and the pointer corresponds to the location at which the numbers are located. In one embodiment, instead of including a pointer, the message may include the data itself.  
         [0013]     The second processor type receives the message from the first processor type, uses the instruction to identify a corresponding function, and uses the pointer to locate and retrieve the data from the shared memory area. Using the retrieved data, the second processor type executes the function and stores the result in the shared memory area.  
         [0014]     In turn, the second processor type sends an acknowledgement that informs the first processor type that it is finished executing the instruction. In addition, the acknowledgement may include a shared memory location (e.g. a pointer) that corresponds to the location of the result of executing the instruction. The first processor type receives the acknowledgement and retrieves the result from the shared memory area for use in further processing.  
         [0015]     The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0016]     The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.  
         [0017]      FIG. 1  is a diagram showing a first processor type sending a message to a second processor type that is programmed to execute a particular instruction using shared memory;  
         [0018]      FIG. 2  is a diagram showing a first processor type sending a message that includes data to a second processor type that is programmed to execute a particular instruction;  
         [0019]      FIG. 3  is a flowchart showing steps taken in compiling code for a function based upon a corresponding processor type;  
         [0020]      FIG. 4  is a flowchart showing steps taken in sending a message to a second processor type to execute a function;  
         [0021]      FIG. 5  is a flowchart showing steps taken in receiving a message from a first processor type and executing a function on a second processor type;  
         [0022]      FIG. 6  is a diagram showing a processor element architecture that includes a plurality of heterogeneous processors;  
         [0023]      FIG. 7A  is a block diagram of an information handling system capable of implementing the present invention; and  
         [0024]      FIG. 7B  is a diagram showing a local storage area divided into private memory and non-private memory.  
     
    
     DETAILED DESCRIPTION  
       [0025]     The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention which is defined in the claims following the description.  
         [0026]      FIG. 1  is a diagram showing a first processor type sending a message to a second processor type that is programmed to execute a particular instruction using shared memory. An application includes a plurality of instructions that correspond to particular functions (e.g. add, subtract, etc.) whereby each instruction is executed on a particular processor type, such as processor type A  100  or processor type B  140 . Both processor type A  100  and processor type B  140  are able to access shared memory store  150 . Shared memory store  150  may be stored on a nonvolatile storage area, such as a computer hard drive.  
         [0027]     Processor type A  100  is a main processor and is responsible for executing application  105 . Processor type B  140  is a different processor type than processor type A  100  and supports processor type A  100  by executing particular instructions that are included in application  105 . For example, application  105  may have an instruction to add one million numbers together. In this example, processor type B  140  may be responsible for executing the particular instruction. Prior to execution, each function is compiled based upon which processor type its corresponding instruction will execute. Identifiers corresponding to instructions that should be executed on processor type B  140  are included in interface definition language (idl) file  110 .  
         [0028]     While executing application  105 , processor type A  100  identifies instructions in application  105  and uses interface definition language (idl) file  110  to determine whether the instructions should be executed on either processor type A  100  or processor type B  140 . When processor type A  100  identifies an instruction to execute on processor type B  140 , processor type A  100  generates message  120  and sends message  120  to processor type B  140 . Message  120  includes instruction  125  and pointer  130 . Instruction  125  corresponds to the particular instruction to execute. Pointer  130  corresponds to a location in shared memory  150  that includes data for which processor type B  140  uses during instruction execution. For example, an instruction may correspond to adding one million numbers to each other, whereby the pointer corresponds to the location at which the numbers are located.  
         [0029]     Processor type B  140  receives message  120 , and uses instruction  125  to identify a corresponding function, such as function  145 . Processor type B  140  uses pointer  130  to locate data  155  and retrieve it from shared memory store  150 . Using data  155 , processor type B  140  executes function  145  and stores the result (i.e. result  160 ) in shared memory store  150 .  
         [0030]     Processor type B  140  sends acknowledgement  170  to processor type A  100 , informing processor type A  100  that processor type B  140  is finished instruction execution. In addition, acknowledgement  170  includes a memory location corresponding to result  160 . Processor type A  100  receives acknowledgement  170  and retrieves result  160  from shared memory store  150 .  
         [0031]      FIG. 2  is a diagram showing a first processor type sending a message that includes data to a second processor type that is programmed to execute a particular instruction.  FIG. 2  is similar to  FIG. 1  with the exception that processor type A  100  sends data  155  directly to processor type B  140  instead of sending a pointer, such as that shown in  FIG. 1 . Processor type A  100 , processor type B  140 , and data  155  are the same as that shown in  FIG. 1 .  
         [0032]     Processor type B  140  receives message  200  and extracts data  155 . Using instruction  125 , processor type B  140  identifies function  145  and executes function  145  using data  155 . The result (i.e. result  160 ) is sent directly to processor type A  100 . Instruction  125 , function  145 , and result  160  are the same as that shown in  FIG. 1 .  
         [0033]      FIG. 3  is a flowchart showing steps taken in compiling code for functions based upon a corresponding processor type. An application includes a plurality of functions (e.g. add, subtract, etc.) whereby each of the functions is executed on a particular processor type, such as processor type A  100  or processor type B  140 . Prior to application execution, processing identifies a processor type for each function, and compiles the function to execute on the identified processor type. Processor type A  100  and processor type B  140  are the same as that shown in  FIG. 1 .  
         [0034]     Processing commences at  300 , whereupon processing retrieves a first instruction from code store  315  that is included in the application (step  310 ). A determination is made as to whether to compile the instruction&#39;s corresponding function for execution on processor type A  100  or processor type B  140  (decision  320 ). If the function should be compiled for processor type A  100 , decision  320  branches to “Yes” branch  322  whereupon processing compiles the function for processor type A  100  (step  330 ), and stores the compiled code on processor type A  100  at step  340 .  
         [0035]     On the other hand, if the function should be compiled for processor type B  140 , decision  320  branches to “No” branch  328  whereupon processing stores the location at which the function should be executed (e.g. processor type B  140 ) in idl file  110  (step  350 ) such that processor type A  100  is able to determine whether to execute the function itself or whether to send a message to processor type B  140  to execute the function (see  FIG. 4  and corresponding text for further details regarding function execution). Idl file  110  is the same as that shown in  FIG. 1 . Processing compiles the function for use on processor type B at step  360 , and stores the compiled code on processor type B  140  at step  370 .  
         [0036]     A determination is made as to whether there are more instructions to compile (decision  380 ). If there are more instructions to compile, decision  380  branches to “Yes” branch  382  which loops back to retrieve (step  390 ) and process the next instruction. This looping continues until there are no more instructions to process, at which point decision  380  branches to “No” branch  388  whereupon processing ends at  399 .  
         [0037]     In one embodiment, a particular processor type may execute particular types of functions. For example, if processor type A  100  is microprocessor-based and processor type B  140  is digital signal processor-based, processor type B  140  may execute a majority of mathematical type instructions that are included in an application.  
         [0038]      FIG. 4  is a flowchart showing steps taken in sending a message to a second processor type to execute an instruction. A first processor type, such as processor type A  100  shown in  FIG. 1 , initiates and executes an application. During application execution, particular instructions included in the application are executed on a second processor type, such as processor type B  140 . The first processor type sends messages to the second processor type, which instructs processor type B  140  to execute the instruction. Processor type B  140  is the same as that shown in  FIG. 1 .  
         [0039]     Processing commences at  400 , whereupon processing loads the application into memory store  425  and starts application execution (step  410 ). Memory store  425  may be stored on a volatile memory location, such as internal memory. At step  420 , processing retrieves a first instruction from memory store  425 . For example, the first instruction may add one million numbers together. At step  430 , processing looks-up the instruction in idl file  110  in order to identify which processor type to execute the function that corresponds to the particular instruction. A determination is made as to whether the instruction should be executed on processor type A  100  or processor type B  140  (decision  440 ). If the instruction should be executed on processor type A  100 , decision  440  branches to “Yes” branch  442  whereupon processor type A  100  executes the function at step  450 .  
         [0040]     On the other hand, if the instruction should be executed on processor type B  140 , decision  440  branches to “No” branch  448  whereupon processing creates message  120  at step  460 . In one embodiment, message  120  is an interface definition language (idl) header file. Message  120  is the same as that shown in  FIG. 1 .  
         [0041]     A determination is made as to whether to include a pointer in message  120  that corresponds to the instruction&#39;s data location or whether to include the data itself in message  120  (decision  470 ). For example, if the instruction is to add one million numbers together, processing may wish to send a pointer that corresponds to the location of the numbers as opposed to sending the numbers themselves to processor type B  140 . If processing should include a pointer in message  120 , decision  470  branches to “Yes” branch  472  whereupon processing loads the pointer in message  120  at step  475 . On the other hand, if processing should include the data in message  120 , decision  470  branches to “No” branch  478  whereupon processing loads the data in message  120  at step  480 . At step  485 , processing sends message  120  to processor type B  140 .  
         [0042]     A determination is made as to whether there are more instructions in the program to execute (decision  490 ). If there are more instructions to execute, decision  490  branches to “Yes” branch  492  which loops back to retrieve (step  495 ) and process the next instruction. This looping continues until there are no more instructions to execute, at which point decision  490  branches to “No” branch  498  whereupon processing ends at  499 .  
         [0043]      FIG. 5  is a flowchart showing steps taken in receiving a message from a first processor type and executing a function on a second processor type. The second processor type, such as processor type B  140  shown in  FIG. 1 , received compiled code that corresponds to particular functions. When the first processor type, such as processor type A  100  shown in  FIG. 1 , identifies an instruction to be executed on the second processor type, the first processor type sends a message to the second processor type to execute the function (see  FIG. 3  and corresponding text for further details regarding code compilation).  
         [0044]     Processing commences at  500 , whereupon processor type B  140  initializes at step  505 . Processor type B  140  loads functions from processor B store  515  at step  510 . For example, one of the functions may be a customized function to add one million numbers together. Processor B store  515  may be stored on a nonvolatile storage area, such as a computer hard drive.  
         [0045]     At step  520 , processor type B waits for a message from processor type A  100  to execute an instruction. When processor type B  140  receives a message, a determination is made as to whether the message includes a pointer corresponding to a data location or whether the message includes the data itself (decision  530 ). For example, if processor type B  140  should add one million numbers together, processor type A  100  may send a pointer that corresponds to the location of the numbers as opposed to including all one million numbers in the message (see  FIG. 4  and corresponding text for further details regarding the inclusion of a pointer in a message).  
         [0046]     If the message includes a pointer, decision  530  branches to “Yes” branch  532  whereupon processor type B  140  uses the pointer to retrieve data from shared memory store  150  (step  535 ). Shared memory store  150  is shared between processor type A  100  and processor type B  140  and is the same as that shown in  FIG. 1 . On the other hand, if the message includes the data itself, decision  530  branches to “No” branch  538  whereupon processor type B  140  extracts the data from the message at step  540 .  
         [0047]     At step  545 , processor type B  140  identifies a function in memory store  550  that corresponds to the instruction that is included in the message, and executes the function using the data (step  555 ). A determination is made as to whether to store the result of the function execution in shared memory (decision  560 ). For example, if processor type A  100  sent a pointer to processor type B, processor type B may wish to store the result in shared memory  150  and send a corresponding pointer back to processor type A  100 .  
         [0048]     If processor type B  140  should store the result in shared memory  150 , decision  560  branches to “Yes” branch  562  whereupon processing stores the result in shared memory  150  at step  565 . Processor type B  140  sends an acknowledgement to processor type A  100 , which includes the memory location (e.g. pointer) of the result. On the other hand, if processor type B  140  should send the result directly to processor type A  100 , processing branches to “No” branch  568  whereupon processor type B  140  sends the result to processor type A  100  at step  575 .  
         [0049]     A determination is made as to whether to continue processing (decision  580 ). If processing should continue, decision  580  branches to “Yes” branch  582  which loops back to process more messages. This looping continues until processing should stop, at which point decision  580  branches to “No” branch  588  whereupon processing ends at  590 .  
         [0050]      FIG. 6  is a diagram showing a processor element architecture that includes a plurality of heterogeneous processors. The heterogeneous processors share a common memory and a common bus. Processor element architecture (PEA)  600  sends and receives information to/from external devices through input output  670 , and distributes the information to control plane  610  and data plane  640  using processor element bus  660 . Control plane  610  manages PEA  600  and distributes work to data plane  640 .  
         [0051]     Control plane  610  includes processing unit  620  which runs operating system (OS)  625 . For example, processing unit  620  may be a Power PC core that is embedded in PEA  600  and OS  625  may be a Linux operating system. Processing unit  620  manages a common memory map table for PEA  600 . The memory map table corresponds to memory locations included in PEA  600 , such as L2 memory  630  as well as non-private memory included in data plane  640  (see  FIG. 7A, 7B , and corresponding text for further details regarding memory mapping).  
         [0052]     Data plane  640  includes Synergistic Processing Complex&#39;s (SPC)  645 ,  650 , and  655 . Each SPC is used to process data information and each SPC may have different instruction sets. For example, PEA  600  may be used in a wireless communications system and each SPC may be responsible for separate processing tasks, such as modulation, chip rate processing, encoding, and network interfacing. In another example, each SPC may have identical instruction sets and may be used in parallel to perform operations benefiting from parallel processes. Each SPC includes a synergistic processing unit (SPU) which is a processing core, such as a digital signal processor, a microcontroller, a microprocessor, or a combination of these cores.  
         [0053]     SPC  645 ,  650 , and  655  are connected to processor element bus  660  which passes information between control plane  610 , data plane  640 , and input/output  670 . Bus  660  is an on-chip coherent multi-processor bus that passes information between I/O  670 , control plane  610 , and data plane  640 . Input/output  670  includes flexible input-output logic which dynamically assigns interface pins to input output controllers based upon peripheral devices that are connected to PEA  600 . For example, PEA  600  may be connected to two peripheral devices, such as peripheral A and peripheral B, whereby each peripheral connects to a particular number of input and output pins on PEA  600 . In this example, the flexible input-output logic is configured to route PEA  600 &#39;s external input and output pins that are connected to peripheral A to a first input output controller (i.e. IOC A) and route PEA  600 &#39;s external input and output pins that are connected to peripheral B to a second input output controller (i.e. IOC B).  
         [0054]      FIG. 7A  illustrates an information handling system which is a simplified example of a computer system capable of performing the computing operations described herein. The example in  FIG. 7A  shows a plurality of heterogeneous processors using a common memory map in order to share memory between the heterogeneous processors. Device  700  includes processing unit  730  which executes an operating system for device  700 . Processing unit  730  is similar to processing unit  620  shown in  FIG. 6 . Processing unit  730  uses system memory map  720  to allocate memory space throughout device  700 . For example, processing unit  730  uses system memory map  720  to identify and allocate memory areas when processing unit  730  receives a memory request. Processing unit  730  access L2 memory  725  for retrieving application and data information. L2 memory  725  is similar to L2 memory  630  shown in  FIG. 6 .  
         [0055]     System memory map  720  separates memory mapping areas into regions which are regions  735 ,  745 ,  750 ,  755 , and  760 . Region  735  is a mapping region for external system memory which may be controlled by a separate input output device. Region  745  is a mapping region for non-private storage locations corresponding to one or more synergistic processing complexes, such as SPC  702 . SPC  702  is similar to the SPC&#39;s shown in  FIG. 6 , such as SPC A  645 . SPC  702  includes local memory, such as local store  710 , whereby portions of the local memory may be allocated to the overall system memory for other processors to access. For example, 1 MB of local store  710  may be allocated to non-private storage whereby it becomes accessible by other heterogeneous processors. In this example, local storage aliases  745  manages the 1 MB of nonprivate storage located in local store  710 .  
         [0056]     Region  750  is a mapping region for translation lookaside buffer&#39;s (TLB&#39;s) and memory flow control (MFC registers. A translation lookaside buffer includes cross-references between virtual address and real addresses of recently referenced pages of memory. The memory flow control provides interface functions between the processor and the bus such as DMA control and synchronization.  
         [0057]     Region  755  is a mapping region for the operating system and is pinned system memory with bandwidth and latency guarantees. Region  760  is a mapping region for input output devices that are external to device  700  and are defined by system and input output architectures.  
         [0058]     Synergistic processing complex (SPC)  702  includes synergistic processing unit (SPU)  705 , local store  710 , and memory management unit (MMU)  715 . Processing unit  730  manages SPU  705  and processes data in response to processing unit  730 &#39;s direction. For example SPU  705  may be a digital signaling processing core, a microprocessor core, a micro controller core, or a combination of these cores. Local store  710  is a storage area that SPU  705  configures for a private storage area and a non-private storage area. For example, if SPU  705  requires a substantial amount of local memory, SPU  705  may allocate 100% of local store  710  to private memory. In another example, if SPU  705  requires a minimal amount of local memory, SPU  705  may allocate 10% of local store  710  to private memory and allocate the remaining 90% of local store  710  to non-private memory (see  FIG. 7B  and corresponding text for further details regarding local store configuration).  
         [0059]     The portions of local store  710  that are allocated to non-private memory are managed by system memory map  720  in region  745 . These non-private memory regions may be accessed by other SPU&#39;s or by processing unit  730 . MMU  715  includes a direct memory access (DMA) function and passes information from local store  710  to other memory locations within device  700 .  
         [0060]      FIG. 7B  is a diagram showing a local storage area divided into private memory and non-private memory. During system boot, synergistic processing unit (SPU)  760  partitions local store  770  into two regions which are private store  775  and non-private store  780 . SPU  760  is similar to SPU  705  and local store  770  is similar to local store  710  that are shown in  FIG. 7A . Private store  775  is accessible by SPU  760  whereas non-private store  780  is accessible by SPU  760  as well as other processing units within a particular device. SPU  760  uses private store  775  for fast access to data. For example, SPU  760  may be responsible for complex computations that require SPU  760  to quickly access extensive amounts of data that is stored in memory. In this example, SPU  760  may allocate 100% of local store  770  to private store  775  in order to ensure that SPU  760  has enough local memory to access. In another example, SPU  760  may not require a large amount of local memory and therefore, may allocate 10% of local store  770  to private store  775  and allocate the remaining 90% of local store  770  to non-private store  780 .  
         [0061]     A system memory mapping region, such as local storage aliases  790 , manages portions of local store  770  that are allocated to non-private storage. Local storage aliases  790  is similar to local storage aliases  745  that is shown in  FIG. 7A . Local storage aliases  790  manages non-private storage for each SPU and allows other SPU&#39;s to access the non-private storage as well as a device&#39;s control processing unit.  
         [0062]     While the computer system described in  FIGS. 6, 7A , and  7 B are capable of executing the processes described herein, this computer system is simply one example of a computer system. Those skilled in the art will appreciate that many other computer system designs are capable of performing the processes described herein.  
         [0063]     One of the preferred implementations of the invention is an application, namely, a set of instructions (program code) in a code module which may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, on a hard disk drive, or in removable storage such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.  
         [0064]     While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For a non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.