BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 schematically shows a data store 10 for storing a renaming table and a further data store for storing a condition block;
FIG. 2 shows an example stream of instructions and corresponding stored values for the renaming table and further data store of FIG. 1;
FIG. 3 shows a different example to FIG. 2; and
FIG. 4 shows a portion of a data processing apparatus according to an embodiment of the present invention; and
FIG. 5 shows a flow diagram indicating the steps performed by a method according to an embodiment of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
FIG. 1 shows a data store 10 for storing a renaming table and a further data store 20 for storing a condition block relating to remapping data for unresolved condition codes. Renaming table 10 receives a stream of decoded instructions in which the registers are referenced in architectural form. In other words they are referred to as they are in the instruction set and thus there are, for example, 32 registers referred to. Renaming table remaps the architectural registers referred to by the instruction set into physical registers that are actually present on the processor core. Owing to the optimisation processes performed by many processors and also owing to there often being multiple cores within a processor, it is becoming increasingly common to execute instructions out of order. Furthermore, the remapping occurs early in the pipeline, and thus, there may be an instruction arriving at the renaming table with a condition code that has not yet had its condition resolved. In order to address this problem, any register whose stored value is modified by this instruction is in effect remapped or renamed twice. Thus, a mapping for each possible outcome of the condition is given. An example of this is given in FIG. 2. Additional renaming values are stored in a supplementary data store 20. The information stored in this supplementary data store comprises the architectural register, the physical register and the condition code. In effect two parallel worlds are created and as long as subsequent instructions utilising these condition codes or their opposites use the same world up until the point that the condition code is resolved, then the processor can process the instructions correctly without the need to stall and wait for the condition code to be resolved.
FIG. 2 shows an example instruction stream 40 and the values stored in the renaming table in data store 10 and in the supplementary buffer 20 for each value. The circling of the particular table shows which is used in preference for each instruction.
In FIG. 2, a compare instruction is present in the instruction stream and if this is performed after instructions that are dependent on the relative values of the two items being compared then an unresolved condition code scenario is initiated. The first decoded instruction having an unresolved condition code to reach renaming logic in this example is the instruction move the value one to register R0 if the comparison is equal. Renaming table 10 has register R0 remapped to physical register V3 stored in it at this time. In this implementation, this is left as it is and supplemental data store 20 is populated with a line which indicates that R0 is mapped to physical register V4 for the condition being fulfilled, i.e. the comparison is equal. In the Figure this table is circled as it is this table that is updated by the renaming logic.
A subsequent instruction is conditional upon the opposite of the condition code i.e. the two items not being equal. This instruction produces register R0, i.e. it is the value in register R0 that is modified and the value 2 is stored in this register. Thus, this register needs to be remapped and the renaming logic decides that it should be remapped to physical register V5. As this instruction is in effect operating in the not equal world then it is the renaming table 10 where this value is stored. Thus, as can be seen in the figure renaming 10 is updated so that R0 maps to V5 and it is this remapping information that is updated and thus it is this which is circled.
The following instruction is move the value of register R0 to register R1 if the comparison is equal. Thus, it is register R1 which has its value modified in this case and thus, this needs a new remapping. The renaming logic decides to remap register R1 to V7. As we are operating here in “equal world” this information is written into buffer 20 and thus, this table is circled in the Figure.
Renaming logic then receives a signal from the processor that indicates that the comparison has been resolved and that in fact the comparison was equal. At this point, the renaming table 10 is overwritten with the values from the supplementary buffer 20 as supplementary buffer 20 relates to “equal world”, which it is resolved to be and the supplementary buffer 20 can then be flushed of any values stored in it relating to the EQ condition.
FIG. 3 shows an alternative example. In this example as in the previous one supplementary buffer 20 is chosen to be “equal world” whereas the renaming table is chosen to be not equal world. This is clearly an implementation detail and it could be done the other way around. It is most advantageous to use a renaming table for the world that has the most unresolved conditional code instructions. This is because the renaming table has a fixed size, whereas the size required for the supplementary buffer depends on the number of unresolved conditional code instructions in that world. Clearly it is advantageous to have a small additional buffer 20 and thus this selection is preferable. In some embodiments, selection is made in hardware and cannot be altered, whereas in others the renaming logic has an algorithm which can select according to instructions to be processed.
In the example shown, the first instruction moves the value of register R1 to register R0 if the comparison is equal. Thus, register R0 has a new value stored in it and therefore needs to be renamed or remapped. In this example it is remapped to physical register V4 and this is stored in supplementary table 20.
The next instruction is operating in not equal world and stores the value from R3 in register R0. Thus, R0 needs to be allocated and is allocated to physical register V5 and this is stored in the renaming table.
The next instruction is not a conditional code instruction and wants register R0 to be moved to register R1 however, we do not know at this point which of the two conditional instructions is correct and thus we don't know what to do. However, the move instruction is in fact the same as move if a condition code is equal plus move if the condition code is not equal and we know how to perform both of these instructions. Thus, we can produce these duplicate instructions and can perform them both one being performed in equal world and the other in not equal world. Thus, an instruction moving register R0 into register R1 is performed in equal world so register R1 is allocated to physical register V6 and table 20 is used to record this, whereas in non-equal world register R1 is allocated to physical register V7 and the renaming table is used to record this. Thus, if it turns out that the comparison equal was correct renaming table will have V4 and R0 and V6 as R1, whereas if it is determined that they weren't equal the renaming table will have R0 as V5 and R1 as V7 thus, it can be seen that the comparison can be resolved later and still the correct result be attained.
In the examples given, there has only been one condition code shown. However, it should be clear that other condition codes could be considered and these could be written into the tables with an identifier identifying condition codes. This will work as long as the same architectural registers are not specified. If the same architectural registers are specified by two unresolved condition codes then the processor will need to stall until the condition codes are resolved.
FIG. 4 shows a portion of the data processor 90 comprising an instruction decoder 30 which receives a stream of instructions and produces a stream of decoded instructions. These are sent to register renaming logic 40, which comprises register renaming table 10 and supplementary table 20. If the decoded instruction comprises an unresolved condition code, then renaming logic looks to see if this condition code or its opposite is present in supplementary data store 20. If it is then renaming values for the condition being fulfilled will be stored in either data store 20 or renaming table 10 as appropriate. That is to say in the same table as the same condition code result was stored for the other renaming values. If it is not present then renaming logic can select which table to store any register renaming values in for the condition being fulfilled. The decoded instruction is then sent to execution unit 70 for processing. Execution unit 70 stores data values that it is processing in physical registers 80, the actual register used being dependent on renaming logic 40. When a conditional instruction is resolved by execution unit 70, then this information is sent back to renaming logic 40, where it is used to determine whether supplementary table 20 stored the correct renaming results of renaming table 10 did for this condition. If it was supplementary table 20 then the renaming values relating to this condition are written to renaming table 10. If it was renaming table 10, then the values stored in supplementary buffer 20 relating to this condition code are simply flushed.
FIG. 5 shows a flow diagram illustrating steps performed in a method according to an embodiment of the present invention. Initially a decoded instruction is received at renaming logic. Renaming logic then determines whether it has an unresolved condition code relating to it and whether it produces a register. That is whether it modifies a value stored in a register. If it doesn't have both of these things, then the renaming logic deals with it in a standard way and looks at the next decoded instruction in the instruction stream. If it does have an unresolved condition code and it does produce a register then the renaming logic then looks to see if there are any renaming values stored in the supplementary buffer 20 of FIG. 4 that relate either to the condition or the to opposite condition of this unresolved condition code. If there are, then the renaming logic takes this into account when deciding where to store the renaming value. In particular, it stores the renaming values in the same data store as the previous values for the same condition code were stored. Thus, in effect two worlds are created one with a particular condition code fulfilled and the other with it not fulfilled. It should be noted that the world where the condition code is not fulfilled is the same as the world where the opposite condition code is fulfilled.
If there are no renaming values stored in the supplementary buffer relating to this condition or its opposite then the renaming logic stores renaming value for the registers for the condition code being fulfilled in the supplementary buffer along with an indication of the condition code. The renaming logic then looks to see if any conditional instructions have been resolved in execution pipeline 70 of FIG. 4. If they have not then it looks again at the next decoded instruction received. If there is a condition that has been resolved then it looks to see if there are any register renaming values associated with the resolved condition or with its opposite stored in supplementary buffer 20. If not then it returns to the next decoded instruction received. If the opposite condition is present in buffer 2 then this indicates that the renaming values are stored in the renaming table and thus the renaming table is correct. Thus, the only thing that needs to be done is that the renaming values from the supplementary buffer relating to the opposite condition need to be deleted as we now know that this opposite condition is not fulfilled.
If there are some register renaming values associated with the resolved condition stored in the supplementary buffer then we know that the register renaming values for these registers are not correct in the renaming table and these values need to be overwritten with values from the supplementary buffer. They can then be deleted from the supplementary buffer.
This description illustrates what happens in the case of instructions with unresolved condition codes at renaming logic. Clearly other instructions received at renaming logic are dealt with in a standard way.
Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims.
Patent Application
20080077777
