Execution of complex recursive algorithms

This application discloses tools and mechanisms to convert a program from a sequentially-executable format into a parallel-executable format, and then modify the program in the parallel-executable format to either allow compilation for parallel execution or to speed-up the parallel execution by an accelerated processing unit. The tools and mechanisms can identify various features of the program, such as recursive calls, search loops, inline function calls, uncompressed data structures, memory utilization, and inter-dependent kernel instances. The tools and mechanisms can modify the program to replace or otherwise augment the identified features, which can allow the modified program to be compiled for parallel execution, or speed-up the parallel execution by an accelerated processing unit.

TECHNICAL FIELD

This application is generally related to execution of complex recursive algorithms, more specifically, to static analysis of electronic designs utilizing complex recursive algorithms.

BACKGROUND

Schedulability analysis for electronic designs has become increasingly important, especially when dealing with large complex multi-protocol network designs and verification. One specific type of schedulabilty analysis within the domain of Real-Time science determines a worst-case latency of packetized communication through a communication bus described in the electronic designs. Computing systems often employ dedicated and often very complex worst-case latency calculation algorithms, such as a Trajectory Approach algorithm, to determine a worst-case latency metric for an electronic design.

Practical usability of the Trajectory Approach, however, has been seriously limited when applied to sizable real-life systems, as the execution time of this type of worst-case latency calculation algorithm increases dramatically, often exponentially, with expanding state-space. This exponential increase of the execution time is often caused by the fact that the worst-case latency calculation algorithms take into consideration all blocking factors and then utilize the results recursively for calculations, e.g., such as end-to-end worst-case latency or the like.

There are less computation-intensive or “fast” algorithms, such as Network Calculus algorithm, which can provide a worst-case latency metric for sizable real-life systems. This resulting worst-case latency metric, however, is often overly pessimistic, causing designers to relax timing requirements of their electronic designs and inefficiently utilize available bandwidth. Thus, when tasked with identifying a worst-case latency metric in a sizable real-life system, designers have to trade-off speed and accuracy. As an example, the Trajectory Approach algorithm can give 50% less pessimistic results compared to Network Calculus algorithm, but the execution time using conventional computational methods can be prohibitive.

SUMMARY

This application discloses tools and mechanisms for improving execution time of complex recursive algorithms, for example, found in worst-case latency calculation algorithms, which can provide less pessimistic results of worst-case latency in an electronic system design without exponential execution delay. According to various embodiments, the tools and mechanisms can modify complex recursive algorithms into iterative parallel structures, which can be processed in parallel, for example, with an Accelerated Processing Units (APU), or the like.

In some embodiments, the tools and mechanisms to convert a program from a sequentially-executable format into a parallel-executable format, and then modify the program having the parallel-executable format to either allow compilation for parallel execution or to speed-up the parallel execution by the APU. The tools and mechanisms can identify various features of the program, such as recursive calls, search loops, inline function calls, uncompressed data structures, memory utilization, and inter-dependent kernel instances. The tools and mechanisms can modify the program to replace or otherwise augment the identified features, which can allow the modified program to be compiled for parallel execution, or speed-up the parallel execution by the APU. Embodiments will be described below in greater detail.

DETAILED DESCRIPTION

Illustrative Operating Environment

Various examples of the invention may be implemented through the execution of software instructions by a computing device101, such as a programmable computer. Accordingly,FIG. 1shows an illustrative example of a computing device101. As seen in this figure, the computing device101includes a computing unit103with a processing unit105and a system memory107. The processing unit105may be any type of programmable electronic device for executing software instructions, but will conventionally be a microprocessor. The system memory107may include both a read-only memory (ROM)109and a random access memory (RAM)111. As will be appreciated by those of ordinary skill in the art, both the read-only memory (ROM)109and the random access memory (RAM)111may store software instructions for execution by the processing unit105.

