Processing device with micro branch target buffer for branch prediction

Abstract

An integrated circuit (100) includes an instruction processing circuit (108) for processing a plurality of program instructions and an instruction prediction circuit (124). The instruction prediction circuit includes a circuit (128) for detecting a second occurrence of a same program loop sequence of program instructions. The instruction prediction circuit also includes a circuit (128) for predicting a number of iterations of the same program loop sequence of program instructions in response to the circuit for detecting detecting a second occurrence of the same program loop sequence of program instructions includes a same number of iterations as a first occurrence of the same program loop sequence of program instructions.

Description

BACKGROUND

[0001] Example embodiments relate to processing devices, such as microprocessors or digital signal processors, that can be formed as part of an integrated circuit included on a system on a chip (SoC). More specifically, embodiments relate to a processing device having a micro-branch target buffer for a branch predictor.

[0002] Processing devices execute many types of program instructions, one type of which is a branch instruction. A branch instruction is an instruction that can change the execution of program instructions to deviate from the sequential order of instructions when a condition associated with the branch instruction is satisfied. If the condition is satisfied such that execution changes from sequential execution, the branch is said to be taken; conversely, if the condition is not satisfied such that execution continues with sequential execution, the branch is said to be not taken.

[0003] Modern processing devices typically process sequences of instructions through a pipeline, or the device can include multiple instruction pipelines, and each pipeline can individually process a respective sequence of instructions. A pipeline, or each such pipeline, includes several stages, and each performs one or more associated actions for instructions being processed at the stage. Example pipeline stages, and in a common order, can include instruction fetch, instruction decode, instruction execution, memory access, and instruction writeback, some of which are modified or omitted in certain processors, such as in certain digital signal processors.

[0004] The combination of instruction pipelining and branch instructions can be computationally very powerful, but can also provide additional complexity. For example, without added aspects as described below, when a branch instruction reaches the execution stage and then is determined to be taken, there is a possibility that information in stages before the execution stage must be discarded, often referred to as flushing, which occurs more typically in earlier processors. In other words, given the sequential nature of the pipeline, a first instruction that is proceeding through the pipeline can be followed by a second sequential instruction. However, if the first instruction is a branch that is taken, the second instruction that follows it and is on its way to execution cannot be allowed to execute and write its results, so the results only occur when the branch is not taken, not when it is taken. Thus, in some instances, the second instruction (and any other instructions in the pipeline after the first instruction) is flushed, and then the pipeline is loaded with the next instruction to follow the taken branch, which can be referred to as the target instruction.

[0005] In view of the foregoing, branch prediction can be performed in a processing device by a branch predictor. Branch prediction can involve one or both of two different aspects: (i) predicting the branch instruction outcome, i.e., whether the branch is taken (or not taken); and (ii) predicting the target address of the next instruction when the branch is taken.

[0006] While all of the above aspects can improve processing device performance, in at least some contexts, inadequate branch prediction can degrade performance, and in fact, can degrade performance below that without any prediction. For example, if a branch instruction is incorrectly predicted (as to outcome or target instruction), there is a disruption in the flow of operations to correct the incorrect prediction. In more detail, if a branch instruction is predicted to not be taken, but then arrives at the execution stage and is taken, the instructions following the instruction in the pipeline are incorrect and must be flushed or otherwise invalidated, followed by fetching the correct target instruction. Various other examples are known in the art.

[0007] Accordingly, example embodiments are provided that can improve certain of the above-noted concepts, as further detailed below. SUMMARY

[0008] One embodiment includes an integrated circuit comprising both an instruction processing circuit and an instruction prediction circuit for processing a plurality of program instructions. The instruction prediction circuit comprises circuitry for detecting a second occurrence of a same sequence of program loops of program instructions as a first occurrence of the same sequence of program loops of program instructions. The instruction prediction circuit further comprises circuitry for predicting a number of iterations of the same sequence of program loops of program instructions in response to the circuitry for detecting detecting that the second occurrence of the same sequence of program loops of program instructions comprises a same number of iterations as the first occurrence of the same sequence of program loops of program instructions.

[0009] Other aspects are also described and claimed. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1 A block diagram of a processing device is illustrated.

[0011] Figure 2A An example of a 16-line sequential program pseudo-code instruction sequence is illustrated as Figure 1 An example of a program portion of a processing device.

[0012] Figure 2B Another pseudo-code instruction sequence is illustrated that depicts an example of a hyperblock program loop.

[0013] Figure 3 An illustration Figure 1 More details of a micro-BTB.

[0014] Figure 4 An illustration Figure 1 A flowchart of a method of a portion of the operation of a BP block.

[0015] Figure 5 An illustration Figure 1 A schematic diagram of additional details of an example embodiment of a BP block 124 of DETAILED DESCRIPTION

[0016] Figure 1 A block diagram of a processing device 100, such as a microprocessor or digital signal processor, that can be formed as part of an integrated circuit included on a system on a chip (SoC) is illustrated. For example, the processing device 100 can be implemented in conjunction with or as a modification to various processors commercially available from Texas Instruments Incorporated, including its TMS3207x series of processors. The processing device 100 is illustrated in simplified form to provide those skilled in the art with an understanding of example embodiments.

[0017] The processing device 100 includes a central processing unit (CPU) core 102, which can represent one or more CPU cores. The CPU core 102 is coupled to a program memory (P_MEM) block 104 and a data memory (D_MEM) block 106. Each of the P_MEM block 104 and the D_MEM block 106 can and most likely represent a hierarchical memory, including one or more controllers that access one or more levels of memory (e.g., via a cache), where such memory can include both internal and external memory. In general, the P_MEM block 104 provides program instructions to the CPU core 102, and the D_MEM block 106 can be read or written by the CPU core 102. Additionally and by way of example, certain aspects of such memory can be found in commonly owned U.S. Patent Application Nos. 16 / 874,435, filed May 14, 2020, and 16 / 874,516, filed May 14, 2020 (Docket TI-91022 and TI-91023, respectively), and are incorporated by reference herein in their entirety.

