Way prediction for a branch target buffer of a processor

Abstract

Implementations described herein relate to way prediction for a branch target buffer of a processor. For example, a disclosed method includes determining an instruction address and accessing, from a first branch target buffer and based on the instruction address, first branch prediction data. The first branch prediction data includes a branch offset, a branch target, and a predicted way-hit map for the branch target in a second branch target buffer that provides a plurality of ways and stores second branch prediction data corresponding to the branch target. The method further includes accessing, from the second branch target buffer and based on the branch target, the second branch prediction data. The accessing of the second branch prediction data is performed which at least one way of the plurality of ways being disabled based on the predicted way-hit map. Corresponding branch prediction units, front ends, processors, and other implementations are also disclosed.

Description

Atty Docket No. 0120-1100WO1WAY PREDICTION FOR A BRANCH TARGET BUFFER OF A PROCESSORBACKGROUND

[0001] Modem microprocessors (e.g., central processing units, etc.) use branch prediction to achieve high performance and instruction throughput. Branch instructions, which can alter the flow of program execution, may create pipeline stalls if a processor must wait to determine the branch's outcome before fetching subsequent instructions. To help avoid such stalls, traditional branch prediction techniques (e.g., static prediction, simple branch history tables, etc.) have been used. However, these conventional techniques may struggle when sections of code include abundant and / or complex branching, thereby leading to mispredictions and significant performance penalties. Accordingly, there remains room for further advancements in branch prediction to address the increasing complexity of modem software and the growing performance demands of computing systems.SUMMARY

[0002] A branch target buffer may be used within a processor front end to assist with branch prediction by storing branch information for branch instructions in memory based on the addresses of the instructions. However, since it would be impractical and wasteful for a branch target buffer to provide unique storage space for every possible memory address (since only a small fraction of addresses in memory' are likely to be storing branch instructions at any given time), each addressable index of a branch target buffer (referred to as a buffer index) may be shared by instructions at many different memory addresses. For example, if 1000 memory locations had addresses numbering from decimal values 0 to 999, each of the 100 addresses that ended in ‘5’ (i.e., addresses 5, 15, 25, 35, etc., up to 995) could all map to a same buffer index, meaning that a physical storage space associated with that buffer index could be used by any of the 100 addresses. As described in detail herein, a multiway branch target buffer may help alleviate conflicts of multiple addresses that share a same buffer index by providing multiple entries at the index. As used herein, the multiple entries at a buffer index can be provided by different “ways” of the branch target buffer. For example, a four-way buffer would allow the 100 addresses in this example to share physical storage space for four entries instead of only for one entry. Methods and systems described hereinAtty Docket No. 0120-1100WO1relate to way prediction for a branch target buffer. More particularly, implementations described herein facilitate efficient use of multi-way branch target buffers by allowing certain ways of the buffer to remain disabled (e.g., powered down) when it can be predicted ahead of time that these ways are not likely to be associated with a particular address. In this manner, the processor may be made to run more efficiently (e.g., with reduced power consumption, less heat, etc.), leading to various performance benefits such as improved benchmarks, increased battery life, reduced heat, and so forth.

[0003] To this end, one implementation described herein involves a method that may be performed by a branch prediction controller within a processor to perform way prediction for a branch target buffer of the processor. For example, this method may include: 1) determining an instruction address; 2) accessing, from a first branch target buffer and based on the instruction address, first branch prediction data that includes a branch offset, a branch target, and a predicted way -hit map for the branch target in a second branch target buffer. For example, the first branch target buffer may be a smaller branch target buffer that uses less power and is fully powered on, while the second branch target buffer may be a larger, branch target buffer that provides a plurality of ways and stores second branch prediction data corresponding to the branch target. The method may then further include: 3) accessing, from the second branch target buffer and based on the branch target, the second branch prediction data, where the accessing of the second branch prediction data may be performed with at least one way of the plurality of ways being disabled based on the predicted way-hit map.

[0004] Another implementation described herein involves a branch prediction unit of a processor. The branch prediction unit of this implementation may include: 1) a first branch target buffer storing first branch prediction data that includes a branch offset, a branch target, and a predicted way -hit map for the branch target: 2) a second branch target buffer that provides a plurality of ways and stores second branch prediction data corresponding to the branch target; and 3) a branch prediction controller. Similarly as described in relation to the method above, the branch prediction controller may be configured to: 1) determine an instruction address, 2) access, based on the instruction address, the first branch prediction data from the first branch target buffer, and 3) access, based on the branch target, the second branch prediction data from the second branch target buffer. The access of the second branch prediction data may again be performed with at least one way of the plurality7of ways being disabled based on the predicted way-hit map for the branch target.

[0005] Another implementation described herein involves a branch target buffer within a branch prediction unit of a processor. For example, this branch target buffer mayAtty Docket No. 0120-1100WO1correspond to the first branch target buffer in the examples described above and may include, for example: 1) an input interface configured to receive an instruction address from a branch prediction controller of the branch prediction unit; 2) a memory configured to store first branch prediction data associated with the instruction address, the first branch prediction data including a branch offset, a branch target, and a predicted way -hit map for the branch target within a separate branch target buffer (e g., corresponding to the second branch target buffer in the examples above), the separate branch target buffer providing a plurality of ways and storing second branch prediction data corresponding to the branch target; and 3) an output interface configured to provide, in response to the instruction address being received at the input interface, the first branch prediction data.

[0006] Other implementations may perform similar functions as described above and / or may use other types of hardw are to perform the functions. Certain implementations may involve systems, devices, media, and / or combinations of these, that employ processors such as described herein (e.g., processors with branch prediction units that include multi-way branch target buffers, branch target buffers that are configured to store predicted way -hit maps, etc.).

[0007] The details of these and other implementations are set forth in the accompanying drawings and the description below . Other features will also be made apparent from the following description, drawings, and claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 show s certain aspects of an illustrative implementation of way prediction for a branch target buffer of a processor in accordance with principles described herein.

[0009] FIG. 2 shows an illustrative branch prediction unit with a branch prediction controller and first and second branch target buffers in accordance with principles described herein.

[0010] FIG. 3A shows generic instructions, including branch instructions, within example predict blocks of a generic program layout in accordance with principles descnbed herein.

[0011] FIG. 3B show s more particular instructions, including branch instructions, within example predict blocks of a more specific program layout in accordance with principles described herein.

[0012] FIG. 4A shows a generic instruction address that may be used to access aAtty Docket No. 0120-1100WO1branch target buffer in accordance with principles described herein.

[0013] FIG. 4B shows a more specific instruction address that may be used to access a branch target buffer in accordance with principles described herein.

[0014] FIG. 5 shows certain aspects of an illustrative first branch target buffer that may store predicted way -hit mapping data for a second branch target buffer in accordance with principles described herein.

[0015] FIG. 6 shows certain aspects of an illustrative multi-way branch target buffer that may operate with certain ways disabled based on predicted way -hit mapping data managed in accordance with principles described herein.

[0016] FIG. 7 shows an illustrative timing diagram to illustrate how- data may be used and managed in branch target buffers in accordance with principles described herein.

[0017] FIG. 8A shows certain aspects of an illustrative way-hit map used for way prediction in accordance with principles described herein.

[0018] FIG. 8B shows an illustrative predicted way -hit map that exhibits a superset mismatch with an illustrative observed way -hit map in accordance with principles described herein.

[0019] FIG. 8C shows an illustrative predicted way -hit map that exhibits a subset mismatch with an illustrative observed way -hit map in accordance with principles described herein.

[0020] FIG. 9A shows certain aspects of an illustrative validated branch pair that may be represented in branch target buffers in accordance with principles described herein.

[0021] FIG. 9B show s certain aspects of an illustrative invalidated branch pair that may be represented in branch target buffers in accordance with principles described herein.

[0022] FIG. 9C shows certain aspects of how the validated and invalidated branch pairs of FIGS. 9A-9B may be handled when performing way prediction for the branch target buffer in accordance with principles described herein.

[0023] FIG. 10 shows an illustrative method for w ay prediction for a branch target buffer of a processor in accordance with principles described herein.

[0024] FIG. 11 shows certain aspects of an illustrative processor in which a branch prediction unit such as described herein may be implemented in accordance with principles described herein.

[0025] FIG. 12 shows an illustrative computing device that may be used to implement various devices and / or systems described herein.Atty Docket No. 0120-1100WO1DETAILED DESCRIPTION

[0026] Methods and apparatuses described herein relate to way prediction for a branch target buffer of a processor. As will be described and illustrated in detail, different types of branch target buffers may be used within a processor front end to assist with branch prediction. Specifically, each addressable storage space within a branch target buffer may potentially store branch information for branch instructions that could be stored at a number of memory addresses that map to the same storage space within the buffer (referred to as having the same buffer index). As will be described in detail herein, a multi-way branch target buffer allows for branch prediction data associated with different addresses to be stored at the same buffer index of the branch target buffer. However, it may be inefficient to always enable (e.g., power on) all of the resources associated with each of the plurality of ways provided by the branch target buffer. Accordingly, implementations described herein relate to methods of predicting which ways are likely to be relevant for a given memory address (e.g., the ways that will “hit” for that memory address) so that only resources associated with those predicted ways consume power for a given buffer access while other resources can remain disabled (e.g., powered down) so as to conserve power, heat, and so forth.

[0027] Modem processors (also referred to as microprocessors, computer processors, etc.) such as CPUs function by performing, as quickly and efficiently as possible, large numbers of instructions stored in an instruction cache or other such memory or data buffer. For example, human-readable computer code may be written by a software developer and converted (e.g., by a process of compiling, linking, etc.) into a series of machine code instructions. Performance of the processor is often measured in terms of latency (i.e., how long it takes the processor to fully process a given instruction) and throughput (i.e., how many instructions the processor is capable of processing in a given amount of time). To maximize throughput, modem processors tend to have long pipelines in which as much work is parallelized as possible. More particularly, a given instruction may be performed in stages, over the course of several clock cycles, by various different functional units within the processor. To the extent possible (e.g., where the execution of at least part of one instruction is not dependent on execution of another instruction), many instructions may also be performed concurrently (i.e., in parallel). As a result, many instructions may be in the pipeline of a certain processor at any given time and multiple instructions may be completed during each clock cycle.

[0028] In order to achieve the desirable throughput and performance that a relatively long and wide pipeline may provide (i.e., long in that instructions are performed in manyAtty Docket No. 0120-1100WO1small steps over the course of several clock cycles, and wide in that the work is highly parallelized), processor architectures may be divided into a front end that is responsible for keeping the execution pipeline full and a back end that is responsible for quickly executing the instructions that the front end provides. As such, the front end may include an instruction cache (e.g., a memory7buffer that may be accessed with very7low latency) into which upcoming instructions are loaded (e.g., instructions associated with a program that is executing on the processor), as well as a fetch unit that accesses the instruction cache (as well as, potentially, other locations where instructions may be stored if they have not been prefetched to the cache) to obtain relevant instruction data as it is prepared for execution by the back end. Other functional units may be associated with the front end to further prepare instructions obtained (fetched) by the fetch unit for execution by the back end. For example, a decoding unit may determine what type of instruction has been fetched, an out of order engine may determine what dependencies the instruction may have (and the extent to which it may be processed in parallel and / or out of order with respect to other instructions), and so forth.

[0029] The back end may then include various functional units for executing the various types of instructions that have been fetched, decoded, and provided to the pipeline. For instance, the back end may include an integer execution unit (IXU) responsible for integer arithmetic (e.g., add, subtract, etc.) and logical operations (e.g., bitwise operations, shifts, comparisons, etc.), a load / store unit (LSU) responsible for transferring data between memory and the processor’s registers, a floating point unit (FPU) responsible for performing mathematical operations on floating point values (e.g., including more complex functions such as square roots, trigonometric functions, etc.), and so forth.

[0030] If program execution were merely to consist of executing a long, linear list of ordered instructions, the role of the front end would be straightforw ard and relatively simple. Specifically, the fetch unit could be configured to fetch at least as many instructions per cycle as the back end could process per cycle and could thereby expect to remain ahead and keep the pipeline full (e.g., keep the execution pipeline of the back end busy and engaged with processing work). The nature of real-world program execution is. however, not so linear. Generally, real-world program instructions tend to branch to other parts of code in order to implement loops, conditionals statements, and other non-linear software structures.Accordingly, while typical program code may contain a few- instructions that are performed in a consecutive and linear sequence, it is generally not long before an instruction will be encountered that causes program execution to branch (e.g., skip, move jump, etc.) to a targetAtty Docket No. 0120-1100W01location that would ty pically (though not always) be in a new part of memory' (e.g., a memory address other than the next sequential address that would be executed if not for the instruction). Such instructions are referred to herein as branch instructions.

[0031] Branch instructions may be characterized by7various properties, including being conditional (diverting program flow only under certain circumstances) or unconditional (diverting program flow whenever encountered), being direct (diverting program flow to a target location specified in the instruction) or indirect (diverting program flow to a target location that is calculated or retrieved from a register or memory location), and so forth. Branch instructions that are determined or predicted to divert program flow (i.e., certain conditional branch instructions and all unconditional branch instructions), are referred to as taken branches, while branch instructions that are determined or predicted to not actually divert program flow (i.e., other conditional branch instructions) are referred to as not taken. While described above in terms of diverting program flow to a target location, it will be understood that taken branches may sometimes divert program flow to a target location that happens to be the same as a sequential memory location that flow would move to if the branch were not taken. For example, it will be understood that, in certain scenarios, a branch could be taken to the next address in sequence, such that program flow moves to the same place whether or not the branch is taken. Taking such a branch will be understood, therefore, to not divert program flow non-linearly.

[0032] Branch instructions (and conditional branch instructions in particular) create a technical problem that complicates the simplistic front end described above with a linear list of instructions that are to be consecutively fetched and executed. This is because branch instructions may divert program flow from one part of memory from which instructions are being fetched and executed (e.g., one location within memory, etc.) to a different part of memory, meaning that the fetch unit may need to move to a new location to continue fetching instructions for execution. While unconditional branch instructions (which are alway s taken) may complicate the movement of the fetch unit through memory' (so that it jumps around rather than proceeding linearly), conditional branch instructions compound this technical problem even further, since they may or may not be taken, and since it is generally not known for sure whether they will be taken until many cycles after subsequent instructions are to be fetched.

[0033] To address this technical problem of fetching and preparing instructions for execution by the back end before it is certain exactly what instructions are to be executed, at least one technical solution that may be implemented by a front end is to include, along withAtty Docket No. 0120-1100WO1the fetch unit and other front-end units, a branch prediction unit. A branch prediction unit may be responsible for identifying branch instructions in upcoming code, predicting whether the branch instructions are likely to be taken or not, and directing the fetch unit accordingly (e.g., instructing the fetch unit to continue fetching instruction data in the same location or to move to a new target location (address) according to the best prediction that the branch prediction unit is able to make). Branch prediction units may help the front end keep the instruction queue as full as possible (and thereby keep the execution pipeline of the back end more efficiently engaged than it might otherw ise be) by allowing the fetch unit to continue fetching instruction data beyond branch instructions that have not yet been executed and / or whose conditions have not yet been resolved.

