Filtering micro-operations in a micro-operation cache for a processor

Abstract

A processor is provided that includes a micro-op cache having a plurality of micro-op cache entries to store micro-ops decoded from instruction groups and a micro-op filter having a plurality of micro-op filter table entries to store identifiers of instruction groups for which micro-ops are predicted to be evicted on fill if the micro-ops are stored in the micro-op cache. The micro-op filter receives an identifier of an instruction group. The micro-op filter prevents a copy of a micro-op from the first instruction group from being stored in the micro-op cache when a micro-op filter table entry includes an identifier that matches the first identifier.

Description

Background Technology

[0001] Related technologies

[0002] In some electronic devices, the processor executes program code instructions, or more simply, instructions that cause the processor to perform corresponding operations. For example, a processor such as a Central Processing Unit (CPU) can execute instructions from software applications, operating systems, firmware, etc. Some processors are capable of executing multiple different instructions or "macro instructions" that are decoded by the processor into one or more micro-operations. Each micro-operation is a simpler, low-level processor instruction that, when executed by the processor, causes the processor to execute the corresponding part of the entire operation from which the micro-operation was decoded. For example, a Single Instruction Multiple Data (SIMD) instruction can be decoded by the processor into multiple individual micro-operations for performing SIMD instruction operations on multiple data items.

[0003] When instructions are executed in a processor, fetching the instructions to be executed from the instruction cache (or other locations in the memory subsystem) and decoding the fetched instructions into micro-operations for execution takes a relatively long time and consumes a significant amount of energy. Therefore, designers have proposed techniques to accelerate the fetching of micro-operations from instructions. One such technique is to use a cache memory called a micro-operation cache to store copies of the micro-operations decoded from the instructions. With this technique, the micro-operation decoded from the instructions is forwarded to the execution unit in the processor for execution, and along with the operation, the processor stores a copy of the micro-operation in the micro-operation cache. When the processor encounters an instruction again with a copy of the micro-operation stored in the micro-operation cache, it can fetch the micro-operation from the micro-operation cache instead of fetching and re-decoding the instruction. Due to the type of circuitry in the micro-operation cache and its physical location (closer to the execution unit), fetching micro-operations from the micro-operation cache is much faster than fetching and re-decoding the instruction.

[0004] While microoperation caches can offer benefits, their use can also be inefficient. Generally, a microoperation cache is a small-capacity cache memory that can only hold a small subset of all microoperations previously decoded from an instruction at any given time (note that the microoperations obtained from decoding an instruction may require more bytes of storage than the instruction itself). Therefore, it is common for microoperation caches to be full of microoperations. Once the microoperation cache is full, existing microoperations must be evicted to free up space for storing subsequently decoded microoperations in order for any subsequently decoded microoperations to be stored in the cache. Inefficiency in microoperation cache usage can occur when inaccessible microoperations or "dead-on-fill" microoperations are stored in the cache. This inefficiency arises because useful microoperations may be evicted from the cache to free up space for storing dead-on-fill microoperations. Therefore, when the corresponding instruction is executed again, it must be fetched again and the useful micro-operations must be re-decoded, which takes a relatively long time and consumes additional energy. Furthermore, re-fetching and re-decoding the corresponding instruction leads to unnecessary consumption of memory system bandwidth and decoding resources, as well as unnecessary power consumption. Attached Figure Description

[0005] Figure 1 A block diagram illustrating an electronic device according to some implementation schemes is presented.

[0006] Figure 2 A block diagram illustrating a processor according to some implementation schemes is presented.

[0007] Figure 3 A block diagram illustrating a micro-operation filter and a micro-operation cache according to some implementation schemes is presented.

[0008] Figure 4 A block diagram illustrating micro-operation cache entries according to some implementation schemes is presented.

[0009] Figure 5 A block diagram illustrating the entries in the micro-operation filter table according to some implementation schemes is presented.

[0010] Figure 6 A block diagram illustrating entries in an expulsion history table, based on some implementation schemes, is presented.

[0011] Figure 7 A flowchart illustrating a process for bypassing micro-operations, based on some implementation schemes, is presented.

[0012] Figure 8A flowchart illustrating the process for updating entries in a micro-operation filter table, according to some implementation schemes, is presented.

[0013] Figure 9 A flowchart illustrating a process for invalidating information in entries in a micro-operation filter table, according to some embodiments, is presented.

[0014] Throughout the accompanying drawings and description, the same reference numerals denote the same elements. Detailed Implementation

[0015] The following description is presented to enable those skilled in the art to perform and use the described implementation schemes, and is provided in the context of specific applications and their requirements. Those skilled in the art will readily understand various modifications to the described implementation schemes, and the general principles described herein can be applied to other implementation schemes and applications. Therefore, the described implementation schemes are not limited to those shown, but will conform to the widest range consistent with the principles and features described herein.

[0016] the term

[0017] In the following description, various terms are used to describe the implementation scheme. The following is a simplified general description of some of these terms. It should be noted that these terms may have important additional aspects, which are not listed herein for clarity and brevity, and therefore this description is not intended to limit these terms.

[0018] Functional Block: A functional block refers to a group of interconnected circuit systems, such as integrated circuit systems, discrete circuit systems, etc. Circuit systems are "interconnected" because the circuit elements within a circuit system share at least one attribute. For example, a circuit system may be included in, manufactured in, or otherwise coupled to a particular integrated circuit chip, substrate, circuit board, or portion thereof; may be involved in the execution of a specified function (e.g., computing or processing function, memory function, etc.); may be controlled by a common control element and / or a common clock, etc. A functional block circuit system 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).

[0019] Instruction Sets: A processor can fetch instructions from instruction sets, which include one or more instructions that will be processed (e.g., for decoding and execution), from the instruction cache or other locations in the memory subsystem. In other words, a processor can fetch instruction sets of size N bytes or more from the memory subsystem, where N is any size, such as 20 bytes, 64 bytes, or 100 bytes. For example, a processor can fetch half of the instructions in a cache line in the instruction cache as an instruction set. In some cases, each instruction set, and therefore one or more instructions within it, is associated with an identifier used by the processor to identify the instruction set. For example, some or all of the memory address of the first instruction in the instruction set can be used as the identifier of the instruction set.

[0020] Overview

[0021] In the described embodiments, the electronic device includes a processor (e.g., a central processing unit, a graphics processing unit, etc.) having processing circuitry for executing instructions from program code. The processor also includes a fetch unit and a decode unit. The fetch unit includes circuitry for fetching sets of instructions from an instruction cache (or other location in the memory subsystem) within the processor, and the decode unit includes circuitry for decoding the instructions in the fetched set of instructions into micro-operations for execution by the processing circuitry. The processor also includes a micro-operation cache, which includes circuitry for storing copies of micro-operations for subsequent re-execution of the corresponding set of instructions without having to fetch and re-decode them. The processor further includes a micro-operation filter, which includes circuitry for controlling which micro-operations are stored in the micro-operation cache, thereby "filtering" micro-operations stored in the micro-operation cache.

[0022] In some implementations, the micro-operation filter maintains (or accesses) a record identifying instruction groups for which micro-operations are predicted not to be accessed if they are stored in the micro-operation cache. Such micro-operations can be considered predicted as "invalid at fill time" because if they are stored in the micro-operation cache, they are predicted as "invalid" and therefore not accessed. Based on the information in the record, the micro-operation filter "bypasses" the predicted invalid at fill time micro-operations. Bypassing a micro-operation means that a copy of the micro-operation is not stored in the micro-operation cache because it is identified as predicted as invalid at fill time in the record. Conversely, for micro-operations not identified as predicted as invalid at fill time in the record, the micro-operation filter stores a copy of the micro-operation in the micro-operation cache. Thus, the micro-operation filter filters micro-operations to be stored in the micro-operation cache by preventing the storage of predicted invalid at fill time micro-operations in the micro-operation cache.

