Metadata predictor

Abstract

In one embodiment for a metadata predictor, an index pipeline generates an index in an index buffer, the index is used to read a memory device, a prediction cache is populated with metadata for instructions read from the memory device, a prediction pipeline generates a prediction using instruction metadata from the prediction cache, and populating the prediction cache with instruction metadata is performed asynchronously with operation of the prediction pipeline.

Description

Technical Field

[0001] The present invention generally relates to computer systems, and more particularly to a computer-executable method, a computer system, and a computer program product configured and arranged for a metadata predictor.

Background Art

[0002] Pipeline microprocessors have paths, channels, or pipelines that are divided into multiple stages for performing specific tasks. Each of the specific tasks is a part of all the operations directed by the programmed instructions. Each of the programmed instructions of a software application program or macro instruction is executed sequentially by the microprocessor. When a programmed instruction enters the first stage of the pipeline, a specific task is performed. The instruction is then passed to the subsequent stage for the performance of the subsequent task. After the completion of the last task, the instruction completes execution and exits the pipeline. The execution of the programmed instructions by the pipeline microprocessor is similar to the manufacture of items on an assembly line. One obvious aspect of any assembly line is that at any given time, there are multiple items on the line at successive assembly stages. The same is true for pipeline microprocessors. During any cycle of the pipeline clock signal, there are multiple instructions in various stages, and each of the instructions is at a successive completion level. Thus, the microprocessor enables the overlapping execution of multiple instructions by the same circuit. The circuit is typically divided into multiple stages, and each stage processes a specific part of one instruction at a time and passes the partial result to the next stage.

Summary of the Invention

[0003] Embodiments of the present invention relate to computer execution methods for metadata predictors. Non-limiting examples of computer execution methods include operating an index pipeline to generate an index in an index buffer, the index being used to read from a memory device, and populating the metadata of the instructions read from the memory device into a prediction cache. A computer execution method also includes operating a prediction pipeline to generate a prediction using the instruction metadata from the prediction cache, the population of the instruction metadata into the prediction cache being performed asynchronously with the operation of the prediction pipeline.

[0004] A non-exclusive example of how a computer can execute this includes querying an index accelerator using a reset address and determining, in response to the query, that an index line exists within the index accelerator. The computer execution method also includes determining a sequential line to the index line within the index accelerator and placing the sequential line into the index buffer.

[0005] A non-exclusive example of a computer execution method includes generating a primary and secondary prediction using metadata, determining that the primary and secondary predictions are different, and selecting a secondary prediction in response to the difference between the primary and secondary predictions. The computer execution method also includes extending the length of the prediction pipeline over a predetermined period of time and sending the secondary prediction to the instruction execution pipeline.

[0006] Other embodiments of the present invention implement the features of the above-described method in computer systems and computer program products.

[0007] Additional technical features and benefits are realized through the technology of the present invention. Embodiments and aspects of the present invention are described in detail herein and are considered to be part of the subject matter claimed. For a better understanding, refer to the detailed description and drawings.

[0008] Details of the exclusive rights described herein are specifically pointed out and explicitly claimed in the claims in the conclusions herein. The aforementioned and other features and advantages of embodiments of the present invention will become apparent from the following detailed description, made in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0009] [Figure 1] This is a block diagram of an example computer system for use in conjunction with one or more embodiments of the present invention. [Figure 2] This is a block diagram of a metadata predictor in a processor according to one or more embodiments of the present invention. [Figure 3] This is a block diagram of a metadata predictor having a metadata prediction cache according to one or more embodiments of the present invention. [Figure 4] This is a block diagram of a metadata predictor having a metadata prediction cache in a parent-based design according to one or more embodiments of the present invention. [Figure 5] This is a block diagram of a metadata predictor process according to one or more embodiments of the present invention. [Figure 6] This is a block diagram of an example metadata predictor cache according to one or more embodiments of the present invention. [Figure 7] This is a block diagram of an example pipeline according to one or more embodiments of the present invention. [Figure 8] This is a block diagram of an example metadata predictor cache according to one or more embodiments of the present invention. [Figure 9] This is a block diagram of an example pipeline according to one or more embodiments of the present invention. [Figure 10] This is a flowchart of a computer execution method for using a metadata predictor according to one or more embodiments of the present invention. [Figure 11] This is a flowchart of an accelerator flow for writing to a line index accelerator according to one or more embodiments of the present invention. [Figure 12] This is a flowchart of an accelerator flow for reading a line index accelerator according to one or more embodiments of the present invention. [Figure 13] This is a block diagram of an example of a latency accelerator entry for a line index accelerator according to one or more embodiments of the present invention. [Figure 14] This is a flowchart of an accelerator flow for performing payload matching according to one or more embodiments of the present invention. [Figure 15] This is a block diagram of an example accelerator according to one or more embodiments of the present invention. [Figure 16] This is a block diagram of an example accelerator according to one or more embodiments of the present invention. [Figure 17] This is a block diagram of an example pipeline including a line-index accelerator without line offset, according to one or more embodiments of the present invention. [Figure 18] This is a block diagram of an example pipeline including a line-index accelerator with line offset, according to one or more embodiments of the present invention. [Figure 19] This is a block diagram of an example pipeline including a line-index accelerator with line offset, according to one or more embodiments of the present invention. [Figure 20] This is a block diagram of an example pipeline including a line index accelerator with line offset and intraline branching, according to one or more embodiments of the present invention. [Figure 21]A flowchart of a computer-executable method for determining an index for a line index buffer of a metadata predictor using a line index accelerator, according to one or more embodiments of the present invention. [Figure 22] A block diagram of prediction logic including a primary predictor and an auxiliary predictor, according to one or more embodiments of the present invention. [Figure 23] A flowchart of a variable-length metadata prediction pipeline flow for determining when to use an auxiliary predictor, or extend a prediction pipeline, or both, according to one or more embodiments of the present invention. [Figure 24] A block diagram of an example of a pipeline depicting downstream congestion, according to one or more embodiments of the present invention. [Figure 25] A block diagram of an example of a pipeline depicting that an auxiliary predictor has made a different prediction than a primary predictor, according to one or more embodiments of the present invention. [Figure 26] A block diagram of an example of a pipeline depicting that an auxiliary predictor has made the same prediction as a primary predictor, according to one or more embodiments of the present invention. [Figure 27] A flowchart of a computer-executable method for using a variable-length metadata prediction pipeline, according to one or more embodiments of the present invention. [Figure 28] A block diagram of a system that will design / layout a metadata predictor, according to one or more embodiments of the present invention. [Figure 29] A process flow of a method for fabricating the integrated circuit of FIG. 28, according to one or more embodiments of the present invention. [Figure 30] A diagram of a cloud computing environment, according to one or more embodiments of the present invention. [Figure 31] A diagram of an abstraction model layer, according to one or more embodiments of the present invention.

Best Mode for Carrying Out the Invention

[0010] One or more embodiments of the present invention provide a computer execution method, computer system, and computer program product arranged and configured to place a metadata predictor cache in a metadata predictor. One or more embodiments improve processor performance by implementing caching and reuse of predictive metadata to ensure low-latency branch prediction, thereby minimizing fetch inaccuracies and downstream branch penalties. Furthermore, one or more embodiments are configured and arranged to place a predictive cache in a metadata predictor line index accelerator. The accelerator is configured to populate a line index buffer (LIB), allowing metadata buffers (e.g., branch target buffer (BTB) or other buffers) to be accessed before the predictive pipeline, thereby minimizing predictive latency. Furthermore, one or more embodiments are configured and arranged to place a variable-length metadata predictive pipeline within the metadata predictor.

[0011] A metadata predictor is a system that uses metadata to predict information about instructions, data, or both in a microprocessor. The fact that a load instruction depends on a store instruction is an example of the type of information that a metadata predictor can predict. A line prefetch predictor is another example. Branch prediction is yet another type of metadata prediction and is an essential component of the performance of pipelined high-frequency microprocessors. Branch prediction is used to predict the instructions (e.g., whether to perform or not) and target address of a branch instruction. This is beneficial because it allows processing to continue along the predicted branch path without having to wait for the branch's conclusion to be determined. A penalty is only incurred if the branch is predicted incorrectly.

[0012] A branch target buffer (BTB) is a structure that stores metadata containing branch and target address information. The BTB can be searched in parallel with and independently of instruction fetching to find upcoming branches; in this case, the BTB is used for proactive branch prediction, known as asynchronous branch prediction. Additionally, the BTB can be accessed simultaneously with, or after, instruction fetching, or both, and is used to determine instruction boundaries for making predictions about each encountered branch instruction, known as synchronous branch prediction. In either case, the performance benefit of the BTB is a function of the accuracy of the predictions it provides and the latency required to access it.

[0013] A metadata predictor cache can capture metadata predictor output and reuse it while remaining in the same code section to repeat the prediction. Metadata predictors can be organized to have a variable line size based on the parent base design. A multi-level hierarchy is possible for metadata predictors, similar to a multi-level instruction or data cache hierarchy. In a two-level hierarchy, the first level should be smaller and faster to access than the second level, which should be larger and slower. The design of metadata predictor hierarchies is more flexible than that of instruction or data cache hierarchies because metadata, unlike other caches, does not need to exist and be accurate for the proper functioning of the processor.

[0014] Various terms may be used in this specification.

[0015] LIB is the line index buffer. LOB is the line output buffer. BTB is the branch target buffer. IL is the intraline branch, a branch whose target is on the same line of instruction text (itext). DGT refers to a dynamically guessed taken branch. An exit branch refers to a branch that flows from line X to several other lines. The entry point is the instruction address (IA) at which the metadata predictor begins its search after finding the exit branch, and is therefore effectively the target instruction address of the exit branch. The branch offset is the number of lines between the entry point and the exit branch. SKOOT represents the skip-over offset and indicates the number of lines that do not contain branches and therefore do not need to be searched.

[0016] Moving to Figure 1, a computer system 100 according to one or more embodiments of the present invention is shown in its entirety. The computer system 100 can be an electronic computer framework comprising, employing, or both, any number of computing devices and networks, and combinations thereof, utilizing various communication technologies as described herein. The computer system 100 can be easily scaled down, extensible, and modular, and can be changed to different services or reconfigured with some features unrelated to others. The computer system 100 may be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, the computer system 100 may be a cloud computing node. The computer system 100 may be described in the general context of computer system executable instructions, such as program modules, which are executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or execute a specific abstract data type. The computer system 100 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules may reside on both local and remote computer system storage media, including memory storage devices.

