This relates generally to microprocessors.
One way that microprocessors improve performance is to use a branch prediction unit. A branch prediction unit attempts to determine which way an execution sequence will branch so that instructions may be pre-fetched along the predicted path. This may improve speed and performance.
Typically, microprocessors are designed to prevent a core from executing instructions down the wrong program path. For this reason, branch prediction units include a branch predictor that predicts the direction of a branch and a branch target buffer that predicts the target of a taken branch. For example, a Pentium® processor employs a 256 entry 4-way set associated branch prediction buffer in the decode stage with each entry augmented with a 2-bit branch predictor. The branch predictor is typically implemented using static random access memories. Typically, 16 kilobytes or even larger static random access memory is needed, with the branch predictor and branch target buffer employing roughly half of the branch prediction unit area.
Embedded processors are typically used for microcontrollers, smart phones, tablet computers, and other mobile applications. The branch prediction unit adds a significant amount of power consumption and consumes a significant amount of area on the core in embedded processors. This power and area consumption is more of an issue with relatively small embedded processors.
Some embodiments are described with respect to the following figures:
In accordance with some embodiments of the present invention, a branch prediction unit for an embedded controller may be placed in association with the instruction fetch unit. In addition, the branch prediction unit may include no branch predictor. Also, the return address stack may be associated with the instruction decode stage and is structurally separate from the branch prediction unit. In some cases, this arrangement reduces the area of the branch prediction unit, as well as power consumption.
Referring to
The instruction fetch 12 sends a taken or not-taken branch direction and a target information to the next stage. The instruction decode stage 14 sends the same information to the operand fetch stage 16 which sends it on to the execution unit 18.
In accordance with some embodiments, no branch predictor is provided in the branch prediction unit 22. This reduces the size of the branch prediction unit. Furthermore, the branch target buffer may be relatively small sized compared to conventional branch target buffers in some embodiments. For example, the branch target buffer may have 32 entries or less and less than 5000 gates.
The inventors of the present invention have determined that, in relatively small sized branch prediction units, the branch predictor is largely ineffective. By eliminating the branch predictor, the branch target buffer can potentially occupy more area to improve its hit ratio, in some embodiments.
Unlike traditional return address stacks (RASs) that sit alongside the target buffer, the return address stack 24 is structurally separated from the main branch prediction unit. Instead, it resides in the instruction decode stage, stores a return address when a call instruction has been decoded and predicts the return target when a ret instruction has been decoded. By structurally separating the RAS from branch prediction unit, branch target buffer entries are not wasted for identifying call and instructions in fetch stage. This further improves the effective size of branch target buffer and increases the accuracy of branch prediction unit in some embodiments. Because the branch prediction unit is implemented in the instruction fetch stage in some embodiments, it guides the paths of the instruction fetch, collaborating with the instruction fetch buffer to keep the program counter up to date.
While an embodiment is shown with a five stage in order processor pipeline, other architectures may also be used.
The branch prediction unit in the instruction fetch stage provides three interfaces in some embodiments. The prediction interface takes as an input the current fetch block's address and predicts the next fetch block's address. The update interface updates the branch prediction unit for resolved branches. The next instruction pointer (NIP) interface takes as an input the current program counter or instruction pointer and provides the next program counter if it has previously made a taken prediction for the fetch block in which the current program counter resides.
With the branch prediction unit sitting in the instruction fetch unit, correct predictions made by the branch prediction unit lead to correct instruction fetch paths. This may avoid extra cycle bubbles or wasting energy and bandwidth to fetch the wrong program path, in some embodiments.
The instruction decode stage 14, operand fetch and execution stages are all responsible for resolving and repairing the branches. Unconditional branches using immediate number operands are resolved and/or fixed in the instruction decode unit. Conditional branches using immediate number operands are resolved or fixed in the operand fetch unit and the rest of the branches are handled in the execution stage.
To determine the correctness of a predicted branch, the predicted direction and target are carried forward in the pipeline stages, as shown in
To reduce power consumption incurred by excessive branch prediction unit updates, only taken branches are updated in the branch target buffer, in some embodiments. Likewise, indirect branches, less likely to be correctly predicted by a relatively small branch target buffer, are not sent to the branch prediction unit for updates, in some embodiments.
Referring to
The sequence 40 begins by receiving the misprediction signal in the instruction fetch unit, as indicated in block 42. Then the instruction fetch unit flushes the internal fetch buffer, as indicated in block 44. Next, the instruction fetch unit starts fetching from the correct target (block 46). Meanwhile, it sends an update signal to the branch prediction unit to update the branch target buffer, as indicated in block 48.
In one embodiment, the return address stack is a size-configurable stack implemented in the instruction decode stage. For call instructions decoded in the instruction decoder, the next program counter of the return address stack gets pushed into the top of the return address stack. For anret instruction decoded in the instruction decoder, the first entry of the return address stack is popped up as a target of the ret. The target is then sent back to the instruction fetch unit for an immediate fix in the same cycle, in some embodiments.
With this embodiment, correct predictions made by the return address stack incur only one cycle bubble. However, this effectively saves space for the branch target buffer to make it more productive for other types of branches.
Referring to
The sequence 50 begins by detecting whether a call instruction has been decoded, as indicated in diamond 52. If so, the next program counter gets pushed into the top of the return address stack, as indicated in block 54. Then a check at diamond 56 determines whether anret instruction was decoded in the instruction decode unit. If so, the first entry of the return address stack is popped up as a target of the ret, as indicated in block 58. Then the target is sent back to the instruction fetch unit for an immediate fix in the same cycle, as indicated in block 60.
The branch prediction unit, shown in
The branch target buffer 30 stores tags 26, targets 28 and the last bytes. The prediction history buffer stores a branch identifier 34, last byte 36 and a target 38.
A sequence 62, shown in
The sequence 62 begins by receiving the current fetch block address, as indicated in block 64. Then the address is fed into the branch target buffer, as indicated in block 66.
A check at diamond 68 determines whether there is a hit in the branch target buffer. If so, the prediction output is a taken branch with the target address stored in the corresponding branch target buffer entry being provided as the next fetch address to the instruction fetch unit (block 70). Otherwise, a misprediction is announced at 78.
The instruction fetch unit in the pipeline may fetch a fetch block, such as 8 bytes, every cycle based on addresses provided by the branch prediction unit and store the fetch block in an instruction fetch buffer. Similarly, it also pulls out a few bytes from the instruction fetch buffer every cycle for the instruction length decoder. Once the length of the current instruction is known, the next instruction pointer logic updates the program counter accordingly. Without a branch prediction unit, the next instruction pointer logic simply increments the instruction pointer with the length of the current instruction. With the branch prediction unit, the next instruction pointer logic needs to know if a taken prediction has previously been made by the branch prediction unit for the instruction bytes it is currently dealing with.
For updating the branch prediction unit, the mispredicted branch address, as well as the target address, is sent to the instruction fetch unit when a branch is resolved. The instruction fetch unit then feeds this information into the branch prediction unit as needed.
For every taken prediction the branch prediction unit makes, the target address and the last byte offset are stored in the prediction history buffer, as indicated in block 72. An index, such as a two-bit branch identifier, is assigned for this prediction for future prediction history buffer lookup, as indicated in block 74. The index is provided along with the predicted fetch block's address to the instruction fetch unit, as indicated in block 76.
The fetch unit associates the branch identifier with the fetch block and keeps it in the instruction fetch buffer, as shown in
References throughout this specification to “one embodiment” or “an embodiment” mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one implementation encompassed within the present invention. Thus, appearances of the phrase “one embodiment” or “in an embodiment” are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be instituted in other suitable forms other than the particular embodiment illustrated and all such forms may be encompassed within the claims of the present application.
While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.
This application is a continuation of U.S. patent application Ser. No. 13/992,723, filed Jun. 8, 2013, which is a §371 national stage of international application PCT/US2011/68027, which filed Dec. 30, 2011, the content of which is hereby incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
5623614 | Van Dyke | Apr 1997 | A |
5794063 | Favor | Aug 1998 | A |
5835967 | McMahan | Nov 1998 | A |
5935241 | Shiell | Aug 1999 | A |
5964869 | Talcott | Oct 1999 | A |
6058447 | Holst | May 2000 | A |
6646899 | Yiu | Nov 2003 | B2 |
6874081 | Kruckemyer | Mar 2005 | B2 |
6877085 | Yeh | Apr 2005 | B2 |
6883090 | Kruckemyer | Apr 2005 | B2 |
7100064 | Rogenmoser | Aug 2006 | B2 |
7269714 | Yeh | Sep 2007 | B2 |
7320066 | Yokoi | Jan 2008 | B2 |
7752426 | Nye | Jul 2010 | B2 |
7822954 | Ward, III | Oct 2010 | B2 |
8250349 | Inoue | Aug 2012 | B2 |
8578141 | Jarvis | Nov 2013 | B2 |
20050278517 | Wong | Dec 2005 | A1 |
20100095102 | Toyoshima | Apr 2010 | A1 |
20120233442 | Shah | Sep 2012 | A1 |
20120297167 | Shah | Nov 2012 | A1 |
Number | Date | Country |
---|---|---|
2001521241 | Nov 2001 | JP |
Number | Date | Country | |
---|---|---|---|
20160283244 A1 | Sep 2016 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 13992723 | US | |
Child | 15175427 | US |