Patent Application
20140129804
This application relates generally to processor-based systems, and, more particularly, to physical registers in processor-based systems.
Conventional processor-based systems typically include one or more processing elements such as a central processing unit (CPU), a graphical processing unit (GPU), an accelerated processing unit (APU), and the like. The processing units include one or more processor cores that are configured to access instructions or data that are stored in a main memory and then execute the instructions or manipulate the data. Processor cores include a floating point unit (FPU) that is used to perform mathematical operations on floating point (FP) numbers when required by the executed instructions. For example, conventional floating-point units are typically designed to carry out operations such as addition, subtraction, multiplication, division, and square root. Some systems can also perform various transcendental functions such as exponential or trigonometric calculations. Floating-point operations may be handled separately from integer operations on integer numbers. The floating-point unit may also have a set of dedicated floating-point registers for storing floating-point numbers.
The floating-point units implemented in processor-based systems typically include a set of physical registers in a physical register file. The physical registers may be used to store different types of information during operation of the floating-point unit. For example, physical registers may be used to store data for in-flight operations until this data is committed to the state of the machine. For another example, instruction set architectures (ISA) may support a set of named architectural (or micro-architectural) registers that can be used in software created for the machine. The architectural registers can be mapped to the physical registers in the physical register file, e.g., using renaming logic that maps the name of the architectural register to a physical register number that identifies a physical register. In operation, the physical registers can be allocated to in-flight operations or architectural registers as needed, depending on the availability of the physical registers in the physical register file.
Floating-point units can support multiple floating-point instruction sets. For example, the x86 architecture instruction set includes a floating-point related subset of instructions that is referred to as x87. The x87 instruction set includes instructions for basic floating point operations such as addition, subtraction and comparison, as well as for more complex numerical operations such as the tangent and arc-tangent functions. Floating-point instructions in the x87 instruction set can use a set of architected registers that can be mapped to physical registers in the floating-point unit. For another example, computers that include multiple processing cores may support a single instruction, multiple data (SIMD) instruction set. The x86 architecture SIMD instruction set supports a subset of instructions that are referred to as Multi-Media Extensions (MMX). Floating-point instructions in the MMX instruction set use the same set of architected registers as the x87 instruction set. These registers are thus conventionally known as x87/MMX registers. The x86 architecture SIMD instruction set supports another floating-point related subset of instructions that are referred to as Streaming SIMD Extensions (SSE). Floating-point instructions in the SSE instruction set can use another set of architected registers (conventionally known as XMM registers) that can also be mapped to physical registers in the floating-point unit. The Advanced Vector Extension (AVX) instruction set is an advanced version of SSE that defines 256-bit versions of the SSE instructions, as well as new instructions, and extends the XMM registers to be 256 bits wide.
The following presents a simplified summary of the disclosed subject matter in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an exhaustive overview of the disclosed subject matter. It is not intended to identify key or critical elements of the disclosed subject matter or to delineate the scope of the disclosed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is discussed later.
In some embodiments, an apparatus is provided for tracking and reclaiming physical registers. Some embodiments of the apparatus include rename logic configurable to map architectural registers to physical registers. The rename logic is configurable to bypass allocation of a physical register to an architectural register when information associated with the architectural register satisfies a bypass condition. Some embodiments of the apparatus also include a plurality of first bits associated with the architectural registers. The rename logic is configurable to set one of the first bits to indicate that allocation of a physical register to the corresponding architectural register has been bypassed. Embodiments of a computer readable media including instructions that when executed can configure a manufacturing process used to manufacture a semiconductor device including the apparatus are also provided.
In some embodiments, a method is provided for tracking and reclaiming physical registers. Some embodiments of the method include bypassing allocation of a physical register to an architectural register when information associated with the architectural register satisfies a bypass condition. Some embodiments of the method also include setting one or more first bits to indicate that allocation of a physical register to the architectural register has been bypassed.
The disclosed subject matter may be understood by reference to the following description taken in conjunction with the accompanying drawings, in which like reference numerals identify like elements, and in which:
While the disclosed subject matter may be modified and may take alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the description herein of specific embodiments is not intended to limit the disclosed subject matter to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the appended claims.
Illustrative embodiments are described below. In the interest of clarity, not all features of an actual implementation are described in this specification. It will of course be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions should be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure. The description and drawings merely illustrate the principles of the claimed subject matter. It should thus be appreciated that those skilled in the art may be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles described herein and may be included within the scope of the claimed subject matter. Furthermore, all examples recited herein are principally intended to be for pedagogical purposes to aid the reader in understanding the principles of the claimed subject matter and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions.
The disclosed subject matter is described with reference to the attached figures. Various structures, systems and devices are schematically depicted in the drawings for purposes of explanation only and so as to not obscure the disclosed embodiments with details that are well known to those skilled in the art. Nevertheless, the attached drawings are included to describe and explain illustrative examples of the disclosed subject matter. The words and phrases used herein should be understood and interpreted to have a meaning consistent with the understanding of those words and phrases by those skilled in the relevant art. No special definition of a term or phrase, i.e., a definition that is different from the ordinary and customary meaning as understood by those skilled in the art, is intended to be implied by consistent usage of the term or phrase herein. To the extent that a term or phrase is intended to have a special meaning, i.e., a meaning other than that understood by skilled artisans, such a special definition is expressly set forth in the specification in a definitional manner that directly and unequivocally provides the special definition for the term or phrase. Additionally, the term, “or,” as used herein, refers to a non-exclusive “or,” unless otherwise indicated (e.g., “or else” or “or in the alternative”). Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.
As discussed herein, floating-point units are expected to support numerous ISA register formats at least in part to maintain backwards compatibility. For example, x87/MMX registers are architecturally 80-bits wide, SSE registers are architecturally 128-bits wide, and AVX registers extend the SSE register format up to 256-bits wide. The different sizes of the different architectural register formats may be accommodated using physical registers that are 128 bits wide. The architectural registers for x87/MMX therefore use a subset of the available bits in a physical register and the AVX architectural registers may be mapped to two physical registers to accommodate the 256 bit width. However, the AVX format supports both 128-bit instructions and 256-bit instructions. The AVX 128-bit instructions zero out the upper 128 bits of the 256-bit architectural register.
Mapping architected registers for the different instruction sets to physical registers in the floating-point unit consumes area on the chip, timing resources, and power. Depending on the instruction sets used by different applications, the resources that are allocated to the different types of instruction sets may not be used, thereby reducing the efficiency of the processing unit. For example, reserving a physical register for storing the zeroed out portion of the 256-bit architectural register prevents the physical register from being used for other instructions such as in-flight instructions. Reserving a physical register for other all-zero data entries or unused architectural registers may similarly reduce the available number of physical registers for in-flight operations. Embodiments of the techniques described herein may be used to reduce or eliminate one or more of the aforementioned problems in the conventional practice.
As discussed herein, reserving a physical register for architectural registers that store information (or are going to store information in the future) satisfying a bypass condition prevents the physical register from being used by other instructions such as in-flight instructions. The information (e.g., data) satisfies a bypass condition when the information includes a bit pattern that is all-zeros, when the information includes a predetermined bit pattern (e.g., the upper 128 bits of a 256 bit register are all zeros, the register includes a non-zero configurable bit pattern that can be identified, etc.), or when the information includes unusable or “dead” data. Embodiments of the techniques described herein may address one or more of these deficiencies in the conventional practice by incorporating logic that can determine whether an architectural register stores information satisfying a bypass condition (e.g., all zeros). The architectural register may be mapped to a physical register number that is not associated with a physical register when the architectural register stores information satisfying a bypass condition. The mapping of the architectural register to the physical register number includes an indication that the architectural register stores information satisfying a bypass condition. Bypass logic may then provide a configurable bit pattern to instructions that access the architectural register that has not been allocated a physical register.
In some embodiments, the indication includes a bit that is associated with the architectural register. The bit may be one of an array of bits implemented in the renaming or mapping logic used to map architectural registers to physical register numbers. The bit can be set to indicate that the architectural register may be used to store information satisfying a bypass condition. One exemplary bypass condition occurs when an architectural register either stores or is going to store all zeros. For example, a bypass condition may occur when the upper 128 bits of an AVX 256-bit architectural register are zeroed out because the 256-bit architectural register is used by a 128-bit instruction. For another example, a bypass condition may occur when memory data that is to be written or loaded into an architectural register is all zeros. Some embodiments may also be able to detect a bypass condition when the memory data loaded into an architectural register is some other configurable bit pattern besides all zeros. If the bit is set, the system bypasses allocating a physical register to the architectural register because it is understood that the architectural register stores information satisfying a bypass condition. Thus, instead of allocating a physical register to store the information satisfying the bypass condition, the physical register is free to be allocated to other architectural registers or in-flight operations. In some embodiments, the bit may also be set in response to an instruction that generates the information satisfying the bypass condition (e.g., an instruction that zeros out an architectural register). The corresponding physical register may be freed in response to the zeroing instruction so that it is available for allocation to other architectural registers or in-flight operations. For example, the previous physical register may be freed when the zeroing instruction retires and no new physical register is mapped.
Some embodiments may use the bits associated with the architectural registers, as well as other information associated with the architectural registers or the physical registers, to free or reclaim physical registers that are associated with architectural registers that store information satisfying a bypass condition (e.g., architectural registers that store all-zeros, that store a predetermined bit pattern, or that are known to hold unusable data). Unusable data is data that for any reason should not be used by instructions because it may cause the instruction to return an incorrect result or perform an incorrect action. Unusable data may also be referred to as “dead” data. Techniques for detecting or identifying unusable data are known in the art. The term “bypass” is therefore understood herein to encompass actions including deciding not to allocate a physical register that would ordinarily have been allocated to an architectural register or freeing a physical register that was previously allocated to an architectural register even though the architectural register may still be referenced by one or more instructions.
In some embodiments, the main structure 110 includes a graphics card 120. For example, the graphics card 120 may be an ATI Radeon™ graphics card from Advanced Micro Devices (“AMD”). The graphics card 120 may, in different embodiments, be connected on a Peripheral Component Interconnect (PCI) Bus (not shown), PCI-Express Bus (not shown), an Accelerated Graphics Port (AGP) Bus (also not shown), or other electronic or communicative connection. The graphics card 120 may include a graphics processing unit (GPU) 125 used in processing graphics data. The graphics card 120 may be referred to as a circuit board or a printed circuit board or a daughter card or the like.
The computer system 100 shown in
The computer system 100 may be connected to one or more display units 170, input devices 180, output devices 185, or peripheral devices 190. These elements may be internal or external to the computer system 100, and may be wired or wirelessly connected. The display units 170 may be internal or external monitors, television screens, handheld device displays, touchscreens, and the like. The input devices 180 may be any one of a keyboard, mouse, track-ball, stylus, mouse pad, mouse button, joystick, touchscreen, scanner or the like. The output devices 185 may be any one of a monitor, printer, plotter, copier, or other output device. The peripheral devices 190 may be any other device that can be coupled to a computer. Example peripheral devices 190 may include a CD/DVD drive capable of reading or writing to physical digital media, a USB device, Zip Drive, external hard drive, phone or broadband modem, router/gateway, access point or the like.
The GPU 125 and the CPU 140 may implement floating point units (FPUs) 198, 199, respectively. The FPUs 198, 199 are configurable to carry out operations on floating point numbers such as addition, subtraction, multiplication, division, and square root. The instruction set architecture (ISA) used by the FPUs 198, 199 may specify a set of architectural registers that can be used by instructions, e.g., instructions in programs written for execution by the computer system 100. Instructions executed by the FPUs 198, 199 may read or write the architectural registers. The FPUs 198, 199 also implement a physical register file that includes physical registers used to store the information associated with the architectural registers. The FPUs 198, 199 may therefore include mapping tables that can be used to map the architectural registers to numbers indicating the actual physical registers. As discussed herein, the mapping tables may be configurable to map architectural registers that have different sizes (e.g., the architectural registers defined by different instruction set architectures) to a common set of physical registers in a physical register file.
The floating-point unit 300 also includes rename logic 310 that maps architectural registers to one or more physical registers in a physical register file 315. in some embodiments, the rename logic 310 includes an array of bits (which may be referred to as Zbits) that are each associated with one of the architectural registers. The rename logic 310 may set the Zbit corresponding to an architectural register when the rename logic 310 (or other functionality within the floating-point unit 300) determines that the contents of the architectural register correspond to a configurable bit pattern, such as all zeros or unused data.
A schedule queue 320 may be used to schedule execution of instructions in the floating-point unit 300. In some embodiments, the rename logic 310 provides information (such as a physical register number) indicating the identity of the physical register(s) allocated to architectural register(s) that are referenced by the instructions. The schedule queue 320 may therefore schedule reads or writes to the physical registers in the physical register file 315 and the results may be passed to other portions of the floating-point unit 300, e.g. for performing multiply or add operations on the source operands that were read from the physical register file 315. However, if the rename logic 310 determines that the Zbit associated with the architectural register has been set, indicating that allocation of a physical register has been bypassed and no physical register is associated with the architectural register, the schedule queue 320 can bypass reading or writing the physical register file 315.
In some embodiments, the floating-point unit 300 includes bypass logic 325 that can receive signals from the schedule queue 320 indicating that the schedule queue 320 has bypassed accessing the physical register file 315 because no physical register is associated with an architectural register referenced by the instruction. The bypass logic 325 may then generate the configurable bit pattern associated with the architectural register and provide the configurable bit pattern to other portions of the floating-point unit 300, e.g., as the source operands for the instruction. For example, the bypass logic 325 may provide zeros to fill the 128 zero bits of a 128-bit AVX architectural register when the 128-bit AVX architectural register is a source operand for an instruction. The control signal provided by the scheduler queue 320 may therefore indicate whether the bypass logic 325 generates and provides zeros as outputs or passes through the information provided by the physical register file 315. Some embodiments of the bypass logic 325 may be implemented in software, firmware, hardware, or a combination thereof.
The floating-point unit 300 also includes a retire queue 330 that stores instructions that are waiting to retire or are in the process of being retired. A free list (FL) 335 includes entries associated with the physical registers in the physical register file. In some embodiments, the physical register file 315 includes 72 physical registers and, therefore, the free list 335 may include up to 72 entries corresponding to these physical registers. Entries in the free list 335 indicate whether the corresponding physical register is “free” so that the physical register can be allocated to a decoded instruction or other in-flight operation. The retire queue 330 can signal the free list 335 when an instruction has retired so that the physical registers currently mapped as the destination architectural register referenced by the retired instruction can be freed for allocation to other instructions or operations, since the retired instruction maps a new physical register to that architectural register. The free list 335 may also communicate with the rename logic 310 so that the rename logic 310 knows when a physical register has been freed for allocation to an architectural register.
In some embodiments, the ARF 405 includes an array 415 that includes information indicating the available architectural registers and an array 420 that includes information indicating the physical register number (PRN) of the physical register that is mapped to the corresponding architectural register. The ARF 405 also includes an array 425 that includes the Zbits associated with the corresponding architectural registers. When a physical register has been allocated to an architectural register, the physical register number identifying the allocated physical register is stored in the corresponding entry in the array 420 and the value of the Zbit in the corresponding entry in the array 425 is set to 0. The Zbit in the corresponding entry in the array 425 may alternatively be set to 1 to indicate that allocation of a physical register to the architectural register has been bypassed so that no actual physical register has been allocated to the architectural register. In this case, the value of the corresponding entry in the array 420 is not used to identify an actual physical register and consequently the entry may take on any value.
The FF 410 also includes an array 430 that includes information indicating the available architectural registers, an array 435 that includes information indicating the physical register number (PRN) of the physical register mapped to the architectural register, and an array 440 that includes Zbits associated with the corresponding architectural registers. In some embodiments, the FF 410 also includes an array 445 of valid bits, an array 450 of ready bits, and an array 455 of IsLd bits. The arrays 445, 450, 455 may be used to track whether the physical register that is mapped to the corresponding architectural register is “ready” (e.g., whether the operation that produces its data has completed or not) at dispatch. When a physical register has been allocated to an architectural register in response to decoding a speculative instruction, the physical register number identifying the allocated physical register is stored in the corresponding entry in the array 430 and the value of the Zbit in the corresponding entry in the array 445 is set to 0. The Zbit in the corresponding entry in the array 440 may alternatively be set to 1 to indicate that allocation of a physical register to the architectural register has been bypassed so that no actual physical register has been allocated to the architectural register. In this case, the value of the corresponding entry in the array 435 is not used to identify an actual physical register and may therefore take on any value.
A decoder such as the FP opcode decoder 305 shown in
The rename logic 310 sets (at 515) a Zbit associated with the architectural register that includes all zeros and bypasses (at 520) allocation of a physical register to the architectural register. For example, the rename logic 310 may bypass (at 520) allocation of a physical register to an architectural register by not allocating a physical register to the 128 zero bits of a 256-bit architectural register. For another example, the rename logic 310 may bypass (at 520) allocation of a physical register to an architectural register by freeing the physical register in response to determining (at 510) that the decoded instruction zeros out the contents of the physical register. The mapping of the zeroed-out architectural register to the physical register may however be maintained in a mapping table such as the ARF 405 or the FRF 410 shown in
In some embodiments, the ARF 605 includes an array 615 that includes information indicating the available architectural registers and an array 620 that includes information indicating the physical register number (PRN) of the physical register that is mapped to the corresponding architectural register. The rename logic 600 differs from the rename logic 400 shown in
The FF 610 also includes an array 625 that includes information indicating the available architectural registers, an array 630 that includes information indicating the physical register number (PRN) of the physical register mapped to the architectural register, an array 635 of valid bits, an array 640 of ready bits, and an array 645 of IsLd bits. When a physical register has been allocated to an architectural register in response to decoding a speculative instruction, the physical register number identifying the allocated physical register is stored in the corresponding entry in the array 630. The physical register number in the corresponding entry in the array 620 may alternatively be set to PRN_Rsrv0 to indicate that allocation of a physical register to the architectural register has been bypassed so that no actual physical register has been allocated to the architectural register.
Embodiments of the data structure 720, 725, 730 may be used to bypass allocation of physical registers to architectural registers based on data values that are produced by execution units or data loaded from memory. For example, some embodiments may be used to retain or recover Zbit values following operations such as full floating-point register loading instructions like FXRSTOR/XRSTOR, as well as CC6 restore. Some embodiments may perform dynamic detection of configurable sequences of bits in registers using an instruction such as a op—referred to herein as FPKLDTEST—that can perform zero detection on data loaded from memory. The FXRSTOR, XRSTOR, and CC6-restore microcode routines may be configured to use FPKLDTEST to perform floating-point state restores of XMM and YMM registers.
Some embodiments of the FPKLDTEST operation are configured as a load-execute op that sets a zero-detect status bit in the data structure 720 of the retire queue 705 (e.g., the status bit is set to a value of 1) if the memory data in the corresponding architectural register is all zeros. At retire, the retire queue 705 reads out the zero-detect status bit and uses that to set ZBits for the architectural registers in the data structure 730 maintained by the renamer 715. In some embodiments, the retire queue 705 is not configured to set bits in the renamer's retire-time ZBit array directly because the ZBit array in the data structure 730 may be used for floating-point physical register file token accounting. To support the token accounting, the Zbit array in the data structure 730 should be kept consistent with a speculative, decode-time ZBit array. The speculative Zbit array is not aware of dispatching and decoding of the FPKLDTEST op for the data-based zero detection and consequently allowing the retire queue 705 to directly change the Zbit array in the renamer 715 could lead to an inconsistency between the speculative and non-speculative Zbit arrays. The retire queue 705 may therefore use the zero-detect status bit in the data structure 720 to set bits in the Data0 array to track which registers have zero data.
The free list 710 tracks the physical registers that are mapped to the Data0 registers using a 72-entry bit-vector in the data structure 725. This vector may be referred to as the ArchZeroDataVector. In response to the floating-point unit receiving an abort command that terminates a program or series of instructions, the Data0 array may be used to update the speculative and non-speculative Zbit arrays in the renamer 715. For example, the Data0 array may be OR'd into both the speculative and non-speculative ZBit arrays to set the ZBits for any full-zero registers. Additionally, the ArchZeroDataVector may be used to update the speculative and non-speculative freelist bit vectors in the data structure 725, e.g., by combining the ArchZeroDataVector with the speculative or non-speculative free list bit-vectors using an OR operation to mark any zero-data registers as free.
Some embodiments, which may be practiced in addition to or in place of other embodiments described herein, use the ZBit optimization to reclaim architectural registers when not in use. For example, the Zbit array in the data structure 730 is used to reclaim microcode temporary registers or registers that have been cached using techniques such as x87 register caching.
In microcode cases, the FPU 700 may implement eight temporary renamed registers (ftmp0-ftmp7) for use by complex instructions to store intermediate results. When microcode is not being executed, these registers are not defined to hold usable data, so holding entries for the ftmps in the physical register file is inefficient. In some embodiments, the unused ftmp registers are marked as unusable or “dead” when a microcode sequence is not executing and their physical registers are reclaimed by setting the ZBits in the renamer 715. The data values of the ftmps may not be all-zeros but the data value in the dead registers is inconsequential and so these registers may be added to the free list 710 without disrupting or interfering with normal operation of the floating-point unit 700. The free list 710 tracks the physical registers that are mapped to microcode ftmp registers using another 72-entry bit-vector in the data structure 725. This vector may be referred to as the ArchUcodeTmpVector. The ArchUcodeTmpVector may be used to update the speculative and non-speculative freelist bit vectors in the data structure 725, e.g., by combining the ArchUcodeTmpVector with the speculative or non-speculative free list bit-vectors using an OR operation to mark any zero-data registers as free.
Cached registers may be reclaimed by setting Zbits in the renamer 715 in some embodiments. The evolution of instruction set architectures implies that some earlier ISAs may be less commonly used. For example, some floating-point units may be optimized for SSE and AVX single-precision performance and x87 performance may be explicitly de-emphasized. Thus, the design of the floating-point unit 700 may assume that the eight registers that are reserved for x87 instructions may often be unused. In some embodiments, the FPU 700 loads values from a memory image into all of the FPU registers—including the x87 registers—during state-restore instructions such as FXRSTOR or XRSTOR or CC6 restore. Rather than restoring the x87 values to physical registers in the physical register file during the instruction sequence, microcode instead copies the x87 values from the memory image into internal scratch storage in the main processor data cache unit. In some embodiments, the floating-point unit 700 also sets the ZBits in the renamer 715 to indicate that the x87 architectural registers have not been allocated a physical register. The sequence then sets a status bit in an internal control register indicating that the x87 registers are unmapped, or “cached”. If an x87 instruction is detected while the x87 registers are cached, the main core takes a fault and vectors to a sequence which restores the x87 values from the scratch storage space back into the physical register file.
Some embodiments may implement combinations of the dispatch-time detection (e.g., as shown in
Embodiments of processor systems that can track or reclaim physical registers as described herein (such as the processor system 100) can be fabricated in semiconductor fabrication facilities according to various processor designs. In some embodiments, a processor design can be represented as code stored on a computer readable media. Exemplary codes that may be used to define and/or represent the processor design may include HDL, Verilog, and the like. The code may be written by engineers, synthesized by other processing devices, and used to generate an intermediate representation of the processor design, e.g., netlists, GDSII data and the like. The intermediate representation can be stored on computer readable media and used to configure and control a manufacturing/fabrication process that is performed in a semiconductor fabrication facility. The semiconductor fabrication facility may include processing tools for performing deposition, photolithography, etching, polishing/planarising, metrology, and other processes that are used to form transistors and other circuitry on semiconductor substrates. The processing tools can be configured and are operated using the intermediate representation, e.g., through the use of mask works generated from GDSII data.
Portions of the disclosed subject matter and corresponding detailed description are presented in terms of software, or algorithms and symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the ones by which those of ordinary skill in the art effectively convey the substance of their work to others of ordinary skill in the art. An algorithm, as the term is used here, and as it is used generally, is conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of optical, electrical, or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, or as is apparent from the discussion, terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical, electronic quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
Note also that the software implemented aspects of the disclosed subject matter are typically encoded on some form of program storage medium or implemented over some type of transmission medium. The program storage medium may be magnetic (e.g., a floppy disk or a hard drive) or optical (e.g., a compact disk read only memory, or “CD ROM”), and may be read only or random access. Similarly, the transmission medium may be twisted wire pairs, coaxial cable, optical fiber, or some other suitable transmission medium known to the art. The disclosed subject matter is not limited by these aspects of any given implementation.
Furthermore, some embodiments of the methods illustrated in
The particular embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. Furthermore, no limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.
This application is related to U.S. patent application Ser. No. 12/828,402, filed on Jul. 1, 2010, which is incorporated herein by reference in its entirety. This application is also related to U.S. patent application Ser. No. 12/900,124, filed Oct. 7, 2010, which is incorporated herein by reference in its entirety.
