Shared freelist

Abstract

Methods, systems, and apparatus for maintaining a shared freelist for register renaming. One of the methods includes maintaining a shared freelist for multiple different register sets, wherein each register set comprises one or more registers of a particular type, wherein the freelist has a plurality of physical register name (PRN) entries. After a first physical register name is allocated to registers of a first type, the first physical register name can be returned to the freelist if the first physical register name does not appear in an architected map table for registers of a second type.

Description

[0001] SHARED FREELIST

[0002] BACKGROUND

[0003] Modem Out-of-Order (OOO) processing leverages register renaming in order to remove false data dependencies so that more instructions can be executed in parallel, which often involves executing them out of order. In this specification, register renaming refers to allocating a physical register name (PRN) to a logical register name (LRN) in an instruction being executed. Using register renaming, subsequent instructions that write to a logical register can be executed before or in parallel with other instructions that use or read from the same logical register name because the register renaming process allocated different underlying physical registers for the logical register name.

[0004] A “freelist’ ' is a microarchitectural component of a processor that maintains a pool of available physical resources, for example, physical registers. In this specification, an available resource, e.g., a physical register, will be described as being in a free state or the corresponding PRN being a free PRN. A freelist can thus provide free PRNs in order to allocate physical registers for register renaming. When a PRN is no longer needed, the PRN can return to the freelist for reuse.

[0005] Freelist size and control logic complexity are major considerations in processor design, which impact silicon area, power, and performance in machines that use OOO processing.

[0006] Traditionally, there have been two primary methods of implementing a freelist in an OOO processor - using a first-in-first-out (FIFO) queue and using a bit vector. In a FIFO freelist, PRNs are allocated one by one from the start of the freelist and returned to the end when no longer needed. Accordingly, in a pure FIFO freelist, PRNs are allocated based on age, with older PRNs that have not been allocated for a longer amount of time being allocated over younger PRNs that have been allocated more recently. However, because the entire PRN, which can be up to 10 bits long or more, is stored in the FIFO, returning a PRN to the FIFO freelist requires writing multi-bit PRN entries. Accordingly, the frequent writing of multi-bit PRN entries in a FIFO freelist requires large area and power requirements, which pose severe problems for performance, cost, and scalability'.

[0007] In contrast, a bit-vector freelist uses a single bit to represent each PRN and therefore has smaller storage requirements than a FIFO freelist. However, a bit vector freelist requires very complex control logic for routine tasks. For example, performing a flush recovery, e.g., after a mispredicted branch, requires substantially more complex logic in a bit- vector freelist than a FIFO freelist because the bit- vector freelist does not contain age information for each PRN. And as the total number of PRNs increases, the complexity of finding available PRNs also increases, which further drives area and power requirements. For example, when providing multiple available entries from a bit-vector freelist, finding the first available, or the first pair of available PRNs, becomes more challenging as the frequency of requests and the vector length increase, which is a substantial scalability bottleneck.

[0008] SUMMARY

[0009] This specification describes technologies relating to a hybrid freelist for fast and efficient register renaming that provides the benefits of both a FIFO and a bit-vector freelist, as well as many other additional advantages. The hybrid freelist maintains a set of PRN entries that require only a few bits of storage. As one example, each PRN entrycan have 1) a valid bit to indicate whether the corresponding PRN is free or if it has been allocated, and 2) a commit bit to indicate whether the PRN is in an architected state, which means that the data in the corresponding physical register is part of the permanent state of the machine at a particular point in time and its corresponding instruction is no longer subject to being flushed or being re-executed.

[0010] In this specification, a PRN entry- is structure storing data from which a PRN can be generated based on the position of the PRN entry in a freelist. In this specification, a freelist being described as generating a PRN means using the position of a PRN entry to generate a PRN, and does not imply that the freelist stores a full PRN itself.

[0011] The hybrid freelist maintains a head pointer that indicates where in the freelist to search for the next free PRN. In some implementations, the head pointer is advanced by freelist segments of multiple PRN entries rather than by individual PRN entries. The hybrid freelist also maintains a tail pointer that indicates the entry corresponding to the youngest PRN that is free to be allocated again. PRNs in front of the head pointer and behind the tail pointer can be allocated in order, skipping PRNs that have already been allocated and not yet returned.

[0012] The tail pointer is generally used to protect the in-order arrangement of allocated PRN entries. The head pointer is thus not allowed to overtake the tail pointer when allocating PRN entries. By maintaining the head and tail pointers, the processor can essentially perform circular allocation of PRNs by cycling through the freelist in order, skipping over PRNs that are already allocated.

[0013] The head pointer can be used for efficient flush recover}'. When recovering PRNs during a flush recover}’, the head pointer is simply redirected to a flush point, and valid bits for PRNs between the flush point and old head pointer are reset, except for PRNs that are in an architected state as indicated by their commit bit.

[0014] Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. A hybrid freelist achieves the benefits of both a FIFO freelist and a bit- vector freelist while mitigating their respective disadvantages. For example, the hybrid freelist can efficiently clear allocated PRNs during a flush recovery. Additionally, the hybrid freelist contains simplified PRN information, which requires less storage space. Accordingly, the hybrid freelist realizes area and power reductions that would otherwise not be achievable in an equivalent FIFO freelist. Additionally, the hybrid freelist is completely scalable in that, as the number of PRNs increase, a flush recovery does not become disproportionately more challenging as it would in a strictly bit-vector freelist. The freelist described in this specification can also efficiently allocate groups of PRNs to satisfy the bandwidth of a hyperscalar processor. For example, the freelist can continually populate input staging buffers and output staging buffers so that N available and full PRNs are already queued up on every cycle.

[0015] The hybrid freelist described in this specification is can 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, which saves power and reduces the required silicon area. For example, the freelist can be used for register renaming for both integer registers and flag registers. The freelist can also be used for register renaming for integer registers and floating point registers, even when the sizes of the respective physical register files are different. Moreover, even when the freelist is used for register renaming for multiple different types of physical registers, the basic scalable flush recovery mechanism remains largely unchanged and can be used for returning all types of physical register names to the freelist after a flush.

[0016] This specification also describes how the freelist can be used to borrow physical register names that have already been allocated. This arrangement increases the efficiency of the processor, mitigates the chances that the processor will run out of register space, and all without adding any additional naming storage. This specification also describes how a processor can improve the floating point instruction bandwidth by introducing a new microarchitectural structure, the architected floating point physical register file, which is an auxiliary physical register file for maintaining the values of floating point registers whose names get stuck in the architected map table.

[0017] This specification also describes techniques for using the in-order structure of the hybrid freelist for saving processor power through clock gating. Because the freelist inherently maintains information about which physical registers are being used during execution, the processor can leverage that information to perform highly targeted clock gating of physical registers that are unused, which saves power without substantially affecting processor performance.

[0018] The details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subj ect matter will become apparent from the description, the drawings, and the claims.

[0019] BRIEF DESCRIPTION OF THE DRAWINGS

[0020] FIG. 1 A is an overview of an example lifecycle of a PRN in a hybrid freelist.

[0021] FIG. IB is an example overview of a hybrid freelist.

[0022] FIG. 2 is an example process of allocating PRNs from a hybrid freelist.

[0023] FIG. 3 is an example process of deallocating PRNs into a hybrid freelist.

[0024] FIG. 4 illustrates an example flush recovery using a hybrid freelist.

[0025] FIG. 5 is an example process for implementing a hybrid freelist.

[0026] FIG. 6 is a diagram of a processor system having a shared freelist that uses a single namespace of physical register names for two different physical register files.

[0027] FIG. 7 is an illustration of how a system can maintain a single shared freelist for integer registers and flag registers.

[0028] FIG. 8 is a flowchart of an example process for maintaining a shared freelist.

[0029] FIG. 9 illustrates PRN borrowing in a system having two physical register sets.

[0030] FIG. 10 is a flowchart of an example process for physical register name borrowing.

[0031] FIG. 11 illustrates one example technique to associate PRN entries for floating point registers. FIG. 12 is a diagram of how a system can maintain a shared freelist between integer registers and floating point registers.

[0032] FIG. 13 is a flowchart of an example process for virtual PRN entry maintenance on a flush recover}' when managing multiple different register sets.

[0033] FIG. 14 is a flowchart of an example process for allocating virtual PRNs for a freelist that manages multiple different register sets.

[0034] FIG. 15 illustrates a sliding window for PRNs in a freelist.

[0035] FIG. 16 illustrates a data structure for handling stuck floating point PRNs.

[0036] FIG. 17 is a flowchart of an example process for managing virtual PRNs for a freelist that manages multiple different register sets.

[0037] FIG. 18 illustrates a hybrid freelist having 512 entries divided into banks of 16 entries each.

[0038] FIG. 19 is a flowchart of an example for clock gating a physical register file based on a freelist.

[0039] Like reference numbers and designations in the various drawings indicate like elements.

[0040] DETAILED DESCRIPTION

[0041] FIG. 1 A is an overview of an example lifecycle 100 of a PRN maintained by a hybrid freelist. The lifecycle 100 includes three phases, which are maintained by three corresponding structures: a hybrid freelist phase 102, a reorder buffer (ROB) phase 130, and an architected map table (AMT) phase 140. Throughout OOO processing, PRNs cycle between these three phases.

[0042] PRNs start in a free state in the freelist phase 102. Free PRNs can then be allocated from the hybrid freelist, renamed, and transitioned to the ROB phase 130, which stores the mapping between PRNs and their corresponding LRNs in instruction order. When a PRN transitions out of the freelist phase 120 and into the ROB phase 130 or into the AMT phase 140, as a general rule the PRN is no longer free and therefore cannot be allocated to another logical register until the PRN returns back to the freelist phase 120. However, in certain circumstances, described in detail below, a PRN can be reallocated to another logical register before returning to the freelist.

[0043] The ROB can also associate each PRN-LRN mapping with a corresponding location in the freelist so that when a flush occurs, the head pointer of the freelist can be efficiently snapped back to the flush point. When the instruction corresponding to an entry in the ROB has finished execution and has reached the head of the ROB, the instruction is committed by retiring the PRN to the AMT, which also stores a mapping between the PRN and its corresponding LRN. The data stored by the physical register corresponding to the PRN is now part of the permanent state of the machine and is not subject to a flush or to being re-executed.