The processing unit105and the system memory107are connected, either directly or indirectly, through a bus113or alternate communication structure, to one or more peripheral devices117-123. For example, the processing unit105or the system memory107may be directly or indirectly connected to one or more additional memory storage devices, such as a hard disk drive117, which can be magnetic and/or removable, a removable optical disk drive119, and/or a flash memory card. The processing unit105and the system memory107also may be directly or indirectly connected to one or more input devices121and one or more output devices123. The input devices121may include, for example, a keyboard, a pointing device (such as a mouse, touchpad, stylus, trackball, or joystick), a scanner, a camera, and a microphone. The output devices123may include, for example, a monitor display, a printer and speakers. With various examples of the computing device101, one or more of the peripheral devices117-123may be internally housed with the computing unit103. Alternately, one or more of the peripheral devices117-123may be external to the housing for the computing unit103and connected to the bus113through, for example, a Universal Serial Bus (USB) connection.

With some implementations, the computing unit103may be directly or indirectly connected to a network interface115for communicating with other devices making up a network. The network interface115can translate data and control signals from the computing unit103into network messages according to one or more communication protocols, such as the transmission control protocol (TCP) and the Internet protocol (IP). Also, the network interface115may employ any suitable connection agent (or combination of agents) for connecting to a network, including, for example, a wireless transceiver, a modem, or an Ethernet connection. Such network interfaces and protocols are well known in the art, and thus will not be discussed here in more detail.

It should be appreciated that the computing device101is illustrated as an example only, and it not intended to be limiting. Various embodiments of the invention may be implemented using one or more computing devices that include the components of the computing device101illustrated inFIG. 1, which include only a subset of the components illustrated inFIG. 1, or which include an alternate combination of components, including components that are not shown inFIG. 1. For example, various embodiments of the invention may be implemented using a multi-processor computer, a plurality of single and/or multiprocessor computers arranged into a network, or some combination of both.

With some implementations of the invention, the processor unit105can have more than one processor core. Accordingly,FIG. 2illustrates an example of a multi-core processor unit105that may be employed with various embodiments of the invention. As seen in this figure, the processor unit105includes a plurality of processor cores201A and201B. Each processor core201A and201B includes a computing engine203A and203B, respectively, and a memory cache205A and205B, respectively. As known to those of ordinary skill in the art, a computing engine203A and203B can include logic devices for performing various computing functions, such as fetching software instructions and then performing the actions specified in the fetched instructions. These actions may include, for example, adding, subtracting, multiplying, and comparing numbers, performing logical operations such as AND, OR, NOR and XOR, and retrieving data. Each computing engine203A and203B may then use its corresponding memory cache205A and205B, respectively, to quickly store and retrieve data and/or instructions for execution.

Each processor core201A and201B is connected to an interconnect207. The particular construction of the interconnect207may vary depending upon the architecture of the processor unit105. With some processor cores201A and201B, such as the Cell microprocessor created by Sony Corporation, Toshiba Corporation and IBM Corporation, the interconnect207may be implemented as an interconnect bus. With other processor units201A and201B, however, such as the Opteron™ and Athlon™ dual-core processors available from Advanced Micro Devices of Sunnyvale, Calif., the interconnect207may be implemented as a system request interface device. In any case, the processor cores201A and201B communicate through the interconnect207with an input/output interface209and a memory controller210. The input/output interface209provides a communication interface between the processor unit105and the bus113. Similarly, the memory controller210controls the exchange of information between the processor unit105and the system memory107. With some implementations of the invention, the processor unit105may include additional components, such as a high-level cache memory accessible shared by the processor cores201A and201B. It also should be appreciated that the description of the computer network illustrated inFIG. 1andFIG. 2is provided as an example only, and it not intended to suggest any limitation as to the scope of use or functionality of alternate embodiments of the invention.

Sequential-to-Parallel Conversion Tool

FIG. 3illustrates an example sequential-to-parallel conversion tool300according to various examples of the invention. Referring toFIG. 3, the sequential-to-parallel conversion tool300can be implemented by a computing system, which, in some embodiments, can include the computing device101described inFIGS. 1 and 2. The sequential-to-parallel conversion tool300can receive a sequential program301having a sequential-executable format. The sequential program301can be written in a C or C++ programming language, or the like. In some embodiments, the sequential program can correspond to a worst-case latency calculation algorithm capable of determining a worst-case latency metric for an electronic design.