[0018] The CPU core 102 includes several stages that collectively provide an instruction pipeline 108. By way of example and to potentially reduce the total stages for simplicity, Figure 1The pipeline 108 is illustrated as including three stages, each of which can include several stages (not shown individually), namely, an instruction fetch (IF) stage 110, an instruction dispatch and decode (DDE) stage 112, and an execution (EX) stage 114; and, the DDE stage 112 cooperates with two potential sources of data, namely, a register file 116 and a stream engine 118. Each pipeline stage represents successive actions taken with respect to program instructions. Generally, the IF stage 110 fetches instructions from the P_MEM block 104, where the address of the fetched instruction is indicated or determined in response to a program counter (PC) 120. In one embodiment, the IF stage 110 can include three stages, including program address generation, program memory access, and instruction program reception. It should also be noted that, as used herein, an "instruction" can include several bits, which collectively include several instructions. For example, a fetch can have a 512-bit instruction packet, which can represent a single executable instruction, or can be subdivided into individual instructions, e.g., up to 16 individual instructions, each formed of 32 bits. An example of this can be implemented, for example, where the processing device 100 is implemented as a single-instruction multiple-data (SIMD) processor including parallel execution units, each of which is operable to execute a respective instruction fetched as part of a larger instruction packet concurrently. The fetched instruction is then dispatched and decoded by the DDE stage 112. In one embodiment, the DDE stage 112 can include three stages, including a dispatch stage that buffers an instruction packet and potentially splits the packet based on whether it includes multiple instructions, followed by first and second instruction decode stages to decode the instruction packet (which at this point can be split from the dispatch into individual instructions). Also in connection with completing the DDE stage 112, data operations for the decoded instruction can be sourced from the register file 116 or the stream engine 118, where the stream engine 118 is a separate mechanism that in some cases can stream data, e.g., in connection with certain instruction loops. Finally, the decoded instruction (packet) is committed to the EX stage 114 and executed by the EX stage 114 in connection with one or more operands from the register file 116 or the stream engine 118. In one embodiment, the EX stage 114 can include several (e.g., five) execution stages, which can also include memory reads and writes, such that there is no separate writeback stage.

[0019] The core CPU 102 also includes a branch predictor (BP) block 124, a more detailed example of which is shown later in Figure 5 "Branch Prediction in the Alpha 21464 Microprocessor," Proceedings of the 2000 International Symposium on Microarchitecture, November 2000, pp. 182-191. As introduced earlier, branch prediction can include one or both of predicting whether to take (or not take) a branch instruction and predicting a target address of a branch instruction when the branch instruction is taken. To support some of this functionality, the BP block 124 includes an exit history table (EHT) 126 and a micro-branch target buffer (micro-BTB) 128.

[0020] Generally, the EHT 126 is populated with instruction history information based on instruction execution and predictions from those executions. Thus, the EHT 126 can operate in some examples using known techniques to store or track sequences of values in the PC 120 in order to determine certain historical patterns and store results from those determinations, including whether an instruction at a particular PC value (instruction address) is a branch instruction. For branch instructions, when a prediction is determined to be inaccurate, i.e., when a predicted instruction is predicted to be taken but is executed as not taken, or when a predicted instruction is predicted to be not taken but is executed as taken, the EHT 126 information is updated and can also include a history (and thus, a prediction) of the target address to which execution changes when the branch instruction is taken. Further, the EHT 126 stores history information (e.g., metadata) for sequences of PC 120 values corresponding to sequences of program instructions described subsequently as hyperblocks. For introductory purposes, generally, a hyperblock is a sequence of program instructions beginning with a first instruction representing an entry instruction in the hyperblock, followed by one or more instructions, one of which is a branch instruction that is taken. The EHT 126 history information includes the address of the hyperblock entry instruction, an offset (address difference) between the entry instruction and a subsequent exit branch instruction (i.e., a branch instruction taken after the entry instruction), and a type indicator for the exit branch instruction. Once the offset is established in the EHT 126, the offset thereafter can be used as a prediction of at what instruction the hyperblock will exit relative to the instruction address of the beginning of the hyperblock, and also potentially as a prediction of whether the exit branch instruction will be taken and the target address when the branch is taken. Further, the EHT 126 information can indicate when the target address of the taken exit branch instruction returns to the same target address in the hyperblock containing the exit instruction in successive executions of the branch instruction, thereby indicating a loop behavior, i.e., instruction execution returns from the end of the same hyperblock back to the beginning. Further, when the EHT 126 identifies such a branch instruction (hereinafter referred to as an exit loop branch instruction), the branch type (loop) is retained as history information in the EHT 126 along with the hyperblock entry instruction address and offset, where the instruction address can be stored in the form of a tag (folded down entry PC address). Also for the same occurrence of a loop, a data set entry is initialized in the micro-BTB 128 (see Figure 3). The dataset stores the superblock exit loop branch instruction address, which can be determined from the superblock entry address plus the offset stored in EHT 126, along with a count of the number of iterations of the loop occurrence determined when the exit loop branch instruction is no longer taken, as further detailed subsequently. Thereafter, when pipeline 108 is to process the same loop again, the loop iteration count can be accessed from micro BTB 128 and provide a prediction of the number of iterations of the loop, however it exits by no longer taking the exit branch instruction, in which case instruction sequencing continues for the next instruction after the loop exit branch instruction. In this regard, BP block 124 receives input 124 IN that provides a current instruction address indicator value (or some portion of the value) of PC 120, from which BP block 124 provides various options to predict whether a branch instruction (including a branch instruction that leads to a loop) is taken. For example, EHT 126 receives input 124 IN and outputs a branch type indicator thereof that indicates the type of branch instruction, such as a loop exit branch instruction or other branch instruction. When the branch type is not a loop exit branch instruction, branch predictor block 124 (e.g., EHT 126) can predict the branch instruction behavior (taken / not taken and target address) in a manner that can be determined by those skilled in the art. However, in example embodiments, when the branch type is a loop exit branch instruction, micro BTB 128 is checked to determine whether it contains valid information corresponding to the instruction, and if so, the output of micro BTB 128 is selected to indicate (predict) the number of times the loop ending with the loop exit branch instruction is taken. Thus, this prediction or other taken / not taken predictions of BP block 124 provide output 124 OUT that provides a signal to IF stage 110, such that once a taken / not taken prediction is provided, the next instruction can be indicated to the controller of P_MEM block 104, such that the next instruction at the predicted target address can be fetched.