[0044] When a subsequent instruction writes to the logical register of a PRN maintained in the AMT, the PRN mapping is no longer needed and the PRN is evicted from the AMT and cycled back to the hybrid freelist, where it re-enters the hybrid freelist phase 102.

[0045] The hybrid freelist can maintain PRN entries that each have a pair of values, e.g., a pair of bits, to track the valid state and the commit state of each PRN. A ‘‘valid” bit can be used to track the valid state of the PRN, which indicates whether or not the PRN is free for renaming. The valid state of a PRN can thus be referred to as being in a free state or an allocated state.

[0046] A “commit” bit can be used to track the commit state of the PRN, which indicates whether or not an instruction using an allocated PRN has been committed, which means that the value in the corresponding physical register has become a permanent state of the program being executed by the processor and is no longer subject to being flushed or re- executed. The commit state of a PRN can thus be referred to as being in a committed state or an uncommitted state. The change of commit state from an uncommitted state to a committed state generally corresponds to a PRN leaving the ROB and entering the AMT.

[0047] Thus, a PRN or its corresponding PRN entry' can be referred to in this specification as having a free state or an allocated state, which can indicate the value of the PRN entry’s valid bit. Similarly, a PRN or its corresponding PRN entry’ can be referred to as having a committed state or an uncommitted state, which can indicate the value of the PRN entry' ’s commit bit.

[0048] In some cases, the valid and commit bits have a binary' value, where “1” indicates a set value and “0” indicates a cleared value. A set value, e g., “1”, for the valid bit can indicate that the PRN has been allocated for renaming, while a set value for the commit bit can 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”, represent an illegal or improper state because it would mean that a PRN was committed before it was allocated. This situation is not expected to occur, but if it does, the processor can enter a fault state to restore the integrity' of the freelist. A table presenting example combinations of valid and commit bit values is presented in FIG. 1A. In alternative implementations, the values of the what is considered to be set and cleared, or high and low, can be reversed.

[0049] In some implementations, the availability of a PRN can be dynamically constructed rather than being explicitly represented. For example, the free state for each PRN can be determined using a freelist head pointer and tail pointer, instead of maintaining an explicit valid bit for each PRN. In this case, the head pointer indicates the region of the freelist to search for PRNs to be allocated. In addition, the commit state of a PRN can be constructed by inspecting the AMT rather than maintaining a commit bit. However, when a processor has hundreds of physical registers, it can often be faster to simply maintain an explicit commit bit in the freelist rather than searching the AMT.

[0050] FIG. IB is an example overview 101 of a hybrid freelist 132. The hybrid freelist 132 includes a set of PRN entries representing PRNs. 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.

[0051] When PRNs need to be allocated in OOO processing, the hybrid freelist 132 will use the head pointer 108 to find PRN entries for PRNs that can be allocated. Although FIG. IB illustrates one PRN entry at the head pointer 108 in the hybrid freelist 132, the head pointer in the hybrid freelist can be implemented as a coarse-grained pointer that steps per segment of multiple PRN entries. For example, FIG. IB also illustrates how the set of PRN entries in the freelist 132 can be implemented as banks 116, with the head pointer stepping bank-by-bank. In some implementations, the size of each bank is based on the bandwidth of the processor. For example, if the processor may need to rename ten registers per cycle, then the freelist can have a bank size of ten PRN entries, or more than ten PRN entries to account for PRNs that are still in the commit state. Typically each instruction wntes to only one logical register, and therefore, the instruction bandwidth of the processor typically corresponds to the required PRNs to be generated on each cycle.

[0052] The tail pointer 110 is updated as PRNs are retired from the ROB . The tail pointer 110 is updated when the next PRN entry retires from the ROB by having the state {0,0} or {1,1 } for its valid and commit bits. This means that the PRN was retired from the ROB without entering in the AMT or that the instruction using the PRN was committed and the PRN entered the AMT. Alternatively or in addition, when the tail pointer is stepped by banks of PRN entries, the tail pointer is updated when all the entries in the next bank have a state of {0.0} or {1,1 }. The tail pointer 110 thus indicates the youngest PRN entry or bank of PRN entries that can be re-allocated. The head pointer, in contrast, indicates the PRN entry or bank of PRN entries that is the oldest PRN that can be allocated, which corresponds to the PRN that has not been used for the longest number of cycles.

[0053] As mentioned above, the system maintains the tail pointer 110 to preserve the inorder arrangement of PRN entries in the freelist by preventing the head pointer 108 from ever overtaking the tail pointer 110. This is important for maintaining or deriving age information about the PRN entries because if architected PRNs that return to the freelist are reallocated, it might be impossible or impractical to determine the age of the corresponding PRN entries on a flush. Maintaining the tail pointer 110 also improves power performance by preventing the continual updating of the head pointer and staging buffers over many PRN entries that are not free to be allocated.

[0054] When PRN entries are read out from the hybrid freelist 102, a decoding process is performed to generate the corresponding PRN from the position of the PRN entry in the freelist. This process saves storage space because it allows the freelist to efficiently store two bits per PRN rather than all the bits of each PRN.

[0055] The process of using pointers to step through PRN banks is highly scalable. In other words, the head 108 and tail 110 pointers can be used to allocate any number of PRNs from the hybrid freelist without disproportionately increasing processing requirements.

[0056] In some implementations, the freelist continually populates one or more staging buffers so that available PRNs are always ready on each cycle. The input staging buffer receives the PRN entries from the bank indicated by the head pointer. An output staging buffer is then populated with the full physical register numbers corresponding to the PRN entries in the input staging buffer. At either the input staging buffer or the output staging buffer, the PRN entries that are already allocated, e.g., as indicated by their valid bits, can be removed. In some cases, the input staging buffer includes only the valid bit 104 values of each of the PRN entries that have been identified from the hybrid freelist 102. In other words, the input staging buffer can essentially be a bit vector representing which PRNs are free in the bank indicated by the head pointer. The positions of the set bits in the input staging buffer, and the position of the head pointer, then be used to populate the output staging buffer with full PRNs. For example, the output staging buffer can include a bank of 16 different PRNs. In other cases, the buffers can be scaled to include different numbers of PRNs and / or bits. The operation of the staging buffers will be explained in greater detail below with reference to FIG. 2. FIG. 2 is a diagram of an example process 200 of allocating PRNs from a hybrid freelist 202. The example process, as well as other processes described in this specification, can be implemented using digital logic circuitry of a processor, e.g., an out- of-order processor.

[0057] In this example, for simplicity7of illustration, each PRN entry in the freelist 202 is represented as having a single valid bit, although as described above, the hybrid freelist entries would typically also have a commit bit. The processor includes an input staging buffer 204 and an output staging buffer 206. In some cases, when the PRN bank identified by the head pointer is read out, the PRNs within the bank that can be allocated (e.g., valid bits 104 cleared, e.g., “0,” or an alternative availability7state) are expanded into PRNs in a series of input staging 204 output staging 206 buffers. This is accomplished by placing the PRN entries from a bank indicated by the head pointer into the input staging buffer 204. For example, as show n in FIG. 2, an input staging buffer 204 can include 16 bits, where each bit corresponds to a different PRN entry's valid bit value from the bank indicated by the head pointer 108.

[0058] Next, the physical register names that correspond to the PRN entries in the input staging buffer 204 are populated into the output staging buffer 206. The physical register names can be generated by the position of the PRN entries in the freelist. In some implementations, the position can be reconstructed from the position of the head pointer plus the offset of the PRN entry in the input or output staging buffer or in the bank of PRN entries. Assuming a PRN length of 10 bits, the output staging buffer 204 can include the 10-bit PRNs for every free PRN entry in the input staging buffer 204, thus converting the PRN entries to actual PRNs. For example, from 16 bits in the input staging buffer 204. the system can generate up to 16 full 10-bit PRNs in the output staging buffer 206.

[0059] As part of this process, “holes” in the input staging buffer due to PRNs that are not available according to their valid bits are essentially squeezed out so that the output staging buffer stores only PRNs of PRN entries having cleared valid bits.

[0060] The processor can then use the available PRNs in the output staging buffer 204 for renaming, e.g., by allocating PRNs to logical register names and storing each allocated PRN to LRN mapping in the ROB 302.

[0061] FIG. 3 is an example process 300 of deallocating PRNs into a hybrid freelist 102 after being retired from the ROB and / or evicted from an AMT 304. As described above. after a PRN has been allocated, the value of the associated PRN entry valid bit 104 can be set to “1”.

[0062] During OOO processing, the PRN mapping between a PRN and a LRN will remain in the ROB 302 until the associated instruction either commits, causing the PRN to LRN mapping to be retired to the AMT, or is flushed. When a PRN is retired, the value of the commit bit 106 of the associated PRN entry is set toLT” (operation 306), indicating that the PRN’s instruction has been committed and that the PRN has been cycled into the AMT 304 (operation 308). As discussed above, the AMT 304 maintains the PRN to LRN mapping for committed PRNs, and committed PRNs 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 an instruction set, while the size of the ROB 302 is usually much larger because there are usually many more physical registers than logical register names in an 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, e.g., back to “0,” indicating that the PRN is now available for allocation (operation 310).

[0063] FIG. 4 illustrates an example flush recovery using a hybrid freelist 102. In some cases, PRNs need to be returned to the hybrid freelist 102, or deallocated, from the ROB 302. This process is referred to as a flush recovery. A flush recovery can be performed, for example, when instructions were speculatively executed down an incorrect control flow path, e g., a mispredicted branch.

[0064] During a flush recovery, a flush point is designated at a point in the hybrid freelist 102 and the head pointer 108 will be steered to this new point. In some implementations, a flush point is the point at which writers to a particular PRN. and all younger 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 prior to steering) will have its valid 104 bit cleared, e.g., to “0”, except for PRNs in the AMT 304 that are still in use as indicated by their commit bits being set.

[0065] In some cases, to support efficient flush recovery. PRN pointers can be continually check pointed during a dispatch process (operation 402). For example, in the dispatch process, the current head pointer 108 plus an offset value can be associated with each PRN that enters the ROB 302. Alternatively or in addition, the PRN pointers can be stored in other structures linked to the ROB or in structures tracking instructions in flight, e.g., reservation stations or issue queues, to name just a few examples. In other words, the system can use any appropriate structures for gathering the PRNs that are allocated but not yet committed in the AMT, and the corresponding PRN entries will be returned to the freelist on a flush.

