Efficient hybrid freelist for fast register name allocation

Abstract

Methods, systems, and apparatus for maintaining a hybrid freelist for register renaming are disclosed. One of the methods comprises the step of maintaining a hybrid freelist representing physical registers available for register renaming, wherein the hybrid freelist comprises a plurality of ordered entries, each entry comprising a bit pair for each physical register among the plurality of physical registers, and the bit pair for each entry comprises an effective bit and a commit bit representing the effective state and the commit state for the physical register, respectively. The head pointer and tail pointer of the freelist are used to perform sequential assignment of free-state physical register names from the plurality of entries of the freelist.

Description

Background Technology

[0001] Modern out-of-order (OOO) processing utilizes register renaming to eliminate incorrect data dependencies, allowing more instructions to be executed in parallel, which often entails executing instructions out of order. In this specification, register renaming refers to assigning a physical register name (PRN) to a logical register name (LRN) in an instruction currently being executed. When register renaming is used, subsequent instructions writing to a logical register may be executed before or in parallel with other instructions using the same logical register name or reading from it, because the register renaming process has assigned different underlying physical registers to the corresponding logical register name.

[0002] A 'freelist' is a microarchitecture component of a processor that maintains a pool of available physical resources, such as physical registers. In this specification, available resources, such as physical registers, are described as being free, or the corresponding PRN is a free PRN. Thus, the freelist may provide a free PRN to allocate physical registers for register renaming. When a PRN is no longer needed, it may be returned to the freelist for reuse.

[0003] Freelist size and control logic complexity are major considerations in processor design, affecting silicon area, power, and performance in machines using out-of-order processing.

[0004] Traditionally, the use of a first-in-first-out (FIFO) queue and a bit vector have been used as the two main methods for implementing a freelist in out-of-order processors. In a FIFO freelist, PRNs are allocated one by one starting from the beginning of the freelist and are returned to the end when they are no longer needed. Therefore, in a pure FIFO freelist, PRNs are allocated based on age, with earlier PRNs that have not been allocated for a longer period being given priority over subsequent PRNs that were allocated more recently. However, since the entire PRN, which can be up to 10 bits or longer, is stored in the FIFO, multi-bit PRN entries must be written to return a PRN to the FIFO freelist. Consequently, the frequent writing of multi-bit PRN entries in a FIFO freelist increases area and power requirements, which causes serious problems in terms of performance, cost, and scalability.

[0005] On the other hand, since bit vector freelists use a single bit to represent each PRN, they have smaller storage requirements than FIFO freelists. However, bit vector freelists require very complex control logic for routine tasks. For example, performing flush recovery after an incorrectly predicted branch requires substantially more complex logic in a bit vector freelist than in a FIFO freelist because the bit vector freelist does not contain age information for each PRN. Furthermore, as the total number of PRNs increases, the complexity of finding available PRNs also increases, which further increases area and power requirements. For example, when providing multiple available entries from a bit vector freelist, finding the first available PRN or the first pair of available PRNs becomes more difficult as the request frequency and vector length increase, causing a significant scalability bottleneck.

[0006] This specification describes a hybrid freelist for fast and efficient register renaming that offers many other additional benefits as well as the advantages of both FIFO and bit vector freelists. A hybrid freelist maintains a set of PRN entries that require only a few bits of storage space. As an example, each PRN entry may have 1) a valid bit indicating whether the corresponding PRN is free or allocated, and 2) a commit bit indicating whether the PRN is in an architectured state, which means that the data in the corresponding physical register is part of the machine's permanent state at a given time and the corresponding instruction is no longer flushed or re-executed.

[0007] In this specification, a PRN entry is a structure that stores data for which a PRN can be generated based on the location of the PRN entry within the freelist. When described in this specification that the freelist generates a PRN, it means generating a PRN using the location of the PRN entry, and does not mean that the freelist itself stores the entire PRN.

[0008] A hybrid freelist maintains a head pointer indicating where in the freelist to search for the next free PRN. In some implementations, the head pointer advances in units of freelist segments consisting of multiple PRN entries, rather than in units of individual PRN entries. A hybrid freelist also maintains a tail pointer indicating the entry corresponding to the most recent free PRN available for reallocation. PRNs located before the head pointer and after the tail pointer can be allocated in order, skipping over PRNs that have already been allocated but have not yet been returned.

[0009] The tail pointer is generally used to protect the sequential array of allocated PRN entries. Therefore, the head pointer is not allowed to overtake the tail pointer when allocating PRN entries. By maintaining the head and tail pointers, the processor can effectively perform circular allocation of PRNs by traversing the free list in order while skipping already allocated PRNs.

[0010] The head pointer can be used for efficient flush recovery. When recovering PRNs during flush recovery, the head pointer is simply redirected to the flush point, and the valid bits for the PRNs between the flush point and the old head pointer are reset, except for PRNs in an architectured state as indicated by their commit bits.

[0011] Specific embodiments of the subject of the invention described herein may be implemented to realize one or more of the following advantages. A hybrid freelist achieves the advantages of both a FIFO freelist and a bit vector freelist while mitigating their respective disadvantages. For example, a hybrid freelist can efficiently clear allocated PRNs during flush recovery. Additionally, since the hybrid freelist contains simplified PRN information, it requires less storage space. Thus, the hybrid freelist achieves area and power reductions that cannot be achieved with an equivalent FIFO freelist. Additionally, the hybrid freelist has full scalability because, unlike in a strict bit vector freelist, flush recovery does not become excessively difficult even as the number of PRNs increases. The freelist described herein may also efficiently allocate groups of PRNs to meet the bandwidth requirements of a hyperscalar processor. For example, the freelist can ensure that all N available PRNs are already queued at every cycle by continuously filling the input staging buffer and the output staging buffer.

[0012] The hybrid freelist described herein may also be used for register renaming for multiple different types of physical registers. This allows the processor to maintain a single freelist rather than multiple freelists, thereby saving power and reducing the required silicon area. For example, the freelist may be used for register renaming for both integer registers and flag registers. The freelist may also be used for register renaming for integer registers and floating-point registers, even if the sizes of the individual physical register files differ. Furthermore, even when the freelist is used for register renaming for multiple different types of physical registers, the underlying scalable flush recovery mechanism remains largely unchanged and can be used to return all types of physical register names to the freelist after a flush.

[0013] This specification also describes a method in which a freelist can be used to borrow already allocated physical register names. This configuration increases processor efficiency and mitigates the possibility of the processor running out of register space, all of which are achieved without adding additional naming storage space.

[0014] This specification also describes a method by which a processor can improve floating-point instruction bandwidth by introducing a new microarchitecture structure called an architectured floating-point physical register file, which is an auxiliary physical register file for maintaining the values ​​of floating-point registers whose names are fixed in an architectured map table.

[0015] This specification also describes a technique using a sequential structure of a hybrid freelist to reduce processor power through clock gating. Since the freelist essentially retains information regarding physical registers being used during execution, the processor can utilize this information to perform highly precise clock gating on unused physical registers, thereby reducing power without substantially affecting processor performance.

[0016] Details regarding one or more embodiments of the subject matter of the invention of this specification are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages of the subject matter of the invention will become apparent from the detailed description, drawings, and claims. Brief explanation of the drawing

[0017] Figure 1a is a schematic diagram of an exemplary lifecycle of a PRN in a hybrid freelist. Figure 1b is an exemplary schematic diagram of a hybrid freelist. Figure 2 is a diagram illustrating an exemplary process for allocating PRN from a hybrid freelist. Figure 3 is a diagram illustrating an exemplary process of deallocating a PRN to a hybrid freelist. Figure 4 illustrates an exemplary flush recovery using a hybrid freelist. Figure 5 is a diagram illustrating an exemplary process for implementing a hybrid freelist. Figure 6 is a diagram of a processor system having a shared freelist using a single namespace of physical register names for two different physical register files. Figure 7 is a diagram illustrating how a system can maintain a single shared freelist for integer registers and flag registers. Figure 8 is a flowchart of an exemplary process for maintaining a shared freelist. Figure 9 illustrates PRN borrowing in a system having two sets of physical registers. Figure 10 is a flowchart of an exemplary process for borrowing physical register names. Figure 11 illustrates an exemplary technique for associating a PRN entry with a floating-point register. FIG. 12 is a diagram illustrating a method by which a system can maintain a shared free list between integer registers and floating-point registers. FIG. 13 is a flowchart of an exemplary process for maintaining a virtual PRN entry during flush recovery when managing a number of different register sets. FIG. 14 is a flowchart of an exemplary process for allocating a virtual PRN for a freelist that manages a number of different register sets. Figure 15 illustrates a sliding window for PRN within a freelist. Figure 16 illustrates a data structure for processing a stuck floating-point PRN. FIG. 17 is a flowchart of an exemplary process for managing a virtual PRN for a freelist that manages a number of different register sets. FIG. 18 illustrates a hybrid freelist having 512 entries divided into banks of 16 entries each. Figure 19 is a flowchart of an example of clock gating a physical register file based on a freelist. In various drawings, similar reference numbers and names represent similar elements. Specific details for implementing the invention

[0018] FIG. 1a is a schematic diagram of an exemplary lifecycle (100) of a PRN maintained by a hybrid freelist. The lifecycle (100) includes three stages maintained by three corresponding structures, which are a hybrid freelist stage (102), a reorder buffer (ROB) stage (130), and an architectured map table (AMT) stage (140). Throughout non-sequential processing, the PRN cycles between these three stages.

[0019] In the freelist stage (102), the PRN starts in a free state. The free PRN can then be allocated from the hybrid freelist, renamed, and transitioned to the ROB stage (130), which stores the mapping between the PRN and its corresponding LRN in instruction order. When the PRN exits the freelist stage (102) and transitions to the ROB stage (130) or the AMT stage (140), the PRN is generally no longer free and therefore cannot be allocated to another logical register until the PRN is returned to the freelist stage (102). However, in certain situations described in detail below, the PRN may be reassigned to another logical register before being returned to the freelist.

[0020] ROB can also associate each PRN-LRN mapping with a corresponding location within the freelist, allowing the head pointer of the freelist to efficiently snap back to the flush point when a flush occurs.

[0021] When the instruction corresponding to an entry in the ROB completes execution and reaches the head of the ROB, the instruction is committed by retiring the PRN to the AMT, and the AMT also stores the mapping between the PRN and its corresponding LRN. The data stored by the physical register corresponding to the PRN is now part of the machine's permanent state and is not flushed or re-executed.

[0022] When a subsequent instruction writes to a logical register of a PRN maintained within the AMT, the PRN mapping is no longer needed, the PRN is evicted from the AMT, and returns to the hybrid freelist, where the PRN re-enters the hybrid freelist stage (102).

[0023] A hybrid freelist may maintain PRN entries having a pair of values, for example, a pair of bits, to track the valid and committed states of each PRN. The 'valid' bit can be used to track the valid state of a PRN, which indicates whether the PRN is free for renaming. Thus, the valid state of a PRN can be referred to as being in a free or allocated state.

[0024] The 'Commit' bit can be used to track the commit state of a PRN, and the commit state indicates whether the instruction using the assigned PRN has been committed. This means that the value in the corresponding physical register has become the permanent state of the program being executed by the processor and will no longer be flushed or re-executed. Therefore, the commit state of a PRN can be referred to as being in a committed state or an uncommitted state. A change in the commit state from an uncommitted state to a committed state generally corresponds to the PRN exiting ROB and entering AMT.

