Physical register resource recovery method, processor, storage medium and program product

Abstract

The embodiment of the invention discloses a physical register resource recycling method, a processor, a storage medium and a program product. The method comprises the following steps: in a renaming stage, receiving an instruction and a logic register number of the instruction; obtaining an original physical register number bound with the logic register number; when the original physical register number reaches a recovery standard, generating returned physical register token information; and in an instruction submission stage, when the instruction is submitted, marking the original physical register number as an idle state based on pre-generated returned physical register token information, and updating the original physical register number to an idle physical register pool. According to the method, the feedback token information can be generated in advance, so that secondary calculation redundancy is eliminated, the physical register is quickly recycled, and the instruction throughput of the processor is improved.

Description

Technical Field

[0001] This disclosure relates to the field of processor microarchitecture technology, and in particular to a method for physical register resource reclamation, a processor, a storage medium, and a program product. Background Technology

[0002] The number of physical registers in a processor is limited, and instruction issuance relies on available physical register resources. When these resources are exhausted, the processor must wait for the old physical registers to be reclaimed (i.e., a token is returned) before it can continue issuing instructions. In existing technologies, the return of physical register tokens depends on instruction submission. Pipeline instructions (such as floating-point / fixed-point arithmetic instructions) can synchronize token information through the instruction status after execution and reclaim the token when the submission signal is valid. However, for non-pipelined instructions, such as Load instructions, which need to be executed across memory access units and arithmetic units, the arithmetic unit does not have its completion status. Therefore, it is necessary to read the submission queue information and calculate the token information after instruction submission before returning.

[0003] The token information for non-pipelined instructions needs to be recalculated after submission, which results in slower physical register reclamation, delayed replenishment of idle resources, and can easily cause instruction issue blocking, reducing the processor's instruction throughput. Summary of the Invention

[0004] In view of this, the present disclosure provides a physical register resource reclamation method, processor, storage medium, and program product, which can avoid the redundant steps of secondary token calculation in the prior art by locking the original physical register number to be reclaimed in advance and generating return token information in advance, thereby realizing the rapid reclamation of physical registers and replenishment of idle resources, effectively reducing instruction issuance blocking, and improving processor instruction throughput and overall computing performance.

[0005] In a first aspect, embodiments of this disclosure provide a method for reclaiming physical register resources, employing the following technical solution: During the renaming phase, the instruction and its logical register number are received. Obtain the original physical register number bound to the logical register number; When the original physical register number reaches the recycling standard, a physical register return token is generated; During the instruction submission phase, when the instruction is submitted, the original physical register number is marked as idle based on the pre-generated return physical register token information, and updated to the idle physical register pool.

[0006] Optionally, when the original physical register number reaches the reclamation criterion, generating a physical register return token includes: Detect the reference status of the original physical register number; If the original physical register number is not referenced by any uncommitted instruction, the original physical register number is determined to have met the reclamation criteria, and a physical register token is generated.

[0007] Optionally, the type of instruction includes intra-module pipelined execution type and cross-module non-pipelined execution type; The intra-module pipeline execution type refers to completing the execution task of instructions within the internal pipeline of a single target functional module; The cross-module non-pipeline execution type refers to splitting the execution task of the instruction into a target functional module and a dedicated execution module to complete the task in collaboration, and the target functional module does not carry the complete pipeline process of the instruction.

[0008] Optionally, when the type of the instruction is an intra-module pipeline execution type, the execution status information of the target functional module for the instruction is obtained; When the execution status information of the target functional module for the instruction is "completed", it is determined that the instruction has been submitted.

[0009] Optionally, when the type of the instruction is a cross-module non-pipelined execution type, the execution status information of the dedicated execution module for the instruction is obtained; When the execution status information of the instruction by the dedicated execution module is "completed", it is determined that the instruction has been submitted.

[0010] Optionally, the renaming phase may also include: Select a new physical register number from the pool of free physical registers; The original physical register number is replaced with the new physical register number and bound to the logical register number. Based on the updated mapping relationship between the logical register number and the physical register number, the instructions are executed out of order.

[0011] Optionally, the renaming phase may also include: Based on the renaming operation of the instruction, instruction submission information is generated and stored in the storage module. The instruction submission information includes the original physical register number and the returned physical register token information. The instruction submission phase also includes: Read the original physical register number and the returned physical register token information from the storage module; Based on the submitted status of the instruction, a release flag is generated; Based on the original physical register number, the returned physical register token information, and the release flag, the physical register to which the original physical register number belongs is released.

[0012] Secondly, this disclosure also provides a processor, which includes a renaming module, an instruction submission queue, an instruction submission control module, and a physical register token management module. The renaming module is used to receive instructions and the logical register number of the instructions; Obtain the original physical register number bound to the logical register number; When the original physical register number reaches the recycling standard, a physical register return token is generated and stored in the instruction submission queue; The instruction submission control module is used to pre-read the physical register token information in the instruction submission queue, and when the instruction is submitted, it sends the pre-read physical register token information to the physical register token management module. The physical register token management module is used to mark the original physical register number as idle based on the received returned physical register token information and update it to the idle physical register pool.