[0066] When the flush recovery is commenced, the current checkpoint is indicated by the oldest PRN that will be flushed from the ROB 302. The head pointer of the freelist can then be reset to the flush point by using the pointer of that ROB entry (operation 404). In the case that the head pointer points to banks of PRN entries, the 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 repopulated with PRN data from the new flush point. In some cases, flush recovery' procedures are restricted during allocation times to prevent conflicts with the ROB 302.

[0067] By maintaining a checkpoint, flush recoveries can be performed efficiently without having to exhaustively search for the affected PRNs during a flush. The flush recovery process in the hybrid freelist 102 is also highly scalable because the performance of flush recovery is minimally affected with increasing freelist size. In other words, if the freelist were to grow by a factor of 10. the flush recovery process would still be just as fast. This is very' unlike a bit-vector freelist in which flush recoveries become more computationally intensive as the number of PRNs increases, and more complex and time consuming as the ROB size increases. Using a checkpoint in the ROB also avoids side-tracking the in-flight PRNs. e.g., by the ROB or another structure, to determine and indicate the set of PRNs affected by the flush (as is the case in a bit-vector freelist).

[0068] FIG. 5 is an example process 500 for implementing a hybrid freelist. The process can be performed by a processor configured in accordance with this specification. For convenience, the process will be described as being performed by a system.

[0069] The system uses a freelist head pointer to find a PRN with a free state (e.g., a valid bit having a value of “0”) (510). As described above, PRNs in the hybrid freelist are associated with both a valid bit and commit bit that represent in which phase the PRN is in. The valid bit indicates whether or not a PRN is currently in use.

[0070] The hybrid freelist also maintains a head and tail pointer. The head pointer indicates the next PRN entiy or set of entries to allocate, while the tail pointer indicates the next-to-retire PRN being written by the oldest in-flight instruction that writes to a register. In some implementations, a head pointer points to a bank of PRN entries, and the head pointer steps by each bank of PRN entries. The system allocates the PRN and modifies the free state of the PRN (520). The PRN is then allocated, and the valid bit is updated to indicate that the PRN is no longer free, e.g., a valid bit value of “1”. As described above, once a PRN is allocated from the hybrid freelist it cycles to the ROB, which maintains an in-order list of instructions that have been allocated PRNs as well as PRN-to-LRN mappings for those instructions.

[0071] The system retires the PRN and modifies the commit state (530). At commit time, the PRN is retired and the PRN-to-LRN mapping is stored in the AMT. When this occurs, the commit bit of the PRN entry is modified to indicate that the PRN has been retired (e.g., by setting the value of the commit bit to “1”). As described above, when a PRN transitions to the AMT. it can evict an older PRN that was allocated to the same LRN for an older instruction.

[0072] The system evicts the PRN from the AMT and modifies the free state of the PRN (540). When a PRN is evicted from the AMT, and returned to the hybrid freelist, both the valid bit and commit bits are updated to indicate the PRN is free, e.g., both values of the valid bit and the commit bit can be set to “(T.

[0073] This specification also describes how a freelist can be used for multiple different types of physical registers that each have their own physical register namespace. For example, some processors have different physical register files that each have their own namespaces. Instructions can reference different logical register names that correspond to different underlying physical register files. While it would be possible to maintain a separate freelist for each respective physical register file, in many situations this would result in inefficient and redundant hardware.

[0074] Instead, the techniques described in this specification allow a processor to use a single, shared freelist to maintain and allocate physical register names for multiple different register files. When executing an instruction requires a physical register name for register renaming, the freelist can allocate physical register names using the single, shared namespace that applies to both types of physical register files. In addition, for some instructions that reference multiple different types of registers, the freelist can allocate the same physical register name for both types of logical registers in the instruction.

[0075] One primary benefit of using a shared freelist for multiple different types of physical register files is that only one flush recovery mechanism needs to be executed on a flush. In addition, sharing the freelist between the different types of registers saves hardware resources without significantly affecting performance. FIG. 6 is a diagram of a processor system 600 having a shared freelist that uses 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, through FRN.

[0076] The system 600 also includes a shared freelist 630 that maintains physical register name entries PRN1, PRN2, through 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.

[0077] Typically each physical register file has its own architected map table (AMT). Thus, the physical register file 610 would have its own AMT. and the second physical register file 620 would have its own AMT. Because the two physical register files are sharing a same namespace for register renaming, the system can ensure that a physical register name is not returned to the freelist 630 unless it is evicted from or is absent from both AMTs.

[0078] One example of a separate type of physical register file is a special register file. In some processors, special physical registers can be used to maintain information about the state of the processor. These special registers are often maintained in a separate physical register file from the physical register file for integers or floating point numbers.

[0079] An example of a special register is a flag register, which is sometimes called an application program status register. In this specification, a flag register wall refer to any special register that can be referenced by a logical register name in an instruction set that has a different physical register file than an integer register file or a floating point register file.

[0080] In some processors, there is only one logical flag register that instructions can write to but dozens or hundreds of physical flag registers that can be allocated to the single, logical flag register. This is because in OOO execution, the flag register can be used to maintain the conditional state of many different in-flight instruction branches. Therefore, register renaming can be used to maintain the status of all of the in-flight conditional branches, even though the instruction set has only one logical flag register.

[0081] FIG. 7 is an illustration of how a system 700 can maintain a single shared freelist 730 for integer registers and flag registers. The sy stem 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 each include a valid bit and a commit bit. The integer register file 710 has its own integer AMT 740. The flag register file 720 also has its own flag AMT 750.

[0082] As described above, the valid bit indicates whether or not a physical register name is free for register renaming, or if it has already been allocated. The commit bit represents whether or not the physical register name is currently still in the AMT. These two bits, as described above, dictate how the system allocates physical register names and also how the system handles returning physical register names to the freelist on a flush, which essentially involves returning PRNs allocated after the flush point that are not yet in the AMT.

[0083] In this example system, integer registers and flag registers share the freelist 730 by using explicitly represented valid bits in PRN entries of the freelist 730.

[0084] The system 700 can use the integer commit bits 706 of the PRN entries to track the commit state of PRNs allocated to integer registers. But for flag PRNs, the system 700 can reconstruct a virtual flag commit bit from the PRN entries and from the status of the flag AMT 750. This saves the system from having to maintain a separate freelist for flag registers and keeps the size of the PRN entries at two bits each.

[0085] In this example, the flag AMT 750 has only a single entry' because in this example flag registers have only a single logical register in the instruction set. Therefore, the physical-to-logical register name mapping in the flag AMT 750 only needs a single entry. Moreover, the flag AMT 750 only needs to store the physical register name, and not a full mapping from the physical register name to a logical register name when there is only a single logical flag register. Thus, the flag AMT 750 is illustrated as only storing a single PRN instead of a mapping. In contrast, the integer AMT 740 has as many integer entries as there are integer logical registers, and the integer AMT 740 stores mappings between the physical register name and the logical register name for each entry.

[0086] At allocation time, a physical register name can be allocated according to its valid state. For integer registers and flag registers this means checking the valid bit in the freelist 730. But in order to prevent naming conflicts, system also performs a bit-wise OR between the valid state as indicated by the PRN entry with a decoded commit bit from the flag AMT 750. This prevents reallocation of the same PRN until the PRN has been evicted from or is otherwise absent from both AMTs 740 and 750.

[0087] A decode module 770 can be used to generate a decoded commit bit for any PRN entry in the freelist 730 by checking to see whether the corresponding PRN is still in the flag AMT 750. In other words, for a particular PRN, the decode module 770 can generate a 1 for the decoded commit bit if the PRN is in the flag AMT 750 and can generate a 0 for the decoded commit bit otherwise.

[0088] Then, from the decoded commit bit for a PRN, the system 700 can generate the virtual valid bit 772 for the PRN with a bit-wise OR 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 an integer register and a flag register can be simultaneously allocated to the same PRN when they occur in the same instruction.

[0089] Similarly, the system 700 can generate the virtual flag commit bit 774 for the PRN with a bit- wise OR between 1) the decoded commit bit and 2) the commit bit of the corresponding PRN entry in the freelist 730.

[0090] As described above, a physical register name can become free again when the PRN is not still in the integer AMT 740 or in the flag AMT 750. For the integer AMT 740, the system can use the commit bit of the PRN entries in the freelist 730 to determine whether a physical register name is still being maintained in the integer AMT 740.

[0091] On the other hand, because there is only one logical flag register maintained by the flag AMT 750, the system can save considerable storage space by determining the flag commit bit virtually from the decoded commit bit. Thus, for flag PRNs, the system can determine the commit state by performing a bit-wise OR between 1) the commit bit of the corresponding PRN entry, and 2) the decoded commit bit.

[0092] TABLE 1 summarizes the states of PRN entries that are shared between integer registers and flag registers.

[0093] TABLE 1

[0094] The operations for maintaining the shared freelist 730 will now be described. During operation 1, a physical register name can be allocated by identifying a PRN entry in the freelist having a free state. As described above, PRN entries that are 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 a freelist position of the corresponding PRN entry'.

[0095] Because the integer register file 710 and the flag register file 720 are sharing a namespace, if an instruction references a logical register for the integers, or a logical register for the flag registers, the system simply allocates a physical register name for any free PRN entry' in the freelist 730.

[0096] In some implementations, the system can assign the same PRN to both an integer register and a flag register. For example, if a single instruction references both an integer logical register and the flag logical register, the system can find an available PRN from the freelist and allocate the same PRN to both the integer logical register and the flag logical register. Although they are allocated the same physical register name, the values written to the respective logical registers will be stored by different physical registers because the logical register names refer to the different physical register files 710 and 720.

[0097] The PRN to LRN mapping is then stored in the ROB 760 while the instructions are executed. In some implementations, the ROB 760 includes fields 711 and 712 that indicate whether the mapping is an integer mapping, a flag mapping, or both. Because the system is allocating the same physical register name for instructions that reference both the integer register file 710 and the flag register file 720, the ROB 760 only needs two bits — a flag bit 711 and an integer bit 712 — for each ROB entry' to represent if the entry is an integer mapping, a flag mapping, or both.

[0098] Operation 2 represents a flush recovery. Because the integer register file 710 and the flag register file 720 are sharing a freelist, only a single flush operation for the freelist 730 needs to be performed. As described above, the head pointer of the freelist 730 will be snapped back to the flush point indicated by a checkpoint in the ROB 760. as described above. Any allocated PRN entries after the flush point and before the head pointer that do not have their commit bits set will be returned to the freelist, e.g., by resetting their valid and commit bits.