[0025] Accordingly, a PRN or a corresponding PRN entry may be referred to herein as having a free or allocated state, which may indicate the effective bit value of the PRN entry. Similarly, a PRN or a corresponding PRN entry may be referred to as having a committed or uncommitted state of the PRN entry, which may indicate the commit bit value of said PRN entry.

[0026] In some cases, the valid bit and commit bit have binary values, where '1' represents a set value and '0' represents a cleared value. A set value for the valid bit, e.g., '1', may indicate that the PRN has been allocated for renaming, whereas a set value for the commit bit may indicate that the PRN has been retired to the AMT. In some cases, a cleared valid bit value, e.g., '0', and a set commit bit value, e.g., '1', would indicate an invalid or improper state, as this would imply that the PRN was committed before being allocated. While such a situation is not expected to occur, if it does, the processor may enter a fault state to restore the integrity of the freelist. A table showing exemplary combinations of valid and commit bit values ​​is presented in FIG. 1a. In an alternative implementation, the values ​​considered to be set and cleared, or high and low, may be reversed.

[0027] In some implementations, the availability of PRNs can be configured dynamically rather than explicitly expressed. For example, instead of maintaining an explicit valid bit for each PRN, the free status for each PRN can be determined using a freelist head pointer and a tail pointer. In this case, the head pointer indicates the freelist area for searching for the PRN to be allocated. Additionally, the commit state of a PRN can be configured by checking the AMT rather than maintaining a commit bit. However, if the processor has hundreds of physical registers, simply maintaining an explicit commit bit in the freelist can often be faster than searching the AMT.

[0028] FIG. 1b is an exemplary schematic diagram (101) of a hybrid freelist (132). The hybrid freelist (132) includes a set of PRN entries representing a PRN. Each PRN entry has a valid bit (104) and a commit bit (106). Additionally, the hybrid freelist (132) includes a head pointer (108) and a tail pointer (110).

[0029] When a PRN needs to be allocated in out-of-order processing, the hybrid freelist (132) will use a head pointer (108) to find a PRN entry for the PRN that can be allocated. FIG. 1b illustrates a single PRN entry at the head pointer (108) within the hybrid freelist (132), but the head pointer within the hybrid freelist can be implemented as a coarse-grained pointer that moves in segments of multiple PRN entries. For example, FIG. 1b also illustrates a way in which a set of PRN entries within the freelist (132) can be implemented as a bank (116) as the head pointer moves in bank units. In some implementations, the size of each bank is based on the processor's bandwidth. For example, if the processor needs to rename 10 registers per cycle, the freelist can have a bank size of 10 PRN entries, or a bank size of more than 10 PRN entries to account for PRNs that are still in a committed state. Typically, each instruction writes to only a single logical register, and thus the processor's instruction bandwidth typically corresponds to the required PRNs that must be generated per cycle.

[0030] The tail pointer (110) is updated as the PRN retires from the ROB. The tail pointer (110) is updated when the next PRN entry retires from the ROB by having a state of {0,0} or {1,1} for its effective bit and commit bit. This means that the PRN retired from the ROB without entering the AMT, or that the instruction using the PRN committed and the PRN entered the AMT. Alternatively, or additionally, when the tail pointer moves to a bank of PRN entries, the tail pointer is updated when all entries in the next bank have a state of {0,0} or {1,1}. Thus, the tail pointer (110) points to the most recent PRN entry or the most recent bank of PRN entries that can be reassigned.

[0031] On the other hand, the head pointer points to the PRN entry or PRN entry bank that is the oldest PRN that can be allocated, which corresponds to the PRN that has not been used for the most cycles.

[0032] As described above, the system maintains the tail pointer (110) to preserve the sequential arrangement of PRN entries in the free list by preventing the head pointer (108) from overtaking the tail pointer (110). This is important for maintaining or deriving age information for PRN entries, because if an architectured PRN returned to the free list is reallocated, it may be impossible or impractical to determine the age of the corresponding PRN entry at the time of a flush. Maintaining the tail pointer (110) also improves power performance by preventing the head pointer and staging buffer from being continuously updated across multiple PRN entries that are not allocatable free.

[0033] When a PRN entry is read from the hybrid freelist (102), a decoding process is performed to generate a corresponding PRN from the location of the PRN entry within the freelist. This process saves storage space by allowing the freelist to efficiently store 2 bits per PRN instead of storing all bits of each PRN.

[0034] A process that uses pointers to sequentially pass through PRN banks is highly scalable. That is, by using a head pointer (108) and a tail pointer (110), any number of PRNs can be allocated from the hybrid freelist without excessively increasing processing requirements.

[0035] In some implementations, the freelist continuously fills one or more staging buffers so that available PRNs are always ready in each cycle. The input staging buffer receives PRN entries from the bank indicated by the head pointer. Then, the output staging buffer is filled with the full physical register number corresponding to the PRN entries in the input staging buffer. In the input staging buffer or the output staging buffer, already allocated PRN entries, for example as indicated by the valid bit, may be removed. In some cases, the input staging buffer contains only the valid bit (104) value of each PRN entry identified from the hybrid freelist (102). In other words, the input staging buffer may essentially be a bit vector indicating which PRN is free in the bank indicated by the head pointer. Then, the position of the set bit in the input staging buffer and the position of the head pointer may be used to fill the output staging buffer with the full PRNs. For example, the output staging buffer may contain banks of 16 different PRNs. In other cases, the buffer may be expanded to include a different number of PRNs and / or bits. The operation of the staging buffer will be described later with reference to FIG. 2.

[0036] FIG. 2 is a diagram illustrating an exemplary process (200) for allocating a PRN from a hybrid freelist (202). The exemplary process, as well as other processes described herein, may be implemented using digital logic circuits of a processor, for example, a non-sequential processor.

[0037] In this example, for convenience of explanation, each PRN entry in the freelist (202) is represented as having a single valid bit, but as described above, hybrid freelist entries may typically also have a commit bit. The processor includes an input staging buffer (204) and an output staging buffer (206). In some cases, when a PRN bank identified by the head pointer is read out, PRNs within the bank that can be allocated (e.g., when the valid bit (104) is cleared (e.g., '0') or an alternative availability state) are expanded into PRNs from a series of input staging buffers (204) and output staging buffers (206). This is achieved by placing PRN entries from the bank indicated by the head pointer into the input staging buffer (204). For example, as illustrated in FIG. 2, the input staging buffer (204) may contain 16 bits, where each bit corresponds to the valid bit value of a PRN entry different from the bank indicated by the head pointer (108).

[0038] Next, physical register names corresponding to PRN entries in the input staging buffer (204) are filled into the output staging buffer (206). Physical register names can be generated by the location of the PRN entry in the free list. In some implementations, the location can be reconstructed by adding the offset of the PRN entry in the input or output staging buffer or in the PRN entry bank to the location of the head pointer. Assuming the PRN length is 10 bits, the output staging buffer (206) may contain 10-bit PRNs for all free PRN entries in the input staging buffer (204), thereby converting the PRN entries into actual PRNs. For example, from 16 bits in the input staging buffer (204), the system may generate up to 16 full 10-bit PRNs in the output staging buffer (206).

[0039] As part of this process, 'holes' in the input staging buffer caused by PRNs that are unavailable based on the valid bit are essentially decompressed, and as a result, the output staging buffer stores only the PRNs of PRN entries with cleared valid bits.

[0040] After that, the processor can use the available PRNs in the output staging buffer (206) for renaming, for example, assigning the PRNs to logical register names and storing each assigned PRN-LRN mapping in the ROB (302).

[0041] FIG. 3 is a diagram illustrating an exemplary process (300) for deallocating a PRN to a hybrid freelist (102) after it has been retired from the ROB and / or evicted from the AMT (304). As previously described, after the PRN is allocated, the value of the associated PRN entry valid bit (104) can be set to '1'.

[0042] During out-of-order processing, the PRN mapping between the PRN and LRN will remain in the ROB (302) until the associated instruction is committed and the PRN-LRN mapping is retired or flushed to the AMT. When the PRN is retired, the value of the commit bit (106) of the associated PRN entry is set to '1' (Operation 306), which indicates that the instruction for the PRN has been committed and the PRN has entered the AMT (304) (Operation 308). As discussed above, the AMT (304) retains the PRN-LRN mapping for the committed PRN, and any committed PRN entering the AMT (304) for the same logical register will evict any previous PRN mapping for that logical register. Thus, typically, the size of the AMT (304) is based on the number of logical registers in the instruction set, whereas the size of the ROB (302) is much larger because there are more physical registers than logical register names in the instruction set. When a PRN is evicted from the AMT (304), the values ​​of the associated valid bit (104) and commit bit (106) are cleared back to, for example, '0', to indicate that the PRN is now available for allocation (operation 310).

[0043] FIG. 4 illustrates an exemplary flush recovery using a hybrid freelist (102). In some cases, the PRN needs to be returned from the ROB (302) to the hybrid freelist (102) or deallocated. This process is referred to as flush recovery. Flush recovery may be performed, for example, when an instruction is executed speculatively along an incorrect control flow path, for example, an incorrectly predicted branch.

[0044] During flush recovery, the flush point is assigned to a point within the hybrid freelist (102), and the head pointer (108) is redirected to this new point. In some implementations, the flush point is the point where the write instruction for a specific PRN and all subsequent PRNs are invalidated from the ROB. Any PRN after the flush point and before the original head pointer (108) (e.g., the head pointer (108) before redirection) has its valid bit (104) cleared, for example, to '0', except for PRNs within the AMT (304) that are still in use, as indicated by the commit bit being set.

[0045] In some cases, to support efficient flush recovery, checkpoints for PRN pointers may be continuously created during the dispatch process (Operation 402). For example, in the dispatch process, the value of the current head pointer (108) plus an offset value may be associated with each PRN entering the ROB (302). Alternatively, or additionally, PRN pointers may be stored in other structures linked to the ROB, such as a reservation station or an issue queue, to name just a few examples, or in a structure that tracks instructions in progress. In other words, the system may use any appropriate structure to collect PRNs that have been allocated but not yet committed within the AMT, and the corresponding PRN entries are returned to the freelist when a flush occurs.

[0046] When flush recovery begins, the current checkpoint is indicated by the oldest PRN to be flushed from the ROB (302). Then, the head pointer of the freelist can be reset to the flush point by using the pointer of that ROB entry (action 404). If the head pointer points to a bank of PRN entries, an offset can be used to determine which of the PRN entries in the bank are part of the flush. In some implementations, the input and output staging buffers are also cleared so that they can be refilled with PRN data from their new flush point. In some cases, the flush recovery procedure is limited for the allocated time to prevent a crash with the ROB (302).

[0047] By maintaining checkpoints, flush recovery can be performed efficiently without the need to exhaustively search for PRNs affected during the flush. The flush recovery process in the hybrid freelist (102) also has high scalability because the flush recovery performance is minimally affected even as the freelist size increases. In other words, even if the freelist increases tenfold, the flush recovery process can still be just as fast. This is very different from the bit vector freelist, where flush recovery becomes more computationally intensive as the number of PRNs increases, and becomes more complex and time-consuming as the ROB size increases. By using checkpoints in the ROB, there is no need for the ROB or other structures to separately track the PRNs being processed to determine and indicate the set of PRNs affected by the flush (as in the case of the bit vector freelist).

[0048] FIG. 5 is a diagram illustrating an exemplary process (500) for implementing a hybrid freelist. The process may be performed by a processor configured according to the present specification. For convenience, the process is described as being performed by a system.