The sequential-to-parallel conversion tool300can convert the sequential program301into a parallel program302. The sequential program301can include a parallel model unit310to convert the sequential program301from a sequentially-executable format into a parallel-executable format. For example, the parallel model unit310can convert sequential constructs in the sequential program301to parallel operations based on at least one parallel programming model, such as Compute Unified Device Architecture (CUDA), Open Computing Language (OpenCL), Open Accelerators (OpenACC), Open Multi-Processing (OpenMP), or the like. CUDA describes a parallel computing platform and application programming interface (API) model, which can allow software developers to use a graphics processing unit (GPU) for general purpose processing, also known as a general-purpose graphics processing unit (GPGPU). OpenCL describes a framework for programs capable of execution across heterogeneous platforms, for example, including central processing units (CPUs), GPUs, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), other processors or hardware accelerators, or the like. OpenACC describes a programming standard for parallel computing, which, for example, can define annotations capable of being made to portions of program source code. These annotations can mark those portions of the program capable of being accelerated, for example, via compiler directives, additional functions or the like. OpenMP describes an application programming interface (API) to support multi-platform shared-memory multi-processing programming on a variety of computing platforms, processor architectures, and operating systems. The OpenMP APIs can include a set of compiler directives, library routines, and environment variables that can influence run-time behavior.

The parallel-executable program, which conforms to the parallel programming model, can be compiled and executed by parallel computing platforms or system. For example, Accelerated Processing Units (APUs) are one type of parallel computing platform or system that may be able to execute the parallel-executable program. In some embodiments, a low-cost graphical card built around a graphical processing unit (GPU), which is a type of APU, includes multiple processing units, each capable of executing several tasks in a parallel manner working on many sets of data (SIMD) simultaneously. Since APUs can have limited instruction sets and a different memory architecture compared to those supported by mainstream CPU platforms, the sequential-to-parallel conversion tool300can include an execution performance unit320to identify certain portions of the parallel-executable program, such as program structures, functions, calls, or other constructs, which could inhibit or slow down execution on the APU or GPU, and also modify the parallel-executable program based on the identified portions for execution on an APU or GPU. The sequential-to-parallel conversion tool300can output the modified parallel-executable program as the parallel program302, which can be compiled and executed by the APU or GPU. Embodiments of modification of the parallel-executable program will be described below in greater detail, after a description of a parallel computing environment inFIGS. 4A and 4B.

FIG. 4Aillustrates an example parallel computing memory model400according to various examples of the invention. Referring toFIG. 4A, the parallel computing memory model400can describe an abstract model of a memory architecture, which can map to hardware once a specific parallel computing system has been selected for implementation. In some embodiments, the parallel computing memory model400can describe an OpenCL memory model hierarchy.

The parallel computing memory model400can include a computing device410having multiple computing units413-1to413-M. In some embodiments, each of the computing units413-1to413-M can include a plurality of processors or processing units (not shown) that can work independently or together to execute operations in work items414-1to414-X and415-1to415-Y. In some embodiments, a kernel can run on work item having a collection of parallel executions, for example, invoked by a command, which can be executed by one or more processing units as part of a work-group executing on one of the computing units413-1to413-M. The work group can include a collection of related work-items414-1to414-X and415-1to415-Y that execute on the computing unit413-1to413-M.

The parallel computing memory model400can include a variety of memories available for the computing units413-1to413-M, such as a global memory421, a memory cache411, local memory412-1to412-M, and private memory416-1to416-X and417-1to417-Y. The global memory421, located in a computing device memory420external to the computing device410, can be available to all of the computing units413-1to413-M. The global memory421is typically the largest by capacity of the various memories in the parallel computing memory model400, but practically-speaking also provides the slowest memory access to the computing units413-1to413-M. The keyword_global can be added to a pointer declaration, which identifies data stored in the global memory421.