[0099] Operation 3 represents a bypass return to the freelist 730. This is a special case that avoids unnecessary storage of a PRN in the AMTs. For example, if a physical register mapped to a logical register retires in the same cycle as a younger instruction writing to the same logical register, there is no need to add the physical register to the AMT because it will be overwritten by the younger water. Therefore, the physical register name can bypass the AMT and return directly to the freelist. In doing so, the system can clear the valid and integer commit bits, e.g., by setting them to 0.

[0100] During operation 4, when a PRN is retired from the ROB 760, if a PRN was only an integer PRN, the PRN will be retired to the integer AMT 740. The system can also set the integer commit bit of the corresponding PRN entry, e.g., by setting it to 1. If a PRN was only a flag PRN, the PRN will be retired to the flag AMT 750. If a PRN was both an integer PRN and a flag PRN. the PRN will be retired to both AMTs 740 and 750.

[0101] The PRNs can eventually be evicted from their respective AMTs 740 and 750.

[0102] During operation 5, an integer PRN is evicted from the integer AMT 740. The system can clear the valid bit and the integer commit bit from the corresponding PRN entry7of the freelist 730 to indicate that the PRN is no longer in the integer AMT 740.

[0103] However, the PRN will not actually become free for allocation unless and until the PRN is not also stored in the flag AMT 750. As described above, the system 700 can enforce this restriction using the virtual valid bit 772 that is a bit-wise OR between the valid bit of the PRN entry and the decoded commit bit from the flag AMT 750.

[0104] When a flag PRN is evicted from the flag AMT 750, the system can reset the valid bit of the corresponding PRN entry7. When this occurs, a different PRN will be stored by the flag AMT 750, so the decoded commit bit will change for that PRN from 1 to 0. Therefore, at that point the virtual flag commit bit for the PRN will be reset to 0 unless the integer PRN is still in the integer AMT 740.

[0105] FIG. 8 is a flowchart of an example process for maintaining a shared freelist. The process can be performed by a processor configured in accordance with this specification. For convenience, the process will be described as being performed by a system.

[0106] The system maintains a shared freelist for multiple t pes of register sets (810). As described above, a processor can have different physical register files, each having their own physical register names. For multiple physical register files, the system can maintain a single physical register namespace. As one example, the system can maintain a single physical register namespace for both integer registers and flag registers that are maintained in separate physical register files.

[0107] The system generates a first physical register name for a physical register of the first type (820), and a second physical register name for a physical register of the second ty pe (830). In other words, the system can generate physical register names from the same, shared freelist even though the physical registers are in different physical register files. And. as descnbed 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 the different physical register files.

[0108] The system retires the first physical register name and the second physical register name to different respective AMTs (840). As described above the different register files have different AMTs for maintaining the state of the processor for committed instructions.

[0109] The system designates the first physical register name as free if the first physical register name is not in the second AMT (850). In other words, because the different physical register files are sharing namespaces, a physical register name should not become free 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 check to make sure that the physical register name is not still being maintained in the second AMT. As described above, in some implementations, the system can perform this check as a bit-wise OR between a decoded commit bit and a valid bit that is maintained in the PRN entry of the freelist

[0110] This specification also describes how a shared freelist can be used to borrowphysical register names that are already allocated. In other words, in some situations even though a physical register name is already allocated to a logical register of an instruction, the same physical register name can be reallocated for another logical register under certain situations. This arrangement increases the efficiency of the processor, mitigates the chances that the processor will run out of register space, and all without adding any additional naming storage.

[0111] FIG. 9 illustrates PRN borrowing in a system having two physical register sets 910 and 920. In this example, the shared freelist 930 will be used to allocate physical register names for a sequence of instructions 905, 915, and 925. In this example, the same physical register name is used for logical registers referenced by the instructions 905 and 925. The add instruction 905 adds the values of logical registers X2 and X3 and stores the value using logical register XI. This is a situation that requires allocation of a physical register, so the shared freelist 930 generates a physical register name, in this example PRN2, which can be, for example, the bi nan value 0x10. Therefore, the processor will use that physical register name to identify a second physical register in the integer register set 910. Consequently, the result of the add instruction is written into the second physical integer register 911.

[0112] Next, an intervening store instruction 915 is executed. Because the store instruction does not require writing any values to any physical registers, the store instruction does not need allocation of any physical registers with register renaming. Because of this, if the next instruction references only logical registers of a different type, the physical register name that was allocated for the add instruction 905 can be reallocated for the logical register of the instruction 925.

[0113] The instruction 925 compares the values of logical registers X5 and X6 and stores the result in the flag register. The syntax of the instruction 925 references the flag register only implicitly by virtue of it being a compare instruction. Because the instruction 925 needs to write to a 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.

[0114] But because the compare instruction 925 satisfies the criteria for borrowing physical register names, the freelist 930 re-allocates the same physical register name that it generated for instruction 905 by again generating PRN2. As a result, the result of the compare instruction will be stored in the second physical flag register (921).

[0115] FIG. 10 is a flowchart of an example process for physical register name borrowing. The process can be performed by a processor configured in accordance with this specification. For convenience, the process will be described as being performed by a system.

[0116] The system maintains a shared freelist for multiple different register sets (1010). As described above, the different register sets have different types and are referenced by logical register names that reflect those types.

[0117] The system allocates a first physical register name for a first physical register of a first type (1020). The system can use the freelist allocation process to generate a next available PRN according to the values of its PRN entries and the location of the head pointer. The system receives a second instruction for a physical register of the second ty pe (1030) and the system determines whether the second instruction satisfies one or more borrowing criteria with the first instruction (1030). In other words, the system can check the second logical register ty pe against one or more previously received instructions to determine whether or not the instructions satisfy one or more borrowing criteria.

[0118] A first example of a borrowing criterion is the instructions being sequential. Thus, in some implementations, the system checks an instruction against a previously executed instruction to determine if they7reference physical registers of different types. If so, the system can determine that the two instructions satisfy the borrowing criteria.

[0119] A second example of a borrowing criterion is that one or more intervening instructions are instructions that do not need register renaming. For example, a store instruction between two other instructions is an example of an instruction that does not require register renaming. Thus, any arbitrary' number of store instructions could occur between the two instructions, and they may still satisfy' the borrowing criteria.

[0120] A third example of a borrowing criterion is whether the instructions are renamed in the same cycle. As described above, the use of input and output staging buffers allows the processor to perform multiple renames in the same cycle. Thus, in some implementations, the system can allow borrowing only between instructions that are renamed in the same cycle.

[0121] A fourth example of a borrowing criterion is whether there is a branch instruction between the two instructions. In some implementations, to simplify the logic of flush recoveries, the system can disallow borrowing if an intervening instruction is a branch instruction. However, in some alternative implementations, borrowing can still be allowed despite an intervening branch instruction if the processor treats the instructions as a non-borrowing case after flush recovery is initiated. In other words, before the flush recovery, the system can allow borrowing, but after a flush, the system can disallow borrowing for the instructions.

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

[0123] On the other hand, if the one or more borrowing criteria are satisfied, the system re-allocates the same PRN for the second instruction (branch to 1060). As described above, when the same PRN is used to execute the different instructions, the results will actually go to different physical register files. When the two instructions have been allocated the same PRN, the system can ensure that both are evicted from their respective AMTs before returning the PRN to the freelist. Thus, when a first PRN is evicted from the AMT by a younger writer to the logical register, the system can check commit status of the other PRN, either by checking an explicitly maintained commit bit or by searching its AMT. Only if both PRNs have been evicted from their respective AMTs will the system return the shared PRN to the freelist.

[0124] This specification also describes how a shared freelist can be further extended to also manage physical floating point registers without a substantial increase in hardware costs. By sharing the freelist between integer registers and floating point registers, the processor can actually get rid of a separate freelist for floating point registers. In addition, the freelist can still employ the same allocation and flush recovery processes with only an insubstantial amount of additional record keeping.

[0125] Sharing between integer registers and floating point registers has more complexity7than sharing with flag registers because there tend to be fewer floating point registers than integer or flag registers. A processor design is the result of a carefully chosen number of each type of register in order to achieve a particular level of performance and efficiency. Thus, the relative number of physical registers in each register file varies considerably, but floating point registers tend to be fewer than integer registers, in part because floating point registers are larger in size. As described above, there can efficiently be the same number of integer registers and flag registers because flag registers store far less data than integer registers, e.g., 4 bits for a flag register versus 64 bits for an integer register. In contrast, the number of physical floating point registers may be far less, e.g., only a quarter or half the number of integer registers, to name just a few common examples.

[0126] In order to support sharing between integer registers and floating point registers, the system can essentially allocate virtual PRN's for floating point registers. In this specification, a PRN being virtual means that the PRN belongs to a namespace that does not correspond to the size of a physical register file. Instead, there is a mapping between each virtual PRN and each floating point PRN in a floating point PRN namespace that does correspond to the size of the physical register file. When the freelist is used to maintain the virtual PRN namespace, this means that every PRN entry in the freelist can be allocated for a floating point register, but because there are fewer floating point registers than freelist entries, multiple PRN entries in the freelist having different virtual PRNs can be mapped to the same floating point PRN. In order to avoid reallocating a floating point PRN that has already been allocated, the system can keep track of which PRN entries are associated with each other by having virtual PRNs that are mapped to the same floating point PRN. Then, if a PRN is already allocated to a floating point register, none of the other associated PRN entries can be allocated to another logical floating point register name until the allocated one is deallocated. However, during this time, the PRNs of the other associated PRN entries can still be assigned to other register types, e.g., integer registers. In the description that follows, PRN entries being described as being paired or associated PRN entries means a group of multiple PRN entries having different virtual PRNs that map to the same floating point PRN.

[0127] The techniques described below for sharing between integer registers and floating point registers can also be combined with the techniques described above for sharing with flag registers and for PRN borrowing. Therefore, the shared freelist described in this specification can be used to maintain PRN allocation for at least three different types of physical registers: integer, flag, and floating point registers.