[0049] The system uses the freelist head pointer to search for a free PRN (e.g., a valid bit with a value of '0') (510). As previously described, a PRN in the hybrid freelist is associated with both a valid bit and a commit bit, which indicate which stage the PRN is in. The valid bit indicates whether the PRN is currently in use.

[0050] The hybrid freelist also maintains head and tail pointers. The head pointer indicates the next PRN entry or set of entries to be allocated, while the tail pointer indicates the next PRN to be retired, which is written by the oldest executing instruction writing to the register. In some implementations, the head pointer points to a bank of PRN entries, and the head pointer moves one bank of PRN entries.

[0051] The system allocates a PRN and modifies the free status of the PRN (520). Then, the PRN is allocated, and the valid bit is updated to a valid bit value, for example, '1', to indicate that the PRN is no longer free. As described above, once the PRN is allocated from the hybrid freelist, the PRN is cycled through the ROB, which maintains a sequential list of instructions to which the PRN was allocated and the PRN-LRN mapping for those instructions.

[0052] The system retires the PRN and modifies the commit state (530). At the time of commit, the PRN is retired and the PRN-LRN mapping is saved to the AMT. When this occurs, the commit bit of the PRN entry is modified to indicate that the PRN has retired (e.g., by setting the value of the commit bit to '1'). As previously mentioned, when the PRN transitions to the AMT, the PRN can evict the preceding PRN assigned to the same LRN for the preceding instruction.

[0053] The system evicts PRN from AMT and modifies the free of PRN (540). When PRN is evicted from AMT and returned to the hybrid freelist, both the valid bit and the commit bit are updated to indicate that PRN is free, for example, the values ​​of both the valid bit and the commit bit can be set to '0'.

[0054] This specification also describes how freelists can be used for several different types of physical registers, each having its own physical register namespace. For example, some processors have different physical register files, each with its own namespace. Instructions may refer to different logical register names corresponding to different underlying physical register files. While it would be possible to maintain a separate freelist for each individual physical register file, in many situations this would result in inefficient and redundant hardware.

[0055] Instead, the technique described herein enables a processor to maintain and assign physical register names for multiple different register files using a single shared freelist. When a physical register name is required for register renaming during instruction execution, the freelist may assign the physical register name using a single shared namespace applicable to both types of physical register files. Additionally, for some instructions that reference multiple different types of registers, the freelist may assign the same physical register name to both types of logical registers within the instruction.

[0056] One major advantage of using a shared freelist for multiple different types of physical register files is that only a single flush recovery mechanism needs to be executed when a flush occurs. Additionally, sharing the freelist between different register types saves hardware resources without significantly impacting performance.

[0057] FIG. 6 is a diagram of a processor system (600) having a shared freelist using a single namespace of physical register names for two different physical register files. The system (600) includes a first physical register file (610) having physical registers (PR1, PR2 to PRN). The system (600) also includes a second register file (620) having physical registers (FR1, FR2 to FRN).

[0058] The system (600) also includes a shared freelist (630) that maintains physical register name entries (PRN1, PRN2 to PRNN). The PRN entries for this single shared namespace can be used for register renaming for both the first physical register file (610) and the second physical register file (620).

[0059] Typically, each physical register file has its own built-in map table (AMT). Thus, the physical register file (610) will have its own AMT, and the second physical register file (620) will have its own AMT. Since the two physical register files share the same namespace for register renaming, the system can ensure that physical register names are not returned to the freelist (630) unless they are expelled from both AMTs or do not exist.

[0060] One example of a separate type of physical register file is a special register file. In some processors, special physical registers may be used to maintain information regarding the processor's state. These special registers are often maintained in a physical register file separate from the physical register files for integers or floating-point numbers.

[0061] An example of a special register is the flag register, which is sometimes referred to as the application program status register. In this specification, the flag register will refer to any special register that may be referenced by a logical register name within an instruction set having a physical register file different from an integer register file or a floating-point register file.

[0062] In some processors, there is only one logical flag register that an instruction can write to, but there are tens or hundreds of physical flag registers that can be assigned to that single logical flag register. This is because, in out-of-order execution, flag registers can be used to maintain the conditional state of many different instruction branches currently in execution. Therefore, even if an instruction set has only one logical flag register, register renaming can be used to maintain the state of all executing conditional branches.

[0063] FIG. 7 illustrates a method in which a system (700) can maintain a single shared freelist (730) for integer registers and flag registers. The system (700) includes a set of integer registers (710) and a set of flag registers (720). The system also includes a hybrid freelist (730) that maintains a single physical register namespace for both the integer registers (710) and the flag registers (720). The hybrid freelist (730) includes PRN entries that include a valid bit and a commit bit, respectively. The integer register file (710) has its own integer AMT (740). The flag register file (720) also has its own flag AMT (750).

[0064] As previously mentioned, the valid bit indicates whether the physical register name is free for register renaming or is already allocated. The commit bit indicates whether the physical register name is currently in the AMT. As previously mentioned, these two bits indicate how the system allocates physical register names and how the system returns physical register names to the freelist when a flush occurs, which essentially involves returning the PRN allocated after the flush point that is not yet included in the AMT.

[0065] In this exemplary system, the integer register and the flag register share the freelist (730) by using the valid bit explicitly expressed in the PRN entry of the freelist (730).

[0066] The system (700) can track the commit state of the PRN assigned to the integer register using the integer commit bit (706) of the PRN entry. However, for the flag PRN, the system (700) can reconstruct the virtual flag commit bit from the PRN entry and from the state of the flag AMT (750). This eliminates the need for the system to maintain a separate free list for the flag register and keeps the size of the PRN entry 2 bits each.

[0067] In this example, the flag AMT (750) has only a single entry, because in this example, the flag register has only a single logical register within the instruction set. Therefore, the physical-logical register name mapping within the flag AMT (750) requires only a single entry. Additionally, if only a single logical flag register exists, the flag AMT (750) only needs to store the physical register name and does not need to store the entire mapping from the physical register name to the logical register name. Therefore, the flag AMT (750) is exemplified by storing only a single PRN instead of the mapping. On the other hand, the integer AMT (740) has as many integer entries as there are integer logical registers, and the integer AMT (740) stores the mapping between the physical register name and the logical register name for each entry.

[0068] When assigning, physical register names may be assigned based on their valid status. For integer registers and flag registers, this means checking the valid bits within the freelist (730). However, to prevent naming conflicts, the system also performs a bitwise OR operation between the valid status indicated by the PRN entry and the commit bit decoded from the flag AMT (750). This prevents the same PRN from being reassigned until the PRN is evicted from both AMTs (740, 750) or otherwise ceases to exist in both AMTs (740, 750).

[0069] The decode module (770) can be used to generate a decoded commit bit for any PRN entry in the freelist (730) by checking whether the corresponding PRN still exists in the flag AMT (750). That is, for a specific PRN, the decode module (770) can generate 1 for the decoded commit bit if the PRN exists in the flag AMT (750), and 0 for the decoded commit bit otherwise.

[0070] Then, from the decoded commit bit for the PRN, the system (700) can generate a virtual valid bit (772) for the PRN by using a bitwise OR operation between 1) the decoded commit bit and 2) the valid bit of the corresponding PRN entry in the freelist (730). In effect, this means that if an integer register and a flag register occur in the same instruction, they can be assigned to the same PRN simultaneously.

[0071] Likewise, the system (700) can generate a virtual flag commit bit (774) for a PRN by using a bitwise OR operation between 1) a decoded commit bit and 2) a commit bit of a corresponding PRN entry in the freelist (730).

[0072] As described above, the physical register name can be freed again when the PRN is not still in the integer AMT (740) or flag AMT (750). In the case of the integer AMT (740), the system can use the commit bit of the PRN entry in the freelist (730) to determine whether the physical register name is still being maintained in the integer AMT (740).

[0073] Meanwhile, since there is only one logical flag register maintained by the flag AMT (750), the system can save a significant amount of storage space by virtually determining the flag commit bit from the decoded commit bit. Therefore, in the case of the flag PRN, the system can determine the commit state by 1) performing a bitwise OR operation between the commit bit of the corresponding PRN entry and 2) the decoded commit bit.

[0074] Table 1 summarizes the status of the PRN entry shared between the integer register and the flag register.

[0075]

[0076] Table 1

[0077] The following describes operations for maintaining a shared freelist (730). During operation 1, a physical register name can be assigned by identifying a PRN entry in the freelist that has free. As previously mentioned, a PRN entry available for renaming can be identified through the use of input and output staging buffers, which can also be used to generate a PRN from the freelist location of the corresponding PRN entry.

[0078] Because the integer register file (710) and the flag register file (720) share a namespace, when an instruction refers to a logical register for an integer or a logical register for a flag register, the system simply assigns a physical register name to any free PRN entry in the free list (730).

[0079] In some implementations, the system may assign the same PRN to both the integer register and the flag register. For example, if a single instruction references both the integer logical register and the flag logical register, the system may find available PRNs from the freelist and assign the same PRN to both the integer logical register and the flag logical register. Even if the same physical register name is assigned, the values ​​written to the individual logical registers are stored by different physical registers, because the logical register names reference different physical register files (710, 720).

[0080] Then, while the instruction is being executed, the PRN-LRN mapping is stored in the ROB (760). In some implementations, the ROB (760) includes fields (711, 712) indicating whether the mapping is an integer mapping, a flag mapping, or both. Since the system assigns the same physical register name to instructions that reference both the integer register file (710) and the flag register file (720), the ROB (760) requires only two bits for each ROB entry, namely the flag bit (711) and the integer bit (712), to indicate whether the entry is an integer mapping, a flag mapping, or both.

[0081] Operation 2 represents a flush recovery. Since the integer register file (710) and the flag register file (720) share the freelist, only a single flush operation needs to be performed on the freelist (730). As previously described, the head pointer of the freelist (730) snaps back to the flush point indicated by the checkpoint within the ROB (760) as previously explained. Any PRN entry allocated from the flush point to the head pointer that does not have a commit bit set is returned to the freelist, for example, by resetting its valid bit and commit bit.

[0082] Operation 3 indicates a bypass return to the freelist (730). This is a special case to prevent unnecessary storage of PRNs within the AMT. For example, if a physical register mapped to a logical register retires in the same cycle as a subsequent instruction to write to the same logical register, there is no need to add the physical register to the AMT, as the physical register will be overwritten by the subsequent write instruction. Therefore, the physical register name can bypass the AMT and return directly to the freelist. By doing so, the system can be cleared, for example, by setting the valid and integer commit bits to 0.

[0083] During operation 4, when PRN is retired from ROB (760), if PRN is only an integer PRN, PRN is retired to an integer AMT (740). The system may also be configured by setting the integer commit bit of the corresponding PRN entry to, for example, 1. If PRN is only a flag PRN, PRN is retired to a flag AMT (750). If PRN is both an integer PRN and a flag PRN, PRN is retired to both AMTs (740, 750).

[0084] PRN can eventually be expelled from its individual AMT (740, 750).

[0085] During operation 5, the integer PRN is evicted from the integer AMT (740). To indicate that the PRN no longer exists in the integer AMT (740), the system may clear the valid bit and the integer commit bit from the corresponding PRN entry in the freelist (730).

[0086] However, the PRN is not actually free for allocation only if the PRN is not stored in the flag AMT (750). As previously mentioned, the system (700) can enforce this restriction by using a virtual valid bit (772), which is a bitwise OR operation between the valid bit of the PRN entry and the decoded commit bit from the flag AMT (750).

