Filtering micro-ops for a micro-op cache in a processor - Patent Application 20070122997

Abstract

The processor includes a micro-op cache having a plurality of micro-op cache entries for storing micro-ops decoded from instruction groups, and a micro-op filter having a plurality of micro-op filter table entries for storing identifiers of instruction groups that are predicted to be single-use if the micro-ops are stored in the micro-op cache. The micro-op filter receives the identifiers of the instruction groups. The micro-op filter then prevents copies of micro-ops from the first instruction group from being stored in the micro-op cache if the micro-op filter table entry includes an identifier that matches the first identifier.

Description

[Background technology]

[0001] (Related Technology) In some electronic devices, a processor executes program code instructions, or more simply, executes instructions, causing the processor to perform corresponding operations. For example, a processor such as a central processing unit (CPU) may execute instructions from a software application, an operating system, firmware, etc. Some processors can execute several different instructions, or "macro-instructions," that are decoded by the processor into one or more micro-operations. Each micro-operation is a simpler, lower-level processor instruction that, when executed by the processor, causes the processor to perform a respective portion of the overall operation of the instruction from which the micro-operation was decoded. For example, a single-instruction, multiple-data (SIMD) instruction may be decoded by the processor into several individual micro-operations to perform the operation of the SIMD instruction on multiple data.

[0002] When executing instructions in a processor, the operations of fetching the instructions to be executed from an instruction cache (or elsewhere in a memory subsystem) and decoding the fetched instructions into micro-ops for execution take a relatively long time and consume significant energy. Therefore, designers have proposed techniques to speed up the retrieval of micro-ops from instructions. One such technique uses a cache memory, called a micro-op cache, to store copies of the micro-ops decoded from the instructions. In this technique, the processor stores copies of the micro-ops in the micro-op cache while forwarding the micro-ops decoded from the instructions to the execution units in the processor for execution. When the processor again encounters an instruction that stores a copy of the micro-op in the micro-op cache, it can retrieve the micro-op from the micro-op cache instead of refetching and re-decoding the instruction. Due to the type of circuitry in the micro-op cache and the physical location of the micro-op cache (closer to the execution units), retrieving the micro-ops from the micro-op cache is significantly faster than refetching and re-decoding the instructions.

[0003] Although benefits can be obtained using a micro-op cache, it can be used inefficiently. Generally, a micro-op cache is a lower-capacity cache memory that can hold only a small subset of all micro-ops previously decoded from an instruction at any given time (note that the micro-ops into which an instruction is decoded may require more storage, per byte, than the instruction itself). Therefore, it is common for the micro-op cache to fill up with micro-ops. When the micro-op cache becomes full, for any subsequently decoded micro-op to be stored in the micro-op cache, existing micro-ops must be evicted from the micro-op cache to free up space for storing the subsequent decoded micro-op. Inefficiencies in the use of the micro-op cache can occur when micro-ops that are never accessed, i.e., "dead-on-fill" micro-ops, are stored in the micro-op cache. This inefficiency arises because useful micro-ops may be evicted from the micro-op cache to free up space in the micro-op cache for storing single-use micro-ops. If each instruction is to be executed again, it must be re-fetched and useful micro-operations must be re-decoded, which takes a relatively long time and consumes additional energy. Additionally, re-fetching and re-decoding each instruction causes unnecessary consumption of memory system bandwidth and decoding resources, as well as unnecessary consumption of power. [Brief explanation of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram illustrating an electronic device according to some embodiments. [Figure 2]FIG. 1 is a block diagram illustrating a processor, according to some embodiments. [Figure 3] FIG. 2 is a block diagram illustrating a micro-op filter and a micro-op cache, according to some embodiments. [Figure 4] FIG. 2 is a block diagram illustrating a micro-op cache entry, according to some embodiments. [Figure 5] FIG. 10 is a block diagram illustrating micro-op filter table entries, according to some embodiments. [Figure 6] FIG. 1 is a block diagram illustrating an eviction history table entry, according to some embodiments. [Figure 7] 10 is a flowchart illustrating a process for bypassing a micro-op, according to some embodiments. [Figure 8] 10 is a flowchart illustrating a process for updating entries in a micro-op filter table according to some embodiments. [Figure 9] 10 is a flowchart illustrating a process for invalidating information in entries in a micro-op filter table according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0005] The following description is presented to enable any person skilled in the art to make and use the described embodiments, and is provided in the context of a particular application and its requirements. Various modifications to the described embodiments will be readily apparent to those skilled in the art, and the general principles described herein may be applied to other embodiments and applications. Thus, the described embodiments are not limited to the embodiments shown, but are to be accorded the widest scope consistent with the principles and features described herein.

[0006] (term) In the following description, various terms are used to describe embodiments. Below are simplified general descriptions of some of these terms. It should be noted that these terms may have important additional aspects that are not listed here for clarity and brevity, and therefore the description is not intended to be limiting of these terms.

[0007] Functional Block: A functional block refers to a set of interrelated circuitry, such as an integrated circuit configuration, a discrete circuit configuration, etc. The circuitry is "interrelated" in that the circuit elements within the circuitry share at least one characteristic. For example, the circuitry may be contained in, fabricated on, or otherwise coupled to a particular integrated circuit chip, substrate, circuit board, or portion thereof, may be involved in performing a particular function (e.g., a computational or processing function, a memory function, etc.), may be controlled by a common control element and / or a common clock, etc. The circuitry of a functional block can have any number of circuit elements, from a single circuit element (e.g., a single integrated circuit logic gate or discrete circuit element) to millions or billions of circuit elements (e.g., an integrated circuit memory).

[0008] Instruction Group: Instructions may be fetched by the processor from an instruction cache memory or elsewhere in the memory subsystem in instruction groups that include one or more instructions to be processed in the processor (e.g., for decoding and execution). In other words, the processor may fetch instruction groups of N bytes or less in size from the memory subsystem, where N may be any size, such as 20 bytes, 64 bytes, 100 bytes, etc. For example, the processor may fetch half of the instructions in a cache line in the instruction cache memory as an instruction group. In some cases, each instruction group, and therefore one or more instructions therein, is associated with an identifier that is used by the processor to identify the instruction group. For example, some or all of the memory address of the first instruction in the instruction group may be used as the identifier of the instruction group.

[0009] (overview) In the described embodiment, the electronic device includes a processor (e.g., a central processing unit, a graphics processing unit, etc.) having processing circuitry for executing instructions based on program code. The processor also has a fetch unit including circuitry for fetching instruction groups from an instruction cache within the processor (or elsewhere within a memory subsystem), and a decode unit including circuitry for decoding instructions within the fetched instruction groups into micro-operations for execution by the processing circuitry. The processor additionally has a micro-operation cache including circuitry for storing copies of micro-operations used to later re-execute respective instruction groups without refetching and re-decoding the respective instruction groups. Furthermore, the processor has a micro-operation filter including circuitry for controlling which micro-operations are stored in the micro-operation cache, thereby "filtering" the micro-operations stored in the micro-operation cache.

[0010] In some embodiments, the micro-op filter maintains (or accesses) a record identifying instruction groups that are predicted not to be accessed if the micro-op is stored in the micro-op cache. Such micro-ops can be considered predicted to be "single-use" because, when stored (or "filled") in the micro-op cache, the micro-op is predicted to be "dead" and therefore will not be accessed. Based on the information in the record, the micro-op filter bypasses the predicted single-use micro-op. Bypassing a micro-op means that a copy of the micro-op is not stored in the micro-op cache because the micro-op is identified in the record as predicted to be single-use. In contrast, for micro-ops that are not identified in the record as predicted to be single-use, the micro-op filter stores a copy of the micro-op in the micro-op cache. Thus, the micro-op filter filters micro-ops from being stored in the micro-op cache by preventing predicted single-use micro-ops from being stored in the micro-op cache.