[0128] FIG. 11 illustrates one example technique to associate PRN entries for floating point registers. In this example, the physical floating point register file has half as many physical registers as the integer physical register file. Therefore, the freelist can maintain the virtual PRN namespace by associating two PRN entries with every floating point PRN. To do so, the system can pair the PRN entries in any appropriate manner such that each pair of PRN entries identifies the same floating point PRN. FIG. 11 illustrates one example of pairing PRN entries in a way that does not require overly complex logic or record keeping.

[0129] As shown in Figure 11. the freelist of N PRN entries is conceptually divided into two halves: a first half 1110 that spans from PRNO to PRN N / 2 - 1 and a second half 1120 that spans from PRN N / 2 to PRN N-l. Corresponding PRN entries in each half are paired together so that they each identify the same floating point PRN in the physical floating point register file 1130, which has N / 2 entries.

[0130] For example, the PRN entries for PRNO and PRN N / 2 both identify the first floating point register FP PRO. Similarly, the PRN entries for PRN N / 2-1 and PRN N-l both identify the last floating point register FP PR N / 2-1.

[0131] With this arrangement, the system can quickly and efficiently check to see whether a paired PRN entry has been assigned to a floating point register. If so, the system can re-assign the same PRN to another register type, but not to another floating point register. FIG. 12 is a diagram of how a system can maintain a shared freelist between integer registers and floating point registers. As shown, 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 the integer registers and a floating point AMT 1250 for the floating point registers. Each AMT stores a mapping between logical register names and physical register names for their respective physical register files.

[0132] Unlike the shared freelists described above, the shared freelist 1230 includes an additional bit for each PRN entry to track whether or not the PRN entry' has been allocated to a floating point register. Thus, each PRN entry includes a valid bit, a commit bit, and a floating point bit (“FP bit”).

[0133] TABLE 2 summarizes the states of PRN entries that also have a floating point bit.

[0134] TABLE 2

[0135] As shown in TABLE 2, the FP bit of a PRN entry is used to keep track of whether a PRN for the PRN entry, or for an associated PRN entry that maps to the same floating point PRN, has been allocated to a floating point register. If the PRN entry7itself has been allocated to a floating point register, the PRN cannot be allocated to any other register until it returns to the freelist. However, if. for a particular PRN entry, its associated PRN entry has been allocated to a floating point register, the particular PRN entry can still be used to allocate a PRN to a non-floating point register. In FIG. 12 operation 1, the freelist generates a PRN for a physical register and sets the valid bit for the corresponding PRN entry. If the physical register is a floating point register, the system sets the FP bit for the PRN entry as well as for all other paired or associated PRN entries. That makes the paired or associated PRN entries having FP bits set available for allocation only to non-floating point registers, until the PRN returns to the freelist, e g., during a bypass return, on a flush, or by being evicted from the FP AMT 1250.

[0136] The PRN-LRN mapping then enters the ROB 1260. In order to keep track of which AMT to retire a PRN to, the ROB 1260 can also maintain integer and floating point fields 1211 and 1212 to indicate whether the PRN is allocated to a floating point register or to a non-floating point register. During operation 2, the PRNs are retired to their respective AMTs 1240 or 1250, which can be based on the integer and floating point fields 1211 and 1212 of the ROB 1260. The corresponding PRN commit bits will then be set to indicate that they have been retired to their AMTs, as indicated by the label “Set PRN commit = 1.”

[0137] During flush recovery at operation 3, the system can use checkpoints in the ROB to reset the head pointer to a flush point and then flush the affected PRN entries between the old head pointer and the flush point by resetting their valid bits, unless they are stored in an AMT according to their commit bits. Thus, if the commit bit is 0 for a flushed PRN entry, the system clears both the valid and floating point bits.

[0138] However, the system can perform some additional maintenance to account for the virtual PRNs, which may result in restoring the FP bits in the PRN entries. Namely, the system can perform a bit-wise OR between all associated PRN entries, and if any of the associated PRN entries has an FP bit still set, the system sets the FP bit in all of the associated PRN entries. On the other hand, if all of the associated PRN entries do not have an FP bit set, the system can decline to restore any of the FP bits.

[0139] This additional step accounts for the situation in which a PRN entry is allocated to a physical floating point register, and its paired or associated PRN entry’ gets flushed. In that situation, the system can restore the FP bit of the flushed PRN entry so that it does not get re-allocated to another floating point register. Thus, the system can perform a bitwise OR between the FP bits of all associated PRN entries and stores the resulting value for the FP bit in all associated PRN entries.

[0140] In this example, the bit-wise OR process includes first determining the paired PRN entry. When the PRN entries are paired as illustrated in FIG. 11, the paired PRN entry can be obtained using integer addition of N / 2, where N is the size of the freelist (1221). The system then decodes the values of the FP bits of the paired PRN entries (e.g. using decode modules 1222 and 1223), performs the bit-wise OR between the FP bits (1224) and writes the result to both PRN entries in the freelist 1230.

[0141] A final step can be performed to account for the opposite situation in which the paired PRN entry has not been allocated, as evidenced by its valid bit. In that situation, the system clears the FP bits of both PRN entries. This maintenance of FP bits during a flush is described in more detail below with reference to FIG. 13.

[0142] During operation 4, when a 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 so, the system can first determine the paired PRN entry, which can include performing integer addition of N / 2 (1231) in this example. The system can then clear their respective FP bits (1232 and 1233). As per the usual operation of returning a PRN to the freelist, the system can also clear the valid and commit bits of the PRN entry.

[0143] During operation 5, which is a bypass return of an FP PRN without reaching the FP AMT 1250. the system can clear the valid and commit bits of the PRN entry. And because the FP PRN is ready to be reallocated to another floating point register, the system can also clear all FP bits for all paired or associated PRN entries.

[0144] FIG. 13 is a flowchart of an example process for virtual PRN entry maintenance on a flush recovery when managing multiple different register sets. The process can be performed by a processor configured in accordance with this specification. For convenience, the process will be described as being performed by a system.

[0145] As described above, to perform a flush recovery, the system resets the head pointer to a flush point. All PRN entries that are after the flush point and before the old head pointer location will be processed according to the operations of FIG. 13. Thus, the system can perform the example process for all flushed PRN entries.

[0146] 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. Thus, the system clears the valid bit and the 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).

[0147] The system performs a bit-wise OR between the associated PRN entries and writes the result to the FP bit of each associated PRN entry (1330). In other words, if any of the paired or associated PRN entries have their FP bit set, all of the paired or associated PRN entries will have their FP bits set. The system determines whether any of the associated PRN entries have a valid bit set (1340). In this situation, if a PRN entry in a group of paired or associated PRN entries has a valid bit set, it has been allocated to a register that was not subject to the flush and will be left alone (branch to end).

[0148] But if all of the paired or associated PRN entries do not have a valid bit set, then the FP bits also need to be cleared in order to make the PRN entries available to floating point registers in the future. Thus, if all paired or associated PRN entries do not have the valid bit set, the system clears all floating point bits for PRN entries in the group (branch to 1350).

[0149] FIG. 14 is a flowchart of an example process for allocating virtual PRNs for a freelist that manages multiple different register sets. The process can be performed by a processor configured in accordance with this specification. For convenience, the process will be described as being performed by a system.

[0150] The system maintains a shared freelist for multiple different types of register sets (1410). As described above, the system can allocate virtual PRNs by maintaining a virtual PRN namespace where multiple PRN entries having different virtual PRNs can be mapped to the same physical register name. The system can thus group together multiple PRN entries that map to the same PRN number for physical registers of a particular type.

[0151] The system allocates a first PRN for a logical register name of the second type (1420) and designates one or more other PRN entries as unavailable for allocation for logical registers of the second type (1430). As described above, the system can maintain a separate bit value in each PRN entry7to indicate whether any of the associated registers in the group have been allocated to registers of a particular type. For example, the sy stem can maintain a floating point bit to indicate whether any paired or associated PRN entries have been allocated to a floating point register. If so, the other PRN entries in the group are not available to be allocated to floating point registers, but they can still be allocated to other types of non-floating point registers.

[0152] Although for clarity the descriptions above used floating point registers as an example of a register type having virtual PRNs, the same techniques can also be used for any other appropriate register types.

[0153] This specification also describes another way that a shared freelist can support multiple different types of register files. In the floating point register examples described above, because there are fewer floating point registers than 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, N / 2 floating point PRNs were allocated for N / 2 physical floating point registers for a freelist of size N.

[0154] However, for some applications that heavily use floating point execution, the renaming process itself can become a performance bottleneck. Therefore, the system described above can be configured or reconfigured, e.g., either during execution or during manufacture, to allow the concurrent allocation of multiple associated or paired PRN entries to different logical floating point registers. In other words, a group of PRN entries with different virtual PRNs that map to the same floating point PRN can be allocated over the same time period for logical register names. In contrast, in the examples described above, a paired or associated PRN entry that mapped to the same floating point PRN as an already allocated PRN could only be allocated to a different type of register, e.g., an integer or a flag register.

[0155] In order to prevent a clash between multiple instructions that are assigned the same floating point PRN, the system can manage renaming and execution in different stages. In a first stage, the system allocates a floating point PRN for an instruction but does not yet allow the instruction to execute. In a second stage, the system issues the instruction for execution only if a PRN entry having a different virtual PRN that is mapped to the same floating point PRN is available for renaming, e.g., because it was never allocated or because it has returned to the freelist. Returning the same floating point PRN to the freelist means that the floating point PRN was evicted from the AMT or returned in another way, e.g., by a bypass return described above, and means that the data in the physical register is no longer needed by the program. The effect of this is to push resolution of name clashes from the renaming stage to the execution stage, where real data dependency conflicts will have to be resolved in any event.

[0156] In order to support multiple paired or associated PRN entries being assigned to floating point registers, the system can use modified logic to determine when to set and clear the FP bits of PRN entries in the freelist when being allocated and deallocated for floating point registers, as well as modified logic to determine when to allow instructions to issue when they write to floating point registers.

[0157] In order to maintain information about which instructions using floating point registers are ready to be issued, the system can maintain a sliding window of PRN entries in the freelist. The sliding window separates which PRNs are ready to be issued for execution and which have to wait for the floating point PRN to be returned to the freelist before being issued. The sliding window is a separately maintained data item from the head and tail pointers of the freelist itself.