[0087] When a flag PRN is evicted from the flag AMT (750), the system may reset the valid bit of the corresponding PRN entry. At this time, since another PRN is stored by the flag AMT (750), the decoded commit bit for that PRN is changed from 1 to 0. Thus, unless an integer PRN still exists in the integer AMT (740) at that point, the virtual flag commit bit for that PRN is reset to 0.

[0088] FIG. 8 is a flowchart of an exemplary process for maintaining a shared freelist. The process may be performed by a processor configured according to the present specification. For convenience, the process is described as being performed by a system.

[0089] The system maintains a shared freelist for multiple types of register sets (810). As previously mentioned, the processor may have different physical register files, each of which has its own physical register name. For multiple physical register files, the system may maintain a single physical register namespace. For example, the system may maintain a single physical register namespace for both integer registers and flag registers that are maintained in separate physical register files.

[0090] The system generates a first physical register name for a first type of physical register (820) and generates a second physical register name for a second type of physical register (830). That is, even if the physical registers are in different physical register files, the system can generate physical register names from the same shared freelist. And, as described above, if an instruction references physical registers in both physical register files, the system can generate a shared physical register name for both physical registers in different physical register files.

[0091] The system retires the first physical register name and the second physical register name to different individual AMTs (840). As previously mentioned, different register files have different AMTs to maintain the state of the processor for committed instructions.

[0092] The system frees the first physical register name if it does not exist in the second AMT (850). In other words, because different physical register files share a namespace, the physical register name should not be freed if it is still being maintained in one of the AMTs. Therefore, to return the first physical register name to the freelist, the system can first verify that the corresponding physical register name is not still being maintained in the second AMT. As previously described, in some implementations, the system can perform this verification by performing a bitwise OR operation between the decoded commit bit and the valid bit maintained in the PRN entry of the freelist.

[0093] This specification also describes how a shared freelist can be used to borrow an already assigned physical register name. In other words, in some situations, even if a physical register name is already assigned to a logical register of an instruction, the same physical register name can be reallocated to another logical register in certain situations. This configuration increases processor efficiency and mitigates the possibility of the processor running out of register space, all of which are achieved without adding additional naming storage space.

[0094] FIG. 9 illustrates PRN borrowing in a system having two sets of physical registers (910, 920). In this example, a shared freelist (930) is used to assign physical register names for a sequence of instructions (905, 915, 925). In this example, the same physical register names are used for logical registers referenced by instructions (905, 925).

[0095] The add instruction (905) adds the values ​​of logical registers X2 and X3 and stores the value using logical register X1. Since this requires the allocation of a physical register, the shared freelist (930) generates a physical register name, PRN2 in this example, which may be, for example, a binary value 0x10. Thus, the processor will use that physical register name to identify a second physical register within the integer register set (910). Consequently, the result of the add instruction is written to the second physical integer register (911).

[0096] Next, the interposed save instruction (915) is executed. Since the save instruction does not need to write a value to any physical register, the save instruction does not require the allocation of a physical register through register renaming. For this reason, if the next instruction refers only to a different type of logical register, the physical register name assigned to the add instruction (905) can be reassigned to the logical register of the instruction (925).

[0097] The instruction (925) compares the values ​​of logical registers X5 and X6 and stores the result in the flag register. Since the syntax of the instruction (925) is a comparison instruction, it refers to the flag register only implicitly. Since the instruction (925) needs to write to the physical flag register, the shared freelist will generate a physical register name that identifies one of the flag registers in the flag register file (920).

[0098] However, since the comparison instruction (925) satisfies the criteria for borrowing a physical register name, the freelist (930) reassigns the same physical register name that was generated for the instruction (905) by regenerating PRN2. As a result, the result of the comparison instruction will be stored in the second physical flag register (921).

[0099] FIG. 10 is a flowchart of an exemplary process for borrowing physical register names. The process may be performed by a processor configured according to the present specification. For convenience, the process is described as being performed by a system.

[0100] The system maintains a shared freelist for a number of different register sets (1010). As previously mentioned, different register sets have different types and are referenced by logical register names that reflect these types.

[0101] The system assigns a first physical register name for a first physical register of a first type (1020). The system can use a freelist allocation process to generate the next available PRN based on the value of the PRN entry and the position of the head pointer.

[0102] The system receives a second instruction for a second type of physical register (1030), and the system determines whether the second instruction satisfies one or more borrowing criteria with the first instruction (1030). In other words, to determine whether the instruction satisfies one or more borrowing criteria, the system can check the second logical register type by comparing it with one or more previously received instructions.

[0103] A first example of a borrowing criterion is that instructions are sequential. Therefore, in some implementations, the system can check whether instructions refer to different types of physical registers by comparing them to previously executed instructions. If so, the system can determine that the two instructions satisfy the borrowing criterion.

[0104] A second example of the borrowing criterion is that one or more intervening instructions are instructions that do not require register renaming. For example, a store instruction between two different instructions is an example of an instruction that does not require register renaming. Therefore, any number of store instructions can occur between two instructions, and even in this case, they can still satisfy the borrowing criterion.

[0105] A third example of a borrowing criterion is whether instructions are renamed within the same cycle. As previously mentioned, the use of input and output staging buffers enables the processor to perform multiple renamings within the same cycle. Therefore, in some implementations, the system may allow borrowing only between instructions that are renamed within the same cycle.

[0106] The fourth example of a borrowing criterion is whether a branch instruction exists between two instructions. In some implementations, to simplify flush recovery logic, the system may not allow borrowing if the intervening instruction is a branch instruction. However, in some alternative implementations, borrowing may still be allowed even if an intervening branch instruction exists, provided that the processor treats the instruction as a non-borrowing case after flush recovery has begun. In other words, the system may allow borrowing before flush recovery, but may not allow borrowing for that instruction after flushing.

[0107] If one or more borrowing criteria are not met, the system generates a new physical register name for the second instruction (branch to 1050).

[0108] On the other hand, if one or more borrowing criteria are met, the system reallocates the same PRN for the second instruction (branching to 1060). As previously explained, if the same PRN is used to execute different instructions, the result is actually delivered to different physical register files.

[0109] If the same PRN is assigned to two instructions, the system can ensure that both are evicted from their respective AMTs before returning the PRNs to the freelist. Thus, when the first PRN is evicted from the AMT by a subsequent write instruction to a logical register, the system can determine the commit status of the other PRN by checking the explicitly retained commit bit or by retrieving that AMT. Only when the PRNs are both evicted from their respective AMTs will the system return the shared PRN to the freelist.

[0110] This specification also describes a method for further extending the shared freelist to manage physical floating-point registers without a significant increase in hardware costs. By sharing the freelist between integer registers and floating-point registers, the processor can effectively eliminate the separate freelist for floating-point registers. Furthermore, the freelist can continue to use the same allocation and flush recovery processes with only a very small amount of additional write-keeping operations.

[0111] The sharing between integer registers and floating-point registers is more complex than the sharing with flag registers, because floating-point registers tend to be fewer than integer or flag registers. Processor design is the result of carefully selecting the number of each type of register to achieve a specific level of performance and efficiency. Therefore, while the relative number of physical registers within each register file varies considerably, floating-point registers tend to be fewer than integer registers, partly because of their larger size. As mentioned above, since flag registers store much less data than integer registers (e.g., 4 bits for flag registers versus 64 bits for integer registers), integer and flag registers can be efficiently configured in equal numbers. On the other hand, the number of physical floating-point registers can be much smaller, and in a few common examples, it can be only one-quarter or one-half the number of integer registers.

[0112] To support sharing between integer registers and floating-point registers, the system may allocate virtual PRNs to floating-point registers by nature. In this specification, a PRN being virtual means that the PRN belongs to a namespace that does not correspond to the size of the physical register file. Instead, a mapping exists between each virtual PRN and each floating-point PRN within the floating-point PRN namespace corresponding to the size of the physical register file. If a freelist is used to maintain a virtual PRN namespace, this means that while all PRN entries within the freelist can be allocated to floating-point registers, multiple PRN entries within the freelist with different virtual PRNs may be mapped to the same floating-point PRN because the number of floating-point registers is less than the number of freelist entries. To prevent the reallocation of already allocated floating-point PRNs, the system can track which PRN entries are associated with each other by having virtual PRNs mapped to the same floating-point PRN. Then, if a PRN is already assigned to a floating-point register, none of the other associated PRN entries can be assigned to another logical floating-point register name until the assigned PRN is deallocated. However, during this period, the PRN of another associated PRN entry can still be assigned to a different register type, for example, an integer register. In the following description, a PRN entry described as being paired or associated with a PRN entry refers to a group of multiple PRN entries having different virtual PRNs mapped to the same floating-point PRN.

[0113] The technique described below for sharing between integer registers and floating-point registers may be combined with the technique described above for sharing with flag registers and borrowing PRNs. Accordingly, the shared free list described herein may be used to maintain PRN allocations for at least three different types of physical registers, namely integer registers, flag registers, and floating-point registers.

[0114] FIG. 11 illustrates an exemplary technique for associating PRN entries for floating-point registers. In this example, the physical floating-point register file has half the number of physical registers as the integer physical register file. Therefore, the freelist can maintain a virtual PRN namespace by associating two PRN entries for each floating-point PRN. To this end, the system can pair PRN entries in any appropriate manner so that each pair of PRN entries identifies the same floating-point PRN. FIG. 11 illustrates an example of pairing PRN entries in a manner that does not require overly complex logic or write-keeping operations.

[0115] As illustrated in FIG. 11, the free list of N PRN entries is conceptually divided into two halves: a first half (1110) spanning from PRN0 to PRN N / 2-1 and a second half (1120) spanning from PRN N / 2 to PRN N-1. The corresponding PRN entries in each half are paired with each other so that they identify the same floating-point PRN in a physical floating-point register file (1130) having N / 2 entries.

[0116] For example, the PRN entries for PRN0 and PRN N / 2 both identify the first floating-point register (FP PR0). Similarly, the PRN entries for PRN N / 2-1 and PRN N-1 both identify the last floating-point register (FP PR N / 2-1).

[0117] Through this arrangement, the system can quickly and efficiently check whether a paired PRN entry has been assigned to a floating-point register. If so, the system can reallocate the same PRN to a different register type, but not to a different floating-point register.

[0118] FIG. 12 is a diagram illustrating a method by which a system can maintain a shared freelist between integer registers and floating-point registers. As illustrated, the system includes an integer register file (1210) and a floating-point register file (1220). The system also includes a shared freelist (1230). The system also has an integer AMT (1240) for integer registers and a floating-point AMT (1250) for floating-point registers. Each AMT stores a mapping between logical register names and physical register names for its respective physical register file.

[0119] Unlike the shared freelist described above, the shared freelist (1230) includes an additional bit for each PRN entry to track whether the PRN entry has been assigned to a floating-point register. Thus, each PRN entry includes a valid bit, a commit bit, and a floating-point bit ('FP bit').

[0120] Table 2 summarizes the status of PRN entries that also have floating-point bits.

[0121]

[0122] Table 2

[0123] As shown in Table 2, the FP bit of a PRN entry is used to track whether the PRN for that PRN entry or the PRN for an associated PRN entry mapped to the same floating-point PRN has been assigned to a floating-point register. If the PRN entry itself is assigned to a floating-point register, that PRN cannot be assigned to any other register until it is returned to the freelist. However, for a specific PRN entry, if the associated PRN entry is assigned to a floating-point register, that specific PRN entry can still be used to assign a PRN to a non-floating-point register.