[0021] Figure 2A An example of 16 lines of sequential program instructions (shown as pseudo code) is illustrated as a program portion 200 stored in P_MEM block 104. Any or all of the program instructions can be processed (fetch, decode, execute, etc.) by processing device 100, and it provides an example of a context. Each program portion 200 instruction has a corresponding PC instruction address IA <x>where each instruction address is sequentially numbered relative to the other instruction addresses, consistent with sequential processing of the instructions. In other words, if the program flow has not changed, each instruction is processed in sequential order of its address, starting with PC IA<01>, followed by PC IA<02>, and so on to PC IA<16>, and where the sequential pass through addresses is accomplished by the advancement (e.g., incrementing) of the PC 120 Figure 1 ) of the PC. One skilled in the art can appreciate various types of pseudo-code syntax. For example, the instruction at PC IA<01> is the product of the contents at registers A8 and A9, where the result is stored on register A10. As another example, there are a number of predicted branch instructions of the format "[Ay] B Tz", where "B" indicates a branch instruction predicted on register [Ay], and if satisfied, points to a relative target Tz; for example, at PC IA<02>, if the predicate at register [A0] is satisfied, the program flow branches to the instruction at target T3 (which is at IA<09> in absolute addressing).

[0022] Figure 2A Four branch flows BF1 through BF4 are also illustrated along the left side of the graph in arrows. Each branch flow BFy is illustrated as an arrow starting with the taken branch instruction and ending with the target instruction resulting from the taken branch instruction. For example, branch flow BF1 occurs when the branch instruction at PC IA<02> is taken and the program flow changes to target T3, which is the instruction at PC IA<09>. As another example, branch flow BF2 occurs when the branch instruction at PC IA<11> is taken and the program flow changes to target T2. One skilled in the art will appreciate the remaining branch flow examples.

[0023] Figure 2A The program portion 200 also illustrates the concept of instruction superblocks, which are shown by example as integer N (e.g., N = 4) superblocks H1, H2, H3, and H4. The division between each superblock Hn is based on the real-time programming construct of branch instruction behavior, i.e., the start and end of the superblock, and thus the sequence of instructions between the start and end are defined based on the actual execution (or prediction) behavior of their branch instructions. Specifically, each superblock Hn identifies a group of instructions that starts with an entry point instruction and ends with a taken branch exit instruction. The entry point instruction can occur at the beginning of several instructions, or can be a target instruction from a taken branch in another superblock. For example, in the example of the program portion 200, the entry point instruction for superblock H1 is the instruction at PC IA<01>, the entry point instruction for superblock H2 is the instruction at PC IA<02>, the entry point instruction for superblock H3 is the instruction at PC IA<11>, and the entry point instruction for superblock H4 is the instruction at PC IA<12>. Figure 2A When, for example, the branch instruction at PC IA<02> exhibited by branch flow BF1 is taken to target instruction T3, the T3 target instruction (at address PC IA<09>) becomes the entry point instruction for hyperblock H3. Thus, the hyperblock entry point instruction is the instruction to which program flow can be directed, such that the instructions beginning with the entry point instruction are processed sequentially in the corresponding hyperblock, and then end with the taken branch ("exit") instruction. Thus, Table 1 below indicates each hyperblock and its corresponding entry point instruction address.

[0024] Table 1

[0025] Hyperblock Entry point instruction address H1 IA<01> H2 IA<05> H3 IA<09> H4 IA<12>

[0026] The hyperblock exit instruction ends the hyperblock, and is either a taken branch instruction to a different hyperblock, or is the end of the program (or program portion). For example, starting at PC IA<01>, whose first instruction address is target T1 from another hyperblock, and taking its next sequential instruction, which is at PC IA<02>, a branch instruction (to target T3), thereby making the PC IA<02> branch instruction the end of hyperblock H1. Thus, based on this and another point, Figure 2A An example of the taken branch instruction behavior is illustrated, followed by Table 2 below indicating each hyperblock and its corresponding exit instruction address.

[0027] Table 2

[0028] Hyperblock Exit instruction address H1 IA<02> H2 IA<08> H3 IA<11> H4 IA<16>

[0029] A superblock can contain more than one branch instruction that branches program control out of the superblock, and the branch instruction preceding the exit instruction is called an early exit. For example, superblock H4 contains two branch instructions: (i) in PC IA <14> (i) the potential (and early exit) branch to target address T3, as predicted in register A1; and (ii) in PC IA. <16> At the target address T1, the potential (and exit instruction) branch is also predicted in register A0. Therefore, it should be noted that the definition of a superblock ensures that any branch instruction within it can only change the program flow to another superblock, and therefore cannot change it to another instruction between the beginning and end of the same superblock – this definition defines the boundaries of superblocks, as further demonstrated below. Also according to this definition, BP block 124 predicts the first branch in the sequence of superblocks to be adopted, which implicitly suggests that the superblock is predicted to end with the instruction to be adopted. For example, in superblock H1, if the prediction is to adopt PC IA... <02> If the branch instruction is at a certain point, then this must instruct the PC IA... <04> The branch instruction at that point is not part of superblock H1. Conversely, if the prediction uses PC IA... <04> If the branch instruction is at a certain point, then this must instruct the PC IA... <02> The branch instruction at that point is predicted as unused, and in the same situation, superblock H1 will contain instructions from PC IA. <01> To PC IA <04> All four instructions. Furthermore, if the prediction does not employ a branch instruction in the superblock, then the control flow through the superblock is fully sequential and continues to the next sequential superblock.

