JP2001249806A - Prediction information managing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an efficient means to manage instructions and branching prediction information about the instructions of a computer processor. SOLUTION: When prediction information is stored in memory hierarchy at plural levels including low level and high level prediction caches and a predicted information value is fetched from the low level prediction cache and when no predicted information value is stored there, the predicted information value is fetched from the high level prediction cache. Pieces of the prediction information stored in the low level and high level prediction caches are periodically updated by using the prediction information stored in the low level prediction cache. Furthermore, efficiency of management of the instruction and the branching prediction information is enhanced by integrating the low level prediction cache with a low level instruction cache and controlling them under common management mechanism.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

FIELD OF THE INVENTION The present invention relates to a method and apparatus for generating and storing prediction information used by a processor, and more particularly to generating and storing control flow prediction information such as branch prediction information. .

[0002]

2. Description of the Related Art Branch prediction information is information that assists in predicting the result of an instruction having the form "branch to instruction X if condition Y is satisfied". The purpose of branch prediction information is twofold. The branch prediction information predicts first whether a branch is taken (taken), and second, if it is predicted that a branch is taken, predicts the destination of the branch (ie, the “target” of the branch). Must.

[0003] Many of today's processors incorporate a structure known as an instruction pipeline. The instruction pipeline increases the efficiency of the processor by allowing the processor to process multiple instructions simultaneously. The instruction pipeline can be considered an instruction assembly line. When Instruction_0 enters the first stage of the pipeline, multiple instructions are processed simultaneously, such as Instruction_1 is processed in the second stage of the pipeline at the same time, and Instruction_2 is processed simultaneously in the third stage of the pipeline. . Periodically, new instructions are entered into the pipeline, and each instruction being processed in the pipeline is moved to the next stage of the pipeline or exits the pipeline.

In order to maximize the efficiency of instruction execution, the instruction pipeline should be updated whenever possible so that a useful output is generated at each clock of the instruction pipeline. It is desirable to satisfy. However, (1) when program flow control transfers from one section of program code to another, (2) when instructions are fetched and processed speculatively, and (3) when fetched and processed speculatively. When it is determined that the fetched instruction should not have been fetched and processed, one or more instruction pipelines will eventually produce wasted output. At each clock cycle when the instruction pipeline produces useless output, the instruction pipeline has a negative impact on processor efficiency.

[0005] Program flow control instructions, such as branch instructions, are one means by which program flow control can be transferred from one section of program code to another. Branch instructions are either conditional or unconditional. Conditional branch instructions determine program flow control based on the determination of a specified condition. Unconditional branch instructions always involve a transfer of program flow control. The instruction "Branch to instruction X if A>B" is one example of a conditional branch instruction. If A> B, program flow control transfers to the section of program code beginning with instruction X (ie, the target code section). If A ≦ B, the program control flow continues with a section of program code that follows the conditional branch instruction (ie, a sequential code section).

[0006] Because the instruction pipeline can have multiple levels of depth, the conditional branch instruction is often fetched before the condition specified in the branch instruction can be determined. Therefore, the processor predicts the result of the conditional branch instruction, and speculatively fetches and processes the instruction based on the prediction. When predicting the result of a branch instruction, the processor must actually make two predictions. First, the processor must predict whether a branch will be taken or not taken. Second, if the branch is predicted to be taken, the processor must predict the target of the branch (ie, the address where the flow control of the program may transfer). After the prediction is made, instructions are speculatively fetched from the target code section (if the branch is predicted to be taken) or from the sequential code section (if the branch is predicted not taken).

Although there are many branch prediction algorithms, branch prediction errors still occur. By the time a misprediction is confirmed, the instruction pipeline may have already processed many instructions fetched from the wrong code section. Upon encountering such a misprediction, the incorrectly fetched instruction being processed in one or more pipelines is flushed from the pipeline, the instruction is fetched from the correct code section, and the instruction is Must be processed through

When flushing instructions from the pipeline, bubbles (ie, gaps) are injected into the pipeline. Unfortunately, the pipeline often requires several clock cycles before the instruction pipeline can produce useful output again. Conditional branch instructions and other programs
Because flow control instructions are numerous in the program code (eg, may appear in the order of one out of every five instructions), even when branch prediction accuracy is relatively high, the cumulative Significantly detrimental to processor performance.

"Predict that branch is always taken" or "
When branch prediction is performed based on an algorithm other than "always predict that a branch is not taken", some means for managing branch prediction information (ie, generating, storing, accessing, updating, etc.) is required. Although there are various methods for storing branch prediction information, many of them include, for example, only a cache of predicted branch targets and a cache of branch history (or a single global branch history register). Therefore, (1) access the branch history, (2) predict whether the branch is taken or not based on the branch history, and (3) if the branch is predicted to be taken, access the branch target. (Or by calculating the branch target many times), a branch prediction is made.

Due to space constraints, each of the above caches is typically small, so that many branch instructions are mapped to a single entry (or set of entries) in each of the caches. Occurs frequently. For example, in a cache made up of 2-bit branch history counters, multiple branch instructions are mapped to each counter. In one prior art embodiment of such a cache, when any one of the branches to which the counter maps is taken, the counter is incremented. Similarly, when any one of the branches to which the counter maps is not taken, the counter is decremented. If the counter to which the next branch instruction to be predicted is mapped has a value of "10" or "11", the next branch is predicted to be taken. Similarly, the counter to which the next branch instruction to be predicted is mapped is "0".
Having a value of "0" or "01" predicts that the next branch will not be taken, so that the counter has been updated in response to the result of one or more extraneous branches. , A branch prediction is made and the prediction is assumed to be correct.

[0011]