[0034] Branch prediction within a processor is thus performed to help keep an execution pipeline of the processor as full as possible so that delays to fetch instructions (and performance penalties associated therewith) may be avoided. To make such predictions, a branch prediction unit may include, maintain, and use one or more data stores (e.g., buffers, caches, tables, etc.) that help track information about taken branches. One such data store is referred to herein as a branch target buffer and will be understood to refer to a cache that stores information about whether various branch instructions are taken, what the targets for these taken branches are, other metadata regarding content about the branch and certain actions to be taken by the pipeline as a result of the branch, and so forth. As will be described herein, multiple branch target buffers with different properties may be used in a single implementation to gain insights with different characteristics at different times. For example, a first branch target buffer could be low in capacity but also very low7latency so as to provide almost instantaneous (e.g., within a single clock cycle) insight that may be of mediocre reliability. Meanwhile, a second branch target buffer could be high in capacity and deliver insight with very high reliability, though the latency may be higher, such that the branch data provided by this buffer takes several clock cycles to produce. Other types of predictors and / or data structures (e.g., multiple branch target buffers, tagged geometric history length predictors (TAGEs), indirect target tagged geometric history length predictors (ITTAGEs), etc.) may also be used in combination to perform branch prediction functions described herein.

[0035] Computer processors operate using clock signals that cycle through short periods (referred to as clock cycles or, more simply, cycles) to synchronize operations being performed by the processor. For example, in a branch prediction unit implementation employing the branch target buffers described above, both the first and second branch targetAtty Docket No. 0120-1100WO1buffers may share a clock signal (shared with one another and with other logic and storage facilities within the branch prediction unit) to allow all the facilities to interoperate in a synchronous manner.

[0036] At least one technical problem that is presented by any type of branch target buffer is that branch prediction data is stored within the buffer in relation to memory¬ addresses of branch instructions, and yet there are generally far more potential memory addresses that could store a branch instruction than there are storage spaces (e.g.. at distinguishable7addressable buffer indexes). In other words, it would be highly impractical and wasteful for a branch target buffer to provide a dedicated storage space for branch prediction information relevant to each unique instruction address in memory.

[0037] At least one technical solution to this technical problem involves a branch target buffer with buffer indexes that map to many instruction addresses that could potentially be associated with stored branch prediction data. To illustrate with a basic example, 1000 memory7addresses numbering from OdO to 0d999 (decimal values 0 to 999) will be considered. Rather than implementing a branch target buffer with 1000 different entries addressable at unique buffer indices (e.g., to allow each memory address to uniquely map to one buffer index), a branch target buffer could instead include only ten buffer indices, which the addresses could map to based on the last digit of the address. For example, the 100 addresses ending in ‘0’ (i.e., OdO, OdlO, 0d20, 0d30. etc., up to 0d990) may map to a first buffer index (e.g., buffer index 0). the 100 addresses ending in71 ‘ (i.e.. Odl, Odl 1, 0d21. 0d31 , etc., up to 0d991 ) may map to a second buffer index (e.g., buffer index 1 ) , and so forth up to the 100 addresses ending in ‘9’ (i.e., 0d9, 0dl9, 0d29, 0d39, etc., up to 0d999), which may map to a tenth buffer index (e.g., buffer index 9).

[0038] While this approach would save significant resources for the branch target buffer and thereby address the technical problem of storage resources mentioned above (since it would need only enough resources to hold only ten branch prediction data entries rather than 1000), another technical problem arises as this type of buffer addressing is implemented. Specifically, there could be a conflict as to which memory7address is associated with a particular buffer index to which several memory addresses correspond. For instance, if there were branch instructions at addresses 0d31, 0d411, and 0d601 in the example above, each of these addresses would map to the same buffer index (e.g., buffer index 1 in the example above). Meanwhile, if there were also branch instructions at addresses 0d89, 0d259, 0d719, and 0d799 in the example above, each of these addresses, too, would map to the same buffer index (e.g., buffer index 9).Atty Docket No. 0120-1100WO1

[0039] While the only way to completely guarantee that no such conflict ever arises may be to provide uniquely addressable entries for each and every address (which is not practical, as described above), at least one technical solution described herein allows for many conflicts to be mitigated while still maintaining a reasonable amount of resource usage. Specifically, this technical solution involves providing multiple entries for each addressable buffer index so that when two addresses both happen to map to the same buffer index, one need not necessarily evict the other to be able to store its data. Such a branch target buffer is referred to as a multi-way branch target buffer and the multiple storage entries associated with each unique buffer index are referred to as ways. For example, a four-way buffer would allow the 100 addresses mapping to buffer index 1 in the example above to share four entries worth of physical storage space instead of a single entry. Thus, for instance, a first way of buffer index 1 could be used for the branch instruction at address 0d31, a second way could be used for the branch instruction at address 0d411, a third way could be used for the branch instruction at address 0d601, and a fourth way may be available for use by another branch instruction at an address ending in ‘ 1’ if such should be discovered. Similarly, the four-way buffer would allow the 100 addresses mapping to buffer index 9 in the example above to similarly share four entries worth of physical storage space instead of a single entry. For instance, the first way of index 9 could be used for the branch instruction at address 0d89, a second way could be used for the branch instruction at address 0d259, a third way could be used for the branch instruction at address 0d719, and a fourth way could be used for the branch instruction at address 0d799.

[0040] While the multi-way branch target buffer may address the technical problem of too many conflicts and evictions in the buffer while not exacerbating the technical problem of a buffer that is impractically large and slow, yet another technical problem arises when all hardware resources associated with all the ways of a particular buffer index are enabled and consuming power even though it may often be the case that some or many of these resources are not relevant to an current address for which branch prediction data is being requested. Power consumption for any modem electronic device, including a processor, may be desirable to minimize for the sake of battery life, heat, and so forth. Accordingly, it would be desirable to implement a multi-way branch target buffer as efficiently as possible by not enabling certain ways if it can be predicted that the data they store is not of interest for a given address lookup.

[0041] Methods and systems described herein provide technical solutions to this technical problem by providing way prediction for multi-way branch target buffers. MoreAtty Docket No. 0120-1100WO1particularly, as will be described in more detail below, a first branch target buffer (which may¬ be implemented as a multi-way buffer but which may be configured to remain fully powered on during operation) may be used to store predictions of which ways are likely to be relevant (stored within data structures referred to herein as predicted way -hit maps) as an instruction address is accessed within a second branch target buffer. The second branch target buffer may be a multi-way branch target buffer and, based on predicted way -hit maps from the first branch target buffer, may be configured to disable one or more ways that are not predicted to be relevant for an address being accessed. The second branch target buffer may also be configured to provide ground truth observation data indicative of which w ays actually do hit for a particular address (referred to as observed way -hit maps), so that predicted way -hit maps stored by the first branch target buffer may be updated and managed to be as accurate as possible.

[0042] Various beneficial technical effects may arise as a consequence of the technical solutions described herein to the various technical problems around branch prediction and multi-way branch target buffers. For example, implementations described herein facilitate efficient use of multi-way branch target buffers by allowing the second branch target buffer to disable certain ways of the buffer (e.g., to power down the ways, to leave the ways pow ered down rather than powering them up, etc.) when it can be predicted ahead of time that these ways are not likely to be associated with a particular address. The technical effect of this may be that the processor runs more efficiently (e.g., with reduced power consumption, less heat, etc.) and provides various performance benefits such as improved benchmarks, increased battery life, reduced heat, and so forth.

[0043] Various implementations will now be described in more detail with reference to the figures. It will be understood that particular implementations described below are provided as non-limiting examples and may be applied in various situations. Additionally, it will be understood that other implementations not explicitly described herein may also fall within the scope of the claims set forth below. Methods and systems for way prediction for a branch target buffer of a processor may result in any or all of the technical effects mentioned above, as well as various additional and / or alternative technical effects and benefits that will be described and / or made apparent below.

[0044] FIG. 1 show s certain aspects of an illustrative implementation 100 of way¬ prediction for a branch target buffer of a processor in accordance with principles described herein. More particularly, as shown, implementation 100 includes a first branch target buffer 102 and a second branch target buffer 104. Each of the branch target buffers may be includedAtty Docket No. 0120-1100WO1in a branch prediction unit (not shown in FIG. 1, but as will be illustrated in more detail below) configured to predict upcoming instructions that are to be executed by a back end of a processor, including by predicting when branch instructions will be encountered and taken to divert program flow to different memory locations.

[0045] Each of branch target buffers 102 and 104 are shown to take an instruction address as an input and to provide branch prediction data as an output. For example, branch target buffer 102 is shown to input an instruction address 106-1 and, based on that address, to output branch prediction data 108. Similarly, branch target buffer 104 is shown to input an instruction address 106-2 and, based on that address, to output branch prediction data 110.

[0046] A dotted line is shown to connect instruction address 106-1 and instruction address 106-2 in FIG. 1. This line suggests that, while the distinct branch target buffers each have their own input interface and can be addressed separately, the same address is typically provided to both branch target buffers at the same time. In other words, during a given clock cycle, a branch prediction unit may be redirected to a new instruction address and, in response, may provide that instruction address to both branch target buffers 102 and 104. However, it will also be understood that if it takes a branch target buffer several clock cycles to access data (e.g., as may be the case, particularly, with branch target buffer 104, as will be described), a different instruction address could be input for the buffer to start working through the pipeline prior to a previous input being completed. As a result, both branch target buffers 102 and 104 could be directed at a first instruction address during a first clock cycle, then, during a subsequent clock cycle, both branch target buffers 102 and 104 could be redirected to a second instruction address even while branch target buffer 104 is still working on the first instruction address.

[0047] The reason that both separate branch target buffers may be employed in this manner is that, while the buffers may ultimately perform a similar branch prediction role, they may be configured with different characteristics and operate in different and complementary' ways. For example, as indicated parenthetically, branch target buffer 102 may be “Faster” than branch target buffer 104. More particularly, branch target buffer 102 may be configured to produce branch prediction data in the same or fewer clock cycles after a request (e g., after receiving a new instruction address) than branch target buffer 104. For instance, if a request is made to both branch target buffers by providing an instruction address on both input lines, branch target buffer 102 may produce branch prediction data 108 by the subsequent clock cycle after the request, such that the branch prediction data is produced in a single clock cycle. In contrast, it may take branch target buffer 104 several clock cycles (e.g..Atty Docket No. 0120-1100WO1two, three, four, or more clock cycles) to produce branch prediction data 110.

[0048] One reason that branch target buffer 102 may produce branch prediction data faster (e.g., with lower latency, in fewer clock cycles, etc.) than branch target buffer 104 is that branch target buffer 102 may be lower capacity than branch target buffer 104 and may be less flexible. For instance, branch target buffer 102 may be configured to store only one branch pair per unique entry point offset within the block, such that if there is an instruction that is followed by multiple different branch instructions that may be taken under different circumstances, only one of those branch instructions at a time will be represented within branch target buffer 102. The relatively low capacity of branch target buffer 102, while allowing for it to be more responsive (e.g., faster), also means that it is only capable of storing branch prediction data for some branch instructions that have been discovered during a particular program execution. The relatively low capacity means that more branch prediction data will tend to be evicted when conflicts arise and the buffer lacks sufficient capacity to store branch prediction data for certain branch instructions that may be observed (including certain branch instructions that may be represented in branch target buffer 104).

[0049] In contrast, while branch target buffer 104 may operate more slowly than branch target buffer 102 (e.g., taking several clock cycles, rather than just one, to produce branch prediction data 110 after a request), the characteristics of branch target buffer 104 may complement branch target buffer 102 in many respects (having strengths where branch target buffer 102 has limitations and vice versa). As indicated parenthetically on the buffer in FIG. 1, for example, branch target buffer 104 may be '‘More Accurate” than branch target buffer 102. More particularly, branch target buffer 104 may be configured to produce branch prediction data 110 that more accurately reflects observed branching than branch target buffer 102 (e.g., such that branch prediction data 110 may be assumed to be more reliable and accurate than branch prediction data 110 if they are not in agreement).

[0050] One reason that branch target buffer 104 may produce branch prediction data more accurately than branch target buffer 102 (e.g., more likely to comport with the actual program flow that will be taken as the back end executes the instructions) is that branch target buffer 104 may be higher capacity than branch target buffer 102 and may be more flexible. For instance, branch target buffer 104 may be configured to store branch prediction data for multiple branches for any given instruction address or predict block. As such, if there is an instruction that is followed by multiple different branch instructions that may be taken under different circumstances, all of those potential branch instruction candidates may be represented in the large branch target buffer 104 with sufficient information to veryAtty Docket No. 0120-1100WO1accurately predict which one will be taken under a given set of circumstances. The relatively high capacity of branch target buffer 104, while allowing for it to be more accurate (e.g.. reliable), also means that it takes more clock cycles to produce branch prediction data 110 (e.g., several clock cycles, rather than the single clock cycle that branch target buffer 102 may need). However, the relatively high capacity also means that, statistically, there will tend to be less eviction of branch prediction data since fewer conflicts will tend to arise in this buffer with its larger capacity for branch prediction data (e.g., larger capacity than branch target buffer 102).

[0051] It will be assumed that the higher-capacity and more accurate branch target buffer 104 in implementation 100 is implemented as a multi-way branch target buffer. As has been described (and as will be further illustrated and detailed below), a plurality of way options for each buffer index with which branch target buffer 104 may be addressed may allow- for the buffer to store branch prediction data for multiple branches associated with a given address and within a given predict block. Branch target buffer 104 may also have a wider buffer index (e.g., using more bits of the instruction address) as compared to branch target buffer 102, allowing for selection from a larger number of rows that implement the higher capacity and make collisions less likely. Branch target buffer 102 may also be implemented as a multi-way branch target buffer in certain implementations, though there may not necessarily be the same number of ways in each buffer (e.g., branch target buffer 104 may include more ways) and branch target buffer 102 may have fewer buffer indices (fewer rows) available for branch prediction data storage.

[0052] Due to the relatively large number of bits being read by branch target buffer 104, significant power may be drawn when branch prediction data is accessed from the buffer, particularly if all the ways for all the buffer indices are powered on for every access. Thus, to conserve power, implementation 100 shows that instruction address 106 may include a predicted w ay -hit map 112 that may be used to control whether the various ways of branch target buffer 104 are enabled (power on) at any given time. This control is represented in FIG. 1 by way enable 114 lines that will be understood to enable (e.g., power on) a given way when driven to one value (e.g., when driven high) and to disable (e.g., power off) the way when driven to the opposite value (e.g., when driven low). For example, if the multi-way branch target buffer of branch target buffer 104 includes four ways per lane for two lanes (lanes will be described in more detail below), predicted way -hit map 112 may indicate predictions for whether eight different ways are to be relevant (e.g.. are expected to hit) when an instruction address (e.g., a target address indicated in branch prediction data 108 inAtty Docket No. 0120-1100WO1response to instruction address 106-1) is used to access branch target buffer 104.

[0053] More particularly, predicted way -hit map 112 may be produced within one clock cycle of instruction address 106-1 being provided to both branch target buffers 102 and 104, and may be associated with a branch target indicated in branch prediction data 108. Instruction address 106-2 may be redirected for the next clock cycle to the branch target and the predictions represented in the predicted way -hit map 112 may be used to determine which way enables 114 to drive when accessing data associated with the branch target from branch target buffer 104. To put it another way, the predicted way-hit map 112 may indicate which ways can be left disabled (e.g., powered down) during the accessing of the target branch prediction data so as to conserve power.

[0054] When the actual data access for the target is performed in branch target buffer 104, ground truth as to which ways actually hit for a given instruction address may be observed by branch target buffer 104. This information may be fed back as an observed way-hit map 116 to branch target buffer 102, which is what the information for predicted way -hit map 112 is based on. For example, at first, predicted way -hit map 112 may not yet be initialized and may thus default to enabling all of the ways. Then, when actual way-hit observations are made (e.g., when branch target buffer 104 is accessed using a particular instruction address and certain ways hit while others do not), observed way -hit map 116 may be provided to allow branch target buffer 102 to update the predicted way -hit map 112 to be more tailored to the observed reality (e.g.. allowing certain ways to remain disabled if they are not predicted to hit) the next time the instruction address is encountered. With a high-level description of the illustrative implementation 100, an example branch prediction unit configured to achieve way prediction for a branch target buffer will now be described in more detail.