[0023] In some implementations, the aforementioned record identifying instruction groups (for which micro-operations are predicted to fail upon filling) is maintained in a micro-operation filter table. The micro-operation filter table includes circuitry for multiple entries, each configured to store an identifier for an instruction group for which micro-operations are predicted to fail upon filling. During processor operation, as the identifier for the instruction group is generated (e.g., by the next program counter function block in the processor), the micro-operation filter determines whether any entry in the micro-operation filter table includes an identifier that matches the generated identifier. If it does, and therefore if the micro-operation from the corresponding instruction group is predicted to fail upon filling, the micro-operation filter bypasses the micro-operation as described above.

[0024] In some implementations, during the three-step process, an identifier for instruction groups (for which micro-operations are predicted to fail upon filling) is added to a micro-operation filter table. For the first step of this process, the micro-operation cache tracks whether micro-operations stored in micro-operation cache entries have been accessed while stored in the cache. For example, the micro-operation cache may use a separate access indicator for each micro-operation cache entry to record whether a micro-operation stored in that entry has been accessed.

[0025] In some implementations, the second step in the process of adding the identifier of an instruction group to the micro-operation filter table involves an eviction history table. This eviction history table includes circuitry for multiple entries, each configured to store the identifier of an instruction group for which micro-operations are invalidated on refill in the micro-operation cache. For this second step, when a micro-operation recorded as not yet accessed is evicted from the micro-operation cache entry, the micro-operation cache notifies the micro-operation filter that the micro-operation is invalidated on refill. The micro-operation filter then updates the eviction history table entry with the identifier of the instruction group, decoding the invalidated micro-operation from that instruction group. To update an eviction history table entry, when the identifier of the instruction group is not yet stored in the eviction history table entry, the micro-operation filter finds an available entry (which may mean eviction of existing information from the entry), updates the available entry with the identifier of the instruction group, and sets the confidence counter of the available entry to its initial value. Conversely, when the eviction history table already includes an eviction history table entry with the identifier of the instruction group, the micro-operation filter increments the confidence counter of that entry. In this way, the micro-operation filter keeps a count in a confidence counter that indicates the number of times a micro-operation from an instruction set is found to be invalid when the micro-operation cache is filled.

[0026] In some implementations, for the third step in the process of adding the identifier of an instruction group to the micro-operation filter table, the micro-operation filter uses a confidence counter from the eviction history table to determine micro-operations predicted to be invalid on fill in the micro-operation cache, and accordingly adds the identifier of the corresponding instruction group to the micro-operation filter table. For this operation, if the confidence counter of an eviction history table entry is incremented to exceed a threshold, and it is thus found that the micro-operation of the instruction group whose identifier is stored in the eviction history table entry has been invalid on fill in the micro-operation cache more than a specified number of times, the micro-operation filter predicts that the micro-operation will continue to be invalid on fill in the micro-operation cache. Therefore, the micro-operation filter stores the identifier of the instruction group in an available micro-operation filter table entry (which may mean evicting existing information from the micro-operation filter table entry). By storing the identifier of the instruction group in the micro-operation filter table entry, the micro-operation filter records micro-operations predicted to be invalid on fill in the micro-operation cache.

[0027] In some implementations, the micro-operation filter includes a mechanism to ensure that information in the micro-operation filter table does not become outdated and is therefore more likely to remain correct. This mechanism includes a local counter in or associated with each micro-operation filter table entry. The micro-operation filter sets the local counter to a specified local counter value because the identifier of the instruction group is stored in the micro-operation filter table entry. Whenever a micro-operation from the instruction group is bypassed, the micro-operation filter then decrements the local counter based on the identifier found in the micro-operation filter table entry. When the local counter reaches zero, the micro-operation filter invalidates the micro-operation filter table entry. Thus, the micro-operation filter uses the information in each individual micro-operation filter table entry only a specified number of times and then discards the information from that micro-operation filter table entry.

[0028] In some implementations, mechanisms to ensure that information in the micro-operation filter table does not become obsolete include a global counter in or associated with the micro-operation filter table. To use the global counter, the micro-operation filter sets the global counter to zero when all micro-operation filter table entries are invalidated before the identifier of the instruction group is stored in the micro-operation filter table entries. For example, the micro-operation filter may set the global counter to zero at startup or after a micro-operation filter table entry is invalidated or reset. Whenever a micro-operation from any instruction group is bypassed, the micro-operation filter then increments the global counter based on the identifier found in the corresponding micro-operation filter table entry. Then, when the value of the global counter exceeds a reset threshold, the micro-operation filter invalidates all micro-operation filter table entries. Therefore, the micro-operation filter uses the information in all micro-operation filter table entries as a group only a specified number of times, and then discards the information in all micro-operation filter table entries as a group.

[0029] By bypassing micro-operations as described above, the described implementation avoids storing micro-operations in the micro-operation cache that are predicted to be invalid on fill-time. Avoiding the storage of invalid micro-operations in the micro-operation cache improves the operation of the micro-operation cache by preventing useful micro-operations from being evicted from the cache to free up space for storing invalid micro-operations. Since useful micro-operations are retained in the micro-operation cache, the processor can fetch useful micro-operations for re-execution more quickly (unlike re-fetching and re-decoding instructions from the corresponding instruction set). Furthermore, the power and resource consumption associated with re-fetching and re-decoding instruction sets for evicted useful micro-operations is reduced because useful micro-operations are retained in the micro-operation cache. Additionally, the memory subsystem in the processor can operate more efficiently because the retention of useful micro-operations in the micro-operation cache reduces the need for instruction set re-fetching. Improvements in the operation of the micro-operation cache, memory subsystem, and fetch and decode units contribute to improved operation of the processor and electronic devices, leading to increased user satisfaction.

[0030] electronic devices

[0031] Figure 1 A block diagram illustrating an electronic device 100 according to some embodiments is presented. For example... Figure 1 As shown, electronic device 100 includes processor 102 and memory 104. Generally, processor 102 and memory 104 are implemented in hardware, i.e., using circuitry. For example, the circuitry of processor 102 and memory 104 can be fabricated entirely on one or more semiconductor chips, including fabrication on one or more separate semiconductor chips, fabrication by combining one or more semiconductor chips with discrete circuitry elements, or fabrication by discrete circuitry elements alone. As described herein, processor 102 and memory 104 perform operations to bypass micro-operations caches that are predicted to fail upon filling.

[0032] Processor 102 is a functional block that executes operations associated with executing instructions from program code (such as instructions from software applications, firmware, operating systems, scripts, etc.) and 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.

[0033] Memory 104 is a functional block that performs operations of the memory (e.g., "main" memory) in electronic device 100. Memory 104 includes memory circuitry for storing instructions, information, and data accessed by the functional block in electronic device 100, and control circuitry for processing data access in the memory circuitry. The memory circuitry in memory 104 includes volatile memory circuitry, such as dual 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 acts as a long-term storage device for instructions and / or data.

[0034] For illustrative purposes, electronic device 100 is shown as including a specific number and arrangement of elements (i.e., processor 102 and memory 104). However, in some embodiments, electronic device 100 contains a different number or arrangement of elements. For example, electronic device 100 may include a power subsystem, a networking subsystem, a human-machine interface system, etc. Generally, electronic device 100 includes enough elements to perform the operations described herein.

[0035] Electronic device 100 may be or can be included in any electronic device that performs operations for performing the instructions as described herein. For example, electronic device 100 may be or can be included in electronic devices such as desktop computers, laptop computers, wearable electronic devices, tablet computers, smartphones, servers, artificial intelligence devices, virtual or augmented reality equipment, network devices, toys, audiovisual equipment, home appliances, controllers, vehicles, and / or combinations thereof.

[0036] processor