[0013] Optionally, the processor further includes a target function module; When the type of the instruction is an intra-module pipeline execution type: The target functional module is used to schedule the execution of the instructions, generate corresponding execution status information, and store it in the instruction submission queue; The instruction submission control module is also used to pre-read the execution status information of the target functional module for the instruction from the instruction submission queue; When the execution status information indicates completion, it is determined that the instruction has been submitted. The intra-module pipeline execution type refers to completing the execution of instructions within the internal pipeline of a single target functional module.

[0014] Optionally, the processor further includes a target function module and a dedicated execution module; When the type of the instruction is a cross-module non-pipelined execution type: The target functional module is used to perform a renaming operation on the instruction through the renaming module; The dedicated execution module is used to perform dedicated functions on the instructions, generate corresponding execution status information, and store it in the instruction submission queue; The instruction submission control module is also used to pre-read the execution status information of the instruction from the dedicated execution module from the instruction submission queue; When the execution status information of the instruction by the dedicated execution module is all "completed", it is determined that the instruction has been submitted. The cross-module non-pipeline execution type refers to splitting the execution task of the instruction into a target functional module and a dedicated execution module to complete the task in collaboration, and the target functional module does not carry the complete pipeline process of the instruction.

[0015] Optionally, the processor further includes a storage module and a physical register release module; The renaming module is also used to generate instruction submission information and store it in the storage module based on the renaming operation of the instruction. The instruction submission information includes the original physical register number and the returned physical register token information. The physical register release module is used to read the original physical register number and the returned physical register token information from the storage module during the instruction submission phase. Based on the submitted status of the instruction, a release flag is generated; Based on the original physical register number, the returned physical register token information, and the release flag, the physical register to which the original physical register number belongs is released.

[0016] Thirdly, this disclosure also provides a computer device, which adopts the following technical solution: The computer device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform any of the physical register resource reclamation methods described above.

[0017] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing computer instructions for causing a computer to execute any of the physical register resource reclamation methods described above.

[0018] Fifthly, embodiments of this disclosure also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of any of the methods described above.

[0019] The physical register resource reclamation method provided in this disclosure identifies the original physical register number during the renaming stage, pre-locking the original physical register number to be reclaimed and laying the foundation for subsequent reclamation processes. Addressing the issue of non-pipelined instructions causing arithmetic units to fail to synchronize their states due to cross-unit execution, this solution pre-generates a physical register return token information when the original physical register number reaches the reclamation standard. This avoids the redundant steps of rereading the commit queue and calculating token information twice after instruction submission in existing technologies, significantly shortening the token information generation cycle and substantially improving the physical register reclamation response speed. During the instruction submission stage, based on the pre-generated token information, the original physical register number can be directly marked as free and updated to the free pool, achieving rapid replenishment of physical register resources. This process optimization effectively solves the pain points of slow physical register reclamation and delayed free resource replenishment in existing technologies, providing sufficient free physical register resources for instruction issuance in a timely manner, reducing instruction issuance blocking caused by resource exhaustion, and ensuring the smooth operation of the processor pipeline. Meanwhile, the scheme takes into account the compatibility of pipelined and non-pipelined instructions, and comprehensively improves the processor's instruction throughput without affecting the efficiency of out-of-order execution, thereby enhancing the processor's overall computing performance and resource utilization.

[0020] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart illustrating the physical register resource reclamation method provided in this embodiment of the disclosure; Figure 2 This is a schematic diagram of the processor structure provided in an embodiment of the present disclosure; Figure 3 A flowchart illustrating the method for obtaining the original physical register number provided in this embodiment of the disclosure; Figure 4 A flowchart illustrating the binding relationship update method provided in this embodiment of the disclosure; Figure 5A flowchart illustrating the original physical register number recycling detection method provided in this embodiment of the disclosure; Figure 6 A flowchart illustrating the method for determining the completion and submission status of pipelined execution type instructions within a module, as provided in this embodiment of the disclosure; Figure 7 A flowchart illustrating the method for determining the completion and submission status of cross-module non-pipelined execution type instructions provided in this embodiment of the disclosure; Figure 8 A schematic block diagram of a processor provided for embodiments of this disclosure; Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. Detailed Implementation

[0023] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0024] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0025] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0026] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The drawings only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0027] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0028] Reference Figure 1 This disclosure provides a method for reclaiming physical register resources, including the following steps: S1: During the renaming phase, receive the instruction and the instruction's logical register number; S2: Retrieve the original physical register number bound to the logical register number; S3: When the original physical register number reaches the reclamation standard, a physical register token is generated for return; S4: During the instruction commit phase, when the instruction is committed, the original physical register number is marked as idle based on the pre-generated return physical register token information, and updated to the idle physical register pool.