As computer architectures increasingly rely on parallelism, predication, speculation, etc., the ability of a processor to generate and access accurate prediction information, such as branch prediction information. Is extremely important. To date, such needs include increasing the number of entries in the predictive cache, increasing the number of ways in the predictive cache, increasing the size of tags stored in the predictive cache, or (eg, "Alternative Implementations of Two-Lev").
el AdaptiveBranch Prediction "by T. Yeh and, Y. P
att (Association for Computing Machinery, July 19
It has been addressed by implementing a multi-stage prediction algorithm (as described in 92).

However, there is a need for better methods and apparatus for managing prediction information, such as branch prediction information.

[0013]

SUMMARY OF THE INVENTION In order to solve the above problems, the present invention proposes a new method and apparatus for generating and storing prediction information. In the method and apparatus of the invention, the prediction information used by the processor is stored in a multi-level memory hierarchy. In the present invention,
The “multi-level memory hierarchy” is defined as a structure in which the same type of prediction information is stored in a plurality of levels of the memory hierarchy.
tive Implementations of Two-Level Adaptive Branch
It should not be confused with the multi-level prediction algorithm as disclosed in "Prediction". Although this specification specifically describes the storage of branch prediction information in a multi-level memory hierarchy, other types of Those skilled in the art will readily understand how to store prediction information in the multi-level memory hierarchy.

The present invention provides a method for managing prediction information used by a processor. The method stores prediction information in a multi-level memory hierarchy including at least one low-level prediction cache and one higher-level prediction cache, and fetches prediction information values from the low-level prediction cache. When an attempt is made and the prediction information value is not stored in the low-level prediction cache, attempting to fetch the prediction information value from the high-level prediction cache; and And periodically updating the prediction information stored in the low-level prediction cache and the high-level prediction cache using the prediction information that is present.

In another aspect of the invention, branch prediction information is generated and stored prior to the time at which a branch instruction is to be fetched for execution. This branch prediction information includes information for predicting the “current fetch result” of the branch instruction. When a branch instruction is fetched for execution (e.g., from a low-level instruction cache), (1) the instruction pointer is quickly redirected (if the branch is predicted to be taken), and (2) the branch instruction The branch prediction information is used to speculatively determine the information for predicting the “next fetch result”. In this way, each time a branch instruction is fetched for execution, its prediction information has already been generated and stored, and the instruction pointer can be quickly redirected.

In yet another aspect of the invention, the prediction information is stored in a cache that is integrated with a low-level instruction cache. Therefore, the two caches can share a common management structure, and the prediction information can be accessed almost at the same time that the branch instruction corresponding to the prediction information is accessed. In addition, separate high level instruction and prediction caches can be implemented. Implementing and managing a high-speed, low-level cache is costly, so merging the low-level prediction information cache and the low-level instruction cache achieves economies of scale.

On the other hand, some prediction information (eg, IP relative branch instruction targets) can be generated very quickly, and (for most branch targets) storage of prediction information is Because of the cost, storing a large number of instructions in a high-level cache that is particularly suitable for storing instructions, and storing more branch prediction information in a high-level cache that is particularly suitable for storing branch prediction information This provides economies of scale outside of the integrated low-level cache. Preferably, the high-level instruction cache is implemented as a set-associative cache, and the high-level prediction cache is implemented as an untagged n-way cache. Also, preferably, branch prediction information, such as branch targets, branch history, and branch trigger prediction information, is stored in the unified low-level cache along with corresponding instructions. However, preferably only the branch history and branch trigger prediction information are stored in the high-level cache.

Still further, in accordance with the present invention, more efficient utilization of the high level prediction cache is achieved by only storing the "selected" branch history and trigger prediction information in the high level prediction cache.

The various aspects of the present invention described above operate in conjunction with one another to ensure that branch prediction information is (1) timely generated and (2) stored in an efficient manner. It should be noted that it is designed as follows.

[0020]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of the methods and apparatus described herein below are based on the Intel® / Hewlett-Packard® IA-64 software.
Have implemented the architecture. However, as will be readily appreciated by those skilled in the art, many of the methods and apparatus described herein may be implemented with other software and software.
It is also possible to adapt to implementing the architecture. For more information on the IA-64 software architecture, see the IA-64 Application Developer's Architecture Gu
ide "(Intel, May 1999).

In the IA-64 software architecture IA-64, instructions are fetched in bundles. Each bundle 100 has a total of 128 bits and 3
Includes one 41-bit instruction syllable (ie, instruction slot) and one 5-bit template field. Figure 1 shows syllable_0, syllable_1 and syllable
A typical IA-64 instruction bundle 100 containing three syllables is shown. The instructions in the instruction bundle 100 include “unconditional” or “taken” branch instructions in the program
Unless and until flow control is transferred to the first sequential instruction in a different instruction bundle (or a fault, trap,
Until an interrupt or some other event causes the transfer of program flow control), syllable_0, then syllable_1, then syllable_2, and so on. Unless the program flow control is changed, the execution of instructions in one bundle 100 is followed by the instructions in the next successive bundle.

There are five IA-64 instruction syllable types (M, I, F, B and L) and six IA-64 instruction types (M,
I, A, F, B and L) and 12 basic templates
Type (MII, MI, I, MLX, MMI, M, MI, MFI, MMF, MIB, M
BB, BBB, MMB, MFB). The instruction template type specifies the mapping of the instruction syllable to an execution unit type, along with a "stop" position. There are two versions of each of the basic template types, one with a stop after the third syllable and one without. A stop indicates that the instruction or instructions after the stop may have some type of resource dependency with respect to the instruction or instructions before the stop (i.e., the Can be explicitly specified). It should be noted that MI, I and M.MI instruction templates, by definition, have in-bundle stops as indicated by the commas contained in those templates. Except for A-type instructions, which can be placed in either I-syllables or M-syllables, instructions must be placed in the syllable corresponding to that instruction type, based on the template specification. For example, MII
Of the three instructions in the bundle 100, the first instruction is a memory (M) type instruction or A
Type instruction, which means that the next two instructions are integer (I) type instructions or A type instructions.

The MLX template is unique in that it contains only two instructions: a memory (M) instruction and a long X-type instruction. At present, the MLX template is actually an MLI template, since the X instruction can only be an integer instruction. The X syllable in the MLX template holds a 22-bit "long immediate" integer instruction. These 22 bits are sent to the integer unit, with the additional 41 bits of "long immediate" held by the L syllable of the MLX template. Thus, the LX instruction is a form of integer instruction.

An instruction execution flow in the IA-64 processor is controlled by an instruction pointer (hereinafter, sometimes referred to as IP). The instruction pointer holds the address of the bundle 100 containing the currently executing IA-64 instruction. The IP is incremented when the instruction bundle 100 is executed, and is set to a new value by executing the branch instruction (or by other means). The IA-64 instruction bundle 100 is 16 bytes and contains 1
Since alignment is performed in units of 6 bytes, the least significant 4 bits of the IP are always zero.

The IA-64 software architecture is:
It provides two basic branch divisions: IP relative branches and indirect branches. IP-relative branches specify a branch target address using a signed 20-bit offset. This offset is carried with the IP relative branch instruction. When this offset is added to the start address of the instruction bundle including the IP relative branch, it indicates the start address of the target bundle. Signed 20-bit offset
(Ie, 21 bit offset) allows the IP relative branch to reach ± 16 MB. On the other hand, the reachable address provided by the indirect branch is greater than that of the IP relative branch, but at a higher cost. The target bundle of the indirect branch is specified by the value held in one of the eight 64-bit branch registers. Thus, the indirect branch target must be moved to one of the eight branch registers before the indirect branch target is needed (this is because the branch prediction hardware is intended for branch prediction). Before the time of relying on the target). Therefore, indirect branching requires a setup routine such as MOVL, MOV-to-BR, BR. The MOVL instruction moves the 64-bit value to a general purpose register (GR). next,
The MOV-to-BR instruction moves the 64-bit general register value to the specified branch register (BR). Next, the BR instruction executes a branch to the target address stored in the specified branch register.

The setup routine for an indirect branch involves three instructions, some of which are 64 instructions.
Because of the need to move bit values, the instructions of the setup routine of the indirect branch can only fit at most two instruction bundles. Furthermore, these three
The execution of one indirect branch requires at least three cycles because the two instructions are dependent on each other and must therefore be executed sequentially (as opposed to the IP relative branch, which requires the execution of only one instruction). . Also, performing an indirect branch requires the use of at least one available general purpose register and one available branch register.
Thus, indirect branching requires a lot of overhead. However, indirect branches are advantageous over IP-relative branches in that they can branch anywhere in the IA-64 64-bit address space.

A branch is either an unconditional branch or a conditional branch. Unconditional branches always hold. A conditional branch may or may not be taken. Therefore, the result of the conditional branch must be predicted in some way. In one approach, the outcome of a branch is predicted via "hints" generated by the compiler. The hint is encoded with the branch instruction at compile time and decoded by the processor prior to the execution of the branch instruction.

The following is a description of some improved methods and apparatus for implementing the above IA-64 software architecture (and other software architectures). Some of such methods and devices include:
An improved means for generating, storing and managing prediction information, especially branch prediction information.