[0037] As described above, the electronic device 100 includes a processor 102. Figure 2 A block diagram illustrating processor 102 according to some embodiments is presented. For example... Figure 2 As shown, the functional blocks in processor 102 can be considered as part of front-end subsystem 200, back-end subsystem 202, or memory subsystem 204. Generally, front-end subsystem 200 includes functional blocks that perform operations for fetching instructions from memory subsystem 204 and generating micro-operations from instructions sent to execution units in back-end subsystem 202 for execution.

[0038] The front-end subsystem 200 includes instruction fetch / decode 206, a functional block of circuitry that includes operations associated with the fetched instructions and decodes the fetched instructions into micro-operations in preparation for execution. If necessary, instruction fetch / decode 206 fetches (i.e., requests and receives) instruction sets from L1 instruction cache 208, L2 cache 210, or memory 104. Instruction fetch / decode 206 then decodes the instructions in the fetched instruction sets into corresponding micro-operations. Instruction fetch / decode 206 forwards the micro-operations to a micro-operation (UOP) queue 212, a functional block of circuitry that includes control over when and how micro-operations are fed from the front-end subsystem 200 to the back-end subsystem 202. The micro-operations are ultimately fed from the micro-operation queue 212 to a scheduler 214, a functional block of circuitry that includes circuitry for directing or directing the micro-operations to appropriate execution units in the back-end subsystem 202 for execution.

[0039] The front-end subsystem 200 also includes a next PC (NPC) 216, which is a functional block including circuitry that performs operations to determine an address or "program counter" in memory to obtain the next instruction set to be fetched from the L1 instruction cache 208 for execution. The next PC 216 calculates the next sequential value of the program counter based on its initial or current value. For example, given a 32-byte instruction set, the next PC 216 can calculate the next address = current address + 32 bytes. When the program / instruction flow is not altered by control transfer instructions (e.g., branch instructions), the front-end subsystem 200 uses the sequential value of the program counter calculated by the next PC 216 to fetch the instruction set from the corresponding sequential address in memory.

[0040] The front-end subsystem 200 further includes a branch prediction unit (BPU) 218, which is a function block including circuitry that performs operations to predict the resolution of control transfer instructions (e.g., branches) in an instruction set and modify the program counter, and thus modify the address in memory from which to fetch subsequent instruction sets. In other words, the branch prediction unit 218 uses one or more records of control transfer instruction behavior to predict an "adopted" or "not adopted" solution for the control transfer instruction and provides a predicted target address for the adopted control transfer instruction. When a control transfer instruction is predicted to be adopted by the branch prediction unit 218, the branch prediction unit 218 can replace the next or subsequent program counter provided by the next PC 216 with the target address of the control transfer instruction.

[0041] The front-end subsystem 200 also includes a micro-operation (UOP) cache 220, which is a functional block including circuitry for storing copies of previously decoded micro-operations. These copies will be used for subsequent rescheduling and execution of the corresponding instruction sets without having to fetch and decode them again. When an instruction in an instruction set is decoded into a micro-operation by instruction fetch / decode 206, a copy of the micro-operation can be stored in the micro-operation cache 220. The copies of the micro-operations stored in the micro-operation cache 220 can then be used to quickly fetch micro-operations during subsequent re-execution of the instruction set. More specifically, when the next PC 216 provides the address of the next instruction set to be fetched and executed, the micro-operation cache 220 receives the address and determines whether a copy of the micro-operations for that instruction set is stored in the micro-operation cache 220. If so, the micro-operation cache 220 forwards the copy of the micro-operation to the micro-operation queue 212, from which the micro-operations are fed to the scheduler 214 and the back-end subsystem 202 for execution. The micro-operation cache 220 can also send instructions to the instruction fetch / decode 206 to provide micro-operations from the micro-operation cache 220, and therefore the instruction fetch / decode 206 does not need to fetch and decode instructions in the instruction set. Therefore, the instruction fetch / decode 206 can terminate the fetching and / or decoding of the instruction set.

[0042] The front-end subsystem 200 also includes a micro-operation filter 222, which is a functional block including circuitry that performs operations to control which micro-operations are stored in the micro-operation cache 220. The micro-operation filter 222 uses records to determine micro-operations that will be bypassed and therefore not stored in the micro-operation cache 220. These records identify instruction groups that are predicted not to be accessed if they are already stored in the micro-operation cache 220. The micro-operation filter 222 and the records it uses are described in more detail below.

[0043] The rear subsystem 202 includes an integer execution unit 224 and a floating-point execution unit 226, which are functional blocks comprising circuitry that performs operations for executing integer micro-operations and floating-point micro-operations, respectively. The integer execution unit 224 and the floating-point execution unit 226 include elements for performing micro-operations or other operations, such as renaming hardware, an execution scheduler, an arithmetic logic unit (ALU), floating-point multiplication and addition units (in the floating-point execution unit 226), register files, etc. Micro-operations are directed or directed from the scheduler 214 to the integer execution unit 224 or the floating-point execution unit 226 based on the data type of the micro-operation and the execution unit resources available for performing the micro-operation.

[0044] The memory subsystem 204 includes a hierarchical structure of cache memories, which are functional blocks including circuitry that performs operations for storing copies of instructions and / or data in the vicinity of the functional blocks using those instructions and / or data (compared to memory 104), and control circuitry for processing access to the instructions and / or data. The hierarchical structure comprises two levels, with a Level 1 (L1) instruction cache 208 and an L1 data cache 228 in the first level, and an L2 cache 210 in the second level. The memory subsystem 204 is communicatively coupled to memory 104 and may also be coupled to an external L3 cache (not shown).

[0045] Although Figure 2 The processor 102 is shown with a specific arrangement, connectivity, and number of elements, but in some embodiments, different arrangements, connectivity, and / or numbers of elements exist in the processor 102. Generally, the processor 102 includes a sufficient number of elements to perform the operations described herein.

[0046] Micro-operation filters and micro-operation caches

[0047] In the described implementation, the micro-operation filter performs operations to control whether copies of micro-operations are bypassed or stored in the micro-operation cache. Figure 3 A block diagram illustrating micro-operation filter 222 and micro-operation cache 220 according to some embodiments is presented. It should be noted that, although... Figure 3 The document illustrates a specific arrangement of function blocks, and operations are described as being performed by corresponding function blocks. However, some embodiments use different arrangements of function blocks and / or some or all operations are performed by different function blocks. Generally, the described embodiments include a sufficient number of function blocks to perform the operations described herein.

[0048] In description Figures 3 to 6 When referring to functional blocks shown in other parts of this specification, micro-operations are described as "fill-on-delay". Generally, a fill-on-delay micro-operation is a micro-operation that is stored or "filled" in the micro-operation cache but is not accessed until evicted from the micro-operation cache, and is therefore considered "delayed" in terms of its usefulness while stored in the micro-operation cache. In other words, when a fill-on-delay micro-operation resides in the micro-operation cache, the instruction set from which the fill-on-delay micro-operation is decoded is not re-executed, and therefore no request is made to the micro-operation cache to retrieve the fill-on-delay micro-operation. For example, re-execution of a missing instruction set may occur when the instruction set is executed serially, when a subroutine in the program code is executed only once, etc.