[0029] In existing technologies, the return method for instructions returning physical register tokens varies depending on the instruction type. For instructions executed on the pipeline of the target functional module (such as floating-point or fixed-point scheduling execution modules), the physical register token information can be directly carried by the instruction status output after instruction execution, and the return is completed when the instruction commit signal is valid. However, for instructions that need to be executed collaboratively by multiple execution units, such as Load instructions, their core functions and auxiliary tasks need to be split into different modules. These instructions do not enter the complete pipeline of the target functional module, and the target functional module cannot output the global execution completion status of the instruction. Therefore, after the instruction is committed, the instruction information in the instruction commit queue must be read first to identify these non-pipelined instructions, and then the corresponding physical register token information must be calculated and generated. The physical register resource reclamation speed of this type of instruction is relatively slower than that of instructions executed pipelined within the module.

[0030] Based on the differences in return methods mentioned above, instructions can be divided into two categories: intra-module pipelined execution and cross-module non-pipelined execution. Intra-module pipelined execution refers to instructions whose execution tasks are completed within the internal pipeline of a single target functional module. The core functionality and auxiliary processes of this type of instruction are all assigned to the same target functional module, requiring no other execution units. After entering the target functional module, the instruction flows through the complete pipeline stages of instruction fetch, decoding, computation, and write-back. The target functional module's dedicated renaming module provides the target functional module with execution-related information such as instruction encoding information. The target functional module can independently act as the dedicated execution carrier for the instruction, directly capturing and outputting the instruction's execution completion status. For example, a pure fixed-point multiplication instruction completes its entire computation process solely within the pipeline of the fixed-point module, the target functional module, without the intervention of other modules.

[0031] Cross-module non-pipelined execution refers to the splitting of instruction execution tasks into tasks completed collaboratively by a target functional module and a dedicated execution module. The target functional module does not handle the complete instruction pipeline; its core functionality is independently performed by the dedicated execution module (e.g., a memory access module), while the target functional module only undertakes some auxiliary tasks. These auxiliary tasks typically refer to renaming operations performed by the target functional module's renaming module. The target functional module's pipeline only processes its assigned subtasks and cannot independently complete the entire instruction process, nor can it output the instruction's execution status. Status feedback from the dedicated execution module is required to determine the overall completion of the instruction. For example, in the Load instruction, the dedicated execution module is the memory access module, and the target functional module is the floating-point module. The core Load function is performed by the memory access module, while the renaming task, such as physical register allocation, is performed by the floating-point module's dedicated renaming module.

[0032] The physical register resource reclamation method disclosed herein identifies the original physical register number during the renaming phase, pre-locking the original physical register number to be reclaimed and laying the foundation for the subsequent reclamation process. Addressing the issue of non-pipelined instructions (instructions of cross-module non-pipelined execution type) causing the arithmetic unit to fail to synchronize its state due to cross-unit execution, this solution pre-generates physical register return token information when the original physical register number reaches the reclamation standard. This avoids the redundant steps in existing technologies that require a second reading of the submission queue and calculation of token information after instruction submission, significantly shortening the token information generation cycle and substantially improving the physical register reclamation response speed.

[0033] During the instruction submission phase, based on pre-generated token information, the original physical register number can be directly marked as free and updated to the free pool, achieving rapid replenishment of physical register resources. This process optimization effectively solves the pain points of slow physical register reclamation and delayed free resource replenishment in existing technologies. It can provide sufficient free physical register resources for instruction issuance in a timely manner, reduce instruction issuance blocking caused by resource exhaustion, and ensure the smooth operation of the processor pipeline. At the same time, this solution takes into account the reclamation adaptability of pipelined instructions (instructions of pipelined execution type within a module) and non-pipelined instructions. Without affecting the out-of-order execution efficiency of instructions, it comprehensively improves the processor's instruction throughput and enhances the overall computing performance and resource utilization of the processor.

[0034] In S1, refer to Figure 2 The schematic diagram of the processor shown illustrates that the renaming module of the target functional module receives the instruction transmitted by the instruction fetch unit and the logical register number corresponding to the instruction parsed and output by the decoding unit. The renaming module performs a renaming operation on the instruction using this key information of the logical register number.

[0035] In S2, when obtaining the original physical register number bound to the logical register number, a new physical register number is selected from the idle physical register pool; the original physical register number is replaced with the new physical register number and bound to the logical register number. This is the key step of renaming. Based on the updated mapping relationship between the logical register number and the physical register number, the instructions are executed out of order.

