Patent Application
20150121040
The invention relates generally to electronic circuits, and more particularly, to microprocessors and methods of microprocessing.
Many computer systems include hardware designed to carry out operations on floating point numbers. Such hardware may be referred to as a floating point unit, and may be integrated with a central processing unit. A floating point unit (FPU) may be used for executing floating point instructions, and floating point instructions may reference a set of floating point architectural registers.
Some instruction set architectures (ISAs), such as ARM v7, may organize floating point architectural registers so that they are densely packed. For example, the architectural registers may be organized in such a way that a single bit space can be referenced as a single quad precision (Q) register, two double precision (D) registers, or four single precision (S) registers.
In some applications it may be desirable to use register renaming for floating point instructions to map the architectural register operands of such instructions to physical registers. A register renamer may be implemented for this purpose. Register renaming may be used to deserialize execution of the floating point instructions. By mapping the same architectural register referenced by two instructions (where there is a false dependency) to different physical registers (i.e. by “renaming” the architectural registers referenced by the instructions), execution of instructions that would otherwise encounter a hazard by referencing the same architectural register may be executed simultaneously or out of order, for example.
Some embodiments provide a method for accessing packed registers. A state of the packed registers is stored. It is determined whether the register is directly accessible based on the state, on a condition that an instruction accesses a register of the packed registers. An action is performed which allows the register to be accessed directly on a condition that the register is not directly accessible.
Some embodiments provide a device configured to access packed registers. Circuitry stores a state of the packed registers. Circuitry determines based on the state whether the register is directly accessible, on a condition that an instruction accesses a register of the packed registers. Circuitry performs an action which allows the register to be accessed directly on a condition that the register is not directly accessible.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
The processor 102 may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, wherein each processor core may be a CPU or a GPU. The memory 104 may be located on the same die as the processor 102, or may be located separately from the processor 102. The memory 104 may include a volatile or non-volatile memory, for example, random access memory (RAM), dynamic RAM, or a cache. It is noted that memory 104 may be implemented as one or more discrete units and that device 100 may include multiple distinct memories (not shown). For example, device 100 may include both CPU and GPU memories (not shown) as further discussed herein.
The storage device 106 may include a fixed or removable storage, for example, a hard disk drive, a solid state drive, an optical disk, or a flash drive. The input devices 108 may include a keyboard, a keypad, a touch screen, a touch pad, a detector, a microphone, an accelerometer, a gyroscope, a biometric scanner, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals). The output devices 110 may include a display, a speaker, a printer, a haptic feedback device, one or more lights, an antenna, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals).
The input driver 112 communicates with the processor 102 and the input devices 108, and permits the processor 102 to receive input from the input devices 108. The output driver 114 communicates with the processor 102 and the output devices 110, and permits the processor 102 to send output to the output devices 110. It is noted that the input driver 112 and the output driver 114 are optional components, and that the device 100 will operate in the same manner if the input driver 112 and the output driver 114 are not present.
For the sake of brevity, conventional techniques related to integrated circuit design, caching, memory operations, memory controllers, and other functional aspects of the systems (and the individual operating components of the systems) have not been described in detail herein. Furthermore, the connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and/or physical couplings between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in an embodiment of the subject matter. In addition, certain terminology may also be used in the following description for the purpose of reference only, and thus are not intended to be limiting, and the terms “first”, “second” and other such numerical terms referring to structures do not imply a sequence or order unless clearly indicated by the context.
The following description refers to elements or nodes or features being “connected” or “coupled” together. As used herein, unless expressly stated otherwise, “connected” means that one element/node/feature is directly joined to (or directly communicates with) another element/node/feature, and not necessarily mechanically. Likewise, unless expressly stated otherwise, “coupled” means that one element/node/feature is directly or indirectly joined to (or directly or indirectly communicates with) another element/node/feature, and not necessarily mechanically. Thus, although the figures may depict one exemplary arrangement of elements, additional intervening elements, devices, features, or components may be present in an embodiment of the depicted subject matter.
While at least one exemplary embodiment has been presented in the following description, it should be appreciated that a vast number of variations exist. It will also be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a guide for implementing the described embodiment or embodiments. It will be understood that various changes may be made in the function and arrangement of elements without departing from the scope defined by the claims.
Storing densely packed architectural registers such as those illustrated with respect to
To address such issues, a register state may be stored for all registers packed within the full width architectural register (i.e., the quad) which reflects whether the quad has been stored as a fully packed register (i.e., within a single physical register and in order) or whether it has been broken up into two registers (D or 64 bit registers in the example of
When an instruction attempts to access a full width architectural register or one of the architectural registers packed within it, the state may be checked to determine whether the desired register can be accessed directly from a single physical register, whether the data must first be reassembled from different physical registers, or whether the data within the physical registers must be reorganized, for example by writing a part of the data stored within a physical register to a new physical register in a different bit position. For example, if an instruction attempts to read a full width architectural register or one of the architectural registers packed within it, the state may be checked to determine whether the desired register can be read directly from a single physical register, whether the data must first be reassembled from different physical registers, or whether the data within the physical registers must be reorganized, for example by writing a part of the data stored within a physical register to a new physical register in a different bit position. The state may also be checked for other types of accesses, for example writes, etc.
In a processor architecture where it is desired to independently read and write densely packed registers, writing a smaller register after a larger corresponding packed register is written may only invalidate part of the data stored for the larger packed register. It may thus be necessary to preserve the rest of the data. For example, if Q0 is written and subsequently S0 is written (mapped to a new physical register name (PRN) corresponding to a new physical register), the data for S1, S2, and S3 within the physical register storing Q0 is still valid and must be preserved, i.e., not discarded by overwriting the entire physical register storing Q0. By storing a state of the quad register Q0 which reflects how the packed registers are stored physically, it remains possible to access each of the packed registers. In this example, some of the packed registers may be directly accessed from the physical registers and some may require the bits stored within the physical registers be reorganized, possibly by moving them into a new physical register as further discussed herein.
To facilitate renaming, a logical register name (LRN) may be assigned to each architectural register. A mapping may then be stored between the LRN and the PRN of the physical register within which it is written. A table containing mappings between the LRNs and the PRNs may be referred to as a register map.
A new physical register may be allocated for an architectural register each time it is written (to facilitate renaming, for example.) That physical register may later be “retired” and returned to a “free list” (i.e., may be made unavailable for reading and can be used for mapping to a new architectural register) when the data is no longer valid.
Table 1 describes example problems which may arise if a given architectural register of a given size is read or written by an instruction after a different architectural register aliased or “packed” with the quad has previously been written. Table 1 is described with respect to the architectural registers packed with Q0 of
As discussed above, to address such issues, a register state of each quad may be stored. To track the state, each quad may correspond to multiple LRNs, which are each independently mappable to the physical registers. Each of the independently mappable LRNs may represent one or more of the packed architectural registers. In the example of
The first LRN may represent either a full Q register, the lower D register (which is aligned with the Q register), or the lowest S register (which is aligned with the Q register and the lower D register). In the example of
An example set of LRNs for example architectural registers Q0-Q3 of
Each LRN may be mapped to a PRN independently. An example register map illustrating a possible mapping of the LRNs to PRNs is shown below in Table 3:
A state of the LRN-PRN mapping must be tracked to handle the aliasing issues discussed above, because it may not otherwise be certain that data read by accessing a given LRN will be valid. The state for each LRN-PRN mapping may be tracked per-quad (i.e., the state may pertain to all of the LRNs that are aliased or packed together.) The quad may be referred to by the name of the Q register within which the other registers are packed. For example, a state for Q0 may track the state of the LRN-PRN mapping between LRNs Q0/D0/S0, S1, D1/S2, and S3 and the PRNs. Thus, if Q0 is in a state D0/D1 for example (discussed further herein), the state may denote that any read from or write to architectural registers Q0, D0, D1, S0, S1, S2, or S3 will need to take account of this state during decoding, because the state pertains to all of the LRNs for these architectural registers. Table 4 illustrates eight example register states for LRN-PRN mapping.
To keep track of the state of the mappings, bits may be stored for each quad. These bits may be tracked and/or stored by a decoder unit (DE) or any other suitable unit of the processor. For example, three bits may be stored and tracked by a unit within a DE for each quad to track eight states. In an example using eight states, the state may be tracked using the example bit encoding described in Table 5.
It is noted that the states described in Tables 4 and 5 are exemplary. For example, the Quad, D0/D1, and S0/S1/S2/S3 states may be essential for dealing with aliasing issues. However, the other states, i.e., Q/D1, D0/D1U, D0/S2/S3, and S0/S1/D1 may be used for performance optimization purposes (e.g., fewer manipulations of the data in the physical registers may be required if these additional states are tracked). It is noted and will be understood that the scheme could be further extended for any number of optimizations, for example, by increasing the number of states or by using different states. Such additional or different states may include Q0/D1/S3, Q0/S3, Q0/S1, D0/S1/D1, D0/S1/S2/S3, D0/S1/S2/S3, D0/S1/D1/S3, S0/S1U/D1, D0/S2/S3U, S0/S1U/S2/S3, S0/S1/S2/S3U, S0/S1U/S2/S3U, and so forth, as are derivable from the principles discussed herein.
If it is determined that data stored the physical registers must be manipulated to maintain the validity of the data when executing an instruction (based on the LRN-PRN mapping state and the type and size of access to the aliasing registers), the data within the physical registers may be manipulated (e.g., moved from part of a physical register to part of a different physical register) by injecting additional “fixup” micro operations (uops) into the uop stream or buffer ahead of the decoded uops for the instruction. The fixup uops may be determined and/or injected by the DE or any other suitable structure of the processor. In some cases, it may also or alternatively be necessary to change the state of the mapping to validly read or write an architectural register as will be further discussed herein.
Fixup uops may be injected into or ahead of the uops for an instruction to pack and/or unpack the registers into various configurations. These uops or combinations thereof may include one or more of the example fixup uops described in Table 6. It is noted that the names for these uops are arbitrary. It is also noted that the physical register bits are described with respect to a 128 bit quad, however other bit widths may be used change-for-change as appropriate for other architectures.
To determine whether it is necessary to inject one or more of these fixup uops and/or to change the state of a quad, a suitable part of the processor detects any aliasing among the operand architectural registers of an instruction and among any other instructions being renamed (i.e., whether they share a quad), checks the state for any such registers, determines which if any uops must be injected for the instruction to validly read or write such register based on the state, and determines to which if any state the register state must be changed. These determinations may be made by a decode unit or aliasing logic which receives information about the operand registers of the decoded instruction from the decode unit for example, although it is noted that these determinations may be made by any suitable structure.
Tables 7-13 illustrate example state transitions and uop injections which may be necessary for reads or writes to an architectural register based upon the current state of the quad (i.e., the state of the LRN-PRN mapping for the quad within which the architectural register is packed). The state names are denoted with respect to Q0, but are relevant to any of the packed architectural registers Q0-Q15 change for change as will be further illustrated herein.
To track the state for each quad, a register state table may be maintained. Table 14 illustrates a register state table reflecting an example state of the registers packed with architectural registers Q0-Q3,
Extraction logic 305 receives a stream of instructions, extracts N instructions from the stream (floating point instructions in this example), and loads the instructions into N decode units. Three decode units 310, 315, 320 are shown, however it is noted that the number of decode units and extracted instructions can be greater or less as desired.
The extraction logic 305 may receive the stream of instructions from an instruction fetch unit (not shown) or from any other suitable source. The extraction logic 305 may then load the extracted instructions into decode units 310, 315, 320. Although only three decode units are shown for decoding three extracted instructions, in principle an arbitrary number of decode units may be used for decoding an arbitrary number of extracted instructions.
Decode unit 310 decodes the instruction INST1 into one or more uops for execution and loads the decoded uops into uop buffer 330. It is noted that in some implementations (not shown) uop buffer 330 may be omitted, and the uops may simply be dispatched downstream to execution unit 335. Decode unit 310 also transmits information about the operand registers of INST1 to logic 325. Decode unit 315 decodes the instruction INST2 into one or more uops for execution and loads the decoded uops into uop buffer 330. Decode unit 315 also transmits information about the operand registers of INST2 to logic 325. Decode unit 320 decodes the instruction INST3 into one or more uops for execution and loads the decoded uops into uop buffer 330. Decode unit 320 also transmits information about the operand registers of INST3 to logic 325. It is noted that decode units 315, 320, 325 may decode the three instructions concurrently; however the instructions may be decoded non-concurrently in other implementations.
Logic 325 checks the state of the LRN-PRN mapping for each operand register of INST1 to determine if it is valid. If the state mapping is invalid, logic 325 determines whether uops must be injected and determines whether a state change is required. If uop injection is necessary, logic 325 injects the appropriate fixup uops ahead of the decoded uops for INST1 in the uop buffer 330. As discussed above, it is noted that in some implementations (not shown) uop buffer 330 may be omitted, and the uops may simply be injected ahead of the decoded uops for INST1 and dispatched downstream to execution unit 335. If a state change is required, logic 325 updates the state of the mapping for the quad. Logic 325 also performs these same tasks for INST2 and INST3.
After all decoded ops for INST1, INST2, and INST3 have been loaded into buffer 330, any required fixup ops are injected, and state has been updated as required, the queue of uops in uop buffer 330 may be dispatched to one or more execution units 335 for execution. As mentioned above, in implementations which do not use a uop buffer (not shown) the uops may already have been dispatched downstream to execution unit 335.
In step 405 it is determined whether any instructions are available to decode. If instructions are available to decode, they are decoded into uops in step 410. The determination may be made by decode units and the uops may be buffered such as is discussed with respect to
In step 415, it is determined whether any of the operand registers of the instructions have yet to be checked for valid LRN-PRN state mapping. If so, the state each register is checked in step 420. These determinations may be made by aliasing logic which receives information regarding the operand registers such as is discussed with respect to
It is noted that in some implementations (not shown) the validity of LRN-PRN state mapping may be checked before or concurrently with decoding of uops.
If the register state is determined not to be valid, it is determined whether it is necessary to inject fixup uops in step 425. This determination may be made by the aliasing logic. If it is necessary to inject fixup uops, they are injected in step 430. The fixup uops may be injected into a uop queue ahead of the decoded uops for the instruction and may be buffered such as is discussed with respect to
Whether or not it is determined to inject uops in step 425, it is also determined whether it is necessary to change the state of the LRN-PRN mapping in step 435. If so, the mapping is updated in step 440. In either event, the flow returns to step 415.
If there are no further registers to check for valid state, the decoded and injected uops may be dispatched for execution in step 445.
The following example parallel decoding of three floating point instructions is illustrative of the principles discussed herein, and may be carried out using the structures and methods discussed with respect to
The initial LRN-PRN mapping (i.e., the register map) is shown by Table 16.
The initial contents of the physical register file (PRF) are shown by Table 17.
The three example floating point instructions to be decoded in this example are:
In this example, the instructions are decoded in parallel by decode units 310, 315, 320 as shown in
Decode unit 310 decodes INST1 and passes the uops for INST1 downstream into buffer 330 for later execution. Decode unit 310 also transmits information to logic 325 indicating that its operands are registers Q0, Q1, and Q2. Logic 325 detects that the architectural registers Q0, Q1, and Q2 are not aliased with one another. Accordingly, no uops are required to be injected ahead of the uops for INST1 and the register states do not need to be changed.
Decode unit 315 decodes INST2 and passes the uops for INST2 downstream into buffer 330 for later execution behind the uops for INST1. Decode unit 315 also transmits information to logic 325 indicating that its operands are registers D0, D1, and D2.
Logic 325 detects that register D2 is aliased with Q1, which is in state Q. Logic 325 also detects register aliasing of the read of D1 and write of D0 with Q0, which is in state Q.
D2 is readable from Q1 in state Q. This is because D2 is the lower double of Q1, and is valid for reading when Q1 is in state Q. Accordingly, logic 325 does not inject any uops ahead of the uops for INST2 and does not change the register states for this aliasing.
D1 is not valid for reading when Q0 is in state Q. Accordingly; the read of D1 requires injection of fkregq2d D1, Q0 and state transition of Q0 from Q to Q0/D1. Accordingly, logic 325 injects this uop ahead of the uops for INST2 in the queue and updates the state bits for Q0 to reflect state Q0/D1. This is done because D1 is the upper double, and is not aligned with the LSB of the physical registers when Q0 is in state Q.
The injected uop fkregq2d D1, Q0 will take the upper double of the physical register storing Q0 (i.e., the upper 64 bits—the data for D1) and write this data to the lower double of a new physical register. D1 will be mapped to this new physical register after this uop is executed, and the data for D1 will be aligned with the LSB of the physical register and thus may be validly read. It is noted that this uop will not return the PRN to the free list, and the original data will remain in the original physical registers.
After this unpacking, the state of Q0 (which represents all architectural registers packed within Q0) will be changed to Q/D1 to indicate that reads that would be valid for the quad state are still valid (i.e., this data remains in the original physical register as before) but that reads of D1 are now also valid, because D1 is mapped to a new physical register.
D0 can be written when Q0 is in state Q/D1 without injecting any uops. However following the write, D0 will be mapped to a new physical register and D1 will remain available for valid reads in the other physical register. Q0 therefore will no longer be directly readable, and thus the state of Q0 must be updated from Q/D1 to D1/D0. Accordingly, logic 325 updates the state bits for Q0 to reflect state D1/D0.
The register state at this point is reflected by Table 18.
Decode unit 320 decodes INST3 and passes the uops for INST3 downstream into buffer 330 for later execution behind the uops for INST2. Decode unit 320 also transmits information to logic 325 indicating that its operands are registers Q3, Q0, and Q1. Logic 325 detects that register Q0 is aliased with D0 and D1.
Q0 is in state D0/D1, and Q0 cannot be directly read in this state. This is because the D0 and D1 registers are mapped to different physical registers. To read Q0, the state must be changed by injecting uops. Accordingly, logic 325 injects two consecutive uops ahead of the uops for INST3. The first uop (fkreclaimprn D1) puts the physical register to which D1 is mapped back on the free list, but leaves it mapped in the register map. This is a preparatory step for the second uop. The second uop (fkregd2q Q0, D0, D1) allocates a new physical register for Q0, writes the lower double from the physical register mapped to D0 to the lower double of the new physical register, and writes the lower double from the physical register mapped to D1 to the upper double of the new register. This “reassembles” the quad in the new register, making it valid for reading Q0. Thus the state for the registers packed into Q0 is then changed to Q. It is noted that in some implementations (not shown) the fkreclaimprn D1 uop could be omitted, and the state could be changed to Q/D1, leaving the PRN for D1 mapped. It is also noted that fkreclaimprn uops may always be executed atomically with a second fixup uop (here fkregd2q) as shown in Table 6 for example.
The register state at this point is reflected by Table 19.
After decoding the instructions, injecting uops, and/or changing the register state as appropriate, the queue of instruction uops is:
Once the instructions have been thus decoded, fixup uops have been injected, and states have been updated as appropriate, the uops may be processed by register map logic of logic 325 as follows.
When a decoded uop or uops for add Q0=Q1+Q2 is/are processed by the register map logic, a new PRN (PRNE) for storing Q0 is mapped to LRNs for architectural registers packed within Q0 (i.e., Q0/D0/S0, S1, D1/S2, and S3). The operation is also transformed using the mapping to Add PRNE=PRNB+PRNC. The state of the register map after this operation is shown by Table 20.
When an injected uop or uops for fkregq2d D1, Q0 is/are processed by the register map logic, a new PRN (PRNF) for storing D1 is mapped to LRNS for architectural registers packed within D1 (i.e., D1/S2 and S3). The operation is also transformed using the mapping to fkregq2d PRNF=PRNE[127:64]. The state of the register map after this operation is shown by Table 21.
When a decoded uop or uops for sub D0=D1−D2 is/are processed by the register map logic, a new PRN (PRNG) for storing D0 is mapped to LRNs for architectural registers packed within D0 (i.e., Q0/D0/S0 and S1). The operation is transformed using the mapping to SUB PRNG=PRNF−PRNC. The state of the register map after this operation is shown by Table 22.
When an injected uop or uops for fkreclaimprn D1 is/are processed by the register map logic, there is no change to the register map, and the operation is transformed using the mapping to fkreclaimprn PRNF.
When an injected uop or uops for fkregd2q Q0, D1 is/are processed by the register map logic, a new PRN (PRNH) for storing Q0 is mapped to LRNs for architectural registers packed within Q0 (i.e., Q0/D0/S0, S1, D1/S2, and S3). The operation is transformed to fkregd2q PRNH[127:0]=PRNF[63:0], PRNG[63:0]. The state of the register map after this operation is shown by Table 23.
When a decoded uop or uops for Mul Q3=Q0×Q1 is/are processed by the register map logic, a new PRN (PRNI) for storing Q3 is mapped to LRNs for architectural registers packed within Q3 (i.e., Q3/D6/S12, S13, D7/S14, S15). The operation is transformed using the mapping to mul PRNI=PRNH×PRNB. The state of the register map after this operation is shown by Table 24.
After all of the uops have been processed by the register map logic, they may be executed by an execution unit 335 (or units), resulting in changes to the PRF file as follows.
a. add PRNE=PRNB+PRNC (from add Q0=Q1+Q2). The PRF state after the corresponding ops are executed is shown by Table 25.
b. fkregq2d PRNF=PRNE[127:64] (from fkregq2d D1, Q0). PRF state after the corresponding ops are executed is shown by Table 26.
c. sub PRNG=PRNF−PRNB (from sub D0=D1−D2). PRF state after the corresponding ops are executed is shown by Table 27.
d. fkreclaimprn PRNF (from fkreclaimprn D1). No change to PRF until fkreclaimprn retires, upon which the register is returned to the free list, however fkreclaimprn must be retired with following uop. Accordingly, the PRF effect will occur after fkregd2q which is atomic with fkreclaimprn.
e. fkregd2q PRNH[127:0]=PRNF[63:0], PRNG[63:0] (fkregd2q Q0, D1). The PRF state after the corresponding ops are executed is shown by Table 28.
f. mul PRNI=PRNH×PRNB (from mul Q3=Q0×Q1). The PRF state after the corresponding ops are executed is shown by Table 29.
In some implementations, the packing of a particular register may be tracked over time to optimize the decoding of instructions. Such tracking may be done in the aliasing and state tracking logic or another suitable part of the processor, and may be used to minimize the need to inject repacking uops. For example, if a stream of instructions includes a small number of instructions which access a particular register in a way that conflicts with the majority use of that register, the processor may change the way it decodes that small number of instructions. More specifically, if the stream of instructions includes a small number of instructions which access a particular packed register using a register size that conflicts with a size by which the register is usually accessed, the processor may change the way those instructions with conflicting sizes are decoded.
Such conflicts may arise as a result of the structure of the ISA. For example, in an ISA which includes only one sized load or store instruction (e.g. 64 bits) other instructions may utilize the results of those loads or stores as a different size (e.g. 128 bits.) Such conflicts may also arise due to a particular coding style which results in a similar behavior. For example, a particular program may load or store data in one size or a set of sizes and operate on the stored data as a different size or set of sizes, even where the ISA is not constrained in this way.
To address such cases, a history of the packing of the registers may be tracked. In some implementations, one or more counters may be maintained for each register in order to track the size of accesses. A saturating counter may be used for such purposes. For example, a saturating counter may be maintained for accesses to Q0 for example, where such counter is incremented for each quad-sized access and decremented for each double-sized access. A threshold point may be determined, whereupon the processor will either inject 2 64 bit loads uops or 1 128-bit load uop depending upon whether Q0 is more frequently accessed as a quad or as a double. It is noted that other history tracking strategies are possible.
For example, a history of fixup uop injections may also or alternatively be tracked, and the processor may use this historical information to detect situations where decoding an instruction differently could yield better performance. In some implementations, the address of the instruction that is being decoded could be analyzed using a hashing algorithm and such histories could be stored in memory for each register. To illustrate, if Q0 (e.g. 128 bits) is first loaded in two halves (e.g. first loading D0 and then loading D1) and is later accessed as a quad register (e.g. 128 bits), uops may be injected to first unpack Q0 prior to loading, and a uop may also be injected to repack Q0 prior to access. However if a particular stream of instructions primarily accesses Q0 as a quad register (e.g. 128 bits) and primarily loads the register in two halves (e.g. first loading D0 then loading D1), the processor may detect this by tracking the injection of uops for the instruction stream over time. Once this behavior is detected (e.g. using a history, saturating counter, or statistically for example as described above), instead of sending uops to perform 2 64 bit loads to the consecutive D registers, the processor may issue only 1 128-bit load uop to the full quad register, eliminating the need to unpack Q0 before loading and to repack Q0 after loading prior to use. Such detection may have the advantage of improving performance by reducing the net number of uops required for loading and storing. Various other permutations of this tracking will be evident to those having skill in the art.
The following example optimizations may be performed as a function of register mapping. As discussed above, there may be only one fixed supported load size in some architectures. For example, the only supported load size for an example vector load instruction VLD* may be 64 bits. In this case, any instruction which performs 128-bit arithmetic would necessarily use data which was previously loaded in two 64-bit chunks.
In this case, the current mapping of the destination register along with the length of the load and the starting destination register number may be used by the processor to determine whether to load the data as a double or a quad. If the instruction loads an even number of registers, the first register is an even register number, and the current map shows that the destinations were previously used as quads, the data may be loaded as quads. If the instruction loads an odd number of registers, starts with an odd numbered register, or the current mapping shows the previous use of the register was not a quad, the data may be loaded as doubles.
Similar optimizations may be applicable to store instructions. It may be possible to store a source as doubles or quads depending on the current mapping, whether an even or odd number of registers is stored, and whether the store begins with an even or odd register.
In general, instructions which lengthen the data (i.e., write to an architectural register that is longer than one or more of the source registers) may be susceptible to such optimization. An example of such instruction may have one or both of the sources specified as double registers, and the destination specified as a quad register. Because of the way these instructions are decoded into uops, it may be possible to execute such instructions without unpacking the sources if they are currently packed as quads and if the decoder can transform the uops in the sequence.
For example, an instruction VADDL.S8<Qd>, <Dn>, <Dm> may be broken down into two shuffle uops which lengthen the data in Dn and Dm and a third uop to perform the add. A shuffle uop may lengthen a register of an instruction, for example from either the upper or lower bits (64 bits). In a specific example, fkpmovsxbw <destination> <source> may be used to lengthen data packed in bits 63:0 of the source, while fkpmovsxbwh <destination> <source> may be used to lengthen data packed in bits 127:64 of the source. For example, in a case where the instruction source is an odd D register which is currently packed as bits 127:64 a quad, the fkpmovsxbwh uop can be used instead of the fkpmovsxbw, and the register may not need to be unpacked with injected uops. If the first two shuffle ops are transformed based upon whether the register is odd or even and whether the register is packed as a quad or double, the uops may be as follows (assuming the registers are not packed as singles):
The same is true for widening instructions where only one of the sources is a double, but the other is a quad and the destination is a quad. In this case, the op transformation mentioned above may be performed for the source double.
Although various embodiments have been described with respect to a floating point unit and floating point registers, it is noted that these concepts may also be applied to other processing units and packed registers where aliasing effects may occur. For example, the concepts described herein may apply where an ISA organizes registers other than floating point registers in a densely packed configuration similar to that illustrated in
The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a non-transitory computer-readable storage medium for execution by a general purpose computer or a processor. Examples of non-transitory computer-readable storage media include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
This application claims the benefit of U.S. Provisional Patent Application No. 61/896,091 filed Oct. 27, 2013, the contents of which are hereby incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 61896091 | Oct 2013 | US |