[0055] FIG. 2 shows an illustrative branch prediction unit 200 that will be understood to be included in a front end of a processor (not show n in FIG. 2). Branch prediction unit 200 is shown to include a branch prediction controller 202 that is communicatively coupled to first and second branch target buffers in accordance with principles described herein. More particularly, as shown, branch prediction unit 200 includes an implementation of first branch target buffer 102 and an implementation of second branch target buffer 104.

[0056] As noted w ith dashed-line tags in FIG. 2, certain aspects of branch prediction unit 200 and its operation (e.g., communication between branch prediction controller 202 and branch target buffers 102 and 104. etc.) will be further described below in relation to additional figures. For example, when branch prediction unit 200 is in operation, branchAtty Docket No. 0120-1100WO1prediction controller 202 may make predictions relating to upcoming instructions in accordance with their memory addresses in a program layout 300. The instructions of program layout 300 may be stored in an instruction cache (e.g., cached from main computer memory) and may be fetched (e.g., by a fetch unit not shown in FIG. 2 but described in more detail below) based on the predictions made by branch prediction controller 202. As noted by the dashed-line tag associated with program layout 300 (‘"See FIGS. 3A-3B”), additional aspects and details of example program layouts will be described in relation to FIGS. 3A and 3B.

[0057] As mentioned above, branch target buffer 102 may be configured to store first branch prediction data (e.g., branch prediction data 108) that includes a branch offset, a branch target, and a predicted way-hit map (e.g., predicted way -hit map 112) for the branch target. As has been described, this branch prediction data may be accessed based on an instruction address 106 (e.g., instruction address 106-1, which, as mentioned above, may be the same as instruction 106-2) that is provided as input to branch target buffer 102 from branch prediction controller 202. As noted by the dashed-line tag associated with this communication ("See FIGS. 4A-4B’?). additional aspects and details of such instruction addresses will be described in relation to FIGS. 4A and 4B. As noted by the dashed-line tag associated with branch target buffer 102 (“See FIG. 5”), branch target buffer 102 will be further detailed in relation to FIG. 5.

[0058] Branch target buffer 104 may provide a plurality of ways and may be configured to store second branch prediction data (e.g., branch prediction data 110) corresponding to the branch target included in the first branch prediction data provided by branch target buffer 102. As noted by the dashed-line tag associated with branch target buffer 104 (“See FIGS. 6. 7?’), branch target buffer 104 will be further detailed in relation to FIG. 6, w hile a timing diagram to illustrate various principles of how branch target buffer 102 and branch target buffer 104 may be accessed will be provided in FIG. 7. Branch target buffer 104 is shown to receive the same input instruction address 106 as branch target buffer 102. However, as described above, when the instruction address 106 is redirected based on branch prediction data 108 (e.g.. to the branch target), the instruction address 106 may change to a different address even while branch target buffer 104 is still processing the earlier instruction address 106. As noted by the dashed-line tag associated with branch prediction data 108 and 110 (“See FIGS. 8A-8C, 9A-9C”), various details relating to the branch prediction data output by each branch target buffer 102 and 104 will be described below in relation to FIGS.8A-8C and FIGS. 9A-9C.Atty Docket No. 0120-1100WO1

[0059] Branch prediction controller 202 may be configured to perform operations of a method 1000 that, as noted by the dashed-line tag associated with method 1000 (“See FIG.10"). will be detailed further below with reference to FIG. 10. More particularly, branch prediction controller 202 may be configured to: 1) determine instruction address 106; 2) access, based on the instruction address 106, first branch prediction data 108 from branch target buffer 102; and 3) access, based on the branch target (represented within branch prediction data 108 and used to redirect the input instruction address 106 during a subsequent clock cycle after the accessing of the first branch prediction data), second branch prediction data 110 from branch target buffer 104. Based on the predicted way -hit map for the branch target (also represented within branch prediction data 108), the access of the second branch prediction data 110 from branch target buffer 104 may be performed while at least one way of the plurality of ways of branch target buffer 104 is disabled. In this way, power may be conserved and other technical effects and benefits described herein may be achieved.

[0060] The hardware of branch prediction unit 200 may be implemented in any suitable way. For example, the various components of branch prediction unit 200 may be implemented by structures integrated within the process (e.g., CPU) such as logic structures, memory structures, or the like. In certain implementations, branch target buffer 102 may be implemented using one or more distinct static random-access memory' (SRAM) buffers, while branch target buffer 104 may be implemented using one or more additional distinct SRAM buffers (separate from the one or more SRAM buffers implementing branch target buffer 102). Each of these SRAM buffers may be synchronized on a shared clock signal, such that operations may be performed with respect to different SRAM buffers during a same clock cycle.

[0061] Each of the elements of branch prediction unit 200 shown in FIG. 2 (including the program layout 300 that the branch prediction unit 200 is configured to analyze) will now be described in more detail with reference to the figures indicated by the dashed-line tags in FIG. 2.

[0062] FIGS. 3A and 3B further illustrate how instructions, and particularly branch instructions, may be stored in memory with respect to predict blocks used by branch prediction units to predict upcoming instructions. More particularly, and as illustrated in at least FIGS. 3A and 3B, branch data may be organized within a branch target buffer in relation to small blocks of memory referred to herein as predict blocks. In implementations described herein, for example, predict blocks each include 32 bytes, such that they each may store up to eight 4-byte instructions (i.e., 32-bit instructions). If an instruction address used to addressAtty Docket No. 0120-1100WO1into a branch target buffer (e.g., a program counter) happens to point to an instruction near the front of a particular predict block and there are no taken branches, up to eight instructions within that predict block could be predicted during a clock cycle. However, if the branch prediction unit happens to address into the branch target buffer near the back of the predict block, the number of instructions predicted during a cycle in which that predict block is examined may be more limited (e.g., to as few as one instruction). It will be understood that, in other implementations, predict blocks may be different sizes (e.g., 16 bytes, 64 bytes, etc.) rather than the 32 bytes used in implementation described herein.

[0063] Certain predict blocks will be referred to herein using letters (e.g., a predict block A, a predict block B, a predict block X, a predict block Y, etc.). When referring to adjacent predict blocks, the same letter will be used with an indication based on 32-byte predict blocks. For example, a predict block A will be understood to be immediately followed by a predict block A+32, which will be immediately followed by a predict block A+64. A different letter (e.g., predict block B) would indicate that there is no prescribed relationship to the earlier predict block. For example, predict block B could be adjacent to predict block A (i.e., predict block B could implement predict block A+32). though that will not be assumed. More typically, predict block B will be assumed to refer to an arbitrary and different block of memory than predict block A.

[0064] FIG. 3A shows generic instructions, including branch instructions, within example predict blocks of a generic program layout 300-A in accordance with principles described herein, while FIG. 3B shows more particular instructions, including branch instructions, within example predict blocks of a more specific program layout 300-B. In both examples, the instructions in the program layout will be understood to represent various instructions as they may be defined by an assembly language and stored in computer memory. These instructions may be prefetched from main memory (e.g., a high capacity but relatively high latency dynamic random-access memory' (DRAM) facility) to any of various caching facilities, which would generally allow for data storage that is lower in capacity7but also lower in latency than the main memory.

[0065] Referring first to the generic program layout 300-A in FIG. 3A. instructions represented by long rectangles are shown to be stored with respect to various predict blocks 302 represented by dotted lines. As in other examples described herein, predict blocks 302 may each include 32 bytes worth of 4-byte (i.e., 32-bit) instructions. As such, each predict block 302 in FIG. 3A is shown to include eight rectangles, representing eight instructions within the block.Atty Docket No. 0120-1100WO1

[0066] In one of the predict blocks 302, a particular instruction 304 is called out as being associated with a present program counter or location of program flow. In other words, this instruction 304 may be understood to be where program flow (e.g., as tracked by a program counter) is located at a given moment in time (e.g., after a reset, etc.) when the branch target buffers 102 and 104 will be accessed by providing the address of instruction 304 to the branch target buffer. For this reason, instruction 304 is shown to be located at an instruction address 106 that, as has been described, may be provided to one or more branch target buffers such as branch target buffers 102 and 104.

[0067] Some of the instructions in this predict block 302 are labeled “Branch Instruction'’ and are individually called out with reference numbers to label these as branch instructions 306-1. 306-2, and 306-3. Assuming that program flow generally moves down (when not branching otherwise) within the generic program layout 300-A, it is clear that branch instruction 306-1 will not be the next taken branch associated with the address of instruction 304, since branch instruction 306-1 comes before instruction 304 in the top-to-bottom sequence. However, either of branch instructions 306-2 or 306-3 (or neither of them) could be the next taken branch that the branch prediction unit predicts, depending on whether or not these branch instructions are taken.

[0068] To show a similar, but more specific example, program layout 300-B in FIG.3B is shown to indicate both addresses (16-bit addresses in this example) and instructions within non-contiguous predict blocks 302-A (for a predict block A), 302-B (for a predict block B), and 302-C (for a predict block C). These predict blocks are shown to be separated by ellipses to illustrate that intervening predict blocks may also be present in program layout 300-B but are omitted from the figure to illustrate branching from an address in one block to an address in another.

[0069] In this example, instruction 304, where program flow may presently be located (e.g., to which the program counter may presently be pointing), is shown to be associated with an instruction address 106-A, which, as shown, may be 0x010C within predict block 302-A.

[0070] Similar to FIG. 3 A. a branch instruction 306-1 is shown to be located before this instruction 304 (a LOAD instruction in this example), so that branch instruction 306-1 is known to not be the next branch instruction. However, a branch instruction 306-2 and a branch instruction 306-3 that follow the present LOAD instruction in predict block 302-A may each be candidates for the next taken branch in the sequence that a branch prediction unit is tasked with predicting.Atty Docket No. 0120-1100WO1

[0071] In each of these branch instructions and others described below, notation is made in FIG. 3B to indicate predictions that are made. For example, “T” refers to a branch instruction that is predicted to be (and therefore treated by the branch prediction unit as having been) taken to an indicated target location. “NT” then refers to a branch instruction that is predicted not to be (and therefore treated by the branch prediction unit as having not been) taken, such that sequential instructions immediately following the NT branch instructions will be assumed to be executed instead.

[0072] For example, as shown, branch instruction 306-2 is labeled at address 0x0114 to not be taken (“BRANCH(NT)”), whereas branch instruction 306-3 is labeled at address 0x011C to be taken (“BRANCH(T)”) to address 0x0404 in predict block 302-B. Various other instructions 308-1 through 308-5 are also called out in non-contiguous predict blocks 302-B and 302-C. Specifically, an instruction 308-1 is the target of the branch at branch instruction 306-3 (as shown by a taken path 310-1 that illustrates the predicted diversion of the program flow' from address 0x011C straight to address 0x0404). Instruction 308-1 is shown to be associated with an instruction address 106-B, which, as shown, may be 0x0404 within predict block 302-B.

[0073] An instruction 308-2 at address 0x0408 shows a first candidate branch that could be the next taken branch after program flow completes taken path 310-1 (though, as noted, the branch at 0x0408 in this case will not be predicted to be taken (i.e., NT)). An instruction 308-3 at address 0x0414 shows a second candidate branch that could be the next taken branch after taking path 310-1 (and, as noted and as illustrated by a taken path 310-2, the branch instruction at address 0x0414 is predicted to be taken to address 0x060C in predict block 302-C). An instruction 308-4 represents the target to which taken path 310-2 proceeds (i.e., the instruction at 0x60C, to which program execution goes directly from address 0x0414), and is soon followed, at address 0x0618, by an instruction 308-5, which is yet another taken branch to address 0x0884 (not shown).

[0074] An entry within a branch target buffer such as described herein (e g., branch target buffer 102 or branch target buffer 104) may be used to store different types of branch instructions such as those represented by instructions 306-1, 306-2. 306-3, 308-2, 308-3. and 308-5. Moreover, as will be further described in more detail below, certain branch target buffers could store branch prediction data for pairs of such branch instructions, referred to herein as branch pairs. For example, using a plurality of slots (i.e., data fields) within a single branch target buffer entry, both branch instruction 306-3 and branch instruction 308-3 could be associated with instruction address 106-A of instruction 304 such that the branch targetAtty Docket No. 0120-1100WO1buffer would produce both offsets and targets for these branch instructions in response to instruction address 106-A. This type of branch pair, in which a primary branch (e.g., branch instruction 306-3) targets a different predict block (e.g., predict block 302-B) that includes a secondary branch (e.g., branch instruction 308-3) is referred to herein as a trampoline branch pair. In some implementations, the multiple slots within the single entry of the branch target buffer may be different sizes, so as to store, for example, a full branch target in one slot and a relative branch target (requiring fewer bits) in the other slot. While branch ‘'pairs'’ (suggestive of only two branch instructions) are referred to herein, it will be understood that, by the same principles, larger sets or groups of three or more branches could likewise be stored in a multibranch entry, rather than only a pair of branches (i.e., two branches).

[0075] Multiple types of branch pairs may be stored in this way. For example, an unconditional branch pair may refer to a trampoline branch pair in which a primary branch in a first predict block is followed, when taken, by an unconditional secondary candidate branch in a second predict block (e.g., the target block to which the primary7branch diverts the program flow). Conversely, a conditional branch pair may refer to a trampoline branch pair in which a primary branch in a first predict block is followed, when taken, by a conditional secondary candidate branch in a second predict block (e.g., the target block to which the primary7branch diverts the program flow).

[0076] In some implementations, a single entry (a multi-slot entry associated with predict block 302 -A and accessed based on the instruction address 106-A of instruction 304) could be used to store information for the trampoline block pair of primary branch instruction 306-3 (at address 0x011C within predict block 302-A) and secondary7branch instruction 308-3 (at address 0x0414 within the targeted predict block 302-B), where the secondary7branch instruction 308-3 could either be unconditional (making this an unconditional branch pair) or conditional (making this a conditional branch pair). Though there is an intervening branch instruction 308-2 between the target of the primary branch (i.e., instruction address 106-B at 0x0404) and the exit offset of the secondary branch (i.e., address 0x0414) in this example, it may be determined that branch instruction 308-2 is rarely taken, such that it is advantageous to treat branch instructions 306-3 and 308-3 as a trampoline branch pair (i.e. assuming that when branch instruction 306-3 is taken, branch instruction 308-3 is likely to be taken next). Information for this trampoline branch pair may be stored in a single multi-slot entry7(also referred to as a multi-branch entry) within a branch target buffer such as branch target buffer 102 and / or branch target buffer 104.

[0077] To illustrate how branch prediction controller 202 may address (and therebyAtty Docket No. 0120-1100W01access data stored by) branch target buffers 102 and 104, FIGS. 4A and 4B will now be described.

[0078] FIG. 4A shows a generic instruction address 400-A that may be used to access a branch target buffer such as either of branch target buffers 102 or 104 in accordance with principles described herein. Instruction address 400-A is made up of a number of bits that may be interpreted as fields 402-A, 404- A, 406- A, and 408-A when instruction address 400-A is used to access an entry of a branch target buffer. As shown, the bits are numbered using labels (from right to left) from 0 up to N, for a total of N+l bits. For example, N could be 63, 47, 31, 15, or another suitable number of bits, for a total instruction address length, respectively, of 64 bits, 48 bits, 32 bits, 16 bits, or the like. Each field may then be referred to using a colon notation such as bits N:M+1 of an upper tag field 402-A, bits M:L+1 of a buffer index field 404- A, bits L:K+1 of a lane index field 406- A, and bits K:0 of an instruction offset field 408-A. Each of these fields will now be described in more detail.

[0079] Upper tag field 402-A is not used to index into the branch target buffer, but, once the buffer has been indexed and a row of entries has been read out (e.g.. four entries for a four-way buffer, as described in more detail below), upper tag field 402-A may be matched with the upper tag field of an entry read out to determine if the entry is actually associated with the current instruction address. If there is a hit (i.e., a match of upper tag field 402-A and the upper bits read out of an entry that has been addressed), the entry will be determined to correspond to the particular instruction address. Alternatively, if there is no hit (i.e., no match between the upper tag field of the instruction address and any upper tags stored in entries being read out), it will be determined that the data in the entry' is not relevant, as it actually corresponds to a different instruction address with the same buffer index (but a different upper tag). It will be understood that the upper tag stores the most significant bits of the instruction address. In a system with a reversed endianness, a lower tag would store the most significant bits and may be used in an analogous way.

[0080] Buffer index field 404-A indicates which row of the branch target buffer an address maps to (e.g., which row of the branch target buffer, if any. will hit such that the upper tag bits can be compared to determine if there is a hit in the branch target buffer). As such, buffer index field 404-A may be used to index into the branch target buffer. The branch target buffer may include as many row s (e.g., entries or groupings of entries, as will be described in more detail below) as bits M:L+1 are able to differentiate. For example, if bits M:L+1 includes 9 bits, the branch target buffer may have a 9-bit address space (from ObOOOOOOOOO-Ob 111111111 in binary or from 0-511 in decimal). As will be made apparent,Atty Docket No. 0120-1100WO1and in contrast to upper tag field 402-A, buffer index field 404-A does not need to be stored in a branch target buffer entry itself since the address of the entry indicates what the buffer index field is for that entry.

[0081] Lane index field 406-A indicates which lane of a multi-lane branch target buffer will handle the predict block associated with the instruction address. For example, as described in more detail below, if there are two lanes (e.g., an even lane associated with ‘0’ and an odd lane associated with ‘1’), then every other predict block will correspond to either lane. For example, if a predict block A is an even lane, predict block A+32 will be an odd lane, predict block A+64 will be an even lane, and so forth. Each lane may be associated with a separate buffer structure (e.g., a separate SRAM buffer) or at least with its own address space (identical to the address space of the other lanes, though holding different data) that allows for access concurrently (e.g., during a same clock cycle) with access to the other lanes.

[0082] Instruction offset field 408-A indicates, within a specified predict block (indicated by bits M:L+1) and lane (indicated by bits L:K+1), a specific byte or offset within the predict block addressed by bits N:K+1. In examples where instructions fall on certain byte boundaries (e.g., 2-byte boundaries, 4-byte boundaries, etc.), the very lowest bits (e.g., bit 0 for the 2-byte boundaries, bits 1:0 for the 4-byte boundaries, etc.) may always be zero or may be omitted (thereby only allowing addressing to instruction boundaries and not specific bytes).

[0083] FIG. 4B shows a more specific instruction address 400-B that may be used to access a branch target buffer in accordance with principles described herein. In other words, instruction address 400-B may represent a particular implementation of instruction address 400- A in which specific numbers of bits have been used to provide a more concrete example (with the understanding that all the fields can be configurable to best serve various considerations that differ from implementation to implementation).

[0084] More particularly, instruction address 400-B shows a 64-bit address with an upper tag field 402-B (corresponding to upper tag field 402-A) using bits 63:15, a buffer index field 404-B (corresponding to buffer index field 404-A) using bits 14:6, a lane index field 406-B (corresponding to lane index field 406-A) using single bit 5, and an instruction offset field 408-B (corresponding to instruction offset field 408-A) using bits 4:0.

[0085] As shown, a decimal representation of the possible values that may be represented by each field is noted above each of the fields, while the hexadecimal range of the field is noted within the field itself. In this implementation, for instance, the 49 bits of upper tag field 402-B can represent any value from 0x0_0000_0000_0000 toAtty Docket No. 0120-1100WO1Oxl FFFF FFFF FFFF, or, in decimal, from 0 to about 5.6*1014. The 9 bits of buffer index field 404-B can represent any value from 0x000 to Ox IFF, or. in decimal, from 0 to 511. The one-bit lane index can represent either an even lane (0) or an odd lane (1). And the instruction offset, which in this example permanently stores ‘0’s in bits 1:0, may hold any of the eight offset values 0x00, 0x04, 0x08, OxOC, 0x10, 0x14, 0x18, or OxlC (decimal values 0, 4, 8, 12, 16, 20, 24, or 28).

[0086] FIG. 5 shows certain aspects of the first (e.g., faster, smaller) branch target buffer 102 that may store predicted way -hit mapping data for the second (e.g., more accurate, larger) branch target buffer 104 in accordance with principles described herein. In this example implementation, branch target buffer 102 is shown to be a multi-lane branch target buffer that includes: 1) a first buffer structure associated with a first lane 502-0 (e.g.. "LANE 0”) and that is addressable using a set of buffer index values, and 2) a second buffer structure associated with a second lane 502-1 (e.g., “LANE 1”) and that is addressable using the set (i.e., the same set) of buffer index values. To illustrate, the implementation of branch target buffer 102 in FIG. 5 shows a first buffer structure representing the first lane (“LANE 0”) as well as a second buffer structure representing the second lane (“LANE 1”).

[0087] While only two buffer structures (e.g., memory structures such as static random-access memory structures (SRAMs) or groupings of the same) implementing two lanes are shown in this example, it will be understood that branch target buffer 102 may include the first lane, the second lane, and one or more additional lanes in certain implementations. Accordingly, one or more additional buffer structures corresponding to additional lanes 502 (“OTHER LANES”) may also be included within the branch target buffer 102 in certain implementations. These additional lanes may be configured to store additional branch data for additional predict blocks. For instance, in a four-lane branch target buffer example, two bits of the instruction address could be used to represent the lane and data for the predict blocks could be stored in one of the four lanes based on these bits (i.e., ‘00’, ‘OL, ‘10’, or ‘11’).

[0088] As shown, the addressable rows of each of lanes 502-0 and 502-1 display the same set of buffer index values (e.g., the buffer indices from 0 to 2 and beyond). In other words, as mentioned above, one predict block (e.g., a predict block A) may7be associated with lane 0, the next predict block (e.g., predict block A+32) may be associated with lane 1, the next predict block (e.g., predict block A+64) may be associated again with lane 0, and so forth. In examples having more than 2 lanes, the various predict blocks would be spread evenly over all the lanes in a similar way. As mentioned above, the buffer structures for eachAtty Docket No. 0120-1100WO1lane of branch target buffer 102 may be implemented by any suitable structures. For instance, branch target buffer 102 may be implemented using one or more static random-access memory (SRAM) buffers included in the processor. A first SRAM could implement lane 502-0 while a second SRAM implements lane 502-1, for example. As another example, a single SRAM could implement both lanes if it had a separate input / output interface associated with each lane so that both lanes could be simultaneously accessed.

[0089] Along with being a multi-lane branch target buffer, this implementation of branch target buffer 102 is also shown to be a multi-way branch target buffer. As shown, an entry 504 of branch target buffer 102 (chosen at random from among the entries illustrated for the two lanes in FIG. 5) is associated with a single buffer index (e.g., the row of "Buffer Index 1” in this example). However, as shown, the entry 504 is not the only entry’ that is associated with this row or this buffer index in this example. This is because, as a multi-way branch target buffer, branch target buffer 102 is configured to store, for each addressable location within the multi-way branch target buffer (e.g., for each given index value formed by the subset of the set of bits of the instruction address, or, for example, the subset of bits associated with buffer index field 404-A or buffer index field 404-B), a plurality of entries associated with a plurality of ways (e.g., Way 0, Way 1, Way 2, and Way 3, in this example).

[0090] The illustrated entry’ 504 is shown to be one of up to four entries (in this 4-Way example) represented in output branch prediction data that the branch target buffer 102 produces when Buffer Index 1 is used to address Lane 0. In other w ords, entry 504 may be a first entry' of a plurality' of entries represented in the output data and may be associated w ith a first way of the plurality' of ways (e.g., Way 2 of the four ways in this example). The branch prediction data produced by branch target buffer 102 (e.g., branch prediction data 108) may further be representative of other entries of the plurality of entries, the other entries being associated with other ways of the plurality of ways (e.g., another entry from the same row such as associated w ith Way' 0, Way 1, or Way 3).

[0091] While various inputs and outputs of branch target buffer 102 are not explicitly shown in FIG. 5, it will be understood that branch target buffer 102 may be integrated in a branch prediction unit (e.g., branch prediction unit 200) and may include: 1) an input interface configured to receive an instruction address from a branch prediction controller (e.g., branch prediction controller 202) of the branch prediction unit; 2) a memory' (e.g., the SRAMs implementing lanes 502-0 and / or 502-1) configured to store branch prediction data associated with the instruction address; and 3) an output interface configured to provide, in response to the instruction address being received at the input interface, the branch predictionAtty Docket No. 0120-1100WO1data.

[0092] The branch prediction data stored in connection with a particular instruction address (e.g., stored in a particular entry such as entry 504) may include any suitable data as may sen e a particular implementation. For example, as illustrated in FIG. 5, the branch prediction data within entry 504 may include: an upper tag 506, a branch offset 508, a branch target 510, a predicted way -hit map 112 for the branch target within a separate branch target buffer (e.g., for branch target 510 when looked up in branch target buffer 104, as described below), and other data 512 (e g., metadata, etc.). As will be described in more detail below, the separate branch target buffer (e.g., branch target buffer 104, in this example) may provide a plurality of ways and may store second branch prediction data corresponding to the branch target.

[0093] As described above, branch target buffer 102 may be configured to provide a prediction in a relatively short amount of time, such as within a single clock cycle of when the instruction address (with its embedded buffer index that is used to address branch target buffer 102) is received. However, as further described, this prediction may not necessarily be as accurate as a prediction that will be made by branch target buffer 104 at a later time (e.g., one or more clock cycles after the prediction is provided by branch target buffer 102).Accordingly, as shown in FIG. 5, branch offset 508 and branch target 510 may be considered to be initial (“Initial'’) or, in other words, preliminary predictions that may be corrected and finalized at a later time by data from a more accurate branch target buffer (e.g.. branch target buffer 104).

[0094] When an instruction address is provided to branch target buffer 102, a buffer index and a lane index may be extracted from the address (e.g., the bits of the buffer index field, such as described above in relation to FIGS. 4A and 4B) so that an entire row, including four entries associated with the four ways, may be provided as branch prediction data in response to the instruction address. To determine if any of these entries is a hit (e.g., actually relates to the instruction address, rather than to a different instruction address that happens to have the same buffer index and lane index), the upper tag 506 stored in each entry may be compared to the upper tag field of the instruction address. If there is a hit, the branch offset 508 indicates, for this instruction address, an offset within the predict block where the program flow is predicted to exit the predict block (e.g., which slot within the predict block the branch instruction is predicted to inhabit). The branch target 510 then indicates, for this instruction address, a target address (e.g., a full or absolute address, an abbreviated or relative address based on the current instruction address, etc.) to which program flow is predicted toAtty Docket No. 0120-1100WO1branch. Predicted way-hit map 112 indicates, for the branch target, which ways are predicted to hit in the branch target buffer 104. As described above, this prediction may allow for less than all of the ways to be powered on during the lookup of the branch target to which the branch target buffers will be redirected. For example, based on the predicted way -hit map 112, only one or a small number of ways may be enabled when branch prediction data for the branch target 510 is accessed from branch target buffer 104, while the remainder of the ways may be disabled to save power.

[0095] Other data 512 may represent any other data as may be included in an entry such as entry 504. For example, various types of metadata or other data outside the scope of the above description could be represented by other data 512. As has been mentioned, and as will be described in more detail below, certain implementations of branch target buffer 102 could include multiple slots per entry so that branch pairs (and not just singular branch instructions) can be represented in each entry. In this type of implementation, other data 512 could therefore store an additional branch offset and an additional branch target that is either in the same predict block as indicated by the current instruction address or that relates to the next branch instruction after branch target 510 is followed to a new predict block (e.g.. the secondary branch of a trampoline branch pair). In this example, other data 512 may also include data indicating a format of the entry (e.g., indicating, for example, what type of branch pair, if any. is currently stored in the entry).

[0096] FIG. 6 shows certain aspects of the example multi-way branch target buffer 104, which, as has been described, may be configured to operate with certain ways disabled based on predicted way-hit mapping data managed in accordance with principles described herein. In many respects, branch target buffer 104 is similar to branch target buffer 102 and incorporates several of the concepts described above.

[0097] For example, like branch target buffer 102, branch target buffer 104 is shown to include multiple lanes 602-0 (“LANE 0”), 602-1 (“LANE 1”), and possibly additional lanes 602 (“OTHER LANES”), all of which may be implemented by separate SRAMs or other memory structures. Branch target buffer 104 is also shown, like branch target buffer 102, to be a multi-way branch target buffer that includes, in this case, four ways (“Way 0,” “Way 1,” “Way 2,” and “Way 3”). While a four-way branch target buffer is shown in the example of FIG. 6, it will be understood that certain implementations may include more or fewer than these four ways. For instance, the plurality of ways provided by branch target buffer 104 may include one or more additional ways beyond the first way, the second way, the third way, and the fourth way (e.g., for a total of 8 ways, 16 ways, etc.). For example, byAtty Docket No. 0120-1100WO1having more ways, there may be a reduced likelihood that entries will conflict within the branch target buffer, therefore leading to a reduced eviction rate in the buffer. As such, additional ways may help increase the hit rate for the branch target buffer. As another example, the plurality of ways provided by branch target buffer 104 may include fewer than the four ways shown (e.g., a total of two ways, etc.). For example, by having fewer ways, fewer resources may be expended to implement overhead for the various ways. In this example, branch target buffer 104 is shown to provide a same number of ways as are provided by branch target buffer 102 (i.e., four ways). It will be understood, however, that these two branch target buffers need not necessarily have the same number of w ays like they do in this example. For instance, branch target buffer 104 could have multiple ways and branch target buffer 102 could have only 1, branch target buffer 104 could have twice as many ways as branch target buffer 102, or the like.

[0098] Another manner in which branch target buffers 102 and 104 are similar is that branch target buffer 104 is likewise addressable by a buffer index that may be extracted from an instruction address that is provided to branch target buffer 104 as an input. In this case, however, it will be understood (as has been mentioned), that the buffer index used by branch target buffer 104 may include more bits than the buffer index used by branch target buffer 102 to allow7for branch target buffer 104 to be larger in capacity (e.g., to allow for more addressable rows of data storage than the smaller branch target buffer allow s). Branch target buffer 104 is also shown to output an entry 604 that incorporates some similar data as entry 504 of branch target buffer 102. For example, entry 604 is shown to include an upper tag 606 for identifying an entry hit (similar to upper tag 506), a branch offset 608 to indicate an exit offset (or branch instruction offset) within the present predict block (similar to branch offset 508), a branch target 610 indicating the target address of the branch instruction (similar to branch target 510), and other data 612 (similar to other data 512).

[0099] Whereas the branch prediction data of entry 504 was indicated as representing an initial or preliminary7prediction, the branch prediction data of entry7604 is shown to represent a final and more reliable prediction (“Final”) of the next branch instruction. For example, this prediction may represent the final knowledge of branch offsets that the system has (though a final target may be pulled from another source such as a call-return stack or another target predictor such as an ITT AGE or the like). In some cases, this final branch prediction data may align and agree with the initial branch prediction data produced by branch target buffer 102. whereas in other cases, there may be disagreement, in which case, the final branch prediction data produced by branch target buffer 104 will be treated as theAtty Docket No. 0120-1100WO1more reliable prediction.

[0100] In spite of the various similarities between branch target buffers 102 and 104. there may also be certain differences. For example, along with being larger and taking more clock cycles to produce branch prediction data, branch target buffer 104 is also shown in FIG.6 to have certain structural differences in its implementation as compared to branch target buffer 102. For example, while each lane 502-0 and 502-1 of branch target buffer 102 was shown to be implemented by a single buffer structure (e.g., a single SRAM buffer, etc.) in FIG. 5, branch target buffer 104 shows that groups of multiple memory structures may be used to implement each lane 602-0 and 602-1 of branch target buffer 104. For example, for lane 602-0. branch target buffer 104 is shown to include a first memory structure 601-0 configured to store tag data (e.g., data that will be output as upper tag 606) and offset data (e.g., data that will be output as branch offset 608), while a second memory structure 603-0 is configured to store target data (e.g., data that will be output as branch target 610). Similarly, for lane 602-1, branch target buffer 104 is shown to include a first memory structure 601-1 configured to store the tag data and offset data, while a second memory structure 603-1 is configured to store the target data.

[0101] One advantage of bifurcating the storage of the various elements to these separate memory' structures is that the different memory' structures can be individually enabled and disabled to save power in accordance with strategies that will now be described. For example, during the accessing of branch prediction data (e.g.. data for the branch target 510 described above), one or more ways may be disabled within memory' structure 603-0 (i.e., the memory' structure storing the branch targets) while all the ways may remain enabled within memory structure 601-0 to allow for upper tags and offsets to be output and examined. In this way, the branch prediction unit 200 (e.g., branch target buffer 104, branch prediction controller 202, or another suitable component) may determine an observed way -hit map 116 for the branch target based on the tag data accessed from memory structure 601-0 as part of accessing the branch prediction data for the branch target 510.

[0102] In other words, even though certain ways may be predicted to not hit for the branch target (based on the predicted way-hit map 112) and, for this reason, may be disabled so as to not consume power during the access of the new branch target 610 from memory structure 603-0, all the ways of memory' structure 601-0 may be enabled at all times to that predicted way-hit map 112 may be checked and verified. If it is discovered, based on tag data read out of memory structure 601-0. that certain ways that were not predicted to hit actually did hit, the data access may be replayed with minimal penalty' and the predicted way-hit mapAtty Docket No. 0120-1100WO1112 may be updated and corrected based on the observed way -hit map 116. More particularly, based on the observed way -hit map 116, the predicted way -hit map 112 may be updated within branch target buffer 102 so that it will more accurately predict which ways will hit the next time branch target 510 is encountered.

[0103] FIG. 7 shows an illustrative timing diagram 700 to illustrate how data may be used and managed in branch target buffers 102 and 104 in accordance with principles described herein. More particularly, timing diagram 700 is shown to illustrate, clock cycle by clock cycle, how way prediction for a branch target buffer of a processor may be performed. In timing diagram 700, clock cycles are represented as columns (labeled ‘CO’, ‘Cl’, ‘C2’, etc.), while branch target buffer access is represented by rows. Since, as described above, both branch target buffers 102 and 104 used for this implementation are multi -lane branch target buffers, two different lanes of the buffers, Lane 0 and Lane 1, are shown to be represented on different rows since these two lanes may perform the same operations on two different predict blocks on the same clock cycle.

[0104] Various branch prediction unit operations that may be performed with respect to particular predict blocks are indicated using labels ‘'Redirect,” '‘Initial,” and '‘Final.” “Redirect” may represent a clock cycle in which a branch prediction unit receives direction to analyze the particular predict blocks indicated, followed by multiple stages of branch prediction that may be performed. More particularly, the cycle after a redirect, “Initial'’ indicates a clock cycle in which an initial prediction is made that may be quick, though possibly less reliable. A final prediction (“Final”) that may take more time but be more reliable may then be made sometime after the initial prediction. In other words, “Redirect” may represent a redirection of both branch target buffers 102 and 104 to investigate a new instruction address at a new predict block. “Initial” may represent an initial prediction made using branch target buffer 102, and “Final” may represent final predictions made using branch target buffer 104.

[0105] In different implementations, the final prediction may take different amounts of time to produce. For instance, the final prediction could come one cycle after the initial prediction, two cycles after, three cycles after, four cycles after, or the like. In some cases, the final prediction may vary within a given implementation based on other factors. For instance, the final prediction relating to one predict block could follow the initial prediction by two clock cycles while the final prediction relating to another predict block could follow the initial prediction by four clock cycles. To illustrate the potential variability of the final prediction while still showing how final predictions may influence (e.g., trigger) redirects andAtty Docket No. 0120-1100WO1new initial predictions and so forth, certain clock cycle after the first few are shown to be abstracted to use variables rather than constants (e.g. ’ Cx '. “Cy”, etc.). Intermediary ellipses (“... ”) are also shown to represent zero or more clock cycles that may occur between the labels. Additionally, “Final” predictions are shown to extend for arbitrary lengths indicating that the prediction is made in that range or later (in examples where the timeline shown by the figure cuts off).

[0106] While any given stage of branch prediction (e.g., Redirect, Initial, or Final) may only be performed for each lane during a given cycle, timing diagram 700 shows that the stages may overlap. For example, at Clock Cycle Cl, an Initial prediction may be generated for the predict blocks identified at the Redirect of Clock Cycle CO (predict blocks A and A+32 in this example), and the results of this Initial prediction may cause the branch target buffers to Redirect for the next clock cycle to analyze different predict blocks in each lane (predict blocks B and B+32 in this example).

[0107] With these notational conventions in mind, timing diagram 700 will now be described in more detail. As shown at Clock Cycle CO, Lane 0 is redirected to analyze predict block A while Lane 0 is redirected to concurrently analyze predict block A+32 (the predict block contiguously following predict block A). At Clock Cycle Cl, Lane 0 is shown to make an Initial prediction (e.g., based on an entry from branch target buffer 102) that a branch instruction will be taken from predict block A to predict block B (notated as A=>B in FIG. 7). Since the branch prediction A=>B is discovered and predicted in Block A by Lane 0, it is irrelevant w hat might be found within predict block A+32 by Lane 1 (since, as a result of the prediction, program flow7will be diverted to predict block B rather than continuing to predict block A+32). As a result of the Initial prediction at Clock Cycle Cl of predict block A, the branch prediction unit may be redirected to predict block B (with Lane 0, assuming that predict block B happens to be an even lane) and to predict block B+32 (with Lane 1). This is shown by the Redirected to analyze predict block B using Lane 0 while also analyzing predict block B+32 using Lane 1.

[0108] At Clock Cycle C2, the Initial stage associated with the Initial prediction for predict block B (made using Lane 0) and the Initial prediction for predict block B+32 (made using Lane 1) is shown to be represented by ellipsis. This notation is intended to indicate that branch target buffer 102 may continue making its quick initial predictions to predict the next branch (if any) from the new target location that is being analyzed. For the purposes of this description, however, this initial prediction is of less interest than the final prediction forAtty Docket No. 0120-1100WO1predict blocks B and B+32 that are being performed by branch target buffer 104. At Clock Cycle Cx, a Final prediction is completed by branch target buffer 104. Examining predict block A, branch target buffer 104 is shown to make a final prediction of a taken branch from predict block A to predict block B (”A^>B (Final)”). In other words, the more accurate Final prediction that branch target buffer 104 is now completing at Clock Cycle Cx is in agreement with the quicker Initial prediction that was made by branch target buffer 102 at Clock Cycle Cl.

[0109] Also during Clock Cycle Cx, branch target buffer 104 may analyze predict block B to determine that certain ways have actually hit for the branch target within branch target buffer 104. Accordingly, an observed way-hit map for predict block B (i.e., “B (Obs. Way-Hit Map)”) and an observed way-hit map for predict block B+32 (i.e., “B+32 (Obs. Way-Hit Map)”) are shown to be determined during this clock cycle and to be fed back to branch target buffer 102 for use in training the entry' that originally indicated the branch from predict block A to the target in predict block B. Specifically, as shown at Clock Cycle Cy, the predicted way -hit maps for predict blocks B and B+32 that are stored in connection with the A=>B entry' in branch target buffer 102 are updated based on the observed way-hit maps (i.e., “A (Update Pr. Way -Hit Map)”).

[0110] Put another way, timing diagram 700 shows that first branch prediction data from branch target buffer 102 (A=>B (Initial)) may correspond to an initial prediction of a taken branch from a first predict block (predict block A) to a second predict block (predict block B). The branch prediction unit may then access, from branch target buffer 104 based on the same instruction address, branch prediction data that corresponds to a final prediction of the taken branch from the first predict block to the second predict block (A=>B (Final)). The updating of the predicted way -hit map within the first branch target buffer may then be performed based on the observed way-hit maps and in response to the final prediction of the taken branch from the first predict block to the second predict block.

[0111] The way prediction illustrated by timing diagram 700 has been described as operating based on different types of way -hit maps. More specifically, a predicted way -hit map has been described as being maintained (e.g.. stored, managed, etc.) by branch target buffer 102 in connection with a particular branch instruction (e.g., a branch from predict blocks A=>B). When the branch target is analyzed by branch target buffer 104, this predicted way -hit map may be used to enable only the ways of the target buffer that may be predicted to hit (while leaving other ways of the target buffer disabled to conserve power). An observedAtty Docket No. 0120-1100WO1way -hit map has then been described as being determined based on what ways are actually observed to hit within branch target buffer 104 for the branch target (since all the ways of the tag buffer may remain enabled for way -hit detection). The observed way-hit map has then been described as being fed back from branch target buffer 104 to branch target buffer 102 to allow the predicted way-hit map to be updated and trained to be more accurate when the same branch target is encountered again in the future.

[0112] Both of these types of way-hit maps may be implemented by a few bits of data that represent the ways supported by branch target buffer 104 on a per lane basis. For example, as mentioned above, if branch target buffer 104 is a multi-lane branch target buffer that includes a first buffer structure associated with a first lane (and addressable using a set of index values) and a second buffer structure associated with a second lane (and addressable using the same set of index values), the predicted way-hit map for this branch target buffer may include w ay-hit predictions for the plurality of w ays in the first lane and for the plurality of ways in the second lane. In an example where the plurality of ways provided by branch target buffer 104 includes a first way, a second way, a third way, and a fourth way (i.e., four ways total in this example), the predicted way-hit map would therefore include, for the first lane: 1) a first way -hit prediction for the first way, 2) a second way -hit prediction for the second way, 3) a third way -hit prediction for the third way, and 4) a fourth way -hit prediction for the fourth way. For the second lane, the predicted way-hit map would then include: 5) a fifth way -hit prediction for the first way, 6) a sixth way -hit prediction for the second way, 7) a seventy way -hit prediction for the third way, and 8) an eighth way -hit prediction for the fourth way. Thus, in total, a two-lane, Pour-way implementation of branch target buffer 104 would be associated with predicted and observed way -hit maps that each include eight total bits.