[0017] As shown in Figure 1, the computer system 100 has one or more central processing units (CPUs) 101a, 101b, 101c, etc. (collectively or as a whole, referred to as the processor 101). The processor 101 can be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. The processor 101, also called the processing circuit, is coupled to the system memory 103 and various other components via the system bus 102. The system memory 103 may include read-only memory (ROM) 104 and random access memory (RAM) 105. The ROM 104 is coupled to the system bus 102 and may have a Basic Input / Output System (BIOS) or a successor such as a Unified Extensible Firmware Interface (UEFI) that controls certain basic functions of the computer system 100. The RAM is read-write memory coupled to the system bus 102 for use by the processor 101. System memory 103 provides a temporary memory space for the operation of the instructions during operation. System memory 103 may include random access memory (RAM), read-only memory, flash memory, or any other suitable memory system.

[0018] The computer system 100 includes an input / output (I / O) adapter 106 and a communication adapter 107 connected to a system bus 102. The I / O adapter 106 may be a small computer system interface (SCSI) adapter that communicates with a hard disk 108, or any other similar component, or both. The I / O adapter 106 and the hard disk 108 are collectively referred to as mass storage 110 in this specification.

[0019] Software 111 for execution on computer system 100 may be stored in mass storage 110. Mass storage 110 is an example of a tangible storage medium readable by processor 101, and the software 111 is stored as instructions for execution by processor 101 to operate computer system 100, as will be described later in this specification with reference to various figures. Examples of computer program products and the execution of such instructions will be discussed in more detail in this specification. A communication adapter 107 interconnects system bus 102 with network 112, which may be an external network, enabling computer system 100 to communicate with other such systems. In one embodiment, a portion of system memory 103 and mass storage 110 collectively stores an operating system, which may be any suitable operating system for coordinating the functions of the various components shown in Figure 1.

[0020] Additional input / output devices are shown connected to the system bus 102 via a display adapter 115 and an interface adapter 116. In one embodiment, adapters 106, 107, 115, and 116 may be connected to one or more I / O buses connected to the system bus 102 via an intermediate bus bridge (not shown). A display 119 (e.g., a screen or display monitor) is connected to the system bus 102 by the display adapter 115, which may include a graphics controller and a video controller to improve performance for graphics-intensive applications. A keyboard 121, mouse 122, speaker 123, etc., are interconnectable to the system bus 102 via the interface adapter 116, which may include, for example, a super I / O chip integrating multiple device adapters into a single integrated circuit. Suitable I / O buses for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols such as Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe). Thus, as configured in Figure 1, the computer system 100 includes processing capabilities in the form of a processor 101, storage capabilities including system memory 103 and mass storage 110, input means such as a keyboard 121 and a mouse 122, and output capabilities including speakers 123 and a display 119.

[0021] In some embodiments, the communication adapter 107 can transmit data using any suitable interface or protocol, particularly the Internet Small Computer System Interface. The network 112 may be a cellular network, a wireless network, a wide area network (WAN), a local area network (LAN), or the Internet. An external computing device may connect to the computer system 100 through the network 112. In some examples, the external computing device may be an external web server or a cloud computing node.