[0049] Turn now Figure 3As described above, instruction fetch / decode 206 performs operations associated with fetching instructions and decoding the fetched instructions. More specifically, instruction fetch / decode 206 fetches instructions from an instruction set (these instructions may be referred to as macro instructions, complex 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 the execution unit, causes the processor to execute the corresponding portion of the entire operation of the instruction (from which the micro-operation is decoded). For example, a single RepMov instruction can be decoded by instruction fetch / decode 206 into multiple individual micro-operations for performing the move operation indicated by the RepMov instruction on various data elements.

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

[0051] As described above, the micro-operation cache 220 stores copies of micro-operations. The micro-operation cache 220 includes multiple micro-operation cache entries 304 (only some of them are labeled for clarity), each micro-operation cache entry including circuitry for storing copies of the micro-operation and associated metadata. Figure 4 A block diagram illustrating micro-operation cache entry 304 according to some embodiments is presented. It should be noted that although micro-operation cache entry 304 is... Figure 4 While illustrated as including specific values, in some embodiments, micro-operation cache entries 304 include different values. For example, in some embodiments, each micro-operation cache entry 304 includes only the micro-operation 402, and the identifier 400, access bit (AB) 404, and metadata (MD) 406 are stored elsewhere (e.g., in a separate tag array within micro-operation cache 220). Generally, micro-operation cache 220 includes sufficient values ​​for performing the operations described herein.

[0052] like Figure 4As shown, micro-operation cache entry 304 includes an identifier 400, a micro-operation 402, an access bit 404, and metadata 406. The identifier 400 stores the identifier of the instruction set in which the micro-operation is stored in micro-operation cache entry 304, or an identifier associated therewith. For example, in some embodiments, the identifier 400 includes some or all of the addresses in memory of the instruction set or values ​​generated therefrom. The micro-operation 402 stores the micro-operation decoded from the instruction set. Because the number of micro-operations obtained by decoding instructions is variable, micro-operation 402 has a capacity for storing up to M micro-operations. The access bit 404 stores an indicator indicating whether micro-operation 402 has been accessed. In some embodiments, the access bit 404 is a single bit that is cleared (e.g., set to 0) when micro-operation 402 is stored in micro-operation cache entry 304 and set (e.g., set to 1) when micro-operation 402 is subsequently accessed. The metadata 406 stores metadata of micro-operation cache entry 304, such as validity information, thread identifiers, etc.

[0053] In some implementations, the microoperation cache 220 is configured associative, for example, using set association or another form of association. Because the microoperation cache 220 is configured associative, each microoperation cache entry 304 can be used to store microoperations decoded from a range or portion of instruction sets (e.g., instruction sets located at two or more memory addresses). In other words, a given microoperation cache entry 304 is not limited to storing microoperations from a single instruction set. During replacement in the microoperation cache 220, all microoperations stored in a given microoperation cache entry 304 can be evicted to free up the given microoperation cache entry 304 for storing microoperations decoded from another instruction set. In some implementations, microoperation cache entries 304 are evicted and otherwise processed according to rules or policies such as Least Recently Used (LRU), Least Used, etc.

[0054] Return now Figure 3 The micro-operation cache 220 also includes a control 306 that includes circuitry for controlling the operation of the micro-operation cache 220. For example, the control 306 may perform the following actions: store micro-operations and associated metadata in corresponding micro-operation cache entries 304; select a micro-operation cache entry 304 to free up space for storing an incoming micro-operation; search a micro-operation cache entry 304 to determine if a micro-operation decoded from a given instruction set is currently stored in the micro-operation cache entry 304; retrieve and provide a micro-operation from the micro-operation cache entry 304 (e.g., to the micro-operation queue 212), etc.

[0055] When the operation for storing micro-operations and associated metadata in micro-operation cache entry 304 is performed as described above, control 306 receives micro-operation information 308 from micro-operation filter 222. This micro-operation information includes micro-operations and metadata, such as identifiers of instruction sets from which micro-operations are decoded (e.g., some or all of the memory addresses), thread identifiers, etc. Control 306 then locates or releases available micro-operation cache entries 304 and stores the micro-operation and metadata in the available micro-operation cache entries 304. On the other hand, when the operation for retrieving and providing micro-operations from micro-operation cache entries 304 is performed, control 306 receives instruction set identifiers 300 from another functional block in processor 102 (e.g., the next PC 216), searches for matching identifiers in micro-operation cache entries 304, and when a micro-operation cache entry 304 storing a matching identifier is found, provides micro-operation 310 to micro-operation queue 212. Micro-operation 310 is fed from micro-operation queue 212 to back-end subsystem 202 via scheduler 214 for execution.

[0056] In some implementations, as part of the operation of fetching a micro-operation 310 for an instruction set and providing it to the micro-operation queue 212, when the micro-operation for the instruction set is found in the micro-operation cache entry 304 (and therefore a "hit" exists in the micro-operation cache 220), control 306 (or another functional block) notifies instruction fetch / decode 206, for example, via hit / miss 326. Instruction fetch / decode 206 then terminates the operation for fetching and / or decoding the instruction set. For example, instruction fetch / decode 206 may stop or hold the fetch request for the instruction set while control 306 searches the micro-operation cache entry 304 for a matching identifier, and discard the stopped or held fetch request when control 306 finds a match. As another example, instruction fetch / decode 206 may send a fetch request for the instruction set while control 306 searches the micro-operation cache entry 304 for a matching identifier, but ignore or discard (and therefore not decode) the fetched instruction set when control 306 finds a match. Conversely, when the microoperation of the instruction set is not found in the microoperation cache entry 304 (and therefore there is a "miss" in the microoperation cache 220), the control 306 notifies the instruction fetch / decode 206, for example via the hit / miss 326, that the microoperation is not stored in the microoperation cache 220, and the instruction fetch / decode 206 continues to fetch and decode the instruction set.

[0057] When a micro-operation that is not accessed while stored in the micro-operation cache is evicted from micro-operation cache entry 304, control 306 also performs an operation to notify micro-operation filter 222. In other words, when evicting a fill-time invalidated micro-operation from micro-operation cache entry 304, control 306 transmits fill-time invalidation information 312 to micro-operation filter 222, which includes at least an identifier of the instruction set from which the evicted micro-operation is decoded. Micro-operation filter 222 then processes the received fill-time invalidation information 312 as described below.

[0058] As described above, the micro-operation filter 222 controls which micro-operations are stored in the micro-operation cache 220. The micro-operation filter 222 includes a micro-operation filter table 314 for storing information used to control which micro-operations are stored in the micro-operation cache 220. The micro-operation filter table 314 includes multiple micro-operation filter table entries 316 (only a few are labeled for clarity), each micro-operation filter table entry including circuitry for storing information about instruction groups predicted to fail upon filling, which is used to bypass the corresponding micro-operation (i.e., prevent the corresponding micro-operation from being stored in the micro-operation cache 220). Figure 5 A block diagram illustrating micro-operation filter table entry 316 according to some embodiments is presented. It should be noted that although micro-operation filter table entry 316 is... Figure 5 The table is shown as including a specific arrangement of values, but in some embodiments, micro-operation filter table entries 316 include different values. Generally, each micro-operation filter table entry 316 includes a sufficient number of values ​​for performing the operations described herein.

[0059] like Figure 5 As shown, micro-operation filter table entry 316 includes an identifier 500, a local counter (LC) 502, and metadata (MD) 504. The identifier 500 stores an identifier for or associated with an instruction set for which micro-operations are predicted to be invalidated upon filling in the micro-operation cache 220. For example, in some embodiments, the identifier 500 includes some or all of the addresses of the instruction set in memory. The local counter 502 stores a counter for micro-operation filter table entry 316. The local counter 502 controls the number of times information from micro-operation filter table entry 316 is used to bypass micro-operations before being discarded as obsolete (and therefore unlikely to be correct). The metadata 504 stores metadata for micro-operation filter table entry 316, such as validity information, thread identifiers, and other information.

[0060] Return now Figure 3The micro-operation filter table 314 also includes a global counter 318. The global counter 318 stores global counters associated with micro-operation filter table entries 316. The global counter 318 controls the number of times information grouped from all micro-operation filter table entries 316 is used before it is discarded as obsolete (and therefore unlikely to be correct).

[0061] The micro-operation filter 222 also includes an eviction history table 320 for storing information used to determine which instruction sets are added to the micro-operation filter table 314. The eviction history table 320 includes eviction history table entries 322 (only a few are labeled for clarity), each entry including an identifier for storing instruction sets for which micro-operations are invalidated upon filling in the micro-operation cache 220, and circuitry for storing counters used to determine which instruction sets are added to the micro-operation filter table 314. Figure 6 A block diagram illustrating entry 322 of the expulsion history table according to some implementation schemes is presented. It should be noted that, although in Figure 6 The eviction history table entry 322 is shown as a specific arrangement of values, but in some embodiments, the eviction history table entry 322 includes different values. Generally, each eviction history table entry 322 includes sufficient values ​​to perform the operations described herein.

[0062] like Figure 6 As shown, eviction history table entry 322 includes an identifier 600, a confidence counter (CC) 602, and metadata (MD) 604. Identifier 600 stores an identifier for or associated with an instruction set for which micro-operations are invalidated upon filling in the micro-operation cache 220. For example, in some embodiments, identifier 600 includes a tag or other value generated from or based on some or all addresses in the memory of the instruction set. Confidence counter 602 stores a counter that holds a count of the number of times micro-operations decoded from the instruction set identified by identifier 600 are invalidated upon filling in the micro-operation cache 220. Metadata 604 stores metadata for eviction history table entry 322, such as validity information, thread identifiers, and other information.

[0063] In some implementations, the eviction history table 320 is configured associative, for example, using set association or another form of association. Because the eviction history table 320 is configured associative, each eviction history table entry 322 can be used to store identifiers of instruction groups that are invalid on fill from 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 of a single instruction group. During replacement in the eviction history table 320, existing identifiers of instruction groups that are invalid on fill and stored in a given eviction history table entry 322 can be evicted to free up the given eviction history table entry 322 to store identifiers of another instruction group that is invalid on fill and stored. In some implementations, the eviction history table entry 322 is evicted according to rules or policies such as Least Recently Used (LRU), Least Used, etc., and otherwise processed. In some implementations, the associativity of the eviction history table 320 (e.g., the arrangement of modes and sets, etc.) is similar to that used for the microoperations cache 220, which can be helpful when storing information 312 from the microoperations cache 220 that is invalidated on fill in the eviction history table 320.

[0064] return Figure 3 The micro-operation filter 222 also includes a control 324, which includes a circuit system for controlling / managing the operation of the micro-operation filter 222. For example, the control 324 may perform the following operations: receive information 312 that is invalidated upon filling from the micro-operation cache 220; update the eviction history table 320 based on the information 312 that is invalidated upon filling; update the micro-operation filter table 314 based on and using the information from the eviction history table 320; bypass the micro-operation of the instruction group based on the information in the micro-operation filter table 314; update the local counter 502 in the micro-operation filter table entry 316; and invalidate the information in the corresponding micro-operation filter table entry 316 using the local counter 502; update the global counter 318 and invalidate the information in the micro-operation filter table entry 316 using the global counter 318, and so on.

[0065] In some implementations, when updating the micro-operation filter table 314 based on and using information from the eviction history table 320 as described above, control 324 performs multiple operations. In other words, the process by which control 324 adds the identifier of an instruction group (for which micro-operations are predicted to fail upon filling) to the micro-operation filter table 314 is a multi-step process. For the first step, micro-operation cache 220 provides control 324 with information 312 regarding the failure upon filling of a given instruction group, for which a failure upon filling is found in micro-operation cache 220. For the second step, control 324 uses the received failure upon filling 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 may 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 update includes updating the confidence counter 602 of eviction history table entry 322 to indicate the number of times a micro-operation decoded from the instruction set has been found to have failed to fill in the micro-operation cache 220. For the third step, when updating the confidence counter 602 of eviction history table entry 322 causes the confidence counter 602 to exceed a threshold, control 324 adds information about the instruction set to micro-operation filter table entry 316. As detailed below, the information in micro-operation filter table entry 316 is used to bypass the micro-operation. Therefore, by adding information to micro-operation filter table entry 316, control 324 configures itself to bypass future instances of micro-operations decoded from the instruction set. Essentially, based on the specified number of times the micro-operation has previously failed to fill in the micro-operation cache 220, as counted in eviction history table entry 322, control 324 predicts that for future instances of the instruction set, the micro-operation will continue to fail to fill in the micro-operation cache 220.

[0066] In some implementations, when bypassing a micro-operation of an instruction group based on information in the micro-operation filter table 314, control 324 receives micro-operation information 308 for a given instruction group from instruction fetch / decode 206. Control 324 then searches the micro-operation filter table 314 for a match between the identifier 500 in the micro-operation filter table entry 316 and the identifier of the given instruction group from the micro-operation information 308. When a match is found, control 324 bypasses the micro-operation by preventing a copy of the micro-operation from being stored in the micro-operation cache entry 304 (i.e., discarding or ignoring the micro-operation received from instruction fetch / decode 206). On the other hand, when no match is found, control 324 does not bypass the micro-operation. In this case, control 324 provides the micro-operation information 308 to the micro-operation cache 220, which stores a copy of the micro-operation, the identifier of the instruction group, and possibly metadata from the micro-operation information 308 in available micro-operation cache entries 304 (which may mean evicting existing information from micro-operation cache entries 304). It should be noted that regardless of the result of the search and bypass operation of control 324, instruction extraction / decoding 206 forwards micro-operation 302 to micro-operation queue 212 in preparation for scheduling to the back-end subsystem 202 for execution.

[0067] In some implementations, when control 324 initially stores the identifier of an instruction group (and possibly other information) into a given micro-operation filter table entry 316, in order to invalidate the information in the corresponding micro-operation filter table entry 316 using local counter 502, control 324 sets the local counter 502 of the given micro-operation filter table entry 316 to a specified local counter value (e.g., 5, 10, or another value). Whenever a micro-operation is bypassed because the identifier of the instruction group is found in the given micro-operation filter table entry 316, control 324 decrements the local counter 502 of the given micro-operation filter table entry 316. Then, when the local counter reaches zero, control 324 invalidates the given micro-operation filter table entry 316, thus making the information stored therein unavailable. For example, to invalidate a given micro-operation filter table entry 316, control 324 can set a valid bit in metadata 504 for the given micro-operation filter table entry 316 to indicate that the given micro-operation filter table entry 316 is currently invalid. By setting and decrementing the local counter 502 of a given micro-operation filter table entry 316 and ultimately invalidating the given micro-operation filter table entry 316 based on the value of the local counter 502, control 324 limits the number of times information from a given micro-operation filter table entry 316 can be used to bypass a micro-operation. This can help prevent stale information from being used to (potentially incorrectly) bypass a micro-operation.

[0068] In some implementations, to invalidate information in micro-operation filter table entries 316 using global counter 318, control 324 initially sets global counter 318 to zero. For example, control 324 may set global counter 318 to zero at startup, or after all micro-operation filter table entries 316 have been invalidated. Then, whenever a micro-operation is bypassed because an identifier for an instruction group is found in any micro-operation filter table entry 316, control 324 increments global counter 318. When the global counter exceeds a reset threshold (e.g., 40, 55, or another value), control 324 then invalidates all micro-operation filter table entries 316. For example, to invalidate all micro-operation filter table entries 316, control 324 may set a valid bit in metadata 504 for each of a given micro-operation filter table entry 316 to indicate that the micro-operation filter table entry 316 is currently invalid. By setting and incrementing the global counter 318 and ultimately invalidating all micro-operation filter table entries 316 based on the value of the global counter 318, control 324 limits the number of times information from the micro-operation filter table 314 as a whole is used to bypass micro-operations, which helps to prevent outdated information from being used to bypass micro-operations.

[0069] Prediction and Mispretation

[0070] In the described implementation, a micro-operation filter (e.g., micro-operation filter 222) predicts whether subsequent instances of micro-operations in an instruction set will become invalid on fill-time in the micro-operation cache based on information about micro-operations in the micro-operation cache (e.g., micro-operation cache 220) that have already become invalid on fill-time. The micro-operation filter makes this "prediction" by adding an identifier of the instruction set to the micro-operation filter table, where the identifier will be used to bypass subsequent micro-operations decoded from the instruction set. The predictions made by the micro-operation filter are assumptions / guesses about future micro-operation access behavior based on previous micro-operation access behavior. Predictions may be incorrect, and therefore micro-operations predicted to become invalid on fill-time may have already been accessed in the micro-operation cache. However, if the actual behavior differs from the predicted behavior, the operation of the micro-operation cache and the processor is correct, although this incurs a performance penalty for re-fetching and re-decoding the bypassed (and therefore not stored and available in the micro-operation cache) micro-operations.

[0071] In some implementations, the thresholds and values ​​of the confidence counter, local counter, and / or global counter are set to values ​​that help to usefully bypass micro-operations that fail upon filling, while also avoiding misprediction of micro-operations that fail upon filling. For example, the thresholds of the local and global counters and / or the local and / or global counters may be set to values ​​such that useful entries remain in the micro-operation filter table for a reasonable amount of time, but older / stale entries are removed from the micro-operation filter table before the probability of misprediction becomes unacceptably high. The corresponding values ​​of the confidence counter, local counter, and / or global counter can be determined experimentally, calculated, estimated, or otherwise generated.

[0072] The process of handling micro-operations

[0073] In the described implementation, the micro-operation filter (e.g., micro-operation filter 222) performs operations to bypass micro-operations received from the instruction fetch / decode unit (e.g., instruction fetch / decode 206) and therefore does not store copies of the micro-operations in the micro-operation cache (e.g., micro-operation cache 220). Figure 7 A flowchart illustrating a process for bypassing micro-operations, based on some implementation schemes, is presented. It should be noted that... Figure 7 The operations shown are presented as general examples of operations performed by some implementations. Operations performed by other implementations include different operations, operations performed in different orders, and / or operations performed by different entities or functional blocks.

[0074] When the micro-operation filter receives the micro-operations decoded from the instruction set from the instruction fetch / decode unit, Figure 7 The operation begins (step 700). For this operation, the instruction fetch / decode unit fetches the instruction set from the L1 instruction cache (e.g., L1 instruction cache 208) or other location in the memory subsystem (e.g., memory subsystem 204) based on the instruction set identifier received from the next program counter function block (e.g., the next PC 216) or another entity. The instruction fetch / decode unit then decodes the instructions in the instruction set into micro-operations. Along with forwarding the micro-operations to the downstream subsystem (e.g., downstream subsystem 202) for execution, the instruction fetch / decode unit sends micro-operation information (e.g., micro-operation information 308) to the micro-operation filter.

[0075] Then, the micro-operation filter determines whether a micro-operation filter table entry (e.g., one of micro-operation filter table entries 316) includes a matching identifier (step 702). For this operation, the micro-operation filter obtains the identifier of the instruction group from the received micro-operation information. The micro-operation filter then compares the identifier from the instruction group with the identifier in any valid micro-operation filter table entry to determine whether there is a micro-operation filter table entry that includes a matching identifier.

[0076] When a micro-operation filter table entry includes a matching identifier (step 702), the micro-operation filter bypasses the micro-operation from the instruction set (step 704). For this operation, the micro-operation filter determines that the micro-operation is predicted to fail upon filling based on the presence of the matching identifier in the micro-operation filter table entry. The micro-operation filter then discards (e.g., deletes, ignores, etc.) the micro-operation information and does not store a copy of the micro-operation information in the micro-operation cache. Conversely, when the micro-operation filter table does not include a matching identifier (step 702), the micro-operation filter stores a copy of the micro-operation from the instruction set in the micro-operation cache (step 706). For this operation, since no micro-operation filter table entry with a matching identifier is found in the micro-operation filter table, the micro-operation filter determines that the micro-operation is not predicted to fail upon filling. The micro-operation filter then causes the micro-operation cache to store a copy of the micro-operation information in the micro-operation cache entry.

[0077] The process for updating entries in the micro-operation filter table.

[0078] In the described implementation, the micro-operation filter (e.g., micro-operation filter 222) performs operations to update entries in the micro-operation filter table (e.g., micro-operation filter table 314) for bypassing micro-operations. Figure 8 A flowchart illustrating the process for updating entries in a micro-operation filter table, according to some implementation schemes, is presented. Note that... Figure 8 The operations shown are presented as general examples of operations performed by some implementations. Operations performed by other implementations include different operations, operations performed in different orders, and / or operations performed by different entities or functional blocks.

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

[0080] The micro-operation is then evicted from the micro-operation cache entry (step 802). For this operation, the micro-operation cache can evict the micro-operation to free up the cache entry for storing a micro-operation from another instruction set or for another purpose. When evicting a micro-operation from the cache entry, the cache uses, for example, access bits (e.g., access bit 404) to determine that the micro-operation was not accessed while stored in the cache entry and is therefore invalidated upon refill. The cache then transmits this invalidation information (e.g., invalidation information 312) to the micro-operation filter to notify it that the micro-operation is invalidated upon refill.

[0081] Next, the micro-operation filter determines that a micro-operation was not accessed while stored in a micro-operation cache entry based on information received from the micro-operation cache that failed to fill at the time of filling (step 804). Upon determining that a micro-operation failed to fill at the time of filling, the micro-operation filter updates the eviction history table entry (eviction history table entry 322) with the identifier of the instruction group and / or updates the confidence counter of the eviction history table entry used to store the identifier of the instruction group (step 806). For this operation, when an eviction history table entry already includes the identifier of the instruction group, and therefore the micro-operation of the instruction group is found to have failed to fill at the time of filling at least once earlier, the micro-operation filter simply updates (e.g., increments, increases, etc.) the confidence counter of that eviction history table entry. On the other hand, when no eviction history table entry includes the identifier of the instruction group, the micro-operation filter finds an available eviction history table entry, adds the identifier to that available eviction history table entry, and sets the confidence counter of the eviction history table to an initial value (e.g., 1). In some embodiments, finding an available eviction history table entry means eviction of existing information from the eviction history table entry to free up the available eviction history table entry.

[0082] When updating the confidence counter of an eviction history table entry does not cause the eviction history table entry to exceed a threshold (step 808), the micro-operation filter continues to operate without making any changes to the micro-operation filter table. Conversely, when updating the confidence counter of an eviction history table entry causes the eviction history table entry to exceed a threshold (step 808), the micro-operation filter stores the identifier of the instruction group in the available micro-operation filter table entries (step 810). For this operation, when a sufficient number of micro-operation instances have been found to be invalidated on fill time in the micro-operation cache, and thus cause the micro-operation filter to update the confidence counter of the eviction history table entry as in step 806, the micro-operation filter updates the entries in the micro-operation filter table. As described above, since the micro-operation filter table entries will be used to bypass micro-operations of the instruction group, this operation is equivalent to predicting that future instances of the micro-operation will be invalidated on fill time in the micro-operation cache.

[0083] The process for invalidating entries in the micro-operation filter table.

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

[0085] for Figure 9 The operations in this context assume that the entries in the micro-operation filter table contain information about instruction groups stored therein (e.g., identifier 500 and metadata 504). For example, this includes step 810. Figure 8 The operation could have been performed at some point in the past. Furthermore, when information about the instruction group is stored in a local counter (e.g., local counter 502) of a micro-operation filter table entry, this local counter is set to its initial value. Additionally, when all entries in the micro-operation filter table are invalidated, such as at startup or after all previous invalidation of micro-operation filter table entries, the global counter is pre-reset / set to zero.

[0086] When a micro-operation filter bypasses a micro-operation from an instruction set based on information in the micro-operation filter table entries... Figure 9 The operation begins (step 900). For this operation, the micro-operation filter performs the operation... Figure 7The operations shown in steps 700 to 704 are similar to those operations, and therefore the micro-operations are not stored in entries in the micro-operation cache (e.g., micro-operation cache 220), but are ignored or discarded by the micro-operation filter.

[0087] Because the information in the micro-operation filter table entries is used to bypass micro-operations, the micro-operation filter decrements the local counter (e.g., local counter 502) of the micro-operation filter table entries (step 902). For this operation, the micro-operation filter decrements the local counter of the entry, which tracks the number of times the entry has been used to bypass the micro-operation. Because the information in the micro-operation filter table entries is used to bypass micro-operations, the micro-operation filter also increments the global counter (e.g., global counter 318) of the micro-operation filter table (step 904). For this operation, the micro-operation filter increments the global counter of the micro-operation filter table, which tracks the number of times any micro-operation filter table entry has been used to bypass the micro-operation.

[0088] It should be noted that although decrementing and incrementing are used respectively in some embodiments of steps 902 and 904, in some embodiments, the micro-operation filter uses different values ​​of local counters and / or global counters, and makes corresponding adjustments to the local counters and / or global counters (e.g., increasing, decreasing, etc.). Generally, in the described embodiments, the micro-operation filter includes mechanisms for tracking the use of individual micro-operation filter table entries and for using micro-operation filter table entries as a group / whole.

[0089] If the local counter is decremented to zero (step 906), the micro-operation filter invalidates the micro-operation filter table entry (step 908). For this operation, the micro-operation filter sets a valid bit in the metadata (e.g., metadata 504) used for the micro-operation filter table entry to indicate that the entry is invalid, clears / removes all information from the entry, and / or otherwise renders the information in the entry unusable for subsequent bypass micro-operations. Otherwise, if the local counter has not reached zero (step 906), the micro-operation filter proceeds to step 910 (i.e., without invalidating the entry).

[0090] If incrementing the global counter causes it to exceed the reset threshold (step 910), the micro-operation filter table invalidates all micro-operation filter table entries as a group (step 912). For this operation, the micro-operation filter sets a valid bit in the metadata (e.g., metadata 504) for each micro-operation filter table entry to indicate that the micro-operation filter table entry is invalid, clears / removes all information from all micro-operation filter table entries, and / or otherwise renders all information in the micro-operation filter table unusable for subsequent bypass micro-operations. Otherwise, if the global counter has not yet exceeded the reset threshold (step 910), the micro-operation filter continues with subsequent operations (i.e., without invalidating all micro-operation filter table entries).

[0091] Thread

[0092] In some implementations, the processor includes a circuit system or "context" for supporting two or more (and possibly more) execution threads. Thus, the processor can use each of the two or more execution threads to maintain the state of program code instructions and execute program code instructions. In some implementations, the processor performs operations similar to those described above to bypass micro-operations that fail upon filling for each thread. In some of these implementations, multiple threads may share a micro-operation filter table and an eviction history table. Thus, in these implementations, a prediction can be made, entirely or partially, that micro-operations stored in the micro-operation cache will not be accessed by a given thread based on the past behavior of another thread, and the micro-operation can be bypassed based on this prediction. In other implementations of these implementations, each thread may have its own micro-operation filter table and / or eviction history table, or exclusive access to certain portions of a shared micro-operation filter table and eviction history table. In these implementations, a prediction can be made, entirely based on the past behavior of a given thread, that micro-operations stored in the micro-operation cache will not be accessed by a given thread, and the micro-operation can be bypassed based on this prediction.

[0093] 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 code and / or data from a computer-readable storage medium and executes the code and / or uses the data when performing the described operations. The computer-readable storage medium can be any device, medium, or combination thereof that stores code and / or data for use by the electronic device. For example, the computer-readable storage medium can include, but is not limited to, volatile and / or non-volatile memories, including 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 torque random access memory, magnetoresistive random access memory, etc.), read-only memory (ROM), and / or magnetic or optical storage media (e.g., disk drives, magnetic tape, CDs, DVDs, etc.).

