TRANSLATION OF NON-NATIVE CODE BASED ON META-OPERATORS
Technical Field
The present application relates generally to translation and execution of non-native code streams. In particular, the present disclosure relates to translation of non-native code based on meta-operators included in non-native code streams.
Background
A computing system generally includes a central processing unit that is configured to execute program instructions which are ordered and arranged to execute various tasks. Each central processing unit has a predefined set of instructions capable of execution on that system, referred to as an instruction set. The instruction set executable by a central processing unit defines the instruction set architecture of that central processing unit.
Often, it is desirable to run software written for a particular instruction set architecture on a computing system that has a different, and incompatible, instruction set architecture. To do so, the software must be translated from the instruction set in which it is written to an instruction set compatible with the target central processing unit. If a binary program is the desired source from which operation of the non-native software is to be derived, the software can be translated onto the new (target) instruction set architecture by translating the non-native binary program onto the new instruction set architecture on an instruction-by-instruction basis. In such systems, the non-native binary code is generally parsed by a translator, which attempts to translate that code based on the non-native code format or architecture.
Such systems have drawbacks. For example, for existing translators to properly convert non-native code to native code, the format or instruction set architecture of the non-native binary code must be known. Furthermore, if an instruction set changes, any translations incorporated into a translator must be changed to accommodate those changes in the instruction set, while at the same time accommodating older versions of the instruction set. Therefore, existing binary translation systems are incapable of managing translation when the translator might receive non-native software for translation that is formatted according to any of a number of different instruction sets or versions of an instruction set that uses a common opcode for different instructions. Additionally, existing translators are generally incapable of analyzing existing binary code streams to detect features or characteristics of that code without previously knowing which instruction set architecture is used by the code stream, even when that instruction set architecture is selected from among a group of possible predetermined instruction set architectures.
For these and other reasons, improvements are desirable.
Summary
In accordance with the following disclosure, the above and other issues are addressed by the following:
In a first aspect, a method for of executing non-native code on a computing system is disclosed. The method includes receiving a non-native code segment at a computing system, and detecting one or more operators within an unexecuted portion of the code segment. The method further includes selecting a set of operations from among a plurality of sets of operations based at least in part on the one or more operators detected within the unexecuted portion of the code segment. The method also includes translating the non-native code segment to native code using the selected set of operations, for execution on the computing system.
In a second aspect, a computing system includes a code translation unit and one or more central processing modules. The code translation unit is configured to detect an operator within an unexecuted portion of a code segment, select an instruction set from among a plurality of different instruction sets based on the operator, and translate a non-native code segment compiled according to the selected instruction set to native code. The one or more central processing modules are configured to receive and execute the native code. In a third aspect, a computer-implemented method of translating non- native code for native execution on a computing system is disclosed. The method includes receiving a non-native code segment from a compiler, the non-native code segment including an executed portion and at least one unexecuted portion. The method also includes detecting one or more operators within the at least one unexecuted portion of the non-native code segment and describing an instruction set employed in the non-native code segment. The method further includes translating the non-native code segment to native code, based at least in part on the one or more operators, for execution on the computing system. Brief Description of the Drawings
Figure 1 is a schematic illustration of a plurality of computing systems operating using incompatible instruction set architectures;
Figure 2 is a flowchart of a method for translating and executing a non- native code stream on a native, target computing system using one or more unexecuted meta-operators, according to a possible embodiment;
Figure 3 A is a block diagram of an example embodiment of a system in which translation of non-native code based on unexecuted meta-operators in the non- native code segment can be performed, according to a possible embodiment of the present disclosure;
Figure 3B is a block diagram of an example embodiment of a system in which translation of non-native code based on unexecuted meta-operators in the non- native code segment can be performed, according to a second possible embodiment of the present disclosure;
Figure 4 is a block diagram illustrating an example system for translating non-native code based on unexecuted meta-operators and execution of translated, native code, according to an example embodiment;
Figure 5 illustrates an example non-native code segment including meta- operators in unexecutable portions of the code segment, according to a further example embodiment; and Figure 6 is a schematic illustration of an example computing system in which aspects of the present disclosure can be implemented.
Detailed Description
Various embodiments of the present invention will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the invention, which is limited only by the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the claimed invention.
The logical operations of the various embodiments of the disclosure described herein are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a computer, and/or (2) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a directory system, database, or compiler.
In general the present disclosure relates to methods and systems for translation of non-native code based on unexecuted meta-operators included in non- native code streams, for execution on target computing systems implemented using native instruction set architectures. Use of one or more meta-operators allows for improved flexibility in translating non-native code streams, on a segment-by-segment basis, from a variety of different non-native instruction sets to a target instruction set (or sets). Additionally, the present disclosure allows for any of a variety of other types of meta-operators to be recognized by a translator of non-native code, for example to detect potential destinations of branches, a lexical level (nested function depth) of the code in the segment, or to otherwise identify the compiler used to generate the non- native binary code, for example for debug or performance tracking purposes.
Referring now to Figure 1 , a schematic illustration of a plurality of computing systems operating using incompatible instruction set architectures is shown. The illustration shown in Figure 1 is intended to illustrate execution of a code stream 102 on two computing systems 104a-b using different and incompatible instruction set architectures. In other words, while code stream 102 executes natively on the hardware provided as part of computing system 104a, it is non-native to the computing system 104b, meaning that computing system operates using a different set of instructions, and cannot natively execute those instructions, or operators, included in the code stream.
In further specific detail regarding this distinction between native and non-native execution of a code stream, computing system 104a has a first system architecture 106a, and computing system 104b has a second system architecture 106b. Computing system 104a includes a memory 108a and processing unit 110a, while computing system 104b has a memory 108b and processing unit 110b. Typically, in systems having a different system architecture, different memory address sizes and different instruction lengths may be employed, as well as different sets of registers or other resources within the processing units 1 lOa-b.
In the example shown, each memory 108 includes a variety of different types of stored information, including data 112, applications 114, and an operating system 116. On computing system 104a, the operating system executes natively using the system architecture 106a, and controls operation of the applications 114 and access to data 112. The resulting code stream 102 represents a sequence of binary operations and data that are parsed and executed on the computing system 104a, within one or more execution units 115a of the processing unit 110a.
In contrast, the same data 112, applications 114, and operating system 116 can be stored in memory 108b and can form code stream 102, but that code stream cannot directly be executed by the processing unit 110b. Rather, the code stream 102 is passed to a translator 118, which converts the code stream 102, which is non-native with respect to system architecture 106b, to a second code stream 120 which is native to that system architecture. That second code stream 120 can then be executed on execution units 115b of the processing unit 110b.
Referring now to Figure 2, a flowchart of an example method 200 for translating and executing a non-native code stream on a target computing system implementing a native instruction set architecture is illustrated. The method 200 can be executed on a target computing system implementing a native instruction set architecture, such as computing system 104b of Figure 1.
In the embodiment shown, the method 200 is instantiated at a start operation 202, which corresponds to initial compilation of binary code, for example for use/execution on a computing system having a first instruction set architecture. For example, in some embodiments, the first instruction set architecture can correspond to the Unisys Clearpath/MCP instruction set architecture, defined by Unisys Corporation of Blue Bell, Pennsylvania. Other operating systems or instruction set architectures could be used as well.
A non-native code receipt operation 204 corresponds to receiving, at a target computing system having a second instruction set architecture, the compiled binary code written for the first instruction set architecture. Because the binary code is not directly executable on the second computing system (e.g., as illustrated in connection with computing system 104b in Figure 1), the code is referred to as "non- native" binary code herein.
A meta-operator detection operation 206 corresponds to detection of one or more meta-operators within unexecuted portions of a code segment included within the received binary code. In some embodiment, in particular those in which the non- native code is configured for execution on a system implementing the Unisys
Clearpath/MCP instruction set architecture, received non-native code will include a plurality of segments, for example by being separated into code blocks. The code segments each include a portion that, when the code is executed, will never be reached. These unreachable locations in a code segment are generally populated with one or more invalid operators (e.g., NVLD operators in the Clearpath/MCP instruction set architecture), and, if reached by program execution, will be recognized as the result of an error occurring in the software.
In some embodiments discussed herein, the non-native code can be compiled such that, rather than including invalid operators in these locations, it has one or more meta-operators that are not intended to be executed, but rather describe features of the code segment. These meta-ops perform no transformation on the system state, but serve to convey potentially useful information from the compiler to the execution engine.
Various types of meta-operators are discussed below in connection with Figures 4-5, below; however, in some embodiments a possible meta-operator can describe a code level that is used by the non-native code, which defines an instruction set that is used by the code. By including such a code level meta-operator, the code can describe (and the target computing system's translator can detect) which instruction set architecture is used within a particular code segment, such that more than one instruction set might be supported by the translator, either on a per code stream basis or a per code segment basis. In additional embodiments, the meta-operators can include, for example, information about the compiler that compiled the non-native code (e.g., for debug purposes), as well as a lexical level or branch information associated with the code, or one or more optimizations to be applied during translation. Other example meta-operators are discussed below.
Once the meta-operator detection operation 206 is performed to detect the one or more meta-operators within a particular code segment, a feature selection operation 208 is performed, to determine which features are to be implemented in the translator based on the description of the non-native code provided by the meta- operators. In an example embodiment in which the meta-operator identifies a code level of the non-native code segment, the feature selection operation 208 executes in a translator (e.g. in the code translation unit, or CTU, described below in Figures 3-4), to select a particular instruction set architecture in which the non-native code is defined. A translation operation 210 then translates the non-native code into native code, for execution. In some embodiments, the native code corresponds to code defined according to an Intel-based instruction set architecture; however, in other embodiments, different instruction set architectures (e.g. for execution on a Java processor, or on an entirely different instruction set architecture) could also be used. An example process for translating non-native code to native code is discussed in copending U.S. Patent Application No. , filed (Unisys Ref. No. 11-002), entitled "Abstracting Computational Instructions to Improve Performance", the disclosure of which is hereby incorporated by reference in its entirety.
Following the translation operation 210, an execution operation 212 is performed, corresponding to native execution of the translated code, natively on the computing system on which it is intended to be executed. In some embodiments, the execution operation 212 can correspond to passing the translated code to one or more central processing modules, as illustrated in Figures 3-4, below. An end operation 214 corresponds to completed execution of the code segment following translation.
Referring to Figure 2 generally, it is noted that the method 200 can be performed on each code segment individually, such that for each code segment that is translated, a different code level or other instruction set architecture could be employed for translation, and other descriptive features could be included in the meta-operators in the code. Furthermore, the operations discussed in Figure 2 can be performed in a variety of orders, for example by receiving an entire code stream including a number of code segments, interpreting each code segment according to the non-native code and associated meta-operators in each segment, and then executing the translated code stream as defined by the translated code. Other arrangements, in which code segments are sequentially pipelined through translation and execution, are possible as well.
Now referring to Figure 3A, an example embodiment of a computer system 300 for executing translated code streams is illustrated. The computer system 300 represents a particular example embodiment in which a Unisys Clearpath/MCP computing system is emulated on a computing system having a different instruction set architecture, for example using an Intel-based instruction set architecture. In the context of the present disclosure, a code stream written for execution on a Unisys Clearpath/MCP system software can be translated for execution using native instructions of the Intel-based instruction set architecture. In the MCP environment, the non-native instructions, or foreign operators, comprise the proprietary E-Mode code 302. The native instructions, in some embodiments refers to the Intel 64 and Intel architecture (IA) 32 instruction sets; however, in alternative embodiments configured for execution on different hardware, other systems architectures could be used as well. In general, in the computer system 300, the non-native E-Mode code 302 is parsed by a parser 304 to form translated code 306, e.g., native Intel instructions. As illustrated in Figure 3, the computer system 300 includes a memory 308 that communicates, via an interface 311, with various function processors. The function processors may be implemented in hardware, software, firmware, or any combination thereof. The memory 308 stores the E-Mode code 302 to be parsed by the E-mode parser 304, and can also store the translated code 306. The function processors include one or more central processor modules (CPM) 312, code translation units (CTU) 314, and one or more additional control units 316 (e.g., for controlling I/O or disk interface actions). As illustrated in the embodiment shown, the parser 304 is implemented within CTU 314.
In the example computer system 300 shown, each CPM 312 is responsible for execution of the translated code 306. In virtual machine
implementations, the CPM 312 can be one or more processes that embody an execution engine, each of which is configured to execute the translated code 306, for example by calling one or more routines defined in that CPM.
Referring now to Figure 3B, an alternative embodiment of the computer system 350 is shown in which one or more CPMs 312 include a CTU 314 and parser 304 incorporated therein. In such embodiments, the CTU 314 and parser 304 can execute in a manner such that the CPM can receive the E-mode code 302 and the CTU 314 and parser 304 can generate translated code 306; that code can then asynchronously (e.g., separately and/or later in time) execute that translated code 306 to perform one or more functions defined in the CPM, to adjust the system state managed by that CPM. In comparison to Figure 3A, the arrangement of computing system 350 in Figure 3B may be implemented in an application execution architecture, rather than a resource management-type arrangement as illustrated in Figure 3A. Furthermore, although two differing embodiments are illustrated in Figures 3A-3B, it is recognized that a variety of other module arrangements could be used.
Referring now to Figure 4, an example embodiment of a system 400 for translating non-native code based on unexecuted meta-instructions, as well as execution of translated, native code, is illustrated. The system 400 can, in some embodiments, be implemented within the computer systems 300, 350 of Figures 3A-3B, on one or more physical computing systems such as are described below in connection with Figure 6.
In the embodiment shown, the system 400 includes a translator, shown as a code translation unit (CTU) 320. The CTU 314 receives one or more non-native code segments 402a-b (referred to generally as code segments 402), for example which can be output from a compiler 404. In some embodiments, the compiler 404 operates on the same physical computing system as the translator; however, in typical embodiments, the compiler executes on a separate system altogether (e.g., either a native or non-native computing system), and does not form a portion of the system 400 overall.
As illustrated, each of the non-native code segments 402a-b can include an executable portion 406 and one or more unexecutable portions 408. The executable portion 406 includes generally executable, non-native instructions, which are translated to native instructions by the CTU 314. The unexecutable portions 408 include one or more meta-operators, or operators that are not strictly included within the non-native instruction set, but are understood by the CTU 314 and inserted by the compiler 404, to pass information about the code segment 402 received at the CTU. The unexecutable portions 408 generally refer to portions of the code segment that will not normally be executed by a computing system. For example, the unexecutable portions 408 can be included at locations within the code segment that would typically not be reached by normal execution flow.
In the embodiments described herein, the meta-operators generally are not encountered during an active execution stream, and attempts to execute any meta- operator will typically result in an error within a CPM. The meta-operators can take a variety of forms, and have a number of uses. In the embodiment shown, an example unexecutable code segment 408 defines a code level of the non-native code included in that code segment 402. The CTU 314 can identify a particular instruction set used for the non-native code segment 402 based on the meta-operator, and can select a correct set of translations for use in generating native code. In the embodiment shown, the CTU 320 includes a code parser, for example as shown to be an E-Mode code parser 304. The interpreter translates the non- native code segment 402 to corresponding native code 410, and accesses a code level libraries module 412, which manages translation definitions for a plurality of different instruction sets, or code levels. In the embodiment shown, the code level libraries module 412 manages translation libraries for a first architecture (libraries 414a-b) and a second architecture (library 414c). In the embodiment shown, two libraries 414a-b are included for the first architecture, and are selectable, either by the CTU 314 and associated parser 304 based on preferences set in the parser, or based on a definition provided by the one or more meta-operations included within the unexecutable portion 408 of the non-native code segment 402. For example, the first library 414a can represent a first set of instructions used for translation, and the second library 414b can represent definitions of a second set of instructions, such as a revised set of instructions that reassigns opcodes from deprecated instructions to new (e.g., more efficiently- executed) instructions. In such cases, two different code levels, or instruction sets, might assign a common opcode to two different instructions.
In a further example, a first library 414a may correspond to a direct, instruction-by-instruction translation from the non-native instruction set to the native instruction set, and the second library 414b may include one or more concatenations to provide improved performance. Example optimizations that can be selectively incorporated into a translated code segment are described in copending U.S. Patent
Application No. , filed (Unisys Ref. No. 11-002), entitled "Abstracting
Computational Instructions to Improve Performance", the disclosure of which was previously incorporated by reference in its entirety.
In both cases, based on the meta-operator, instruction execution performance can be defined by the non-native code received by the CTU 314.
In some embodiments, the third library 414c may represent an entirely different instruction set useable by the parser 304 and CTU 314, in the event that all or a portion of a code stream (including a plurality of code segments 402) is received that includes a meta-operator identifying a different instruction set as defining the non- native code.
Although in the embodiment shown libraries are associated with each of the instruction set architectures, code levels, and/or concatenation selections, it is noted that the term "library" is further intended to encompass a variety of other types of structures which may define the different instruction types that can be encountered, such as tables, text files, or other arrangements.
In the embodiment shown, when a native code segment 410 is generated by the CTU 314, that code segment can be passed to one or more CPMs 312 for execution, shown as CPMs 312a-n. In some embodiments, each of the CPMs operates on the same computing system, and manage different tasks (e.g., operate as different processing systems having a common instruction set architecture). In alternative embodiments, the CPMs can be defined to execute native code differently, for example representing different instruction set architectures, different execution engines, or other differing systems. In such embodiments, the CPMs 312a-n can operate on different physical computing systems, including different systems having different instruction set architectures or computing capabilities.
In an alternative embodiment shown in Figure 5, a second example non- native code segment 500 is illustrated, which includes an executable portion 502 and a plurality of unexecutable portions, shown as portions 504a-b. This second example code segment 500 illustrates additional arrangements of meta-operators and
unexecutable code portions, and relates to discussion of additional meta-operators that could be used in connection with a translator, such as the CTU described above in connection with Figures 3A-3B and 4.
In the embodiment shown, the non-native code segment 500 includes a first unexecutable code portion 504a positioned as a header, before the executable portion 502. This portion can include, for example, an invalid operator, followed by one or more meta-operators describing a code level or instruction set with which the non-native code segment is defined. The second unexecutable code portion 504b can be positioned after the executable portion 502, and can include a variety of additional information useable by a translator to assist in translating or debugging a translation of non-native code to native code.
For example, in some embodiments one of the unexecutable code portions 504a-b can include a meta-operator acting as a lexical level indicator, or LLx, which provides a mechanism by which the CTU is notified of a particular
implementation efficiency that can be employed when translating the code. Generally, the lexical level indicator meta-operator defines the static nesting depth of a procedure defined in a particular code segment. This information may be used to establish for the CPM's preprocessing facilities at what lexical level the code within the code segment 500 will execute. The lexical level established by one of these operators applies to following instructions in code address sequential (not necessarily actual execution) order until the appearance of another meta-operator describing a lexical level. In some embodiments, where lexical level values conflict, this can represent a likely occurrence of an interrupt, for example due to incorrect decoding of addresses; in alternative embodiments, a Code Structure Error will occur if during the dynamic execution sequence an instruction causes the CPM to enter, exit, or branch to an instruction where lexical level values established by one of these meta-operators conflict.
In a further example of types of meta-operators that can be included in a code segment that define the non-native code segment, branch information can be included, in particular are relating to dynamic branches. For example, a compiler may know at compile time the existence of such dynamic branches and likely branch targets, since the entire code has been parsed at compile time. Use of meta-operators may allow the compiler to pass this information to the translator for improved pre-processing of some branch targets.
In a still further example, one of the unexecutable code portions 504a-b can include an identification of the compiler from which the non-native code was generated. If a compilation error or other error in the code is detected when the code is received at a translator, a compiler identifier would allow a debugging user to identify a relationship between the compiler and translator that may be the source of such an error. In addition to the meta-operators discussed above as defining the received non-native code segment, in some embodiments meta-operators can also be included within the unexecuted portions 504a-b of the code segment 500 that define intended operation of the target system. For example, in some embodiments the meta- operators included in the code can define (1) a target instruction set architecture to which the non-native code should be translated, thereby allowing translation to multiple target architectures, or (2) one or more performance levels defined for use of the code, for example defining a number of optimizations to be applied (or not to be applied) during translation. For example, a first code segment can be intended to execute on a first CPM implemented in a first computing system having a first instruction set architecture, while a second code segment can be intended to execute on a second CPM implemented in a second computing system having a second, different instruction set architecture. Other possible arrangements are available as well, and can be defined by other meta-operators, defining other features of a target system.
Referring to Figures 4-5 generally, although the unexecutable portions
408, 504a-b are illustrated as header and end portions of the code segment 500, it is understood that these portions can be located in a variety of different locations within a code segment 500, but are generally positioned such that typical execution flow would not reach the instructions. For example, in the embodiment illustrated in Figure 4, the unexecutable portion 408 is positioned in a beginning or header portion of a code segment, typically following an invalid operator instruction (e.g., NVLD), where it would not be reached by a typical execution stream. In the alternative embodiment illustrated in Figure 5, two unexecutable portions of segment 500 are illustrated, one of which is included at a header of the segment and a second of which is located at an end of the segment.
Furthermore, and referring to Figures 2-5 generally, it can be seen that use of meta-operators in unexecutable portions of code segments allows a compiler to pass information to a translator that the translator would otherwise have no way of knowing, or would otherwise require a complete parsing of a code stream to detect (e.g., in the event of branches and lexical level information). In such circumstances, the meta-operators can define both features of the code stream itself (on a segment-by- segment basis), or can also dictate the target system on which the code stream should be executed. As discussed above, this allows for increased flexibility in translating non- native code streams, in terms of instruction set compatibility, performance levels, and debugging features.
Referring now to Figure 6, a schematic illustration of an example computing system in which aspects of the present disclosure can be implemented. The computing system 600 can represent, for example, a native computing system within which one or more of systems 104a-b, 300, or 400 could be implemented. In particular, in various embodiments, the computing device 600 implements one particular instruction set architecture, and can be used to translate non-native code streams for execution in accordance with the methods and systems described herein.
In the example of Figure 6, the computing device 600 includes a memory 602, a processing system 604, a secondary storage device 606, a network interface card 608, a video interface 610, a display unit 612, an external component interface 614, and a communication medium 616. The memory 602 includes one or more computer storage media capable of storing data and/or instructions. In different embodiments, the memory 602 is implemented in different ways. For example, the memory 602 can be implemented using various types of computer storage media.
The processing system 604 includes one or more processing units. A processing unit is a physical device or article of manufacture comprising one or more integrated circuits that selectively execute software instructions. In various
embodiments, the processing system 604 is implemented in various ways. For example, the processing system 604 can be implemented as one or more processing cores. In another example, the processing system 604 can include one or more separate microprocessors. In yet another example embodiment, the processing system 604 can include an application-specific integrated circuit (ASIC) that provides specific functionality. In yet another example, the processing system 604 provides specific functionality by using an ASIC and by executing computer-executable instructions. The secondary storage device 606 includes one or more computer storage media. The secondary storage device 606 stores data and software instructions not directly accessible by the processing system 604. In other words, the processing system 604 performs an I/O operation to retrieve data and/or software instructions from the secondary storage device 606. In various embodiments, the secondary storage device 606 includes various types of computer storage media. For example, the secondary storage device 606 can include one or more magnetic disks, magnetic tape drives, optical discs, solid state memory devices, and/or other types of computer storage media.
The network interface card 608 enables the computing device 600 to send data to and receive data from a communication network. In different
embodiments, the network interface card 608 is implemented in different ways. For example, the network interface card 608 can be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a wireless network interface (e.g., WiFi, WiMax, etc.), or another type of network interface.
The video interface 610 enables the computing device 600 to output video information to the display unit 612. The display unit 612 can be various types of devices for displaying video information, such as a cathode-ray tube display, an LCD display panel, a plasma screen display panel, a touch-sensitive display panel, an LED screen, or a projector. The video interface 610 can communicate with the display unit 612 in various ways, such as via a Universal Serial Bus (USB) connector, a VGA connector, a digital visual interface (DVI) connector, an S-Video connector, a High- Definition Multimedia Interface (HDMI) interface, or a DisplayPort connector.
The external component interface 614 enables the computing device 600 to communicate with external devices. For example, the external component interface 614 can be a USB interface, a Fire Wire interface, a serial port interface, a parallel port interface, a PS/2 interface, and/or another type of interface that enables the computing device 600 to communicate with external devices. In various embodiments, the external component interface 614 enables the computing device 600 to communicate with various external components, such as external storage devices, input devices, speakers, modems, media player docks, other computing devices, scanners, digital cameras, and fingerprint readers.
The communications medium 616 facilitates communication among the hardware components of the computing device 600. In the example of Figure 6, the communications medium 616 facilitates communication among the memory 602, the processing system 604, the secondary storage device 606, the network interface card 608, the video interface 610, and the external component interface 614. The communications medium 616 can be implemented in various ways. For example, the communications medium 616 can include a PCI bus, a PCI Express bus, an accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing system Interface (SCSI) interface, or another type of communications medium.
The memory 602 stores various types of data and/or software instructions. For instance, in the example of Figure 6, the memory 602 stores a Basic Input/Output System (BIOS) 618 and an operating system 620. The BIOS 618 includes a set of computer-executable instructions that, when executed by the processing system 604, cause the computing device 600 to boot up. The operating system 620 includes a set of computer-executable instructions that, when executed by the processing system 604, cause the computing device 600 to provide an operating system that coordinates the activities and sharing of resources of the computing device 600. Furthermore, the memory 602 stores application software 622. The application software 622 includes computer-executable instructions, that when executed by the processing system 604, cause the computing device 600 to provide one or more applications. The memory 602 also stores program data 624. The program data 624 is data used by programs that execute on the computing device 600.
Although particular features are discussed herein as included within an electronic computing device 600, it is recognized that in certain embodiments not all such components or features may be included within a computing device executing according to the methods and systems of the present disclosure. Furthermore, different types of hardware and/or software systems could be incorporated into such an electronic computing device.
In accordance with the present disclosure, the term computer readable media as used herein may include computer storage media and communication media. As used in this document, a computer storage medium is a device or article of manufacture that stores data and/or computer-executable instructions. Computer storage media may include volatile and nonvolatile, removable and non-removable devices or articles of manufacture implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. By way of example, and not limitation, computer storage media may include dynamic random access memory (DRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), reduced latency DRAM, DDR2 SDRAM, DDR3 SDRAM, solid state memory, read-only memory (ROM), electrically- erasable programmable ROM, optical discs (e.g., CD-ROMs, DVDs, etc.), magnetic disks (e.g., hard disks, floppy disks, etc.), magnetic tapes, and other types of devices and/or articles of manufacture that store data. Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct- wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.
The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.