[0124] In operation 1 of FIG. 12, the freelist generates a PRN for a physical register and sets the valid bit of the corresponding PRN entry. If the physical register is a floating-point register, the system sets the FP bit for that PRN entry as well as for all other paired or associated PRN entries. Accordingly, the paired or associated PRN entries with the FP bit set are only assignable to non-floating-point registers until the PRN is returned to the freelist, for example, during a bypass return, at flush, or by being evicted from the FP AMT (1250).

[0125] After that, the PRN-LRN mapping enters the ROB (1260). To track which AMT the PRN should be retired to, the ROB (1260) may also maintain an integer field (1211) and a floating-point field (1212) indicating whether the PRN is assigned to a floating-point register or a non-floating-point register. During operation 2, the PRN is retired to the individual AMT (1240 or 1250), which may be based on the integer field (1211) and floating-point field (1212) of the ROB (1260). Then, the corresponding PRN commit bit is set to indicate that the PRN has been retired to the AMT, as indicated by the label 'PRN commit = 1'.

[0126] During the flush recovery of operation 3, the system can reset the head pointer to the flush point using the checkpoint of the ROB and then flush the PRN entry by resetting the effective bit of the affected PRN entry between the old head pointer and the flush point, except when stored in the AMT according to the commit bit. Thus, if the commit bit of the flushed PRN entry is 0, the system clears both the effective bit and the floating-point bit.

[0127] However, the system may perform some additional maintenance to account for a virtual PRN, and as a result, the FP bit of the PRN entry may be restored. That is, the system may perform a bitwise OR operation between all associated PRN entries, and if the FP bit of any of the associated PRN entries is still set, the system sets the FP bit of all associated PRN entries. On the other hand, if the FP bit is not set in any of the associated PRN entries, the system may not restore the FP bit.

[0128] This additional step takes into account the situation where a paired or associated PRN entry is flushed while the PRN entry is assigned to a physical floating-point register. In this case, the system can restore the FP bits of the flushed PRN entry to prevent the PRN entry from being reallocated to another floating-point register. Thus, the system can perform a bitwise OR operation between the FP bits of all associated PRN entries and store the result for the FP bits in all associated PRN entries.

[0129] In this example, the bitwise OR operation process first includes the step of determining the paired PRN entry. As illustrated in FIG. 11, if the PRN entry is paired, the paired PRN entry can be obtained by adding an integer N / 2 when N is the size of the freelist (1221). Then, the system decodes the FP bit value of the paired PRN entry (e.g., using a decode module (1222, 1223)), performs a bitwise OR operation (1224) between the FP bits, and then writes the result to both PRN entries of the freelist (1230).

[0130] A final step may be performed to account for the opposite situation where the paired PRN entry is not assigned, which is verified by the valid bit of the corresponding PRN entry. In this case, the system clears the FP bits of both PRN entries. The maintenance of the FP bits in this manner upon a flush will be explained in more detail below with reference to FIG. 13.

[0131] During operation 4, when the floating-point PRN is evicted from the FP AMT (1250), the system will clear the FP bits of the floating-point PRN entry and all other associated PRN entries. To do this, the system may first determine the paired PRN entries, which may include performing an integer addition of N / 2 (1231) in this example. Then, the system may clear their individual FP bits (1232, 1233). According to the usual operation of returning the PRN to the freelist, the system may also clear the valid bit and commit bit of the PRN entry.

[0132] During operation 5, in which FP PRN is bypassed and returned without reaching FP AMT (1250), the system may clear the valid bit and commit bit of the PRN entry. And because FP PRN is ready to be reallocated to another floating-point register, the system may also clear all FP bits for all paired or associated PRN entries.

[0133] FIG. 13 is a flowchart of an exemplary process for maintaining a virtual PRN entry during flush recovery when managing a number of different register sets. The process may be performed by a processor configured according to the present specification. For convenience, the process is described as being performed by a system.

[0134] As described above, to perform flush recovery, the system resets the head pointer to the flush point. All PRN entries from the flush point up to the old head pointer position will be processed according to the operation of FIG. 13. Thus, the system can perform an exemplary process for all flushed PRN entries.

[0135] The system determines whether the commit bit is set (1310). If the commit bit is not set, the PRN of the PRN entry can be returned to the freelist. Therefore, the system clears the valid bit and floating-point bit of the PRN entry (branch to 1320). If the commit bit is set, the system skips to the next step (branch to 1330).

[0136] The system performs a bitwise OR operation between the associated PRN entries and records the result in the FP bit of each associated PRN entry (1330). In other words, if the FP bit of any of the paired or associated PRN entries is set, the FP bit of all paired or associated PRN entries is set.

[0137] The system determines whether any of the associated PRN entries has a valid bit set (1340). In this case, if the valid bit of one of the PRN entries in the group of paired or associated PRN entries is set, it is assigned to a register that is not subject to flush and is therefore retained (branch to exit).

[0138] However, if the valid bit is not set in either the paired or associated PRN entry, the FP bit must also be cleared so that the PRN entry can be used in a floating-point register in the future. Therefore, if the valid bit is not set in either the paired or associated PRN entry, the system clears all floating-point bits of the PRN entries within that group (branch to 1350).

[0139] FIG. 14 is a flowchart of an exemplary process for allocating a virtual PRN for a freelist managing a plurality of different register sets. The process may be performed by a processor configured according to the present specification. For convenience, the process is described as being performed by a system.

[0140] The system maintains a shared freelist for multiple sets of different types of registers (1410). As previously described, the system can allocate virtual PRNs by maintaining a virtual PRN namespace in which multiple PRN entries with different virtual PRNs can be mapped to the same physical register name. Thus, the system can group together multiple PRN entries that are mapped to the same PRN number for a specific type of physical register.

[0141] The system assigns a first PRN to a logical register name of type 2 (1420) and designates one or more other PRN entries for the logical register of type 2 as unassignable (1430). As previously described, the system may maintain a separate bit value within each PRN entry to indicate whether any of the associated registers within that group are assigned to a specific type of register. For example, the system may maintain a floating-point bit to indicate whether any of the paired or associated PRN entries are assigned to a floating-point register. In that case, other PRN entries within that group cannot be assigned to a floating-point register, but can still be assigned to a different type of non-floating-point register.

[0142] For clarity, floating-point registers were used as an example of a register type with a virtual PRN in the above description, but the same technique can be applied to other appropriate register types.

[0143] This specification also describes another method by which a shared freelist can support different types of register files. In the floating-point register example described above, since the number of floating-point registers is smaller than that of integer registers, the freelist ensured that only the correct number of floating-point PRNs were allocated according to the floating-point register file. In that example, for a freelist of size N, N / 2 floating-point PRNs were allocated to N / 2 physical floating-point registers.

[0144] However, in some applications that heavily utilize floating-point execution, the renaming process itself can become a performance bottleneck. Therefore, the previously described system can be configured or reconfigured, for example, during runtime or manufacturing, to allow multiple associated or paired PRN entries to be simultaneously assigned to different logical floating-point registers. In other words, a group of PRN entries having different virtual PRNs mapped to the same floating-point PRN can be assigned to a logical register name for the same duration. Conversely, in the previously described example, paired or associated PRN entries mapped to the same floating-point PRN as the already assigned PRN could only be assigned to other types of registers, such as integer or flag registers.

[0145] To prevent conflicts between multiple instructions assigned the same floating-point PRN, the system may manage renaming and execution in different stages. In the first stage, the system assigns a floating-point PRN to an instruction but does not yet allow the execution of that instruction. In the second stage, the system issues the instruction for execution only when a PRN entry with a different virtual PRN mapped to the same floating-point PRN is available for renaming—that is, only if the PRN entry has not yet been assigned or has been returned to the freelist. Returning the same floating-point PRN to the freelist means that the floating-point PRN has been evicted from the AMT or returned in other ways, such as the bypass return described earlier, which implies that the data in the corresponding physical register is no longer needed by the program. The effect of this is to push the resolution of name conflicts from the renaming stage to the execution stage, where actual data dependency conflicts must be resolved in any case.

[0146] To support multiple paired or associated PRN entries being allocated to a floating-point register, the system may use modified logic to determine when to set or clear the FP bit of a PRN entry in the free list when it is allocated and deallocated for the floating-point register, and modified logic to determine when to allow the issuance of an instruction to write to the floating-point register.

[0147] To maintain information about which instructions using floating-point registers are ready to be issued, the system may maintain a sliding window of PRN entries within the freelist. The sliding window distinguishes between PRNs that are ready to be issued for execution and PRNs that must wait for a floating-point PRN to return to the freelist before being issued. The sliding window is a data entry maintained separately from the head pointer and tail pointer of the freelist itself.

[0148] This specification also describes techniques and circuit structures for handling stuck floating-point PRNs that would otherwise be unable to enter the sliding window for execution. There are various situations in which a PRN becomes stuck within the AMT. As previously explained, a PRN can remain in the AMT until it is evicted by a logical write instruction. However, many programs may contain instructions that write to a logical register only once, and then write again much later in the program or not write at all. In such situations, a floating-point PRN may become stuck in the AMT indefinitely, and as a result, the PRN entry paired with or associated with it may not be issued for execution.

[0149] FIG. 15 illustrates a sliding window for PRNs within a freelist. In this example, the freelist is maintained in banks of 16 PRN entries each. Thus, the first bank (1510) contains PRN entries 0 through 15. The total freelist size is 512 entries, and thus the last entry (1520) contains PRN entries 495 through 511.

[0150] In this example, the number of floating-point registers is half the number of integer registers. Thus, the sliding window (1545) indicated by the dashed line has 256 entries, which is half the number of integer registers. With this configuration, the system can assign two PRN entries to two different instructions even if the PRN entries are mapped to the same floating-point PRN. In other words, different virtual PRNs of PRN entries are mapped to the same floating-point PRN.

[0151] To implement a sliding window, the system may maintain a floating-point tail pointer (FP tail pointer) that points to the oldest PRN entry allocated to a floating-point register in the main floating-point register file. The FP tail pointer is distinct from the previously described freelist tail pointer; for clarity, the freelist tail pointer may be referred to as the FL tail pointer to distinguish it from the FP tail pointer defining the sliding window. From the FP tail pointer, the system may consider the next M PRN entries, based on the size of the physical floating-point register file, to be within the sliding window. Thus, the system can use the FP tail pointer to determine which PRN entries to bring into the sliding window and designate as ready for execution. Since the sliding window is defined based on the size of the physical floating-point register file, instructions using PRN entries within the sliding window can be executed safely because they are guaranteed to have the corresponding physical floating-point register at execution.

[0152] Therefore, in order to move the sliding window, the FP bit must be cleared for the next PRN entry or the next group, for example, the bank or row of the PRN entry.

[0153] In the example described above with reference to FIGS. 11 through 14, the FP bit is set when a paired or associated PRN entry is assigned to a floating-point register. However, in this example, the requirement is modified so that the setting and clearing of each FP bit depend only on the state of the PRN entry itself, rather than the state of the associated or paired PRN entry. Instead, the system uses a sliding window instead of the FP bit to prevent name conflicts.

[0154] Therefore, the system may clear the FP bit for the PRN entry when the PRN entry becomes free for renaming, which is done, for example, by returning it to the freelist after being evicted from the FP AMT, by processing it as part of a flush, or by entering the architectured floating-point register file described in more detail below. The system may check the valid bit of the PRN entry to determine whether it is free for renaming.