[0011] In some embodiments, the above-described records identifying instruction groups for which micro-ops are predicted to be single-use are maintained in a micro-op filter table. The micro-op filter table includes circuitry for several entries, each configured to store an identifier for an instruction group for which a micro-op is predicted to be single-use. During operation of the processor, when an identifier for an instruction group is generated (e.g., by a next program counter functional block in the processor), the micro-op filter determines whether any of the entries in the micro-op filter table includes an identifier that matches the generated identifier. If so, and therefore, if a micro-op from the respective instruction group is predicted to be single-use, the micro-op filter bypasses the micro-op as described above.

[0012] In some embodiments, identifiers of instruction groups for which micro-ops are predicted to be single-use are added to the micro-op filter table in a three-step process. In the first step of the process, the micro-op cache tracks whether a micro-op stored in a micro-op cache entry is accessed while stored in the micro-op cache. For example, the micro-op cache may use a separate access indicator for each micro-op cache entry to keep a record of whether a micro-op stored in that micro-op cache entry has been accessed.

[0013] In some embodiments, the second step in the process of adding an instruction group identifier to the micro-op filter table involves an eviction history table. The eviction history table includes circuitry for several entries, each configured to store an identifier for an instruction group whose micro-op was single-use in the micro-op cache. In the second step of the process, when a micro-op recorded as unaccessed is evicted from a micro-op cache entry, the micro-op cache notifies the micro-op filter that the micro-op was single-use. The micro-op filter then updates the eviction history table entry with the identifier for the instruction group for which the single-use micro-op was decoded. To update the eviction history table entry, if the instruction group identifier is not already stored in the eviction history table entry, the micro-op filter finds an available entry (which may mean evicting existing information from the entry), updates the available entry with the instruction group identifier, and sets the confidence counter of the available entry to an initial value. On the other hand, if the eviction history table already contains an eviction history table entry with the instruction group identifier, the micro-op filter increments the confidence counter of that entry. In this manner, the micro-op filter maintains a count in the confidence counter indicating how many times a micro-op from an instruction group was found to be single-use in the micro-op cache.

[0014] In some embodiments, in a third step in the process of adding instruction group identifiers to the micro-op filter table, the micro-op filter uses confidence counters from the eviction history table to determine which micro-ops are predicted to be single-use in the micro-op cache and adds the identifiers of the respective instruction groups to the micro-op filter table accordingly. For this operation, if incrementing the confidence counter of an eviction history table entry causes the confidence counter to exceed a threshold, thereby finding a micro-op of an instruction group whose identifier is stored in the eviction history table entry as single-use in the micro-op cache more than a specified number of times, the micro-op filter predicts that the micro-op will continue to be single-use in the micro-op cache. Therefore, the micro-op filter stores the instruction group identifier in an available micro-op filter table entry (which may mean evicting existing information from the micro-op filter table entry). By storing the instruction group identifier in the micro-op filter table entry, the micro-op filter records that the micro-op is predicted to be single-use in the micro-op cache.

[0015] In some embodiments, the micro-op filter includes a mechanism for ensuring that the information in the micro-op filter table does not become stale, thereby making it more likely to remain correct. The mechanism includes a local counter within each micro-op filter table entry or a local counter associated with each micro-op filter table entry. The micro-op filter sets the local counter to a specified local counter value when an identifier for an instruction group is stored in the micro-op filter table entry. The micro-op filter then decrements the local counter each time a micro-op from the instruction group is bypassed based on finding the identifier in the micro-op filter table entry. The micro-op filter then invalidates the micro-op filter table entry when the local counter reaches zero. Thus, the micro-op filter uses the information in an individual micro-op filter table entry a specified number of times before discarding the information from that micro-op filter table entry.

[0016] In some embodiments, the mechanism for ensuring that the information in the micro-op filter table is not outdated includes a global counter in the micro-op filter table or a global counter associated with the micro-op filter table. To use the global counter, the micro-op filter sets the global counter to zero if all micro-op filter table entries are invalid before storing the instruction group identifiers in the micro-op filter table entries. For example, the micro-op filter can set the global counter to zero at startup or after the micro-op filter table entries are invalidated or reset. The micro-op filter then increments the global counter each time a micro-op from any instruction group is bypassed based on the identifier found in the respective micro-op filter table entry. The micro-op filter then invalidates all of the micro-op filter table entries when the value of the global counter exceeds a reset threshold. Thus, the micro-op filter uses the information in all of the micro-op filter table entries as a group a specified number of times before discarding the information in all of the micro-op filter table entries as a group.

[0017] By bypassing micro-operations as described above, the described embodiments avoid storing micro-operations predicted to be single-use in the micro-operation cache. Avoiding storing single-use micro-operations in the micro-operation cache can improve the operation of the micro-operation cache by not causing useful micro-operations to be evicted from the micro-operation cache to free up space for storing single-use micro-operations. Because useful micro-operations remain in the micro-operation cache, the processor can more quickly obtain useful micro-operations for re-execution (as opposed to refetching and re-decoding instructions from each instruction group). Also, because useful micro-operations remain in the micro-operation cache, power and resource consumption associated with refetching and re-decoding instruction groups for evicted useful micro-operations can be reduced. Additionally, because useful micro-operations remain in the micro-operation cache, reducing refetching of instruction groups, the memory subsystem within the processor can operate more efficiently. Improved operation of the micro-operation cache, memory subsystem, and fetch and decode units can contribute to improved operation of the processor and electronic device, leading to increased user satisfaction.

[0018] (Electronic Devices) FIG. 1 is a block diagram illustrating an electronic device 100, according to some embodiments. As can be seen in FIG. 1, the electronic device 100 includes a processor 102 and a memory 104. Generally, the processor 102 and the memory 104 are implemented using hardware, i.e., circuitry. For example, the circuitry for the processor 102 and the memory 104 may be fabricated entirely on one or more semiconductor chips, including one or more separate semiconductor chips, fabricated from one or more semiconductor chips in combination with discrete circuit elements, or fabricated solely from discrete circuit elements. As described herein, the processor 102 and the memory 104 perform operations to bypass predicted single-use micro-operations against a micro-operation cache.

[0019] Processor 102 is a functional block that performs operations related to executing instructions from program code, such as instructions from a software application, firmware, operating system, script, etc., as well as other operations (e.g., control, memory access, input / output, etc.) Processor 102 includes one or more central processing unit (CPU) cores, graphics processing unit (GPU) cores, embedded processors, application specific integrated circuits (ASICs), and / or other functional blocks that execute instructions from program code and / or perform other operations.

[0020] Memory 104 is a functional block that performs memory (e.g., "main" memory) operations within electronic device 100. Memory 104 includes memory circuitry for storing instructions, information, and data for access by the functional blocks within electronic device 100, and control circuitry for handling accesses of data within the memory circuitry. The memory circuitry within memory 104 includes volatile memory circuitry, such as double data rate synchronous dynamic random access memory (DDR SDRAM), static random access memory (SRAM), and / or other types of memory circuitry. In some embodiments, memory 104 is coupled to a non-volatile mass storage device (e.g., a disk drive or solid-state drive) (not shown) that serves as long-term storage of instructions and / or data.

[0021] Electronic device 100 is shown for purposes of illustration as including a particular number and configuration of elements (i.e., processor 102 and memory 104). However, in some embodiments, a different number or configuration of elements is present in electronic device 100. For example, electronic device 100 may include a power subsystem, a networking subsystem, a human interface system, etc. In general, electronic device 100 includes sufficient elements to perform the operations described herein.

[0022] Electronic device 100 may be or may be included in any electronic device that performs operations to carry out the instructions described herein. For example, electronic device 100 may be or may be included in an electronic device such as a desktop computer, a laptop computer, a wearable electronic device, a tablet computer, a smartphone, a server, an artificial intelligence device, a virtual or augmented reality device, a network device, a toy, an audiovisual device, a home appliance, a controller, a vehicle, etc., and / or combinations thereof.