The memory cache411can interface with the global memory421and the computing units413-1to413-M to cache data accessed from the global memory421. The memory cache411also can include a constant memory, for example a read-only section of memory, accessible to all of the computing units413-1to413-M. In some embodiments, any element of constant memory can be simultaneously accessible by the work items414-1to414-X and415-1to415-Y in the computing units413-1to413-M. Data declarations qualified by the keyword_constant can identify data stored in constant memory. Each local memory412-1to412-M corresponds to different computing units413-1to413-M to enable coalesced accesses to share data between work items414-1to414-X and415-1to415-Y in a work group. Data declarations qualified by the keyword_local can identify data stored in local memory. Each private memory416-1to416-X and417-1to417-Y can correspond to different work items414-1to414-X and415-1to415-Y. The private memory416-1to416-X and417-1to417-Y can be the fastest memory parallel computing memory model400. In some embodiments, the private memory416-1to416-X and417-1to417-Y can be implemented on-chip in registers. Data declarations qualified by the keyword_private can identify data stored in private memory.

FIG. 4Billustrates an example accelerated processing unit450according to various examples of the invention. Referring toFIG. 4B, the accelerated processing unit450includes an array of processing devices460-1to460-N capable of processing threads or work items in parallel. Each of the processing devices include a processing unit, such as processing unit462shown in processing device460-1, a local memory, such as local memory461shown in processing device460-1, a fetch unit, such as fetch unit463shown in processing device460-1, and a local cache, such as local cache464shown in processing device460-1. In some embodiments, the processing units462can include a single-instruction, multiple data (SIMD) engine or processor, which can correspond to a class of parallel computers in Flynn's taxonomy.

The accelerated processing unit450can include control circuitry, such as a command processor452, a thread generator453, and a dispatch processor454, which can receive commands and instructions from a memory controller451. The control circuitry can direct the processing devices460-1to461-N to perform operations based on the commands and the instructions. In some embodiments, the command processor452can decode the commands received from the memory controller451, for example, which can be in the form of high-level application programming interface (API) commands. The command processor452also can maintain states of the accelerated processing unit450. The thread generator453can receive the decoded commands from the command processor452and map the decoded commands to different processing pipelines or threads associated with the processing devices460-1to460-N in the accelerated processing unit450. The dispatch processor454can receive instructions from the memory controller451and the decoded and mapped commands from the thread generator453. The dispatch processor454can direct the processing devices460-1to461-N to perform operations based on the mapped commands and the instructions.

The accelerated processing unit450can include various memories, such as a global memory455and a local memory456, which can accessible by the processing devices460-1to460-N. In some embodiments, the memory controller451can control the operations of the global memory455and the local memory456. The accelerated processing unit450also can include a memory export buffer457to receive data processed by the processing devices460-1to460-N, which can be provided to the memory controller451. The memory controller451, in some embodiments, can output the processed data or can direct the processed data to be stored back to the global memory455or the local memory456.

Referring back toFIG. 3, the execution performance unit320can include a recursion unit321to unroll recursive portions of the parallel-executable program from the parallel model unit310. Recursion portions of a source code can be utilized to perform a complex task, for example, by breaking the complex tasks into the several subtasks and implemented by calling itself to solve subtasks. During a recursive call, values of local fields can be placed on a memory area called stack memory until completion of the subtask performed in response to the recursive call.

Since some processing units, such as those utilized in APUs, or vector processors, such as those in general-purpose graphical processing units (GPGPUs), do not support recursive calls, when the parallel-executable program includes recursive portions, an error would be received during compilation. Further, these processing units and vector processor often do not have a stack memory capable of storing values of local fields until completion of the subtask performed in response to the recursive calls.

The recursion unit321can identify recursive portions of the parallel-executable program and replace them with conditional loops. In some embodiments, the recursion unit321can identify recursive portions of the parallel-executable program by locating a recursive call in the parallel-executable program. The sequential-to-parallel conversion tool300can include an interface unit330, which can present any located recursive calls in a display presentation304. In some embodiments, the recursion unit321can replace the identified recursive portions of the parallel-executable program with conditional loops automatically or based on user input303received by the interface unit330.

An example of a recursive portion of parallel-executable program is shown below.

While an example of a conditional loop replacing the recursive portion of the parallel-executable program is shown below.