[0155] The FP tail pointer can be advanced by PRN entry unit or by each bank of PRN entries. When the FP tail pointer is advanced by PRN entry unit, the FP tail pointer may be advanced when the FP bit of the oldest allocated PRN entry is cleared. For example, the system may continuously check the valid bit of the PRN entry indicated by the FP tail pointer, and if the valid bit indicates that the PRN entry is available for renaming, the system may clear the FP bit of that PRN entry and advance the FP tail pointer. When the FP tail pointer is advanced by PRN entry bank unit, the system may advance the FP tail pointer when all FP bits within the oldest bank are cleared.

[0156] When the FP tail pointer is updated and the sliding window moves, the system can issue instructions assigned to the PRN entry that entered the sliding window sequentially or in parallel.

[0157] FIG. 16 illustrates a data structure for handling a stuck floating-point PRN. A PRN stuck in the AMT can delay the execution of floating-point instructions because the FP bit of the PRN entry is never cleared. And if the FP bit is never cleared, the FP tail pointer cannot advance, and new floating-point instructions cannot enter the sliding window.

[0158] Therefore, to solve this problem, the system may use a new auxiliary physical register file that stores the architectured floating-point values ​​for the physical registers in which the PRN still exists in the AMT. The architectured floating-point physical register file [APRF] (1620) is a physical register file separate from the main floating-point physical register file [MPRF] (1610).

[0159] APRF (1620) requires only as many physical registers as there are logical registers for the processor, whereas MPRF (1610) generally has many more physical registers. For example, if the processor has 32 logical registers, APRF requires only 32 physical registers. Meanwhile, MPRF generally has hundreds or more, for example, 256 or 512 physical registers.

[0160] APRF (1620) allows the processor to clear the FP bit of a floating-point PRN entry while maintaining the possibility that the value of the stuck PRN will be read in the future. The processor cannot simply remove the stuck PRN from the AMT because it cannot know whether the corresponding logic register will be read at some point in the future.

[0161] APRF (1620) essentially provides another path to clear the FP bit of a PRN entry. Thus, when using APRF, paths to clear the FP bit for a PRN entry include not only the PRN being evicted from the FP AMT or being returned to the freelist by a bypass return or flush, but also the PRN entering the APRF.

[0162] Each entry in the APRF (1620) has a corresponding PRN in the virtual PRN table (1640). Since the size of an entry in the virtual PRN table (1640) is sufficient to store only the bits of the PRN, the virtual PRN table (1640) is generally smaller than the APRF (1640) based on the same number of entries.

[0163] A consumer (1650) of data stored in a physical floating-point register, for example, an execution unit executing an instruction to read the floating-point register, may first check the virtual PRN table (1640). If a hit occurs, the consumer (1650) reads the data from the APRF (1620) rather than the MPRF (1610). Otherwise, the consumer reads the data from the MPRF (1610).

[0164] Table 3 summarizes the status of PRN entries when using a sliding window.

[0165]

[0166] Table 3

[0167] Table 4 illustrates an example of a PRN locked through a series of instructions. In this example, the freelist has 10 entries, and the floating-point physical register file has 5 registers. Therefore, the size of the sliding window is 5 entries. In this example, the FP tail pointer points to the PRN entry corresponding to PRN 3. Table 3 shows the virtual PRNs assigned to each of the 10 floating-point instructions, the corresponding floating-point PRNs, and the FP bit status of each PRN entry at the point where the sliding window's FP tail pointer points to PRN entry 3.

[0168] Table 4

[0169] In this example, if floating-point PRN3 gets stuck in the AMT, instruction 8 can never enter the sliding window and therefore cannot be issued. That is, the FP bit for the PRN entry used by instruction 3 is not cleared until PRN3 is returned to the freelist, which will trigger an update of the FP tail pointer.

[0170] However, by storing the value of PRN3 in APRF, the system can clear the FP bit of PRN entry 3 for instruction 3. This triggers an update of the FP tail pointer, instruction 8 enters the sliding window, and the processor can then issue instruction 8 for execution. Subsequent consumers of the logical register to which PRN 3 is assigned will read data from APRF rather than from the main physical register file.

[0171] FIG. 17 is a flowchart of an exemplary process for managing a virtual PRN for a freelist that manages a plurality of different register sets. The process may be performed by a processor configured according to the present specification. For convenience, the process is described as being performed by a system.

[0172] The system maintains a shared freelist for multiple different sets of registers (1710). As previously mentioned, the freelist may allow multiple different PRN entries to be assigned to floating-point register names by allocating virtual PRNs. The virtual PRNs are greater than the actual number of physical floating-point registers.

[0173] The system allocates a first virtual PRN from the first PRN entry and designates the first PRN entry as ready to execute (1720). Then, the system can execute the first instruction.

[0174] The system allocates a second virtual PRN from the second PRN entry that maps to the same first floating-point PRN (1730). The system can still allocate a virtual PRN to the second PRN entry, but may wait for the issuance of instructions until the first PRN is returned to the freelist. In some implementations, the system uses a sliding window to wait for the issuance of instructions until the second PRN entry reaches the sliding window, at which point the first PRN will have been returned to the freelist.

[0175] The system determines that the first PRN has been returned to the freelist (1740), and the system designates the second instruction as ready to execute (1750). For example, the system may use a sliding window to determine whether a previously allocated PRN has been returned to the freelist. When the second PRN entry enters the sliding window, the system may issue a corresponding instruction.

[0176] Issuing an instruction with a renamed register may involve sending the instruction to a reservation station. A reservation station issuing a floating-point instruction may continuously check the sliding window, as indicated by the FP tail pointer, to determine whether to issue the instruction. The reservation station may then execute the instruction as soon as the corresponding PRN entry enters the sliding window. In some implementations, the system includes modified logic for reservation stations handling floating-point instructions. A reservation station handling other instructions that do not write to floating-point registers may issue the instruction regardless of the state of the sliding window.

[0177] This specification also describes a method in which a system having a hybrid freelist can use data within the freelist to clock gate regions of a physical register file. Clock gating is a power-saving technique that refers to reducing power usage for specific regions of an electronic device.

[0178] FIG. 18 illustrates clock gating based on a freelist. One advantage of the hybrid freelist described herein is that it implicitly contains information regarding which areas of the physical register file are likely to be active and which areas are likely to be inactive. In particular, the area between the head pointer and the tail pointer is virtually certain to be a highly active area of ​​the corresponding physical register file. The system can utilize this information to intelligently control which areas of the physical register file may be clock-gated in order to save power.

[0179] FIG. 18 illustrates a hybrid freelist (1830) having 512 entries divided into banks, each consisting of 16 entries. The freelist (1830) assigns PRNs to a physical register file (1810) having a lower bank (1811) and an upper bank (1812).

[0180] The freelist (1830) has a head pointer (1815) and a tail pointer (1805). A physical register having a name represented by a PRN entry between the head pointer (1815) and the tail pointer (1805) is a physical register that is highly likely to be read and written when the program is executed. Therefore, the system can designate an area of ​​the physical register file (1810) corresponding to the PRN entry between the head pointer and the tail pointer as an active area (1840).

[0181] Other areas of the physical register file may be designated as 'low-active' or 'inactive' if they meet certain criteria. In that case, the system may clock-gate a part of the register file or a part of a subset of the register file. For example, the register file (1810) is divided into two banks (1811, 1812). The latter part of the lower bank (1811) is a low-active area, and thus the system may clock-gate the registers belonging to that part of the lower bank (1811).

[0182] Alternatively or additionally, the system may clock-gate the entire bank of the physical register file (1810). For example, if the registers of the upper bank (1812) are in a low-activity region, for example, because they are outside the head and tail pointers, the system may clock-gate the entire upper bank (1812).

[0183] The system may use any appropriate criterion from the freelist (1830) to determine that a physical register is in a low-activity or inactive state. For example, a row of the PRN entry in the freelist (1830) in which all valid bits are cleared corresponds to a group of physical registers that are not being used by the program. Thus, the system may clock gate the area, including reducing the power, clock frequency, voltage, or some combination thereof for that area.

[0184] In some situations, there may be PRN entries containing data located outside the head and tail pointers but which can nevertheless be read during program execution. For example, if a PRN is architectured into an AMT, the value of the corresponding physical register can still be read during program execution. However, due to the architectured state of the PRN, writing to that PRN is no longer possible.

[0185] Therefore, for regions of the physical register file that are located outside the head and tail pointers but still contain one or more PRN entries with valid bits set, the system may also designate these regions as active regions. Alternatively, or additionally, the system may perform less aggressive clock gating on these regions, such as setting them to a low-power mode where reading is still possible but writing is not.

[0186] FIG. 19 is a flowchart of an example of clock gating a physical register file based on a freelist. The process may be performed by a processor configured according to the present specification. For convenience, the process is described as being performed by a system.

[0187] The system maintains a hybrid freelist for a physical register file partitioned into multiple regions (1910). The physical register file can be partitioned into regions that can be individually clock-gated, e.g., banks, rows, or any other suitable partitioning.

[0188] The system determines that the area of ​​the hybrid freelist represents an inactive area of ​​the physical register file (1920). In some implementations, the system searches only for inactive areas located outside the head and tail of the freelist, for example, inactive areas located before the head pointer and after the tail pointer. As described above, the area of ​​the physical register file corresponding to the PRN entry between the head pointer and the tail pointer is likely to be an area where active reads and writes occur as the program is executed.

[0189] The system can identify active regions from PRN entries by examining the valid bits of the PRN entries. PRN entries with valid bits cleared indicate physical registers that are not in use. Therefore, if the system can identify a contiguous region of PRN entries with all valid bits cleared, the system can identify the corresponding region of the physical register file as an inactive region. One important advantage of the hybrid freelist described herein is that it tends to group large regions of inactive PRN entries, and these regions can subsequently be used to identify inactive regions of the physical register file.

[0190] For PRN entries located outside the head pointer and tail pointer but with valid bits set, the system may designate the area as still active because the corresponding physical register can still be read during program execution.

[0191] The system reduces power to the inactive region of the physical register file (1930). For example, the system can reduce or completely block the clock frequency and voltage in the inactive region of the physical register file.

[0192] The system may re-evaluate the active and inactive regions of the physical register file at any appropriate time interval or when the head pointer and tail pointer move. For example, when the head pointer moves to the next row of the freelist corresponding to an inactive region of the physical register file, the system may stop clock gating for that region and restore the previous power or clock level, because the physical registers in that region will soon be allocated for program execution. Similarly, when the tail pointer of the freelist moves to the next row, the system may examine the valid bits of the PRN entry of the previous row to determine if all valid bits have been cleared, and in this case, the system may perform clock gating for the new region of the physical register file.

[0193] This technique allows the system to activate specific regions of the physical register file before the registers are required for execution, thereby reducing or eliminating any delays associated with clock gating the physical register file. For example, the system can use a freelist to reactivate inactive regions of the physical register file at instruction issuance or register renaming. In either case, the corresponding regions of the physical register file will remain active until the instruction is issued.

[0194] Embodiments of the subject matter and functional operations of the invention described herein may be implemented in digital electronic circuits, in tangibly implemented computer software or firmware, in computer hardware comprising the structures disclosed herein and their structural equivalents, or in combinations of one or more of these. Embodiments of the subject matter of the invention described herein may be implemented as one or more executable programs, namely, as one or more modules of instructions encoded on a tangible non-transient storage medium for execution by a data processing device or for controlling the operation of a data processing device. The storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of these. Alternatively or additionally, instructions may be encoded on an artificially generated radio signal, for example, a machine-generated electrical, optical, or electromagnetic signal generated to encode information for transmission to a receiver device suitable for execution by a data processing device.