[0022] It should be understood that the block diagram in Figure 1 is not intended to indicate that computer system 100 must include all of the components shown in Figure 1. Rather, computer system 100 may include any suitable fewer or additional components not illustrated in Figure 1 (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Furthermore, embodiments of computer system 100 described herein may be performed by any suitable logic, and logic as referred herein may include any suitable hardware (e.g., in particular a processor, embedded controller, or application-specific integrated circuit), software (e.g., in particular an application), firmware, or any suitable combination of hardware, software, and firmware in various embodiments.

[0023] Figure 2 is a block diagram of a metadata predictor 200 of a processor 101 according to one or more embodiments of the present invention. The processor 101 may represent any of the processors 101 discussed in the computer system 100 of Figure 1. The metadata predictor 200 is outside the instruction execution pipeline 250 and runs asynchronously with respect to the instruction execution pipeline 250. The instruction execution pipeline 250 can be an unsequential pipeline and includes modules / blocks to operate as part of the processor core, as will be understood by those skilled in the art. The metadata predictor 200 is configured to communicate with the instruction execution pipeline 250 (e.g., to send and receive data from the instruction execution pipeline 250). The instruction execution pipeline 250 can be any instruction pipeline. In some examples of instruction execution pipelines 250 of several units with a processor core, the branch prediction logic is responsible for instruction fetching and branch prediction in the instruction fetch and branch prediction unit (IFB). The IFB is the core's navigator and arbitrates all pipeline restart points for both threads. Furthermore, the IFB directs the instruction cache and merge (ICM) units, is responsible for fetching instruction text from the level 1 instruction cache, and attempts to ensure that only instruction text for what it considers the correct speculative code path is delivered to the instruction decode and dispatch unit (IDU). The pipeline then sends instructions to the instruction sequence unit (ISU), which maintains the out-of-order execution pipeline. Instruction issue queues are used to execute instructions in fixed-point units (FXU), vector and floating-point units (VFU), load-store units (LSU), etc. Address translation is performed by the translator unit (XU), and checkpointing is managed by the recovery unit (RU). Once an instruction is decoded as a branch, dynamic predictive information for this branch discards any instruction text-based static inference that the IDU should have applied correctly.

[0024] The metadata predictor 200 includes various hardware components, including a line index accelerator 202, a line index buffer (LIB) 204, a branch target buffer (BTB1) 206, a line output buffer (LOB) 208, accelerator logic 222, LIB logic 224, LOB logic 228, and predictive logic 230, the hardware components including cache, combinational logic, memory, etc. Although not shown for brevity, in one or more embodiments, the metadata predictor 200 may include a BTB2 larger than BTB1 that can supply metadata to BTB1. Furthermore, the various hardware components of the metadata predictor 200 include firmware (such as computer executable instructions) executed on the microcontroller, along with hardware modules such as dedicated hardware (e.g., application-specific hardware, application-specific integrated circuits (ASICs), such as embedded controllers, wired circuits, etc.), or some combinations thereof, or both. In the examples, the modules described herein can be combinations of hardware and programming. The programming can be processor-executable instructions stored in tangible memory, and the hardware may include processing circuits for executing these instructions. Alternatively or additionally, the module may include dedicated hardware for implementing the techniques described herein, such as one or more integrated circuits, application-specific integrated circuits (ASICs), application-specific special processors (ASSPs), field-programmable gate arrays (FPGAs), or any combination of the aforementioned examples of dedicated hardware. Furthermore, the metadata predictor 200 module may include various digital logic circuits to function as discussed herein.

[0025] Figure 3 is a block diagram of a metadata predictor 200 having a predictive cache according to one or more embodiments of the present invention. Figure 4 is a block diagram of a metadata predictor 200 with a predictive cache parent-based design according to one or more embodiments of the present invention. BTB1 206 can be divided into quarters for use, for example, four quarters. More specifically, BTB1 206 is a memory structure, but BTB1 206 operates as multiple sections of the parent-based design in Figure 4. In Figure 4, BTB1 206 is represented by two quarters depicting BTB1 206 which are used as BTB1 206_0 and BTB1 206_1 for parents 0 and 1, respectively. Similarly, each quarter has its own LOB208 which is depicted as LOB208_0 and LOB208_1 for the parent-based design in Figure 4. Multiplexers 402_0 and 402_1 may be used to provide an appropriate line of metadata to the prediction logic 230 based on a predetermined format of selection.

[0026] BTB1 206 is read line by line, and the output is written to a prediction cache such as LOB208 (including LOB208_0 and 208_1) to be reused while remaining within that line. The index pipeline (e.g., index pipeline 552 depicted in Figure 5) is configured to read BTB1 206 and send the output to LOB208. The prediction pipeline (e.g., prediction pipeline 554 depicted in Figure 5) is configured to use the BTB data from BTB1 206 (including BTB1 206_0 and BTB1 206_1) and the LOB data from LOB208 (including LOB208_0 and 208_1) to make predictions via the prediction logic 230 of the processor 101. In the metadata predictor 200, the index pipeline 552 and the prediction pipeline 554 operate asynchronously with the instruction execution pipeline 250, and are also decoupled and operate independently of each other.

[0027] Branch prediction latency can be a performance issue for any processor, and downstream pipelines must fetch instruction text accurately as quickly as possible to keep cycles per instruction (CPI). Accurate branch prediction enables such fetching. However, if prediction is unavailable, the processor may either proceed and fetch the wrong instruction text, risking a false branch penalty, or wait for a new branch prediction to become available, thus increasing the CPI. According to one or more embodiments, buffering to LIB204 and LOB208, as well as reusing prediction metadata within LOB208, enables low-latency branch prediction, thereby placing instruction fetching before instruction execution and providing energy-saving benefits. By decoupling the index pipeline 552 from the prediction pipeline 54, the index pipeline 552 can precede the prediction pipeline 554, thereby hiding other prediction latency-inducing events (e.g., read / write collisions). Furthermore, in order to enable the forecast pipeline 554 to generate forecasts as quickly as possible, the index pipeline 552 will be read before the forecast pipeline 554.

[0028] To further illustrate the details of the index pipeline 552 and the prediction pipeline 554, Figure 5 depicts a metadata prediction cache process 500 for the metadata predictor 200 in one or more embodiments. The metadata prediction cache process 500 is a computer execution process performed by the processor 101 in Figures 1, 2, 3, and 4, along with other figures discussed herein. The description of the metadata prediction cache process 500 shown in Figure 5 will be made with reference to Figures 1, 2, 3, and 4, where appropriate.

[0029] In block 502 of the index pipeline 552, the metadata predictor 200 is configured to populate LIB204. LIB204 can populate reset instruction addresses from the instruction execution pipeline 250 or the prediction logic 230, or both. Additionally, LIB204 can populate accelerator instruction addresses. Accelerator instruction addresses can be sent to LIB204 from the line index accelerator 202. The line index accelerator 202 will be discussed further herein. LIB204 may be a first-in, first-out (FIFO) buffer or another type of buffer. Reset instructions are used to populate LIB204 with an index or an index line, or both. The index line is stored and ultimately used to search for BTB1 206, query BTB1 206, or both. An index or index line or both within LIB204 refers to a subset of instruction address bits used by LIB204 to access BTB1 206. In one or more embodiments, each entry in BTB1 206 may represent a 128-byte (B) line, and the index / index line within LIB204 may use a subset of instruction address bits (e.g., a subset of the 128B line), such as instruction address bits (48:56), based on the size of BTB1, where instruction address bits (48:56) refers to instruction address bits 48-56 of the instruction address used to read BTB1 206. In one or more embodiments, the index / index line within LIB204 is any predetermined subset of instruction address bits, 128B being exemplified as an example. Thus, the index line of LIB204 is used to query BTB1 206.Furthermore, instruction execution pipeline events in the instruction execution pipeline 250, such as erroneous branching, can restart the index pipeline 552, the prediction pipeline 554, and the line index accelerator 202.

[0030] In block 504, the metadata predictor 200 (for example, using LIB logic 224) is configured to read LIB204, thereby reading an index containing instruction addresses from LIB204. LIB204 may read the index of instruction addresses all at once.

[0031] In block 506, the metadata predictor 200 (for example, using LIB logic 224) is configured to check whether the received instruction address is valid. The metadata predictor 200 (for example, using LIB logic 224) is configured to check whether the actual instruction address has been read from LIB 204 or whether the output is empty. Each instruction address may be read one at a time (for example, sequentially) as an entry on a line (for example, a cache line), as a group / block of entries, or both. ("NO") If the instruction address is empty, the flow returns to block 504, and the metadata predictor 200 (for example, using LIB logic 224) is configured to read LIB 204 where the index should be populated. ("YES") If the instruction address is valid (i.e., exists), the flow proceeds to block 508. Furthermore, if the "YES" instruction address is valid (i.e., exists), the metadata predictor 200 (for example, using LIB logic 224) is configured in block 510 to check whether this is the last entry in LIB204. Block 510 checks whether this entry is the last index in LIB. If this entry is not the last entry in LIB ("NO"), the metadata predictor 200 (for example, using LIB logic 224) is configured to read the next entry in LIB by returning to block 504. ("YES") If this entry is the last entry in LIB204, the metadata predictor 200 (for example, using LIB logic 224) is configured in block 512 to generate line X+1 by moving to the next consecutive line after the current line (e.g., line X) in order to populate the end of LIB204, and the flow returns to block 504. The metadata predictor 200 writes line X+1 to the end of LIB, and once it has finished processing line X on the "valid" path, the metadata predictor 200 will process line X+1.For example, line X+1 refers to the next consecutive 128B line of instruction text following line X. In one or more embodiments, block 510 can recognize that the accelerator no longer knows where to go, and therefore the LIB continues to move the prediction even though it has exhausted the index for accessing BTB1. In such a case, the index pipeline 552 is configured to generate the next sequential line and use it to search for BTB1.

[0032] In block 508, the metadata predictor 200 is configured to index BTB1 206 by sending a list of indices from LIB204 to access and query BTB1 206. Each index in the index is used to read BTB1 206. An index is a subset of address bits (i.e., multiple addresses sharing the same index) used to access entries within BTB1. Tags are used to verify that what is retrieved from BTB1 matches the address being looked for. Although not illustrated, various queues may be used in the index pipeline 552 and prediction pipeline 554 to hold data where applicable. As a branch target buffer, BTB1 206 contains and tracks branches that are predicted to branch (or decided to branch, or both) and branches that are predicted not to branch, along with their targets. BTB1 206 is a large array or cache or both containing metadata about branch details. The BTB1 206 holds the instruction address bit as a tag in preparation for searching.

[0033] In block 514, the metadata predictor 200 is configured to check for hits in BTB1 206. (For example) Tags in BTB1 are compared to the current search tag in the index. If they match, the line of metadata read from BTB1 is used as input to the prediction pipeline 554. If the tags in BTB1 do not match the current search tag, the line is not used for prediction. In one or more embodiments, whether or not there are hits does not affect the flow, and the metadata predictor 200 can write the metadata to the LOB regardless of hits. Therefore, the flow from block 514 may be modified based on the implementation, and one implementation may choose to delete this metadata because it cannot be used for prediction.

[0034] In block 520 of the prediction pipeline 554, the metadata predictor 200 (using, for example, LOB logic 228) is configured to populate data from BTB1 206 into LOB208. Note that LIB204 and LOB208 are smaller in size and capacity than BTB1 206. Data is populated into LOB208 from cache hits of BTB1 206. Just like BTB1 206, LOB208 stores branch and target address information, including location, direction, and target. It should be understood that BTB1 and LOB are available for branch prediction, but can be used with any metadata for any purpose.

[0035] In block 522, the metadata predictor 200 (for example, using LOB logic 228) is configured to read lines (e.g., cache lines) within LOB 208. For example, an index / index line from LIB 204 is used to read a line of metadata from BTB1 206. In one or more embodiments, the output of LOB 208 is a line of branch prediction metadata associated with a 128B line of the instruction text searched by the index from LIB 204.

[0036] In block 524, the metadata predictor 200 (for example, using LOB logic 228) is configured to check whether something has been read for a line in LOB 208 (for example, a line of metadata about the read instruction address). If no data has been read for the cache line ("NO") (i.e., empty), the flow returns to block 522. If "YES" data (for example, a line of metadata about the instruction address) has been read, the metadata predictor 200 (for example, using LOB logic 228) generates a prediction and is configured in block 526 to send the prediction (for example, a target address) downstream. For example, the predicted target address is sent for processing to the instruction cache and merger (ICM) unit, as well as the instruction decode and dispatch unit (IDU) of the instruction execution pipeline 250. Additionally, in block 528, the metadata predictor 200 (for example, using LOB logic 228) is configured to check whether the predicted target address in the metadata line is an intraline. When the predicted target address is on an intraline, this means that the predicted target address is on the same / current line of metadata about the instruction text read from LOB208. If "YES" the predicted target address is on the current line read from LOB208, in block 530 the metadata predictor 200 (for example, using LOB logic 228) is configured to update the entry instruction address and output the updated entry instruction address (the next target address on the same line) which will be used to generate another prediction without another line needing to be read from LOB208, and the flow returns to block 530. The update of the entry instruction address indicates which branch will be considered next for the prediction. Continuing with the example using line 128B, we assume that the first search on this line was in byte 20 of this 128B line.This means that if there are branches in bytes 0 through 19, the metadata predictor 200 is not interested in these branches because processing has already branched beyond this instruction text. An intraline branch (for example, in a small loop) immediately returns the metadata predictor 200 to byte 20, but in some cases it may cause processing to a different byte. If the target of an intraline branch was to cause processing to byte 10 instead of byte 20, the metadata predictor 200 should have to consider any branch in bytes 10 through 19, even if the metadata predictor 200 had not yet made its last prediction. Thus, effectively, the search start position is moved based on the intraline target. Blocks 526, 528, and 530 allow the execution of loop 550 in the prediction pipeline 554 to continue, generating a new prediction using the current line with the updated instruction address (i.e., the updated target address), which speeds up the metadata predictor 200 by eliminating the need to read another / subsequent line (or entry).

[0037] If the predicted target address is not intraline ("NO"), the metadata predictor 200 (for example, using LOB logic 228) is configured in block 532 to increment the read pointer, and the flow returns to block 522. This causes LOB 208 to read the next line. In one or more embodiments, a LOB can be implemented like a LIB, like a FIFO, while other implementation forms are possible. Therefore, if the metadata predictor 200 determines that there is no intraline branch, this means that the metadata predictor 200 is implemented on this LOB entry and can increment to the next entry in the FIFO.

[0038] Figure 6 is a block diagram of an example metadata predictor cache according to one or more embodiments. Figure 6 illustrates three code lines, line X, line Y, and line Z, each of which contains a dynamically guessed taken (DGT) branch. Information about these branches is collected in BTB1 206. In other words, lines X, Y, and Z (lines of metadata about X, Y, and Z) are stored in LOB208 (i.e., the predictor cache). Using an index from LIB204, the metadata predictor 200 (e.g., using LOB logic 228) searches for the instruction address on line X of the code in LOB208 in event 602 and predicts (e.g., using predictor logic 230) the dynamically taken branch on line X of the code that branches to line Y of the code in LOB208 in event 604. After branching to the target instruction address on line Y of the code (for example, using LOB logic 228), the metadata predictor 200 searches for the instruction address on line Y of the code in event 606 and predicts (for example, using prediction logic 230) the dynamically occurring branch on line Y of the code that branches to line Z of the code in LOB 208 in event 608. After branching to the target instruction address on line Z of the code (for example, using LOB logic 228), the metadata predictor 200 searches for the instruction address on line Z of the code in LOB 208 in event 610, and the process continues.

[0039] Figure 7 is a block diagram of a typical pipeline example, including an index pipeline 552 and a forecast pipeline 554, according to one or more embodiments. Referring again to the flow in Figure 5, all orange (depicted, for example, with dots) refers to processes to the left of the dotted line, and all green refers to processes to the right of the dotted line. Each B0 (orange) indicates that the entry is read from the LIB and that the entry is used to index BTB1. Each B2 (green, depicted, for example, with an upward-sloping diagonal line) indicates that the entry is read from the LOB and that the entry is for generating forecasts.

[0040] Figure 8 is a block diagram of an example metadata predictor cache according to one or more embodiments. Figure 8 illustrates three code lines, lines X, Y, and Z, which include dynamically guessed and performed (DGT) branches. Information about these branches is collected in BTB1 202. Figure 8 is an example of the intraline case. Using an index from LIB204 (for example, using LOB logic 228), the metadata predictor 200 is configured to first search for the instruction address of line X of the code in event 802, which results in a dynamically guessed and performed (DGT) branch in event 804, which leads the metadata predictor 200 to another instruction address on line X of the code (i.e., the intraline). In the prediction pipeline 554, the metadata predictor 200 (e.g., using LOB logic 228) recognizes an intraline branch in event 804, and instead of returning to BTB1 206 to fetch the metadata for line X, the metadata predictor 200 (e.g., using LOB logic 228) can decide to reuse the metadata for line X from LOB 208 (e.g., the predictor cache) using a new start instruction (X') in event 806. In event 806, the metadata predictor 200 (e.g., using LOB logic 228) searches for a target instruction address (X') on the same line X of the code that has the metadata. This process of reusing the metadata for line X of the code previously read from LOB 208 without fetching the metadata from LOB 208 can continue as a loop 550 (as depicted in Figure 5) for a number of instruction addresses that branch into branches that are dynamically inferred, all of which are on the same line X of the code. This speeds up branch prediction. At some point, the dynamically inferred branch (X') in event 808 branches to a target instruction address that is not on line X of the code, for example, on line Y of the code, so loop 550 satisfies the condition for termination.After branching to the target instruction address on line Y of the code (for example, using LOB logic 228), the metadata predictor 200 searches for the target instruction address (Y) on line Y of the code in event 810 and predicts the dynamically occurring branch on line Y of the code in event 812 (for example, using prediction logic 230) to branch to line Z of the code in LOB 208. After branching to the target instruction address on line Z of the code (for example, using LOB logic 228), the metadata predictor 200 searches for the instruction address (Z) on line Z of the code in LOB 208 in event 814, and the process continues.

[0041] Figure 9 is a block diagram of a typical pipeline example, including an index pipeline 552 and a forecast pipeline 554, according to one or more embodiments, showing a branch at event 604. In particular, Figure 9 illustrates an intraline example where the metadata forecaster 200 predicts two branches from a single read of LOB 208. Similar to Figure 7, there are two independent index and forecast pipelines. However, Figure 9 illustrates an intraline branch. The behavior of the index pipeline 552 remains unchanged, but the forecast pipeline 554 can generate additional predictions without additional access to BTB1 via the index pipeline.

[0042] Figure 10 is a flowchart of a computer execution method 1000 for indexing BTB1 208 using a metadata predictor 200, populating LOB208, and generating predictions, according to one or more embodiments of the present invention. The computer execution process 1000 may be performed using the computer system 100 of Figure 1. The processor 101 of Figure 1 may include, or perform, or both, the functions of the processor 101 discussed herein, together with any other processors discussed herein. The functions of the processor 101 may be used or performed, or both, in the hardware components of the hardware and software layer 60 depicted in Figure 31.

[0043] In block 1002 of the computer execution method 1000, the metadata predictor 200 is configured to operate an index pipeline 552 (using, for example, LIB logic 224) to generate an index in an index buffer (e.g., LIB 204) used to read the index from a memory device (e.g., BTB1). In block 1004, the metadata predictor 200 is configured to populate the metadata of instructions from the memory device (e.g., BTB1) into a prediction cache (e.g., LOB 208). In block 1006, the metadata predictor 200 is configured to operate the prediction pipeline 554 to generate a prediction using the metadata of instructions from the prediction cache (e.g., LOB 208), with the population of instruction metadata into the prediction cache occurring asynchronously with the operation of the prediction pipeline.

[0044] Populating instruction metadata into the prediction cache is performed asynchronously with the operation of the prediction pipeline, which involves constantly indexing a memory device (e.g., BTB1 206) for reading metadata about the prediction cache, independently of the prediction pipeline process. For example, the metadata predictor 200 (e.g., using LIB logic 224) is configured to execute blocks 504, 506, 508, 510, and 512 of the index pipeline 552 in Figure 5, and as a result populate (or store metadata in LOB208) metadata from BTB1 206 into LOB208 without triggering, and independently of, the execution of blocks 522, 524, 526, 528, 530, and 532 of the prediction pipeline 554 in Figure 5.

[0045] The index buffer (e.g., LIB204) is configured to read metadata about the prediction cache (e.g., BTB1 206) into a memory device (e.g., BTB1 206) before generating predictions, rather than relying on generating predictions (e.g., by prediction logic 230) using metadata from the prediction cache (e.g., LOB208). For example, the metadata predictor 200 (e.g., using LIB logic 224) is configured to execute blocks 504, 506, 508, 510, and 512 of the index pipeline 552 in Figure 5, and the index pipeline 552 does not rely on generating prediction results via prediction logic 230 in block 526 of the prediction pipeline 554 in Figure 5, but reads metadata from BTB1 206 into LOB208 before generating prediction results. The prediction pipeline 554 is configured to output lines of instruction metadata from the prediction cache (e.g., LOB208). For example, a metadata predictor 200 (for example, using LOB logic 228) is configured to read lines of metadata from LOB 208 for further processing in the prediction pipeline 554.

[0046] The prediction pipeline 554 is configured to constantly reuse lines of instruction metadata from the prediction cache without requiring re-access to a memory device (e.g., BTB1). For example, the metadata predictor 200 of processor 101 is configured to execute a loop 550 containing blocks 526, 528, and 530 of the prediction pipeline 554 when the dynamically predicted branch to be executed is an intraline (i.e., on the same line of metadata previously read from LOB208), without requiring re-access to LOB208 (reading LOB208).

[0047] The prediction pipeline 554 is configured to constantly reuse lines of instruction metadata output from the prediction cache to generate a new prediction in response to the previous prediction being made for the (same) line of metadata. For example, the metadata predictor 200 of processor 101 is configured to execute a loop 550, which includes blocks 526, 528, and 530 of the prediction pipeline 554, to constantly reuse lines of instruction metadata output from LOB 208 to generate a new prediction using the prediction logic 230 in block 526 in response to the previous prediction for a dynamically inferred branch being on an intraline (i.e., on the same line of metadata previously read from LOB 208).

[0048] The prediction is provided to the non-sequential instruction execution pipeline 250, which operates in parallel with the index pipeline 552 and the prediction pipeline 554.

[0049] As discussed herein, LIB204 can be indexed. Additionally, the line index accelerator 202 of the metadata predictor 200 can be used to further populate LIB204, allowing BTB1 to be accessed before the prediction pipeline 554, thereby minimizing prediction latency. In one or more embodiments, an example implementation may access BTB1 using bits 48:56 of the instruction address, since the number of entries in BTB1 should be 512. The example implementation operates on the 128B line (i.e., bits 57:63 = 7 corresponding to 128B), so it is possible to stop at bit 56.

[0050] According to one or more embodiments, the line index accelerator 202 includes a record of the next exit branch target (i.e., the exit target instruction address) for a given entry point (i.e., the entry instruction address). The record in the line index accelerator 202 includes instructions for both line exit branches and lines to be accessed sequentially. For example, the array inside the line index accelerator 202 can include information about line exit branches and sequential line usage. The line index accelerator 202 can include a sequential line offset engine that generates a sequential line index when it is necessary to access the sequential line index. The line index accelerator 202 uses this information to populate LIB204 (used to index BTB1 206), thereby allowing BTB1 206 to be read before the prediction pipeline 554. When BTB1 206 is read, the target address of the remaining exit branch (i.e., the remaining target instruction address at the exit point for the branch) may be determined via an initial target comparison mechanism. This target comparison mechanism may also be called a payload matching mechanism.

[0051] To illustrate the details of the line index accelerator 202 of the metadata predictor 200, Figure 11 is a flowchart of an accelerator flow 1100 for writing to the line index accelerator 202, according to one or more embodiments. The line index accelerator 202 may include, or utilize, accelerator logic 222 for performing accelerator flow 1100 and accelerator flow 1200, which is described later in Figure 12, or both.

[0052] In block 1102 of accelerator flow 1100, line index accelerator 202 is configured to receive successful predictions. Successful predictions can be received as output from prediction pipeline 554, or from instruction execution pipeline 250, or both. Successful predictions can be for instruction addresses that have a branch that may or may not be performed. In block 1104, line index accelerator 202 is configured to check whether the branch was performed or not. ("No") If the branch was not performed, line index accelerator 202 is configured to increment the offset in block 1106, and the flow returns to block 1102. Nothing is written to line index accelerator 202. Incrementing the offset means that the line index accelerator did not find a branch that was performed, and therefore processes the next line of ready metadata to store in line index accelerator. If a "Yes" branch is performed, the line index accelerator 202 is configured in block 1108 to check whether the branch performed was intraline. As referred to herein, intraline means that the target address is on the same metadata line as the instruction address being searched (i.e., the entry instruction address and the target address are on the same metadata line). If the target address of the "Yes" branch is intraline, the line index accelerator 202 is configured to return to block 1102 and nothing is written to the line index accelerator 202. On the other hand, if the target address of the ("No") branch is not intraline, the line index accelerator 202 is configured in block 1110 to check whether the target address of the branch performed is correct."Yes" If the target address is correct, the flow proceeds to block 1102, and nothing is written to line index accelerator 202. In other words, the next line required for the target address is already in index pipeline 552 and forecast pipeline 554. ("No") If the target address of the branch that was made is incorrect, line index accelerator 202 is configured to restart in block 1112 and update in block 1114. Furthermore, the restart event restarts all pipelines, including accelerators, indexes, and forecast pipelines. Updating line index accelerator 202 may include adding the correct target address of the branch that is to be made so that the correct target address is available for the branch that is to be made. Updating line index accelerator 202 may also include updating the branch offset and any tag information used to determine hits.

[0053] Figure 12 is a flowchart of an accelerator flow 1200 for reading a line index accelerator 202 into LIB 204, according to one or more embodiments. The line index accelerator 202 may include, utilize, or both accelerator logic 222 for performing the accelerator flow 1200. In block 1202 of the accelerator flow 1200, the line index accelerator 202 is configured to receive a reset event, the reset event having an instruction address as the reset address. An example of a reset event may be a false branch. In block 1204, the line index accelerator 202 is configured to index the line index accelerator 202 using the reset address (e.g., query the line index accelerator 202). In block 1206, the line index accelerator 202 is configured to check whether the reset address is a hit within the line index accelerator 202. If there is no hit from the instruction address (i.e., the reset address), the line index accelerator 202 is configured in block 1208 to shut down the line index accelerator 202 and wait for the next reset address. If there is a hit from the instruction address (i.e., the reset address), the line index accelerator 202 is configured in block 1210 to check whether the line read from the line index accelerator 202 requires a sequential line. ("No") If the line read from line index accelerator 202 does not require a sequential line, line index accelerator 202 is configured in block 1214 to multiplex the read line (i.e., the target line), and as a result, in block 1216, the line is written to LIB204.Furthermore, the flow returns to block 1204 so that the read line (i.e., the target line) is used to query / index the line index accelerator 202 for the next exit branch.

[0054] If the line read from the line index accelerator 202 requires a sequential line, the line index accelerator 202 is configured in block 1212 to perform a line offset to output the sequential line. In block 1214, the line index accelerator 202 multiplexes the sequential line to LIB204, and in block 1216, it is configured to write the sequential line to LIB204. For example, if the line read from the line index accelerator 202 is line X, the line index accelerator 202 is configured to perform a line offset to obtain line X+1, which corresponds to a subset of instruction address bits needed to search for line X+1 in BTB1 206, and therefore the line index accelerator 202 stores line X+1 immediately after line X in LIB204. Performing a line offset means adding a predetermined number of bits to the previous line (e.g., line X) to create a sequential line (e.g., line X+1) that is used as an index to query the corresponding line of metadata for the sequential line in BTB1 206. Since each line of metadata in BTB1 206 is in a known format (e.g., a metadata line is 128B), the offset is a fixed amount to move to the next line (i.e., sequential line). The sequential line (e.g., sequential line X+1) is fed back to block 1210, where the line index accelerator 202 is configured to check if another sequential line is needed, and if so, a line offset is added in block 1212 to generate the next sequential line, such as sequential line X+2. This loop can continue three times in one or more embodiments, resulting in sequential lines X+1, X+2, and X+3, each of which is written to LIB204.In one or more embodiments, sequential lines X+1, X+2, and X+3 can be written sequentially to LIB204. In one or more embodiments, sequential lines X+1, X+2, and X+3 can all be written simultaneously, for example, in parallel with LIB204.

[0055] Figure 13 is a block diagram of an example latency accelerator entry for a line index accelerator 202 according to one or more embodiments. The example accelerator entry has a first part 1350 used to determine what is written (stored) in LIB204 and how the search of the line index accelerator 202 continues. When the line index accelerator 202 no longer requires the generation of sequential lines, the target of an exit branch, which will become the entry point for the next search, is fed back to the line index accelerator 202 to read new lines. The first part 1350 of the example accelerator entry includes an exit branch target field 1302, for example, as instruction address bits 48:62, an offset field 1304, as bits 0:1, and a SKOOT field 1306, as bits 0:1.

[0056] The second part 1352 of the accelerator entry example is used for hit detection within the line index accelerator 202. The second part 1352 includes, for example, the entry point field 1308 as instruction address bits 48:53, the global path vector (GPV) field 1310 as instruction address 0:1, and the transaction register (TID) field 1312.

[0057] Figure 14 is a flowchart of an accelerator flow 1400 for performing payload matching in one or more embodiments. The line index accelerator 202 may include, utilize, or both accelerator logic 222 for performing the accelerator flow 1400. Payload matching combines BTB1 data with accelerator data to find the instruction address bits required for hit detection. In blocks 1402 and 1404 of the accelerator flow 1400, the line index accelerator 202 is configured to populate LIB204 with its contents, which are instruction address bits for the lines of metadata, and to perform an "OR" operation on the output. In one or more embodiments, the line index accelerator 202 may multiplex (mux) the output from BTB1. LIB204 operates independently. If LIB204 contains valid entries that have not yet been used to index BTB1, LIB204 will send these to BTB1 for indexing, and when BTB1 is read, its contents will be used in conjunction with the next LIB entry for payload matching. For example, payload matching uses IA(48:62) of two LIB entries (the two LIB entries in this example are X(48:62) and Y(48:62) to find Y(32:47), which will be needed for the next search). The line index accelerator 202 does not need Y(32:47) to query BTB1 during the next search, but for example in block 514 discussed herein, the line index accelerator 202 will need Y(32:47) for hit detection. The tag is bit Y(32:47) of the current search line. BTB1 contains bits 32:47 of the read 128B line (for example, this is sometimes called BTB1(32:47)).To determine if there is a hit, Y(32:47) and BTB1(32:47) must match; if they do not match, what was read is for a different line. Payload matching looks at all target addresses of the current search X to find Y(32:47) for the next search. BTB1 206 is operable in its parent base design, and BTB1 206 is divided into four quarters BTB1 206_0, BTB1 206_1, BTB1 206_2, BTB1 206_3 (collectively called BTB1 206), or operates in these quarters. After indexing (for example, after a search), each of BTB1 206_0, BTB1 206_1, BTB1 206_2, and BTB1 206_3 produces its output. In one or more embodiments, each of the BTB1 206_0, BTB1 206_1, BTB1 206_2, and BTB1 206_3 can output target instruction address bits (32:62) for up to six branches.

[0058] Figure 15 is a block diagram of an example accelerator according to one or more embodiments. Figure 15 illustrates three lines of code, which are lines X, Y, and Z (with branches) within the line index accelerator 202. Information about these branches (i.e., metadata) is collected within BTB1 202. In the index pipeline 552, the line index accelerator 202 is configured to be indexed (e.g., queried) using the entry instruction address (X) for line X, and the line index accelerator 202 finds a pointer to the entry instruction address (Y) for line Y. Thus, the line index accelerator 202 is configured to write the entry instruction address (Y) for line Y to LIB204. The entry instruction address (X) for line X also has an exit branch on line X.

[0059] The line index accelerator 202 is configured to index using the entry instruction address (Y) for line Y, and the line index accelerator 202 finds a pointer to the entry instruction address (Z) for line Z. Therefore, the line index accelerator 202 is configured to write the entry instruction address (Z) for line Z to LIB204. The entry instruction address (Y) for line Y has an exit branch on line Y. Furthermore, the line index accelerator 202 is configured to index using the entry instruction address (Z) for line Z, and the process continues.

[0060] Figure 16 is a block diagram of an example accelerator according to one or more embodiments. Figure 16 illustrates four lines of code within the line index accelerator 202, illustrating the use of sequential lines. Information about these branches (e.g., metadata) is collected within BTB1 202. In the index pipeline 552, the line index accelerator 202 is configured to index using the entry instruction address (X) for line X, and the line index accelerator 202 finds a pointer to the entry instruction address (Y) for line Y. In order to find a pointer to the entry instruction address (Y) on line Y, the line index accelerator 202 is configured to determine that the entry instruction address (X) for line X indicates that a sequential line is required (e.g., as discussed in block 1210 of Figure 12). The line index accelerator 202 is configured to generate sequential line X+1 and write sequential line X+1 to LIB204 (as discussed, for example, in blocks 1212, 1214, and 1216 in Figure 12). The loop in blocks 1210, 1212, 1214, and 1216 may be repeated three times in a row, resulting in sequential lines X+1, X+2, and X+3. However, only sequential line X+1 is depicted in Figure 16. Note that sequential line X+1 is after line X (i.e., the next consecutive line) and before line Y. The same is true for lines X+1 and X+2. In another case, the line index accelerator 202 should write sequential lines X+1, X+2, and X+3, respectively, to LIB204. Returning to the example in Figure 16, the line index accelerator 202 then writes the entry instruction address (Y) to LIB204.

[0061] The line index accelerator 202 is configured to index using the entry instruction address (Y) for line Y (depicted, for example, as a flow from block 1210 back to block 1204 in Figure 12), and the line index accelerator 202 finds a pointer to the entry instruction address (Z) for line Z. Thus, the line index accelerator 202 is configured to write the entry instruction address (Z) to LIB204. Furthermore, the line index accelerator 202 is configured to index using the entry instruction address (Z) for line Z, and the process continues.

[0062] Figure 17 is a block diagram of an example pipeline including a line-index accelerator without line offset, according to one or more embodiments. In this example, line-index accelerator 202 is populated. Figure 17 is similar to the pipeline diagrams described above in Figures 7 and 9, except that line-index accelerator 202 is added in a mixed state (e.g., the yellow block depicted as an upward-sloping diagonal line). Upon reset, both the index pipeline and the accelerator pipeline begin to use the reset address. In cycle 1, since the accelerator has not yet completed one pass of the pipeline, the index pipeline writes line X+1 (depicted as block 512 in Figure 5, for example) to LIB. In cycle 4, the line index accelerator 202 learns that it needs line Y instead of line X+1, and therefore the index pipeline for line X+1 is canceled, the LIB entry for line X+1 is replaced with line Y, and B0 for line Y is initiated. Since the X+1 search was canceled with new information from line index accelerator 202, this creates a bubble in the forecast delivery (there is no B4 in cycle 6).

[0063] Figure 18 is a block diagram of an example pipeline including a line-index accelerator with line offset, according to one or more embodiments. In this example, line-index accelerator 202 is populated. Figure 18 is similar to Figure 17, but here Figure 18 adds sequential lines in a mixed state. In one example case, even if line-index accelerator 202 knew that it wanted line X+1, it would blindly cancel the X+1 index pipeline that had already started (the one that started in cycle 2) and trigger another one two cycles later, creating the same predictive delivery bubble as in Figure 17.

[0064] Figure 19 is a block diagram of an example pipeline including a line-index accelerator with line offset, according to one or more embodiments. In this example, the line-index accelerator 202 is popularized. Figure 19 shows the efficiency of fixed, or added to the example in Figure 18, or both. Therefore, since the X+1 line should occur automatically, the line-index accelerator 202 that performs the accelerator pipeline is configured to recognize that the reset search does not need to generate the X+1 line for the LIB. Thus, the line-index accelerator 202 writes line Y to the end of the LIB instead of generating X+1 which the LIB writes. In another case, the initial accelerator search knew that two sequential lines were needed, and it is assumed that the line-index accelerator 202 should have written X+2 and Y to the LIB. By resolving this potential issue, the index pipeline search for X+1 is not canceled, and no prediction bubble occurs.

[0065] Figure 20 is a block diagram of an example pipeline including a line index accelerator with line offsets and intraline branching, according to one or more embodiments. In this example, line index accelerator 202 is populated. Similar to Figure 18, Figure 20 adds intraline branching in a mixed manner, here so that line X is accessed twice. Because line X has intraline branching, the prediction bubble created by the potential problem in Figure 18 is hidden. Regardless of the resolution of the existing potential problem X+1, the prediction bubble may still exist from Figure 17. However, the presence of intraline branching should hide this bubble.

[0066] Figure 21 is a flowchart of a computer execution method 2100 for determining the index for LIB204 of the metadata predictor 200 using a line index accelerator 202 before an index is needed to read BTB1 206 into LOB208, according to one or more embodiments of the present invention. The computer execution method 2100 may be implemented using the computer system 100 of Figure 1. The processor 101 of Figure 1, together with any other processors discussed herein, may include, or perform, the functionality of the metadata predictor 200 discussed herein, or both. As referred to herein, the functionality of the processor 101 may be used, or performed, or both, in the hardware components of the hardware and software layer 60 depicted in Figure 31.

[0067] In block 2102 of the computer execution method 2100, the metadata predictor 200 is configured to query an index accelerator (e.g., line index accelerator 202) using a reset address. In block 2104, the metadata predictor 200 is configured to determine, in response to the query, that an index line (e.g., line X) exists within the index accelerator (e.g., line index accelerator 202). In block 2106, the metadata predictor 200 is configured to determine a sequential line to the index line within the index accelerator (e.g., line index accelerator 202) in response to having checked whether the index line has a sequential line within the index accelerator. For example, as depicted in block 1210 of Figure 12, the line index accelerator 202 is configured to check whether the line index accelerator 202 contains a sequential line, such as sequential line X+1, to an index line (e.g., line X). In block 2108, the metadata predictor 200 is configured to put (write) the sequential line into the index buffer.

[0068] An index accelerator is configured to determine one or more other sequential lines (e.g., sequential lines X+2, X+3) based on an index line (e.g., line X). An index accelerator (e.g., line index accelerator 202) is configured to place a sequential line and one or more other sequential lines into an index buffer before the sequential line and one or more other sequential lines required by the prediction pipeline (e.g., prediction pipeline 554 or instruction execution pipeline 250 or both). The index line includes the exit target instruction address of a branch for a given entry instruction address. In one or more embodiments, the index line may include a hash formed to take into account the exit branch instruction address and the target instruction address of the exit branch.

[0069] There are many technical benefits and solutions from using a processor with a line index accelerator in one or more embodiments. The line index accelerator maintains an index pipeline before the prediction pipeline, meaning that the LIB has and uses an index to read BTB1 into LOBs before the output from LOBs is needed to generate predictions. For example, when prepared in one or more embodiments, the line index accelerator reduces prediction latency from 4 cycles to 2 cycles. Also, because the index pipeline can be read in advance as a result of the index accelerator pre-providing the index to the LIB, the line index accelerator reduces the impact of delays in the index pipeline on prediction latency. As a further technical benefit and solution, the line index accelerator ignores intraline branches that are performed and all branches that are not performed. When trying to determine which BTB1 index needs to be searched, none of the branches that are not performed are relevant. Therefore, this allows the prediction pipeline to leverage a metadata prediction cache (e.g., LOBs) without affecting the index pipeline, thereby substantially increasing the capacity of the latency accelerator. One or more embodiments using line index accelerators enable set associativity, and thus multiple beneficial exit branches can be stored in the same index. As an additional technical benefit and solution, one or more embodiments limit the number of address bits that need to be traversed through the code to traverse branch predictions (which will be stored in the line index accelerator) by leveraging the implementation of reading BTB1 to find the remaining instruction address bits during payload matching. This enables the use of small line index accelerators and LIB arrays.

[0070] According to one or more embodiments, the metadata predictor 200 of the processor 101 may include a variable-length metadata predictor pipeline, as further discussed herein. For example, the variable-length metadata predictor pipeline may be included in the predictor pipeline 554, where the variability is based on strategically delaying the time for outputting predictions in the predictor pipeline 554. In one or more embodiments, the predictor logic 230 of the predictor pipeline 554 may include a main predictor 2202 and auxiliary predictors 2204 (e.g., auxiliary predictors 1, 2, 3), as depicted in Figure 22, along with other digital logic circuits (not shown) as understood by those skilled in the art. One or more embodiments are configured to incorporate slower, higher-accuracy auxiliary predictors and external delays into the predictor pipeline 554 by dynamically increasing the length (latency) of the predictor pipeline 554 as needed. The main predictor 2202 may not have the accuracy of the auxiliary predictors 2204, but can be a typical metadata predictor that makes faster predictions. In one or more embodiments, the primary predictor 2202 may include a dependency predictor, a load / store dependency predictor, a branch history table predictor, a predictor of branches that will or will not be performed, other metadata predictors, or a combination thereof. The auxiliary predictor 2204 may include a perceptron branch predictor with virtualized weights, an auxiliary branch predictor with usefulness tracking, other metadata predictors, or a combination thereof.

[0071] Most branches are predictable directly from BTB information, resulting in the lowest possible latency branch predictions. Some branches are more complex and require assistance from higher-accuracy auxiliary predictors. Often, these auxiliary predictors take more time to generate predictions, or are not physically close to the prediction pipeline (due to silicon area limitations), or both. Delaying all predictions to accommodate these less frequently used auxiliary predictors would be wasteful. Therefore, one or more embodiments implement a dynamic, variable-length prediction pipeline that allows these slower (auxiliary) predictions by the auxiliary predictor 2204 to be incorporated into the prediction pipeline 554 as needed, without delaying the faster and simpler (primary) predictions performed by the primary predictor 2202.

[0072] To illustrate further details of the variable-length metadata prediction pipeline of the metadata predictor 200, Figure 23 is a flowchart of the variable-length metadata prediction pipeline flow 2300 in one or more embodiments for determining when to use the auxiliary predictor 2204 (even when the primary predictor 2202 is used), when to extend the prediction pipeline, or both. In the metadata predictor 200, the primary predictor 2202, the auxiliary predictor 2204, and the prediction logic 230, which includes the logic, are available to implement the variable-length metadata prediction pipeline flow 2300 discussed herein.

[0073] In block 2302 of the variable-length metadata prediction pipeline flow 2300, the metadata predictor 200 is configured to read lines of metadata from LOB208. For example, LIB204 is configured to query BTB1 206 with an index / index line, and the output of BTB1 206 populates LOB208. LOB208 processes the metadata independently as soon as it becomes available. In block 2304, the metadata predictor 200 is configured to check whether the outputted lines of metadata are valid. For example, it checks if anything was actually read from LOB208. ("No") If the lines of metadata were not actually read, the flow returns to 2302. If the "Yes" metadata line is enabled, the metadata predictor 200 is configured to simultaneously generate a prediction using the primary predictor 2202 of the predictor logic 230 in block 2306, and generate auxiliary predictions using the auxiliary predictors 2204 (e.g., auxiliary predictors 1, 2, and 3) of the predictor logic 230 in block 2308. In block 2310, the metadata predictor 200 is configured to multiplex the primary prediction from the primary predictor 2202 with auxiliary predictions from the auxiliary predictors 2204 (e.g., auxiliary predictors 1, 2, and 3). The auxiliary predictions are selectable when the auxiliary predictions differ from the primary predictions.

[0074] In block 2312, the metadata predictor 200 is configured to check whether the primary prediction from primary predictor 2202 differs from the auxiliary prediction from auxiliary predictor 2204. ("No") If the predictions are the same, the flow proceeds to block 2316. ("Yes") If the primary and auxiliary predictions differ (e.g., done by instruction vs. not done by instruction), the metadata predictor 200 is configured in block 2320 to provide the multiplexer with a selection of bits (e.g., 0 or 1) to indicate that the auxiliary prediction should be passed to the logic. ("AND") Otherwise, for example, if there is no selector signal from block 2312, the multiplexer passes the primary prediction. ("Yes") If the primary and auxiliary predictions differ further, the metadata predictor 200 is configured in block 2314 to check whether the auxiliary prediction is complete, ready, or both. Checking whether the auxiliary prediction is complete / ready includes confirming that all information from the auxiliary prediction is available. The auxiliary prediction may contain enough information to determine that it differs from the primary prediction, but it may still be waiting for appropriate instructions or target information, or both, to be sent to and processed in the prediction pipeline 554. In an example implementation, the metadata predictor 200 may be configured to assume that the primary prediction is correct and that the auxiliary predictor 2204 is no longer needed as it has already been selected by the multiplexer 2310. Once the metadata predictor 200 knows that the auxiliary prediction is different, it is configured to wait for some subsequent cycles to generate the correct multiplexing selection and then broadcast the prediction (using the new target / instruction information from the auxiliary predictor 2204). If the auxiliary prediction is ready, the "AND" logic may be informed. If the auxiliary prediction is not ready, the metadata predictor 200 is configured in block 2316 to check whether the length or latency of the prediction pipeline 554 should be extended.In some cases, the length or latency of the prediction pipeline 554 may be extended until an auxiliary prediction is ready, but then it returns to block 2312 or block 2302 or both. Additionally, if the metadata predictor 200 receives a signal or instruction, or both, that the instruction execution pipeline 250 is not ready to receive a new prediction from block 2318, the metadata predictor 200 is configured to extend the time (i.e., latency) of the prediction pipeline 554 by delaying the broadcast of the new prediction (i.e., auxiliary prediction, or possibly primary prediction, or both) downstream to the instruction execution pipeline 250. In one or more embodiments, the metadata predictor 200 may reroute the flow back to block 2312 in order to extend the pipeline, thereby extending the time (i.e., latency), after which the new prediction is broadcast downstream to the instruction execution pipeline 250. In one or more embodiments, the metadata predictor 200 can reroute the flow back to block 2302 (rerouting is shown here) to extend the pipeline, thereby extending time (i.e., latency), after which the new prediction is broadcast downstream to the instruction execution pipeline 250. In one or more embodiments, the metadata predictor 200 can instruct "AND" logic (e.g., using one or more latches or other digital logic components, or both) to hold the new prediction over a predetermined number of clock cycles to extend the pipeline, thereby extending time (i.e., latency), after which the new prediction is broadcast downstream to the instruction execution pipeline 250. In one or more embodiments, the metadata predictor 200 can instruct a counter (not shown) to count over a predetermined number of clock cycles to extend the pipeline, thereby extending time (i.e., latency), after which the new prediction is broadcast downstream to the instruction execution pipeline 250.The metadata predictor 200 is configured to continuously check in block 2316 whether extension is necessary.

[0075] ("No") If the metadata predictor 200 stops receiving a signal or instruction (e.g., a bit) indicating that the instruction execution pipeline 250 is not ready to receive a new prediction from block 2318, and / or if an auxiliary prediction is available, the metadata predictor 200 is configured in blocks 2320 and 2322 to cause the "AND" logic to pass the new prediction (e.g., an auxiliary prediction) downstream to the instruction execution pipeline 250 through the logic.

[0076] Figure 24 is a block diagram of an example pipeline illustrating downstream congestion in one or more embodiments. This example illustrates a situation where downstream logic, which may be part of the instruction execution pipeline 250, or linked to the instruction execution pipeline 250, or both, is not ready for a prediction (e.g., primary or auxiliary prediction, or both) from the prediction logic 230. Therefore, the prediction logic 230 of the metadata predictor 200 is configured to extend the prediction pipeline 554, as depicted in block 2316, and it should be noted that the line of metadata that started the (new) prediction still exists in LOB 208. When the instruction execution pipeline 250 indicates that it is ready, the metadata predictor 200 can move the LOB pointer to repeat the output of the same line of metadata that started the (new) prediction, and as a result, the new prediction is immediately passed to the instruction execution pipeline 250 (i.e., passed without delay or extension, or both), thereby preparing a variable-length (e.g., time) metadata prediction pipeline.

[0077] Figure 25 is a block diagram of an example pipeline illustrating that, according to one or more embodiments, the auxiliary predictor 2204 has a different prediction from the primary predictor 2202. In the first trial in prediction LY, when there is a different auxiliary prediction, the metadata predictor 200 selects the primary prediction, assuming it should be used. However, in cycle 6, as the metadata predictor 200 is about to broadcast its prediction, it learns that the auxiliary predictor has different information. As a result, the metadata predictor 200 cancels broadcasting the primary prediction and selects a new auxiliary prediction (e.g., reduces the multiplicity). In an example of one implementation form, this actually goes all the way back to B2 (which is why "b2" appears in parentheses below b4), where the metadata predictor 200, now aware of the auxiliary prediction, regenerates the prediction. At B6, two cycles later, the new prediction is reportable and the flow can move to the next LOB entry.

[0078] Figure 26 is a block diagram of an example pipeline in one or more embodiments depicting an auxiliary predictor 2204 having the same prediction as the primary predictor 2202. This example illustrates that the prediction pipeline 554 can operate without extension or delay or both, thereby providing variability in the prediction pipeline 554 to handle complex branching when extension or delay or both occur, and / or simple branching when extension or delay or both occur. Thus, the prediction pipeline 554 does not slacken / delay by two clock cycles, for example, when the auxiliary and primary predictions are the same.

[0079] Figure 27 is a flowchart of a computer execution method 2700 for using a variable-length metadata prediction pipeline according to one or more embodiments of the present invention. The computer execution method 2700 may be implemented using the computer system 100 of Figure 1. The processor 101 of Figure 1, together with any other processors discussed herein, may include, or perform, the functionality of the metadata predictor 200 discussed herein, or both. The functionality of the processor 101 may be used, or performed, or both, in the hardware components of the hardware and software layer 60 depicted in Figure 31.

[0080] In block 2702 of the computer execution method 2700, the metadata predictor 200 is configured to generate a primary predictor (e.g., via primary predictor 2202) and an auxiliary predictor (e.g., via auxiliary predictor 2204) using lines of metadata (from LOB 208). In block 2704, the metadata predictor 200 is configured to determine that the primary and auxiliary predictors are different. In block 2706, the metadata predictor 200 is configured to select or decide to use the auxiliary predictor in response to the primary and auxiliary predictors being different. In block 2708, the metadata predictor 200 is configured to extend the length of the predictor pipeline 554 over a predetermined time (e.g., a predetermined number of clock cycles). In block 2710, the metadata predictor 200 is configured to provide the auxiliary predictor to the instruction execution pipeline 250 in response to the extension over the predetermined time. The auxiliary predictor requires a longer processing time (e.g., more clock cycles) than the primary predictor.

[0081] There are many technical benefits and solutions that can be achieved by using a processor with a variable-length metadata prediction pipeline in one or more embodiments. As discussed herein, slower and more precise predictions can be incorporated into the prediction pipeline without sacrificing the low latency of the basic prediction. The slower predictions are applied before they affect downstream instruction fetching. The technical benefits and solutions allow auxiliary predictors to reside physically separate from the prediction pipeline on the integrated circuit chip to save space. For example, a variable-length metadata prediction pipeline can consider cases where downstream logic cannot accept more prediction information. A variable-length metadata prediction pipeline can be used in conjunction with the reuse of metadata predictor caches (e.g., LOBs) and intraline branches. Furthermore, a variable-length metadata prediction pipeline can be incorporated into parent-based systems.

[0082] Figure 28 is a block diagram of a system 2800 for a metadata predictor 200 according to an embodiment of the present invention. The system 2800 includes a processing circuit 2810 used to generate a design 2830 (including the metadata predictor 200) which will ultimately be fabricated into an integrated circuit 2820. The steps involved in fabricating the integrated circuit 2820 are well known and are briefly described herein. To facilitate the optimization of the routing plan, once the physical layout 2840 is finalized based in part on the metadata predictor 200 according to an embodiment of the present invention, the finalized physical layout 2840 is sent to the foundry. A mask is generated for each layer of the integrated circuit based on the finalized physical layout. The wafer is then processed in a sequence according to the mask order. The processing includes photolithography and etching, which will be discussed further with reference to Figure 29.

[0083] Figure 29 is a process flow of a method for fabricating an integrated circuit according to an exemplary embodiment of the present invention. Once physical design data is acquired in part from the metadata predictor 200, the integrated circuit 120 can be fabricated according to a known process described in whole with reference to Figure 29. Generally, a wafer having multiple copies of the final design is fabricated and cut (i.e., diced) so that each die is one copy of the integrated circuit 2820. In block 2910, the process includes fabricating a mask for lithography based on the final determined physical layout. In block 2920, fabricating the wafer includes performing photolithography and etching using the mask. Once the wafer is diced, in block 2930, each die is inspected and sorted to remove all defective dies.

[0084] While this disclosure includes a detailed description of cloud computing, it should be understood that the implementations of the teachings enumerated herein are not limited to cloud computing environments. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment, whether currently known or to be developed later.

[0085] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly delivered and released with minimal administrative effort or interaction with service providers. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0086] The characteristics are as follows: On-demand self-service: Cloud users can unilaterally access computing power, such as server time and network storage, automatically and as needed, without requiring human interaction with service providers. Broad network access: Capabilities are available over a network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs). Resource pooling: A provider's computing resources are pooled to serve multiple users using a multi-tenant model, with various physical and virtual resources dynamically allocated and reallocated as needed. Location independence is significant in that users generally have no control or knowledge of the exact location of the resources provided, but can specify a location at a higher level of abstraction (e.g., country, state, or data center). Rapid resilience: Capabilities are provided quickly and flexibly, sometimes automatically, to scale out rapidly, and can be quickly released to scale in rapidly. To the user, the available capacity for provision often appears unlimited and can be purchased in any quantity at any time. Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metric capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource utilization can be monitored, controlled, and reported, providing transparency to both service providers and users.