[0094] 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, computing units, embedded processors, accelerated processing units (APUs), controllers, and / or other functional blocks. When a circuit system (e.g., integrated circuit elements, discrete circuit elements, etc.) in such a hardware module is activated, that circuit system performs some or all of the operations. In some embodiments, the hardware module includes general-purpose circuit systems, such as pipelines, computing or processing units, which perform operations while executing instructions (program code, firmware, etc.). In some embodiments, the hardware module includes purpose-specific or special-purpose circuit systems that perform operations, possibly including circuit systems that perform some or all of the operations "in hardware" without executing instructions.

[0095] In some embodiments, data structures representing some or all of the functional blocks and circuit elements described herein (e.g., electronic device 100 or parts thereof) are stored on a non-transitory computer-readable storage medium, including databases or other data structures that can be read by the electronic device and used directly or indirectly for manufacturing hardware including functional blocks and circuit elements. For example, the data structure may be a behavioral-level description or register-transfer-level (RTL) description of hardware functionality in a high-level design language (HDL) such as Verilog or VHDL. This description can be read by a synthesis tool that synthesizes the description to generate a netlist comprising a list of transistors / circuit elements from a synthesis library representing the functionality of the hardware including the aforementioned functional blocks and circuit elements. The netlist can then be placed and routed to generate a dataset describing the geometry to be applied to a mask. The mask can then be used in various semiconductor manufacturing steps to produce one or more semiconductor circuits (e.g., integrated circuits) corresponding to the aforementioned functional blocks and circuit elements. Alternatively, the database on the computer-accessible storage medium may be a netlist (with or without a synthesis library), a dataset (as needed), or Graphical Data System (GDS) II data.