[0036] Reference Figure 3 The flowchart illustrating the method for obtaining the raw physical register number shows that "obtaining the raw physical register number bound to the logical register number" includes the following steps: S21: Query the mapping table by logical register number. The mapping table stores the correspondence between logical register numbers and currently bound physical register numbers. S22: Extract the physical register number currently bound to the logical register number and determine it as the original physical register number.

[0037] In S21 and S22, the renaming module pre-stores a logical-physical register mapping table, which maintains a one-to-one correspondence between all logical register numbers and their currently bound physical register numbers in real time. After receiving the instruction logical register number output by the decoding unit, the renaming module performs a precise query operation on the mapping table using that logical register number as the search keyword. Then, it extracts the physical register number that is currently bound to that logical register number from the query results and identifies it as the original physical register number corresponding to this renaming operation.

[0038] The renaming module is pre-configured with an idle physical register pool. This pool uses a first-in-first-out (FIFO) or bitmap management mechanism to maintain a set of all idle physical register numbers in real time. After determining the original physical register number, the renaming module sends a request to the idle physical register pool to allocate a new physical register number. The idle physical register pool selects an unoccupied physical register number from its set of idle physical register numbers according to a preset allocation strategy, designates it as the new physical register number for this renaming operation, and updates the status information of the idle physical register pool synchronously.

[0039] Reference Figure 4 The flowchart illustrating the binding relationship update method includes the following steps: "Replacing the original physical register number with the new physical register number and binding it with the logical register number, and then executing the instructions out of order based on the updated mapping relationship between the logical register number and the physical register number." S23: In the mapping table, replace the entry corresponding to the logical register number with the new physical register number to complete the binding between the logical register and the new physical register; S24: Execute instructions out of order based on the updated mapping table.

[0040] In S23 and S24, after obtaining the original physical register number and the newly allocated physical register number, the renaming module locates the entry in the mapping table corresponding to the instruction logical register number, directly replaces the original physical register number recorded in the entry with the new physical register number, thereby completing the update of the binding relationship between the logical register and the new physical register, and simultaneously marking the status of the new physical register number as "occupied".

[0041] Out-of-order execution refers to the processor breaking the program execution order of instructions and prioritizing the scheduling of instructions without data dependencies into the execution unit. Based on the updated mapping table, the scheduling unit can accurately identify the independent physical register resources corresponding to each instruction. It does not need to wait for the preceding instruction to release the logical register, and directly selects the instruction without data conflict to initiate scheduling, thereby realizing out-of-order execution of instructions.

[0042] In S3, refer to Figure 5 The flowchart illustrating the original physical register number recycling detection method shows that the method for determining whether an original physical register number meets the recycling criteria includes the following steps: S31: Check the reference status of the original physical register number; if the original physical register number is not referenced by any uncommitted instruction, execute S32; if the original physical register number is referenced by any uncommitted instruction, execute S33. S32: Determines that the original physical register number has reached the recycling standard; S33: The original physical register number has not met the recycling criteria.

[0043] In S31-S33, the renaming module has a built-in physical register reference count table, which maintains in real time the number of times each physical register number is referenced by uncommitted instructions. The reference counting rule is: for each instruction that references the physical register, the corresponding count is incremented by 1; after the instruction is committed, the corresponding count is decremented by 1. After the instruction is executed and written to the instruction commit queue (ROB, ReorderBuffer), the renaming module reads the original physical register number corresponding to the instruction and uses it as an index to query the reference count table to check the current reference status. If the query result is a reference count of 0, it means that the original physical register number has not been referenced by any older instruction, and the corresponding instruction execution has no abnormal state. The original physical register number is determined to meet the recycling criteria. Here, the older instruction is in the instruction execution stream and is earlier than the instruction currently to be recycled. If the query result is a reference count greater than 0, it means that the original physical register number has been referenced by other instructions, and it is determined that it has not met the recycling criteria. For example, in some architecture optimization designs, when executing the VMov xmm0 and xmm1 instructions, logical registers xmm0 and xmm1 are mapped to the same physical register (assuming physical register number 80). When the Load xmm0 instruction is subsequently executed, the physical register number corresponding to xmm0 is updated. However, the previous VMov instruction is an older instruction than this Load instruction. If physical register 80 is released at this point, xmm1 will lose its corresponding physical register resource and be unable to read data correctly, leading to an execution error. The reason for this is that the binding between logical and physical registers is dynamically updated. After a new physical register is bound to a logical register, the original physical register is unbound from it. However, there may still be uncommitted instructions referencing this original physical register (for example, instructions have been executed but not yet committed, and the results still exist in the original physical register). Only when all instructions referencing this original physical register have been committed can this original physical register be truly reclaimed.