Instruction Processing / Branch Prediction Hardware FIG. 2 shows various structures for managing instruction and branch prediction information within a single processor. In the structure of FIG.
Integrated low-level instruction / branch prediction cache 200 (sometimes referred to in the following description as simply "integrated low-level cache"), separate high-level instruction cache 20
6 and branch prediction cache 208, and several structures that assist in updating the branch prediction information stored in the various caches.

1. Integrated Low-Level Instruction / Branch Prediction Cache The central structure of the device of FIG. This integrated low-level instruction
Although the branch prediction cache 200 functionally operates as a single structure, conceptually the low level instruction cache 20
4 (L0I) and the low-level branch prediction cache 202 (L0IB
R) (see also FIG. 3).

In the past, most processors maintained branch prediction information in a cache that was functionally different from the processor's low-level instruction cache 204. Part of the reason is that branch prediction algorithms used in the past rely heavily on global branch prediction. Global branch prediction is a form of branch prediction in which each leaving branch instruction shifts one bit indicating the result (taken or not taken) into the global branch history register. The global branch history register is then used to index a cache of a two-bit counter that stores the prediction history for various patterns in which the bit (s) of the global branch history register can be assumed. Each time a leaving branch updates the global branch history register, the appropriate pattern history counter is also updated (see above-cited "Alternat").
ive Implementations of Two-Level Adaptive Branch P
rediction ").

[0032] The accuracy of the global branch predictor depends greatly on the size of the global history register. This is 2
There are two reasons. First, the longer the global history, the more information that can distinguish between different prediction scenarios. Second, the longer the global history register,
This means that the table of the bit pattern history counter is large, and therefore, the counter aliasing is small. Global history register size
When the correct ratio of computer program branch to (and pattern history table size) is maintained,
Although global branch predictors can provide very high levels of accuracy, local branch prediction is advantageous for several reasons. For example, although the details will be described later, the local branch predictor makes it possible to determine information for predicting the “next fetch result” of the branch instruction at the time of the current fetch of the branch (here, the branch instruction The information for predicting the next fetch result includes trigger information for predicting whether a branch instruction is taken or not taken, and target information for predicting a branch destination when it is predicted that a branch will be taken).

Another advantage of local branch prediction is that it fits better in size to programs containing many branches. In other words, the computer
As the number of branches in a program increases, a point is reached where global branch prediction requires more memory space than local branch prediction to achieve the same prediction accuracy as achieved by local branch prediction Becomes Because the IA-64 software architecture is specifically designed to effectively handle large computer programs (and thus programs containing a relatively large number of branch instructions), local branch prediction implements such an architecture. Is considered a better choice.

The local branch prediction determines the information predicting the next fetch result of the branch at the time of the current fetch of the branch. Storing information that predicts the fetch result makes sense, which makes it easier to retrieve and use the prediction information the next time the branch instruction is fetched. This saves the time of having to access (or further calculate) the branch target after waiting to access the global branch history register and the associative pattern history table after the branch is fetched. FIG.
Illustrates such an integrated low-level instruction / branch prediction cache 200.

While it is possible to use one or more caches that collectively perform the function of a branch prediction cache to store information that predicts the result of the next fetch of a branch, the integrated cache shown in FIG. Level cache 200
There are many advantages to using. First, local branch prediction is (because branch prediction information is maintained for each branch).
It requires a one-to-one correspondence between the branch instruction and the branch prediction information. While one way to establish such a correspondence is to increase the size of one or more stand-alone branch prediction caches, the present invention uses integrated low-level instruction / branch prediction cache 200. We decided that introducing it was a better method.

The low-level instruction cache 204 uses full tagging (ie, tags that are large enough to uniquely identify the instructions stored therein). The cost of storing these complete tags is high, and designing, testing, and building a cache management structure that can handle complete tags efficiently is costly. Storing the branch prediction information for each branch is also costly. However, integrating the low-level instruction cache 204 and the branch prediction cache 202 under the common management structure 300 (of FIG. 3) can provide benefits of economies of scale. Branch instructions and their corresponding prediction information can be retrieved from the unified low-level cache 200 using a single addressing means.

Further, in order for the instruction pipeline of the processor to operate at full speed, the access speed of the branch prediction cache 202 must be almost equal to the speed of the low-level instruction cache 204 of the processor. is there. The integration of the low-level instruction cache 204 and the branch prediction cache 202 ensures such speed matching.

As an alternative, the branch prediction cache could be implemented using one or more caches that collectively act as a branch prediction cache, but with a complete cache structure in such a cache structure. Implementing tagging is expensive. In addition, the hardware needs to "associate" the branch prediction information with its corresponding branch instruction. The cost of implementing a branch prediction cache may be reduced, for example, by using less complete tagging for the cache. However, this makes it uncertain whether the information fetched from the branch prediction cache really corresponds to a branch instruction fetched from the low level instruction cache 204. By integrating the low-level instruction cache 204 and the branch prediction cache 202,
It can be seen that the correspondence of the prediction information is accurate.

Since not all instructions stored in low-level instruction cache 204 are branch instructions, at any given point in time, the integrated low-level instruction /
Many of the entries in the branch prediction portion 202 of the branch prediction cache 200 may not be used. However, the advantage that (1) the management structure of the low-level instruction cache 204 can be introduced, and (2) that the prediction information is always available when a branch is fetched, is useful in the usefulness stored in the cache 202. This is more important than the fact that the density of the prediction information is relatively low.

A. One of the L0I portions 204 of the L0I unified low level cache 200
In one preferred embodiment, the instructions are stored in L0I 204 as a bundle pair. One bundle pair of instructions includes two instruction bundles, each including three instruction syllables and a number of template bits. L0
An example of an instruction bundle pair stored in I204 (bundle
_O and bundle_1) are shown in FIG. The three syllables in each instruction bundle are syllable_0 executed first (assuming that program flow control does not move to the start of a different instruction bundle due to a previously executed branch instruction), then syllable_ 1 is designed to be executed in order, such as syllable_2 at the end.

When program flow control is transferred to the first sequential bundle of the pair, it is possible to transfer program flow control to the beginning of any instruction bundle in the instruction bundle pair, but the execution of instructions is , (Again, assuming that the previously executed branch instruction does not cause program flow control to move to the start of a different instruction bundle), sequentially from the first bundle to the second bundle. One of the reasons that instructions are preferably stored in L0I 204 in a bundle pair is that, for a larger number of instruction bits, the cost of the very large number of address bits used to access L0I 204 can be reduced. It is in.

B. In one preferred embodiment of the L0IBR portion 202 of the L0IBR unified low-level cache 200, branch prediction information for each bundle pair of instructions stored in the L0I 204 is stored. One format that the L0IBR branch prediction information can take is shown in FIG. The prediction information includes multiple bits of the target to be predicted, target correlation data (TAS),
And four branch history / trigger prediction chunks 3
02, 304, 306, and 308. The branch history / trigger predictions 302 to 308 are described below as STH (single-way trig).
ger / history).

Each of the four STH chunks 302-308 stored in L0 IBR 202 is formed from five bits, including four branch history bits and one trigger prediction bit. The trigger prediction bit predicts whether the branch currently stored in L0I 204 will be taken or not taken at the next fetch. The branch history bits stored with a given trigger prediction bit form a record of the past taken / failed results of that branch for which the triggered prediction bit predicts a result.