[0030] Figure 2B Describe another pseudocode instruction sequence, such as following... Figure 2A Following the instruction sequence (and superblock), thereby enabling PC IA <17> Starts with and includes PC IA <20> The four instructions that conclude the process. Therefore, when not used in PCIA... <16> End of section Figure 2A When the branch instruction of superblock H4 is executed, it can reach... Figure 2B Sequence. Furthermore... Figure 2B Sequences illustrate instances of superblocked program loops, which are now introduced and addressed in various aspects of example implementations, as described below. Figure 2B In the example, an instance of a superblocked program loop caused by branch flow BF5 is indicated by PC IA. <20> The branch instruction at that point directs the program flow to target T5, that is, to PCIA. <17> The same superblock entry point instruction at the same location. This example illustrates that when a sequence of instructions ends with an exit branch instruction, a superblock program loop occurs. When the exit branch instruction is adopted, the program flow returns to the entry point instruction of the same sequence preceding the exit branch, without any intervening branch between the entry point instruction and the adopted exit branch instruction. Therefore, although Figure 2A The branch flows BF1 to BF4 in the middle are between different superblocks, but... Figure 2B In this process, branch flow BF5 returns from the superblock exit branch instruction to the beginning of the superblock, thereby providing real-time construction of the superblock program loop. As previously described, when an instruction sequence is executed and results in a loop, the flow (e.g., BF5) can be detected by historical information accumulated in EHT 126, and certain metadata describing the loop is stored in EHT 126, such as the loop entry address (e.g., ...). Figure 2B PC IA <17> ) and the offset from the loop entry address to the location of the exit branch instruction (e.g., offset = 3, from Figure 2B PC IA <17> To PC IA <20> It was also at that time that, if the entry point of the detected loop was not already in the micro BTB 128, an entry point was created by overwriting or evicting the oldest loop in the dataset characterized in the micro BTB 128, where such a dataset will be described in further detail later. In any case, program loops can be common in certain types of code, particularly in some digital signal processors programmed with frequently used predictive branch instructions, such as... Figure 2B The example is shown below. Given the possibility or commonality of program loops, the processing device 100 is improved with a micro BTB 128 that predicts such loops in order to improve processing throughput, as further detailed below.

[0031] Figure 3 illustrate Figure 1 More details about the micro BTB 128. The micro BTB 128 includes circuitry for storing integer Z superblock program loops of a characteristic dataset, such as dedicated discrete registers 300, each set having three distinct values. The micro BTB 128 also includes an associated interface controller 302 for reading and writing register values ​​in conjunction with the interface to the BP block 124. Figure 3 The Z set is defined as sets 300.1, 300.2, ..., 300.Z. Each three-value set 300.Z corresponds to and characterizes certain aspects of the corresponding entity in one of the Z distinct superblock program loops detected by the processing device 100 during the processing of program code. In each Z set, the three distinct program loop values ​​are the loop tag address (LTA), the total loop iteration count (TLIC), and the valid bit (VB). Therefore, in Figure 3 In this context, each set 300.z is presented as having three values, each referenced by an end indicator of z to show the association of the value with the corresponding set z in the total number of sets Z. For example, for the first detected superblock program loop, set 300.1 indicates the values ​​LTA1, TLIC1, and VB1 corresponding to set 300.1. As another example, for the second detected superblock program loop, set 300.2 indicates the values ​​LTA2, TLIC2, and VB2 corresponding to set 300.2. Those skilled in the art will understand similar examples. Generally, LTAz is a 47-bit register data value that identifies the PC address (or a portion thereof) of the detected program loop exit branch instruction; that is, LTAz is a tag pointing to the end of the superblock, for example, it can be identified from the superblock entry instruction address plus the offset to the source exit branch instruction; or, LTAz can point to the superblock entry instruction address. TLICz is an 8-bit register that identifies the predicted total loop iteration count, i.e., the total number of iterations (up to 2^3) that the entire superblock program loop will go through before exiting the superblock. 8 =256), that is, the number of times the entire sequence from the superblock entry instruction to the LTA identified after the entry instruction, returned by the used exit branch, is executed before exiting the loop when its loop exit branch instruction is not used. Finally, VBz is a 1-bit register that indicates whether the corresponding values ​​of TLICz and LTAz are expected to be a valid prediction of the loop count in TLICz, thereby indicating the valid result in the processing device 100 using the set value to predict the number of future loop iterations of the same superblock program loop. Each of these values ​​is filled, updated, and replaced by the interface controller 302, as detailed below.

[0032] Figure 4 Explanation in Figure 3 In the context of interface controller 302 filling, updating, and replacing values ​​in dedicated register 300 Figure 1 A flowchart of method 400 for the operation of BP block 124. Therefore, unless otherwise explicitly stated, although method 400 is described according to the steps of operation, the circuitry used to perform these steps may be divided among EHT 126, micro BTB, and other circuitry identified by those skilled in the art in BP block 124 or core 102. Method 400 is described and illustrated to detail various functions and sequences that may be implemented in one or both of hardware circuitry and software / firmware / state machine control.