[0158] This specification also describes technologies and circuit structures for handling stuck floating point PRNs that can otherwise never enter the sliding window for execution. There are many situations in which a PRN can get stuck in the AMT. As described above, a PRN can stay in the AMT until a logical writer evicts it. But in many programs, there can be an instruction that writes to a logical register once and writes to it either much later in the program or never writes to it again. In that situation, the floating point PRN may get stuck in the AMT indefinitely, leaving its paired or associated PRN entry unable to be issued for execution.

[0159] FIG. 15 illustrates a sliding window for PRNs in a freelist. In this example, the freelist is maintained in banks of 16 PRN entries each. Thus, the first bank 1510 includes PRN entries 0 to 15. The total freelist size is 512 entries, so the last entry 1520 includes PRN entries 495 to 511.

[0160] In this example, the number of floating point registers is half the number of integer registers. Therefore, the sliding window 1545, indicated by dashed lines, is 256 entries, which is half the number of integer registers. Using this arrangement, the system can assign two PRN entries to two different instructions even when the PRN entries map to the same floating point PRN. Put another way, the different virtual PRNs of the PRN entries map to the same floating point PRN.

[0161] To implement the sliding window, the system can maintain a floating point tail pointer (FP tail pointer) that points to the oldest PRN entry that has been allocated to a floating point register in the main floating point register file. The FP tail pointer is distinct from the freelist tail pointer described above, which for clarity may be referred to as the FL tail pointer to distinguish it from the FP tail pointer that defines the sliding window. From the FP tail pointer, the system can consider the next M PRN entries as being within the sliding window, where M is based on the size of the physical floating point register file. The system can thus use the FP tail pointer to determine which PRN entries to designate as being ready for execution by entering the sliding window. The instructions using the PRN entries within the sliding window can be safely executed because they are guaranteed to have a corresponding physical floating point register at execution time, because the sliding window is based on the size of the physical floating point register file. Thus, in order to move the sliding window, the next PRN entry or the next group, e.g., bank or row, of PRN entries have to have their FP bits cleared.

[0162] In the previous example described above with reference to FIGS. 11-14, FP bits get set when a paired or associated PRN entry is allocated to a floating point register. But in this example, this requirement is modified and the setting and clearing of each FP bit depends only on the status of the PRN entry itself and not on the associated or paired PRN entries. Instead, the system uses the sliding window to avoid name clashes rather than the FP bit.

[0163] The system can thus clear the FP bit for a PRN entry' when the PRN entry' becomes free for renaming, e.g., by returning to the freelist after being evicted from the FP AMT, by being part of a flush, or by entering an architected floating point register file, which is described in more detail below. The system can check the valid bits of the PRN entry in order to determine whether or not it is free for renaming.

[0164] The FP tail pointer can be stepped per PRN entry' or by each bank of PRN entries. When the FP tail pointer is stepped per PRN entry, the FP tail pointer can be advanced when the FP bit of the oldest allocated PRN entry gets cleared. For example, the system can continually check the valid bit of the PRN entry' indicated by the FP tail pointer, and the valid bit indicates that the PRN entry' is available for renaming, the system can clear the FP bit of the PRN entry and advance the FP tail pointer. When the FP tail pointer is stepped per bank of PRN entries, the system can advance the FP tail pointer when all FP bits in the oldest bank are cleared.

[0165] When the FP tail pointer is updated, thereby moving the sliding window, the system can issue the instructions allocated to PRN entries that have entered the sliding window sequentially or concurrently.

[0166] FIG. 16 illustrates a data structure for handling stuck floating point PRNs. A PRN that is stuck in the AMT can delay execution of floating point instructions because the FP bit of the PRN entry' will never get cleared. And when the FP bit never gets cleared, the FP tail pointer cannot be advanced, and new floating point instructions will not enter the sliding window.

[0167] Thus, in order to resolve this issue, the system can use a new auxiliary physical register fde that stores the architected floating point values for physical registers having PRNs still in the AMT. The architected floating point physical register fde (APRF) 1620 is a separate physical register fde from the main floating point physical register fde (MPRF) 1610. The APRF 1620 only needs as many physical registers as there are logical registers for the processor, while the MPRF 1610 typically has many more physical registers. For example, if a processor has 32 logical registers, the APRF only needs to have 32 physical registers. Meanwhile, the MPRF typically has hundreds of physical registers or more, e.g., 256 or 512 registers.

[0168] The APRF 1620 allows the processor to clear the FP bit for a floating point PRN entry while still preserving the possibility that the value of the stuck PRN will be read in the future. The processor cannot simply remove a stuck PRN from the AMT because it is impossible to know whether the logical register will be read at some time in the future.

[0169] The APRF 1620 essentially provides another avenue for the FP bit of a PRN entry to be cleared. Thus, the ways that the FP bit for a PRN entry can be cleared when using an APRF include: the PRN returning to the freelist by eviction from the FP AMT, from a bypass return, or from a flush, as well as the PRN entering the APRF.

[0170] Each entry7in the APRF 1620 has a corresponding PRN in a virtual PRN table 1640. The size of the entries in the virtual PRN table 1640 only needs to be able to store the bits of a PRN, and thus, the virtual PRN table 1640 is typically smaller than the APRF 1640 for the same number of entries.

[0171] Consumers 1650 of the data stored in physical floating point registers, e.g., an execution unit executing an instruction that reads a floating point register, can first check the virtual PRN table 1640. If there is a hit. the consumer 1650 will read the data from the APRF 1 20 rather than from the MPRF 1610. Otherwise, the consumer will read from MPRF 1610.

[0172] TABLE 3 summarizes the states of PRN entries when using a sliding window.

[0173] TABLE 3

[0174] TABLE 4 illustrates an example of a stuck PRN through a sequence of instructions. In this example, the freelist has 10 entries, and the floating point physical register file has 5 registers. The sliding window size is therefore five entries. In this example, the FP tail pointer points to a PRN entry corresponding to PRN 3. TABLE 3 indicates the virtual PRN and corresponding floating point PRN allocated to each of the ten floating point instructions, as well as the state of the FP bit for each PRN entry at the time that the FP tail pointer of the sliding window points to PRN entry 3.

[0175] TABLE 4

[0176] In this example, if floating point PRN3 gets stuck in the AMT, instruction 8 can never be issued because it will never enter the sliding window. In other words, the FP bit for the PRN entry’ used by instruction 3 won’t be cleared until PRN3 returns to the freelist, which would trigger an update of the FP tail pointer.

[0177] But by storing the value of PRN3 into the APRF, the system can clear the FP bit for PRN entry’ 3 for instruction 3. This will trigger an update of the FP tail pointer, instruction 8 will enter the sliding window, and the processor can then issue instruction 8 for execution. Subsequent consumers of the logical register to which PRN 3 is allocated will read the data from the APRF rather than from the main physical register file.

[0178] FIG. 17 is a flowchart of an example process for managing virtual PRNs for a freelist that manages multiple different register sets. The process can be performed by a processor configured in accordance with this specification. For convenience, the process will be described as being performed by a system.

[0179] The system maintains a shared freelist for multiple different register sets (1710). As described above, the freelist can allow multiple different PRN entries to be allocated for floating point register names by assigning virtual PRNs. The virtual PRNs are more numerous than the actual number of physical floating point registers.

[0180] The system allocates a first virtual PRN from a first PRN entry and designates the first PRN entry7as being ready for execution (1720). The system can then execute the first instruction.

[0181] The system allocates, from the second PRN entry, a second virtual PRN that maps to the same first floating point PRN (1730). The system can still assign the second PRN entry a virtual PRN but can wait to issue the instruction until the first PRN returns to the freelist. In some implementations, the system uses a sliding window and waits to issue the instruction until the second PRN entry reaches the sliding window, at which point the first PRN will have returned to the freelist.

[0182] The system determines that the first PRN has returned to the freelist (1740), and the system designates the second instruction as being ready execution (1750). For example, the system can use the sliding window as a way of determining when previously allocated PRNs have returned to the freelist. Upon the second PRN entry entering the sliding window, the system can issue the corresponding instruction.

[0183] Issuing an instruction having a renamed register can include sending the instruction to a reservation station. Reservation stations that issue floating point instructions can continually check the sliding window, as indicated by the FP tail pointer, to determine whether or not to issue an instruction. The reservation station can 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 that handle floating point instructions. Reservation stations that handle other instructions that do not write to floating point registers can issue their instructions without regard to the status of the sliding window.

[0184] This specification also describes how a system having a hybrid freelist can use the data in the freelist to clock gate regions of the physical register files. Clock gating is a power-saving technique that refers to reducing power usage to a particular region of an electronic device.

[0185] FIG. 18 illustrates clock gating based on a freelist. One benefit of the hybrid freelist described in this specification is that it implicitly includes information regarding which regions of the physical register files are likely to be active and which are likely to be inactive. In particular, the regions between the head and tail pointers are essentially certain to be highly active regions of the corresponding physical register file. The system can leverage this information to intelligently control which regions of the physical register files can be clock gated to save power.

[0186] FIG. 18 illustrates a hybrid freelist 1830 having 512 entries divided into banks of 16 entries each. The freelist 1830 allocates PRNs for a physical register file 1810 having a lower bank 1811 and an upper bank 1812.

[0187] The freelist 1830 has a head pointer 1815 and a tail pointer 1805. Physical registers having names represented by PRN entries that fall between the head and tail pointers 1815 and 1805 are physical registers that are highly likely to be read from and written to as the program executes. Therefore, the system can designate the region of the physical register file 1810 corresponding to PRN entries between the head and tail powers as an active region 1840.

[0188] Other regions of the physical register file can be designated as “low active” or “inactive” if they meet certain criteria. If so, the system can clock gate portions of a register file or portions of subsets of a register file. For example, the register file 1810 is divided into two banks 1811 and 1812. The latter portion of the lower bank 1811 is a low active region, and thus the system can clock gate registers belonging to that portion of the lower bank 1811.

[0189] Alternatively or in addition, the system can clock gate entire banks of the physical register file 1810. For example, if the registers of the upper bank 1812 are a low active region, e.g., because they are outside of the head and tail pointers, the system can clock gate the entire upper bank 1812.

[0190] The system can use any appropriate criteria for determining, from the freelist 1830, that physical registers are in a low active or an inactive state. For example, a row of PRN entries of the freelist 1830 that have all cleared valid bits corresponds to a group of physical registers that are not being used by the program. Therefore, the system can clock gate that region, including reducing the power, clock frequency, voltage, or some combination of these, to that region.