Since an instruction bundle 100 can hold up to three branch instructions, an instruction bundle can have more branches than the STH chunks 302-308 available for that bundle 100. is there. Therefore, STH chunks 302 through 308 are used as follows. If syllable_0 of instruction bundle 100 does not hold a branch instruction, a separate ST
H chunks 302, 304 are assigned to each of the remaining two syllables of the instruction bundle. Instruction bundle 10
If syllable_0 of 0 holds a branch instruction, S
The pair of TH chunks 302, 304 is used to store branch history and trigger prediction information in encoded form 400 (FIG. 4). When used to store encoding information, branch history and trigger prediction information for all three syllables of the instruction bundle can be stored. IA-6
At present, the 4 architecture only provides one template that syllable_0 of the instruction bundle can hold a branch.
BBB. As a result, syllable _ of instruction bundle 100
Whenever 0 holds a branch, it is possible (but not guaranteed) that all three instruction syllables in bundle 100 will hold the branch. To facilitate the decision as to whether or not the encoded STH chunk 400 should be used, instruction bundle 1 regardless of whether syllable_1 and syllable_2 actually hold a branch instruction.
Whenever syllable_0 of 00 holds a true branch, the encoded STH chunk 400 is preferably used.

FIG. 4 shows an encoded pair of STH chunks 400. It should be noted that encoded pair 400 holds four 2-bit history events and one 2-bit trigger prediction for its corresponding instruction bundle. A two-bit value of "00" in the trigger prediction indicates that no branch of the instruction bundle is predicted to be taken, and a "01" value of two bits in the trigger prediction indicates that the branch of syllable_2 is taken. Then, the value of “10” of the two bits of the trigger prediction indicates that the branch of syllable_1 is predicted to be taken, and the value of “11” of the two bits of the trigger prediction is predicted as the syllable. Indicates that the branch of _0 is predicted to be taken.

Given the current IA-64 instruction template, the instruction bundle 100 stored in L0I 204
STH chunk 30 of two L0IBRs assigned to
2, 304 can be used in one of three ways: First, if instruction bundle 100 holds only one branch instruction and that branch instruction does not appear in syllable_0, then one STH chunk 302 stores the branch history and trigger prediction information for that branch. Second, if the instruction bundle 100 holds two branch instructions and none of these branch instructions appear in syllable_0, then store the branch history and trigger prediction information for those two branches. One STH chunk 302, 304 is used. Third, instruction bundle 1
If 00 stores a branch instruction in syllable_0, two STH chunks 30 are stored to store the encoded branch history and trigger prediction information 400 relating to the branch of the instruction.
2, 304 are used. In the encoding case,
It should be noted that two STH chunks 400 can handle branch history and trigger prediction information for up to three branches. However, two STHs
The encoding of chunk 400 does not necessarily mean that instruction bundle 100 has three branches.

As will be described later, STH of unused L0IBR
Chunks 302 to 308 can be used to store L1B management information.

Each instruction bundle pair stored in L0I 204 is a single branch target stored in L0IBR 202.
(Or part of it). Therefore, the target is mapped to the first sequentially executed branch instruction of the instruction bundle having the branch predicted to be taken. Here, the instruction bundle is the first bundle following the “bundle pair entry point”. In the IA-64 software architecture, the branch instruction is either the first instruction bundle (bundle_O) or the second instruction bundle of the bundle pair because its program flow control can be directed to the start of any instruction bundle 100. Program flow control can be redirected to any of the instruction bundles (bundle_1). Thus, when program flow control is directed (or redirected) to one bundle of a bundle pair during the current fetch of a bundle pair, program flow control is directed to the same bundle at the next fetch of the bundle pair. Is assumed. The point to which program flow control is directed is referred to herein as a bundle pair entry point. Once the bundle pair entry point is determined, the trigger prediction bits corresponding to the instruction bundle pair are evaluated,
The first instruction predicted to be taken is determined by determining which branch instruction in the instruction bundle pair is the first branch instruction predicted to be taken after the bundle pair entry point.

The target correlation bits stored with the target simply map the target to the syllable or branch instruction of the instruction bundle pair for which the target was generated (or marked as target invalid). As can be calculated from the above, for each instruction bundle pair (256 bits) stored in the L0I portion 204 of the unified low-level cache 200, 63 bits of data are stored in the L0IBR portion 202 of the cache 200. Stored (LOIBR 202 actually provides 64 bits for each instruction bundle pair, one of which is currently unused). However, the above is L0I
This is just one preferred structure of BR 202, where the number of bits contained is the number of target bits that are desired to be stored for a given application, the number of history bits per branch that are desired to be stored, the instructions provided. It can be increased or decreased according to factors such as the number of STH chunks 302-308 per bundle 100 (or bundle pair).

2. High Level Cache It should be noted that many of the instructions stored in the unified low level cache 200 are non-branch instructions. No corresponding prediction information entry is used for a non-branch instruction. This is acceptable in order to achieve rapid access and economies of scale in storing and accessing prediction information needed by the processor in the very near future. The prediction information indicates that the corresponding instruction is L0I204
Fetched from the L0IBR 202 at the same time. There is no need to derive this information from two independent cache structures.

However, the apparatus of FIG. 2 does not include an integrated high-level instruction / branch prediction cache. Part of the reason is that higher-level cache structures are typically larger and slower than lower-level cache structures, and the predictive information portion of higher-level consolidated structures has too many blanks. It contains entries (ie wastes space). Instead, L0IBR2
02 is stored in a separate high level branch prediction cache or L1B 208. By the independent configuration of L1B208, L0IBR20
2, the branch prediction information can be stored at a higher density than when stored in the second branch.

A. L1 Cache The second structure disclosed as part of the device of FIG.
The second level instruction cache (ie, L1 cache 20)
6). L1 cache 206 is a higher level cache compared to lower level unified cache 200 and is designed to store more instructions than are stored in L0I portion 204 of low level unified cache 200. Some of the instructions stored in L1 cache 206 are copies of the instructions loaded into L0I, and other parts of the instructions stored in L1 cache 206 are L0I.
A copy of the instruction to be loaded into 204 (or L0I20
4 is a copy of the instruction overwritten). However, while L1 cache 206 stores a copy of the instruction loaded into L0I 204, L1206 preferably does not store a copy of the branch prediction information value loaded into L0IBR 202 (L1B 208 performs this operation to some extent). . Also L
One cache 206 does not always store every instruction present in L0I 204.

Preferably, L1206 does not store a copy of the branch prediction information value loaded into L0IBR 202,
L1 cache 206 preferably stores some branch prediction information. For example, branch prediction hints generated by a compiler or the like are often encoded as part of the branch instruction that gives the hint. As a result, one preferred embodiment of the L1 cache 206 continues to store these hints. However, as will be described later, a cache 208 different from the L1 cache 206 is used.
It is beneficial to store backup copies of more extensive branch prediction information (such as branch history). In this way, the secondary branch prediction cache 208 is formatted and managed separately from the L1 cache 206 in a more optimized form for storing branch prediction information.

B. L1B A third structure disclosed as part of the device of FIG.
Secondary branch prediction cache (that is, L1B cache 20)
8). L1B cache 208 is for L0IBR 202, just as L1 cache 206 is for L0I204. Therefore, the L1B 208
Is typically a large and slow cache compared to the L0 IBR 202.

A preferred embodiment of L1B208 is L0I20
4, at most two of the four L0 IBR chunks 302-308 corresponding to a particular instruction bundle pair stored in
Note that you only have the ability to remember one. Therefore, the rest of the branch prediction information maintained by L0IBR 202 is not maintained by L1B 208. However, it will be appreciated by those skilled in the art that more or less or different types of branch prediction information may be stored in L1B 208, depending on the needs of a particular application.