[0033] Method 400 begins with step 402. Step 402 inputs the current value of PC 120 (instruction address or a portion thereof) into EHT 126. For example, returning to... Figure 2A In step 402, PC IA can be entered. <01> To PC IA <16> either of them (or, in) Figure 2B In particular, step 402 is a conditional check that controls the flow of the method based on whether the input PC value corresponds to the start of a superblock (i.e., the first instruction in an instruction sequence that ends with an adopted branch instruction). Recall that EHT 126 contains various historically determined or stored instruction information. Thus, the determination of step 402 can be made, for example, by using the input PC value from step 400 as a lookup in EHT 126 that stores an indication of whether the instruction identified by the PC value is the start of a superblock from a previous occurrence of processing of the instruction. If the PC value does not identify an instruction at the start of a superblock (e.g., PC IA<03>), then the method 400 proceeds from step 402 to step 404. If the PC value does identify an instruction at the start of a superblock (e.g., PC IA<17>), then the method 400 proceeds from step 402 to step 406.

[0034] Step 404 is a conditional check that controls the flow of the method based on whether the input PC value from step 402 corresponds to the start of a superblock (i.e., the first instruction in an instruction sequence that ends with an adopted branch instruction that is the first adopted branch after the first instruction). Recall that EHT 126 contains various historically determined or stored instruction information. Thus, the determination of step 404 can be made, for example, by using the input PC value from step 402 as a lookup in EHT 126 that stores an indication of whether the instruction identified by the PC value is the start of a superblock from a previous occurrence of processing of the instruction. If the PC value does not identify an instruction at the start of a superblock (e.g., PC IA<03>), then the method 400 proceeds from step 404 back to step 402, where the next PC value can be processed. If the PC value does identify an instruction at the start of a superblock (e.g., PC IA<17>), then the method 400 proceeds from step 404 to step 406. Figure 2A Figure 2B Step 406 is a conditional check that controls the flow of the method based on whether the superblock identified in the previous step 404 is a superblock program loop, i.e., a superblock that ends with an adopted branch exit instruction that returns flow to the start instruction in the superblock (e.g., PC IA<17> to PC IA<20>). Again, the determination of this step 406 can be made, for example, by using the input PC value from step 402 as a lookup in EHT 126 that stores an indication of whether the superblock identified by the PC value is a superblock program loop from a previous occurrence of processing of the superblock. If the superblock is not a superblock program loop, then the method 400 proceeds from step 406 to step 408. If the superblock is a superblock program loop, then the method 400 proceeds from step 406 to step 410.

[0035] Step 408 is a conditional check that controls the flow of the method based on whether the input PC value from step 402 corresponds to the start of a superblock program loop (i.e., the first instruction in an instruction sequence that ends with an adopted branch instruction that returns flow to the start instruction in the superblock program loop). Recall that EHT 126 contains various historically determined or stored instruction information. Thus, the determination of step 408 can be made, for example, by using the input PC value from step 406 as a lookup in EHT 126 that stores an indication of whether the instruction identified by the PC value is the start of a superblock program loop from a previous occurrence of processing of the instruction. If the PC value does not identify an instruction at the start of a superblock program loop (e.g., PC IA<03>), then the method 400 proceeds from step 408 back to step 402, where the next PC value can be processed. If the PC value does identify an instruction at the start of a superblock program loop (e.g., PC IA<17>), then the method 400 proceeds from step 408 to step 410. Figure 2B

[0036] ​​From step 406 detecting that the superblock is not a superblock program loop, step 408 processes the (non-loop) branch instruction in the superblock according to other branch prediction processes. For example, if the branch instruction is predicted not taken, it can be implicitly treated as not taken, in which case there is no prediction, but the instruction is processed through all stages, and if execution confirms the implicit not-taken expectation, then the instructions following the not-taken branch are processed, and so on. Alternatively, if there is a misprediction, then the pipeline 108 can be flushed, and a new prediction can be applied, which is targeted to run the prediction process independently of CPU execution, and as far ahead as possible (e.g., eight superblocks in one embodiment) before the core processing catches up. In this process, each time a superblock is confirmed, the BP 124 can re-predict one superblock. If at any time there is a misprediction, then the above process restarts after correcting the misprediction in the EHT 126 and the micro-BTB 128 (and associated 512 shown in FIG. 5). In any case, after this other activity, generally shown by step 408, the method 400 returns from step 408 to step 402. Figure 5

[0037] From step 406 detecting that the superblock is a superblock program loop, step 410 is a conditional check that controls the flow of the method based on whether the superblock program loop detected by step 406 is stored in the micro-BTB 128. For example, the determination of step 410 can be made by using the PC value in each tag LTA1 through LTAZ input from step 402 and more specifically input to the special register 300 as a lookup in the micro-BTB 128. Thus, if no match occurs between the PC input and the LTAz entry in the special register, the condition of step 410 is not met, and the method 400 continues from step 410 to step 412. If such a match occurs, the condition of step 410 is met, and the method 400 continues to step 414.

[0038] ​When a hyperblock program loop has been detected but is not in the micro-BTB 128, step 412 is reached. Recall from above that when a hyperblock program loop is detected from actual instruction execution, at this time an entry is created or exists in the EHT 126 with the hyperblock start (entry instruction) address and exit instruction offset, and also an initial entry is created into the dataset in the micro-BTB 128, which entry corresponds to the detected hyperblock program loop. It is now noted that when the dataset is created in the micro-BTB 128, its valid bit VBz is set to invalid, and its total loop iteration count TLICz is set to the number of times the loop is executed, i.e., one plus the number of times the branch exit instruction is taken. Thus, typically when a given hyperblock has been previously detected, there will be a corresponding entry in the micro-BTB 128; however, after creating such an initial entry, it is also possible that after creating the entry, other instructions are executed that lead to other entries in the micro-BTB 128, which can result in a final overwrite of the previous dataset for a given hyperblock program loop. Thus, in such a case, step 412 can be reached, in which case at this time the micro-BTB 128 does not store or no longer stores the characterization of the hyperblock program loop. In response, step 412 starts a set of three values into location 300.z in the special register 300. The information written is either newly written into an empty register set, or by overwriting the oldest (first-in-first-out) data in the special register 300, thus indicating that the micro-BTB 128 provides a mechanism for tracking which dataset in its register 300 is the oldest. Figure 4 Further indicated is the starting (e.g., writing or otherwise initializing) of three different data elements into the selected location 300.z, namely: (i) the hyperblock program loop exit address (the current PC value plus the offset to the taken exit branch instruction, as can be obtained from the EHT 126); (ii) the total loop iteration count TLICz is set to the initial value of one; and (iii) the valid bit VBz is set to the invalid indication, which for example purposes is the value zero. Next, the method 400 continues from step 412 to step 416.