[0023] (Processor) As described above, electronic device 100 includes processor 102. Figure 2 is a block diagram illustrating processor 102, according to some embodiments. As shown in Figure 2, functional blocks within processor 102 can be considered part of a front-end subsystem 200, a back-end subsystem 202, or a memory subsystem 204. In general, front-end subsystem 200 includes functional blocks that perform operations to retrieve instructions from memory subsystem 204 and generate micro-operations from the instructions that are sent to execution units in back-end subsystem 202 for execution.

[0024] Front-end subsystem 200 includes instruction fetch / decode 206, which is a functional block containing circuitry that performs operations associated with fetching instructions and decoding the fetched instructions into micro-operations in preparation for execution of the micro-operations. Instruction fetch / decode 206 fetches (i.e., requests and receives) instruction groups of instructions from L1 instruction cache 208, L2 cache 210, or memory 104, as needed. Instruction fetch / decode 206 then decodes the instructions in the fetched instruction group into respective micro-operations. Instruction fetch / decode 206 forwards micro-operations to micro-operation (UOP) queue 212, which is a functional block containing circuitry for controlling when and how micro-operations are provided from front-end subsystem 200 to back-end subsystem 202. From the micro-op queue 212, the micro-ops are ultimately provided to dispatch 214, which is a functional block containing circuitry for steering or directing the micro-ops to the appropriate execution units within the back-end subsystem 202 for execution.

[0025] Front-end subsystem 200 also includes next PC (NPC) 216, which is a functional block containing circuitry that performs operations to determine the address in memory for the next group of instructions to be fetched from L1 instruction cache 208 for execution, i.e., the "program counter." Next PC 216 calculates the next sequential value of the program counter based on the initial or current value of the program counter. For example, given a 32-byte instruction group, next PC 216 may calculate: next address = current address + 32 bytes. If the program / instruction flow is not altered by a control transfer instruction (e.g., a branch instruction), front-end subsystem 200 uses the sequential value of the program counter calculated by next PC 216 to fetch instruction groups from corresponding sequential addresses in memory.

[0026] Front-end subsystem 200 additionally includes branch prediction unit (BPU) 218, which is a functional block containing circuitry that performs operations to predict the resolution of control transfer instructions (e.g., branches, etc.) within an instruction group and to modify the program counter and, therefore, the address in memory from which a subsequent instruction group is fetched. In other words, branch prediction unit 218 uses one or more records of control transfer instruction behavior to predict a "taken" or "not taken" resolution of the control transfer instruction and provides a predicted target address for a taken control transfer instruction. If the control transfer instruction is predicted as taken by branch prediction unit 218, branch prediction unit 218 may replace the next or subsequent program counter provided by next PC 216 with the target address for the control transfer instruction.

[0027] Front-end subsystem 200 further includes micro-op (UOP) cache 220, which is a functional block containing circuitry used to store copies of previously decoded micro-ops that are used to later re-dispatch and execute each instruction group without having to fetch and decode the instruction group again. When instructions in an instruction group are decoded into micro-ops by instruction fetch / decode 206, copies of the micro-ops can be stored in micro-op cache 220. The copies of the micro-ops stored in micro-op cache 220 can then be used to quickly retrieve the micro-ops during subsequent re-execution of the instruction group. More specifically, when next PC 216 provides an address for the next instruction group to be fetched and executed, micro-op cache 220 receives the address and determines whether copies of the micro-ops for the instruction group are stored in micro-op cache 220. If so, micro-op cache 220 forwards the copies of the micro-ops to micro-op queue 212, from which the micro-ops are provided to dispatch 214 and back-end subsystem 202 for execution. Additionally, micro-op cache 220 can send an indication to instruction fetch / decode 206 that the micro-ops were provided by micro-op cache 220, and therefore instruction fetch / decode 206 does not need to fetch and decode the instructions in the instruction group, and therefore instruction fetch / decode 206 can finish fetching and / or decoding the instruction group.

[0028] Front-end subsystem 200 further includes micro-op filter 222, which is a functional block containing circuitry that performs operations to control which micro-ops are stored in micro-op cache 220. Micro-op filter 222 uses records that identify instruction groups that are predicted to not be accessed if stored in micro-op cache 220 to determine which micro-ops are bypassed (and therefore not stored in micro-op cache 220). Micro-op filter 222 and the records used by it are described in more detail below.

[0029] Back-end subsystem 202 includes integer execution unit 224 and floating-point execution unit 226, which are functional blocks containing circuitry that executes operations to execute integer and floating-point micro-operations, respectively. Integer execution unit 224 and floating-point execution unit 226 include elements used to execute micro-operations or perform other operations, such as renaming hardware, an execution scheduler, an arithmetic logic unit (ALU), a floating-point multiply and add unit (within floating-point execution unit 226), a register file, etc. Micro-operations are steered or directed from dispatch 214 to integer execution unit 224 or floating-point execution unit 226 based on the data type of the micro-operation, the execution unit resources used to execute the micro-operation, etc.

[0030] Memory subsystem 204 includes a hierarchy of cache memories, including circuitry that performs operations to store copies of instructions and / or data closer to the functional blocks that use the instructions and / or data (than memory 104), as well as control circuitry for handling accesses of the instructions and / or data. The hierarchy includes two levels, with a level 1 (L1) instruction cache 208 and an L1 data cache 228 at the first level and an L2 cache 210 at the second level. Memory subsystem 204 is communicatively coupled to memory 104 and may also be coupled to an external L3 cache (not shown).

[0031] 2, a particular configuration, connectivity, and number of elements is shown in processor 102, but in some embodiments, a different configuration, connectivity, and / or number of elements is present in processor 102. In general, processor 102 includes sufficient elements to perform the operations described herein.

[0032] (micro-op filter and micro-op cache) In the described embodiment, the micro-op filter performs operations to control whether a copy of a micro-op is bypassed or stored in the micro-op cache. Figure 3 is a block diagram illustrating the micro-op filter 222 and the micro-op cache 220, according to some embodiments. While a particular configuration of functional blocks is shown in Figure 3 and operations are described as being performed by corresponding functional blocks, it should be noted that some embodiments use a different configuration of functional blocks and / or some or all of the operations are performed by different functional blocks. In general, the described embodiments include sufficient functional blocks to perform the operations described herein.

[0033] In describing the functional blocks shown in Figures 3-6 and elsewhere in this description, micro-operations are described as "single-use." Generally, single-use micro-operations are micro-operations that are stored or "filled" into the micro-operation cache but are not accessed before being evicted from the micro-operation cache, and are therefore considered "disabled" with respect to their usefulness while stored in the micro-operation cache. In other words, while a single-use micro-operation resides in the micro-operation cache, the instruction group for which the single-use micro-operation was decoded is not re-executed, and therefore, no request is made to the micro-operation cache to obtain the single-use micro-operation. Lack of re-execution of an instruction group can occur, for example, when an instruction group is executed consecutively, when a subroutine in program code is executed only once, etc.

[0034] 3, as described above, instruction fetch / decode 206 fetches instructions and performs operations associated with decoding the fetched instructions. More specifically, instruction fetch / decode 206 fetches instructions within an instruction group (which may be referred to as macroinstructions, compound instructions, etc.) and decodes each instruction into one or more micro-operations. Each micro-operation is a low-level processor instruction that, when executed by an execution unit, causes the execution unit to perform a respective portion of the overall operation of the instruction into which the micro-operation was decoded. For example, a single RepMov instruction may be decoded by instruction fetch / decode 206 into multiple individual micro-operations for performing the move operations indicated by the RepMov instruction on individual data elements.

[0035] During operation, instruction fetch / decode 206 receives an instruction group identifier 300 from another functional block in processor 102 (e.g., next PC 216). Instruction fetch / decode 206 then fetches the corresponding instruction group from L1 instruction cache 208, L2 cache 210, or memory 104, as needed. Instruction fetch / decode 206 then decodes the instructions in the instruction group into one or more micro-operations 302 and provides the micro-operations 302 to micro-operation queue 212. From micro-operation queue 212, the micro-operations 302 are supplied to back-end subsystem 202 for execution via dispatch 214.