Regarding branch history and trigger prediction information,
L1B 208 stores much more information than can be stored in L0 IBR 202. Therefore, even if the instruction bundle pair and its corresponding branch prediction information are deleted from the low level unified cache 200, the L1 cache 2
The branch history and trigger prediction information corresponding to the instruction bundle pair fetched from 06 may be present in the L1B cache 208. If present, low-level unified cache 200 includes L1 cache 206 and L1 cache 206.
Most can be filled with data fetched from the L1B cache 208.

As mentioned above, L1B 208 is preferably
Store only two of the four L0IBRSTH chunks 302-308 corresponding to the 0I instruction bundle pair. As a result, one preferred embodiment of the apparatus of FIG. 2 only uses L1B 208 to store L0IBRSTH chunks 302-308 when only two STH chunks are used by the instruction bundle pair. Thus, when (1) each instruction bundle in a bundle pair holds one branch instruction, (2) one instruction bundle in the bundle pair holds two branch instructions and the other instruction bundle is a branch instruction And (3) one instruction bundle of the bundle pair holds three branch instructions.
(In other words, it is estimated that a maximum of three branch instructions are held by the branch existing in the syllable_0 of the instruction bundle), and when the other instruction bundle does not hold the branch instruction, the L1B 208 is used. It should be noted that in the last case, the branch history and trigger prediction information for the three branch instructions are two STH chunks 4
It is encoded only in 00. In all other cases, L1B 208 is not used as a backup to L0 IBR 202. Fortunately, the arrangement of branches in an instruction bundle pair usually corresponds to one of the three cases listed above. As will be appreciated by those skilled in the art, L1B 208 can be made large enough to store even more L0IBR information, as long as the available chip area allows.

The preferred relationship between L0IBR 202 and L1B 208 is generally a write-through relationship. In other words, when the branch history bit and the trigger prediction bit are updated in L0IBR 202, the same bit is
08 is written. However, L0IBR202 and L1B
One preferred configuration of 208 incorporates a number of exceptions to this general write-through strategy. First, L1B2
08 is two STH chunks 3 per instruction bundle pair
02, 304, only provide storage space for the STH chunk 30 with no more than two instruction bundle pairs.
STH chunk 302 only when using 2, 304
304 is written to the L1B 208. However, since most instruction bundle pairs hold no more than two branch instructions, this first exception to the general write-through strategy is expected to have little effect on branch prediction performance.

Another exception to the general write-through relationship between L0IBR 202 and L1B 208 is that branch instructions may not use L1B 208. For example, one state of the ".clr" hint of the IA-64 software architecture is used to instruct the device of FIG. 2 not to use L1B 208 for a particular branch instruction. In this way, the compiler can predict L1B 208 when predicting a particular branch instruction (eg, a branch that can be predicted using only compiler generated hints).
Can be decided not to use.

A third exception to the general write-through relationship between L0IBR 202 and L1B 208 is (for example, based on compiler hints coded with branch instructions, all history and trigger prediction bits are reset to logical zeros). When the STH chunk 302 is deemed to provide information that yields a higher prediction accuracy than can be obtained if the L0 IBR 202 is simply initialized to some default value (by an initializer setting the reverse), 1 One STH chunk 302 is L1B 208
Is simply written to L0IBR202 and L
Details of the second exception to the general write-through relationship with 1B208 will be described later.

STH chunk 30 in L0IBR 202
There are many possible ways to initialize 2. One way to perform such initialization is to retrieve the relevant data from L1B 208. However, due to a number of factors, the required STH chunks 302-3 are
08 may not be present in the L1B 208. For example, (1) if L1B 208 is smaller than L1206, (2) if the instruction bundle has been fetched into L1 cache 206 but not yet loaded into L0I204, (3) L0IBR
If not all of the data stored in 202 has been copied to L1B 208, or (4) if the instruction hint indicates that L1B 208 should not be used or should not be relied upon, There is a time when the L1B 208 does not hold the value corresponding to the instruction bundle pair fetched from the L1 cache 206.

If L1B 208 does not contain the required value, then some other means for initializing L0IBR 202 must exist. One preferred method of initializing the L0IBRSTH chunk 302 after encountering an L1B miss is to fill all bits of the STH chunk 302 with a logical zero (or alternatively a logical one). As a result, the probability of correctly predicting a branch result is relatively low the first time the branch is encountered. However, the prediction accuracy is improved after the branch is executed once or multiple times. As will be appreciated by those skilled in the art, the hardware required to initialize the STH chunk 302 with a logical zero is relatively simple to implement and low cost.

STH chunk 3 after encountering L1B mistake
Another way to initialize 02 is to set all of the bits of chunk 302 to logic zero or logic one according to the value assumed by the prediction hint (eg, a static or dynamic compiler hint) encoded in the branch instruction. Is to be filled in. One variation of this initialization scheme that provides faster L0 IBR initialization is (1) assuming that a branch is not taken, (2) filling the corresponding STH chunk 302 of that branch with all zeros, and (3) ) If hint information indicates that satisfying logic 1 provides more accurate branch prediction, use extra 1 cycle to STH chunk 302
With logic 1 again.

As described above, the L0IBRSTH chunk 302 is only used when the chunk 302 is considered to hold information that produces better prediction accuracy than when the L0IBR 202 is simply initialized with some default value.
Is written to the L1B 208. S after encountering L1B mistake
Assuming that the TH chunks 302 are all initialized to logical zeros, writing these zeros to L1B 208 does not serve any substantial purpose since reinitialization of L0IBR 202 provides the same data without reference to L1B 208. do not do. In addition, the failure to write L0IBR initialization zero to L1B 208 provides significant advantages. The greatest advantage is that failure to write L0 IBR initialization zero to L1B 208 allows L1B 208 to effectively store a larger amount of prediction information.

For example, an untagged n-way cache storing data using redundancy and index hashes
If L1B 208 is constructed as a cache, L1B
Writing new data values to 208 tends to overwrite duplicate copies of other data values. In other words, if duplicate copies of data A, data B, and data C have already been written to different sets of indexed storage locations in L1B 208, writing data D to L1B may be Overwrite one of the duplicate copies of A, one of the duplicate copies of data B, and one of the duplicate copies of data C. As will be appreciated, if such overwriting occurs too frequently, data A, data B, and data C will be stored in L1B2
At 08 comes a time when it no longer exists.

One way to reduce the likelihood of data A, data B and data C being overwritten is to use L1B 208
0 Avoid writing zeros for IBR initialization.
If these zeros are written to L1B 208 and the instruction bundle pairs corresponding to these zeros are subsequently deleted from L0I 204, the action of reloading L0I 202 with the instruction bundle pairs and reloading zeros from L1B 208 is L0IBR 202. It does not provide better prediction accuracy than if it were re-initialized to a default value by some inexpensive means.

Another advantage of failing to write L0IBR initialization zeros to L1B 208 is that failing to write zeros to L1B 208 reduces the amount of "write" traffic for L1B. This is L1B20
8 is especially important if it has a limited write bandwidth
(For example, if L1B 208 has only a single read / write port, reducing the number of L1B writes frees up more bandwidth for L1B reading). However,
When the non-zero STH chunk 302 is already maintained in L1B 208, the all-zero STH chunk 302
Note that it is necessary to write to L1B 208. Otherwise, reloading data into the L0IBR 202 may load the old STH chunk 302.