[0113] To illustrate, FIG. 8A shows certain aspects of an illustrative way-hit map 800 used for way prediction in accordance with principles described herein. Way -hit map 800 is shown to include eight squares each representing a single bit and labeled by lane and way. Specifically, on a top row, each bit is shown to be associated with a first lane ("‘LANE: 0”), whereas, on a bottom row. each bit is shown to be associated with a second lane (“LANE: 1”). From left to right, the columns then reflect the four different ways (“Way: 0”, “Way: 1”, “Way: 2”, and “Way: 3”). As indicated in each box (“Way-Hit Prediction / Observation”), each bit within the map may represent either a way -hit prediction (if way -hit map 800 is implementing a predicted way -hit map) or a way-hit observation (if way -hit map 800 is implementing an observed way-hit map). Each bit may either be TRUE (e.g., represented byAtty Docket No. 0120-1100WO1a ‘ 1’ and signifying that the represented way of that lane is predicted (observed to hit) or unknown (such that all ways are to be enabled)) or FALSE (e.g., represented by a 'O' and signifying that the represented way of that lane is predicted or observed to not hit). As such, TRUE predictions may cause the corresponding ways to be enabled while FALSE predictions may cause the corresponding ways to be disabled.

[0114] In many circumstances (e.g., once program flow has gone through a section of code and the branch target buffers have had a chance to populate and be trained to some extent), it may be the case that a predicted way -hit map and an observed way-hit map for a particular address will match one another perfectly. This would be an ideal result and would require no updates to be made to the predicted way -hit map. However, for a variety of reasons (e.g.. code has not yet been traversed, user input changes the circumstances, etc.), it will not always be the case that an observed way-hit map matches the predicted way-hit map. In these cases where there is a mismatch between the observed and predicted way -hit maps, there are two possibilities.

[0115] For the first possibility, it may be determined that a first set of way hits indicated by the predicted way-hit map is a superset of a second set of way hits indicated by the observed way-hit map. This will be referred to as a superset mismatch and is illustrated in FIG. 8B by an illustrative predicted way-hit map 112-B and an illustrative observed way -hit map 116-B. As shown, in a superset mismatch, the only bits of way -hit data that are observed to be TRUE are also predicted to be TRUE, such that there is no way that is predicted FALSE that then turns out to be TRUE. The result of this type of superset mismatch is that more ways may be enabled than was strictly necessary, wasting a bit of powder. More specifically, Ways 1 and 3 of Lane 0 (shown using a different type of cross-hatching than other FALSE ways) would have been enabled for the accessing of the second branch prediction data (due to these bits being TRUE in the predicted data) even though it turns out that they did not need to be. To remedy this undesirable power consumption, an updating of the predicted way-hit map may be performed to conserve the pow er next time the second branch prediction data is accessed. However, in this case, there is no branch prediction penalty, since every relevant way was indeed enabled and powered on for the access in the branch target buffer 104.Accordingly, the updating of the predicted way-hit map may be performed without replaying the accessing of the second branch prediction data using the updated predicted way -hit map.

[0116] In contrast, for the second possibility, it may be determined that a first set of way hits indicated by the predicted way -hit map is a subset of a second set of way hits indicated by the observed way -hit map. This will be referred to as a subset mismatch and isAtty Docket No. 0120-1100WO1illustrated in FIG. 8C by an illustrative predicted way -hit map 112-C and an illustrative observed way-hit map 116-C. As shown, in a subset mismatch, there is at least one bit of way-hit data that is observed to be TRUE but that was predicted to be FALSE (i.e., the bit predicted for Lane 1 and Way 3 and shaded in black in illustrative predicted way-hit map 112-C). The result of this ty pe of subset mismatch is more problematic than with the superset mismatch described above. In this example, too, there could be certain ways that were enabled and were not needed, again wasting a bit of power. This is the case, for example, for the bit in Lane 0 and Way 1. But even more consequently, the bit that was predicted to be FALSE and turned out to be TRUE (i.e., the bit in Lane 1 and Way 3) would signify a way storing relevant information but that was not enabled, such that relevant branch prediction data stored therein would have been missed. Accordingly, along with updating of the predicted way -hit map to properly enable the relevant ways and to conserve the power next time the second branch prediction data is accessed, an additional action may also be performed to mitigate a branch prediction penalty that would otherwise accrue due to the misprediction. Specifically, the updating of the predicted way-hit map, in this subset case, may be performed in connection with replaying the accessing of the second branch prediction data using the updated predicted way-hit map (or, in some examples, by enabling all the ways). In other words, before or after the predicted way-hit map is updated such that the wayhit prediction for Lane 1 and Way 3 is TRUE, branch target buffer 104 may be accessed again with the same address instruction so that the proper ways can be enabled, and the proper entries will be identified within the buffer.

[0117] FIGS. 7 and 8A-8C have been described to indicate how way prediction for a branch target buffer may be carried out with respect to a singular branch prediction (e.g., a branch instruction from predict block A=>B). As has been mentioned, certain branch target buffers may also be configured to support pairs of branches whose branch prediction data shares a single entry in each branch target buffer. For example, a trampoline branch pair refers to a set of branch instructions in the form A=>B=>C, where the branch from A=>B is referred to as a primary branch of the trampoline branch pair and the branch from B=>C is referred to as a secondary branch of the trampoline branch pair.

[0118] Certain training procedures (largely outside the scope of this disclosure) may be implemented to keep track of how often a candidate secondary branch is predicted to follow a candidate primary branch during program execution. If these two branches are predicted together only occasionally, they may be worth keeping tabs on, but it may beAtty Docket No. 0120-1100WO1undesirable (due to potential performance costs from branch mispredictions) to treat the two branches as a trampoline branch pair in the branch target buffer. Accordingly, a validation procedure may be put in place that allows a branch prediction unit to determine when a potential trampoline branch pair A=>B=>C should be validated (e.g., treated as a trampoline branch pair by operating with an assumption that the secondary branch from B=>C definitely or is likely to immediately follow the primary branch A=>B) and when the potential trampoline branch pair should be invalidated (e.g., treated by the branch prediction unit as two individual branches from A=>B and B=>C without any assumption that one is connected to the other).

[0119] Special way prediction considerations may be given to validated and invalidated trampoline branch pairs when they are encountered in implementations that support them. Accordingly, FIGS. 9A-9C will now be described to illustrate how way prediction for branch target buffers may be carried out with respect to trampoline branch pairs.

[0120] FIG. 9A shows certain aspects of an illustrative validated branch pair that may be represented in branch target buffers in accordance with principles described herein. More particularly, FIG. 9A shows several predict blocks 302 labeled as Block X. Block X+32 (which is shown to be contiguous and immediately following Block X in memory), Block Y (which, as illustrated with an ellipsis, is non-contiguous with Block X or Block X+32), and Block Z (which, as again illustrated with an ellipsis, is non-contiguous with the other predict blocks). Within the various predict blocks 302, several instructions are specifically called out as instructions 902-1 and 902-2 (in Block X), instructions 902-3 and 902-4 (in Block Y) and instruction 902-5 (in Block Z). It will be understood that each of the predict blocks in this example are 32-byte predict blocks that can store eight 4-byte (32-bit) instructions. Hence, the instructions explicitly labeled will be understood to not represent all the instructions included in the predict blocks 302. Additionally, as has been mentioned, it will be understood that the 4-byte instructions and 32-byte predict blocks used for implementations described herein are provided only by way of illustration and that other implementations may use instructions and predict blocks of other suitable sizes.

[0121] Instruction 902-1 within Block X will be understood to represent the current location of a Program Counter that may be used to track program flow through memory. For example, instruction 902-1 could represent a first instruction to be executed after a reset has been signaled or program flow may have arrived at instruction 902-1 in another suitable wayAtty Docket No. 0120-1100WO1(e.g., from an earlier branch instruction not shown, sequentially from a previous instruction, etc.). In any case, instruction 902-1 will be understood to represent a current instruction from which a branch prediction unit will start analyzing and predicting upcoming instructions.

[0122] Instruction 902-2 within Block X is then shown to be associated with a branch pair that includes a primary' branch and a secondary branch. In other words, instruction 902-2 may be a branch instruction that targets instruction 902-3 in Block Y. and, since Block Y has also been observed to include another branch instruction at instruction 902-4 (which targets instruction 902-5 in Block Z), branch prediction data representing the entire branch pair may be stored in connection with instruction 902-2. More particularly, program flow after branch instruction 902-2 may be predicted to follow- taken path 904-1, which, as shown, diverts the program flow from instruction 902-2 to the target at instruction 902-3. Then, at instruction 902-4, a conditional branch instruction may either go sequential, such that program flow may follow a sequential path 904-2S to the next instruction in Block Y, or may be taken, such that program flow' may follow7a taken path 904-2T to instruction 902-5 in Block Z.

[0123] Dashed arrows from taken path 904-1 and taken path 904-2T are illustrated to be represented by a branch pair 906-A, which, as described above, may be notated herein as X=>Y=>Z. While this example describes a conditional branch pair (i.e., a trampoline branch having a secondary branch Y=>Z that is conditional, as shown by the possibility of sequential path 904-2S), it will be understood that an unconditional branch pair, in which the secondary branch Y=>Z is taken unconditionally, yvould make the trampoline branch pair more straightforyvard, since there yvould be virtually no chance of program flow' following sequential path 904-2S and it could be assumed, whenever instruction 902-2 is predicted to be taken, that instruction 902-4 will also be taken (always following taken path 904-2T). It yy ill also be understood, as labeled in FIG. 9A, that branch pair 906-A is a validated trampoline branch pair. In other words, the pairing of the primary branch (at instruction 902-2) and the secondary branch (at instruction 902-4) will be understood to have been predicted and observed sufficiently in this case to treat branch pair 906-A as a validated trampoline branch pair.

[0124] Beloyv the predict blocks 302 in FIG. 9A, a timing diagram 908-A is shoyvn to illustrate, cycle by cycle, how multi-lane branch prediction may be performed for the validated conditional branch pair 906-A. Timing diagram 908-A uses a similar notation as described above for timing diagram 700, including, for example, clock cycles represented as columns (labeled ‘CO’, ‘Cl’, ‘C2’, etc.), different lanes of the buffer (Lane 0 and Lane 1)Atty Docket No. 0120-1100WO1represented on rows with respect to branch prediction stages (Redirect, Initial, Final, etc.), and so forth.

[0125] As shown at Clock Cycle CO, Lane 0 may be redirected to analyze Block X while Lane 1 is redirected to concurrently analyze Block X+32. At Clock Cycle Cl, Lane 1 is shown to make an Initial prediction of validated branch pair 906-A, which, as described above, indicates both: 1) the primary branch X=>Y (which is predicted to follow taken path 904-1), and 2) the conditional secondary branch Y=>Z (which may either follow sequential path 904-2S if not taken, or may follow taken path 904-2T if taken). Since the branch pair 906-A is discovered and predicted in Block X by Lane 0, it is irrelevant what might be found within X+32 by Lane 1 (since program flow will be diverted away from Block X+32 by taken path 904-1). As a result of the Initial prediction of branch pair 906-A in Clock Cycle Cl, the branch prediction unit may be redirected to handle both possibilities of the conditional secondary branch in the next cycle. This is shown by the Redirect in Clock Cycle C 1 being configured to analyze Block Y using Lane 0 (in the event that instruction 902-4 goes sequential as shown by sequential path 904-2S) while also analyzing Block Z using Lane 1 (in the event that instruction 902-4 is taken and program flow follows taken path 904-2T).