[0087] The service model is as follows: Software as a Service (SaaS): The ability provided to the user is the use of the provider's applications running on a cloud infrastructure. These applications are accessible from various client devices through thin-client interfaces, such as web browsers (e.g., web-based email). Users have no management or control over the underlying cloud infrastructure, including the network, servers, operating system, storage, or possibly individual application capabilities, with the exception of limited user-specific application configuration settings. Platform as a Service (PaaS): The ability provided to the user is to deploy user-created or acquired applications, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage, but does have control over the deployed applications and, in some cases, the configuration of the application hosting environment. Infrastructure as a Service (IaaS): The capability provided to the user is to offer processing, storage, networking, and other basic computing resources that the user can deploy and run any software, including operating systems and applications. The user does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, deployed applications, and, in some cases, limited control over selected networking components (e.g., host firewalls).

[0088] The deployment model is as follows: Private Cloud: The cloud infrastructure is operated solely for the organization. The cloud infrastructure may be managed by this organization or a third party and may reside on-premises or off-premises. Community Cloud: Cloud infrastructure is shared by several organizations and supports a unique community that has shared concerns (e.g., mission, security requirements, policies, and compliance considerations). Cloud infrastructure can be managed by an organization or a third party and can reside on-premises or off-premises. Public cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by organizations that sell cloud services. Hybrid Cloud: Cloud infrastructure remains a unique entity, but it is a composite of two or more clouds (private, community, or public) bound together by standard or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0089] Cloud computing environments are service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure, including a network of interconnected nodes.