[0044] During the renaming operation of instructions, the renaming module generates corresponding instruction commit information and stores it in the storage module. When the original physical register number is determined to meet the recycling criteria, the renaming module generates a structured physical register return token based on the original physical register number, the recycling determination result, and the instruction commit cycle information. This token includes a register identifier field (storing the original physical register number), a recycling status field (marked as "recyclable"), and a check field (storing the CRC check value). Both the physical register return token and the original physical register number are components of the instruction commit information, and they are immediately synchronized to the instruction commit queue after generation.

[0045] When the original physical register number is determined not to meet the recycling criteria, two schemes can be adopted. The first scheme involves the renaming module generating a return physical register token message consistent with the format of the recyclable scenario based on the original physical register number, the recycling determination result, and the instruction submission cycle information. The valid bit of the token is marked as "0," and the recycling status segment is marked as "unrecyclable." This invalid token, along with the original physical register number, is synchronized to the instruction submission queue for the physical register token management module to identify and skip subsequent recycling operations. The second scheme involves the renaming module not generating a return physical register token message, but only synchronizing the original physical register number and the "not meeting recycling criteria" status flag to the instruction submission queue. If the physical register token management module does not receive the corresponding token message, it defaults to determining that the original physical register number does not yet meet the recycling conditions and does not perform the free marker and free pool update operations.

[0046] In S4, the instruction commit phase refers to the core process phase in which the processor confirms the results of out-of-order execution of instructions in the original program order and triggers cleanup operations such as physical register reclamation.

[0047] The criteria for determining whether a command has been successfully submitted differ depending on its type. (See reference...) Figure 6 The flowchart illustrates the method for determining the completion and submission status of pipelined execution type instructions within a module. The method for determining whether an instruction of a pipelined execution type within a module has been completed and submitted includes the following steps: S41: When the instruction type is intra-module pipeline execution type, obtain the execution status information of the target functional module for the instruction; S42: When the execution status information of the target functional module for the instruction is "completed", the instruction is determined to have been submitted.

[0048] In S41 and S42, for the submission determination of pipelined instructions within a module, the instruction submission queue monitors the instruction execution status information output by the target functional module (floating-point or fixed-point module) in real time to obtain the final execution status of the instruction after it has flowed through the entire pipeline of the target functional module, including instruction fetch, decoding, computation, and write-back. The instruction submission control module pre-reads the execution status information in the instruction submission queue. When the execution status information monitored by the instruction submission queue indicates "completed," the instruction submission control module determines that all execution tasks of the instruction have been completed within a single target functional module. When the instruction is determined to be submitted, an instruction submission signal is sent to the instruction submission queue, and the subsequent physical register reclamation process is triggered simultaneously. This scheme relies on the characteristic of "independent completion by a single module" of pipelined instructions within a module, directly using the execution status of the target functional module as the basis for submission determination, without the need for status coordination of other modules. This simplifies the determination logic and ensures the timeliness of instruction submission, perfectly matching the technical characteristics of pipelined instructions within a module.

[0049] Reference Figure 7 The flowchart illustrates the method for determining the completion and submission status of cross-module non-pipelined execution type instructions. The method for determining whether a cross-module non-pipelined execution type instruction has been completed and submitted includes the following steps: S43: When the instruction type is a cross-module non-pipelined execution type, obtain the execution status information of the dedicated execution module for the instruction; S44: When the execution status information of the instruction by the dedicated execution module is "completed", it is determined that the instruction has been submitted.

[0050] In S43 and S44, for the submission determination of cross-module non-pipelined execution type instructions, the instruction submission queue obtains the execution status information output by the dedicated execution module in real time. The instruction submission control module pre-reads the execution status information in the instruction submission queue. When it detects that the execution status information output by the dedicated execution module is "completed," the instruction submission control module can determine that the entire execution task of the instruction has been completed, and then determines that the instruction has been submitted, sends an instruction submission signal to the instruction submission queue, and triggers the subsequent physical register reclamation process. This scheme is based on the technical characteristic of "multi-module collaborative completion" of cross-module non-pipelined execution type instructions, and adopts a dual-module status collaborative verification judgment logic, which not only ensures the accuracy of instruction submission determination, but also avoids submission misjudgment caused by the lack of status of a single module, and is fully adapted to the execution flow of this type of instruction.

[0051] In determining whether an instruction has been successfully submitted, a comprehensive judgment must be made based on both the instruction execution status and the validity of the submit signal. For pipelined instructions within a module, after obtaining the "execution completed" status output by the target functional module, the instruction submission queue needs to further check the validity of the submit signal. For non-pipelined instructions across modules, after confirming that the execution status of the dedicated execution module is "completed," the instruction submission queue also needs to verify the validity of the submit signal. If an exception or error occurs during the execution of the current instruction, the submit signal will be invalidated. In this case, the instruction cannot be submitted, and the subsequent physical register reclamation and release process will not be triggered. Only when the submit signal is valid can it be determined that the instruction has been successfully submitted, and the corresponding operations of the physical register token management module and the physical register release module be initiated.