[0126] At Clock Cycle C2, Lane 0 analyzes Block Y to make an initial prediction 910-1, while Lane 1 analyzes Block Z to make an initial prediction 910-2. These initial predictions may be made, for example, using branch target buffer 102, as has been described. Initial prediction 910-1 may predict instructions from instruction 902-3 through the rest of Block Y (assuming no further branch instructions in Block Y) while initial prediction 910-2 may predict instruct ons from instruction 902-5 through the rest of Block Z (assuming no further branch instructions in Block Z). Later, during a Clock Cycles Cx, the Final stage of the branch prediction may then be performed (e.g., using branch target buffer 104) to generate a final prediction 912-1 with respect to Block Y and a final prediction 912-2 with respect to Block Z. Based on predicted way -hit maps provided by branch target buffer 102 in the manner described above, the final predictions may be made while only predicted ways are enabled and other ways of branch target buffer 104 are left disabled to conserve pow er. However, as will be described below', certain provisions may be made to avoid way mispredictions to which trampoline branch pairs may be especially susceptible.

[0127] As has been described, the final predictions 912-1 and 912-2 may be more accurate and reliable than the initial predictions, such that the proper instruction addressesAtty Docket No. 0120-1100WO1may at this point be added to the fetch target queue (FTQ) to be fetched by a fetch unit. For example, if the final predictions indicate that instruction 902-4 will be taken, the predicted instruction addresses in Block Z will be added to the FTQ and the predicted instruction addresses in Block Y after instruction 902-4 will be discarded. Conversely, if the final predictions indicate that instruction 902-4 will go sequential (i.e. , not be taken), the predicted instruction addresses in Block Y after instruction 904-4 will be added to the FTQ and the predicted instructions in Block Z will be discarded. Conversely, predicted instruction addresses could instead be added earlier to the FTQ and then removed from the queue (prior to actually being fetched) in accordance with the final predictions as they come in.