[0039] Step 416 returns the execution of program instructions by the core 102 to the start of the loop (e.g., the hyperblock start) that was previously detected in step 404, and this causes the method 400 to step through steps 406, 410, and 412. Thus, returning to Figure 2B For example, if the given superblock program loop reaches step 416 for the first time, the first reaching of the step will be followed by one iteration of all the superblock program loop instructions in order to reach and execute the loop exit branch instruction, and the second time is when step 416 processes the loop for the second time; thus, after two iterations of the entire loop, the first reaching of step 416 that binds a new data set entry into micro BTB 128 will occur, such that incrementing TLICz sets it to a value of 2, indicating two full iterations of the loop's instructions. Then, method 400 continues from step 416 to step 418.

[0040] Step 418, reached from completion of execution of all instructions in the superblock program loop from step 416, is a conditional check that controls the method flow based on whether the superblock program loop is to be taken again (i.e., the loop exit branch instruction is to be taken again to return to the beginning of the program loop) or not taken (i.e., the loop exit branch instruction is not taken to continue program flow with the next sequential instruction after the loop exit branch instruction). Since step 418 is reached via steps 410 (and 412 and 416), a fully valid data set for the program loop has not yet been provided in micro BTB 128 (i.e., VBz = 0). Thus, unless a prediction is provided elsewhere in addition to micro BTB 128, there is no valid prediction of whether the loop exit branch instruction is to be taken, and thus instead, one can wait until the loop exit branch instruction is executed to determine whether the program loop is to be taken again. If the superblock program loop is to be repeated for another iteration, method 400 returns from step 418 to step 416. If the superblock program loop is not to be repeated, method 400 returns from step 418 to step 402. It should be noted that when the latter condition occurs, micro BTB 128 will store a data set for the program loop whose superblock tag address is indicated by LTAz, the total number of times the particular superblock program loop is processed as TLICz, but the valid bit VBz will still indicate invalid.

[0041] Returning to step 414, recall that it is reached when step 410 determines that the PC value corresponding to the superblock program loop detected in step 406 is stored in the micro-BTB 128 as a tag address LTAz. Next, step 414 determines whether the valid bit VBz for the loop of the data set 300z that characterizes the detected superblock program loop is valid. If the valid bit VBz indicates that the data set is not valid, then the method 400 continues from step 414 to step 420. If the valid bit VBz indicates that the data set is valid, then the method 400 continues from step 414 to step 422.

[0042] Step 420 is reached when a data set 300z for a detected superblock program loop is stored in the micro-BTB 128, but when the valid bit VBz for the data set indicates that the data set is currently not valid. Recall that this invalid indicator can occur when a superblock program loop has been identified by the metadata in the EHT 126 and an initial entry in the micro-BTB 128 has been created accordingly, or when a superblock program loop is detected but does not have a data set entry for it in the micro-BTB 128 at the time. As now described, the valid bit VBz is changed to valid when a second occurrence of ending all iterations of the same superblock program loop occurs, provided that the number of iterations for both the first and second occurrences is the same. In this regard, a first step 420 initializes a temporary loop iteration counter TEMP_TLIC to a value of 1. Next, the method 400 continues from step 420 to step 424.

[0043] Step 424 is similar to step 416 described above, in that step 416 applies to the first occurrence of a superblock program loop iteration, i.e., an occurrence that is not yet characterized in micro BTB 128, while step 416 applies to the second occurrence of such a superblock program loop iteration after it is characterized, albeit still marked as invalid. Thus, step 424 also returns execution of program instructions by core 102 to the beginning of the loop (e.g., the superblock beginning) previously detected in steps 404 and 406, whereby core 102 again processes the instruction at the beginning of the superblock program loop, followed by processing all instructions in the superblock through the loop exit branch instruction again recognized when the sum of the offset and PC 120IA indicates the loop exit branch instruction address. At this point, temporary total loop iteration count TEMP_TLIC is incremented, so that for example when a given superblock program loop reaches step 424 for the first time, it indicates that the superblock program loop is processed for the first time to detect the superblock program loop, and then the loop is processed by step 424 for the second time, in which case reaching step 424 will be the second iteration of the entire superblock program loop, so that incrementing TEMP_TLIC sets it to a value of 2, indicating two complete iterations of the program loop's instructions. Method 400 then continues from step 424 to step 426.

[0044] Step 426, which is reached from step 424 completing a program loop iteration, is a conditional check that controls the method flow based on whether the superblock program loop is to be taken again (i.e., whether the loop exit branch instruction is taken again to return to the beginning of the program loop) or not taken to have program flow continue with the next sequential instruction after the loop exit branch instruction. Since step 426 is reached via steps 414 (and steps 420 and 424), a full valid data set for the program loop has not yet been provided in micro BTB 128, because valid bit VBz still indicates invalid. Thus, there is no valid prediction in micro BTB 128 of whether the loop exit branch instruction is taken or not, so instead core 102 executes the loop exit branch instruction to determine whether the program loop is taken again. If execution indicates that the branch is taken, i.e., that the superblock program loop is to be repeated, then method 400 returns from step 426 to step 424. Thus, it should be noted that steps 424 and 426 are repeated in combination until all iterations of the second occurrence of the superblock program loop are completed, and at this point, as a result of incrementing TEMP_TLIC with each step 424, TEMP_TLIC provides a total count of program loop iterations for the given superblock program loop. Finally, once the last iteration of the superblock program loop is completed, the step 426 condition is no longer satisfied, and then method 400 continues from step 426 to step 428.