Since conditional loops can be compiled for execution in parallel by processing units and vector processors, the parallel-executable program having its recursive portions replaced with the conditional loops can be both compiled and executed on an APU or a GPGPU.

The execution performance unit320can include a stack unit322to reduce consumption of a stack memory by the parallel program302during execution. In some embodiments, utilization of the stack memory can slow or stop execution of the parallel program302. The tack unit322to reduce consumption of the stack memory in a variety of ways, including performing inline expansion of functional calls, reducing a number of local variables, a number and/or size of function parameters, or the like.

The stack unit322can identify functional the parallel-executable program and replace them with a copy of the function the identified functional calls reference, called inline expansion. In some embodiments, the stack unit322can mark or annotate the identified functional calls with a compiler directive. The compiler of the parallel program302can, in response to the compiler directive in the parallel program302, perform the inline expansion during compilation. The interface unit330can present any located functional calls in a display presentation304. In some embodiments, the stack unit322can perform the inline expansion or marking with a compiler directive automatically or based on user input303received by the interface unit330.

The stack unit322also can identify functions the parallel-executable program having function parameters or local variables, and replace the local variables or function parameters with one or more pointers to the function parameters or local variables. During execution of the parallel program302, the stack memory can store the one or more pointers to the function parameters or local variables rather than the function parameters or local variables themselves, which can reduce consumption of the stack memory.

An example of a function having function parameters is shown below.

The function foo can have function parameters long id and long array[ ]. These function parameters, during execution, could be stored on a stack memory of a processing unit of an APU.

An example code defining a pointer to the function parameters and the function with its function parameters replaced by the pointer is shown below.

The execution performance unit320can include a memory utilization unit323to analyze the parallel-executable program to store variables in a memory from the parallel computing memory model based on memory size and latency. In some embodiments, frequently accessed variables can be cached in a private memory of a processing unit, such as registers in the processing unit. For example, when a processing unit intends to frequently access a global variable, the parallel-executable program can be modified to store the global variable as a private variable in a private memory of the processing unit. The processing unit can utilize the private variable via quick access via the private memory, and then update the global variable with the value of the private variable upon completion of its utilization by the processing unit. The memory utilization unit323also can analyze the parallel-executable program to utilize local memory associated with the parallel computing memory model for random memory access.

The memory utilization unit323can identify portions of the parallel-executable program capable of utilizing a faster memory in the parallel computing memory model, and can modify the parallel-executable program to allow variables or other data to utilize the faster memory. The interface unit330, in some embodiments, can present the parallel-executable program capable of utilizing a faster memory in a display presentation304. In some embodiments, the memory utilization unit323can modify the parallel-executable program to allow variables or other data to utilize the faster memory automatically or based on user input303received by the interface unit330.

The execution performance unit320can include a search loop unit324to unroll search loops in the parallel-executable program from the parallel model unit310. In some examples, a search loop, when executed, can iteratively and often sequentially check an array of values to find a value that matches a particular identifier.

The search loop unit324can identify search loops in the parallel-executable program and replace the search loops with a vector storing locations of identifiers in the array, which are indexable by the identifier. For example, when an identifier having a value of 20 is located in a position or field having a value of 5 in an array, the vector can store the value 5 in its position or field 20. Thus, the processing unit executing the parallel program can determine where the identifier in the array is located by looking up the value in the vector at the position corresponding to the value of the identifier.

The interface unit330, in some embodiments, can present any search loops in a display presentation304. The search loop unit324can replace the identified search loops in the parallel-executable program with array indexing vectors automatically or based on user input303received by the interface unit330.

An example of a search loop is shown below.

In this portion code, the search loop can prompt the processing unit to sequentially compare each position or field in an array with an identifier id to determine whether the value in the position or field matches the identifier.

An example of a vector indexing an array is shown below.

This portion of code describes a vector that, when indexed by the identifier, can provide a location or position in the array having a value that matches a value of the identifier.