[0036] The micro-op cache 220 stores copies of micro-ops, as described above. The micro-op cache 220 includes several micro-op cache entries 304 (only some of which are labeled for clarity), each of which includes circuitry for storing a copy of a micro-op and its associated metadata. FIG. 4 is a block diagram illustrating a micro-op cache entry 304, according to some embodiments. Note that while the micro-op cache entries 304 are illustrated in FIG. 4 as containing particular values, in some embodiments, the micro-op cache entries 304 contain different values. For example, in some embodiments, each micro-op cache entry 304 includes only a micro-op 402, with the identifier 400, accessed bit (AB) 404, and metadata (MD) 406 stored elsewhere (e.g., in a separate tag array within the micro-op cache 220). In general, the micro-op cache 220 contains sufficient values ​​to perform the operations described herein.

[0037] As can be seen in FIG. 4 , micro-op cache entry 304 includes identifier 400, micro-op 402, access bit 404, and metadata 406. Identifier 400 is used to store an identifier of an instruction group for which a micro-op is stored in micro-op cache entry 304, or an identifier associated with the instruction group. For example, in some embodiments, identifier 400 includes some or all of the address in memory of the instruction group or a value generated based thereon. Micro-op 402 is used to store micro-ops decoded from the instruction group. Because an instruction group can decode a variable number of micro-ops, micro-op 402 has the capacity to store up to M micro-ops. Access bit 404 is used to store an indicator of whether micro-op 402 has been accessed. In some embodiments, access bit 404 is a single bit that is cleared (e.g., set to 0) when micro-op 402 is stored in micro-op cache entry 304 and set (e.g., to 1) when micro-op 402 is subsequently accessed. Metadata 406 is used to store metadata for micro-op cache entry 304, such as validity information, a thread identifier, etc.

[0038] In some embodiments, micro-op cache 220 is configured as associatively, e.g., using set associativity or another form of associativity. Because micro-op cache 220 is configured as associatively, each micro-op cache entry 304 can be used to store micro-ops decoded from instruction groups from within a range or portion of different instruction groups (e.g., instruction groups located at two or more memory addresses). In other words, a given micro-op cache entry 304 is not limited to storing micro-ops for a single instruction group. During replacement in micro-op cache 220, all micro-ops stored in a given micro-op cache entry 304 can be evicted, freeing the given micro-op cache entry 304 to store micro-ops decoded from another instruction group. In some embodiments, micro-op cache entries 304 are evicted or otherwise processed according to a rule or policy, such as least-recently-used (LRU), least-used, etc.

[0039] 3, micro-op cache 220 includes a controller 306, which includes circuitry for controlling the operation of micro-op cache 220. For example, controller 306 can perform operations to store micro-ops and associated metadata in respective micro-op cache entries 304, select a micro-op cache entry 304 to free up space for storing an incoming micro-op, search a micro-op cache entry 304 to determine whether a micro-op decoded from a given instruction group is currently stored in the micro-op cache entry 304, retrieve a micro-op from a micro-op cache entry 304 and provide it (e.g., to micro-op queue 212), etc.

[0040] As described above, when performing an operation to store a micro-op and associated metadata in a micro-op cache entry 304, the control unit 306 receives micro-op information 308 from the micro-op filter 222, which includes the micro-op and metadata, such as an identifier of the instruction group from which the micro-op was decoded (e.g., part or all of a memory address), a thread identifier, etc. The control unit 306 then finds or frees an available micro-op cache entry 304 and stores the micro-op and metadata in the available micro-op cache entry 304. On the other hand, when performing an operation to retrieve and provide a micro-op from a micro-op cache entry 304, the control unit 306 receives an instruction group identifier 300 from another functional block within the processor 102 (e.g., the next PC 216), searches the micro-op cache entries 304 for a matching identifier, and, if a micro-op cache entry 304 storing a matching identifier is found, provides the micro-op 310 to the micro-op queue 212. From the micro-op queue 212, the micro-op 310 is provided to the back-end subsystem 202 for execution via the dispatch 214.

[0041] In some embodiments, as part of the operation to obtain and provide micro-ops 310 for the instruction group to micro-op queue 212, control unit 306 (or another functional block) notifies instruction fetch / decode 206, e.g., via hit / miss 326, that the micro-ops for the instruction group were found in micro-op cache entry 304 (and thus there is a "hit" in micro-op cache 220). Instruction fetch / decode 206 then completes the operation to fetch and / or decode the instruction group. For example, instruction fetch / decode 206 can stall or hold a fetch request for the instruction group while control unit 306 searches micro-op cache entry 304 for a matching identifier, and if control unit 306 finds a match, discards the stalled or held fetch request. As another example, instruction fetch / decode 206 can send a fetch request for the instruction group while control unit 306 searches micro-op cache entry 304 for a matching identifier, but if control unit 306 finds a match, ignores or discards the fetched instruction group, and therefore does not decode it. On the other hand, if the micro-op for the instruction group is not found in micro-op cache entry 304 (thus there is a "miss" in micro-op cache 220), control unit 306 notifies instruction fetch / decode 206, e.g., via hit / miss 326, that the micro-op is not stored in micro-op cache 220, and instruction fetch / decode 206 continues fetching and decoding the instruction group.

[0042] The control unit 306 also performs operations to notify the micro-op filter 222 when a micro-op that was not accessed while stored in the micro-op cache is evicted from the micro-op cache entry 304. In other words, upon evicting a single-use micro-op from the micro-op cache entry 304, the control unit 306 communicates single-use information 312 to the micro-op filter 222, the single-use information 312 including at least an identifier of the instruction group for which the evicted micro-op was decoded. The micro-op filter 222 then processes the received single-use information 312 as described below.

[0043] The micro-op filter 222, as described above, controls which micro-ops are stored in the micro-op cache 220. The micro-op filter 222 includes a micro-op filter table 314 for storing information used to control which micro-ops are stored in the micro-op cache 220. The micro-op filter table 314 includes several micro-op filter table entries 316 (only some of which are labeled for clarity), each of which includes circuitry for storing information about instruction groups predicted to be single-use, the information being used to bypass the corresponding micro-op (i.e., prevent the corresponding micro-op from being stored in the micro-op cache 220). FIG. 5 is a block diagram illustrating a micro-op filter table entry 316, according to some embodiments. While the micro-op filter table entry 316 is illustrated in FIG. 5 as including a particular configuration of values, it should be noted that in some embodiments, the micro-op filter table entry 316 includes different values. In general, each micro-op filter table entry 316 includes sufficient values ​​to perform the operations described herein.

[0044] 5, the micro-op filter table entry 316 includes an identifier 500, a local counter (LC) 502, and metadata (MD) 504. The identifier 500 is used to store an identifier for or associated with an instruction group for which the micro-op is predicted to be single-use in the micro-op cache 220. For example, in some embodiments, the identifier 500 includes some or all of the address in memory of the instruction group. The local counter 502 is used to store a counter for the micro-op filter table entry 316. The local counter 502 is used to control how many times information from the micro-op filter table entry 316 is used to bypass the micro-op before it is discarded as stale and therefore unlikely to be correct. The metadata 504 is used to store metadata for the micro-op filter table entry 316, such as validity information, a thread identifier, and other information.

[0045] 3, the micro-op filter table 314 includes a global counter 318. The global counter 318 is used to store global counters associated with the micro-op filter table entries 316. The global counter 318 is used to control how many times the information from all of the micro-op filter table entries 316 as a group is used before the information from all of the micro-op filter table entries 316 as a group is discarded as stale and therefore unlikely to be correct.

[0046] The micro-op filter 222 also includes an eviction history table 320 for storing information used to determine which instruction groups are added to the micro-op filter table 314. The eviction history table 320 includes eviction history table entries 322 (only some of which are labeled for clarity), each of which stores an identifier for an instruction group whose micro-op was single-use in the micro-op cache 220, and includes circuitry for storing a counter used to determine which instruction groups are added to the micro-op filter table 314. FIG. 6 is a block diagram illustrating an eviction history table entry 322, according to some embodiments. While the eviction history table entry 322 is illustrated in FIG. 6 as including a particular configuration of values, it should be noted that in some embodiments, the eviction history table entry 322 includes different values. In general, each eviction history table entry 322 includes sufficient values ​​to perform the operations described herein.