[0052] The renaming module pre-counts all unreclaimed instructions, including the one in question, and calculates the number of original physical registers to be reclaimed in the current system, along with their corresponding register identifiers. This data constitutes instruction submission information, which is synchronized to the instruction submission queue in real time. The instruction submission control module pre-reads this information and, upon completion of instruction submission, synchronously sends a physical register token to the physical register token management module. Based on the pre-generated token, the physical register token management module initiates the physical register resource reclamation process. This module first verifies the integrity of the token, then extracts the original physical register number from the token and marks it as idle. The instruction submission information pre-read by the control module can also be used for physical register resource management, guiding subsequent instruction issuance decisions. When the number of available physical registers is insufficient (e.g., two physical registers are needed simultaneously, but fewer than two are available), the issuance of new instructions is paused. Once the physical register token management module completes the physical register idle marking and updates the idle physical register pool, instruction issuance resumes based on the synchronized resource data, achieving efficient cyclical reuse of physical register resources.

[0053] Furthermore, the renaming phase also includes: a renaming module generating instruction commit information based on the instruction renaming operation and storing it in a storage module; the instruction commit information including the original physical register number and the returned physical register token information. The instruction commit phase also includes: a physical register release module reading the original physical register number and the returned physical register token information from the storage module; generating a release flag based on the instruction commit status; and releasing the resources of the physical register to which the original physical register number belongs based on the original physical register number, the returned physical register token information, and the release flag.

[0054] During the instruction renaming phase, after the renaming module completes the physical register renaming operation for the instruction, it generates corresponding instruction commit information and stores the instruction commit information in a preset storage module. The instruction commit information includes the original physical register number corresponding to the instruction, the number of original physical registers reclaimed, and the physical register token information returned.

[0055] When an instruction is committed, the instruction commit control module also sends an instruction commit signal to the physical register release module. Upon receiving the instruction commit signal, the physical register release module detects that the instruction commit is complete, generates a corresponding release flag, and associates it with the original physical register number read from the storage module and the returned physical register token information. Using the original physical register number as an index, the returned physical register token information as the verification basis, and the release flag as the execution trigger condition, the physical register release module comprehensively cleans up the auxiliary soft information generated by the physical register during instruction execution. This includes deleting the historical mapping records corresponding to the physical register, uncommitted instruction reference caches, and residual status flag data. After cleanup, the physical register release module generates a cleanup completion receipt to ensure that there is no redundant residual information of the physical register, avoiding interference with subsequent renaming operations.

[0056] The physical register release module focuses on soft information cleanup, with the core objective of eliminating historical data residue in physical registers and ensuring the cleanliness of information during the renaming process. It does not directly participate in the marking and allocation of physical registers in their idle state. The physical register token management module, on the other hand, focuses on hardware resource reuse. Its core objective is to quickly add reclaimable physical registers to the idle pool, providing available resources for new instruction renaming and directly impacting instruction issuance efficiency.

[0057] Reference Figure 2 and Figure 8 The present disclosure provides a processor 1, which includes a renaming module 11, an instruction submission queue 12, an instruction submission control module 13, and a physical register token management module 14; The renaming module 11 is used to receive instructions and the logical register number of the instructions; Retrieve the original physical register number bound to the logical register number; When the original physical register number reaches the reclamation criterion, a physical register return token is generated and stored in instruction submission queue 12; The instruction submission control module 13 is used to pre-read the physical register token information in the instruction submission queue 12, and when the instruction is submitted, it sends the pre-read physical register token information to the physical register token management module 14. The physical register token management module 14 is used to mark the original physical register number as idle based on the received physical register token information and update it to the idle physical register pool.

[0058] Furthermore, the renaming module is also used to select a new physical register number from the pool of free physical registers when obtaining the original physical register number bound to the logical register number; Replace the original physical register number with the new physical register number and bind it to the logical register number.

[0059] Furthermore, the processor 1 also includes a target function module 15; When the instruction type is intra-module pipelined execution type: The target function module 15 is used to schedule and execute instructions, generate corresponding execution status information, and store it in the instruction submission queue 12; The instruction submission control module 13 is also used to pre-read the execution status information of the target function module 15 for the instruction from the instruction submission queue 12; When the execution status information of the target function module 15 for the instruction is "completed", it is determined that the instruction has been submitted. The intra-module pipeline execution type refers to completing the execution of instructions within the internal pipeline of a single target function module 15.

[0060] Furthermore, when the instruction type is an intra-module pipeline execution type: The target function module is used to perform a renaming operation on the instruction through the renaming module.