The execution performance unit320can include a kernel unit325to divide tasks performed by a kernel in such a way as to control accesses to shared data structures. When multiple parallel processed kernel instances share data structures or rely on each other's resulting processing, one of the kernel instances may have to cease operations to wait for a different kernel instance to finish utilizing the shared data structure or complete its results and synchronize with the other kernel instance. The kernel unit325can identify synchronization points in kernel code, identify independent groups of data a shared data structure, and identify portions of the parallel-executable program capable of execution independently from each other.

The kernel unit325can identify synchronization points for a kernel in the parallel-executable program. The kernel, when executed by an accelerated processing unit, has multiple instances that share data structures with each other and synchronize at the synchronization points. The kernel unit325can modify the kernel to allow the instances to execute independently and without synchronization due to the shared data structures.

An example of a matrices multiplication function is shown below.

In this example, the kernel unit325could break apart the matrices multiplication function, for example, by dividing out two loops and allowing parallel execution of the matrices multiplication function using multiple work items processing independent parts of the matrices.

The interface unit330, in some embodiments, can present those portions of the parallel-executable program corresponding to the synchronization points, those portions of the parallel-executable program capable of execution independently from each other, and possibly corresponding independent groups of data a shared data structure identified by the kernel unit325, in a display presentation304. In some embodiments, the kernel unit325could break apart the identified portions of the parallel-executable program capable of execution independently from each other automatically or based on user input303received by the interface unit330.

The execution performance unit320can include a data compression unit326to identify a multi-dimensional data array or vector that include empty fields or duplicated data. The data compression unit326can compress the multi-dimensional data array or vector, for example, by removing the empty fields or duplicated data. In some embodiments, the data compression unit326can modify an indexing algorithm or look-up code utilized to access the compressed multi-dimensional data array to avoid at least of one cache misses or memory bank conflicts.

An example of a multi-dimensional data array or vector representing a port where two paths cross each other is shown below.

An example of a compressed multi-dimensional data array or vector representing the port where two paths cross each other is shown below.

The compressed matrix can have a Compression Ratio corresponding to 1−(0.5+matrix dimension/matrix size)*100 [%]. In this example, the matrix is two-dimensional and matrix size is 16 (or 4-by-4), so the Compression Ratio is 37.5% or 6/16. The compression of the multi-dimensional data array or vector can consume fewer processing and memory resources as well as provide a quicker load time during execution of the parallel program.

The interface unit330, in some embodiments, can present multi-dimensional data array or vector that include empty fields or duplicated data in a display presentation304. In some embodiments, the data compression unit326can compress the multi-dimensional data array or vector and modify the indexing algorithm or look-up code automatically or based on user input303received by the interface unit330.

FIG. 5illustrates an example flowchart for sequential-to-parallel conversion of a program with execution performance modifications according to various embodiments of the invention. Referring toFIG. 5, in a block501, a computing system can convert a program from a sequentially-executable format into a parallel-executable format. For example, the computing system can convert sequential constructs in the program to parallel operations based on at least one parallel programming model, such as Compute Unified Device Architecture (CUDA), Open Computing Language (OpenCL), Open Accelerators (OpenACC), Open Multi-Processing (OpenMP), or the like.

In a block502, the computing system can select at least one execution performance modification to analyze for the program in the parallel-executable format. As discussed above, the computing system can select from a variety of execution performance modifications, such as unrolling recursion, modification of stack memory utilizations, memory allocation, unrolling search loops, optimizing kernel synchronization, and compressing data structures. In some embodiments, the computing system can select these execution performance modifications alone or in any combination, and do so automatically or in response to user input.

In a block503, the computing system can identify portions of the program in the parallel-executable format corresponding to the selected execution performance modification. Based on the selected execution performance modification(s), the computing system can scan, parse, or otherwise analyze the program in the parallel-executable format to identify portions of the code that may be capable of being modified to alter execution performance.

In a block504, the computing system can optionally present the identified portions of the program in a display presentation. This optional operation can allow user-visibility into execution performance modification. In some embodiments, the display presentation can include the identified portions of the code, an identification of the selected execution performance modification, and/or a proposed modification to the identified portion of the code. The display presentation can be interactive, for example, the computing system can update the display presentation based on user input. For example, the computing system can receive user input that modifies the identified portions of code, modifies the proposed modification to the identified portion of the code, authorizes an automatic modification of the identified portion of the code, elects to pass on performing automatic modification of the identified portion of the code, de-selects the execution performance modification, or the like.