[0195] The term 'data processing device' refers to data processing hardware and encompasses all kinds of devices, devices, and machines for processing data, including, for example, programmable processors, computers, or multiple processors or computers. The device may also be a special-purpose logic circuit, for example, a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), or may further include such. Optionally, in addition to the hardware, the device may include code that creates an execution environment for computer programs, for example, processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these.

[0196] A computer program, which may also be referred to or described as a program, software, software application, app, module, software module, script, or code, may be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; and it may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program may correspond to a file in a file system, but is not required to do so. A program may be stored as part of a file containing other programs or data, for example, one or more scripts stored in a markup language document, a single file dedicated to the program, or multiple coordinated files, for example, files storing one or more modules, subprograms, or parts of code. A computer program may be distributed to be executed on a single computer or a single site, or on multiple computers distributed across multiple sites and interconnected by a data communication network.

[0197] The processes and logic flows described in this specification may also be performed by special-purpose logic circuits, e.g., FPGAs or ASICs, or by a combination of special-purpose logic circuits and one or more programmed computers.

[0198] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0199] In addition to the embodiments described above, the following embodiments are also innovative.

[0200] Embodiment 1 is a method, wherein the method comprises the step of maintaining a hybrid freelist representing physical registers available for register renaming - wherein the hybrid freelist comprises a plurality of entries having an order, each entry comprising a bit pair for each physical register among a plurality of physical registers, and each bit pair for each entry comprising an effective bit and a commit bit representing an effective state and a commit state for the physical register, respectively, wherein the effective state indicates whether the physical register is free and can be assigned to a logical register name, and the commit state indicates whether an instruction using the physical register has been committed -; and the step of performing a sequential assignment of free physical register names from the plurality of entries of the freelist using a head pointer and a tail pointer of the freelist.

[0201] Embodiment 2 is a method of Embodiment 1, wherein the method further includes the step of finding an entry having a free using the head pointer.

[0202] Embodiment 3 is a method of Embodiment 2, wherein the entries of the hybrid free list are arranged in a plurality of banks, and the step of finding an entry that is free includes the step of reading out a bank corresponding to the head pointer, and the step of finding an entry within the bank that is free.

[0203] Embodiment 4 is a method of Embodiment 3, wherein the method further comprises the steps of filling an output staging buffer based on the valid state of an entry in the bank, and assigning a physical register name using an entry in the output staging buffer.

[0204] Embodiment 5 is a method of Embodiment 4, wherein the step of filling the output staging buffer includes the step of generating a full physical register name from an input staging buffer that stores valid bits from an entry in the bank.

[0205] Embodiment 6 is a method of Embodiment 5, wherein the step of generating the entire physical register name includes the step of expanding each bit in the input staging buffer into a multi-bit physical register name in the output staging buffer.

[0206] Embodiment 7 is a method of any one of embodiments 1 to 6, wherein the method further comprises the step of modifying the valid state of an entry corresponding to the physical register name in response to the assignment of the physical register name.

[0207] Embodiment 8 is a method of any one of embodiments 1 to 7, wherein the method further includes the step of modifying the commit state of an entry corresponding to the physical register when an instruction using the physical register is committed.

[0208] Embodiment 9 is a method of any one of embodiments 1 to 8, wherein the method further includes the step of modifying the effective state and commit state of an entry corresponding to a physical register name assigned to a logical register name when a subsequent instruction is written to the same logical register name.

[0209] Embodiment 10 is a method of any one of embodiments 1 to 9, wherein the method further comprises the steps of receiving a flush instruction at a specific flush point, and modifying the valid state of any entry in the hybrid freelist that does not have a commit state between the flush point and the head pointer.

[0210] Embodiment 11 is a method of Embodiment 10, wherein the method further includes the step of updating the head pointer of the hybrid freelist based on the flush point.

[0211] Embodiment 12 is a method of Embodiment 10, wherein the flush point is based on the oldest assigned PRN affected by the flush.

[0212] Embodiment 13 is a method of Embodiment 12, wherein the method further comprises the steps of storing a checkpoint for each PRN-LRN mapping in a reorder buffer (ROB), and using the checkpoint in the ROB as the flush point.

[0213] Embodiment 14 is a method for implementing a shared freelist for a plurality of different register sets, the method comprising: maintaining a shared freelist for a plurality of different register sets—each register set includes one or more registers of a specific type, and the freelist has a plurality of physical register name (PRN) entries—; generating a first physical register name for a first physical register of a first type from a first freelist entry for a first instruction referencing a first logical register of a first type; generating a second physical register name for a second physical register of a second type from a second freelist entry for a second instruction referencing a second logical register of a second type; retiring the first physical register name to a first architectured map table (AMT) for a first type of register after the first instruction has completed execution; retiring the second physical register name to a second AMT for a second type of register; and, if the first physical register name is not in the second AMT, designating the first physical register name as free.

[0214] Embodiment 15 is a method of Embodiment 14, wherein the method further includes the step of designating the second physical register name as free when the first physical register name is not in the first AMT.

[0215] Embodiment 16 is a method of embodiment 15, wherein the step of designating the second physical register name as free includes the step of determining that the PRN entry in the free list for the second physical register name does not have a set commit bit, and in response thereto, the step of clearing the valid bit for the PRN entry.

[0216] Embodiment 17 is a method of any one of embodiments 14 to 16, wherein the step of designating the first physical register name as free includes the step of determining that the second AMT does not retain the second physical register name, and in response thereto, the step of clearing the valid bit of the PRN entry for the first physical register name.

[0217] Embodiment 18 is a method of any one of embodiments 14 to 17, wherein the method further comprises the step of generating a shared physical register name for a third physical register of type 1 and a fourth physical register of type 2 from a third hybrid freelist entry for a third instruction that references both a first logical register of type 1 and a second logical register of type 2.

[0218] Embodiment 19 is a method of Embodiment 18, wherein the method further includes the step of returning the shared physical register name to the freelist only when the shared physical register name is expelled from both the first AMT and the second AMT.

[0219] Embodiment 20 is a method of any one of embodiments 14 to 19, wherein the first type is an integer register.

[0220] Embodiment 21 is a method of any one of embodiments 14 to 20, wherein the second type is a flag register.

[0221] Embodiment 22 is a method, wherein the method comprises the steps of: maintaining a shared freelist for a plurality of different sets of registers—each set of registers includes one or more registers of a specific type, and the freelist has a plurality of physical register name (PRN) entries—; assigning a first physical register name for a first physical register of a first type from the first freelist entries for a first instruction referencing a first logical register of a first type; determining that a second instruction referencing a second logical register of a different second type satisfies one or more borrowing criteria with the first instruction; and in response thereto, reassigning the first physical register name to the second logical register referenced by the second instruction.

[0222] Embodiment 23 is a method of embodiment 22, wherein the step of reassigning the first physical register name to the second logical register includes the step of assigning the first physical register name to the second logical register while the first physical register name is already assigned to the first logical register.

[0223] Embodiment 24 is a method of any one of embodiments 22 to 23, wherein the step of reassigning the first physical register name results in the first physical register name being simultaneously assigned to a different type of logical register.

[0224] Embodiment 25 is a method of any one of embodiments 22 to 24, wherein the step of determining that the second instruction satisfies the one or more borrowing criteria includes the step of determining that the first instruction and the second instruction are consecutive instructions.

[0225] Embodiment 26 is a method of any one of embodiments 22 to 25, wherein the step of determining that the second instruction satisfies the one or more borrowing criteria includes the step of determining that there is no intervening instruction between the first instruction and the second instruction that requires register renaming.

[0226] Embodiment 27 is a method of Embodiment 26, wherein the step of determining that the second instruction satisfies the one or more borrowing criteria includes the step of determining that the intervening instruction does not require a logical register write.

[0227] Embodiment 28 is a method of any one of embodiments 26 to 27, wherein the intervening instruction is a storage instruction.

[0228] Embodiment 29 is a method of any one of embodiments 22 to 28, wherein the step of determining that the second instruction satisfies the one or more borrowing criteria includes the step of determining that the first instruction and the second instruction are renamed in the same cycle.

[0229] Embodiment 30 is a method of any one of embodiments 22 to 29, wherein the step of determining that the second instruction satisfies the one or more borrowing criteria includes the step of determining that the intervening instruction between the first instruction and the second instruction is not a branch instruction.

[0230] Embodiment 31 is a method of any one of embodiments 22 to 30, wherein the method further comprises the step of committing the first instruction and the second instruction in different cycles.

[0231] Embodiment 32 is a method of any one of embodiments 22 to 31, wherein the first type or the second type is an integer register.

[0232] Embodiment 33 is a method of any one of embodiments 22 to 32, wherein the first type or the second type is a flag register.

[0233] Embodiment 34 is a method, wherein the method comprises the steps of: maintaining a shared freelist for a plurality of different register sets, each register set comprising a first register set and a different second register set, wherein each register set comprises one or more registers of a distinct type, and the second register set comprises fewer physical registers than the first register set, and the freelist comprises a plurality of physical register name (PRN) entries, wherein the freelist associates a group of one or more PRN entries for identifying a single register of the second register set, and at least one group of the plurality of PRN entries identifies a single physical register of the second register set; assigning a first physical register name from a first PRN entry for a first logical register name of a second type, wherein the first PRN entry belongs to a group of one or more other associated PRN entries that also identify the same physical register name of the second register set; and designating one or more other PRN entries of the group as unavailable for assignment to a logical register of the second type until the first PRN entry becomes available again.

[0234] Embodiment 35 is a method of Embodiment 34, wherein the method further comprises the step of assigning a second physical register name to a second logical register name of a first type from a second PRN entry belonging to the group.

[0235] Embodiment 36 is a method of any one of embodiments 34 to 35, wherein a plurality of PRN entries within the group are assigned to different types of physical registers.

[0236] Embodiment 37 is a method of any one of embodiments 34 to 36, wherein each PRN entry includes a second register type bit indicating whether any PRN entry within a group of associated PRN entries has been assigned to a second type of logical register.

[0237] Embodiment 38 is a method of Embodiment 37, wherein the step of designating one or more other PRN entries of the group as unavailable includes the step of setting each individual second register type bit for the first PRN entry and the one or more other PRN entries within the group.

[0238] Embodiment 39 is a method of any one of embodiments 34 to 38, wherein the group of PRN entries is a pair of PRN entries spaced apart by N / 2 entries for a free list having N PRN entries.

[0239] Embodiment 40 is a method of any one of embodiments 34 to 39, wherein the second register set has half the number of physical registers as the first register set.

[0240] Embodiment 41 is a method of any one of embodiments 34 to 40, wherein the first register set includes integer physical registers and the second register set includes floating-point registers.

[0241] Embodiment 42 is a method of Embodiment 41, wherein the shared freelist is configured to maintain PRN entries for an integer register, a flag register, and a floating-point register.

[0242] Embodiment 43 is a method, wherein the method comprises the steps of: maintaining a shared freelist for a plurality of different register sets, each register set comprising a first register set and a different second register set, wherein each register set comprises one or more registers of a different type, and the second register set comprises fewer physical registers than the first register set, and the freelist comprises a plurality of physical register name (PRN) entries, and the freelist comprises a plurality of PRN entries identifying a single register of the second register set; assigning a first virtual PRN from a first PRN entry for a first logical register name of a second type in a first instruction; assigning a second virtual PRN mapped to a first physical register name from a second PRN entry for a second logical register name of a second type in a second instruction; executing the first instruction using the first physical register name; and issuing the second instruction to execute using the first physical register name only after the first virtual PRN has been returned to the freelist.