To avoid unnecessary updating of L1B 208,
1B relevance information is maintained. This relevancy information is preferably (but not necessarily) stored in L0 IBR 202 and written to L1B 208 at some point in STH chunk 3
02, 304 (ie, the relevancy information is at most two STs per instruction bundle pair).
H chunks 302, 304). The relevancy information corresponding to a single STH chunk 302 must consist of only a single information bit. When an instruction bundle pair is fetched from the L1 cache 206 and a corresponding attempt is made to fetch prediction information from the L1B cache 208, the L1B relevance bits are initialized. L1B2
Attempt to fetch STH chunk 302 from 08
If so, the STH chunk 302, which was to be filled with the missed L1B data, is initialized to a default value and its corresponding L1B relevance bit is set to zero. Accordingly, the relevance bit indicates that L1B 208 does not include a backup copy of the newly initialized STH chunk 302.

An attempt to fetch STH chunk 302 from L1B 208 produces an L1B hit, but if the data read from L1B 208 is the same as the default value generated for STH chunk 302, STH chunk 302 is Filled with data to be fetched. As an alternative, the STH chunk 302
It can also be set to that default value by another default initializer. If L1B 208 generates a hit, but the prediction information is not good compared to that provided by the lower cost L0 IBR initialization means, then the L1B relevance bits corresponding to the newly filled STH chunk 302 will also be Set to zero.

The decision as to whether the L1B hit reads all zeros or all ones from L1B 208 is:
Simple NO of bits read from L1B208
This can be done by R or AND. L1B208
If the attempt to fetch STH chunk 302 from L1B produces an L1B hit and the data read from L1B 208 provides different prediction information than can be generated by the default initializer described above, The L1B relevance bit corresponding to the STH chunk 302 that has been set is set to "1".
8 indicates that the related backup history of the STH chunk 302 is held.

Circuit 500 for Initializing L1B Related Bits
Is shown in FIG. Comparator 502 compares the selected data value pattern (or patterns), such as all logic zeros, with STH chunk 302 retrieved from L1B 208. If the two values do not match (as indicated by the output of inverter 504) and there is a hit in L1B 208, then the appropriate L1B relevance bit (ER bit) is "
Set to "1", otherwise set to "0".

In one preferred embodiment of the L0IBR, the relevance bits corresponding to the STH chunks 302, 304 used by the instruction bundle pair are not used to store branch history and trigger prediction information.
Stored in the TH chunks 306, 308. When a given instruction bundle pair uses more than two of its L0IBRSTH chunks 302-308 for storage of branch history and trigger prediction information, no relevancy bits are stored in L0IBR 202 and L1B 208 is in place. Not used to back up data about a given instruction bundle pair. The instruction bundle pair has its L0IBRSTH chunk 302 for storing branch history and trigger prediction information.
308 are used to form the encoded set 400, the pair of relevance bits for the encoded set is
The coded set 400 can be stored in the L0IBRSTH chunks 306, 308, and the coded set 400 can be backed up to the L1B 208 in the same manner as if two uncoded STH chunks 302, 304 were backed up. .

3. New Branch Prediction Structure FIG. 2 shows two new branch prediction structures 210, 212. The first structure 210 describes the instruction pipeline "
A "speculative" branch prediction that is part of the "front end" and fetches a branch. The second structure 212
Part of the "back end" of the instruction pipeline that generates "non-speculative" branch predictions upon branch eviction. When fetching an instruction bundle pair and its corresponding prediction information from the unified low-level cache 200, the fetched prediction information along with its address is provided to a speculative new branch prediction structure 210. Speculative new branch prediction structure 210
Is preferably a pattern history table
table: hereinafter referred to as PHT) and an IP relative adder.

The pattern history table is a table that includes rows of counters corresponding to various patterns of branch history bits that can be stored as part of the L0IBRTH chunk 302. For example, if the STH chunk 302 holds a 4-bit branch history, the PHT is 4
Carrying counter 2 ⁴ corresponding to various patterns that can be history bit takes ^(i.e. 16). PHT
Are preferably addressable based on quasi address units. In other words, for every instruction address, there is no separate row of 16 counters, but enough rows of counters are provided so that aliasing is limited to an acceptably low frequency. When a branch leaves at the back end of the pipeline,
The branch history that existed for the branch at the time it was fetched (i.e., L0IBR 202 when the branch was fetched).
The counter corresponding to (history extracted from) is appropriately updated (for example, it is incremented when the branch is taken, and decremented when the branch is not taken).

Therefore, the apparatus shown in FIG. 2 performs not only branch prediction based on the history of the previous branch result but also branch prediction based on the history of the previous history pattern regarding the branch. L0
In conjunction with the branch history stored in IBR 202, the pattern history table forms part of a two-level branch prediction algorithm. The various forms that the PHT can take are described in the cited reference "Alternative Implementations of Two-Le
vel Adaptive BranchPrediction. In this reference, the PHT is disclosed as part of the speculative new branch prediction structure 210, but the counter maintained by the PHT is updated non-speculatively.

When the STH chunk 302 is fetched from the L0IBR 202, the trigger portion of the chunk 302 is shifted to its newest history bit position and the oldest history bit is shifted out of the STH chunk 302. Next, this new history is stored in its corresponding bundle
Along with a portion of the address, it is used as an index pointing to the PHT to determine the next fetch trigger to be stored as part of the STH chunk 302.

The speculative new branch prediction structure also includes an IP relative adder. Each branch history in the STH chunks 302-308 used by the fetched instruction bundle pair is updated, and the updated trigger value is retrieved from the PHT using the updated history, and then updated with the updated trigger value. Using the latest bundle pair entry point, the first predicted taken branch after the bundle pair entry point is determined. Next, the IP relative adder generates a new target prediction by adding the offset value carried by the branch instruction predicted to be taken to the instruction pointer value corresponding to the bundle address of that branch.

All of the updated prediction information generated by the speculative new branch prediction structure 210 is sent to a multiplexer (MUX) 228 for sequential use in updating ISBBR 226 (described below) and / or L0IBR 202. The new trigger prediction generated for a branch by the speculative new branch prediction structure 210 is (if the branch is the latest bundle pair
ISB 226 with the new target (assuming the first predicted taken branch following the entry point)
Alternatively, information for predicting a fetch result next to the branch instruction stored in the L0I 204 is formed. Since this information is speculatively generated by the front end of the instruction pipeline, it is available on the next fetch of the branch instruction (in this case, the next fetch before the branch leaves the previous fetch). May be done). Further, the prediction information can be used for the purpose of redirecting the instruction pointer without requiring an extra cycle (details will be described later).

The branch prediction information fetched from the L0 IBR 202 includes the rotator mux 234 and the branch execution unit 2 (which may be one of many).
(Via 36). When the branch corresponding to the prediction information leaves at the back end of the pipeline, the branch, along with its current fetch prediction information,
The information is passed to the non-speculative branch prediction structure 212, and a non-speculative fetch prediction regarding the branch is performed. The non-speculative branch prediction is passed to a multiplexer 228 and used to correct erroneous speculative predictions stored in ISBBR 226 or L0IBR 202.

When the L0IBRSTH chunks 302, 304 are updated, the L1B 208 and the appropriate L1B relevance bits stored in the L0IBR 202 must also be updated. The determination of whether the L1B 208 and the appropriate L1B relevance bits should be updated is preferably made by the non-speculative new branch prediction structure 212.