[0090] Referring here to Figure 30, an exemplary cloud computing environment 50 is depicted. As shown in the figure, the cloud computing environment 50 includes one or more cloud computing nodes 10 to which local computing devices used by cloud users can communicate, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, or an automotive computer system 54N, or a combination thereof. The nodes 10 may communicate with each other. The nodes 10 may be physically or virtually grouped in one or more networks, such as private, community, public, or hybrid clouds, or a combination thereof, as described herein (not shown). This allows the cloud computing environment 50 to provide infrastructure, platforms, or software as a service, or a combination thereof, without requiring cloud users to maintain resources on their local computing devices. The types of computing devices 54A-N shown in Figure 30 are intended to be illustrative only, and it should be understood that the computing node 10 and the cloud computing environment 50 can communicate with any type of computerized device via any type of network or network addressable connection or both (e.g., using a web browser).

[0091] Referring here to Figure 31, a set of functional abstraction layers provided by the cloud computing environment 50 (Figure 30) is shown. It should be understood in advance that the components, layers, and functionalities shown in Figure 31 are illustrative only and that embodiments of the present invention are not limited thereto. The following layers and corresponding functionalities are provided as described:

[0092] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include a mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based servers 62, 63, blade servers 64, storage devices 65, and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0093] The virtualization layer 70 provides an abstraction layer that may provide examples of virtual entities, such as virtual servers 71, virtual storage 72, virtual networks 73 including virtual private networks, virtual applications and operating systems 74, and virtual clients 75.