[0243] Embodiment 44 is a method of Embodiment 43, wherein the step of determining that the first virtual PRN has been returned to the freelist includes the step of determining that the valid bits within the first PRN entry have been cleared.

[0244] Embodiment 45 is a method of any one of embodiments 43 to 44, wherein the method further comprises the step of maintaining a sliding window of a second type of PRN entry that is ready to be issued for execution, and the step of issuing the second instruction comprises the step of issuing the second instruction only after the second PRN entry has entered the sliding window.

[0245] Embodiment 46 is a method of Embodiment 45, wherein the method further comprises the step of maintaining a floating-point tail pointer (FP tail pointer) representing the oldest assigned PRN entry of type 2 assigned to a physical register within a set of main physical registers of type 2, and the sliding window is defined by a predetermined number of PRN entries after the FP tail pointer.

[0246] Embodiment 47 is a method of Embodiment 46, wherein the method further comprises the step of determining that an associated PRN entry for a PRN entry indicated by the FP tail pointer is free for renaming; and, in response thereto, updating the FP tail pointer.

[0247] Embodiment 48 is a method of Embodiment 47, wherein the method further includes the step of clearing a floating-point bit for the PRN entry indicated by the FP tail pointer.

[0248] Embodiment 49 is a method of Embodiment 45, wherein the sliding window size is based on the number of registers in the second register set.

[0249] Embodiment 50 is a method of embodiment 45, the method further comprising: determining that a PRN assigned to a third logical register name from a third PRN entry to a third physical register of a second type is stuck in an architectured map table (AMT); in response thereto, moving data from the third physical register to an architectured floating-point physical register file; and clearing an FP bit for a fourth PRN entry mapped to the same PRN stuck in the AMT.

[0250] Embodiment 51 is a method of Embodiment 50, wherein the step of determining that the PRN is stuck to the AMT includes the step of determining that the FP tail pointer points to the third PRN entry while the PRN is not ejected from the AMT.

[0251] Embodiment 52 is a method of embodiment 50, wherein the method further comprises the step of executing an instruction to read from the third logical register name, and the step of reading a value from an architectured floating-point physical register file rather than from a main floating-point physical register file.

[0252] Embodiment 53 is a method of any one of embodiments 43 to 52, wherein the method further comprises the steps of: issuing an instruction having a renamed register to a reservation station for execution; continuously checking whether a PRN entry used in the instruction is within the sliding window; and executing the instruction after the PRN entry has entered the sliding window.

[0253] Embodiment 54 is a method of any one of embodiments 43 to 53, wherein the first register set includes integer physical registers and the second register set includes floating-point registers.

[0254] Embodiment 55 is a method of Embodiment 54, wherein the shared freelist is configured to maintain PRN entries for an integer register, a flag register, and a floating-point register.

[0255] Embodiment 56 is a method, the method comprising: maintaining a freelist that tracks the availability of physical registers in a physical register file in a processor—the freelist is partitioned into a plurality of regions, each region corresponding to a subset of the physical register file—; determining that a region of the freelist represents an inactive region of the physical register file; and in response thereto, performing clock gating on one or more physical registers in the physical register file corresponding to the inactive region of the freelist.

[0256] Embodiment 57 is a method of Embodiment 56, wherein each freelist entry of the freelist has a valid bit indicating whether the corresponding physical register is in use, and the step of determining that an area of ​​the freelist is an inactive area includes the step of determining that all valid bits of the freelist entries within the area indicate that the corresponding physical register is not in use.

[0257] Embodiment 58 is a method of any one of embodiments 56 to 58, wherein the method further comprises the step of determining that the area of ​​the freelist is between the head pointer and the tail pointer of the freelist; and in response thereto, the step of designating the area as an active area.

[0258] Embodiment 59 is a method of any one of embodiments 56 to 58, wherein the physical register file comprises a plurality of banks, and the step of determining that the area of ​​the free list is an inactive area includes the step of determining that all physical registers in the bank corresponding to the area of ​​the free list are not used.

[0259] Embodiment 60 is a method of embodiment 59, wherein the step of performing clock gating for one or more physical registers includes the step of performing clock gating for a bank corresponding to an area of ​​the freelist while maintaining normal clock operation for one or more other banks of the physical register file.

[0260] Embodiment 61 is a method of any one of embodiments 56 to 60, wherein the step of performing clock gating on one or more physical registers occurs before one or more physical registers are assigned to an instruction.

[0261] Embodiment 62 is a method of any one of embodiments 56 to 61, wherein the method further comprises the step of activating one or more physical registers during an instruction issue stage using one of the one or more physical registers.

[0262] Embodiment 63 is a method of any one of embodiments 56 to 62, wherein the method further includes the step of resuming the normal clock operation of the physical register during the register renaming process using the freelist.

[0263] Embodiment 64 is a processor comprising a logic circuit configured to perform any one of the methods of Embodiments 1 to 63.

[0264] Embodiment 64 is a data processing device configured to perform any one of the methods of Embodiments 1 to 63.

[0265] Although this specification contains many specific implementation details, they should not be interpreted as limitations on the scope of any invention or claimables, but rather as descriptions of features that may be assigned to specific embodiments of specific inventions. Certain features described in this specification in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, while a feature may be described above as operating in a specific combination and may even be initially claimed as such, in some cases, one or more features may be removed from the claimed combination, and the claimed combination may be a sub-combination or a variation of the sub-combination.

[0266] For example, although operations are described in the drawings in a specific order, this should not be understood as requiring that these operations be performed in the specific or sequential order depicted to obtain the desired result, or that all described operations be performed. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of the various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together into a single software product or packaged into multiple software products.

[0267] Specific embodiments of the subject matter of the invention have been described. Other embodiments are within the scope of the following claims. For example, the actions described in the claims may be performed in different orders and still achieve desirable results. As an example, the process illustrated in the accompanying drawings does not necessarily require the specific order or sequential order illustrated to achieve desirable results. In certain cases, multitasking and parallel processing may be advantageous.

Claims

Claim 1 As a processor, A logic circuit configured to maintain a hybrid freelist representing physical registers available for register renaming, wherein the hybrid freelist comprises a plurality of ordered entries—each entry comprising a bit pair for each physical register of the plurality of physical registers—and the logic circuit is configured to generate physical register names of free physical registers, and the logic circuit maintains a head pointer and a tail pointer to perform sequential assignment for the free physical register names. The bit pair for each of the above entries includes an effective bit and a commit bit representing the effective state and the commit state for the physical register, respectively, and The above valid state indicates whether the physical register is free and can be assigned to a logical register name, and A processor in which the above commit state indicates whether an instruction using a physical register has been committed. Claim 2 A processor according to claim 1, wherein the logic circuit is configured to perform operations, and the operations include the operation of finding an entry having a free state using a head pointer. Claim 3 A processor according to paragraph 2, wherein the entries of the hybrid freelist are arranged in a plurality of banks, and the operation of finding an entry having a free state includes the operation of reading a bank corresponding to a head pointer and the operation of finding an entry within a bank having a free state. Claim 4 In paragraph 3, the logic circuit is configured to perform operations, said operations including an operation of filling an output staging buffer based on the valid state of an entry in a bank, and an operation of assigning a physical register name using an entry in the output staging buffer, a processor. Claim 5 In paragraph 4, the operation of filling the output staging buffer includes the operation of generating a full physical register name from an input staging buffer that stores valid bits from an entry in a bank, in a processor. Claim 6 In paragraph 5, the operation of generating the entire physical register name includes the operation of expanding each bit in the input staging buffer into a multi-bit physical register name in the output staging buffer, a processor. Claim 7 A processor according to any one of claims 1 to 6, wherein the logic circuit is configured to perform operations, and the operations include an operation to modify the valid state of an entry corresponding to a physical register name in response to the assignment of a physical register name. Claim 8 A processor according to any one of claims 1 to 7, wherein the logic circuit is configured to perform operations, and the operations include modifying the commit state of an entry corresponding to a physical register when an instruction using a physical register is committed. Claim 9 A processor according to any one of claims 1 through 8, wherein the logic circuit is configured to perform operations, and the operations include modifying the effective state and commit state of an entry corresponding to a physical register name assigned to a logic register name when a subsequent instruction is written to the same logic register name. Claim 10 A processor according to any one of claims 1 through 9, wherein the logic circuit is configured to perform operations, the operations include receiving a flush indication at a specific flush point, and modifying the valid state of any entry in a hybrid freelist that does not have a commit state between the flush point and the head pointer. Claim 11 In paragraph 10, the above operations further include an operation to update the head pointer of the hybrid freelist based on the flush point, a processor. Claim 12 In Clause 10, the flush point is a processor based on the oldest assigned PRN affected by the flush. Claim 13 In paragraph 12, the above operations further include the operation of storing a checkpoint for each PRN-LRN mapping in a reorder buffer (ROB), and the operation of using a checkpoint in the ROB as a flush point, a processor. Claim 14 A method performed by a processor, wherein the method A step of maintaining a hybrid freelist representing physical registers available for register renaming—the hybrid freelist comprises a plurality of ordered entries, each entry comprising a bit pair for each physical register of the plurality of physical registers, and The bit pair for each of the above entries includes an effective bit and a commit bit representing the effective state and the commit state for the physical register, respectively, and The above valid state indicates whether the physical register is free and can be allocated to a logical register name, and The above commit status indicates whether an instruction using a physical register has been committed -; and A method comprising the step of performing sequential allocation of free physical register names from a plurality of entries of a free list using the head pointer and tail pointer of the free list. Claim 15 A method according to claim 14, further comprising the step of finding an entry having a free state using the head pointer. Claim 16 In claim 15, the entry of the hybrid freelist is arranged in a plurality of banks, and the step of finding an entry having a free state comprises the step of reading out a bank corresponding to a head pointer and the step of finding an entry within a bank having a free state. Claim 17 A method according to claim 16, further comprising the steps of filling an output staging buffer based on the valid status of an entry in a bank, and assigning a physical register name using an entry in the output staging buffer. Claim 18 In claim 17, the step of filling the output staging buffer comprises the step of generating a full physical register name from an input staging buffer that stores valid bits from an entry in a bank. Claim 19 In paragraph 18, the step of generating the entire physical register name comprises the step of expanding each bit in the input staging buffer into a multi-bit physical register name in the output staging buffer. Claim 20 A method comprising, in any one of claims 14 to 19, further a step of modifying the valid state of an entry corresponding to a physical register name in response to the assignment of a physical register name. Claim 21 A method according to any one of claims 14 to 20, further comprising the step of modifying the commit state of an entry corresponding to a physical register when an instruction using a physical register is committed. Claim 22 A method according to any one of claims 14 to 21, further comprising the step of modifying the valid state and commit state of an entry corresponding to a physical register name assigned to a logical register name when a subsequent instruction writes to the same logical register name. Claim 23 A method according to any one of claims 14 to 22, further comprising the steps of receiving a flush instruction at a specific flush point, and modifying the valid state of any entry in the hybrid freelist that does not have a commit state between the flush point and the head pointer. Claim 24 A method according to claim 23, further comprising the step of updating the head pointer of the hybrid freelist based on the flush point. Claim 25 In paragraph 23, the flush point is based on the oldest assigned PRN affected by the flush, a method. Claim 26 A method according to claim 25, further comprising the steps of storing a checkpoint for each PRN-LRN mapping in a reorder buffer (ROB), and using the checkpoint in the ROB as the flush point.

Images