[0061] Furthermore, processor 1 also includes a dedicated execution module 16; When the instruction type is a cross-module non-pipelined execution type: Target function module 15 is used to perform a renaming operation on the instruction through the renaming module; The dedicated execution module 16 is used to perform dedicated functions on instructions, generate corresponding execution status information and store it in the instruction submission queue 12; The instruction submission control module 13 is also used to pre-read the execution status information of the instruction from the dedicated execution module 16 from the instruction submission queue 12; When the execution status information of the dedicated execution module 16 for the instruction is all "completed", it is determined that the instruction has been successfully submitted. Among them, the cross-module non-pipeline execution type refers to splitting the execution task of the instruction into the target functional module 15 and the dedicated execution module 16 to complete the task together, and the target functional module 15 does not carry the complete pipeline process of the instruction.

[0062] Furthermore, processor 1 also includes a storage module 17 and a physical register release module 18; The renaming module 11 is also used to generate instruction submission information based on the renaming operation of the instruction and store it in the storage module 17. The instruction submission information includes the original physical register number and the returned physical register token information. The physical register release module 18 is used to read the original physical register number and return the physical register token information from the storage module 17 during the instruction submission phase; Generate a release flag based on the status of the command completion and submission. Based on the original physical register number, the returned physical register token information, and the release flag, the resources of the physical register to which the original physical register number belongs are released.

[0063] In existing technologies, the instruction submission control module only reads the instruction submission information from the storage module after confirming instruction submission, then calculates the returned physical register token information, and finally feeds it back to the physical register token management module. This results in a slow return speed for physical register resources. This solution, however, adds the function of calculating the returned physical register token information to the renaming module in advance, and allows the instruction submission control module to pre-read the instruction execution status information and instruction submission information. After confirming instruction submission, the instruction submission control module can immediately feed back the pre-read returned physical register token information to the physical register token management module, thus accelerating the return speed of physical register resources.

[0064] At the hardware implementation level, this solution adds a dedicated circuit connection between the renaming module 11 and the instruction submission queue 12 for transmitting instruction submission information and submission completion notifications. The instruction submission control module 13 does not need to read instruction submission information from the storage module 17. Simultaneously, the original execution status information transmission circuit in the instruction submission queue 12 is reused, enabling it to also transmit instruction submission information, thus achieving synchronous and parallel feedback of instruction submission information and execution status information. This design does not require a large amount of new hardware resources; by simply reusing circuits and supplementing local links, it effectively reduces the number of interactions and transmission latency between modules, improving the overall communication efficiency of the architecture.

[0065] The various variations and specific examples of the physical register resource reclamation method provided above are also applicable to the processor provided in this disclosure. Through the foregoing detailed description of the physical register resource reclamation method, those skilled in the art can clearly understand the implementation method of the processor. For the sake of brevity, they will not be described in detail here.

[0066] A computer device according to embodiments of the present disclosure includes a memory and a processor. The memory is used to store non-transitory computer-readable instructions. Specifically, the memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, flash memory, etc.

[0067] The processor may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the computer device to perform desired functions. In one embodiment of this disclosure, the processor is used to execute computer-readable instructions stored in the memory, causing the computer device to perform all or part of the steps of the physical register resource reclamation methods of the foregoing embodiments of this disclosure.

[0068] Those skilled in the art will understand that, in order to solve the technical problem of how to achieve a good user experience, this embodiment may also include well-known structures such as communication buses and interfaces, and these well-known structures should also be included within the protection scope of this disclosure.

[0069] like Figure 9 This is a schematic diagram of a computer device provided for an embodiment of the present disclosure. It illustrates a structural schematic diagram suitable for implementing the computer device in the embodiments of the present disclosure. Figure 9 The computer device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0070] like Figure 9 As shown, a computer device may include a processor (such as a central processing unit, graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) or programs loaded from storage devices into random access memory (RAM). The RAM also stores various programs and data required for the operation of the computer device. The processor, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0071] Typically, the following devices can be connected to the I / O interface: input devices, such as sensors or visual information acquisition devices; output devices, such as displays; storage devices, such as magnetic tapes or hard drives; and communication devices. Communication devices allow the computer device to communicate wirelessly or wiredly with other devices (such as edge computing devices) to exchange data. Although Figure 9A computer apparatus with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or included alternatively.

[0072] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from ROM. When the computer program is executed by a processor, all or part of the steps of the physical register resource reclamation method of embodiments of this disclosure are performed.

[0073] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0074] A computer-readable storage medium according to embodiments of the present disclosure stores non-transitory computer-readable instructions. When these non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the physical register resource reclamation methods described in the foregoing embodiments of the present disclosure are performed.

[0075] The aforementioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or portable hard drive), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).

[0076] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0077] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0078] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0079] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0080] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0081] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0082] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0083] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A method for reclaiming physical register resources, characterized in that, include: During the renaming phase, the instruction and its logical register number are received. Obtain the original physical register number bound to the logical register number; When the original physical register number reaches the recycling standard, a physical register return token is generated; During the instruction submission phase, when the instruction is submitted, the original physical register number is marked as idle based on the pre-generated return physical register token information and updated to the idle physical register pool.