[0094] In one example, the management layer 80 may provide the functions described below. Resource provisioning 81 dynamically procures computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 tracks the costs of using resources within the cloud computing environment and bills or invoices for the usage of these resources. In one example, these resources may include application software licenses. Security verifies the identity of cloud users and tasks, and protects data and other resources. The user portal 83 provides users and system administrators with access to the cloud computing environment. Service level management 84 allocates and manages cloud computing resources to ensure that required service levels are met. Service level agreement (SLA) planning and execution 85 pre-positions and procures cloud computing resources for anticipated future requirements in accordance with the SLA.

[0095] The workload layer 90 provides examples of functions that can be utilized in a cloud computing environment. Examples of workloads and functions that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom education delivery 93, data analytics processing 94, transaction processing 95, and workloads and functions 96.

[0096] Various embodiments of the present invention are described herein with reference to the relevant drawings. Alternative embodiments of the present invention can be devised without departing from the scope of the invention. Various connections and positional relationships between elements (e.g., above, below, adjacent, etc.) are described in the following description and drawings. These connections or positional relationships, or both, can be direct or indirect unless otherwise specified, and the present invention is not intended to limit in this respect. Thus, connections between entities can refer to direct or indirect connections, and positional relationships between entities can be direct or indirect positional relationships. Furthermore, the steps of the various tasks and processes described herein can be incorporated into more comprehensive procedures or processes having additional steps or functions not described in detail herein.