[0047] 6 , eviction history table entry 322 includes an identifier 600, a confidence counter (CC) 602, and metadata (MD) 604. Identifier 600 is used to store an identifier for or associated with an instruction group whose micro-ops were single-use in micro-op cache 220. For example, in some embodiments, identifier 600 includes a tag or other value generated from or based on some or all of the address in memory of the instruction group. Confidence counter 602 is used to store a counter that maintains a count of the number of times a micro-op decoded from the instruction group identified by identifier 600 was single-use in micro-op cache 220. Metadata 604 is used to store metadata for eviction history table entry 322, such as validity information, a thread identifier, and other information.

[0048] In some embodiments, the eviction history table 320 is configured associatively, e.g., using set associativity or another form of associativity. Because the eviction history table 320 is configured associatively, each eviction history table entry 322 may be used to store identifiers for single-use instruction groups from within a range or portion of different instruction groups (e.g., instruction groups located at two or more different memory addresses). In other words, a given eviction history table entry 322 is not limited to storing identifiers for a single instruction group. During replacement in the eviction history table 320, the existing identifier for a single-use instruction group stored in a given eviction history table entry 322 may be evicted, freeing the given eviction history table entry 322 to store the identifier for another single-use instruction group. In some embodiments, the eviction history table entries 322 are evicted or otherwise processed according to a rule or policy, such as least recently used (LRU), least recently used, etc. In some embodiments, the associativity, e.g., arrangement and sets, for the eviction history table 320 is similar to that used for the micro-op cache 220, which can be useful when storing single-use information 312 from the micro-op cache 220 in the eviction history table 320.

[0049] 3, the micro-op filter 222 includes a controller 324, which includes circuitry for controlling / managing the operation of the micro-op filter 222. For example, the controller 324 can perform operations to receive single-use information 312 from the micro-op cache 220, update the eviction history table 320 based on the single-use information 312, update the micro-op filter table 314 based on the information from the eviction history table 320 and use it to bypass micro-ops for instruction groups based on the information in the micro-op filter table 314, update a local counter 502 in a micro-op filter table entry 316 and use the local counter 502 to invalidate the information in the corresponding micro-op filter table entry 316, and update a global counter 318 and use the global counter 318 to invalidate the information in the micro-op filter table entry 316.

[0050] In some embodiments, based on the information from the eviction history table 320 and using it to update the micro-op filter table 314 as described above, the controller 324 performs several operations. In other words, the controller 324's process of adding identifiers of instruction groups for which micro-ops are predicted to be single-use to the micro-op filter table 314 is a multi-step process. In a first step, the micro-op cache 220 provides the controller 324 with single-use information 312 for given instruction groups for which micro-ops were found to be single-use in the micro-op cache 220. In a second step, the controller 324 uses the received single-use information 312 to update the eviction history table entry 322 with the identifier of the given instruction group. Updating the eviction history table entry 322 can mean updating an existing eviction history table entry 322 or adding new information to an available eviction history table entry 322. In either case, the updating includes updating the confidence counter 602 of the eviction history table entry 322 to indicate the number of times that a micro-op decoded from the instruction group was found to be single-use in the micro-op cache 220. In a third step, if updating the confidence counter 602 of the eviction history table entry 322 causes the confidence counter 602 to exceed a threshold, the control unit 324 adds information about the instruction group to the micro-op filter table entry 316. As described in more detail below, the information in the micro-op filter table entry 316 is used to bypass micro-ops. Thus, by adding the information to the micro-op filter table entry 316, the control unit 324 configures itself to bypass future instances of the micro-op decoded from the instruction group.Essentially, based on the micro-op having previously been single-use a specified number of times in the micro-op cache 220 (as counted in the eviction history table entry 322), the control unit 324 makes a prediction that the micro-op will remain single-use in the micro-op cache 220 for future instances of the instruction group.

[0051] In some embodiments, when bypassing a micro-op for an instruction group based on information in the micro-op filter table 314, the controller 324 receives micro-op information 308 for a given instruction group from the instruction fetch / decode 206. The controller 324 then searches the micro-op filter table 314 for a match between the identifier 500 in the micro-op filter table entry 316 and the identifier for the given instruction group based on the micro-op information 308. If a match is found, the controller 324 bypasses the micro-op by preventing a copy of the micro-op from being stored in the micro-op cache entry 304, i.e., by discarding or ignoring the micro-op received from the instruction fetch / decode 206. On the other hand, if no match is found, the controller 324 does not bypass the micro-op. In this case, the controller 324 provides the micro-op information 308 to the micro-op cache 220, which stores a copy of the micro-op, an instruction group identifier, and possibly metadata from the micro-op information 308 in an available micro-op cache entry 304 (which may mean evicting existing information from the micro-op cache entry 304). Note that regardless of the outcome of the controller 324 lookup and bypass operation, the instruction fetch / decode 206 forwards the micro-op 302 to the micro-op queue 212 in preparation for dispatch to the back-end subsystem 202 for execution.

[0052] In some embodiments, to use the local counter 502 to invalidate information in the corresponding micro-op filter table entry 316, when the controller 324 initially stores an instruction group identifier (and possibly other information) in a given micro-op filter table entry 316, the controller 324 sets the local counter 502 of the given micro-op filter table entry 316 to a specified local counter value (e.g., 5, 10, or another value). The controller 324 then decrements the local counter 502 of the given micro-op filter table entry 316 each time a micro-op is bypassed because the instruction group identifier was found in the given micro-op filter table entry 316. The controller 324 then invalidates the given micro-op filter table entry 316 when the local counter reaches zero, rendering the information stored therein unusable. For example, to invalidate a given micro-op filter table entry 316, the controller 324 may set a valid bit in the metadata 504 of the given micro-op filter table entry 316 to indicate that the given micro-op filter table entry 316 is not currently valid. By setting, decrementing, and ultimately invalidating a given micro-op filter table entry 316's local counter 502 based on the value of the local counter 502, the control unit 324 limits the number of times information from a given micro-op filter table entry 316 is used to bypass a micro-op, which can help prevent stale information from being used to (possibly incorrectly) bypass a micro-op.

[0053] In some embodiments, to use the global counter 318 to invalidate information in the micro-op filter table entries 316, the controller 324 initially sets the global counter 318 to zero. For example, the controller 324 may set the global counter 318 to zero at startup, such as after all of the micro-op filter table entries 316 have been invalidated. The controller 324 then increments the global counter 318 each time a micro-op is bypassed because an instruction group identifier is found in any micro-op filter table entry 316. The controller 324 then invalidates all of the micro-op filter table entries 316 when the global counter exceeds a reset threshold (e.g., 40, 55, or another value). For example, to invalidate all of the micro-op filter table entries 316, the controller 324 may set a valid bit in the metadata 504 of each of the micro-op filter table entries 316 to indicate that the micro-op filter table entry 316 is not currently valid. By setting and incrementing the global counter 318 and eventually invalidating all of the micro-op filter table entries 316 based on the value of the global counter 318, the control unit 324 limits the number of times information from the entire micro-op filter table 314 is used to bypass a micro-op, which can help prevent stale information from being used to bypass a micro-op.

[0054] (Predictions and Mispredictions) In the described embodiment, a micro-op filter (e.g., micro-op filter 222) predicts whether subsequent instances of micro-ops in an instruction group will be single-use in the micro-op cache (e.g., micro-op cache 220) based on information about micro-ops in the instruction group that are single-use in the micro-op cache. The micro-op filter makes the "prediction" by adding an identifier for the instruction group to a micro-op filter table, from which the identifier is used to bypass subsequent micro-ops decoded from the instruction group. The prediction made by the micro-op filter is an assumption / guessment about future micro-op access behavior based on previous micro-op access behavior. It is possible that the prediction is inaccurate, and thus a micro-op predicted to be single-use is accessed in the micro-op cache. However, if the actual behavior differs from the predicted behavior, the micro-op cache and the processor's operation are correct, albeit with a performance penalty for refetching and re-decoding the bypassed micro-ops (and therefore not stored and available in the micro-op cache).

