Operation result caching management methods and superscalar processors
By introducing a result caching module into the superscalar processor and creating target cache entries within the issue cycle, the problems of complex lookup logic and delay bubbles in the register caching scheme are solved, improving the pipeline efficiency and performance of the processor and simplifying circuit design.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-19
- Publication Date
- 2026-04-03
AI Technical Summary
Existing register caching schemes suffer from problems such as complex lookup logic, high circuit complexity, increased power consumption, and dependency chain delay bubbles in high-performance out-of-order execution processors, which hinder further improvements in processor performance.
Introducing a result caching module into a superscalar processor simplifies the renaming phase logic and eliminates delay bubbles on the dependency chain by creating a target cache entry in the pending data state during the first instruction issue cycle and forwarding the target physical register index to the issue queue. This filters out dependent instructions and wakes them up to the ready state.
It improves the processor's pipeline efficiency and overall performance, reduces circuit complexity and power consumption, simplifies the interaction logic in the register renaming stage, and ensures the accuracy and timeliness of the calculation results.
Smart Images

Figure CN121364891B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of processor technology, and more specifically, to a method for managing computation result cache and a superscalar processor. Background Technology
[0002] In modern high-performance out-of-order execution processors, the operands required for instruction execution are typically stored in the General Register File (GRF), which works in conjunction with the issue queue and execution unit to complete instruction scheduling and computation. To alleviate the pressure on the GRF read ports, some designs introduce register caches as a supplementary storage structure. The results of the most recently executed instructions are cached in the register cache, allowing subsequent instructions that depend on those results to directly read data from the cache, thus reducing the occupancy of the GRF read ports.
[0003] However, existing register caching schemes still have significant drawbacks that limit further improvements in processor performance: First, the complex lookup logic limits processor frequency. Each entry in the issue queue needs to perform a CAM lookup (lookup by content address) in the register cache every cycle to determine the operand location. This high-frequency concurrent lookup significantly increases circuit complexity, wiring pressure, and power consumption. Second, the renaming stage increases complexity and power consumption. To avoid conflicts caused by the recycling of physical registers, existing designs need to additionally query the register cache and perform index comparisons during the renaming stage, leading to increased logic latency in this stage and making the cache design too tightly coupled with the front-end pipeline. Third, the update of register cache tags and data filling need to be completed synchronously during the write-back stage after instruction execution. Consumer instructions that depend on this result need to wait for the cache state to be updated before they can be woken up, resulting in at least two cycles of delay bubbles in the dependency chain, which seriously affects pipeline efficiency and leads to overall performance loss. Summary of the Invention
[0004] In view of this, the purpose of this application is to provide a method for managing the cache of computation results and a superscalar processor, which can solve at least one of the problems mentioned above.
[0005] In a first aspect, embodiments of this application provide a method for managing a computation result cache, applied to a superscalar processor, wherein the superscalar processor includes a result cache module parallel to the general-purpose register file, and the method includes:
[0006] During the first instruction's transmission cycle, a target cache entry in a data pending state is created in the result caching module, and the target physical register index of the target cache entry is forwarded to the transmission queue; wherein, the target cache entry is bound to the target physical register used to store the target operation result, and the target operation result is the operation result obtained after the first instruction is executed;
[0007] After the launch queue receives the target physical register index, it filters out the second instruction that depends on the result of the target operation, and at the same time wakes up the second instruction and marks the second instruction as ready;
[0008] After the first instruction is executed, the target operation result is written into the target cache entry, and the target cache entry is marked as valid.
[0009] After the target cache entry is marked as valid, the second instruction, which is in a ready state, is issued.
[0010] In one optional embodiment, the binding relationship between the target cache entry and the target physical register indicates that the target physical register index of the target cache entry is the same as the physical register index of the target physical register, and the target physical register is released back to the free list after the target cache entry is replaced.
[0011] In one optional embodiment, the first instruction is executed through the following steps:
[0012] Based on the position status of the operand of the first instruction, the physical register value corresponding to the operand of the first instruction is read and sent to the execution unit to determine the target operation result;
[0013] The location status includes the status of being located in the general-purpose register file or the status of being located in the result cache module.
[0014] In an optional embodiment, the step of reading the physical register value corresponding to the operand of the first instruction and sending it to the execution unit according to the position state of the operand of the first instruction to determine the target operation result includes:
[0015] If the operand of the first instruction is located in the result cache module, a read request is initiated to the result cache module to read the physical register value corresponding to the operand of the first instruction and send it to the execution unit to determine the target operation result;
[0016] If the operand of the first instruction does not exist in the result cache module, a read request is initiated to the general-purpose register file to read the physical register value corresponding to the operand of the first instruction and send it to the execution unit to determine the target operation result.
[0017] In one optional embodiment, the positional state of the operand of the first instruction is determined through the following steps:
[0018] Before the first instruction enters the launch queue, the cache entry for the physical register index that is already stored in the result cache module is queried;
[0019] Determine whether the physical register index corresponding to the operand of the first instruction matches the physical register index already stored in the result cache module;
[0020] If a match is found, the position status is recorded as the state of being located in the result cache module;
[0021] If there is no match, the position status is recorded as the state located in the general-purpose register file to complete a one-time query of the position status.
[0022] In an optional embodiment, the method further includes:
[0023] When a target cache entry in the result caching module is replaced, the result caching module is controlled to broadcast a failure notification to the transmission queue; the failure notification refers to a notification that the target cache entry has become invalid due to the replacement algorithm.
[0024] Control all entries in the launch queue to listen for the failure notification and update the position status of operands that depend on the failure cache entry.
[0025] In one optional embodiment, the storage content of each cache entry in the result caching module includes a physical register index, a physical register value, and a status signal indicating whether the cache entry is valid;
[0026] In the pending data state, the status signal is invalid, the physical register index is determined, and the physical register value has not been written; in the valid state, the status signal is valid, and both the physical register index and the physical register value are determined.
[0027] Secondly, embodiments of this application provide a superscalar processor, including: a register renaming module, a launch queue, a general-purpose register file, a result cache module, an execution unit, and a control module; the output of the register renaming module is connected to the input of the launch queue, the first output of the launch queue is connected to the first input of the execution unit, the second output of the launch queue is connected to the first input of the general-purpose register file and the first input of the result cache module, the output of the general-purpose register file and the output of the result cache module are connected to the second input of the execution unit through a selector, and the output of the execution unit is connected to the second input of the general-purpose register file and the second input of the result cache module; the control module is connected to the register renaming module, the launch queue, the general-purpose register file, the result cache module, and the execution unit, and the control module is used to execute the method described above.
[0028] In one optional embodiment, the number of read ports of the result cache module is greater than the number of read ports of the general-purpose register file, and the sum of the number of read ports of the result cache module and the number of read ports of the general-purpose register file is not less than the maximum number of read requests of the transmit queue.
[0029] In one optional embodiment, the result caching module is divided into multiple physical blocks according to the type of execution unit, and each physical block is equipped with an independent read / write port and a preset number of cache entries.
[0030] Thirdly, embodiments of this application also provide an electronic device, including: a superscalar processor, a memory, and a bus. The memory stores machine-readable instructions executable by the superscalar processor. When the electronic device is running, the superscalar processor communicates with the memory via the bus. When the machine-readable instructions are executed by the superscalar processor, the steps of the method described above are performed.
[0031] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a superscalar processor, performs the steps of the method described above.
[0032] The computation result cache management method and superscalar processor provided in this application create a target cache entry in a data pending state when the first instruction is issued and forward its target physical register index to the issuance queue, so that the second instruction, which depends on the execution of the first instruction to obtain the target computation result, is woken up in advance, thus eliminating the delay bubble on the dependency chain.
[0033] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0034] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0035] Figure 1 This is a timing flowchart for cache management of an existing instruction dependency chain;
[0036] Figure 2 A flowchart illustrating a computation result cache management method provided in an embodiment of this application;
[0037] Figure 3 A timing flowchart for instruction dependency chain cache management is provided in an embodiment of this application;
[0038] Figure 4 This is a schematic diagram of the structure of a superscalar processor provided in an embodiment of this application;
[0039] Figure 5 This is a schematic diagram of another superscalar processor provided in an embodiment of this application;
[0040] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0041] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.
[0042] First, the applicable application scenarios of this application are introduced. This application can be applied to the field of processors. Research has found that in modern high-performance out-of-order execution processors, the operands required for instruction execution are usually stored in a general-purpose register file, which works in conjunction with the issue queue and execution unit to complete instruction scheduling and computation. To alleviate the pressure on the general-purpose register file read port, some designs introduce a register cache as a supplementary storage structure, caching the results of the most recently executed instructions in the register cache, so that subsequent instructions that depend on the results can directly read data from the cache, reducing the occupation of the general-purpose register file read port.
[0043] However, existing register caching schemes still have significant drawbacks that limit further improvements in processor performance: First, the complex lookup logic limits processor frequency. Each entry in the issue queue needs to perform a CAM lookup (lookup by content address) in the register cache every cycle to determine the operand location. This high-frequency concurrent lookup significantly increases circuit complexity, wiring pressure, and power consumption. Second, the renaming stage increases complexity and power consumption. To avoid conflicts caused by the recycling of physical registers, existing designs need to additionally query the register cache and perform index comparisons during the renaming stage, leading to increased logic latency in this stage and making the cache design too tightly coupled with the front-end pipeline. Third, the update of register cache tags and data filling need to be completed synchronously during the write-back stage after instruction execution. Consumer instructions that depend on this result need to wait for the cache state to be updated before they can be woken up, resulting in at least two cycles of delay bubbles in the dependency chain, which seriously affects pipeline efficiency and leads to overall performance loss.
[0044] To illustrate the drawbacks more clearly, let's take a specific instruction dependency chain as an example, such as... Figure 1 As shown, assume that the superscalar processor has two instructions: Instruction I1: ADDR3, R1, R2 (adds the values of logical registers R1 and R2 and stores the result in the target logical register R3); Instruction I2: SUBR5, R3, R4 (subtracts the values of logical registers R3 and R4 and stores the result in the target logical register R5).
[0045] These two instructions have a true read-after-write (RAW) dependency: the execution of instruction I2 must wait for instruction I1 to compute the result of R3. In processors with traditional register cache designs, their execution flow is as follows:
[0046] Initial state: Instructions I1 and I2 have both entered the processor's issue queue (ISQ). Instruction I2 is in a sleep state, waiting to be woken up, because its source operand R3 is not yet ready.
[0047] Period N: Command I1 is selected to be issued.
[0048] Cycle N+1: Successfully issued to the execution unit. Assuming the ADD operation requires 1 cycle, at this moment, instruction I1 has been executed and its result (the new value of R3) has been generated inside the execution unit.
[0049] Cycle N+2 (Write-back Phase): In this cycle, the processor writes the result of instruction I1 back to the result cache. According to traditional design, the entry corresponding to R3 in the register cache is only marked as valid the instant this write-back operation is completed. The issue queue wake-up logic scans during this cycle. At this point, it finally detects that the entry for R3 in the register cache has become valid. Therefore, the wake-up logic wakes up instruction I2 and marks it as ready.
[0050] Period N+3 (or later): The scheduler selects instruction I2 from all ready instructions for transmission.
[0051] The performance bottleneck is obvious in this process. The calculation result of R3 is physically available at the end of cycle N+1, but the instruction I2, which depends on it, is not woken up until cycle N+3 and cannot be issued until cycle N+4 at the earliest. This creates a delay bubble of at least two cycles. These two cycles are completely wasted on waiting for cache state updates and subsequent wake-up logic responses. For instructions with even longer execution delays (such as multiplication and division), this performance loss caused by update delays is even more severe, directly leading to reduced processor pipeline efficiency and overall performance degradation.
[0052] Based on this, the embodiments of this application provide a method for managing the cache of computation results, which can at least eliminate delay bubbles in the dependency chain, improve pipeline efficiency, and thus improve overall performance.
[0053] This application provides a method for managing computation result caching, applied to a superscalar processor. The superscalar processor includes a result caching module parallel to the general-purpose register file. Each cache entry in the result caching module stores a physical register index, a physical register value, and a status signal indicating whether the cache entry is valid.
[0054] Here, the result cache module is a storage structure physically parallel to the general-purpose register file. It is used to cache the operation results recently written back by the execution unit and is equipped with sufficient read ports to meet the peak read demand of the launch queue. Specifically, the result cache module is a storage module independent of the general-purpose register file. The number of its read ports can be configured according to the maximum number of read requests in the launch queue. For example, 24 read ports can be configured, while the general-purpose register file only needs to be configured with 12 read ports. The two work together to avoid read port conflicts. This result cache module can be divided into multiple independent physical blocks according to the type of execution unit, such as an integer micro-operation result cache and a load-store micro-operation result cache. Each physical block is equipped with independent read / write ports and a preset number of cache entries, using fully associative or set-associative cache structures.
[0055] Please see Figure 2 , Figure 2 This is a flowchart illustrating a computation result caching management method provided in an embodiment of this application. Figure 2 As shown in the embodiments of this application, the method includes:
[0056] S101. During the first instruction's transmission cycle, a target cache entry in a data pending state is created in the result cache module, and the target physical register index of the target cache entry is forwarded to the transmission queue; wherein, the target cache entry is bound to the target physical register used to store the target operation result, and the target operation result is the operation result obtained after the first instruction is executed;
[0057] S102. After receiving the target physical register index in the launch queue, the second instruction that depends on the target calculation result is selected, and the second instruction is woken up and marked as ready.
[0058] S103. After the first instruction is executed, write the target operation result into the target cache entry and mark the target cache entry as valid.
[0059] S104. After the target cache entry is marked as valid, the second instruction, which is in the ready state, is issued.
[0060] In steps S101 to S104 above, by creating a target cache entry in a data pending state and forwarding its target physical register index to the launch queue when the first instruction is issued, the second instruction, which depends on the execution of the first instruction to obtain the target operation result, is woken up in advance, thus eliminating the delay bubble on the dependency chain.
[0061] The following is an exemplary description of steps S101 to S104 above:
[0062] In step S101, during the first instruction's transmission cycle, a target cache entry in a data pending state is created in the result cache module, and the target physical register index of the target cache entry is forwarded to the transmission queue; wherein, the target cache entry is bound to the target physical register used to store the target operation result, and the target operation result is the operation result obtained after the first instruction is executed.
[0063] Here, the first instruction refers to the producer instruction that generates the target operation result. It includes various instructions in a superscalar processor, such as arithmetic and logical operation instructions, load and store instructions, and others that require outputting operation results. For example, the first instruction can be an integer addition instruction, a multiplication instruction, or a load instruction. Its core characteristic is that its execution produces a target operation result that subsequent instructions depend on. For instance, the first instruction I1: ADDR3, R1, R2 adds the values of logical registers R1 and R2, and stores the target operation result in the target logical register R3. The target operation result is the final data obtained after the first instruction completes arithmetic and logical operations or data loading in the execution unit; it is the source operand required by subsequent dependent instructions such as the second instruction. The type of the target operation result corresponds to the type of the first instruction. For example, the result of an addition instruction is the sum of two operands, and the result of a load instruction is data read from memory.
[0064] The launch cycle is the clock cycle during which the first instruction is selected by the launch queue and sent to the execution unit. Specifically, the launch cycle is a specific clock cycle in which the superscalar processor scheduling logic determines that the first instruction meets the launch conditions, pops it from the launch queue, and sends it to the corresponding execution unit. During this cycle, the instruction formally enters the execution phase, which is the preparation process. For example, if the scheduler selects the first instruction I1 for launch in clock cycle N, then clock cycle N is the launch cycle of this first instruction.
[0065] The "data pending" state is the initial state of a target cache entry, indicating that the entry has been allocated to a specific target physical register, but the corresponding calculation result has not yet been written. In an optional implementation, in the "data pending" state, the status signal of the target cache entry is invalid, the physical register index is known, but the physical register value is empty. This "data pending" state is used to reserve cache space in advance and notify the relevant entry in the launch queue that it will soon be valid. For example, in the launch cycle N of the first instruction I1, the result cache module creates a target cache entry for the target physical register Ptag=35 corresponding to its target logical register R3. At this time, the state of the target cache entry is "data pending," the status signal is 0 (invalid), Ptag=35 is recorded, and the data field is empty.
[0066] Specifically, a target cache entry is a storage unit allocated in the result cache module for storing the target operation result of the first instruction, and it has a one-to-one binding relationship with the target physical register. The storage content of the target cache entry includes the physical register index, the physical register value, and the status signal. Each entry corresponds to a unique physical register and is used to temporarily store the latest operation result corresponding to that physical register. For example, if the target physical register index of the first instruction I1 is 35, the corresponding target cache entry is the storage unit with index 35 in the result cache module, which is specifically used to store the operation result R3 obtained after the execution of the first instruction I1.
[0067] Here, the target physical register is the physical register allocated to the first instruction's target logical register after being renamed by the register renaming module, and is used to actually store the result of the first instruction's operation. Specifically, in a superscalar processor, logical registers are replaced with physical registers during the renaming phase, and the target physical register is the physical storage unit allocated to the first instruction's target logical register during this renaming process; its number is much larger than the number of entries in the result cache module. For example, logical register R3 is renamed to physical register P35, and P35 is the target physical register used to store the addition result of the first instruction I1.
[0068] Optionally, the binding relationship represents the index association and lifecycle association between the target cache entry and the target physical register. Specifically, the target physical register index of the target cache entry is the same as the physical register index of the target physical register, and the target physical register is released back to the free list after the target cache entry is replaced.
[0069] Here, the binding relationship establishes a one-to-one correspondence between target cache entries and target physical registers. On the one hand, the same index ensures the accuracy of data storage and retrieval; on the other hand, lifecycle binding simplifies the logic of the renaming phase. For example, if the target physical register index of a target cache entry is 35, and the physical register index of the corresponding target physical register is also 35, the target physical register P35 remains occupied until the target cache entry is replaced. It cannot be reallocated to other logical registers. Only when the target cache entry is replaced due to insufficient space in the result cache module using a replacement algorithm such as Least Recently Used (LRU), will the target physical register P35 be released back to the free list for subsequent instruction renaming. This binding relationship avoids querying the result cache module during the renaming phase, reducing the complexity and power consumption of this phase.
[0070] In traditional solutions, the register renaming phase requires querying the result cache module, traversing all entries to determine if a duplicate physical register index exists, and marking the entry as invalid if one exists to prevent new instructions from using old values. This increases the logical latency and power consumption of the register renaming phase. This embodiment, through the aforementioned binding relationship, eliminates the need to query the result cache module during the register renaming phase; physical registers can be allocated directly. Since the physical registers corresponding to unreplaced cache entries in the result cache module will not be re-allocated, conflicts with old values are avoided. This design decouples the interaction between the register renaming phase and the result cache module, simplifying the logic design and reducing circuit overhead and power consumption from queries. Furthermore, the physical registers corresponding to unreplaced cache entries remain occupied and will not be reallocated, eliminating the possibility of new instructions using old cached values from a hardware perspective. This ensures that the data read during instruction execution is the latest and most valid result, guaranteeing the processor's operational accuracy.
[0071] Furthermore, since the number of physical registers is much greater than the number of result cache entries, the embodiments of this application extend the lifespan of the target physical registers. Cache entries are typically replaced within a few cycles, and physical registers are not occupied for extended periods. This design eliminates the need to increase the number of physical registers and avoids the performance loss caused by frequent queries to the result cache module in traditional solutions. It ensures the rational use of register resources while causing almost no performance loss, achieving a balance between resource utilization and performance.
[0072] In step S102, after the transmit queue receives the target physical register index, it filters out the second instruction that depends on the target calculation result, and at the same time wakes up the second instruction and marks the second instruction as ready.
[0073] In this step, the issue queue refers to a storage module used to cache instructions to be executed. It contains multiple entries, each corresponding to one instruction to be executed. The scheduling logic selects instructions with ready operands from these entries for issuance. Specifically, the issue queue is a timing-critical core module in a superscalar processor, needing to support concurrent caching and scheduling of multiple instructions. Its maximum number of read requests is typically greater than the number of read ports in the general-purpose register file. For example, the issue queue can cache 32 instructions to be executed, supporting a maximum of 24 read requests per clock cycle, while the general-purpose register file only provides 12 read ports. The 24 read ports of the result cache module can supplement the read request demand.
[0074] In this context, the second instruction is a consumer instruction that depends on the target operation result of the first instruction. Its execution requires the target operation result of the first instruction as its source operand, exhibiting a read-after-write (RAW) dependency. Here, at least one source operand of the second instruction is the target operation result of the first instruction, and execution can only proceed after this result is ready. For example, instruction I2: SUBR5, R3, R4, where its source operand R3 is the target logic register of the first instruction I1, thus instruction I2 has a read-after-write dependency with the first instruction I1 and can be considered the second instruction I2. It remains in a waiting state until the target operation result of the first instruction I1 is ready.
[0075] In step S102, after the transmit queue receives the target physical register index, the transmit queue traverses all internal entries according to the received target physical register index, and identifies the instruction whose physical register index corresponding to the source operand is consistent with the target physical register index to obtain the second instruction.
[0076] Specifically, matching queries are performed based on the target physical register index, without waiting for the target operation result to be actually written to the result cache module. For example, after the transmit queue receives the target physical register index 35, it traverses all entries and finds that the physical register index corresponding to the source operand R3 of instruction I2 is 35. Therefore, instruction I2 is selected as the second instruction that depends on the target operation result of the first instruction.
[0077] In step S102, the second instruction is simultaneously woken up and marked as ready. This wake-up operation transforms the second instruction from a waiting state to a schedulable state, enabling it to be selected and issued by the scheduling logic. Specifically, the wake-up operation can be implemented through the wake-up logic of the issuance queue. Once it detects that the target cache entry corresponding to the dependent target physical register index has been created (even if the data has not yet been written), the second instruction is immediately activated. For example, after the issuance queue receives target physical register index 35, the wake-up logic immediately wakes up the second instruction I2, which is in a waiting state, making it eligible for scheduling. It does not need to wait for the target operation result of the first instruction I1 to be written back to the result cache module. This speculative wake-up eliminates the delay bubbles caused by waiting for cache updates in traditional designs.
[0078] The ready state is the state the second instruction is in after being woken up. It indicates that the core dependency condition of the second instruction (i.e., waiting for the target operation result of the first instruction) has entered the deterministic ready process (the dependent operands are about to be ready), and all launch conditions have been basically met. It only needs to wait for the scheduling logic to allocate a launch opportunity based on port resources, execution unit idle status, etc. For example, after the second instruction I2 is woken up, it is marked as ready and enters the scheduler's candidate launch list. After the target cache entry is marked as valid (operands can be read), it can be selected for launch in the next clock cycle.
[0079] Before describing step S103, the execution process of the first instruction will be introduced. The execution of the first instruction refers to the process in which the first instruction is transmitted from the transmission queue and then performs a preset calculation in the execution unit. Specifically, it includes the following steps:
[0080] Step 1030: Based on the position status of the operand of the first instruction, read the physical register value corresponding to the operand of the first instruction and send it to the execution unit to determine the target operation result; wherein, the position status includes the state located in the general-purpose register file or the state located in the result cache module.
[0081] In the above steps, the execution of the first instruction depends on the accurate reading of the operands. The position and state of the operands determine the storage location of the operands to be read, ensuring that the execution unit can obtain the correct computation data. For example, the physical register values corresponding to the operands R1 and R2 of the first instruction I1 need to be read from the result cache module or the general-purpose register file according to their position and state, and then sent to the execution unit to complete the computation.
[0082] The position status includes the state of being in the general-purpose register file or the state of being in the result cache module, used to indicate the specific storage location of the operand. Optionally, the position status is an attribute determined before the instruction enters the issue queue, used to guide operand reading during the execution phase and avoid frequent cache lookups. For example, if the physical register value corresponding to operand R1 of the first instruction I1 is already cached in the result cache module, then its position status is in the result cache module; if the physical register value corresponding to R2 is not cached, then its position status is in the general-purpose register file.
[0083] In an optional embodiment, step 1030 determines the position state of the operand of the first instruction through the following steps:
[0084] Before the first instruction enters the launch queue, the cache entries of physical register indices stored in the result cache module are queried; it is determined whether the physical register index corresponding to the operand of the first instruction matches the physical register index stored in the result cache module; if they match, the position status is recorded as being in the result cache module; if they do not match, the position status is recorded as being in the general-purpose register file, so as to complete a one-time query of the position status.
[0085] Among them, the cache entries that have stored physical register indices include cache entries in the pending data state and cache entries in the valid state.
[0086] Specifically, a one-time lookup refers to performing a position lookup only once before the instruction is enqueued, avoiding the high-frequency lookups to the result cache module in each cycle of traditional designs and reducing the logical complexity of the launch queue. For example, before the first instruction I1 enters the launch queue, the physical register index of all valid entries in the result cache module is queried. Assuming that the physical register index corresponding to the operand R1 of the first instruction I1 is 10, and there is a valid entry with index 10 in the result cache module, and the physical register index corresponding to R2 is 20, and there is no entry with that index in the result cache module, then the position status of R1 is recorded as being in the result cache module, and the position status of R2 is recorded as being in the general-purpose register file. This lookup result will be stored in the corresponding entry in the launch queue, and will not be queried again subsequently.
[0087] Traditional solutions require each entry in the launch queue to be checked in the cache every cycle, resulting in high circuit complexity, tight timing, and limitations on processor frequency. This embodiment eliminates the high-frequency interaction between the launch queue and the result cache module by performing a single query before enqueueing, simplifying internal circuit design and reducing wiring pressure, thus lowering timing latency. Furthermore, traditional high-frequency queries require numerous CAM lookup circuits and signal interaction links, increasing hardware cost and power consumption. This embodiment performs a single query before instruction enqueueing, reusing the query result throughout the process, reducing the number of interactions between the result cache module and the launch queue. Simultaneously, the single query logic is simple, eliminating the need for complex parallel query control and reducing hardware implementation difficulty. This not only reduces static power consumption but also avoids the dynamic power waste caused by high-frequency queries, further lowering overall power consumption.
[0088] Furthermore, a single query pre-locks the operand position, allowing data to be read directly from the record status during execution without waiting for query results. This shortens instruction execution preparation time and improves pipeline efficiency. Simultaneously, the query only targets valid entries already stored in the result cache module, ensuring accurate status determination. Combined with a subsequent failure broadcast mechanism, even if cached entries are replaced, the position status is updated promptly, avoiding the reading of invalid data and guaranteeing the correctness of instruction execution.
[0089] Specifically, the process of reading operands based on position status is as follows: if the operand of the first instruction is located in the result cache module, a read request is initiated to the result cache module to read the physical register value corresponding to the operand of the first instruction and send it to the execution unit to determine the target operation result; if the operand of the first instruction does not exist in the result cache module, a read request is initiated to the general-purpose register file to read the physical register value corresponding to the operand of the first instruction and send it to the execution unit to determine the target operation result.
[0090] In the above steps, the reading process can select the storage module according to the preset position status to ensure the efficiency and accuracy of operand reading. For example, if the position status of operand R1 of the first instruction I1 is in the result cache module, the transmit queue initiates a read request to the result cache module to read the physical register value corresponding to the physical register index of operand R1; if the position status of operand R2 is in the general-purpose register file, a read request is initiated to the general-purpose register file to read the physical register value corresponding to the physical register index of operand R2, and both physical register values are sent to the execution unit to complete the calculation and obtain the target calculation result.
[0091] The above configuration offloads some operand read requests to the result cache module, reducing the port usage pressure on the general-purpose register file. For example, the two operands of the first instruction are read from the result cache module and the general-purpose register file respectively, occupying only one GRF read port. The remaining ports can meet the read needs of other instructions, avoiding pipeline stalls caused by port conflicts and improving the processor's multi-instruction concurrent issue efficiency.
[0092] Because the result cache module is specifically designed to cache the most recent computation results and is equipped with ample read ports, read speeds are much faster. Furthermore, since the position status is predetermined, no additional lookup is needed during execution; read requests are initiated directly, reducing waiting time. For example, reading operands from the result cache module takes only one clock cycle, while traditional solutions might require 2-3 cycles due to GRF port conflicts. Fast reads enable execution units to start computation promptly, shortening instruction execution cycles, increasing overall processor throughput, and ultimately improving instruction execution efficiency.
[0093] This application embodiment eliminates the need to determine operand positions or compete for port resources during the execution phase, resulting in simple and direct control logic. Compared to the complex logic in traditional solutions where all read requests are sent to the GRF and then coordinated by the GRF for port allocation, this application embodiment reduces hardware overhead such as port scheduling, lowers circuit design complexity and wiring pressure, and reduces logic latency, thus avoiding impact on processor operating frequency.
[0094] Furthermore, in step S103, after the first instruction is executed, the target calculation result is written into the target cache entry, and the target cache entry is marked as valid.
[0095] In this step, the valid state is the final state of the target cache entry, indicating that the target cache entry has stored a valid operation result and is available for subsequent instructions to read. Specifically, the valid state is represented by the status signal of the target cache entry. For example, a status signal of 1 indicates that it is valid, at which point both the physical register index and the physical register value are determined and valid. For instance, after the target operation result of the first instruction I1 is written to the target cache entry, the status signal of the target cache entry is updated from 0 to 1, indicating that the target cache entry has stored a usable operation result, and the second instruction in the launch queue can read the target operation result for execution.
[0096] In step S104, after the target cache entry is marked as valid, the second instruction, which is in the ready state, is issued.
[0097] In the above steps, after the target cache entry is marked as valid and the second instruction is in a ready state, the second instruction can be selected from the launch queue and sent to the corresponding execution unit.
[0098] Optionally, the above-described transmission process requires conditions such as available execution unit resources and no read port conflicts. The scheduler will select a suitable instruction from multiple ready instructions based on priority. For example, after the target cache entry is marked as valid, if the scheduler detects that the second instruction I2 is in a ready state and the execution unit is idle, it will transmit the second instruction I2 to the execution unit, enabling it to read the calculation result of R3 and the physical register value of R4, complete the calculation, and obtain the result.
[0099] For example, such as Figure 3 As shown, within the issuance cycle N of the first instruction I1, a target cache entry in a pending data state is created in the result cache module, and the target physical register index of the target cache entry is forwarded to the issuance queue. After the issuance queue receives the target physical register index, it selects the second instruction that depends on the target operation result corresponding to the first instruction, and wakes up the second instruction and marks it as ready, without waiting for bubble. After the execution cycle N+1 of the first instruction ends, the target operation result can be written to the target cache entry in cycle N+2, and the target cache entry can be marked as valid. At the same time, the second instruction in the ready state is issued in cycle N+2 to wake up the subsequent second instruction in advance, improve performance and reduce instruction bubble.
[0100] In one optional embodiment, the present application further includes: when the target cache entry in the result cache module is replaced, controlling the result cache module to broadcast a failure notification to the launch queue; the failure notification refers to a notification that the target cache entry has become invalid due to the replacement algorithm; controlling all entries in the launch queue to listen for the failure notification and update the position status of operands that depend on the invalid cache entry.
[0101] Here, the failure broadcast mechanism ensures the accuracy of the instruction operand status in the issue queue, avoiding the reading of invalid data. For example, the result cache module can use the LRU replacement algorithm. When a new cache entry needs to be allocated but space is insufficient, the least recently used cache entry with physical register index 35 can be replaced. At this time, the result cache module broadcasts a notification to the issue queue that "the cache entry with physical register index 35 has failed." All instructions in the issue queue that depend on this cache entry (i.e., the physical register index corresponding to the operand is 35) will update their position status from the result cache module to the general-purpose register file. If the instruction is subsequently issued, the corresponding physical register value will be read from the general-purpose register file. This mechanism avoids the timing bottleneck caused by high-frequency lookups and simplifies the state management logic of the issue queue.
[0102] In addition, the failure broadcast mechanism forms a closed loop with the one-time query before enqueueing. The single query determines the initial position state, and the failure broadcast dynamically corrects the position state changes, avoiding the problem of operand reading errors caused by the replacement of cache entries in the result caching module.
[0103] The method provided in this application creates a target cache entry in a pending data state during the first instruction issue cycle and forwards its target physical register index to the issue queue. This allows the second instruction, which depends on the execution of the first instruction to obtain the target operation result, to be woken up in advance, eliminating the dependency chain delay bubble caused by cache update delay in traditional designs. By binding the target cache entry to the physical register, the query operation on the result cache module during the register renaming stage is avoided, simplifying the design of the register renaming stage. At the same time, in conjunction with the subsequent single query and failure broadcast mechanism, the timing bottleneck caused by high-frequency query cache in the issue queue is avoided, significantly reducing circuit complexity and power consumption. Without increasing the general-purpose register file read ports, the read port conflict problem is effectively solved, improving the overall performance of the superscalar processor.
[0104] Secondly, such as Figure 4As shown in the figure, this application provides a superscalar processor, including: a register renaming module 40, a launch queue 41, a general-purpose register file 42, a result cache module 43, an execution unit 44, and a control module (not shown in the figure); the output of the register renaming module 40 is connected to the input of the launch queue 41, the first output of the launch queue 41 is connected to the first input of the execution unit 44, the second output of the launch queue 41 is connected to the first input of the general-purpose register file 42 and the first input of the result cache module 43, the output of the general-purpose register file 42 and the output of the result cache module 43 are connected to the second input of the execution unit 44 through a selector 45, and the output of the execution unit 44 is connected to the second input of the general-purpose register file 42 and the second input of the result cache module 43; the control module is connected to the register renaming module 40, the launch queue 41, the general-purpose register file 42, the result cache module 43, and the execution unit 44, and the control module is used to execute... Figure 2 The method described.
[0105] Here, the first output of the transmit queue 41 is connected to the first input of the execution unit 44, and is used to output the instruction to be executed to the execution unit 44; the second output of the transmit queue 41 is connected to the first input of the general-purpose register file 42 and the first input of the result cache module 43, respectively, and is used to initiate an operand read request to the general-purpose register file 42 or the result cache module 43; the output of the general-purpose register file 42 and the output of the result cache module 43 are connected to the second input of the execution unit 44 through the selector 45, and are used to transmit the read physical register value to the execution unit 44; the output of the execution unit 44 is connected to the second input of the general-purpose register file 42 and the second input of the result cache module 43, respectively, and is used to write the calculation result back to the general-purpose register file 42 or the result cache module 43; the third output of the result cache module 43 is connected to the second input of the transmit queue 41, and is used to forward the physical register index and broadcast the cache entry invalidation notification to the transmit queue 41.
[0106] The following is a detailed explanation of each module and their relationships:
[0107] Register renaming module 40: This module renames logical registers of instructions to physical registers, allocating a unique physical storage unit for each instruction and avoiding register resource conflicts. Connected to the control module, this module allocates physical registers without querying the result cache module 43. Physical registers are only released back to the free list after the corresponding cache entry in the result cache module 43 has been replaced. For example, after renaming logical register R3 to physical register P35, the occupancy status of P35 is managed by the control module based on the entry status in the result cache module 43. Register renaming module 40 will not reassign P35 to other logical registers until the corresponding cache entry for P35 has been replaced.
[0108] The launch queue 41 is used to cache instructions to be executed, storing information such as the position status and dependencies of each instruction. It can contain multiple entries (e.g., 32), with each entry corresponding to one instruction. This module is connected to the control module, register renaming module 40, execution unit 44, general-purpose register file 42, and result cache module 43. Under the control of the control module, it completes the reception, filtering, waking up, and launch of instructions. For example, it receives the renamed instructions output by register renaming module 40, filters dependent instructions and wakes them up based on the physical register index forwarded by result cache module 43, initiates a read request to general-purpose register file 42 or result cache module 43 based on the position status, and launches ready instructions to execution unit 44. Simultaneously, this module listens for failure notifications broadcast by result cache module 43 and updates the position status of relevant instructions in a timely manner to ensure the accuracy of data reading.
[0109] General purpose register file 42: Used to store the operand values and calculation results required for instruction execution. This module is equipped with a preset number of read ports (e.g., 12), which are connected to the issue queue 41, the execution unit 44 and the control module. Under the control of the control module, it responds to the read requests of the issue queue 41, outputs the physical register values to the execution unit 44, and simultaneously receives and stores the calculation results output by the execution unit 44.
[0110] Result Cache Module 43: A storage structure physically parallel to the general-purpose register file 42, used to cache the operation results recently written back by the execution unit 44. It is the core module for alleviating read port pressure in the superscalar processor. Specifically, the number of read ports in the result cache module 43 is greater than the number of read ports in the general-purpose register file 42, and the sum of the number of read ports in the result cache module 43 and the general-purpose register file 42 is not less than the maximum number of read requests in the issue queue 41, to avoid instruction issuance pauses due to insufficient read port resources. For example, the result cache module 43 is configured with 24 read ports, and the general-purpose register file 42 is configured with 12 read ports, totaling 36, which meets the requirement of the maximum 24 read requests in the issue queue 41 and avoids read port conflicts. At the same time, this module is divided into multiple physical blocks according to the type of execution unit 44. For example, integer micro-operation result cache and load-store micro-operation result cache. Each physical block is equipped with independent read / write ports and a preset number of cache entries, such as 16 each, using fully associative or set-associative cache structures, and supporting common replacement algorithms such as LRU and random replacement. Each cached entry stores a physical register index, a physical register value, and a status signal indicating whether the entry is valid. In the pending state, the status signal is invalid, the physical register index is determined, and the physical register value has not been written. In the valid state, the status signal is valid, and both the physical register index and the physical register value are determined. This module connects to the transmit queue 41, the execution unit 44, and the control module, and under the control of the control module, it performs operations such as cached entry creation, data writing, status updating, entry replacement, and failure broadcasting.
[0111] Execution Unit 44: Used for executing arithmetic and logical operations or data loading and storage operations, including various types such as integer execution unit 44, floating-point execution unit 44, and load-store unit. Each type corresponds to a physical block of result cache module 43. This module is connected to the issue queue 41, general-purpose register file 42, result cache module 43, and control module. Under the control of the control module, it receives instructions and operands issued by issue queue 41, performs preset operations, and outputs the operation results to general-purpose register file 42 and result cache module 43.
[0112] Control Module: The core control unit of the processor, connected to all other modules via signal lines, is used to coordinate the working timing of each module and execute the aforementioned operation result cache management method. Specifically, it includes: controlling the allocation and release of physical registers in the register renaming module 40; controlling the instruction filtering, wake-up, and issuance in the issue queue 41; controlling the read request response and data writing in the general-purpose register file 42 and the result cache module 43; controlling the execution of operations in the execution unit 44; and controlling the entry creation, status update, replacement, and failure broadcasting in the result cache module 43. For example, during the first instruction I1 issue cycle, the control result cache module 43 creates the target cache entry and forwards the target physical register index of the target cache entry; controls the issue queue 41 to filter and wake up the second instruction I2; after the first instruction I1 is executed, the control result cache module 43 writes the target operation result and updates the status; when a cache entry is replaced, the control result cache module 43 broadcasts a failure notification and simultaneously controls the issue queue 41 to update the position status.
[0113] The number of write ports and read ports of the result cache module 43 mentioned in this application embodiment are both variable. Under normal circumstances, the number of read ports meets the maximum number of read ports of the transmit queue 41 and is much greater than the number of general-purpose register files 42.
[0114] It should be noted that in actual implementations, superscalar processors have multiple execution units. These execution units can be grouped into multiple result caching modules. The register renaming module and the general-purpose register file are one, while the issue queue, result caching module, and execution unit can each have multiple components, such as... Figure 5 As shown, the superscalar processor includes: a register renaming module 40, a issue queue 41, a general-purpose register file 42, a result cache module 43, two execution units (441, 442), and a control module (not shown in the figure). Among these, Figure 5 This is merely an illustrative example of the combination of modules, and no specific limit is made on the number of each module.
[0115] The superscalar processor provided in this application implements a state management mechanism through a control module that performs multi-level pipelined writes and speculative wake-ups, binds physical register lifetimes to cache states, and performs single lookups and failure broadcasts. This alleviates conflicts in the general-purpose register stack read ports, eliminates latency bubbles in the dependency chain, simplifies design complexity, reduces circuit power consumption, and significantly improves the processor's computational efficiency and operating frequency.
[0116] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 includes a superscalar processor 610, a memory 620, and a bus 630.
[0117] The memory 620 stores machine-readable instructions executable by the superscalar processor 610. When the electronic device 600 is running, the superscalar processor 610 communicates with the memory 620 via a bus 630. When the machine-readable instructions are executed by the superscalar processor 610, they can perform the operations described above. Figure 2 The steps of the method in the illustrated embodiment can be found in the method embodiment for specific implementation methods, which will not be repeated here.
[0118] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a superscalar processor, can perform the above-described actions. Figure 2 The steps of the method in the illustrated embodiment can be found in the method embodiment for specific implementation methods, which will not be repeated here.
[0119] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0120] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0121] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0122] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0123] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium executable by a superscalar processor. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0124] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for managing the cache of computation results, characterized in that, Applied to a superscalar processor, the superscalar processor including a result cache module parallel to a general-purpose register file, the method includes: During the first instruction's transmission cycle, a target cache entry in a data pending state is created in the result caching module, and the target physical register index of the target cache entry is forwarded to the transmission queue; wherein, the target cache entry is bound to the target physical register used to store the target operation result, and the target operation result is the operation result obtained after the first instruction is executed; After the launch queue receives the target physical register index, it filters out the second instruction that depends on the result of the target operation, and at the same time wakes up the second instruction and marks the second instruction as ready; After the first instruction is executed, the target operation result is written into the target cache entry, and the target cache entry is marked as valid. After the target cache entry is marked as valid, the second instruction, which is in a ready state, is issued.
2. The method according to claim 1, characterized in that, The binding relationship between the target cache entry and the target physical register indicates that the target physical register index of the target cache entry is the same as the physical register index of the target physical register, and the target physical register is released back to the free list after the target cache entry is replaced.
3. The method according to claim 1, characterized in that, The first instruction is executed through the following steps: Based on the position status of the operand of the first instruction, the physical register value corresponding to the operand of the first instruction is read and sent to the execution unit to determine the target operation result; The location status includes the status of being located in the general-purpose register file or the status of being located in the result cache module.
4. The method according to claim 3, characterized in that, The step of reading the physical register value corresponding to the operand of the first instruction based on the position state of the operand of the first instruction and sending it to the execution unit to determine the target operation result includes: If the operand of the first instruction is located in the result cache module, a read request is initiated to the result cache module to read the physical register value corresponding to the operand of the first instruction and send it to the execution unit to determine the target operation result; If the operand of the first instruction does not exist in the result cache module, a read request is initiated to the general-purpose register file to read the physical register value corresponding to the operand of the first instruction and send it to the execution unit to determine the target operation result.
5. The method according to claim 3, characterized in that, The position state of the operand of the first instruction is determined by the following steps: Before the first instruction enters the launch queue, the cache entry for the physical register index that is already stored in the result cache module is queried; Determine whether the physical register index corresponding to the operand of the first instruction matches the physical register index already stored in the result cache module; If a match is found, the position status is recorded as the state of being located in the result cache module; If there is no match, the position status is recorded as the state located in the general-purpose register file to complete a one-time query of the position status.
6. The method according to claim 5, characterized in that, The method further includes: When a target cache entry in the result caching module is replaced, the result caching module is controlled to broadcast a failure notification to the transmission queue; the failure notification refers to a notification that the target cache entry has become invalid due to the replacement algorithm. Control all entries in the launch queue to listen for the failure notification and update the position status of operands that depend on the failure cache entry.
7. The method according to claim 1, characterized in that, The storage content of each cache entry in the result caching module includes a physical register index, a physical register value, and a status signal indicating whether the cache entry is valid; In the pending data state, the status signal is invalid, the physical register index is determined, and the physical register value has not been written; in the valid state, the status signal is valid, and both the physical register index and the physical register value are determined.
8. A superscalar processor, characterized in that, include: The system comprises a register renaming module, a launch queue, a general-purpose register file, a result cache module, an execution unit, and a control module. The output of the register renaming module is connected to the input of the launch queue. The first output of the launch queue is connected to the first input of the execution unit. The second output of the launch queue is connected to both the first input of the general-purpose register file and the first input of the result cache module. The outputs of the general-purpose register file and the result cache module are connected to the second input of the execution unit via a selector. The output of the execution unit is also connected to both the second input of the general-purpose register file and the second input of the result cache module. The control module is connected to the register renaming module, the launch queue, the general-purpose register file, the result cache module, and the execution unit, and the control module is used to execute the method described in any one of claims 1-7.
9. The superscalar processor according to claim 8, characterized in that, The number of read ports of the result cache module is greater than the number of read ports of the general-purpose register file, and the sum of the number of read ports of the result cache module and the number of read ports of the general-purpose register file is not less than the maximum number of read requests of the transmit queue.
10. The superscalar processor according to claim 8, characterized in that, The result caching module is divided into multiple physical blocks according to the type of execution unit. Each physical block is equipped with an independent read / write port and a preset number of cache entries.
Citation Information
Patent Citations
CPU instruction processing method and processor
CN104216681A
Computing chip and instruction processing method
US20240419443A1