[0045] Following the above, step 428 is reached after the second occurrence of the hyperblock program loop and the end of all iterations of the second occurrence, the number of which will be stored in temporary total loop iteration count TEMP_TLIC. Step 428 compares the second occurrence count TEMP_TLIC of the same hyperblock program loop with the first occurrence count TLICz, recalling that TLICz is the earlier iteration count of the first occurrence of the same hyperblock program loop previously stored in micro BTB 128. If the second occurrence iteration count (TEMP_TLIC) matches the first occurrence iteration count (TLICz), then method 400 continues from step 428 to step 430. If TEMP_TLIC does not match TLICz, then method 400 continues from step 428 to step 432.

[0046] Step 430 is reached when TEMP_TLIC = TLICz, and in response the valid bit VBzin micro BTB 128 corresponding to the hyperblock program loop just completed is set to the valid state (e.g., VBz = 1). In particular, because step 428 compares the total iteration counts of two consecutive occurrences of the same program loop, if the two counts match, then method 400 thereby detects consistent and thus predictable behavior of the hyperblock program loop based on the same number of loop exit branches taken in both the first occurrence and the second occurrence of the program loop. Accordingly, the predictability of the behavior is confirmed by the validity setting of step 430, after which method 400 returns to step 402. As a result of this particular method flow, when the same program loop is next encountered and processed, method 400 will direct its flow through steps 402, 404, 406, 410, 414, and 422.

[0047] As described above, step 422 is reached when valid bit VBzinicates that the data set is valid. In response, step 422 will predict the number of iterations of the next occurrence of the same program loop from the characterization in micro BTB 128. In particular, at this time, BP block 124 predicts the number of iterations of the loop via count TLICzin micro BTB 128 corresponding to the loop. Thereby, core 102 processes all instructions of the loop the number of iterations indicated by the prediction (e.g., re-fetch, decode, execute, etc., or otherwise repeated) without any additional delay that can occur due to lack of prediction or due to a limited prediction architecture (e.g., due to predicting a small number of iterations or otherwise failing to provide the flexibility of the example embodiments).

[0048] When TEMP_TLIC ≠ TLICz, i.e., the second occurrence of a hyperblock program loop is not the same iteration number as the first occurrence of the same program loop, step 432 is reached. In this case, there is no continuous consistent behavior of the loop iteration number. Therefore, step 432 instead updates its loop iteration counter TLICz with the current value of the second occurrence count TEMP_TLIC, i.e., it sets TLICz equal to TEMP_TLIC, as compared to verifying the corresponding data set 300.z in the validation micro BTB 128. For example, assume that in the first occurrence of a program loop it is iterated 30 times, which is stored in the micro BTB 128 data set 300.z as TLICz. For the second and consecutive occurrence of the same program loop, assume that it is iterated 40 times, i.e., a different number of iterations than the first occurrence. Therefore, in this example, step 428 detects the difference in loop iterations for two consecutive hyperblock program loop occurrences, and step 432 updates the data set value of TLICz to 40, however, the data set is not verified. Next, the method 400 returns from step 432 to step 402, and therefore it should be noted that when the method 400 encounters the next (e.g., third) occurrence of the same program loop, the entry for the program loop can still be present in the micro BTB 128 (if it has not been overwritten during this time), but it will be marked as invalid (VBz = 0). Therefore, the method 400 will again proceed to step 420, iterate the program loop the number of times counted by TEMP_TLIC, and step 428 will again repeat the comparison described above. Therefore, only when two consecutive occurrences of the same program loop have iterated the same number of times, will the data set 300.z for the program loop be marked as valid.

[0049] Figure 5 DESCRIPTION Figure 1 A schematic diagram of additional details of an example embodiment of the BP block 124, including additional structures and connections with respect to the EHT 126 and the micro BTB 128. The BP block 124 receives two inputs, fp_cnt and fp_offset, representing the fetch packet counter and its offset, respectively, such that the inputs together indicate the block size of the fetch packet, and essentially the PC 120 Figure 1 ) and is also input to an exit history queue (EHQ) 502. The EHQ 502 outputs history information about the last eight branches to a combiner 504, such as an XOR gate, which combines the output with an output cpu_pmc_address (which is the program memory controller address from a previous instruction read) and inputs the combination as a tag for a lookup to the EHT 126 to start filling the EHT with a tag for either metadata about a newly detected hyperblock or filled information about a previously processed hyperblock. As previously described, when the EHT 126 stores information about a hyperblock, it outputs two values, an instruction branch type (br_type) and an offset from a hyperblock entry instruction to a hyperblock exit instruction, and connects this information to a comparator 506 which compares the information to the cpu_pmc_address and produces a result predicted address (Predicted_Exit) as a predicted exit instruction address. The br_type is used as a control input to a multiplexer 508. The Predicted_Exit is connected as an input to several blocks, including but not limited to a micro BTB 128, a return stack 510 (to service certain types of call and return branch scenarios to keep track of each different potential call to the same return), a branch target buffer 512 (which can perform other branch prediction functions), and a problem queue 514. This connection to the micro BTB 128 facilitates the various details described above, whereby it can be seen herein that the previously described loop tag address (LTAz) is provided as the Predicted_Exit. In response, if this tag hits one of the data sets 300.z in the micro BTB 128, the result is output as one of the inputs to the multiplexer 508, and if the br_type for this cycle indicates that the branch instruction type is a hyperblock program loop exit instruction, the multiplexer 508 selects the output of the micro BTB 128 and outputs it as a Predicted_Target for the next instruction after the loop program exit instruction; thus, if the micro BTB 128 determines that the number of loop iterations has not reached a particular count TLICz, i.e., the loop has not completed all of the predicted iterations, the Predicted_Address will specify an address for another iteration of the loop to return program flow to the beginning of the hyperblock program loop. In contrast, if the number of loop iterations has reached the particular count TLICz, the Predicted_Address will specify an address to continue program flow to the next instruction after the end of the hyperblock program loop.