In a block505, the computing system can modify the identified portions of the program to effect execution performance. The modifications to the identified portions of the program can vary depending on which execution performance modification was selected in the block502, and were discussed above in detail.

In a block506, the computing system can determine whether there is an additional execution performance modification to select. When additional execution performance modification can be selected, execution returns to block502, where at least another execution performance modification can be selected for analysis by the computing system. When no additional execution performance modification will be selected, execution can proceed to a block507, where the computing system can output the modified program as a parallel program capable of execution by an accelerated processing unit.

The system and apparatus described above may use dedicated processor systems, micro controllers, programmable logic devices, microprocessors, or any combination thereof, to perform some or all of the operations described herein. Some of the operations described above may be implemented in software and other operations may be implemented in hardware. Any of the operations, processes, and/or methods described herein may be performed by an apparatus, a device, and/or a system substantially similar to those as described herein and with reference to the illustrated figures.

The processing device may execute instructions or “code” stored in memory. The memory may store data as well. The processing device may include, but may not be limited to, an analog processor, a digital processor, a microprocessor, a multi-core processor, a processor array, a network processor, or the like. The processing device may be part of an integrated control system or system manager, or may be provided as a portable electronic device configured to interface with a networked system either locally or remotely via wireless transmission.

The processor memory may be integrated together with the processing device, for example RAM or FLASH memory disposed within an integrated circuit microprocessor or the like. In other examples, the memory may comprise an independent device, such as an external disk drive, a storage array, a portable FLASH key fob, or the like. The memory and processing device may be operatively coupled together, or in communication with each other, for example by an I/O port, a network connection, or the like, and the processing device may read a file stored on the memory. Associated memory may be “read only” by design (ROM) by virtue of permission settings, or not. Other examples of memory may include, but may not be limited to, WORM, EPROM, EEPROM, FLASH, or the like, which may be implemented in solid state semiconductor devices. Other memories may comprise moving parts, such as a known rotating disk drive. All such memories may be “machine-readable” and may be readable by a processing device.

Operating instructions or commands may be implemented or embodied in tangible forms of stored computer software (also known as “computer program” or “code”). Programs, or code, may be stored in a digital memory and may be read by the processing device. “Computer-readable storage medium” (or alternatively, “machine-readable storage medium”) may include all of the foregoing types of memory, as well as new technologies of the future, as long as the memory may be capable of storing digital information in the nature of a computer program or other data, at least temporarily, and as long at the stored information may be “read” by an appropriate processing device. The term “computer-readable” may not be limited to the historical usage of “computer” to imply a complete mainframe, mini-computer, desktop or even laptop computer. Rather, “computer-readable” may comprise storage medium that may be readable by a processor, a processing device, or any computing system. Such media may be any available media that may be locally and/or remotely accessible by a computer or a processor, and may include volatile and non-volatile media, and removable and non-removable media, or any combination thereof.

A program stored in a computer-readable storage medium may comprise a computer program product. For example, a storage medium may be used as a convenient means to store or transport a computer program. For the sake of convenience, the operations may be described as various interconnected or coupled functional blocks or diagrams. However, there may be cases where these functional blocks or diagrams may be equivalently aggregated into a single logic device, program or operation with unclear boundaries.

CONCLUSION

While the application describes specific examples of carrying out embodiments of the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques that fall within the spirit and scope of the invention as set forth in the appended claims. For example, while specific terminology has been employed above to refer to certain processes, it should be appreciated that various examples of the invention may be implemented using any desired combination of processes.

One of skill in the art will also recognize that the concepts taught herein can be tailored to a particular application in many other ways. In particular, those skilled in the art will recognize that the illustrated examples are but one of many alternative implementations that will become apparent upon reading this disclosure.

Although the specification may refer to “an”, “one”, “another”, or “some” example(s) in several locations, this does not necessarily mean that each such reference is to the same example(s), or that the feature only applies to a single example.