[0128] FIG. 9B shows certain aspects of an illustrative invalidated branch pair that may be represented in branch target buffers in accordance with principles described herein. More particularly, similar to FIG. 9A, FIG. 9B shows several predict blocks 302 labeled as Block X, Block X+32 (which is shown to be contiguous and immediately following Block X in memory), Block Y (which, as illustrated with an ellipsis, is non-contiguous with Block X or Block X+32), Block Y+32 (which is shown to be contiguous and immediately following Block Y in memory), and Block Z (which, as again illustrated with an ellipsis, is noncontiguous with the other predict blocks). Within the various predict blocks 302, the same instructions 902-1 through 902-5 are specifically called out described above in relation to FIG. 9A.

[0129] While the same candidate primary branch from X=>Y (i.e., branch instruction 902-2) and the same candidate secondary branch from Y^Z (i.e., conditional branch instruction 902-4) are shown in FIG. 9B to be tracked as a trampoline branch pair 906-B, in this case, the trampoline branch pair 906-B is shown to be invalidated (rather than validated, as was the case with trampoline branch pair 906- A). As such the branch pair may be tracked as a candidate but is not currently enabled for use as a trampoline branch pair and is thus notated using parenthesis to show that the secondary' branch is still being tracked and considered: X=>Y(=>Z).