2. The physical register resource reclamation method according to claim 1, characterized in that, When the original physical register number reaches the recycling criterion, a physical register token is generated, including: Detect the reference status of the original physical register number; If the original physical register number is not referenced by any uncommitted instruction, the original physical register number is determined to have met the reclamation criteria, and a physical register token is generated.

3. The physical register resource reclamation method according to claim 1, characterized in that, The types of instructions include intra-module pipelined execution types and cross-module non-pipelined execution types; The intra-module pipeline execution type refers to completing the execution task of instructions within the internal pipeline of a single target functional module; The cross-module non-pipeline execution type refers to splitting the execution task of the instruction into a target functional module and a dedicated execution module to complete the task in collaboration, and the target functional module does not carry the complete pipeline process of the instruction.

4. The physical register resource reclamation method according to claim 3, characterized in that, When the type of the instruction is intra-module pipeline execution, obtain the execution status information of the target functional module for the instruction; When the execution status information of the target functional module for the instruction is "completed", it is determined that the instruction has been submitted.

5. The physical register resource reclamation method according to claim 3, characterized in that, When the type of the instruction is a cross-module non-pipelined execution type, obtain the execution status information of the dedicated execution module for the instruction; When the execution status information of the instruction by the dedicated execution module is "completed", it is determined that the instruction has been submitted.

6. The physical register resource reclamation method according to claim 1, characterized in that, The renaming phase also includes: Select a new physical register number from the pool of free physical registers; The original physical register number is replaced with the new physical register number and bound to the logical register number. Based on the updated mapping relationship between the logical register number and the physical register number, the instructions are executed out of order.

7. The physical register resource reclamation method according to claim 1, characterized in that, The renaming phase also includes: Based on the renaming operation of the instruction, instruction submission information is generated and stored in the storage module. The instruction submission information includes the original physical register number and the returned physical register token information. The instruction submission phase also includes: Read the original physical register number and the returned physical register token information from the storage module; Based on the submitted status of the instruction, a release flag is generated; Based on the original physical register number, the returned physical register token information, and the release flag, the physical register to which the original physical register number belongs is released.

8. A processor, characterized in that, The processor includes a renaming module, an instruction submission queue, an instruction submission control module, and a physical register token management module. The renaming module is used to receive instructions and the logical register number of the instructions; Obtain the original physical register number bound to the logical register number; When the original physical register number reaches the recycling standard, a physical register return token is generated and stored in the instruction submission queue; The instruction submission control module is used to pre-read the physical register token information in the instruction submission queue, and when the instruction is submitted, it sends the pre-read physical register token information to the physical register token management module. The physical register token management module is used to mark the original physical register number as idle based on the received returned physical register token information and update it to the idle physical register pool.

9. The processor according to claim 8, characterized in that, The processor also includes a target function module; When the type of the instruction is an intra-module pipeline execution type: The target functional module is used to schedule the execution of the instructions, generate corresponding execution status information, and store it in the instruction submission queue; The instruction submission control module is also used to pre-read the execution status information of the target functional module for the instruction from the instruction submission queue; When the execution status information of the target functional module for the instruction is "completed", it is determined that the instruction has been submitted. The intra-module pipeline execution type refers to completing the execution of instructions within the internal pipeline of a single target functional module.

10. The processor according to claim 8, characterized in that, The processor also includes a target function module and a dedicated execution module; When the type of the instruction is a cross-module non-pipelined execution type: The target functional module is used to perform a renaming operation on the instruction through the renaming module; The dedicated execution module is used to perform dedicated functions on the instructions, generate corresponding execution status information, and store it in the instruction submission queue; The instruction submission control module is also used to pre-read the execution status information of the instruction from the dedicated execution module from the instruction submission queue; When the execution status information of the instruction by the dedicated execution module is "completed", it is determined that the instruction has been submitted. The cross-module non-pipeline execution type refers to splitting the execution task of the instruction into a target functional module and a dedicated execution module to complete the task in collaboration, and the target functional module does not carry the complete pipeline process of the instruction.

11. The processor according to claim 8, characterized in that, The processor also includes a storage module and a physical register release module; The renaming module is also used to generate instruction submission information and store it in the storage module based on the renaming operation of the instruction. The instruction submission information includes the original physical register number and the returned physical register token information. The physical register release module is used to read the original physical register number and the returned physical register token information from the storage module during the instruction submission phase. Based on the submitted status of the instruction, a release flag is generated; Based on the original physical register number, the returned physical register token information, and the release flag, the physical register to which the original physical register number belongs is released.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the physical register resource reclamation method according to any one of claims 1-7.

13. A computer program product comprising computer instructions, characterized in that, When executed by the processor, the computer instruction implements the steps of the physical register resource reclamation method according to any one of claims 1-7.

Images