[0096] In this specification, variables or unspecified values ​​(i.e., a general description of the value of a specific instance of a value) are represented by letters such as N, M, and X. As used herein, although similar letters may be used in different places in this specification, variables and unspecified values ​​are not necessarily the same in every case; that is, there may be different variables and values ​​intended for use with some or all of the general variables and unspecified values. In other words, specific instances of N and any other letters used in this specification to represent variables and unspecified values ​​are not necessarily related to each other.

[0097] As used herein, the terms "etc." or "etc." are intended to indicate a and / or situation equivalent to "at least one" of the elements in the list associated with "etc." For example, in the statement "the electronic device performs a first operation, a second operation, etc.", the electronic device performs at least one of a first operation, a second operation, and other operations. Furthermore, the elements in the list associated with "etc." are merely examples within a set of examples, and at least some examples may not appear in some implementations.

[0098] The foregoing description of embodiments has been given for illustrative and descriptive purposes only. It is not intended to be exhaustive or to limit the embodiments to the disclosed form. Therefore, many modifications and variations will be apparent to those skilled in the art. Furthermore, the foregoing disclosure is not intended to limit the embodiments. The scope of the embodiments is defined by the appended claims.

Claims

1. An electronic device, comprising: a processor; a micro-operation cache in the processor, the micro-operation cache comprising a plurality of micro-operation cache entries, each micro-operation cache entry configured to store micro-operations decoded from an instruction group of one or more instructions; and a micro-operation filter in the processor, the micro-operation filter comprising a plurality of micro-operation filter table entries, one or more of the micro-operation filter table entries storing an identifier of an instruction group for which the micro-operations previously evicted from the micro-operation cache if the micro-operations are stored in the micro-operation cache are predicted to be not accessed based on not being accessed while stored in the micro-operation cache; wherein the micro-operation filter is configured to: receive a first identifier of a first instruction group; and prevent a copy of the micro-operations from the first instruction group from being stored in the micro-operation cache when a micro-operation filter table entry comprises an identifier matching the first identifier.