[0055] In some embodiments, the thresholds and values ​​of the trusted counter, local counter, and / or global counter are set to values ​​that aid in usefully bypassing single-use micro-ops while also avoiding mispredictions of single-use micro-ops. For example, the local counter and / or the thresholds for the local counter and / or global counter can be set to respective values ​​such that useful entries are retained in the micro-op filter table for a reasonable amount of time, but older / stale entries are removed from the micro-op filter table before the likelihood of mispredictions becomes unacceptably high. The respective values ​​of the trusted counter, local counter, and / or global counter can be experimentally determined, calculated, estimated, or otherwise generated.

[0056] (Process for handling micro-operations) In the described embodiment, a micro-op filter (e.g., micro-op filter 222) performs operations to bypass micro-ops received from an instruction fetch / decode unit (e.g., instruction fetch / decode 206), and therefore does not store a copy of the micro-op in a micro-op cache (e.g., micro-op cache 220). FIG. 7 is a flowchart illustrating a process for bypassing a micro-op, according to some embodiments. Note that the operations illustrated in FIG. 7 are presented as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0057] 7 begins when the micro-op filter receives a micro-op decoded from an instruction group from the instruction fetch / decode unit (step 700). For this operation, the instruction fetch / decode unit fetches the instruction group from an L1 instruction cache (e.g., L1 instruction cache 208) or elsewhere in the memory subsystem (e.g., memory subsystem 204) based on an instruction group identifier received from a next program counter functional block (e.g., next PC 216) or another entity. The instruction fetch / decode unit then decodes the instructions in the instruction group into micro-ops. The instruction fetch / decode unit sends micro-op information (e.g., micro-op information 308) to the micro-op filter along with forwarding the micro-ops to a back-end subsystem (e.g., back-end subsystem 202) for execution.

[0058] The micro-op filter then determines whether a micro-op filter table entry (e.g., one of micro-op filter table entries 316) contains a matching identifier (step 702). To do this, the micro-op filter obtains the instruction group identifier from the received micro-op information. The micro-op filter then compares the identifier from the instruction group with the identifiers in any valid micro-op filter table entries to determine whether there is a micro-op filter table entry containing a matching identifier.

[0059] If the micro-op filter table entry contains a matching identifier (step 702), the micro-op filter bypasses the micro-op from the instruction group (step 704). For this operation, the micro-op filter determines that the micro-op is predicted to be single-use based on the presence of a matching identifier in the micro-op filter table entry. The micro-op filter then discards (e.g., deletes, ignores, etc.) the micro-op information and does not store a copy of the micro-op information in the micro-op cache. In contrast, if the micro-op filter table does not contain a matching identifier (step 702), the micro-op filter stores a copy of the micro-op from the instruction group in the micro-op cache (step 706). For this operation, the micro-op filter determines that the micro-op is not predicted to be single-use because a micro-op filter table entry with a matching identifier is not found in the micro-op filter table. The micro-op filter then causes the micro-op cache to store a copy of the micro-op information in the micro-op cache entry.

[0060] (The process for updating entries in the micro-op filter table) In the described embodiment, a micro-op filter (e.g., micro-op filter 222) performs operations to update entries in a micro-op filter table (e.g., micro-op filter table 314) used to bypass micro-ops. FIG. 8 is a flowchart illustrating a process for updating entries in a micro-op filter table, according to some embodiments. Note that the operations illustrated in FIG. 8 are presented as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0061] The operations of FIG. 8 begin when a micro-op decoded from an instruction group is stored in a micro-op cache entry in the micro-op cache (step 800). For this operation, micro-op information (e.g., micro-op information 308) is received by the micro-op cache (e.g., micro-op cache 220) from a micro-op filter. The micro-op cache then stores the micro-op in an available micro-op cache entry (e.g., micro-op cache entry 304). In some embodiments, this may mean evicting an existing micro-op from a micro-op cache entry to free up an available micro-op cache entry. Note that step 800 is an example of a micro-op that is not bypassed by the micro-op filter, as described above for steps 702-704, but instead is stored in the micro-op cache, as described above for steps 702 and 706.

[0062] The micro-op is then evicted from the micro-op cache entry (step 802). This operation allows the micro-op cache to evict a micro-op to store a micro-op from another instruction group or to free up the micro-op cache entry for another reason. Upon evicting the micro-op from the micro-op cache entry, the micro-op cache determines, for example, using access bits (e.g., access bits 404), that the micro-op was not accessed while stored in the micro-op cache entry and was therefore single-use. The micro-op cache therefore communicates single-use information (e.g., single-use information 312) to the micro-op filter to inform the micro-op filter that the micro-op is single-use.

[0063] The micro-op filter then determines, based on the single-use information received from the micro-op cache, that the micro-op was not accessed while stored in the micro-op cache entry (step 804). If the micro-op filter determines that the micro-op was single-use, it updates the eviction history table entry (e.g., eviction history table entry 322) with the instruction group's identifier and / or updates the confidence counter of the eviction history table entry that stores the instruction group's identifier (step 806). For this operation, if the eviction history table entry already contains the instruction group's identifier and therefore the micro-ops for the instruction group were earlier known to be single-use at least once in the micro-op cache, the micro-op filter simply updates (e.g., increments, increases, etc.) the confidence counter of that eviction history table entry. On the other hand, if there is no eviction history table entry containing the instruction group's identifier, the micro-op filter finds an available eviction history table entry, adds the identifier to the available eviction history table entry, and sets the eviction history table's confidence counter to an initial value (e.g., 1). In some embodiments, finding an available eviction history table entry means evicting existing information from the eviction history table entry to free up an available eviction history table entry.

[0064] If updating the reliability counter of the eviction history table entry does not cause the eviction history table entry to exceed the threshold (step 808), the micro-op filter continues operation without making any changes to the micro-op filter table. Conversely, if updating the reliability counter of the eviction history table entry causes the eviction history table entry to exceed the threshold (step 808), the micro-op filter stores the instruction group's identifier in an available micro-op filter table entry (step 810). Because of this operation, the micro-op filter updates the entry in the micro-op filter table when a sufficient number of instances of the micro-op are found to be single-use in the micro-op cache, thus causing the micro-op filter to update the reliability counter of the eviction history table entry, as in step 806. As described above, because the micro-op filter table entry is used to bypass micro-ops of the instruction group, this operation predicts that future instances of the micro-op will be single-use in the micro-op cache.

[0065] (Process for invalidating micro-op filter table entries) In the described embodiment, a micro-op filter (e.g., micro-op filter 222) performs operations to invalidate information in micro-op filter table entries (e.g., micro-op filter table entry 316) to remove stale information from the micro-op filter table. FIG. 9 is a flowchart illustrating a process for invalidating information in entries in a micro-op filter table, according to some embodiments. Note that the operations illustrated in FIG. 9 are presented as general examples of operations performed by some embodiments. Operations performed by other embodiments include different operations, operations performed in a different order, and / or operations performed by different entities or functional blocks.

[0066] 9 assumes that an entry in the micro-op filter table has instruction group information (e.g., identifier 500 and metadata 504) stored therein. For example, the operations of FIG. 8, including step 810, may have been performed at some point in the past. Also, the micro-op filter table entry's local counter (e.g., local counter 502) was set to an initial value when the instruction group information was stored therein. Additionally, the global counter was previously reset / set to zero if all of the entries in the micro-op filter table were invalid, such as at startup or after all micro-op filter table entries had previously been invalidated.