[0130] Below the predict blocks 302 in FIG. 9B, a timing diagram 908-B is shown to illustrate, cycle by cycle, how multi-lane branch prediction may be performed for the invalidated conditional branch pair 906-B. Timing diagram 908-B uses a similar notation as described above for timing diagrams 700 and 908-A, including, for example, clock cycles represented as columns (labeled 'O’, ‘1’, ‘2’, etc.), different lanes of the buffer (Lane 0 and Lane 1) represented on rows with respect to branch prediction stages (Redirect, Initial, Final,Atty Docket No. 0120-1100WO1etc.), and so forth.

[0131] As shown at Clock Cycle CO, Lane 0 may be redirected to analyze Block X while Lane 1 is redirected to concurrently analyze Block X+32. At Clock Cycle Cl, Lane 1 is shown to make an Initial prediction of invalidated branch pair 906-B. While the trampoline branch pair is being tracked and considered for validation (or revalidation), however, the invalid status of branch pair is such that the secondary branch Y=>Z is not actually to be treated as being paired with the primary branch X=>Y in this example. In other words, invalidated branch pair 906-B is currently equivalent to a singular branch instruction X=>Y. Accordingly, as shown, since the branch X=>Y indicated by invalidated branch pair 906-B is discovered and predicted in Block X by Lane 0, it is irrelevant what might be found within X+32 by Lane 1 (since program flow will be diverted away from Block X+32 by taken path 904-1). Then, as a result of the Initial prediction of invalidated branch pair 906-B in Clock Cycle Cl, the branch prediction unit may be redirected to analyze Block Y using Lane 0 (making the Initial prediction 910-1 and the Final prediction 912-1 at Clock Cycle Cx, which is sometime after Clock Cycle C2) while also analyzing Block Y+32 using Lane 1 (making an Initial prediction 910-3 and a Final prediction 912-3 at Clock Cycle Cx). In this example, due to the invalidated state of the candidate branch pair 906-B (e.g., due to the fact that it is not actually being treated as a branch pair at this time), Block Z will not be not analyzed unless there is a redirection to predict block Z (e.g., instruction 902-4 is predicted to be taken) (not shown in FIG. 9B).

[0132] Having laid out the potential scenarios for a validated trampoline branch pair and an invalidated branch pair in FIGS. 9A and 9B. FIG. 9C shows certain aspects of how these validated and invalidated branch pairs may be handled when performing way prediction for the branch target buffer in accordance with principles described herein.

[0133] As shown in the top half of FIG. 9C, a predicted w ay-hit map 112-V1 (‘V’ for “Validated7’) corresponds to a scenario when the branch pair X=>Y=>Z is validated (e.g.. branch pair 906-A as shown in FIG. 9A), while a predicted way -hit map 112-11 (‘F for “Invalidated”) corresponds to a scenario when the branch pair is invalidated or not yet validated (e.g., branch pair 906-B as shown in FIG. 9B). In some cases, the same branch pair can toggle between these states as more final predictions and observations are received during program execution and continuous tracking and training of the branch target buffers is performed. A technical problem arises, how ever, when the branch pair goes back and forth between being validated and invalidated. As shown, while the way -hit predictions associatedAtty Docket No. 0120-1100WO1with Lane 0 (predicting ways associated with predict block Y) remain consistent between the validated and invalidated cases, the way -hit predictions associated with Lane 1 (predicting ways associated with predict block Z in the validated case and with predict block Y+32 in the invalidated case) change for the validated and invalidated cases. In other words, as shown. Lane 0 predictions on the top row stay the same in predicted way -hit map 112-V 1 and predicted way -hit map 112-11 while the Lane 1 predictions on the bottom row change between predicted way -hit map 112-V 1 and predicted way -hit map 112-11. The technical problem is that this inconsistency may lead to way mispredictions (and associated performance penalties such as replays) for Lane 1 when the state of the trampoline branch pair goes between being validated and invalidated.

[0134] At least one technical solution to address this problem involves determining that first branch prediction data (e.g., accessed from branch target buffer 102) is associated with a trampoline branch pair that includes a primary branch from a first predict block (e.g., predict block X) to a second predict block (e.g., predict block Y) and a secondary branch from the second predict block (e.g., predict block Y) to a third predict block (e.g., predict block Z). In this example, the branch target of the first branch prediction data would indicate the second predict block (e.g., predict block Y) and the second predict block would be associated with the first lane (e.g., Lane 0). In response to this determination that the first branch prediction data is associated with the trampoline branch pair, the branch prediction unit may modify the way -hit predictions for the plurality of ways in the second lane (e.g., Lane 1). Specifically, as shown in the bottom half of FIG. 9C by a predicted way-hit map 112-V2 representing the validated branch pair X=>Y=>Z and a predicted way-hit map 112-12 representing the invalidated (or not yet validated) branch pair, the way -hit predictions for the entirety of Lane 1 (the entire bottom row) may be set to TRUE so that all of the ways will be enabled and there will be no risk of a subset misprediction. In other words, the way-hit prediction disabling may be turned off for this scenario, which may trade some lost opportunity to conserve power for a total elimination of risk that a relevant way will be disabled and lead to a performance penalty such as a replay when a way that would have hit was disabled.

[0135] In some examples, this modifying of the way-hit predictions for the plurality of ways in the second lane (e.g., the modifying to set all the way -hit predictions for Lane 1 to TRUE) may be performed in response to identifying a modification of a validation state of the trampoline branch pair. In other words, when it is determined that the branch pairAtty Docket No. 0120-1100WO1switches from a validated state (e.g.. branch pair 906-A) to an invalidated state (e.g., invalidated branch pair 906-B) or vice versa, this change may automatically trigger the modification of the way -hit predictions in the proper lane (Lane 1 in this example).

[0136] FIG. 10 shows illustrative method 1000 for way prediction for a branch target buffer of a processor in accordance with principles described herein. The operations of method 1000 may be performed by (e.g., under the direction of) an implementation of branch prediction unit 200 and / or other branch prediction units or functional units of processor front ends described herein (e.g., by branch prediction controller 202 as shown in FIG. 2 above). While FIG. 10 shows illustrative operations according to a specific implementation, it will be understood that other implementations of this method may omit, add to, reorder, and / or modify any of operations that are explicitly represented in FIG. 10. Additionally, while these operations are illustrated with arrows suggestive of a sequential order of operation, it will be understood that one or more of the operations may be performed concurrently (e.g., in parallel) with one another. Each of the operations of method 1000 will now be described in more detail.

[0137] At operation 1002, a branch prediction controller of a branch prediction unit within a processor may determine an instruction address. For example, the instruction address may be associated with a program counter that points to memory addresses during program execution. In some cases, the determination of the instruction address could be performed in response to a reset or the initialization of a new program or subroutine. In other cases, the instruction address may be arrived at based on a branch from another location or based on sequential execution of instructions from a preceding memory address.

[0138] At operation 1004, the branch prediction controller may access first branch prediction data from a first branch target buffer (e.g., a relatively small capacity and low-latency branch target buffer such as branch target buffer 102). For example, the access of the first branch prediction data may be performed based on the instruction address, such as by providing the instruction address (or certain bits thereof) to the first branch target buffer and receiving the first branch prediction data as output from the first branch target buffer in response. The first branch target buffer may include at least a branch offset, a branch target, and a predicted way-hit map for the branch target in a second branch target buffer. For example, the second branch target buffer may be a relatively large capacity and higher-latency branch target buffer (e.g., branch target buffer 104) that provides a plurality' of ways and stores second branch prediction data corresponding to the branch target.

[0139] At operation 1006, the branch prediction controller may access the secondAtty Docket No. 0120-1100WO1branch prediction data from the second branch target buffer based on the branch target accessed in the first branch prediction data at operation 1004. Additionally, based on the predicted way -hit map accessed in the first branch prediction data at operation 1004, the accessing of the second branch prediction data at operation 1006 may be performed with at least one way of the plurality of ways of the second branch target buffer being disabled or powered down. It will be understood that all the ways may be enabled in certain scenarios (as has been described), but to achieve the power savings and other benefits described herein, method 1000 refers to a scenario in which all the ways are not powered up and at least one is powered down (disabled).

[0140] Along with the predicted way-hit map being used by the second branch target buffer to disable certain ways for the accessing of the second branch prediction data from the second branch target buffer, method 1000 may further include training operations that facilitate generating and managing, within the first branch target buffer, the predicted way -hit map that is used at operation 1006. To this end, the second branch target buffer may include a first memory structure (e.g., a first SRAM buffer) configured to store tag data and a second memory structure (e.g., a separate and distinct SRAM buffer) configured to store target data. This may allow for the at least one way of the plurality of ways to be disabled (as described in relation to operation 1006) within the second memory' structure while all the ways may remain enabled within the first memory structure during the accessing of the second branch prediction data. As has been described, this bifurcation of the storage of different parts of the second branch prediction data (e.g., the tag data and the target data) may allow for power to be conserved (by disabling ways that are not predicted to hit in the target memory' structure) while also identifying any way misprediction (by leaving the ways of the tag memory' structure enabled) so that it can be remedied.

[0141] More particularly, at operation 1008, the branch prediction unit (e.g., the branch prediction controller or the second branch target buffer, etc.) may determine an observed way -hit map for the branch target based on the tag data accessed from the first memory structure as part of accessing the second branch prediction data. Assuming that the observed way -hit map matches the predicted yvay-hit map (‘"Observed and Predicted Way -Hit Maps Match”), this iteration of method 1000 may be complete and may begin again with a neyv instruction address. Hoyvever, if there is disagreement betyveen the observed yvay-hit map and the predicted way-hit map (e.g., the yvay-hit maps are determined to not perfectly match), method 1000 may continue to operation 1010.

[0142] At operation 1010, the branch prediction unit may update the predicted way-Atty Docket No. 0120-1100WO1hit map, within the first branch target buffer, based on the observed way-hit map. For example, since a mismatch between the observed way -hit map and the predicted way -hit map was detected, the predicted way-hit map may be updated to match the observed way -hit map so that it will be more accurate the next time a prediction for this branch target is called for.

[0143] Additionally, in connection with the updating of operation 1010, method 1000 shows that an operation 1012 may be performed to determine which type of way -hit mismatch (e.g., a superset mismatch or a subset mismatch) has been detected. If operation 1012 results in determining that a first set of way hits indicated by the predicted way -hit map is a superset of a second set of way hits indicated by the observed way -hit map (i.e., there is a superset mismatch), a replay indicator 1014-1 indicates that the updating of the predicted way -hit map may be performed without replaying the accessing of the second branch prediction data using the updated predicted way-hit map (i.e., “No replay of second branch prediction data access”). Conversely, if operation 1012 results in determining that a first set of way hits indicated by the predicted way -hit map is a subset of a second set of way hits indicated by the observed way-hit map (i.e., there is a subset mismatch), a replay indicator 1014-2 indicates that the updating of the predicted way-hit map may be performed in connection with replaying the accessing of the second branch prediction data using the updated predicted way-hit map (i.e., “Replay second branch prediction data access”).

[0144] Various hardware components have been mentioned and described as part of the implementation of way prediction for a branch target buffer of a processor such as may be used to perform method 1000. For example, a branch prediction unit within a processor front end has been described as performing the operations of method 1000, while other functional structures and units have been mentioned or alluded to. To further illustrate the context in which a branch prediction unit may operate. FIG. 11 shows certain aspects of an illustrative processor 1100 in which branch prediction unit 200 may be implemented in accordance with principles described herein. More particularly, processor 1100 in FIG. 11 may represent a CPU or other suitable microprocessor and may include a front end 1102, a back end 1104, and additional functional units as may be implemented therein.

[0145] In FIG. 11, front end 1102 is shown to include branch prediction unit 200, a fetch unit 1106 that includes a fetch target queue 1108, and other units 1110. Branch prediction unit 200 is shown to be in communication with fetch unit 1106, and more particularly, with fetch target queue 1108, where branch prediction unit 200 may indicate upcoming instructions that are predicted to be executed and thus need to be fetched by fetch unit 1106. Fetch unit 1106 is shown to be in communication with an instruction cache / Atty Docket No. 0120-1100WO1memory' (that will be understood to store instructions such as those represented by the program layouts 300-A or 300-B described in relation to FIGS. 3A and 3B). The details of how data is cached from memory to be closer to the functional units of processor 1100 are beyond the scope of this disclosure, though it will be understood that a main memory and one or more levels of storage caches may be provided from which instructions are fetched. Once a set of instructions has been predicted (e.g., by branch prediction unit 200), fetched (e.g., by fetch unit 1106). and otherwise prepared (e.g.. decoded, assessed, etc., by other units 1110), front end 1102 passes the instructions to back end 1104, as represented by an output 1112 of front end 1102.

[0146] As has been described, one role of a processor front end (such as front end 1102) is to provide (e.g.. queue up) upcoming instructions for a back end (such as back end 1104) as an execution pipeline in the back end executes the instructions. To avoid unnecessary delays (e.g., pipeline stalls), it is desirable for the front end to stay ahead of the back end and keep the instruction queue the back end is working from as full as possible with the instructions that are to be executed. One challenge associated with this role is that branching instructions divert program flow in ways that can be unpredictable (or at least uncertain and difficult to accurately predict) prior to the instructions (and possibly other instructions preceding them) being executed.

[0147] In spite of the uncertainty inherent in a given set of program instructions, branch prediction unit 200 is configured to use a branch target buffer and / or other resources to make predictions about upcoming instructions that are to be executed, even before all the information needed to determine which instructions are executed is known (e.g., even before certain registers have been written, before feedback has been received from the back end as to results of other instructions on which the branching depends, etc.). To this end. one or more branch target buffers (included in branch prediction unit 200 as shown above, though not explicitly shown in FIG. 11) may be used to track branching that has been taken and not taken in previous traversals through the code (e.g., since training of the branch target buffers, as described herein, may be performed continuously as code is executed). In operation, then, branch prediction unit 200 may be configured to predict, based on the data received from the branch target buffer, a set of instructions that are to be executed by the back end of the processor. As has been described, branch prediction unit 200 may be configured such that this predicted set of instructions (represented by addresses of the instructions written to fetch target queue 1108) can include a plurality of taken branches.

[0148] An indication of the set of instructions predicted by branch prediction unit 200Atty Docket No. 0120-1100WO1(e.g., addressing information for the predicted instructions, etc.) may be delivered to the fetch target queue 1108 of fetch unit 1106. Fetch target queue 1108 may be configured to store information for instructions that are to be fetched by fetch unit 1106 but have not necessarily been fetched yet. Accordingly, branch prediction unit 200 may write to fetch target queue 1108 and then fetch unit 1106 may use fetch target queue 1108 when accessing the instruction cache or memory to determine which instructions are to be fetched. By writing addresses of predicted instructions to fetch target queue 1108, branch prediction unit 200 may guide or direct fetch unit 1106 to fetch these predicted instructions at their respective addresses in the instruction cache, and the fetched instructions can then be further processed in other units 1110 (e.g., decoded, ordered and arranged, etc.) as necessary before being provided, by way of output 1112, for execution by back end 1104.

[0149] As shown in FIG. 11, front end 1102 may be in communication with back end 1104, which may include an instruction queue 1114 that is accessed by execution pipeline 1116 to execute instructions queued up therein. While not explicitly shown, it will be understood that one or more additional units (e.g.. other units 1118) could also be included between instruction queue 1114 and execution pipeline 1116. For example, instruction queue 1114 could be implemented as a micro-op queue that stores not only full instructions that have been fetched but also sub-instructions (micro-ops) into which certain full instructions are divided. Accordingly, in an example that breaks certain instructions into micro-ops associated with sub-tasks for those instructions, additional logic between instruction queue 1 114 and execution pipeline 1116 may be used to convert between instructions and micro-ops or to otherwise manage and prepare instructions for execution by the execution pipeline.

[0150] As shown, front end 1102 may, via output 1112, provide instructions to be executed by execution pipeline 1116. More particularly, front end 1102 may try to keep instruction queue 1114 as full as possible as execution pipeline 1116 removes and executes the instructions coming into the queue. Along with execution pipeline 1116 and instruction queue 1114, back end 1104 is shown to also include other units 1118 that may be configured to perform various other functions and roles outside the scope of the implementations described herein. Additionally, certain feedback 1120 is shown to be provided (e.g., during execution, during time frames when instructions are retired or committed, etc.) from back end 1104 to front end 1102 to provide information about results of executed instructions, including w hich branches are taken and not taken, w here the branch targets of taken branches go, and so forth. This feedback may be accounted for in the management and training of the branch target buffer in ways that have been described.Atty Docket No. 0120-1100WO1

[0151] As has been mentioned, various methods and processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices. In general, a processor (e.g., a microprocessor) receives instructions, from a non-transitory computer-readable medium (e.g., a memory, etc.), and executes those instructions, thereby performing one or more operations such as the operations described herein. Such instructions may be stored and / or transmitted using any of a variety of known computer-readable media.

[0152] A computer-readable medium (also referred to as a processor-readable medium) includes any non-transitory medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including, but not limited to, non-volatile media, and / or volatile media. Non-volatile media may include, for example, optical or magnetic disks and other persistent memory. Volatile media may include, for example, dynamic random-access memory (DRAM), which typically constitutes a main memory'.

[0153] FIG. 12 shows an illustrative computing device 1200 that may use or implement apparatuses (e.g., branch prediction units, front ends, processors, CPUs, etc.) described herein. As show n in FIG. 12, computing device 1200 may include a communication interface 1202, a processor 1204 (which may represent an implementation of processor 1100 with a front end such as front end 1102 or any implementation thereof), a storage device 1206. and an input / output (I / O) module 1208 communicatively connected via a communication infrastructure 1210. While an illustrative computing device 1200 is shown in FIG. 12, the components illustrated in FIG. 12 are not intended to be limiting. Additional or alternative components may be used in other embodiments. Components of computing device 1200 shown in FIG. 12 will now be described in additional detail.

[0154] Communication interface 1202 may be configured to communicate with one or more computing devices. Examples of communication interface 1202 include, without limitation, a wired network interface (such as a netw ork interface card), a wireless netw ork interface (such as a wireless network interface card), a modem, an audio / video connection, and any other suitable interface.

[0155] Processor 1204 generally represents any type or form of processing unit capable of processing data or interpreting, executing, and / or directing execution of one or more of the instructions, processes, and / or operations described herein. Processor 1204 may direct execution of operations in accordance with one or more applications 1212 or other computer-executable instructions such as may be stored in storage device 1206 or anotherAtty Docket No. 0120-1100WO1computer-readable medium.

[0156] Storage device 1206 may include one or more data storage media, devices, or configurations and may employ any type, form, and combination of data storage media and / or device. For example, storage device 1206 may include, but is not limited to, a hard drive, network drive, flash drive, magnetic disc, optical disc, RAM, dynamic RAM, other non-volatile and / or volatile data storage units, or a combination or sub-combination thereof. Electronic data, including data described herein, may be temporarily and / or permanently stored in storage device 1206. For example, data representative of one or more executable applications 1212 configured to direct processor 1204 to perform any of the operations described herein may be stored within storage device 1206. In some examples, data may be arranged in one or more databases residing within storage device 1206.

[0157] I / O module 1208 may include one or more I / O modules configured to receive user input and provide user output. One or more I / O modules may be used to receive input for a single virtual experience. I / O module 1208 may include any hardware, firmware, software, or combination thereof supportive of input and output capabilities. For example, I / O module 1208 may include hardware and / or software for capturing user input, including, but not limited to, a keyboard or keypad, a touchscreen component (e.g., touchscreen display), a receiver (e.g., an RF or infrared receiver), motion sensors, and / or one or more input buttons.

[0158] I / O module 1208 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers. In certain embodiments, I / O module 1208 is configured to provide graphical data to a display for presentation to a user. The graphical data may be representative of one or more graphical user interfaces and / or any other graphical content as may sen e a particular implementation.

[0159] The following examples describe implementations of way prediction for a branch target buffer of a processor in accordance with principles described herein.

[0160] Example 1: A method comprising: determining, by a branch prediction controller within a processor, an instruction address; accessing, from a first branch target buffer and based on the instruction address, first branch prediction data that includes a branch offset, a branch target, and a predicted way -hit map for the branch target in a second branch target buffer, the second branch target buffer providing a plurality of ways and storing second branch prediction data corresponding to the branch target; and accessing, from the second branch target buffer and based on the branch target, the second branch prediction data, theAtty Docket No. 0120-1100WO1accessing of the second branch prediction data being performed while at least one way of the plurality of ways is disabled based on the predicted way-hit map.

[0161] Example 2: The method of any of the preceding examples, wherein: the second branch target buffer includes a first memory structure configured to store tag data and a second memory' structure configured to store target data; during the accessing of the second branch prediction data, the at least one way of the plurality of ways is disabled within the second memory structure while remaining enabled within the first memory structure; and the method further comprises: determining an observed way -hit map for the branch target based on the tag data accessed from the first memory structure as part of accessing the second branch prediction data, and updating, within the first branch target buffer, the predicted wayhit map based on the observed way -hit map.

[0162] Example 3: The method of any of the preceding examples, further comprising determining that a first set of way hits indicated by the predicted way -hit map is a superset of a second set of way hits indicated by the observed way-hit map; wherein the updating of the predicted way -hit map is performed without replaying the accessing of the second branch prediction data using the updated predicted way-hit map.

[0163] Example 4: The method of any of the preceding examples, further comprising determining that a first set of way hits indicated by the predicted way -hit map is a subset of a second set of way hits indicated by the observed way-hit map; wherein the updating of the predicted way -hit map is performed in connection with replaying the accessing of the second branch prediction data using the updated predicted way -hit map.

[0164] Example 5: The method of any of the preceding examples, wherein: the first branch prediction data corresponds to an initial prediction of a taken branch from a first predict block to a second predict block; the method further comprises accessing, from the second branch target buffer and based on the instruction address, third branch prediction data that corresponds to a final prediction of the taken branch from the first predict block to the second predict block; and the updating of the predicted way-hit map within the first branch target buffer is performed in response to the final prediction of the taken branch from the first predict block to the second predict block.

[0165] Example 6: The method of any of the preceding examples, wherein: the second branch target buffer is a multi-lane branch target buffer that includes: a first buffer structure associated with a first lane and addressable using a set of index values, and a second buffer structure associated with a second lane and addressable using the set of index values; and the predicted way-hit map includes way-hit predictions for the plurality of ways in theAtty Docket No. 0120-1100WO1first lane and for the plurality' of ways in the second lane.

[0166] Example 7: The method of any of the preceding examples, further comprising: determining that the first branch prediction data is associated with a trampoline branch pair that includes a primary branch from a first predict block to a second predict block and a secondary branch from the second predict block to a third predict block, the branch target indicating the second predict block and the second predict block being associated with the first lane; and modifying, in response to the determining that the first branch prediction data is associated with the trampoline branch pair, the way-hit predictions for the plurality of ways in the second lane.

[0167] Example 8: The method of any of the preceding examples, wherein the modifying of the way-hit predictions for the plurality of ways in the second lane is further performed in response to identifying a modification of a validation state of the trampoline branch pair.

[0168] Example 9: The method of any of the preceding examples, wherein the multilane branch target buffer includes one or more additional lanes beyond the first lane and the second lane.

[0169] Example 10: The method of any of the preceding examples, wherein: the plurality of ways provided by the second branch target buffer includes a first way, a second way, a third way, and a fourth way; and the predicted way-hit map includes a first way-hit prediction for the first way, a second way-hit prediction for the second way, a third way -hit prediction for the third way, and a fourth way -hit prediction for the fourth way.

[0170] Example 11 : The method of any of the preceding examples, wherein the plurality of w ays provided by the second branch target buffer includes one or more additional ways beyond the first way. the second way, the third way, and the fourth way.

[0171] Example 12: The method of any of the preceding examples, w herein the first branch target buffer provides a same number of ways as are provided by the second branch target buffer in the plurality of ways.

[0172] Example 13: The method of any of the preceding examples, wherein the first branch target buffer is configured to produce branch prediction data in fewer clock cycles after a request than the second branch target buffer.

[0173] Example 14: The method of any of the preceding examples, wherein the second branch target buffer is configured to produce branch prediction data that more accurately reflects observed branching than the first branch target buffer.

[0174] Example 15: A branch prediction unit of a processor, the branch predictionAtty Docket No. 0120-1100WO1unit comprising: a first branch target buffer storing first branch prediction data that includes a branch offset, a branch target, and a predicted way -hit map for the branch target; a second branch target buffer that provides a plurality of ways and stores second branch prediction data corresponding to the branch target; and a branch prediction controller configured to: determine an instruction address, access, based on the instruction address, the first branch prediction data from the first branch target buffer, and access, based on the branch target, the second branch prediction data from the second branch target buffer, the access of the second branch prediction data being performed while at least one way of the plurality of ways is disabled based on the predicted way -hit map for the branch target.

[0175] Example 16: The branch prediction unit of any of the preceding examples, wherein: the second branch target buffer includes a first memory structure configured to store tag data and a second memory structure configured to store target data; during the access of the second branch prediction data, the at least one way of the plurality of ways is disabled within the second memory structure while remaining enabled within the first memory' structure: and the branch prediction controller is further configured to: determine an observed way -hit map for the branch target based on the tag data accessed from the first memory' structure as part of accessing the second branch prediction data, and update, within the first branch target buffer, the predicted way -hit map based on the observed way -hit map.

[0176] Example 17: The branch prediction unit of any of the preceding examples, wherein: the branch prediction controller is further configured to determine that a first set of way hits indicated by the predicted way -hit map is a superset of a second set of way hits indicated by the observed way -hit map; and the update of the predicted way-hit map is performed without replaying the access of the second branch prediction data using the updated predicted way-hit map.

[0177] Example 18: The branch prediction unit of any of the preceding examples, yvherein: the branch prediction controller is further configured to determine that a first set of way hits indicated by the predicted yvay-hit map is a subset of a second set of way hits indicated by the observed way -hit map; and the update of the predicted way-hit map is performed in connection with replaying the access of the second branch prediction data using the updated predicted way -hit map.

[0178] Example 19: A branch target buffer within a branch prediction unit of a processor, the branch target buffer comprising: an input interface configured to receive an instruction address from a branch prediction controller of the branch prediction unit; a memory configured to store first branch prediction data associated with the instructionAtty Docket No. 0120-1100WO1address, the first branch prediction data including a branch offset, a branch target, and a predicted way -hit map for the branch target within a separate branch target buffer, the separate branch target buffer providing a plurality of ways and storing second branch prediction data corresponding to the branch target; and an output interface configured to provide, in response to the instruction address being received at the input interface, the first branch prediction data.

[0179] Example 20: The branch target buffer of any of the preceding examples, wherein the branch target buffer provides a same number of ways as are provided by the separate branch target buffer in the plurality of ways.

[0180] Various implementations of the systems and techniques described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0181] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the description and claims. In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems.Accordingly, other implementations are within the scope of the following claims.

[0182] Specific structural and functional details disclosed herein are merely representative for purposes of describing example implementations. Example implementations, however, may be embodied in many alternate forms and should not be construed as limited to only the implementations set forth herein.

[0183] It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. A first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the implementations of the disclosure. As used herein.Atty Docket No. 0120-1100WO1the term and / or includes any and all combinations of one or more of the associated listed items.

[0184] The terminology used herein is for the purpose of describing particular implementations only and is not intended to be limiting of the implementations. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” when used in this specification, specify the presence of the stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0185] It will be understood that when an element is referred to as being “coupled,” “connected,” or “responsive” to, or “on,” another element, it can be directly coupled, connected, or responsive to, or on, the other element, or intervening elements may also be present. In contrast, when an element is referred to as being “directly coupled,” “directly- connected,” or “directly responsive” to, or “directly on,” another element, there are no intervening elements present. As used herein the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0186] Spatially relative terms, such as “beneath,” “below,” “lower,” “above,” “upper.” and the like, may be used herein for ease of description to describe one element or feature in relationship to another element(s) or feature(s) as illustrated in the figures. It will be understood that the spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientation depicted in the figures. For example, if the device in the figures is turned over, elements described as “below” or “beneath” other elements or features would then be oriented “above” the other elements or features. Thus, the term “below” can encompass both an orientation of above and below. The device may be otherwise oriented (rotated 130 degrees or at other orientations) and the spatially relative descriptors used herein may be interpreted accordingly.