2. The electronic device of claim 1, wherein the micro-operation filter is further configured to: receive a second identifier of a second instruction group; and cache micro-operations from the second instruction group in the micro-operation cache when none of the micro-operation filter table entries comprise an identifier matching the second identifier.

3. The electronic device of claim 1, further comprising: an eviction history table in the processor, the eviction history table comprising a plurality of eviction history table entries, each eviction history table entry configured to store an identifier of an instruction group for which the micro-operations are not accessed while stored in the micro-operation cache; wherein the micro-operation filter is further configured to: determine that a given micro-operation from a given instruction group is not accessed while stored in the micro-operation cache when the given micro-operation is evicted from a micro-operation cache entry; update at least one of the eviction history table entries with an identifier of the given instruction group and update a confidence counter of the eviction history table entry storing the identifier of the given instruction group; and store the identifier of the given instruction group in an available micro-operation filter table entry when the confidence counter of the eviction history table entry storing the identifier of the given instruction group exceeds a confidence counter threshold. when updating the at least one of the eviction history table entries with the identifier of the given instruction group and updating the confidence counter of the eviction history table entry storing the identifier of the given instruction group, the micro-operation filter is configured to:

4. The electronic device of claim 3, wherein, when the eviction history table does not already comprise an eviction history table entry having the identifier of the given instruction group, update an available eviction history table entry with the identifier of the given instruction group, and when the eviction history table already comprises an eviction history table entry having the identifier of the given instruction group, update the confidence counter of the eviction history table entry storing the identifier of the given instruction group. setting a confidence counter of the eviction history table entry storing the identifier of the given instruction group to an initial value; and when the eviction history table already includes an eviction history table entry having the identifier of the given instruction group, incrementing the confidence counter of the eviction history table entry storing the identifier of the given instruction group.