[0067] 9 begins when a micro-op filter bypasses a micro-op from an instruction group based on information in a micro-op filter table entry (step 900). To do this, the micro-op filter performs operations similar to those shown in steps 700-704 of FIG. 7, such that the micro-op is not stored in an entry in a micro-op cache (e.g., micro-op cache 220), but instead is ignored or discarded by the micro-op filter.

[0068] Because the information in the micro-op filter table entry was used to bypass a micro-op, the micro-op filter decrements the micro-op filter table entry's local counter (e.g., local counter 502) (step 902). For this action, the micro-op filter decrements the entry's local counter, which tracks how many times the entry was used to bypass a micro-op. Because the information in the micro-op filter table entry was used to bypass a micro-op, the micro-op filter increments the micro-op filter table's global counter (e.g., global counter 318) (step 904). For this action, the micro-op filter increments the micro-op filter table's global counter, which tracks how many times any micro-op filter table entry was used to bypass a micro-op.

[0069] Although decrement and increment are used in steps 902 and 904 when describing some embodiments, in some embodiments the micro-op filter uses different values ​​of the local and / or global counters and makes corresponding different adjustments (e.g., increments, decrements, etc.) to the local and / or global counters. In general, in the described embodiments, the micro-op filter includes mechanisms for tracking the usage of individual micro-op filter table entries and the usage of the micro-op filter table entries as a group / as a whole.

[0070] If decrementing the local counter causes the local counter to reach zero (step 906), the micro-op filter invalidates the micro-op filter table entry (step 908). To do this, the micro-op filter sets a valid bit in the micro-op filter table entry's metadata (e.g., metadata 504) to indicate that the micro-op filter table entry is invalid, clears / deletes all information from the micro-op filter table entry, and / or otherwise makes the information in the micro-op filter table entry unusable for later micro-op bypasses. Otherwise, if the local counter has not reached zero (step 906), the micro-op filter proceeds to step 910 (i.e., without invalidating the micro-op filter table entry).

[0071] If incrementing the global counter causes the global counter to exceed the reset threshold (step 910), the micro-op filter table invalidates all of the micro-op filter table entries as a group (step 912). To do this, the micro-op filter sets a valid bit in the metadata (e.g., metadata 504) of each micro-op filter table entry to indicate that the micro-op filter table entry is invalid, clears / deletes all information from all of the micro-op filter table entries, and / or otherwise makes all information in the micro-op filter table unusable for subsequent micro-op bypasses. Otherwise, if the global counter does not exceed the reset threshold (step 910), the micro-op filter proceeds with subsequent operations (i.e., without invalidating all of the micro-op filter table entries).

[0072] (thread) In some embodiments, the processor includes circuitry, or "contexts," to support two or more (possibly even more) threads of execution. The processor can therefore maintain and execute program code instruction state using each of the two or more threads of execution. In some embodiments, the processor performs operations similar to those described above to bypass single-use micro-ops for each thread. In some of these embodiments, multiple threads can share a micro-op filter table and an eviction history table. In these embodiments, therefore, predicting that a micro-op stored in the micro-op cache will not be accessed and bypassing the micro-op based thereon may be performed for a given thread based in whole or in part on the past behavior of another thread. In other of these embodiments, each thread may have its own micro-op filter table and / or eviction history table, or may have exclusive access to some portions of a shared micro-op filter table and eviction history table. In these embodiments, predicting that a micro-op stored in the micro-op cache will not be accessed and bypassing the micro-op based thereon may be performed for a given thread based entirely on the past behavior of the given thread.

[0073] In some embodiments, at least one electronic device (e.g., electronic device 100) uses code and / or data stored on a non-transitory computer-readable storage medium to perform some or all of the operations described herein. More specifically, at least one electronic device reads the code and / or data from the computer-readable storage medium and executes the code and / or uses the data when performing the described operations. The computer-readable storage medium may be any device, medium, or combination thereof that stores code and / or data used by the electronic device. For example, the computer-readable storage medium may include, but is not limited to, flash memory, random access memory (e.g., eDRAM, RAM, SRAM, DRAM, DDR4 SDRAM, etc.), non-volatile RAM (e.g., phase-change memory, ferroelectric random access memory, spin-transfer random access memory, magnetoresistive random access memory, etc.), read-only memory (ROM), and / or magnetic or optical storage media (e.g., disk drives, magnetic tapes, CDs, DVDs, etc.).

[0074] In some embodiments, one or more hardware modules perform the operations described herein. For example, a hardware module may include, but is not limited to, one or more central processing units (CPUs) / CPU cores, graphics processing units (GPUs) / GPU cores, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), compressors or encoders, compute units, embedded processors, accelerated processing units (APUs), controllers, and / or other functional blocks. When circuitry (e.g., integrated circuit elements, discrete circuit elements, etc.) within such a hardware module is activated, the circuitry performs some or all of the operations. In some embodiments, a hardware module includes general-purpose circuitry, such as an execution pipeline, compute, or processing unit, that performs operations upon executing instructions (program code, firmware, etc.). In some embodiments, a hardware module includes application-specific or dedicated circuitry that performs operations, and in some cases, includes circuitry that performs some or all of the operations "in hardware" without executing instructions.

[0075] In some embodiments, data structures representing some or all of the functional blocks and circuit elements described herein (e.g., electronic device 100 or portions thereof) are stored on a non-transitory computer-readable storage medium, including a database or other data structure, that can be read by an electronic device and used directly or indirectly to manufacture hardware that includes the functional blocks and circuit elements. For example, the data structure may be a behavioral-level description or a register-transfer level (RTL) description of the hardware functionality in a high-level design language (HDL) such as Verilog or VHDL. The description may be read by a synthesis tool that can synthesize the description to generate a netlist that includes a list of transistors / circuit elements from a synthesis library that represents the functionality of the hardware that includes the functional blocks and circuit elements. The netlist may then be placed and routed to generate a data set that describes the geometric shapes to be applied to a mask. The mask may then be used in various semiconductor manufacturing steps to manufacture a semiconductor circuit or circuits (e.g., an integrated circuit) corresponding to the functional blocks and circuit elements. Alternatively, the database on the computer-accessible storage medium may be a netlist (with or without a synthesis library) or a data set, or Graphic Data System (GDS) II data, as desired.

[0076] In this description, variables or unspecified values ​​(i.e., general descriptions of values ​​without specific examples of values) are represented by letters such as N, M, X, etc. As used herein, despite the possible use of similar letters in different places in this description, the variables and unspecified values ​​in each instance are not necessarily the same, i.e., there may be variables and values ​​intended for some or all of the general variables and unspecified values. In other words, examples of specific values ​​of N, and any other letters used to represent variables and unspecified values ​​in this description, are not necessarily related to each other.

[0077] As used herein, the phrase "et al." or "e.g., "is intended to indicate one and / or the equivalent of "at least one of" the elements in the list with which the "et al." is associated. For example, in a statement that "the electronic device performs a first operation, a second operation, etc.", the electronic device performs at least one of the first operation, the second operation, and the other operations. Additionally, the elements in the list associated with "e.g., " are merely examples from a set of examples, and at least some of the examples may not appear in some embodiments.

[0078] The foregoing descriptions of the embodiments have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Accordingly, many modifications and variations will be apparent to those skilled in the art. Moreover, the above disclosure is not intended to limit the embodiments. The scope of the embodiments is defined by the appended claims.

Claims

1. 1. An electronic device comprising: a processor; a micro-op cache within the processor, the micro-op cache including a plurality of micro-op cache entries, each micro-op cache entry configured to store a micro-op decoded from an instruction group of one or more instructions; a micro-op filter in the processor, the micro-op filter including a plurality of micro-op filter table entries, one or more of the micro-op filter table entries configured to store an identifier of an instruction group that is predicted to not be accessed if the micro-op is stored in the micro-op cache based on the micro-op being evicted from the micro-op cache without being accessed while stored in the micro-op cache; The micro-operation filter includes: receiving a first identifier of a first group of instructions; preventing a copy of the micro-op from the first instruction group from being stored in the micro-op cache if a micro-op filter table entry includes an identifier that matches the first identifier; configured to: Electronic devices.