[0050] From the foregoing, one skilled in the art will appreciate that example embodiments include processing devices with a micro-BTB 128 for branch predictors. Moreover, the micro-BTB 128 includes circuitry that characterizes up to M different program loops, including a consistent assessment prediction of how many iterations will be taken for each program loop. Thus, processing device efficiency can be improved, for example, by reducing branch mispredictions or loop mispredictions and their corresponding inefficiencies (e.g., pipeline flushes), or also provide predictions that can not be available in other processing device architectures. As another example, example embodiment processing devices allow for generation of loop iteration counts of lengths with up to 2 N iterations (where N is the bit size of the TLICz), but do not require expansion of history tables to require that each of the 2 N instructions in the sequence have an entry. As another example, where the special register 300 is embodied as a discrete register, the prediction results can be accessed faster (e.g., in one clock cycle) as compared to other memory storage (e.g., SRAM). As yet another example, example embodiments provide an improved micro-BTB 128 that can be included with existing branch predictors without requiring many changes elsewhere to conform to existing branch predictors. Moreover, the micro-BTB 128 can use itself for other processing improvements. Moreover, while the above attributes are shown in combination, in other embodiments, the scope of the invention includes subsets of one or more features. Moreover, variations in aspects including register size, functional partitioning, and the like are also contemplated, where the foregoing merely provide some examples, other examples can be determined from the teachings herein by one skilled in the art. Thus, additional modifications can be made to the described embodiments, and other embodiments are feasible, within the scope of the claims that follow.< / x>

Claims

1. An integrated circuit, comprising: Instruction processing circuitry, which processes multiple program instructions; and Instruction prediction circuit, comprising: Circuitry configured to determine the program loop sequence among the plurality of program instructions; and A table configured to store instruction information associated with the program loop sequence, the instruction information including addresses; The instruction prediction circuitry is configured to determine whether an entry associated with the program loop sequence is stored in a buffer; The entry point includes a validity indicator and a count of the number of iterations of the program loop sequence; In response to determining that the entry associated with the program loop sequence is not stored in the buffer, the instruction prediction circuit is configured to set the validity indicator to an invalid state; and In response to determining that the entry associated with the program loop sequence is stored in the buffer, the instruction prediction circuit is configured to: Determine the current state of the validity indicator; and In response to the current state indicating a valid state in the validity indicator, the number of iterations of the program loop sequence is predicted.

2. The integrated circuit of claim 1, wherein the instruction prediction circuit further includes circuitry for determining whether a program instruction among the plurality of program instructions includes a superblock program loop entry instruction.

3. The integrated circuit according to claim 1, wherein the address corresponds to a loop exit branch instruction that terminates the program loop sequence.

4. The integrated circuit of claim 1, wherein the first register is written with the current state of the validity indicator; and wherein the second register is written with the address of the loop exit branch instruction.

5. The integrated circuit of claim 4, wherein the third register is written with respect to the number of iterations of the program loop sequence.

6. The integrated circuit of claim 5, wherein the first register, the second register, and the third register are a first register group among a plurality of register groups for characterizing corresponding program loop sequences of the plurality of program instructions.

7. The integrated circuit according to claim 6, wherein the first register is 1 bit.

8. The integrated circuit according to claim 7, wherein the third register stores up to 256 counts.

9. The integrated circuit of claim 1, wherein the instruction prediction circuit further includes circuitry for determining whether a program instruction includes a superblock program loop exit branch instruction in response to a program instruction address among the plurality of program instructions.

10. The integrated circuit of claim 1, wherein the instruction prediction circuit further includes circuitry for determining whether a program instruction includes a superblock program loop entry instruction in response to a program instruction address among the plurality of program instructions.

11. The integrated circuit according to claim 1, The instruction processing circuitry includes an instruction pipeline for processing the plurality of program instructions; and It further includes circuitry for extracting the program loop sequence in response to the instruction prediction circuitry.

12. The integrated circuit according to claim 1, wherein the instruction processing circuit includes a single instruction multiple data processing circuit.

13. The integrated circuit of claim 1, wherein the instruction processing circuit further includes circuitry for extracting and processing the program loop sequence to a number equal to the number of iterations after the instruction prediction circuit predicts the number of iterations of the program loop sequence.

14. A method comprising: Multiple program instructions are processed through instruction processing circuitry; The program loop sequence in the plurality of program instructions is determined by an instruction prediction circuit; A table is used to store instruction information associated with the program loop sequence, the instruction information including addresses; The instruction prediction circuitry is configured to determine whether an entry associated with the program loop sequence is stored in a buffer; The entry point includes a validity indicator and a count of the number of iterations of the program loop sequence; In response to determining that the entry associated with the program loop sequence is not stored in the buffer, the instruction prediction circuit is configured to set the validity indicator to an invalid state; and The entry point associated with the program loop sequence is stored in the buffer in response to the determination: The current state of the validity indicator is determined by the instruction prediction circuit. and In response to the current state indicating a valid state in the validity indicator, the number of iterations of the program loop sequence is predicted by the instruction prediction circuit.

15. The method of claim 14, further comprising determining whether one of the plurality of program instructions includes a superblock program loop entry instruction.

16. The method of claim 14, further comprising, after predicting the number of iterations of the program loop sequence, extracting and processing the number of iterations of the program loop sequence equal to the number of iterations.

Images