[0191] In some situations, there can be PRN entries outside of the head and tail pointers that nevertheless have data that might be read during the program execution. For example, if a PRN has been architected to the AMT, that physical register’s values might still be read during program execution. However, writing to the PRN is no longer possible due to its architected state.

[0192] Therefore, for regions of the physical register file that are outside the head and tail pointers but which still have one or more PRN entries with valid bits set, the system can also designate these regions as active regions. Alternatively or in addition, the system can perform less aggressive clock gating on these regions, e.g., by setting these regions to a lower-power mode that can still be read from but not written to.

[0193] FIG. 19 is a flowchart of an example for clock gating a physical register file based on a freelist. The process can be performed by a processor configured in accordance with this specification. For convenience, the process will be described as being performed by a system. The system maintains a hybrid freelist for a physical register file partitioned into a plurality of regions (1910). The physical register file can be partitioned into regions that can be individually clock gated, e.g., banks, rows, or any other appropriate partitioning.

[0194] The system determines that a region of the hybrid freelist represents an inactive region of the physical register file (1920). In some implementations, the system only- searches for inactive regions that are outside the head and tail of the freelist, e.g., in front of the head pointer and behind the tail pointer. As described above, regions of the physical register file corresponding to PRN entries between the head and tail pointer are likely to be regions where there are active reads and writes occurring as the program executes.

[0195] The system can identify an active region from the PRN entries by inspecting the valid bits of the PRN entries. PRN entries having cleared valid bits essentially represent physical registers that are not being used. Thus, if the system can identify a contiguous region of PRN entries that all have their valid bits cleared, the system can identify the corresponding region of the physical register file as an inactive region. One important benefit of the hybrid freehst described in this specification is that it tends to group large regions of inactive PRN entries, which can then be used for identifying inactive regions of the physical register file.

[0196] For PRN entries that are outside the head and tail pointers but nevertheless have their valid bits set, the system can designate those regions as still being active because the corresponding physical registers might still be read during program execution.

[0197] The system reduces power to the inactive region of the physical register file (1930). The system can for example, reduce the clock frequency, voltage, or turn off altogether, the inactive region of the physical register file.

[0198] The system can reassess the active and inactive regions of the physical register file at any appropriate time interval or when the head and tail pointers move. For example, if the head pointer moves to a next row of the freelist that corresponds to an inactive region of the physical register file, the system can stop clock gating that region and restore a previous power or clock level because its physical registers will imminently be allocated for program execution. Similarly, when the tail pointer of the freelist moves to a next row; the system can inspect the valid bits of the PRN entries of the previous row to determine if all the valid bits are cleared, in which case the system can clock gate a new region of the physical register file. These techniques allow the system to activate particular regions of the physical register files before the registers are needed for execution, which reduces or eliminates any latency associated with clock gating the physical register files. For example, the system can use the freelist to reactivate inactive regions of the physical register files at instruction issue time or at register renaming time. Either way, the corresponding regions of the physical register file will be up and running by the time the instructions get issued.

[0199] Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more executable programs, i.e., one or more modules of instructions encoded on a tangible non-transitory storage medium for execution by, or to control the operation of, data processing apparatus. The storage medium can 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 them. Alternatively or in addition, the instructions can be encoded on an artificially -generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus.

[0200] The term '‘data processing apparatus’’ refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can also be, or further include, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can optionally include, in addition to hardware, code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0201] A computer program which may also be referred to or described as a program, software, a software application, an app, a module, a software module, a script, or code can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple coordinated files, e.g., files that store one or more modules, sub-programs, or portions of code. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a data communication network.

[0202] The processes and logic flows described in this specification can be performed by special purpose logic circuitry, e.g., an FPGA or an ASIC, or by a combination of special purpose logic circuitry and one or more programmed computers.

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

[0204] In addition to the embodiments described above, the following embodiments are also innovative:

[0205] Embodiment 1 is a method comprising: maintaining a hybrid freelist representing physical registers that are available for register renaming, wherein the hybrid freelist comprises a plurality of entries having an order, each entry comprising a pair of bits for each physical register of a plurality' of physical registers, wherein the pair of bits for each entry comprises a valid bit and a commit bit representing a valid state and a commit state respectively for a physical register, wherein the valid state represents whether the physical register is free to be allocated for a logical register name, and wherein the commit state represents whether an instruction using the physical register has been committed; and using a head pointer and a tail pointer of the freelist to perform in-order allocation of free physical register names from the plurality7of entries of the freelist.

[0206] Embodiment 2 is the method of embodiment 1, further comprising: using the head pointer to find an entry having a free state. Embodiment is 3 the method of embodiment 2, wherein the entries of the hybrid freelist are arranged in a plurality of banks, and wherein finding an entry having a free state comprises: reading out a bank corresponding to the head pointer; and finding an entry in the bank having a free state.

[0207] Embodiment 4 is the method of embodiment 3, further comprising: populating an output staging buffer based on the valid states of entries in the bank; and allocating physical register names using entries in the output staging buffer.

[0208] Embodiment 5 is the method of embodiment 4, wherein populating the output staging buffer comprises: generating full physical register names from an input staging buffer storing valid bits from entries in the bank.

[0209] Embodiment 6 is the method of embodiment 5, wherein generating the full physical register names comprises expanding each bit in the input staging buffer into a multi-bit physical register name in the output staging buffer.

[0210] Embodiment 7 is the method of any one of embodiments 1-6, further comprising: modifying the valid state of an entry corresponding to a physical register name in response to the physical register name being allocated.

[0211] Embodiment 8 is the method of any one of embodiments 1-7. further comprising: modifying the commit state of an entry corresponding to a physical register when an instruction using the physical register has been committed.

[0212] Embodiment 9 is the method of any one of embodiments 1-8, further comprising: modifying the valid state and the commit state of an entry corresponding to a physical register name allocated to a logical register name when a subsequent instruction writes to the same logical register name.

[0213] Embodiment 10 is the method of any one of embodiments 1-9, further comprising: receiving an indication of a flush at a particular flush point; modifying the valid state of any entries not having a committed state in the hybrid freelist between the flush point and the head pointer.

[0214] Embodiment 11 is the method of embodiment 10, further comprising updating the head pointer of the hybrid freelist based on the flush point.

[0215] Embodiment 12 is the method of embodiment 10, wherein the flush point is based on an oldest allocated PRN that is affected by the flush. Embodiment 13 is the method of embodiment 12, further comprising: storing, in a reorder buffer (ROB), checkpoints for each PRN to LRN mapping; and using a checkpoint in the ROB as the flush point.

[0216] Embodiment 14 is a method for implementing a shared freelist for multiple different register sets, the method comprising: maintaining a shared freelist for multiple different register sets, wherein each register set comprises one or more registers of a particular type, wherein the freelist has a plurality of physical register name (PRN) entries; generating, from a first freelist entry, a first physical register name for a first physical register of a first type for a first instruction referencing a first logical register of the first type; generating, from a second freelist entry, a second physical register name for a second physical register of a second type for a second instruction referencing a second logical register of the second type; retiring the first physical register name to a first architected map table (AMT) for registers of the first type after the first instruction has finished executing; retiring the second physical register name to a second AMT for registers of the second type; and designating the first physical register name as free if the first physical register name is not in the second AMT.

[0217] Embodiment 15 is the method of embodiment 14, further comprising designating the second physical register name as free if the first physical register name is not in the first AMT.

[0218] Embodiment 16 is the method of embodiment 15, wherein designating the second physical register name as free comprises: determining that a PRN entry in the freelist for the second physical register name does not have a commit bit set; and in response, clearing a valid bit for the PRN entry.

[0219] Embodiment 17 is the method of any one of embodiments 14-16, wherein designating the first physical register name as free comprises: determining that the second AMT does not maintain the second physical register name; and in response, clearing a valid bit for a PRN entry for the first physical register name.

[0220] Embodiment 18 is the method of any one of embodiments 14-17, further comprising: generating, from a third hybrid freelist entry, a shared physical register name for a third physical register of the first type and a fourth physical register of the second type for a third instruction that references both a first logical register of the first type and a second logical register of the second type.

[0221] Embodiment 19 is the method of embodiment 18, further comprising returning the shared physical register name to the freelist if and only if the shared physical register name has been evicted from both the first AMT and the second AMT.

[0222] Embodiment 20 is the method of any one of embodiments 14-19, wherein first type is integer registers.

[0223] Embodiment 21 is the method of any one of embodiments 14-20, wherein the second ty pe is flag registers.

[0224] Embodiment 22 is a method comprising: maintaining a shared freelist for multiple different register sets, wherein each register set comprises one or more registers of a particular type, wherein the freelist has a plurality7of physical register name (PRN) entries; allocating, from a first freelist entry, a first physical register name for a first physical register of a first type for a first instruction referencing a first logical register of the 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, reallocating the first physical register name to the second logical register referenced by the second instruction.

[0225] Embodiment 23 is the method of embodiment 22, wherein reallocating the first physical register name to the second logical register comprises allocating the first physical register name to the second logical register while the first physical register name is already allocated to the first logical register.

[0226] Embodiment 24 is the method of any one of embodiments 22-23, wherein reallocating the first physical register name results in the first physical register name being simultaneously allocated to logical registers of different types. Embodiment 25 is the method of any one of embodiments 22-24, wherein determining that the second instruction satisfies the one or more borrowing criteria comprises determining that the first instruction and the second instruction are consecutive instructions.

[0227] Embodiment 26 is the method of any one of embodiments 22-25, wherein determining that the second instruction satisfies the one or more borrowing criteria comprises determining that there are no intervening instructions between the first instruction and the second instruction that require register renaming.

[0228] Embodiment 27 is the method of embodiment 26, wherein determining that the second instruction satisfies the one or more borrowing criteria comprises determining that an intervening instruction does not require logical register writes.

[0229] Embodiment 28 is the method of any one of embodiments 26-27, wherein the intervening instruction is a store instruction.

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

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

[0232] Embodiment 31 is the method of any one of embodiments 22-30, further comprising committing the first instruction and the second instruction on different cycles.

[0233] Embodiment 32 is the method of any one of embodiments 22-31, wherein the first type or the second type is integer registers.

[0234] Embodiment 33 is the method of any one of embodiments 22-32, wherein the first type or the second type is flag registers.