2. The micro-operation filter includes: receiving a second identifier of a second group of instructions; caching a micro-op from the second instruction group in the micro-op cache if the micro-op filter table entry does not include an identifier that matches the second identifier; configured to: The electronic device of claim 1 .

3. an eviction history table within the processor, the eviction history table including a plurality of eviction history table entries, each eviction history table entry configured to store an identifier of an instruction group that was not accessed while the micro-op was stored in the micro-op cache; The micro-operation filter includes: determining, when a given micro-op from a given instruction group is evicted from a micro-op cache entry, that the given micro-op was not accessed while stored in the micro-op cache; updating at least one of an eviction history table entry having an identifier of the predetermined instruction group and a confidence counter of an eviction history table entry storing the identifier of the predetermined instruction group; storing an identifier of the predetermined instruction group in an available micro-op filter table entry when the confidence counter of the eviction history table entry that stores the identifier of the predetermined instruction group exceeds a confidence counter threshold; configured to: The electronic device of claim 1 .

4. When updating at least one of the eviction history table entry having the identifier of the predetermined instruction group and the confidence counter of the eviction history table entry storing the identifier of the predetermined instruction group, The micro-operation filter includes: If the eviction history table does not already contain an eviction history table entry with the identifier of the given instruction group, updating available eviction history table entries with the identifier of the predetermined instruction group; setting a confidence counter of the eviction history table entry that stores the identifier of the predetermined instruction group to an initial value; if the eviction history table already contains an eviction history table entry with the identifier of the given instruction group, incrementing a confidence counter of the eviction history table entry that stores an identifier of the predetermined instruction group; configured to: The electronic device of claim 3.

5. an access indicator for each micro-op cache entry; The micro-operation cache includes: setting an access indicator in a given micro-op cache entry when a micro-op stored in the given micro-op cache entry is accessed; using a respective access indicator to determine if the micro-op was accessed while stored in the given micro-op cache entry; configured to: The electronic device of claim 3.

6. updating the available eviction history table entries includes locating an eviction history table entry in a corresponding set based on an identifier of the predetermined instruction group, and possibly evicting an existing identifier from the eviction history table entry; The electronic device of claim 3.

7. a local counter for each micro-op filter table entry; The micro-operation filter includes: setting the local counter to a local counter value when an instruction group identifier is stored in a given micro-op filter table entry; decrementing the local counter each time a micro-op from the instruction group is prevented from being stored in the micro-op cache based on an identifier in the given micro-op filter table entry; invalidating the given micro-op filter table entry when the local counter reaches zero; configured to: The electronic device of claim 3.

8. a global counter for the micro-operation filter; The micro-operation filter includes: setting the global counter to zero while all micro-op filter table entries are invalid before storing an instruction group identifier in the micro-op filter table entry; incrementing the global counter each time a micro-op from any instruction group is prevented from being stored in the micro-op cache based on an identifier in a respective micro-op filter table entry; invalidating all micro-op filter table entries when the value of the global counter exceeds a reset threshold; configured to: The electronic device of claim 3.

9. one or more thread contexts within the processor; Each thread context is using at least one of a separate portion of the micro-op filter table entry and a separate portion of the eviction history table entry; or using at least one of a separate thread-specific micro-op filter and a separate thread-specific eviction history table; configured to: The electronic device of claim 3.

10. A memory in which a plurality of instruction groups are stored, an identifier for each instruction group is a tag containing some or all of the addresses in the memory associated with the instruction group, or a value calculated based on the addresses in the memory; The electronic device of claim 1 .

11. 1. A method for processing micro-operations in an electronic device, comprising: The electronic device is a processor; a micro-op cache within the processor including a plurality of micro-op cache entries, each micro-op cache entry configured to store a micro-op decoded from an instruction group of one or more instructions; a micro-op filter in the processor including a plurality of micro-op filter table entries, one or more of the micro-op filter table entries configured to store an identifier of an instruction group that is predicted to not be accessed if the micro-op is stored in the micro-op cache based on the micro-op being evicted from the micro-op cache without being accessed while stored in the micro-op cache; The method comprises: the micro-op filter receiving a first identifier of a first group of instructions; the micro-op filter preventing a copy of the micro-op from the first instruction group from being stored in the micro-op cache if a micro-op filter table entry includes an identifier that matches the first identifier. method.

12. The method comprises: receiving, by the micro-op filter, a second identifier for a second group of instructions; if the micro-op filter table entry does not include an identifier that matches the second identifier, the micro-op filter caches a micro-op from the second instruction group in the micro-op cache. The method of claim 11.

13. the processor includes an eviction history table including a plurality of eviction history table entries, each eviction history table entry configured to store an identifier of an instruction group that was not accessed while the micro-op was stored in the micro-op cache; The method comprises: when a given micro-op from a given instruction group is evicted from a micro-op cache entry, the micro-op filter determining that the given micro-op was not accessed while stored in the micro-op cache; the micro-op filter updating at least one of an eviction history table entry having an identifier of the predetermined instruction group and a confidence counter of an eviction history table entry that stores the identifier of the predetermined instruction group; and when the confidence counter of the eviction history table entry that stores the identifier of the predetermined instruction group exceeds a confidence counter threshold, the micro-op filter stores the identifier of the predetermined instruction group in an available micro-op filter table entry. The method of claim 11.

14. updating at least one of the eviction history table entry having the identifier of the predetermined instruction group and the confidence counter of the eviction history table entry storing the identifier of the predetermined instruction group, If the eviction history table does not already contain an eviction history table entry with the identifier of the given instruction group, the micro-op filter updating available eviction history table entries with the identifier of the predetermined instruction group; the micro-operation filter setting a confidence counter of the eviction history table entry that stores the identifier of the predetermined instruction group to an initial value; if the eviction history table already contains an eviction history table entry with the identifier of the given instruction group, the micro-op filter incrementing a confidence counter of the eviction history table entry that stores an identifier of the predetermined instruction group.

14. The method of claim 13.

15. Each micro-op cache entry includes an access indicator; The method comprises: the micro-operation cache setting an access indicator in a given micro-operation cache entry when a micro-operation stored in the given micro-operation cache entry is accessed; and using a respective access indicator to determine whether the micro-op cache has accessed the micro-op while stored in the given micro-op cache entry.

14. The method of claim 13.

16. updating the available eviction history table entries includes locating an eviction history table entry in a corresponding set based on an identifier of the predetermined instruction group, and possibly evicting an existing identifier from the eviction history table entry; 14. The method of claim 13.

17. Each micro-op filter table entry includes a local counter; The method comprises: the micro-op filter setting the local counter to a local counter value when an instruction group identifier is stored in a given micro-op filter table entry; the micro-op filter decrementing the local counter each time it prevents a micro-op from the instruction group from being stored in the micro-op cache based on an identifier in the given micro-op filter table entry; and when the local counter reaches zero, the micro-op filter invalidates the given micro-op filter table entry.

14. The method of claim 13.

18. the micro-operation filter includes a global counter; The method comprises: the micro-op filter setting the global counter to zero while all micro-op filter table entries are invalid before storing an instruction group identifier in the micro-op filter table entry; the micro-op filter incrementing the global counter each time it prevents a micro-op from any instruction group from being stored in the micro-op cache based on an identifier in a respective micro-op filter table entry; and when the value of the global counter exceeds a reset threshold, the micro-op filter invalidates all micro-op filter table entries.

14. The method of claim 13.

19. the processor comprises a plurality of thread contexts; Each thread context provides support for one thread of execution, The method comprises: each thread context uses at least one of a separate portion of the micro-op filter table entries and a separate portion of the eviction history table entries; or each thread context using at least one of a separate thread-specific micro-op filter and a separate thread-specific eviction history table; 14. The method of claim 13.

20. the electronic device comprises a memory in which a plurality of instruction groups are stored; an identifier for each instruction group is a tag containing some or all of the addresses in the memory associated with the instruction group, or a value calculated based on the addresses in the memory; The method of claim 11.

Images