Each time it is determined that the L0IBRSTH chunk 302 needs to be updated, the non-speculative new branch prediction structure 2
12 determines that the corresponding L1B relevance bits stored in L1B 208 and L0 IBR 202 must also be updated. In one preferred embodiment of the non-speculative new branch prediction structure 212, the updated STH chunk 302 is (1) the STH chunk 30 from the L0 IBR 202.
The state of the relevance information corresponding to the last fetch of 2 and
(2) written to L1B 208 based on a determination as to whether the updated STH chunk 302 to be written to L1B 208 matches one or more selected data value patterns. The selected data value pattern is preferably L0
Default initializer for IBR202 is ST
H chunk 302 must match one or more of the values that can be initialized to that value.

For example, the updated STH chunk 302
Does not match one of the one or more selected data value patterns, it can be determined that L1B 208 must be updated. Also, to avoid hitting the wrong STH value when L1B 208 is accessed in the future, the relevant data that needs to be kept up to date is
When the state of the appropriate L1B relevance bit indicates that L1B 208 includes, it can be determined that L1B 208 must be updated.

One example of a circuit 600 for determining whether L1B 208 needs to be updated is shown in FIG. Comparator 602 compares the selected data value pattern (s) with updated STH chunk 302. If the two values do not match (this is
4), L1B 208 is updated.
Also, if the L1B relevance bit (ER bit) indicates that L1B 208 contains related data, then L1B 208 needs to be updated to keep the L1B data up to date. As a result, the OR operation 606 of the above two possibilities determines whether or not to update L1B.

One example of a circuit 600 for updating the L1B relevance bit is also shown in FIG. If the two values input to comparator 602 do not match and the corresponding ER bit is not set at that time (e.g., the bit is a logical zero, indicating that no relevant information is presently present in L1B 208). ER bit is set (this is N
Indicated by the output of OR gate 608). Comparator 6
If the two values input to 02 match and the ER bit is set (eg, if the bit is a logical one), L1
The B-related bit is cleared (this is the AND gate 61
0). If none of the above conditions are met, the state of the ER bit is not changed. It should be noted that when the state of the updated ER bit matches the state of the existing ER bit, the updating of the bit can be stopped using appropriate logic.

4. Branch / Leave Queue The branch / leave queue 214 has a new branch prediction structure 210,
It operates in cooperation with the T.12. When a branch instruction is fetched for execution, the speculative new branch prediction structure 210
Update 2. When a branch instruction leaves (i.e., when execution of a branch instruction is completed), the branch retirement queue 214
The non-speculative new branch prediction structure 212 helps correct erroneous L0IBR updates. Branch retirement queue 214 also assists in modifying L0IBR 202 when the instruction pipeline is flushed before the branch has a chance to retire.

The branch-leave queue 214 preferably comprises
Implemented as a 16 entry queue divided into two 8 entry banks. Branch prediction information is L0IBR202
When read from the queue, the prediction information is
4 is written. After the branch leaves, the prediction information is removed from the queue 214. When the pipeline is flushed, entries in the branch evacuation queue 214 are written back to the ISBBR 226 and / or the L0IBR 202.

5. Instruction Pointer Generator The apparatus of FIG. 2 also includes an instruction pointer generator (instruction pointer generator).
pointer generator: hereinafter referred to as IP generator) 216
including. At the center of the IP generator 216 is an IP generator multiplexer (IP GEN MUX) 218. Branch triggers fetched from L0IBR 202 are ORed and IP GEN MUX
218 is passed to the selection control logic 220. The target associated with the trigger is provided to the IP GEN MUX 218 data input. IP GEN MUX 218
1 for the IP address previously generated by
It also receives other data inputs, including addresses that are only incremented. As long as the branch instruction does not go elsewhere,
Each time the instruction bundle is executed, it is incremented by one bundle address. However, due to a branch instruction, bits of the target address may overwrite some or all of the previous value of the IP.

The predicted branch trigger and target are
The predicted branch triggers and targets can be provided to the IP generator 216 without restoring as they are stored in the L0IBR 202 and are fetched upon fetching the corresponding branch instructions. . Also, there is no delay due to the need to fetch the branch history separately, check its validity, calculate the trigger prediction, and (if necessary) fetch or calculate the target address. As a result, the integrated low-level cache 200 and its associated branch prediction hardware allow the redirection of the instruction pointer without the injection of bubbles into the instruction pipeline. The instruction pointer can address the instruction and prediction information stored in a single cache, thus reducing the load that the instruction pointer must drive, and thereby driving the data more quickly. It should be noted that

When the instructions required by the general structure / operation instruction pipeline are not already present in the L0I portion 204 of the unified low level cache, the fetch process places the data in the L1 cache 206 and L1B cache 208. Submit the request you want. The data fetched from L1B 208, if any, is temporarily stored in a structure shown as RAB 222 (buffer) in FIG. Instruction bundle pair
When returned from L1 cache 206, the template of the instruction bundle and any S retrieved from L1B 208
Using the instruction bundle pair, including the TH chunks 302-308, the target of the branch (if any) that is predicted to be taken first in the bundle pair is calculated. If STH chunks 302-308 are not stored in L1B 208, default values for these chunks are generated. The STH chunks 302-308, the number of target bits, the target correlation bits and the instruction bundle pair are all provided to the ISB / lsBBR 226. I
SB / LSBBR 226 serves as a buffer for each of the entries in the unified low-level cache 200.

When an instruction bundle pair is fetched from L0I 204, its corresponding branch prediction information is
Fetched from This includes information for predicting the current fetch result of the branch instruction in the bundle pair. When an instruction bundle pair is fetched from L0I / L0IBR 200, L0IBR target information, if any, is provided as a data input to IP GEN MUX 218,
The trigger prediction information from the associated STH chunk 302 is ORed and presented to the selection logic 218 of the IP GEN MUX 218. In this way, the instruction pointer can be quickly redirected for one cycle.

All L0IBR information is stored in the branch exit queue 214 and new branch prediction structure 210,
212. The information for predicting the next fetch result of the branch instruction is speculatively determined by the speculative new branch prediction hardware 210, and is used for the ISBBR 226 and / or L0.
It should be noted that the information is available before the next fetch of the branch instruction since it is written back to the IBR 202. Therefore, valid next fetch prediction information is always available.

The instruction fetched from the L0I 204 is placed in the instruction buffer 232, and is sent to an appropriate execution unit (for example, the branch execution unit 2) via the rotator mux 234.
36). New branch prediction structures 210, 21
2 and the output of the branch / leave queue 214 are passed to a switching means (eg, a multiplexer 228), after which the updated information is passed through the ISBBR 226 or directly to L
0 Sent to IBR202.

Alternative Embodiments The above disclosure describes a processor that fetches instructions in the form of a bundle pair. As a result, a number of branch prediction information entries mapped to a bundle pair of instructions have been described. However, it is within the scope of the present invention to manage branch prediction in a similar manner for processors fetching instructions alone or in bundles or in the form of bundle groups (such as bundle pairs). Be considered.

The above disclosure also referred to the IA-64 instruction bundle in its entirety. When the disclosed method and apparatus are used to manage prediction information on a per bundle basis, managing the prediction information for alternative bundles is also considered to be within the scope of the present invention. For example, the instruction bundle may include more or less instruction bundles. Instruction bundles can also include different template types or have no templates at all. Such a case is possible, for example, if each instruction syllable can only accept a specific type of instruction, or if each instruction has instruction type information.