[0097] One or more of the methods described herein can be implemented using any technique or combination of techniques well known in the art, such as individual logic circuits having logic gates for performing logic functions based on data signals, application-specific integrated circuits (ASICs) having appropriate combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0098] For the sake of brevity, prior art relating to the implementation and use of aspects of the present invention may or may not be described in detail herein. In particular, various aspects of computing systems and specific computer programs for implementing the various technical features described herein are well known. Therefore, for the sake of brevity, details of many conventional implementations are either briefly mentioned herein or omitted entirely without providing details of well known systems or processes or both.

[0099] In some embodiments, various functions or actions can be performed at a given location, or in conjunction with the operation of one or more devices or systems, or both. In some embodiments, some of the functions or actions can be performed at a first device or location, while the remaining functions or actions can be performed at one or more additional devices or locations.

[0100] The technical terms used herein are for the purpose of describing specific embodiments and are not intended to limit them. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless otherwise explicitly indicated by the context. It will be further understood that the terms “comprises” or “comprising,” when used herein, specify the presence of a described feature, integer, step, action, element, or component, or combination thereof, but do not exclude the presence or addition of one or more other features, integers, steps, actions, element components, or groups thereof, or combination thereof.

[0101] All means or steps and functional elements in the following claims, corresponding structures, materials, actions, and equivalents are intended to include any structure, material, or action for performing a function in combination with other claimed elements, such as those specifically claimed. While this disclosure has been presented for illustrative and explanatory purposes, it is not intended to be exhaustive or to limit the form of disclosure. Many variations and modifications that do not deviate from the scope and spirit of this disclosure will be apparent to those skilled in the art. The embodiments have been selected and described to best illustrate the principles and practical applications of this disclosure, and to enable those other skilled in the art to understand the disclosure of various embodiments with various modifications suitable for specific intended uses.

[0102] The diagrams depicted herein are illustrative. Many variations may exist to the diagrams or steps (or actions) described, which do not deviate from the spirit of this disclosure. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Furthermore, the term “connected” means having a signal path between two elements, and does not imply a direct connection between elements without an intervening element / connection. All of these variations are considered part of this disclosure.

[0103] The following definitions and abbreviations will be used for the purposes of the claims and interpretation of this specification. As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” “contains,” or “containing,” or any other variation thereof, are intended to include non-exclusive inclusion. For example, a structure, mixture, process, method, item, or apparatus containing a list of elements is not necessarily limited to these elements and may include other elements not explicitly listed or inherent in such structure, mixture, process, method, item, or apparatus.