[0235] Embodiment 34 is a method comprising: maintaining a shared freelist for multiple different register sets comprising a first register set and a different second register set, wherein each register set comprises one or more registers of a respective type, wherein the second register set has fewer physical registers than the first register set, and wherein the freelist has a plurality of physical register name (PRN) entries, wherein the freelist associates groups of one or more PRN entries for identifying single registers of the second register set, wherein at least one group of multiple PRN entries identifies a single physical register of the second register set; allocating, from a first PRN entry for a first logical register name of the second type, a first physical register name, 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 the one or more other PRN entries of the group as unavailable for allocation for logical registers of the second ty pe until the first PRN entry becomes available again.

[0236] Embodiment 35 is the method of embodiment 34, further comprising: allocating, from a second PRN entry belonging to the group, a second physical register name for a second logical register name of the first type.

[0237] Embodiment 36 is the method of any one of embodiments 34-35, wherein multiple PRN entries in the group are allocated to different types of physical registers.

[0238] Embodiment 37 is the method of any one of embodiments 34-36, wherein each PRN entry includes a second register type bit to indicate whether any PRN entries in a group of associated PRN entries have been allocated to a logical register of the second type.

[0239] Embodiment 38 is the method of embodiment 37, wherein designating the one or more other PRN entries of the group as unavailable comprises setting each respective second register type bit for the first PRN entry and the one or more other PRN entries in the group.

[0240] Embodiment 39 is the method of any one of embodiments 34-38, wherein the groups of PRN entries are pairs of PRN entries that are N / 2 entries apart for a freelist having N PRN entries.

[0241] Embodiment 40 is the method of any one of embodiments 34-39, wherein the second register set has half as many physical registers as the first register set.

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

[0243] Embodiment 42 is the method of embodiment 41, wherein the shared freelist is configured to maintain PRN entries for integer registers, flag registers, and floating point registers.

[0244] Embodiment 43 is a method comprising: maintaining a shared freelist for multiple different register sets comprising a first register set and a different second register set, wherein each register set comprises one or more registers of a respective type, wherein the second register set has fewer physical registers than the first register set, and wherein the freelist has a plurality of physical register name (PRN) entries, wherein the freelist maintains multiple PRN entries that identify a single register of the second register set; allocating, from a first PRN entry’ for a first logical register name of the second type in a first instruction, a first virtual PRN; allocating, from the second PRN entry for a second logical register name of the second fype in a second instruction, a second virtual PRN that maps to the first physical register name; executing the first instruction using the first physical register name; and issuing the second instruction for execution using the first physical register name only after the first virtual PRN returns to the freelist.

[0245] Embodiment 44 is the method of embodiment 43, further comprising determining that the first virtual PRN has returned to the freelist comprises determining that a valid bit in the first PRN entry has been cleared.

[0246] Embodiment 45 is the method of any one of embodiments 43-44, further comprising: maintaining a sliding window of PRN entries of the second ty pe that are ready to be issued for execution, wherein issuing the second instruction comprises issuing the second instruction only after the second PRN entry enters the sliding window.

[0247] Embodiment 46 is the method of embodiment 45, further comprising: maintaining a floating point tail pointer (FP tail pointer) that indicates the oldest allocated PRN entry of the second type that is allocated to a physical register in a main physical register set of the second type, and wherein the sliding window is defined by a predetermined number of PRN entries after the FP tail pointer.

[0248] Embodiment 47 is the method of embodiment 46, further comprising: determining that an associated PRN entry for a PRN entry indicated by the FP tail pointer is free for renaming; and in response, updating the FP tail pointer.

[0249] Embodiment 48 is the method of embodiment 47, further comprising: clearing a floating point bit for the PRN entry indicated by the FP tail pointer..

[0250] Embodiment 49 is the method of embodiment 45, wherein the sliding window size is based on a number of registers in the second register set. Embodiment 50 is the method of embodiment 45, further comprising: determining that a PRN allocated for a third logical register name from a third PRN entry to a third physical register of the second type is stuck in an architected map table (AMT); in response, moving data from the third physical register into an architected floating point physical register file; and clearing an FP bit for a fourth PRN entry that maps to the same PRN stuck in the AMT.

[0251] Embodiment 51 is the method of embodiment 50, wherein determining that the PRN is stuck in the AMT comprises: determining that the FP tail pointer points to the third PRN entry while the PRN has not been evicted from the AMT.

[0252] Embodiment 52 is the method of embodiment 50, further comprising: executing an instruction that reads from the third logical register name; and reading the value from the architected floating point physical register file instead of from a main floating point physical register file.

[0253] Embodiment 53 is the method of any one of embodiments 43-52, further comprising: issuing an instruction having a renamed register to a reservation station for execution; continually checking whether a PRN entry used for the instruction is within the sliding window; and executing the instruction after the PRN entry enters the sliding window.

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

[0255] Embodiment 55 is the method of embodiment 54, wherein the shared freelist is configured to maintain PRN entries for integer registers, flag registers, and floating point registers.

[0256] Embodiment 56 is a method comprising: maintaining, in a processor, a freelist that tracks the availability of physical registers of a physical register file, wherein 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, clock gating one or more physical registers in the physical register file corresponding to the inactive region of the freelist.

[0257] Embodiment 57 is the method of embodiment 56, wherein each freelist entry of the freelist has a valid bit indicating whether or not a corresponding physical register is being used, and wherein determining that the region of the freelist is an inactive region comprises determining that all valid bits of freelist entries in the region indicate that the corresponding physical register is not in use.

[0258] Embodiment 58 is the method of any one of embodiments 56-58, further comprising: determining that a region of the freelist is between a head pointer and a tail pointer of the freelist; and in response, designating the region as an active region.

[0259] Embodiment 59 is the method of any one of embodiments 56-58, wherein the physical register file comprises a plurality of banks, and wherein determining that the region of the freelist is an inactive region comprises determining that all physical registers in a bank corresponding to the region of the freelist are not used.

[0260] Embodiment 60 is the method of embodiment 59, wherein clock gating the one or more physical registers comprises clock gating the bank corresponding to the region of the freelist while maintaining normal clock operation for one or more other banks of the physical register file.

[0261] Embodiment 1 is the method of any one of embodiments 56-60, wherein clock gating the one or more physical registers occurs before the one or more physical registers have been assigned to an instruction.

[0262] Embodiment 62 is the method of any one of embodiments 56-61, further comprising activating the one or more physical registers during an instruction issue stage that uses a physical register of the one or more physical registers.

[0263] Embodiment 63 is the method of any one of embodiments 56-62, further comprising resuming normal clock operation of the physical register during a register renaming process using the freelist.

[0264] Embodiment 64 is a processor comprising logic circuitry configured to perform the method of any one of embodiments 1-63.

[0265] Embodiment 64 is data processing apparatus configured to perform the method of anyone of embodiments 1-63. While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially be claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0266] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of 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 in a single software product or packaged into multiple software products.

[0267] Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain cases, multitasking and parallel processing may be advantageous.

[0268] What is claimed is:

Claims

CLAIMS1. A method for implementing a shared freelist for multiple different register sets, the method comprising: maintaining a shared freelist for multiple different register sets, wherein each register set comprises one or more registers of a particular type, wherein the freelist has a plurality of physical register name (PRN) entries; generating, from a first freelist entry, a first physical register name for a first physical register of a first type for a first instruction referencing a first logical register of the first t pe: generating, from a second freelist entry, a second physical register name for a second physical register of a second type for a second instruction referencing a second logical register of the second type; retiring the first physical register name to a first architected map table (AMT) for registers of the first type after the first instruction has finished executing; retiring the second physical register name to a second AMT for registers of the second type; and designating the first physical register name as free if the first physical register name is not in the second AMT.

2. The method of claim 1. further comprising designating the second physical register name as free if the first physical register name is not in the first AMT.

3. The method of claim 2, wherein designating the second physical register name as free comprises: determining that a PRN entry in the freelist for the second physical register name does not have a commit bit set; and in response, clearing a valid bit for the PRN entry.

4. The method of any one of claims 1-3, wherein designating the first physical register name as free comprises: determining that the second AMT does not maintain the second physical register name; andin response, clearing a valid bit for a PRN entry for the first physical register name.

5. The method of any one of claims 1-4, further comprising: generating, from a third hybrid freelist entry, a shared physical register name for a third physical register of the first type and a fourth physical register of the second type for a third instruction that references both a first logical register of the first t pe and a second logical register of the second type.

6. The method of claim 5, further comprising returning the shared physical register name to the freelist if and only if the shared physical register name has been evicted from both the first AMT and the second AMT.

7. The method of any one of claims 1-6, wherein first type is integer registers.

8. The method of any one of claims 1-7, wherein the second type is flag registers.

9. A processor comprising logic circuitry' configured to perform operations comprising: maintaining a shared freelist for multiple different register sets, wherein each register set comprises one or more registers of a particular type, wherein the freelist has a plurality7of physical register name (PRN) entries; generating, from a first freelist entry, a first physical register name for a first physical register of a first type for a first instruction referencing a first logical register of the first type; generating, from a second freelist entry, a second physical register name for a second physical register of a second type for a second instruction referencing a second logical register of the second type; retiring the first physical register name to a first architected map table (AMT) for registers of the first type after the first instruction has finished executing; retiring the second physical register name to a second AMT for registers of the second type; and designating the first physical register name as free if the first physical register name is not in the second AMT.

10. The processor of claim 9, wherein the operations further comprise designating the second physical register name as free if the first physical register name is not in the first AMT.

11. The processor of claim 10, wherein designating the second physical register name as free comprises: determining that a PRN entry in the freelist for the second physical register name does not have a commit bit set; and in response, clearing a valid bit for the PRN entry.

12. The processor of any one of claims 9-11, wherein designating the first physical register name as free comprises: determining that the second AMT does not maintain the second physical register name; and in response, clearing a valid bit for a PRN entry for the first physical register name.

13. The processor of any one of claims 9-12, wherein the operations further comprise: generating, from a third hybrid freelist entry, a shared physical register name for a third physical register of the first type and a fourth physical register of the second type for a third instruction that references both a first logical register of the first type and a second logical register of the second type.

14. The processor of claim 13, wherein the operations further comprise returning the shared physical register name to the freelist if and only if the shared physical register name has been evicted from both the first AMT and the second AMT.

15. The processor of any one of claims 9-14, wherein first type is integer registers.

16. The processor of any one of claims 9-15, wherein the second type is flag registers.

Images