[0187] Unless otherwise defined, the terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which these concepts belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and / or the present specification and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.Atty Docket No. 0120-1100WO1

[0188] Further to the descriptions above, a user may be provided with controls allowing the user to make an election as to both if and when systems, programs, or features described herein may enable collection of user information (e.g., information about a user's social network, social actions, or activities, profession, a user's preferences, or a user's current location), and if the user is sent content or communications from a server. In addition, certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity may be treated so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized, or location information may be obtained (such as to a city, zip code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over what information is collected about the user, how that information is used, and what information is provided to the user.

[0189] While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover such modifications and changes as fall within the scope of the implementations. It will be understood that they have been presented by way of example only, not limitation, and various changes in form and details may be made. Any portion of the apparatus and / or methods described herein may be combined in any combination, except mutually exclusive combinations. The implementations described herein can include various combinations and / or sub-combinations of the functions, components, and / or features of the different implementations described. As such, the scope of the present disclosure is not limited to the particular combinations hereafter claimed but instead extends to encompass any combination of features or example implementations described herein irrespective of whether or not that particular combination has been specifically enumerated in the accompanying claims at this time.

Claims

Atty Docket No. 0120-1100W01WHAT IS CLAIMED IS:

1. A method comprising:determining, by a branch prediction controller within a processor, an instruction address;accessing, from a first branch target buffer and based on the instruction address, first branch prediction data that includes a branch offset, a branch target, and a predicted way -hit map for the branch target in a second branch target buffer, the second branch target buffer providing a plurality of ways and storing second branch prediction data corresponding to the branch target; andaccessing, from the second branch target buffer and based on the branch target, the second branch prediction data, the accessing of the second branch prediction data being performed with at least one way of the plurality of ways being disabled based on the predicted way -hit map.

2. The method of claim 1. wherein:the second branch target buffer includes a first memory structure configured to store tag data and a second memory' structure configured to store target data;during the accessing of the second branch prediction data, the at least one way of the plurality of ways is disabled within the second memory structure while remaining enabled within the first memory structure; andthe method further comprises:determining an observed way -hit map for the branch target based on the tag data accessed from the first memory structure as part of accessing the second branch prediction data, andupdating, within the first branch target buffer, the predicted way-hit map based on the observed way -hit map.

3. The method of claim 2. further comprising determining that a first set of way hits indicated by the predicted w ay-hit map is a superset of a second set of way7hits indicated by the observed way -hit map;wherein the updating of the predicted way-hit map is performed without replaying the accessing of the second branch prediction data using the updated predicted way’ -hit map.Atty Docket No. 0120-1100WO14. The method of any of claims 2 to 3, further comprising determining that a first set of way hits indicated by the predicted way-hit map is a subset of a second set of way hits indicated by the observed way -hit map;wherein the updating of the predicted way -hit map is performed in connection with replaying the accessing of the second branch prediction data using the updated predicted way -hit map.

5. The method of any of claims 2 to 4, wherein:the first branch prediction data corresponds to an initial prediction of a taken branch from a first predict block to a second predict block;the method further comprises accessing, from the second branch target buffer and based on the instruction address, third branch prediction data that corresponds to a final prediction of the taken branch from the first predict block to the second predict block; and the updating of the predicted way -hit map within the first branch target buffer is performed in response to the final prediction of the taken branch from the first predict block to the second predict block.

6. The method of any of claims 1 to 5, wherein:the second branch target buffer is a multi-lane branch target buffer that includes: a first buffer structure associated with a first lane and addressable using a set of index values, anda second buffer structure associated with a second lane and addressable using the set of index values; andthe predicted way-hit map includes way-hit predictions for the plurality of ways in the first lane and for the plurality of ways in the second lane.

7. The method of claim 6, further comprising:determining that the first branch prediction data is associated with a trampoline branch pair that includes a primary branch from a first predict block to a second predict block and a secondary branch from the second predict block to a third predict block, the branch target indicating the second predict block and the second predict block being associated with the first lane; andAtty Docket No. 0120-1100WO1modifying, in response to the determining that the first branch prediction data is associated with the trampoline branch pair, the way -hit predictions for the plurality of ways in the second lane.

8. The method of claim 7, wherein the modify ing of the way-hit predictions for the plurality of ways in the second lane is further performed in response to identifying a modification of a validation state of the trampoline branch pair.

9. The method of any of claims 6 to 8, wherein the multi-lane branch target buffer includes one or more additional lanes beyond the first lane and the second lane.

10. The method of any of claims 1 to 9, wherein:the plurality of ways provided by the second branch target buffer includes a first way, a second way, a third way, and a fourth way; andthe predicted way-hit map includes a first way -hit prediction for the first way, a second way -hit prediction for the second way. a third way -hit prediction for the third way. and a fourth way-hit prediction for the fourth way.

11. The method of claim 10, wherein the plurality of ways provided by the second branch target buffer includes one or more additional ways beyond the first way, the second way, the third way, and the fourth way.

12. The method of any of claims 1 to 11, w herein the first branch target buffer provides a same number of ways as are provided by the second branch target buffer in the plurality of ways.

13. The method of any of claims 1 to 12, wherein the first branch target buffer is configured to produce branch prediction data in fewer clock cycles after a request than the second branch target buffer.

14. The method of any of claims 1 to 13, wherein the second branch target buffer is configured to produce branch prediction data that more accurately reflects observed branching than the first branch target buffer.Atty Docket No. 0120-1100WO115. A branch prediction unit of a processor, the branch prediction unit comprising: a first branch target buffer storing first branch prediction data that includes a branch offset, a branch target, and a predicted way-hit map for the branch target;a second branch target buffer that provides a plurality of ways and stores second branch prediction data corresponding to the branch target; anda branch prediction controller configured to:determine an instruction address.access, based on the instruction address, the first branch prediction data from the first branch target buffer, andaccess, based on the branch target, the second branch prediction data from the second branch target buffer, the access of the second branch prediction data being performed with at least one way of the plurality of ways being disabled based on the predicted way-hit map for the branch target.

16. The branch prediction unit of claim 15, wherein:the second branch target buffer includes a first memory structure configured to store tag data and a second memory structure configured to store target data;during the access of the second branch prediction data, the at least one way of the plurality of ways is disabled within the second memory structure while remaining enabled within the first memory structure; andthe branch prediction controller is further configured to:determine an observed way -hit map for the branch target based on the tag data accessed from the first memory' structure as part of accessing the second branch prediction data, andupdate, within the first branch target buffer, the predicted way-hit map based on the observed way -hit map.

17. The branch prediction unit of claim 16, wherein:the branch prediction controller is further configured to determine that a first set of way hits indicated by the predicted way -hit map is a superset of a second set of way hits indicated by the observed w ay -hit map; andthe update of the predicted way -hit map is performed without replaying the access of the second branch prediction data using the updated predicted way -hit map.Atty Docket No. 0120-1100WO118. The branch prediction unit of any of claims 16 or 17, wherein:the branch prediction controller is further configured to determine that a first set of way hits indicated by the predicted way-hit map is a subset of a second set of way hits indicated by the observed way -hit map; andthe update of the predicted way -hit map is performed in connection with replaying the access of the second branch prediction data using the updated predicted way -hit map.

19. A branch target buffer within a branch prediction unit of a processor, the branch target buffer comprising:an input interface configured to receive an instruction address from a branch prediction controller of the branch prediction unit;a memoty configured to store first branch prediction data associated with the instruction address, the first branch prediction data including a branch offset, a branch target, and a predicted way -hit map for the branch target within a separate branch target buffer, the separate branch target buffer providing a plurality of ways and storing second branch prediction data corresponding to the branch target; andan output interface configured to provide, in response to the instruction address being received at the input interface, the first branch prediction data.

20. The branch target buffer of claim 19. wherein the branch target buffer provides a same number of ways as are provided by the separate branch target buffer in the plurality of ways.

Images