[0104] In addition, the term “exemplary” is used herein to mean “to serve as an example, instance, or illustration.” Any embodiment or design described herein as “exemplary” should not necessarily be construed as preferable or advantageous to other embodiments or designs. The terms “at least one” and “one or more” are understood to include one or more any integers, i.e., 1, 2, 3, 4, etc. The term “multiple” is understood to include two or more any integers, i.e., 2, 3, 4, 5, etc. The term “connection” can include both indirect and direct “connection.”

[0105] The terms “about,” “substantially,” “approximately,” and their variations are intended to include some degree of error associated with measurements of a particular quantity based on the equipment available at the time of filing this application. For example, “about” could include a range of ±8% or 5%, or 2% of a given value.

[0106] The present invention may be a system, method, or computer program product, or a combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium (or more mediums) having computer-readable program instructions for causing a processor to execute an aspect of the present invention.

[0107] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction-executing device. A computer-readable storage medium may, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A less-than-complete list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved-reinforced structures on which instructions are recorded, and any suitable combination thereof. Computer-readable storage media as used herein should not be interpreted as inherently transient signals, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0108] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to each computing / processing device, or to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. The network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on the computer-readable storage media within each computing / processing device.

[0109] The computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk(R), C++, or similar, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may be executed as a standalone software package, either entirely or partially on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, electronic circuits including programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions by individualizing the electronic circuits using state information of computer-readable program instructions in order to carry out aspects of the present invention.

[0110] Aspects of the present invention will be described herein with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block in a flowchart or block diagram, or both, and combinations of blocks in a flowchart or block diagram, or both, are executable by computer-readable program instructions.

[0111] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a machine that generates means for instructions to be executed via the processor of a computer or other programmable data processing device to perform functions / actions specified in one or more blocks of a flowchart or block diagram, or both. These computer-readable program instructions may also be stored on a computer-readable storage medium so that the computer-readable storage medium containing the instructions can provide a product containing instructions to perform a manner of function / action specified in one or more blocks of a flowchart or block diagram, or both, and can be directed to a computer, a programmable data processing device, or other device, or a combination thereof, to function in a particular manner.

[0112] Computer-readable program instructions may also be loaded onto a computer, another programmable device, or another device to perform a series of operational steps on the computer, another programmable device, or another device in order to generate computer execution processing in order to produce instructions that will be executed on the computer, another programmable device, or another device in order to perform a function / action specified in one or more blocks of a flowchart or block diagram or both.

[0113] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for performing a specified logical function. In some alternative implementations, the functions described in a block may be performed independently of the order shown in the diagram. For example, two consecutively shown blocks may actually be executed substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the functions they contain. It should also be noted that each block in a block diagram or flowchart, or both, and any combination of blocks in a block diagram or flowchart, or both, is executable by a dedicated hardware-based system that performs a specified function or action, or executes a combination of dedicated hardware and computer instructions.

[0114] The descriptions of various embodiments of the present invention have been presented for illustrative purposes only and are not intended to be exhaustive or limitful to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the embodiments described. The terminology used herein has been chosen to best describe the principles, practical applications, or technical improvements to the technologies available on the market of the embodiments, or to enable other those skilled in the art to understand the embodiments described herein.

Claims

1. A computer execution method, Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, the index in the index buffer is generated using an accelerator, and the write to the accelerator is at least partially based on whether the target address of the branch is intraline. Populating the metadata of an instruction into a predictive cache, wherein the metadata of the instruction is read from the memory device, The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. A computer execution method, including...

2. A computer execution method, Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of an instruction into a predictive cache, wherein the metadata of the instruction is read from the memory device, The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. Includes, The index buffer is configured not to rely on generating the prediction using the metadata from the prediction cache, but to read the memory device containing the metadata for the prediction cache before generating the prediction. Computer execution method.

3. A computer execution method, Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of an instruction into a predictive cache, wherein the metadata of the instruction is read from the memory device, The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. Includes, The prediction pipeline is configured to output lines of the metadata for the instructions from the prediction cache. Computer execution method.

4. A computer execution method, Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of an instruction into a predictive cache, wherein the metadata of the instruction is read from the memory device, The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. Includes, The prediction pipeline is configured to continuously reuse the line of metadata for the instruction from the prediction cache without requiring re-access to the memory device. Computer execution method.

5. A computer execution method, Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of an instruction into a predictive cache, wherein the metadata of the instruction is read from the memory device, The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. Includes, In response to a previous prediction being made for a line of metadata, the prediction pipeline is configured to continuously reuse the line of metadata for the instruction output from the prediction cache to generate a new prediction. Computer execution method.

6. A computer execution method according to any one of claims 1 to 5, wherein populating the metadata of the instruction into the prediction cache is performed asynchronously with respect to the operation of the prediction pipeline, and includes continuously indexing the memory device to read the metadata for the prediction cache, independently of the process of the prediction pipeline.

7. The computer execution method according to any one of claims 1 to 5, wherein the prediction is sent to an unsequential instruction execution pipeline, and the unsequential instruction execution pipeline operates in parallel with the index pipeline and the prediction pipeline.

8. It is a system, Memory with computer-readable instructions, One or more processors for executing the computer-readable instruction, wherein the computer-readable instruction is Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, the index in the index buffer is generated using an accelerator, and the write to the accelerator is at least partially based on whether the target address of the branch is intraline. Populating the metadata of instructions from the aforementioned memory device into a predictive cache, and The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. Controlling one or more processors to perform a process including the processor and A system that includes these features.

9. A system, Memory with computer-readable instructions, One or more processors for executing the computer-readable instruction, wherein the computer-readable instruction is Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of instructions from the aforementioned memory device into a predictive cache, and The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. Controlling one or more processors to perform a process including the processor and It is equipped with, The index buffer is configured not to rely on generating the prediction using the metadata from the prediction cache, but to read the memory device containing the metadata for the prediction cache before generating the prediction. system.

10. A system, Memory with computer-readable instructions, One or more processors for executing the computer-readable instruction, wherein the computer-readable instruction is Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of instructions from the aforementioned memory device into a predictive cache, and The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. Controlling one or more processors to perform a process including the processor and It is equipped with, The prediction pipeline is configured to output lines of the metadata for the instructions from the prediction cache. system.

11. A system, Memory with computer-readable instructions, One or more processors for executing the computer-readable instruction, wherein the computer-readable instruction is Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of instructions from the aforementioned memory device into a predictive cache, and The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. Controlling one or more processors to perform a process including the processor and It is equipped with, The prediction pipeline is configured to continuously reuse the line of metadata for the instruction from the prediction cache without requiring re-access to the memory device. system.

12. A system, Memory with computer-readable instructions, One or more processors for executing the computer-readable instruction, wherein the computer-readable instruction is Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of instructions from the aforementioned memory device into a predictive cache, and The prediction pipeline is operated to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline. Controlling one or more processors to perform a process including the processor and It is equipped with, In response to a previous prediction being made for a line of metadata, the prediction pipeline is configured to continuously reuse the line of metadata for the instruction output from the prediction cache to generate a new prediction. system.

13. The system according to any one of claims 8 to 12, wherein populating the metadata of the instruction into the prediction cache is performed asynchronously with respect to the operation of the prediction pipeline, and includes continuously indexing the memory device to read the metadata for the prediction cache, independently of the process of the prediction pipeline.

14. The system according to any one of claims 8 to 12, wherein the prediction is sent to an unsequential instruction execution pipeline, and the unsequential instruction execution pipeline operates in parallel with the index pipeline and the prediction pipeline.

15. A computer program comprising a computer-readable storage medium that embodies program instructions, wherein the computer Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, the index in the index buffer is generated using an accelerator, and the write to the accelerator is at least partially based on whether the target address of the branch is intraline. Populating the metadata of the instructions from the aforementioned memory device into the prediction cache, A computer program that operates a prediction pipeline to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline.

16. A computer program comprising a computer-readable storage medium that embodies program instructions, wherein the computer Operating an index pipeline to generate an index in an index buffer, wherein the index buffer does not rely on generating predictions using metadata from a prediction cache, but is configured to read a memory device containing the metadata for the prediction cache before generating the predictions, and the index is used to read the memory device, and the operation is as follows: Populating the metadata of the instructions from the aforementioned memory device into the prediction cache, A computer program that operates a prediction pipeline to generate predictions using the metadata of the instructions from the prediction cache, wherein the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline.

17. A computer program comprising a computer-readable storage medium that embodies program instructions, wherein the computer Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of the instructions from the aforementioned memory device into the prediction cache, A computer program that operates a prediction pipeline to generate predictions using the metadata of the instructions from the prediction cache, wherein the prediction pipeline is configured to output lines of the metadata of the instructions from the prediction cache, and the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline.

18. A computer program comprising a computer-readable storage medium that embodies program instructions, wherein the computer Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of the instructions from the aforementioned memory device into the prediction cache, A computer program that operates a prediction pipeline to generate predictions using the metadata of the instructions from the prediction cache, wherein the prediction pipeline is configured to constantly reuse lines of the metadata of the instructions from the prediction cache without requiring re-access to the memory device, and the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline.

19. A computer program comprising a computer-readable storage medium that embodies program instructions, wherein the computer Operating an index pipeline to generate an index in an index buffer, wherein the index is used to read from a memory device, Populating the metadata of the instructions from the aforementioned memory device into the prediction cache, A computer program that operates a prediction pipeline to generate predictions using the metadata of the instructions from the prediction cache, wherein the prediction pipeline is configured to continuously reuse the lines of the metadata of the instructions output from the prediction cache to generate new predictions in response to a previous prediction being made for the lines of the metadata, and the population of the metadata of the instructions into the prediction cache is performed asynchronously with the operation of the prediction pipeline.

20. A computer program according to any one of claims 15 to 19, wherein populating the metadata of the instruction into the prediction cache is performed asynchronously with respect to the operation of the prediction pipeline, and includes continuously indexing the memory device to read the metadata for the prediction cache, independently of the process of the prediction pipeline.

21. The computer program according to any one of claims 15 to 19, wherein the prediction is sent to an unsequential instruction execution pipeline, and the unsequential instruction execution pipeline operates in parallel with the index pipeline and the prediction pipeline.

22. The computer program according to any one of claims 15 and 17-19, wherein the index buffer is configured to read the memory device having the metadata for the prediction cache before generating the prediction, rather than relying on the metadata from the prediction cache to generate the prediction.

23. The computer program according to any one of claims 15-16 and 18-19, wherein the prediction pipeline is configured to output lines of the metadata of the instructions from the prediction cache.

24. The computer program according to any one of claims 15 to 17 and 19, wherein the prediction pipeline is configured to continuously reuse the line of metadata for the instruction from the prediction cache without requiring re-access to the memory device.

25. The computer program according to any one of claims 15 to 18, wherein, in response to a previous prediction being made for a line of metadata, the prediction pipeline is configured to continuously reuse the line of metadata for the instruction output from the prediction cache to generate a new prediction.

Images