5. The electronic device of claim 3, further comprising: an accessed indicator of each micro-operation cache entry, wherein: the micro-operation cache is configured to: set an accessed indicator for a given micro-operation cache entry when a micro-operation stored therein is accessed; and use the respective accessed indicator to determine whether the micro-operation was accessed while stored in the given micro-operation cache entry.

6. The electronic device of claim 3, wherein updating available eviction history table entries includes finding eviction history table entries in a corresponding set based on the identifier of the given instruction group and possibly evicting existing identifiers therefrom.

7. The electronic device of claim 3, further comprising: a local counter of each micro-operation filter table entry, wherein the micro-operation filter is configured to: set the local counter to a local counter value when an identifier of an instruction group is stored in a given micro-operation filter table entry; decrement the local counter each time a micro-operation from the instruction group is prevented from being stored in the micro-operation cache based on the identifier in the given micro-operation filter table entry; and when the local counter reaches zero, invalidate the given micro-operation filter table entry.

8. The electronic device of claim 3, further comprising: a global counter of the micro-operation filter, wherein the micro-operation filter is configured to: set the global counter to zero when all micro-operation filter table entries are invalidated prior to storing an identifier of an instruction group in the micro-operation filter table entry; increment the global counter each time a micro-operation from any instruction group is prevented from being stored in the micro-operation cache based on the identifier in a respective micro-operation filter table entry; and when a value of the global counter exceeds a reset threshold, invalidate all micro-operation filter table entries.

9. The electronic device of claim 3, further comprising: one or more thread contexts in the processor, wherein each thread context is configured to: use at least one of a separate portion of the micro-operation filter table entries and a separate portion of the eviction history table entries; or use at least one of a separate thread-specific micro-operation filter and a separate thread-specific eviction history table.

10. The electronic device of claim 1, further comprising: a memory storing instruction groups, wherein an identifier of an instruction group is a tag including some or all of an address in the memory associated with the instruction group or a value computed based on an address in the memory.

11. A method for processing micro-operations in an electronic device, the electronic device comprising: a processor; a memory; and a micro-operation cache configured to store micro-operations from a plurality of instruction groups, wherein each micro-operation is associated with an instruction group, and wherein the micro-operation cache is configured to: store an identifier of an instruction group in a micro-operation cache entry; and evict an identifier of an instruction group from a micro-operation cache entry based on a confidence counter of the micro-operation cache entry. a micro-op cache in the processor, the micro-op cache including a plurality of micro-op cache entries, one or more of the micro-op cache entries storing micro-ops decoded from an instruction group of one or more instructions; and a micro-op filter in the processor, the micro-op filter including a plurality of micro-op filter table entries, each micro-op filter table entry configured to store an identifier of an instruction group for which the micro-ops previously evicted from the micro-op cache based on not being accessed while stored in the micro-op cache are predicted to not be accessed if the micro-ops are stored in the micro-op cache, the method comprising: receiving, by the micro-op filter, a first identifier of a first instruction group; and preventing, by the micro-op filter, a copy of the micro-ops from the first instruction group from being stored in the micro-op cache when a micro-op filter table entry includes an identifier matching the first identifier.

12. The method of claim 11, wherein the method further comprises: receiving, by the micro-op filter, a second identifier of a second instruction group; and caching, by the micro-op filter, micro-ops from the second instruction group in the micro-op cache when none of the micro-op filter table entries include an identifier matching the second identifier.

13. The method of claim 11, wherein: the processor includes an eviction history table, 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 for which the micro-ops are not accessed while stored in the micro-op cache; and the method further comprises: determining, by the micro-op filter, that a given micro-op from a given instruction group is not accessed while stored in the micro-op cache when the given micro-op is evicted from a micro-op cache entry; updating, by the micro-op filter, at least one of the eviction history table entries with an identifier of the given instruction group and updating a confidence counter of the eviction history table entry storing the identifier of the given instruction group; and storing, by the micro-op filter, the identifier of the given instruction group in an available micro-op filter table entry when the confidence counter of the eviction history table entry storing the identifier of the given instruction group exceeds a confidence counter threshold.

14. The method of claim 13, wherein updating the at least one of the eviction history table entries with the identifier of the given instruction group and updating the confidence counter of the eviction history table entry storing the identifier of the given instruction group comprises: when the eviction history table does not already include an eviction history table entry having the identifier of the given instruction group, updating, by the micro-op filter, an available eviction history table entry with the identifier of the given instruction group, and when the eviction history table already includes an eviction history table entry having the identifier of the given instruction group, updating, by the micro-op filter, the confidence counter of the eviction history table entry storing the identifier of the given instruction group. setting, by the micro-op filter, a confidence counter of the eviction history table entry storing the given instruction group's identifier to an initial value; and when the eviction history table already includes an eviction history table entry having the given instruction group's identifier, incrementing, by the micro-op filter, the confidence counter of the eviction history table entry storing the given instruction group's identifier.

15. The method of claim 13, wherein: each micro-op cache entry includes an accessed indicator; and the method further comprises: setting, by the micro-op cache, an accessed indicator for a given micro-op cache entry when a micro-op stored in the micro-op cache is accessed; and determining, by the micro-op cache, using the respective accessed indicator, whether the micro-op was accessed while stored in the given micro-op cache entry.

16. The method of claim 13, wherein updating available eviction history table entries includes finding eviction history table entries in a corresponding set based on the given instruction group's identifier and possibly evicting existing identifiers therefrom.

17. The method of claim 13, wherein: each micro-op filter table entry includes a local counter; and the method further comprises: setting, by the micro-op filter, the local counter to a local counter value when an instruction group's identifier is stored in a given micro-op filter table entry; decrementing, by the micro-op filter, the local counter each time a micro-op from the instruction group is prevented from being stored in the micro-op cache based on the identifier in the given micro-op filter table entry; and invalidating, by the micro-op filter, the given micro-op filter table entry when the local counter reaches zero.

18. The method of claim 13, wherein: the micro-op filter includes a global counter; and the method further comprises: setting, by the micro-op filter, the global counter to zero when all micro-op filter table entries are invalidated prior to storing an instruction group's identifier in the micro-op filter table entry; incrementing, by the micro-op filter, the global counter each time a micro-op from any instruction group is prevented from being stored in the micro-op cache based on the identifier in a respective micro-op filter table entry; and invalidating, by the micro-op filter, all micro-op filter table entries when the global counter's value exceeds a reset threshold.

19. The method of claim 13, wherein: the processor includes a plurality of thread contexts, each thread context providing support for one execution thread; and the method further comprises: using, by each thread context, 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 using, by each thread context, at least one of a separate thread-specific micro-op filter and a separate thread-specific eviction history table.

20. The method of claim 11, wherein: The electronic device includes a memory storing a set of instructions; and The identifier of the set of instructions is a tag that includes some or all of an address in the memory associated with the set of instructions or a value computed based on the address in the memory.

Images