Further, an arbitrary number of branch prediction information and / or
Or any type of integrated low level cache 200
It should be noted that it can be stored in The choice of the type of information (and the amount of information) stored in the L0IBR 202 can vary according to the particular application. However, more or less, the prediction information can be stored in L0IBR (and L1B). For example, it is possible to increase 40 bits of IA-64 target information to full 64 bits of IA-64 target information. Similarly, the length of the branch history stored in L0I 204 for each branch instruction can be increased or decreased, or the available branch history (or STH chunk 302
To 308) can be increased or decreased. Further, the various components of the device of FIG. 2 may be implemented in an integrated manner (as shown) or may have only some of the advantages that the device of FIG. 2 provides as a whole. Can also be implemented individually and independently.

Although the preferred embodiments of the present invention have been described above, it should be understood that the principles of the present invention can be implemented in various forms different from the above.

The present invention includes the following embodiments as examples.

(1) A method for managing prediction information used by a processor, comprising: predicting prediction information in a multi-level memory hierarchy including at least one low-level prediction cache (202) and one high-level prediction cache (208). Storing information and attempting to fetch a prediction information value from said low level prediction cache, wherein said prediction information value is not stored in said low level prediction cache; Using the prediction information stored in the low-level prediction cache and periodically updating the prediction information stored in the low-level prediction cache and the high-level prediction cache. And a method comprising.

(2) The low-level prediction cache (202) is
Integrates with the two low-level instruction caches (204) and uses a common cache management structure (300), and instructions, if any, and their corresponding prediction information are maintained in the unified low-level cache (202) The method of (1) above, further comprising the step of:

(3) A method for managing prediction information related to a branch instruction fetched by a processor, comprising:
Each time a branch instruction is fetched from one low-level instruction cache (204), prediction information associated with the branch instruction, including information predicting the current fetch result of the branch instruction, is stored in one or more Substantially in parallel with fetching from the cache (202), (a) execute the branch instruction if the information for predicting the current fetch result of the branch instruction predicts that the branch instruction will be taken; The instruction pointer is updated according to the information for predicting the current fetch result of the instruction (216), and (b) predicting the next fetch result of the branch instruction based on the branch instruction and the fetched prediction information. Determining 210 information to be stored and storing updated prediction information associated with the branch instruction and including the information for predicting a next fetch result of the branch instruction in the one or more caches. That The method comprising.

(4) The information for predicting the current and next fetch results of the branch instruction includes trigger information indicating whether the branch instruction is taken or not taken, and the trigger information indicating that the branch instruction is taken. The target information indicating a branch destination of the branch instruction.

(5) The method according to (4), wherein the prediction information related to the branch instruction further includes branch history information, and the method predicts a next fetch result of the branch instruction. Substantially updating the branch history information in response to the trigger information forming part of the information predicting the current fetch result of the branch instruction, substantially in parallel with the step (210) of determining the branch instruction. Method.

(6) The method according to (3), wherein the processor fetches the instruction in the form of a bundle (100),
The prediction information retrieved from and stored in the one or more caches (202) is, for each bundle,
(a) trigger prediction information indicating prediction of whether each of the branch instructions in the bundle is taken or not taken; and (b) when the trigger information predicts that one or more branch instructions in the bundle are taken, Target information indicating a branch destination of a branch instruction predicted to be taken first, and when extracting the prediction information related to the branch instruction, extracting prediction information associated with each of the branch instructions in the same bundle And determining the information for predicting the next fetch result of the branch instruction based on the branch instruction and its fetched prediction information, wherein the fetched branch instructions in the same bundle and their fetched predictions Determining information predicting a next fetch result for each of the branch instructions in the same bundle based on the information (210)
And when storing updated prediction information associated with the branch instruction in the one or more caches, storing updated prediction information associated with each of the branch instructions in the same bundle. Including methods.

(7) The method according to (3), wherein the processor fetches instructions in a bundle group, and the prediction information fetched from the one or more caches (202) and stored therein. For each bundle group, (a) trigger prediction information indicating prediction of whether each of the branch instructions in the bundle group is taken or not taken, and (b) the trigger information is one or more in the bundle group. When predicting that a plurality of branch instructions will be taken, target information indicating a branch destination of a branch instruction predicted to branch first is provided, and when extracting the prediction information related to the branch instruction, Retrieving prediction information associated with each of the branch instructions; and fetching a next fetch of the branch instruction based on the branch instruction and the retrieved prediction information. Predicting the next fetch result of each of the branch instructions in the same bundle group based on the fetched branch instructions in the same bundle group and their fetched prediction information when determining the information for predicting the outcome. Determining what information to do (210)
And storing updated prediction information associated with each of the branch instructions in the same bundle group when storing updated prediction information associated with the branch instruction in the one or more caches; A method that includes

(8) The one or more caches include:
A prediction cache (202) integrated with the low level instruction cache (204) to form an integrated low level cache (200)
Wherein the branch instruction and the branch instruction are fetched from the unified low-level cache such that information predicting a current fetch result of the branch instruction is fetched from the unified low-level cache each time the branch instruction is fetched from the unified low-level cache. (3) further comprising storing the information predicting a current fetch result of a branch instruction in the unified low-level cache.
The method described in.

(9) An apparatus for predicting the result of a branch instruction fetched by a processor, comprising: one low-level instruction cache (204); and the current value of any branch instruction stored in said low-level instruction cache. One or more branch prediction caches (202) for storing branch prediction information including information for predicting a fetch result, and corresponding branch instructions and branch predictions from the low-level instruction cache and the one or more branch prediction caches Logic means (216) for fetching information respectively, and logic means (210) for determining information for predicting the next fetch result of the fetched branch instruction based on the fetched branch prediction information
And logic means (226, 228) for storing updated prediction information in said one or more branch prediction caches.

(10) The apparatus according to (9), wherein the low-level instruction cache (204) and the one or more branch prediction caches (202) form an integrated low-level cache (202). .

[Brief description of the drawings]

FIG. 1 is a block diagram showing an instruction bundle of IA-64.

FIG. 2 is a block diagram illustrating various components of a processor, including a multi-level prediction information memory hierarchy and an integrated low-level instruction / branch prediction cache.

FIG. 3 is a block diagram of a preferred embodiment of the integrated low-level instruction / branch prediction cache of the memory hierarchy of FIG. 2;

FIG. 4 is a block diagram illustrating storage of encoding formats of branch history and trigger prediction information.

FIG. 5 is a block diagram of a typical circuit for determining an initial state of “relevance information” indicating whether to store relevant information in a high-level prediction cache of the memory hierarchy of FIG. 2;

FIG. 6 is a block diagram of an exemplary circuit that determines the need for updating a high-level prediction cache of the memory hierarchy of FIG. 2 and updating the relevancy information referenced in FIG.

[Explanation of symbols]

 Reference Signs List 200 Integrated low-level cache 202 Low-level prediction cache 204 Low-level instruction cache 208 High-level prediction cache 210 Speculative new branch prediction structure 216 Instruction pointer generator 300 Common management structure

 ──────────────────────────────────────────────────続 き Continued on front page (72) Inventor Stephen Earl Andy 5916 Linden View Court, Fort Collins, Colorado 80524 USA

Claims (1)

[Claims] 1. A method for managing prediction information used by a processor, the method comprising: storing prediction information in a multi-level memory hierarchy including at least one low-level prediction cache and one high-level prediction cache; Attempting to fetch a prediction information value from the low-level prediction cache and attempting to fetch the prediction information value from the high-level prediction cache when the prediction information value is not stored in the low-level prediction cache. And periodically updating the prediction information stored in the low-level prediction cache and the high-level prediction cache using the prediction information stored in the low-level prediction cache.