Instruction Set Architecture-Based Automatic Workload Tracing for Opportunistic Redirection of Data-Dependent Vulnerable Branches

Abstract

To provide hardware that overrides prediction about a branch instruction in which branch instruction results depend on load instruction results.SOLUTION: In a computing system 101, a processor includes a pipeline circuit having a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions, a branch predictor circuit for generating a prediction path for a branch instruction, and a branch reinduction circuit. For branch instructions that depend on results from load instructions, if an instruction received by the pipeline circuit is a load instruction, the branch reinduction circuit checks writeback resulting from the load instruction between decoding a branch instruction in the decoder and executing the branch instruction in the execution circuit. If the prediction path is different from a path based on the result from the load instruction, the branch reinduction circuit reinduces the branch instruction in the pipeline circuit to the path, and causes execution of the branch instruction on the path based on the result from the load instruction.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This patent application claims the benefit of Indian Provisional Patent Application No. 202041016867, entitled "ISA-Based Automatic Load Tracking for Opportunistic Override of Data-Dependent Vulnerable Branches," filed on April 20, 2020, which is hereby incorporated by reference in its entirety.

[0002] The present disclosure relates generally to electronic devices, and embodiments of the present disclosure more specifically relate to hardware for overriding predictions for branch instructions whose outcome depends on the outcome of a load instruction. [Background technology]

[0003] A processor or set of processors executes instructions from an instruction set, e.g., an instruction set architecture (ISA). An instruction set is a portion of a computer architecture related to programming and generally includes native data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input and output (I / O). Note that the term instructions herein may refer to macroinstructions, e.g., instructions provided to a processor for execution, or microinstructions, e.g., instructions resulting from a decoder of a processor decoding a macroinstruction. [Brief description of the drawings]

[0004] The present disclosure is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference symbols indicate similar elements and in which:

[0005] [Figure 1] 1 illustrates a hardware processor including at least one branch predictor circuit and at least one branch redirection circuit, according to an embodiment of the present disclosure.

[0006] [Diagram 2] 1 illustrates a computer system including a branch predictor circuit and a branch redirection circuit in a pipeline processor according to an embodiment of the present disclosure.

[0007] [Diagram 3] 4 illustrates an example format of a load dependency branch table entry, according to an embodiment of the present disclosure.

[0008] [Figure 4] 1 illustrates an example format of an Instruction Set Architecture (ISA) extension for one dependent branch instruction, according to an embodiment of the present disclosure.

[0009] [Diagram 5] 1 illustrates an example format of an Instruction Set Architecture (ISA) extension for two dependent branch instructions according to an embodiment of the present disclosure.

[0010] [Figure 6] 1 illustrates a flow diagram for populating a load dependency branch table (LDBT) for branch redirection according to an embodiment of the present disclosure.

[0011] [Figure 7] 1 illustrates an example format of an architectural register file (ARF) extension, according to an embodiment of the present disclosure.

[0012] [Figure 8] 1 illustrates a flow diagram triggered by receiving a load instruction when branch redirection is enabled, according to an embodiment of the present disclosure.

[0013] [Figure 9] 1 illustrates a flow diagram triggered by receiving a branch instruction when branch redirection is enabled, according to an embodiment of the present disclosure.

[0014] [Figure 10]1 illustrates a flow diagram triggered by a writeback of a load instruction when branch redirection is enabled, according to an embodiment of the present disclosure.

[0015] [Figure 11] 1 illustrates a flow diagram of branch redirection according to an embodiment of the present disclosure.

[0016] [Figure 12A] FIG. 2 is a block diagram illustrating a generic vector friendly instruction format and its class A instruction templates, according to an embodiment of the present disclosure.

[0017] [Figure 12B] FIG. 2 is a block diagram illustrating a generic vector friendly instruction format and its class B instruction templates, according to an embodiment of the present disclosure.

[0018] [Figure 13A] FIG. 12C is a block diagram illustrating the fields of the generic vector friendly instruction format of FIGS. 12A and 12B in accordance with an embodiment of the present disclosure.

[0019] [Figure 13B] FIG. 13B is a block diagram illustrating the fields of the vector-specific instruction format in FIG. 13A that constitute the full opcode field, in accordance with one embodiment of the present disclosure.

[0020] [Figure 13C] FIG. 13B is a block diagram illustrating the fields of the vector specific instruction format of FIG. 13A that constitute a register index field in accordance with one embodiment of the present disclosure.

[0021] [Figure 13D] FIG. 13B is a block diagram illustrating the fields of the vector-specific instruction format in FIG. 13A that constitute the extended operation field 1250, in accordance with one embodiment of the present disclosure.

[0022] [Figure 14]FIG. 2 is a block diagram of a register architecture according to one embodiment of the present disclosure.

[0023] [Figure 15A] 1A-1C are block diagrams illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline, in accordance with an embodiment of the present disclosure.

[0024] [Figure 15B] 2 is a block diagram illustrating both an example embodiment of an in-order architecture core and an example register renaming, out-of-order issue / execution architecture core included in a processor in accordance with an embodiment of the present disclosure.

[0025] [Figure 16A] 1 is a block diagram of a single processor core shown with its connection to an on-die interconnect network and a local subset of a level 2 (L2) cache, according to an embodiment of the present disclosure.

[0026] [Figure 16B] FIG. 16B is an expanded view of a portion of the processor core in FIG. 16A according to an embodiment of the present disclosure.

[0027] [Figure 17] FIG. 2 is a block diagram of a processor that may have more than one core, may have an integrated memory controller, and may have integrated graphics, according to an embodiment of the present disclosure.

[0028] [Figure 18] FIG. 1 is a block diagram of a system according to one embodiment of the present disclosure.

[0029] [Figure 19] FIG. 2 is a block diagram of a more specific exemplary system according to an embodiment of the present disclosure.

[0030] [Figure 20]FIG. 2 shows a block diagram of a second more specific exemplary system according to an embodiment of the present disclosure.

[0031] [Figure 21] 1 illustrates a block diagram of a system on a chip (SoC) according to an embodiment of the present disclosure.

[0032] [Figure 22] 1 is a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set, according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0033] In the following description, numerous specific details are set forth. However, it is understood that embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

[0034] References herein to "one embodiment," "embodiment," "exemplary embodiment," and the like indicate that the embodiment being described may include a particular feature, structure, or characteristic, but that all embodiments may not necessarily include such a particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with one embodiment, it is believed to be within the knowledge of one of ordinary skill in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly described.

[0035] A (e.g., hardware) processor (e.g., having one or more cores) may execute instructions (e.g., threads of instructions) to process data, such as to perform an arithmetic, logic, or other function. For example, software may request an operation, and a hardware processor (e.g., its one or more cores) may perform the operation in response to the request. In particular embodiments, the operation (e.g., thread) that is executed includes one or more branch operations (e.g., branch instructions).

[0036] In certain embodiments, for example, a branch operation (e.g., an instruction) is either unconditional (e.g., the branch is taken each time the instruction is executed) or conditional (e.g., the direction selected for the branch depends on a condition). The instructions executed following a conditional branch (e.g., a conditional jump) are not known with certainty until the condition on which the branch depends is resolved. Now, rather than waiting until the condition is resolved, a branch predictor (e.g., a branch predictor circuit) of the processor may perform (e.g., speculatively execute) a branch prediction to predict whether the branch will be taken or not taken and / or predict the target instruction (e.g., target address) for the branch (e.g., if predicted to be taken). In one embodiment, if the branch is predicted to be taken, the processor fetches and speculatively executes instructions for the selected direction (e.g., path) of the branch, e.g., instructions found at the predicted branch target address. The instructions executed following the branch prediction are speculative in certain embodiments where the processor has not yet determined whether the prediction is accurate. In particular embodiments, the processor resolves the branch instruction in the back end of the pipeline circuitry (e.g., in the execution, retirement and / or writeback units / circuitry). In one embodiment, if the processor (e.g., by the back end) determines that the branch instruction is not taken, all instructions (and, e.g., their data) currently residing in the pipeline circuitry after the taken branch instruction are flushed (e.g., discarded). For example, a particular branch instruction is referred to as an indirect branch instruction if the branch target (e.g., the branch target's instruction pointer) is stored in a (e.g., branch) register.

[0037] In certain (e.g., superscalar) processors (e.g., those with increased out-of-order (OoO) width and depth of the processor pipeline), branch prediction accuracy is important in minimizing work lost from branch mispredictions. In certain embodiments, a branch predictor (e.g., a branch predictor circuit) learns from the past behavior of branches to predict the next (e.g., upcoming) branch. However, for data-dependent branches, high entropy values ​​can result in poor prediction accuracy from a history-based branch predictor.

[0038] Embodiments herein utilize branch redirection to reduce the misprediction penalty for a branch when the outcome of the branch depends on the outcome of (e.g., only one) load instruction. In one embodiment, such load instructions are referred to as feeder load instructions. Certain embodiments herein track the progress of (e.g., feeder) load instructions relative to a branch instruction within a pipeline processor (e.g., core). Certain embodiments herein provide an extension to an instruction set architecture (ISA) to convey information of a dependent branch (e.g., upon receipt by the pipeline, e.g., upon decode). If the result (e.g., load value) of a load operation is available before the branch enters a particular stage of the pipeline (e.g., an out-of-order portion of the pipeline), the actual result is used to compute the branch prediction. In certain embodiments, if the original prediction (e.g., predicted path) provided by the branch predictor does not match this load value-based prediction (e.g., load value-based path), the pipeline (e.g., front end of the pipeline) is redirected to a (e.g., correct) path, resulting in either avoiding a misprediction or reducing the misprediction penalty by redirecting the pipeline earlier. Embodiments herein utilize ISA-based automatic load tracing for opportunistic redirection of data-dependent vulnerable branches.

[0039] Particular embodiments herein utilize one or more microarchitectural options that include (i) ISA extensions and compiler hints, or (ii) are made entirely within the microarchitecture. Particular embodiments herein relate to novel hardware for tracking loads in a processor's pipeline to override branch predictions based on actual (and unpredicted) load values. For example, this early override reduces the penalty of branch mispredictions (e.g., due to pipeline flushes) when a (e.g., baseline) branch predictor provides an incorrect prediction for such a (e.g., single) load data-dependent branch.

[0040] Certain embodiments detect data-dependent branches purely in hardware using instruction set (ISA) extensions and communicate program behavior to hardware, e.g., without using ISA extensions or tracking store instructions that generate load values ​​to obtain data-value-based predictions. Certain of these embodiments may work well when the store instruction pointer (IP) is strongly correlated with the load instruction pointer (IP). However, any misprediction of the store-load relationship may result in inaccurate branch predictions. Furthermore, determining the correct dynamic instance of the load IP to transfer the store value is also a challenge. To avoid these issues, certain embodiments herein use the actual load value to evaluate the branch direction (e.g., one path out of multiple paths) instead of the predicted value, e.g., without using compiler analysis of the program and / or without introducing delays in the execution of the load and branch instructions so that a prediction can be calculated. Certain embodiments herein are targeted to the case of programs that rely on a delay between the branch and load instructions already existing in the program code (e.g., not consecutive in the program code or otherwise far enough apart). In one embodiment, a compiler may encode this information as part of a load and / or branch instruction and then use the data when the load is ready. Opportunistically, certain embodiments herein may identify in the pipeline that a load has completed (e.g., data has been received in a load buffer) and provide the value to its dependent branches. In certain embodiments (e.g., where the compiler does not mark them as such), the processor hardware (e.g., branch redirection circuitry) identifies in the pipeline that a load has completed and opportunistically reduces the penalty of a pipeline flush. Certain embodiments herein do not require compiler support and / or ISA modifications (extensions) as a necessary part of the solution. Certain embodiments herein may utilize ISA modifications as described herein.

[0041] Returning now to the drawings, FIG. 1 illustrates a hardware processor 100 including at least one branch predictor circuit 104(1)-104(N) and at least one (e.g., data load dependent) branch redirection circuit 102, 102(1)-102(N) in accordance with an embodiment of the present disclosure. Although multiple branch predictor circuits are shown, a single branch predictor circuit may be utilized for branch prediction for the cores 106(1)-106(N). In one embodiment, branch prediction is distributed with each core including its own local branch predictor 104(1)-104(N). Each local branch predictor 104(1)-104(N) may share data, e.g., a history of branch instructions executed by the processor 100.

[0042] In one embodiment, N is any integer number equal to or greater than 2. Hardware processor 100 is shown coupled to system memory 114 to form, for example, computing system 101. A core of hardware processor 100 (e.g., each core 106(1)-106(N)) may include any of instruction fetch circuitry, decoder execution circuitry, or retirement circuitry (or other units or circuits described herein), for example as the core's pipeline circuitry.

[0043] The illustrated hardware processor 100 includes registers 108. The registers 108 may include one or more general-purpose (e.g., data) registers 110 for performing (e.g., logic or arithmetic) operations, such as accessing (e.g., loading or storing) data in memory 114, or alternatively. The registers 108 may include one or more architectural register files 112. In one embodiment, the processor 100 (e.g., its branch predictor) populates branch history data (e.g., context data) into one or more registers 108 based on previous execution of instructions, such as branch instructions. In another embodiment, the branch history may be stored in system memory 114. The branch history may include a global history of the branch instruction (e.g., including a history of paths taken by a series of branches through the currently executing program code to reach the branch instruction) along with an address identifier of the branch instruction (e.g., an instruction pointer value or a program counter value associated with the branch instruction). In a particular embodiment, the global branch (e.g., path and / or direction) history includes direction information. The direction information indicates how frequently a resolved direction of a branch instruction is taken or not taken, e.g., to provide a prediction for future instances of the branch instruction. In a particular embodiment, the global branch (e.g., path and / or direction) history includes path information. The path information indicates the paths (e.g., executed instructions) to reach the branch instruction for a particular prediction, e.g., a proper subset of executed instructions to reach the branch instruction for a particular prediction.

[0044] The system memory 114 may include (eg, store) one or more (eg, any combination thereof) of the following software: operating system (OS) code 116 or application code 118 .

[0045] It should be noted that the figures herein may not show all data communication connections. Those skilled in the art will appreciate that this is not to obscure certain details in the figures. It should be noted that a double-headed arrow in a figure may not require two-way communication, e.g., may indicate one-way communication (e.g., between the component or device). Any or all combinations of communication paths may be utilized in certain embodiments herein. In one embodiment, the processor 100 has a single core. In certain embodiments, the computing system 101 and / or the processor 100 include one or more of the features and / or components described below, e.g., with reference to any figure herein.

[0046] As an example, a branch predictor enhances the functionality of a pipeline processor by generating a prediction as to which of multiple paths will be taken, e.g., a planned instance of a (e.g., conditional) branch instruction (e.g., an “IF” operation in code).

[0047] Processors (e.g., microprocessors) may employ the use of pipelines to enhance performance. Within certain embodiments of a pipelined processor, functional circuits (e.g., fetch circuits, decode circuits, execute circuits, retirement circuits, etc.) for executing different stages of an instruction operate simultaneously on multiple instructions to achieve a degree of parallelism, thereby providing improved performance over a non-pipelined processor. In one embodiment, an instruction fetch unit (e.g., circuitry), an instruction decoder (e.g., decode unit or decode circuitry), and an instruction execution unit (e.g., circuitry) operate simultaneously. In a particular embodiment, during one clock cycle, the instruction execution unit executes a first instruction, while the instruction decoder decodes a second instruction, and the fetch unit fetches a third instruction. In a particular embodiment, during the next clock cycle, the execution unit executes the newly decoded instruction, while the instruction decoder decodes the newly fetched instruction, and the fetch unit fetches yet another instruction. In this manner, neither the fetch unit nor the decoder need wait for the instruction execution unit to execute the last instruction before processing a new instruction. In certain embodiments (e.g., during the writeback stage), the results of an executed instruction (e.g., an instruction taken one path after a branch instruction) are preserved (e.g., made visible) if the prediction was correct, or discarded (e.g., the effect is rolled back) if the prediction was incorrect.

[0048] Embodiments herein utilize branch redirection circuitry (e.g., branch redirection circuitry 102(1) for core 106(1) and branch redirection circuitry 102(N) for core 106(N)) to redirect incorrect predictions, for example, possibly after a branch instruction has entered the core's pipeline but before it is sent to a (e.g., out-of-order) stage.

[0049] 2 illustrates a computer system 200 including a branch predictor circuit 220 and a branch redirection circuit 222 within a pipeline processor 210 (e.g., a pipeline core) in accordance with an embodiment of the present disclosure. The illustrated computer system 200 further includes a network device 201, input / output (I / O) circuitry 203 (e.g., a keyboard), a display 205, and a system bus (e.g., an interconnect) 207.

[0050] In one embodiment, each core of processor 100 in FIG. 1 is an instance of processor core 210, where N is any positive integer. In the embodiment shown, each of the single processors (e.g., each core 210) includes an instance of branch predictor circuit 220 and / or branch redirection circuit 222. Branch predictor circuit 220 may include branch redirection circuit 222 therein. Branch predictor circuit 220 may include a branch target buffer (BTB), a return stack buffer (RSB), a history table, registers, and / or other data storage structures. One or more of these may be used only by a single branch predictor, or they may be maintained and / or used by any of the multiple branch predictors.

[0051] In particular embodiments, the branch target buffer stores (e.g., in a branch predictor array) predicted target instructions corresponding to each of a plurality of branch instructions (e.g., branch instructions of a section of code) that have been executed a plurality of times. In particular embodiments, the return stack buffer stores (e.g., in a last-in-first-out (LIFO) stack data structure) return addresses of any CALL instructions (e.g., that push their return addresses onto the stack). In particular embodiments, the history table stores a history of each of a plurality of code branches that have been executed by the processor 210. In particular embodiments, the registers include a register for storing a branch global path history and / or a register for storing a branch global direction history.

[0052] In one embodiment, processor 210 is a pipeline processor core that includes a branch prediction stage 220, a fetch stage 230, a decode stage 240, an allocation stage 250, an execution stage 260, and a writeback (e.g., retirement) stage 270. Each of the pipeline stages shown in processor core 210 may include different levels of circuitry. Alternatively, the pipeline stages may be sub-divided into more stages. Additionally, additional pipeline stages may also be included, such as a pre-fetch stage, an instruction pointer generation (IP generation) stage, etc.

[0053] In one embodiment, pipeline processor 210 receives (e.g., via connection (e.g., wire) 221) an instruction pointer (IP) that identifies the next instruction to be input to the processor. For example, an IP generation stage may select an instruction pointer (e.g., a memory address) that identifies the next instruction in a program sequence to be fetched and executed by a core (e.g., a logical core). In one embodiment, pipeline processor 210 (e.g., IP generation stage) increments the memory address of the most recently fetched instruction by a predetermined amount X (e.g., 1) on each clock cycle.

[0054] However, in the case of an exception or if a branch instruction is taken, the pipeline processor 210 (e.g., IP generation stage) may select an instruction pointer that identifies an instruction that is not the next consecutive instruction in program order. In particular embodiments, the pipeline processor 210 (e.g., branch prediction stage 220) predicts whether a conditional branch instruction will be taken, e.g., to reduce branch penalties.

[0055] The fetch stage 230 shown in FIG. 2 includes an instruction fetch circuit 234. The instruction fetch circuit 234 accepts an instruction pointer from upstream in the pipeline processor (e.g., from the branch prediction stage 220) and fetches the respective instruction from the memory 202 or the instruction cache 232. The decode stage 240 performs a decode operation with the decoder 242 to decode the instruction into a decoded instruction (e.g., into a micro-operation). The allocation stage 250 shown in FIG. 2 performs an allocation operation with the allocation circuit 252, such as renaming and dispatching (e.g., scheduling) of registers. In one embodiment, the ISA supports a certain number of logical registers (e.g., the ARF of registers 208 in FIG. 2 or the ARF 112 in FIG. 1) that are mapped to a certain (e.g., a larger) number of physical registers. For example, each register of the ARF points to a particular physical register file (PRF) in the registers 208. In one embodiment, the logical identifiers (e.g., “names”) of registers are mapped to physical identifiers (e.g., “names”) of registers, for example, and these mappings can be updated. In one embodiment, instruction dispatching includes reserving different resources used by the instruction, including execution resources, entries in a reorder buffer (ROB), issue queues, store buffer 274, load buffer 276, etc. In a particular embodiment, if a resource is not available, the corresponding instruction is stalled until some other instruction releases the required resource. The execution stage 260 shown in FIG. 2 performs operations with the execution circuitry 262 (e.g., access registers 208, memory 202, store buffer 274, and / or load buffer) as specified by the decoded instruction. The writeback stage shown in FIG. 2 retires the executed instruction with the writeback circuitry 272. For example, the results of executed instructions (e.g., instructions for one direction taken after a conditional branch) may be preserved (e.g., made visible) if the branch prediction was correct, or discarded (e.g., the effect is rolled back) if the branch prediction was incorrect.A store request by execution circuitry 262 may cause data to be stored in store buffer 274, e.g., which then stores the data to a final storage destination, e.g., a destination in register 208, memory 202, and / or data cache 264. A load request by execution circuitry 262 may cause data to be loaded into load buffer 276, e.g., which then loads the data to a destination in register 208, memory 202, and / or data cache 264. In alternative embodiments, the above-described pipeline stages may also include additional operations.

[0056] The branch predictor circuit 220 (e.g., a branch predictor unit (BPU)) may provide a pipeline (e.g., a fetch stage 230). The instructions correspond to a predicted taken direction for a branch instruction. In a particular embodiment, the branch predictor circuit 220 includes or has access to storage having one or more entries. Each entry may store data identifying a branch instruction, with the corresponding data identifying the predicted direction (e.g., the taken path and / or the not taken path). In a particular embodiment, the branch predictor circuit 220 predicts a branch target for a branch instruction.

[0057] In one embodiment, the branch instructions stored in the branch predictor circuit 220 are preselected by a compiler from the code to be executed. In a particular embodiment, the compiler code 204, shown as stored in memory 202 of FIG. 2, includes code sequences that, when executed, convert source code of a program written in a high-level language into executable machine code. In one embodiment, the compiler code 204 further includes additional branch predictor code 206 that predicts the direction (e.g., taken or not taken) and / or target instruction for a branch instruction (e.g., the path of a branch instruction that may be taken (e.g., a preselected branch instruction)). The branch predictor circuit 220 (e.g., its BTB) is then updated with the direction prediction and / or with the predicted target instruction for the branch instruction.

[0058] The illustrated core (e.g., its branch predictor 220) includes access to one or more registers (e.g., registers 208). In a particular embodiment, registers 208 include one or more of general purpose registers and / or branch prediction history registers.

[0059] In particular embodiments, the branch redirection circuit 222 is included to reduce misprediction penalties for branches where the outcome of the branch depends on the outcome of one or more monitored load instructions. In one embodiment, such load instructions are referred to as feeder load instructions. Certain embodiments herein track the progress of (e.g., feeder) load instructions relative to branch instructions within a pipeline processor (e.g., core), e.g., as described herein. In particular embodiments, the branch redirection circuit populates and / or updates the load dependent branch table 224, e.g., to indicate branch instructions and / or load instructions whose outcome depends on the branch instruction. Examples of identifying (e.g., detecting) and / or marking such instructions are described below.

[0060] In a particular embodiment, branch redirection involves the use of one or more of the following components: (1) a mechanism for detecting load (e.g., instruction) data-dependent (e.g., instruction) branches; (2) a load-dependent branch table 224 for storing learned load instructions (e.g., their IPs) that supply values ​​that control the outcome of data-dependent branches; and (3) a load value table (LVT) 226A (which may include a copy of all or a subset of the load value table (LVT) in load value table 226B). In one embodiment, the load value table 226B is located between the decoder 242 and the allocation circuit 252. In another embodiment, the load value table 226B is located in a stage where a check for redirection is performed on the writeback of the monitored load. In a particular embodiment, a load instruction (e.g., as indicated by a field or other indication for the load instruction) provides a load value to the load value table (LVT) (e.g., 226A and / or 226B) when it is ready for writeback (e.g., when the load value is received in the load buffer 276). In particular embodiments, if the load value is available before the branch enters a particular stage (e.g., before the OoO portion of the pipeline, such as, but not limited to, the reservation station, reorder buffer, etc.), redirection is performed based on the load value. In particular embodiments, the result from the load instruction (e.g., the load value) is read from a load value table that is separate from the final store destination (e.g., and separate from the load buffer in the writeback stage).

[0061] In a particular embodiment, the branch redirection circuit 222 populates respective entries in the load dependency branch table 224 with branch instructions that are to be monitored for possible redirection as disclosed herein. In one embodiment, the branch redirection circuit 222 adds entries to the load dependency branch table 224 that identify the branch instructions to be monitored, for example, by including an instruction pointer (IP) for the branch instruction in the entry and / or by including an instruction pointer (IP) for its feeder load instruction in the entry. In one embodiment, the format of the load dependency branch table entry is format 300 in FIG. 3.

[0062] In a particular embodiment, branch instructions that have feeder load instruction dependencies are identified by a compiler. In a particular embodiment, branch instructions that have feeder load instruction dependencies are identified by analyzing registers (e.g., ARFs).

[0063] As an example, a load instruction is input (e.g., into a pipeline) of the processor 210 (e.g., into the branch predictor circuitry and / or instruction fetch stage 230) and is checked (e.g., the IP of the load instruction) in the load dependent branch table 224 to determine if it corresponds to a monitored branch instruction. If not, in particular embodiments, the flow of the processor 210 continues through these stages. If yes, in particular embodiments, the branch redirection circuit 222 marks the load instruction for monitoring its results (e.g., outcome). In one embodiment, the branch redirection circuit 222 assigns an entry in a load value table (e.g., 226A and / or 226B) such that upon receipt (e.g., upon receipt into the load buffer 276), the result of the load instruction is stored in the entry in the load value table. In this example, a branch instruction is input (e.g., speculatively) into (e.g., pipeline) of processor 210 (e.g., input to branch predictor circuitry) and (e.g., the IP of the branch instruction) is checked in load dependency branch table 224 to determine if it has a corresponding monitored load instruction. If not, in certain embodiments, flow of processor 210 continues through these stages (e.g., according to speculative execution). If yes, in certain embodiments, branch redirection circuitry 222 causes one or more checks (e.g., via connections (e.g., wires) 223) to see if the result (e.g., result) of the load instruction is currently ready (e.g., if not ready during the first stage of pipeline processing for the branch instruction). In one embodiment, load data is received into load buffer 276 such that the load data is sent to a corresponding entry in the load value table (e.g., from writeback stage 270 of the load instruction) (e.g., based on a mapping of the load IP to a particular load value table (LVT) index).For example, the load value is transmitted from the load buffer 276 to the LVT 226A via a connection (e.g., wire 225) and / or from the load buffer 276 to the LVT 226B via a connection (e.g., wire 227). In one embodiment, the branch redirection circuit 222 causes a comparison (e.g., between the decoding of the branch instruction in the decoder 242 and the execution of the branch instruction in the execution circuit 262) of the result from the load instruction (e.g., when the monitored feeder load result is received in the load value table) and redirects the execution of the branch instruction to a path that is different from the (e.g., actual) path based on the result from the load instruction and / or causes the branch instruction to be executed (e.g., without overriding the execution of that instance of the branch instruction) for the path based on the result from the load instruction. In a particular embodiment, the load instruction includes an identifier (e.g., an index value) of the load value table (LVT) entry to be used for its result. For example, the identifier is stored in an entry in the load dependency branch table 224. In certain embodiments, a branch instruction includes an identifier (e.g., an index value) in the load value table (LVT) entry that is used for the result of that feeder load. For example, the identifier is carried with the branch instruction through the pipeline (e.g., until the last point (e.g., stage) where possible redirection is checked). In certain embodiments, possible redirection is checked (e.g., once or multiple times) before scheduling for execution, e.g., before the execution stage 260, before the allocation stage 250 allocates execution resources. In certain embodiments, the final (e.g., only) check for redirection is performed after the fetch stage 230 or the decode stage 240 (e.g., before the allocation or execution scheduling of the branch instruction). It should be understood that the above are merely examples and other points in the pipeline may be selected, e.g., points before the execution stage 260 or the writeback stage 270.In particular embodiments, circuitry (e.g., arithmetic logic unit (ALU) 228) performs operations (e.g., a greater than, less than, equal to, etc.) to determine when the predicted path differs from the path based on the result from the load instruction, e.g., to avoid using resources of the execution stage 260. The branch redirection circuitry 222 may, for example, cause flushing of any (e.g., speculative) data for the incorrectly predicted path when the predicted path differs from the path based on the result from the load instruction. The branch redirection circuitry 222 may cause execution of the branch instruction (e.g., via redirecting the branch instruction and returning the result to a beginning stage (e.g., front end) of the pipeline) for the actual path based on the result from the load instruction. FIG. 3 illustrates an example format 300 of a load-dependent branch table entry in accordance with an embodiment of the present disclosure. The illustrated format 300 includes one or more fields for storing (e.g., by a branch redirection circuit) the IP 302 of a branch instruction being monitored (e.g., to redirect an incorrectly predicted path caused by a feeder load instruction), an (optional) number of mispredictions for this branch instruction 304, an (optional) confidence score 306 (e.g., 304 and 306 are used in a substitution scheme for the prediction), a feeder load IP 308 (and comparison information, e.g., an identification of an operation and value for comparing the load value to a (e.g., constant) value), and a load value table (LVT) index 310 for identifying an element of a corresponding load value table (LVT) where the result of the load instruction is stored (e.g., temporarily). For example, if a branch instruction corresponds to the pseudocode of “IF” (a>100), the feeder load instruction may load a value of “a” (e.g., from memory) and the compare field may store an indication of a “greater than” comparison and a value of “100” to cause (e.g., ALU 228) to compare the value of “a” (e.g., provided from load value table (LVT) 226A or 226B) with “100” to determine the actual path for the branch instruction based on the result “a” from the load instruction.

[0064] An exemplary scheme for detecting load data dependency branches is now described. The following pseudo-code example is referred to below (do_work can be any operation):

number

[0065] This example includes load data dependent branches B1 and B2, both of which use a single load value in L1 ("a") to calculate a result, and load data dependent branch B3, which uses data from two loads to calculate a result. Branch B3 uses two load values ​​to calculate a branch result and is not supported by certain embodiments herein to avoid the complexity of tracking multiple loads for a single branch instruction, although it should be understood that other embodiments track multiple loads for a single branch instruction in accordance with the present disclosure herein.

[0066] As mentioned above, the identification of load-data dependent branches (e.g., and therefore the population of the load dependent branch table 224) may be via (i) a compiler and instruction set architecture (ISA) extension or (ii) a hardware-based implementation. [An example implementation via compiler / ISA extension]

[0067] In particular embodiments, load dependency branch detection is performed by a compiler (e.g., using a dataflow graph) and ISA extensions described herein to enable special handling of load data dependency branches in hardware. In one embodiment, the load instruction is marked and an offset to the branch IP (e.g., program counter (PC)) (or the branch IP itself) is added to the load instruction as an extension bit (e.g., including one or more other fields, including but not limited to those described below in Figures 12A-13D).

[0068] Certain embodiments herein use (e.g., and provide) ISA extensions to indicate (e.g., store) the L1->B1 and L1->B2 dependencies discussed above. In the pseudocode example discussed above, certain embodiments herein use a compiler (e.g., a dataflow graph) to detect (e.g., determine) that branches B1 and B2 are directly dependent on the value of load L1 (e.g., the other operand is an immediate value). FIG. 4 illustrates an example format 400 of an instruction set architecture (ISA) extension for one dependent branch instruction, according to an embodiment of the present disclosure. The illustrated format 400 includes one or more fields for storing (e.g., by a compiler) an (optional) load operation extension 402 (e.g., indicating that the branch instruction depends on only one load), a branch IP 404 to identify the branch instruction provided by the load instruction, and one or more operations 406, 408 to indicate, for example, an operation to be performed on the result of the load data (e.g., “greater than” in the [B1]if(a>100) example discussed above). The first operation indication 406 may be "greater than" or "less than". The second operation indication 408 may be "equal to". In the above example, B1 uses a direct comparison of the load value to "100" (e.g., to find the remainder when divided by "2") and B2 uses a modulo operation (%). In a particular embodiment, this information is added to the ISA load instruction extension as fields 406 (e.g., and 408), allowing a simple calculation (e.g., in the front end) to obtain the branch result from the load value (e.g., via ALU 228 in FIG. 2).

[0069] Data from the ISA extension of format 400 may be used to populate load-dependent branch table (LDBT) entries when reading such instructions from output (eg, machine code) generated by a compiler, for example.

[0070] In the pseudocode example above, certain embodiments herein use a compiler (e.g., a dataflow graph) to detect (e.g., determine) that branch B3 uses two load values ​​to calculate the branch outcome. Figure 5 illustrates an example format 500 of an instruction set architecture (ISA) extension of two dependent branch instructions in accordance with an embodiment of the present disclosure. The illustrated format 500 includes one or more fields for storing (e.g., by a compiler) an (optional) load operation extension 502 (e.g., to indicate that two branch instructions are dependent on only one load), a first branch IP 504 for identifying the first branch instruction provided by the load instruction, one or more operations 506, 508 (e.g., to indicate an operation to be performed on the result of the load data for the first branch instruction (e.g., “greater than” in the [B1] if(a>100) example above), a second branch IP 510 for identifying a second branch instruction provided by the load instruction, and one or more operations 512, 514 (e.g., to indicate an operation to be performed on the result of the load data for the second branch instruction (e.g., “modulo” and “equal to” in the [B2] if(a%2==0) example above). In particular embodiments, this operation information is added to the ISA load instruction extension as fields 506 and 512 (e.g., and 508 and / or 514), allowing a simple calculation (e.g., in the front end) to obtain the branch result from the load value (e.g., via ALU 228 in FIG. 2 ).

[0071] Data from the ISA extension of format 500 may be used to populate a load dependency branch table (LDBT) entry (or multiple entries) upon reading the instruction in question from output (e.g., machine code) generated by, for example, a compiler.

[0072] 6 illustrates a flow diagram 600 for populating a load dependency branch table (LDBT) for branch redirection (e.g., upon detection (e.g., during decoding) of a feeder load instruction) according to an embodiment of the present disclosure. Flow 600 includes detecting the load type of an instruction (e.g., decoding a load instruction and / or its IP) (602), checking whether the load instruction includes an ISA extension for branch redirection (e.g., an ISA extension used to populate a load dependency branch table (LDBT) entry) (604), if no, terminating any further branch redirection operations of this particular flow (608), and if yes, causing population of an entry of the load dependency branch table with data from the ISA extension, e.g., load IP (e.g., in field 308 in FIG. 3), branch IP (e.g., in field 302 in FIG. 3), comparison (e.g., operation) information (e.g., in field 308 in FIG. 3), etc. (606), and then terminating any further branch redirection operations of this particular flow (608). This may also cause the allocation of load value table (LVT) entries and their respective indices to be inserted into load dependency branch table (LDBT) entries (eg, in field 310 in FIG. 3).

[0073] The above example illustrates an exemplary design of an ISA extension and a flow diagram for actions taken upon detection (e.g., decoding) of a feeder load instruction in Figure 2. In a particular embodiment, the ISA extension (i) encodes the operation performed on the load value to calculate the branch result, and (ii) captures multiple branch offsets if the load instruction supplies multiple branches. Enabling such different load opcode extensions (LD OP EXT1 402 and LD OP EXT2 502) may be used.

[0074] In particular embodiments, one or more fields of this information are added to the load instruction as extensions, so that when the load instruction is received (e.g., decoded) by the pipeline, the processor (e.g., branch redirection circuitry) adds the load IP and its dependent branches to the LBT, along with operation information, e.g., from the extension bits (e.g., referred to as CMP information in LBT entry 308 in FIG. 3 ). [Example implementation via hardware-based implementation]

[0075] In certain embodiments, load dependency branch detection is performed in hardware (e.g., without relying on a compiler or added ISA extensions), allowing special handling of load data dependency branches in hardware. In certain embodiments, a purely hardware-based mechanism is used to detect load dependency branches (e.g., L1->B1 and L1->B2 load data dependencies in the pseudocode example above). One embodiment for detecting load data dependency branches in hardware involves tracking data flow through a shadow architecture register file (ARF) or an extension of an ARF entry. In one embodiment, the hardware (e.g., branch redirection circuitry) detects branches that are controlled by only one load value. For example, if multiple loads are found to be supplying a (e.g., register) value during tracking, the hardware stops tracking that dependency chain (e.g., by invalidating an entry). Similarly, multiple register operations may also be excluded from the dependency chain (e.g., and only operations performed with immediate operands are allowed).

[0076] In one embodiment, hardware (e.g., branch redirection circuitry) calculates the branch outcome from the load value, e.g., as operations are performed on data values ​​between the tracked load and the branch instruction. In a particular embodiment, once a load-dependent branch is detected, its feeder load IP and operation sequence are recorded in a load-dependent branch table (LDBT) table. FIG. 7 illustrates an example format 700 of an architectural register file (ARF) extension, according to an embodiment of the present disclosure. The illustrated format 700 includes one or more fields for storing (e.g., by a branch redirection circuitry) an identifier of a register 702, a load 704 (e.g., the IP of the load instruction) that is accessing the register, and one or more operations 706(0), 706(1), ..., 706(N) (e.g., to indicate the operation). In one embodiment, the one or more operations 706(0)-706(N) indicate when the load value is available, e.g., which operation the ALU (228) should perform to calculate the branch direction to override the (e.g., default) branch prediction. For example, one or more operations 706(0)-706(N) are a chain of dependent instructions between a load and a branch. For example, if a load generates R1 through operations OP0(R1+5->R2) and OP1(R2×7->R3), and R3>20, then a jump is performed.

[0077] The tracking of loads (e.g., and their load value table (LVT) indexes) through the pipeline (e.g., via the LDBT and LVT) disclosed herein is applicable to both categories of methods for detecting load-dependent branches described above. Figures 8 through 11 illustrate various flow diagrams that may be used for branch redirection. Some or all of the operations for the flows (or other processes described herein or variations and / or combinations thereof) may be performed under the control of one or more computer systems comprised of executable instructions and implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that collectively execute on one or more processors by hardware or a combination thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of these operations are performed by the branch redirection circuitry of the other figures.

[0078] 8 illustrates a flow diagram 800 triggered by receiving (e.g., fetching) a load instruction when branch redirection is enabled, according to an embodiment of the present disclosure. The illustrated flow 800 includes detecting the load type of the instruction (e.g., decoding the load instruction and / or its IP) (802), checking whether the load instruction (e.g., IP) is present in an entry in a load-dependent branch table (LDBT) (804), and if "no", terminating any further branch redirection operations of this particular flow (808), and if "yes", allocating a new load value table (LVT) entry such that an identifier (e.g., index) of the load value table (LVT) entry is stored in a corresponding entry in the LDBT table (e.g., in field 310 in FIG. 3 ) (e.g., such that each load iteration uses a new LVT index in the corresponding LDBT entry) (806), and then terminating any further branch redirection operations of this particular flow (808).

[0079] 9 illustrates a flow diagram 900 triggered by receiving (e.g., fetching) a branch instruction when branch redirection is enabled, according to an embodiment of the present disclosure. The illustrated flow 900 includes detecting the branch type of an instruction (e.g., decoding the branch instruction and / or its IP or detecting the branch instruction that took the predicted path in the processor's pipeline) (902), checking whether the branch instruction (e.g., IP) is present in an entry in a load dependent branch table (LDBT) (e.g., in field 302 in FIG. 3 ) (904), and if no, terminating any further branch redirection operations for this particular flow (916), and if yes, performing a lookup in a load value table (LVT) for feeder data identified by the load value table (LVT) index in the entry in the load dependent branch table (LDBT) (906), and then checking whether the LVT entry has been updated (e.g., has current load data) (908), and if no, terminating any further branch redirection operations for this particular flow. terminating the redirection operation (916); if yes, executing a branch path based on data from the load instruction (e.g., current load data) (910); then checking whether the branch path based on the data matches the predicted branch path (912); if not, terminating any further branch redirection operations for this particular flow (916); if yes, causing the (e.g., correct) branch instruction for the path based on the data (e.g., current load data) to be executed (e.g., and canceling execution of the branch instruction for the prediction-based (e.g., incorrect) path) by sending a redirect indication and / or a flush indication (e.g., to a fetch stage of the pipeline) (914); and then terminating any further branch redirection operations for this particular flow (e.g., by marking the load data as now stale) (916).

[0080] 10 illustrates a flow diagram 1000 triggered by a writeback of a load instruction when branch redirection is enabled, according to an embodiment of the present disclosure. The illustrated flow 1000 includes detecting a writeback of a load type of instruction (1002), checking whether the load instruction (e.g., IP) is present in an entry in a load-dependent branch table (LDBT) (e.g., the LDBT entry for the load IP contains a valid LVT index) (1004), and if no, terminating any further branch redirection operations for this particular flow (1010), and if yes, sending result data from the writeback of the load instruction (e.g., along with the LVT index) to the LVT (or LVTs) (1006), updating the LVT entry with the result data (1008), and then terminating any further branch redirection operations for this particular flow (1010). In one embodiment, if an LVT index is assigned to a load instruction (e.g., at 806 in FIG. 8 ) and the load is performing a writeback, only the load instruction with the (e.g., valid) LVT index will send the data value to the LVT (e.g., at 1006 in FIG. 10 ).

[0081] 11 illustrates a flow diagram 1100 for branch redirection according to an embodiment of the present disclosure. The illustrated flow 1100 includes generating a predicted path for a branch instruction in a branch predictor circuit of the processor (1102), the branch redirection circuit of the processor checking, for a branch instruction that depends on a result from a load instruction, whether an instruction received by a pipeline circuit of the processor, the pipeline circuit comprising a decoder for decoding the instruction into a decoded instruction and an execution circuit for executing the decoded instruction (1104), and if the instruction received by the pipeline circuit is a load instruction, the branch redirection circuit performing a loop between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuit (1105). This includes checking a writeback of the result from the load instruction (1106), and if the predicted path differs from the path based on the result from the load instruction, a branch redirection circuit redirects the branch instruction in the pipeline circuit (e.g., a front end of the pipeline circuit) to a path (1108), and if the predicted path differs from the actual path based on the result from the load instruction, (optionally) an execution circuit executes the branch instruction for the actual path based on the result from the load instruction (1110) (e.g., the branch instruction continues down the pipeline circuit and is executed in an execution circuit in a back end of the pipeline circuit).

[0082] In particular embodiments, when an instruction enters the pipeline (e.g., the front end of the pipeline), its IP is checked for a match against the load IP in the LDBT, and if there is a match, the load instruction is marked with an LVT index. The LVT index may be selected in a round-robin fashion or based on availability. In particular embodiments, the assigned LVT index is also stored in the LDBT in the corresponding entry. In particular embodiments, when a load instruction gets a load value from the memory pipeline (e.g., and into a load buffer), the value is updated in the LVT index slot of the LVT table (e.g., in the front end).

[0083] In a particular embodiment, at branch instruction fetch, the branch IP is searched in the LBT, and if there is a hit, the LVT index is read, for example, from the table, and then the LVT is looked up at the LVT index for the load value. In a particular embodiment, if the load instruction writes back a value to the LVT, a calculation based on the load value and the branch comparison condition, for example, produces a predicted branch result, and if this result differs from what the branch predictor predicted, redirection occurs and the front end (e.g., front end unit 1530 in FIG. 15B) is redirected. Thus, in a particular embodiment, redirection resolves the branch with the actual load data value. Although particular embodiments herein do not preclude execution of the branch in the pipeline (e.g., the OoO section of the pipeline), this high accuracy allows redirection in the later part of the front end. This increases coverage because redirection is possible even if the load and branch are (e.g., slightly) close to the program flow, or the writeback of the load is delayed (e.g., a little) due to, for example, out-of-order effects or cache misses. For example, if the penalty of a branch misprediction (e.g., length of time) (e.g., BP points in time redirection and / or allocation points in time redirection) versus the penalty of redirection at the front end is significantly lower than the former, this latter redirection reduces the misprediction penalty by performing redirection at the front end prior to execution of the branch. Certain embodiments herein focus on overriding (e.g., default) branch prediction with load value based prediction (e.g., known to be more accurate since it is based on load value). Certain embodiments herein do not preclude execution of the branch, for example, in the pipeline (e.g., back end of the pipeline), because this is required for accuracy. For example, a smaller number of tag bits may be used in the LDBT to match branch IP or load IP to save to storage, which may result in aliasing hits and false bits.Certain of these embodiments still perform an override of the prediction since there is a hit, for example, the override may not be accurate in some implementations where aliasing is allowed within the LDBT.

[0084] In particular embodiments, before a branch enters a particular stage of the pipeline (e.g., the OoO section of the pipeline), the LVT may be looked up (e.g., again) to see if the load value is available and if the branch outcome can be calculated for redirection. To allow for faster lookups, multiple LVTs may be maintained (e.g., one at the front end and another just before the allocation stage). In particular embodiments, the LVT index is transmitted (e.g., carried) with the branch instruction through the pipeline, for example, until the final checkpoint (e.g., the allocation stage in the example above). In particular embodiments, the LVT maintained in the allocation stage (e.g., LVT 226B in FIG. 2) is minimal in that it only maintains the override result. In particular embodiments, the override result may be calculated and transmitted to this LVT if the corresponding LVT entry has been updated at the time of the writeback of the load. As a design choice, the calculation (e.g., by ALU 228 in FIG. 2) may be done just in time, at the time of the branch prediction, or as soon as the load value is available. In certain embodiments, the result is calculated using the LVT and sent from the LDBT to the LVT, for example, to avoid duplication overhead of the calculation circuitry (eg, ALU 228 in FIG. 2).

[0085] Exemplary architectures, systems, etc. that may be used above are detailed below.

[0086] At least some embodiments of the disclosed technology can be illustrated in light of the following examples. [Example 1] a pipeline circuit having a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions; a branch predictor circuit for generating a predicted path for a branch instruction; a branch redirection circuit for, for the branch instruction dependent on a result from a load instruction, checking whether an instruction received by the pipeline circuit is the load instruction, and if the instruction received by the pipeline circuit is the load instruction, checking a write-back of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuit, and redirecting the branch instruction in the pipeline circuit to the path if the predicted path differs from a path based on the result from the load instruction, and causing execution of the branch instruction for the path based on the result from the load instruction; A processor comprising: [Example 2] 2. The processor of claim 1, wherein the branch redirection circuitry checks the writeback of the result in a load value table that is separate from a final storage destination of the result. [Example 3] 3. The processor of claim 2, wherein the branch redirection circuitry assigns an index value of an entry in the load value table to the result of the load instruction if the instruction received by the pipeline circuitry is the load instruction, and causes the index value to be transmitted to the pipeline circuitry as a field of the branch instruction. [Example 4] 4. The processor of example 3, wherein the branch redirection circuitry updates an entry for the branch instruction in a load dependency branch table with the index value if the instruction received by the pipeline circuitry is the load instruction. [Example 5] 4. The processor of example 3, wherein the branch redirection circuitry assigns an index value for a second branch instruction that also depends on the outcome from the load instruction. [Example 6] 2. The processor of example 1, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuit that allocates execution of the branch instruction to the execution circuit. [Example 7] 7. The processor of example 6, wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the allocation stage. [Example 8] 2. The processor of claim 1, further comprising circuitry separate from an execution stage including the execution circuitry of the pipeline circuitry for performing one or more operations to determine whether the predicted path differs from the path based on the result from the load instruction. [Example 9] generating a predicted path for the branch instruction in a branch predictor circuit of the processor; a branch redirection circuit of the processor checking, for the branch instruction that depends on a result from a load instruction, whether an instruction received by a pipeline circuit of the processor, the pipeline circuit including a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions, is the load instruction; if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry checks for a writeback of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuitry; if the predicted path differs from a path based on the result from the load instruction, the branch redirection circuitry redirects the branch instruction in the pipeline circuitry to the path; if the predicted path differs from the path based on the result from the load instruction, the execution circuitry executes the branch instruction for the path based on the result from the load instruction; A method for providing the above. [Example 10] 10. The method of example 9, wherein checking the writeback comprises checking the writeback of the result in a load value table that is separate from a final storage destination of the result. [Example 11] if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry assigns an index value of an entry in the load value table to the result of the load instruction; causing said index value to be transmitted to said pipeline circuitry as a field of said branch instruction; The method of Example 10, further comprising: [Example 12] 12. The method of claim 11, further comprising: if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry updates an entry for the branch instruction in a load dependency branch table with the index value. [Example 13] 12. The method of example 11, further comprising the branch redirection circuitry assigning an index value of a second branch instruction that also depends on the outcome from the load instruction. [Example 14] 10. The method of example 9, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuit that allocates execution of the branch instruction to the execution circuit. [Example 15] 15. The method of example 14, wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the allocation stage. [Example 16] 10. The method of example 9, further comprising: performing, in a circuit separate from an execution stage including the execution circuit of the pipeline circuit, one or more operations to determine whether the predicted path differs from the path based on the result from the load instruction. [Example 17] When performed by a machine, generating a predicted path for the branch instruction in a branch predictor circuit of the processor; a branch redirection circuit of the processor checking, for the branch instruction that depends on a result from a load instruction, whether an instruction received by a pipeline circuit of the processor, the pipeline circuit including a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions, is the load instruction; if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry checks for a writeback of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuitry; if the predicted path differs from a path based on the result from the load instruction, the branch redirection circuitry redirects the branch instruction in the pipeline circuitry to the path; if the predicted path differs from the path based on the result from the load instruction, the execution circuitry executes the branch instruction for the path based on the result from the load instruction; How to prepare A non-transitory machine-readable medium storing code for causing the machine to execute the above. [Example 18] 20. The non-transitory machine-readable medium of example 17, wherein checking the writeback comprises checking the writeback of the result in a load value table that is separate from a final storage destination of the result. [Example 19] The above method is if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry assigns an index value of an entry in the load value table to the result of the load instruction; causing said index value to be transmitted to said pipeline circuitry as a field of said branch instruction; Further comprising: The non-transitory machine-readable medium of Example 18. [Example 20] 20. The non-transitory machine-readable medium of Example 19, wherein the method further comprises, if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry updates an entry for the branch instruction in a load dependency branch table with the index value. [Example 21] 20. The non-transitory machine-readable medium of example 19, wherein the method further comprises the branch redirection circuitry assigning an index value of a second branch instruction that also depends on the outcome from the load instruction. [Example 22] 20. The non-transitory machine-readable medium of example 17, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuit that allocates execution of the branch instruction to the execution circuit. [Example 23] 23. The non-transitory machine-readable medium of example 22, wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the assignment stage. [Example 24] 18. The non-transitory machine-readable medium of Example 17, wherein the method further comprises performing one or more operations in a circuit separate from an execution stage including the execution circuit of the pipeline circuit to determine whether the predicted path differs from the path based on the result from the load instruction. [Example 25] a memory for storing branch and load instructions; a processor core coupled to the memory; Equipped with The processor core is a pipeline circuit having a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions; a branch predictor circuit for generating a predicted path for said branch instruction; a branch redirection circuit for, for the branch instruction dependent on a result from the load instruction, checking whether an instruction received by the pipeline circuit is the load instruction, and if the instruction received by the pipeline circuit is the load instruction, checking a write-back of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuit, and redirecting the branch instruction in the pipeline circuit to the path if the predicted path differs from a path based on the result from the load instruction, and causing execution of the branch instruction for the path based on the result from the load instruction; having system. [Example 26] 26. The system of example 25, wherein the branch redirection circuitry checks the writeback of the result in a load value table that is separate from a final storage destination of the result. [Example 27] 27. The system of example 26, wherein the branch redirection circuitry assigns an index value of an entry in the load value table to the result of the load instruction if the instruction received by the pipeline circuitry is the load instruction, such that the index value is transmitted to the pipeline circuitry as a field of the branch instruction. [Example 28] 28. The system of example 27, wherein the branch redirection circuitry updates an entry for the branch instruction in a load dependency branch table with the index value if the instruction received by the pipeline circuitry is the load instruction. [Example 29] 28. The system of example 27, wherein the branch redirection circuitry assigns an index value for a second branch instruction that also depends on the outcome from the load instruction. [Example 30] 26. The system of example 25, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuit that allocates execution of the branch instruction to the execution circuit. [Example 31] 31. The system of example 30, wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the assignment stage. [Example 32] 26. The system of Example 25, wherein the processor core further comprises circuitry separate from an execution stage including the execution circuitry of the pipeline circuitry for performing one or more operations to determine whether the predicted path differs from the path based on the result from the load instruction.

[0087] In yet another embodiment, an apparatus comprises a data storage device storing code that, when executed by a hardware processor, causes the hardware processor to perform any of the methods disclosed herein. The apparatus may be as described in the detailed description. The method may be as described in the detailed description.

[0088] The instruction set may include a conditional branch instruction. The instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, bit positions) that specify, among other things, the operation to be performed (e.g., opcode) and the operands and / or other data fields (e.g., masks) on which the operation is to be performed. Some instruction formats are further subdivided through the definition of instruction templates (or sub-formats). For example, instruction templates of a given instruction format may be defined to have different subsets of the instruction format's fields (the included fields are typically in the same order, but at least some have different bit positions because fewer fields are included) and / or to have given fields that are interpreted differently. Thus, each instruction of the ISA is represented using a given instruction format (and, if defined, a given one of the instruction templates of that instruction format) and includes fields for specifying the operation and the operands. For example, an exemplary ADD instruction has an instruction format that includes a particular opcode and an opcode field that specifies the opcode and an operand field that selects the operands (source1 / destination and source2). When this ADD instruction occurs in an instruction stream, it will have particular content in the operand field that selects the particular operand. A set of SIMD extensions called Advanced Vector Extensions (AVX) (AVX1 and AVX2) and the use of the Vector Extensions (VEX) coding scheme have been published and / or made public (see, e.g., Intel® 64 and IA-32 Architectures Software Developer's Manual, May 2018, and Intel® Architecture Instruction Set Extensions Programming Reference, May 2018). [Example instruction format]

[0089] Embodiments of the instructions described herein may be embodied in different formats. Further, exemplary systems, architectures, and pipelines are detailed below. Embodiments of the instructions may be executed on such systems, architectures, and pipelines, but are not limited to those detailed. [Generic vector instruction format]

[0090] The vector friendly instruction format is an instruction format that is suitable for vector instructions (e.g., has certain fields that are specific to vector operations). Although embodiments are described in which both vector and scalar operations are supported through the vector friendly instruction format, alternative embodiments use only vector operations with the vector friendly instruction format.

[0091] 12A and 12B are block diagrams illustrating a generic vector friendly instruction format and its instruction templates according to an embodiment of the present disclosure. FIG. 12A is a block diagram illustrating a generic vector friendly instruction format and its class A instruction templates according to an embodiment of the present disclosure, while FIG. 12B is a block diagram illustrating a generic vector friendly instruction format and its class B instruction templates according to an embodiment of the present disclosure. Specifically, the generic vector friendly instruction format 1200 defines class A and class B instruction templates, both of which include no memory access 1205 and memory access 1220 instruction templates. The term generic in the context of the vector friendly instruction format refers to an instruction format that is not tied to any particular instruction set.

[0092] In an embodiment of the present disclosure, the vector friendly instruction format supports vector operand lengths (or sizes) of 64 bytes with 32-bit (4 byte) or 64-bit (8 byte) data element widths (or sizes) (so a 64 byte vector consists of either 16 doubleword sized elements or alternatively 8 quadword sized elements), vector operand lengths (or sizes) of 64 bytes with 16-bit (2 byte) or 8-bit (1 byte) data element widths (or sizes), 32-bit (4 byte), 64-bit (8 byte), 16-bit (2 byte) or 8-bit (1 byte) data element widths (or sizes), While described as supporting vector operand lengths (or sizes) of 32 bytes having an element width (or size), and vector operand lengths (or sizes) of 16 bytes having 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte) or 8-bit (1-byte) data element widths (or sizes), alternative embodiments may support more, fewer and / or different vector operand sizes (e.g., 256-byte vector operands) having more, fewer or different data element widths (e.g., 128-bit (16-byte) data element widths).

[0093] The class A instruction templates in Figure 12A include 1) a no memory access, full round control type operation 1210 instruction template and a no memory access, data transform type operation 1215 instruction template shown in the no memory access 1205 instruction templates, and 2) a memory access, temporal 1225 instruction template and a memory access, non-temporal 1230 instruction template shown in the memory access 1220 instruction templates. The class B instruction templates in Figure 12B include 1) a no memory access, write mask control, partial round control type operation 1212 instruction template and a no memory access, write mask control, VSIZE type operation 1217 instruction template shown in the no memory access 1205 instruction templates, and 2) a memory access, write mask control 1227 instruction template shown in the memory access 1220 instruction templates.

[0094] The generic vector friendly instruction format 1200 includes the following fields, listed below in the order shown in Figures 12A and 12B:

[0095] Format field 2140 - a particular value (the instruction format identifier value) in this field uniquely identifies the vector friendly instruction format and thus the occurrence of an instruction in the vector friendly instruction format in an instruction stream. As such, this field is optional in the sense that it is not required for an instruction set that has only a generic vector friendly instruction format.

[0096] Base Operation field 1242 - its content distinguishes between different base operations.

[0097] Register index field 1244 - its contents specify the location of the source and destination operands, whether they are in registers or in memory, either directly or through address generation. These contain a sufficient number of bits to select N registers from a P×Q (e.g., 32×512, 16×128, 32×1024, 64×1024) register file. In one embodiment, N may be up to three source and one destination register, although alternative embodiments may support more or fewer source and destination registers (e.g., up to two sources, where one of these sources also functions as a destination, and up to three sources, where one of these sources also functions as a destination, and up to two sources and one destination).

[0098] Qualifier field 1246 - its content distinguishes the occurrence of instructions in the generic vector instruction format that specify memory access from instructions that do not, i.e., distinguishes between no-memory access 1205 instruction templates and memory access 1220 instruction templates. Memory access operations read and / or write to the memory hierarchy (possibly using values ​​in registers to specify source and / or destination addresses), while no-memory access operations do not (e.g., source and destination are registers). In one embodiment, this field also selects among three different ways to perform memory address calculations, while alternative embodiments may support more, less, or different ways to perform memory address calculations.

[0099] Extended operation field 1250 - its contents distinguish which of various different operations are performed in addition to the base operation. This field is context specific. In one embodiment of the present disclosure, this field is split into a class field 1268, an alpha field 1252 and a beta field 1254. The extended operation field 1250 allows a group of common operations to be performed within a single instruction rather than two, three or four instructions.

[0100] Scale field 1260 - its content allows scaling of the contents of the index field for memory address generation (eg, for address generation using 2 scale x index + base).

[0101] Displacement field 1262A - its contents are used as part of memory address generation (e.g., for address generation using 2 scale x index + base + displacement).

[0102] Displacement factor field 1262B (note that the juxtaposition of displacement field 1262A directly above displacement factor field 1262B indicates that one or the other may be used) - its content is used as part of the address generation, and it specifies a displacement factor that is scaled by the size of the memory access (N) - N is the number of bytes in the memory access (e.g., for address generation using 2 scale x index + base + scaled displacement). Since redundant low order bits are ignored, the content of the displacement factor field is multiplied by the total size of the memory operands (N) to generate the final displacement used in calculating the effective address. The value of N is determined by the processor hardware at run-time based on the full opcode field 1274 and data manipulation field 1254C (described later in this specification). The displacement field 1262A and displacement factor field 1262B are optional in the sense that they are not used in the non-memory access 1205 instruction templates and / or different embodiments may implement only one or neither of the two.

[0103] Data element width field 2164 - its content distinguishes which of multiple data element widths are used (in some embodiments, for all instructions, in other embodiments, for only some instructions). This field is optional in the sense that it is not needed if only one data element width is supported and / or if data element widths are supported using some aspect of the opcode.

[0104] Write mask field 1270 - its content controls, on a data element position by data element position basis, whether data element positions in the destination vector operand reflect the results of the base and extension operations. Class A instruction templates support merging-write masking, while class B instruction templates support both merging-write masking and zeroing-write masking. When merging, the vector mask allows any set of elements in the destination to be protected from updates during the execution of any operation (specified by the base and extension operations). In another embodiment, the old value of each element in the destination is preserved if the corresponding mask bit has a zero value. In contrast, when zeroing, the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified in the base and extension operations). In one embodiment, the element in the destination is set to zero if the corresponding mask bit has a zero value. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span from the first element to the last element of the elements being modified). However, the elements being modified need not be contiguous. Thus, the write mask field 2270 allows for partial vector operations including loads, stores, arithmetic, logic, etc. Although embodiments of the present disclosure are described in which the contents of the write mask field 2270 select one of a number of write mask registers containing the write mask to be used (and thus the contents of the write mask field 2270 indirectly identify the masking to be performed), alternative embodiments allow the contents of the mask write field 2270 to instead or additionally directly specify the masking to be performed.

[0105] Immediate field 2172 - its content allows the specification of an immediate value. This field is optional in the sense that it is absent in implementations of the generic vector friendly format that do not support immediate values, and is also absent in instructions that do not use immediate values.

[0106] Class field 1268 - its contents distinguish between different classes of instructions. With reference to Figures 12A and 12B, the contents of this field select between class A and class B instructions. In Figures 12A and 12B, a rounded corner rectangle is used to indicate that a particular value is present in the field (e.g., class A 1268A and class B 1268B, respectively, of the class field 1268 in Figures 12A and 12B). [Class A instruction template]

[0107] For class A no memory access 1205 instruction templates, the alpha field 1252 is interpreted as an RS field 1252A whose content distinguishes which of the different extended operation types are performed (e.g., round 1252A.1 and data transform 1252A.2 are specified for the no memory access round type operation 1210 and no memory access data transform type operation 1215 instruction templates, respectively), and the beta field 1254 distinguishes which of the specified types of operations are performed. The scale field 1260, displacement field 1262A and displacement scale field 1262B are not present in the no memory access 1205 instruction templates. [Non-memory access instruction template - full-round control type operation]

[0108] In the no memory access full round control type operation 1210 instruction template, the beta field 1254 is interpreted as a round control field 1254A, whose contents provide the static rounding. In the described embodiment of the disclosure, the round control field 1254A includes a full floating-point exception suppression (SAE) field 1256 and a round operation control field 1258, although alternative embodiments may support encoding both of these concepts in the same field or may only have one or the other of these concepts / fields (e.g., may only have the round operation control field 1258).

[0109] SAE field 2256 - its content distinguishes whether to disable exception event reporting; if the SAE field 2256 content indicates that suppression is enabled, then the given instruction will not report any floating-point exception flags of any kind and will not raise any floating-point exception handlers.

[0110] A round operation control field 2258 - its content distinguishes which of a group of round operations to perform (e.g., round up, round down, round towards zero, and round towards nearest). Thus, the round operation control field 2258 allows the round mode to be changed on a per-instruction basis. In one embodiment of the present disclosure in which the processor includes a control register for specifying the round mode, the content of the round operation control field 2250 overrides that register value. [Non-memory access instruction template - data transformation type operation]

[0111] In the no memory access data transform type operation 1215 instruction template, the beta field 1254 is interpreted as a data transform field 1254B, whose content distinguishes which of a number of data transforms is performed (e.g., no data transform, swizzle, broadcast).

[0112] For memory access 1220 instruction templates of class A, the alpha field 1252 is interpreted as an eviction hint field 1252B, whose content distinguishes which of the eviction hints should be used (in FIG. 12A, temporal 1252B.1 and non-temporal 1252B.2 are specified for the memory access-temporal 1225 instruction template and the memory access-non-temporal 1230 instruction template, respectively). The beta field 1254 is interpreted as a data manipulation field 1254C, whose content distinguishes which of a number of data manipulation operations (also known as primitives) should be performed (e.g., no operation, broadcast, upconversion of source, downconversion of destination). The memory access 1220 instruction templates include a scale field 1260 and optionally include a displacement field 1262A or a displacement scale field 1262B.

[0113] Vector memory instructions perform vector loads from memory and vector stores to memory with conversion support. Like regular vector instructions, vector memory instructions transfer data to and from memory on a data element by data element basis, with the elements actually transferred being dictated by the contents of a vector mask selected as a writemask. [Memory access instruction template - temporary]

[0114] Transient data is data that is likely to be reused quickly enough to benefit from caching, however this is a hint and different processors may implement it differently, including ignoring the hint entirely. [Memory access instruction template - non-temporal]

[0115] Non-transient data is data that is unlikely to be reused quickly enough to benefit from caching in the first level cache, and eviction should be prioritized, however this is a hint and different processors may implement it in different ways, including ignoring the hint entirely. [Class B instruction template]

[0116] For class B instruction templates, the alpha field 1252 is interpreted as a write mask control (Z) field 1252C, whose content distinguishes whether the write masking controlled by the write mask field 1270 should be merging or zeroing.

[0117] For class B no memory access 1205 instruction templates, part of the beta field 1254 is interpreted as an RL field 1257A whose content distinguishes which of the different extended operation types is performed (e.g. round 1257A.1 and vector length (VSIZE) 1257A.2 are specified for the no memory access, write mask control, partial round control type operation 1212 instruction template and the no memory access, write mask control, VSIZE type operation 1217 instruction template, respectively), and the remainder of the beta field 1254 distinguishes which of the specified types of operations is performed. The scale field 1260, displacement field 1262A and displacement scale field 1262B are not present in the no memory access 1205 instruction templates.

[0118] For the no memory access write mask control partial round control type operation 1210 instruction template, the remainder of the beta field 1254 is interpreted as a round operation field 1259A and exception event reporting is disabled (the given instruction will not report any kind of floating-point exception flags or raise any floating-point exception handlers).

[0119] Round operation control field 1259A - similar to round operation control field 1258, its content distinguishes which of a group of round operations to perform (e.g., round up, round down, round towards zero, and round towards nearest). Thus, round operation control field 1259A allows the round mode to be changed on a per-instruction basis. In one embodiment of the present disclosure in which the processor includes a control register for specifying the round mode, the content of round operation control field 1250 overrides that register value.

[0120] In the non-memory access write mask control VSIZE type operation 1217 instruction template, the remainder of the beta field 1254 is interpreted as a vector length field 1259B, whose content distinguishes which of a number of data vector lengths is to be executed (e.g., 128 bytes, 256 bytes or 512 bytes).

[0121] For class B memory access 1220 instruction templates, a portion of the beta field 1254 is interpreted as a broadcast field 1257B, whose content distinguishes whether a broadcast-type data manipulation operation is performed or not, and the remainder of the beta field 1254 is interpreted as a vector length field 1259B. The memory access 1220 instruction templates include a scale field 1260 and optionally include a displacement field 1262A or a displacement scale field 1262B.

[0122] With respect to the generic vector friendly instruction format 2100, the full opcode field 2174 is shown to include the format field 2140, the base operation field 2142, and the data element width field 2164. While one embodiment is shown in which the full opcode field 2174 includes all of these fields, in embodiments that do not support all of these fields, the full opcode field 2174 includes less than all of these fields. The full opcode field 2174 provides an operation code (opcode).

[0123] The extended operation field 1250, data element width field 1264 and write mask field 1270 allow these functions to be specified on a per-instruction basis in the generic vector friendly instruction format.

[0124] The combination of the write mask field and the data element width field creates a typed instruction in that it allows masks to be applied based on different data element widths.

[0125] The various instruction templates found in class A and class B are useful in different situations. In some embodiments of the present disclosure, different processors or different cores within a processor may support only class A, only class B, or both classes. For example, a high-performance general-purpose out-of-order core intended for general-purpose computing may support only class B, a core intended primarily for graphics and / or scientific (throughput) computing may support only class A, and a core intended for both may support both (of course, a core having some combination of templates and instructions from both classes, but not all templates and instructions from both classes, is within the scope of the present disclosure). Also, a single processor may include multiple cores, all of which support the same class, or different cores support different classes. For example, in a processor with separate graphics and general-purpose cores, one of the multiple graphics cores intended primarily for graphics and / or scientific computing may support only class A, and one or more of the multiple general-purpose cores may be a high-performance general-purpose core with out-of-order execution and register renaming intended for general-purpose computing that supports only class B. Another processor that does not have a separate graphics core may include another general-purpose in-order or out-of-order core that supports both class A and class B. Of course, functionality from one class may be implemented in other classes in different embodiments of the present disclosure. Programs written in high-level languages ​​must be converted (e.g., just-in-time compiled or statically compiled) into a variety of different executable forms, including 1) a form that has only instructions of classes supported by the target processor for execution, or 2) a form that has alternative routines written with different combinations of instructions of all classes, and has control flow code that selects which routines to execute based on the instructions supported by the processor currently executing the code. [Example Vector Specific Instruction Format]

[0126] 13A-13D are block diagrams illustrating an example specific vector instruction format according to an embodiment of the present disclosure. FIG. 13A-13D show a specific vector instruction format 1300 that is unique in the sense that it specifies the location, size, interpretation and order of fields, as well as the values ​​of some of those fields. The specific vector instruction format 1300 can be used to extend the x86 instruction set. Thus, some of the fields are similar or the same as those used in the existing x86 instruction set and its extensions (e.g., AVX). The format remains consistent with the prefix encoding field, real opcode byte field, MOD R / M field, SIB field, displacement field, and immediate field of the existing x86 instruction set with extensions. It is shown which fields from FIG. 12A and FIG. 12B map to which fields in FIG. 13A-13D.

[0127] Although embodiments of the present disclosure are described with reference to the specific vector instruction format 1200 in the context of the generic vector instruction format 1300 for illustrative purposes, it should be understood that the present disclosure is not limited to the specific vector instruction format 1300 except as set forth in the claims. For example, the generic vector instruction format 1200 contemplates a variety of possible sizes for various fields, while the specific vector instruction format 1300 is illustrated as having fields of specific sizes. As a specific example, while the data element width field 1264 is illustrated in the specific vector instruction format 1300 as a one-bit field, the present disclosure is not so limited (i.e., the generic vector instruction format 1200 contemplates data element width field 1264 of other sizes).

[0128] The generic vector friendly instruction format 1200 includes the following fields, listed below in the order shown in FIG. 13A:

[0129] The EVEX prefix (bytes 0-3) 1302 is encoded in a 4-byte format.

[0130] Format field 2240 (EVEX byte 0, bits [7:0])—The first byte (EVEX byte 0) is the format field 2240, which contains 0x62 (a unique value used to distinguish vector friendly instruction formats in one embodiment of the present disclosure).

[0131] The second through fourth bytes (EVEX bytes 1-3) contain a number of bit fields that provide specific functionality.

[0132] The REX field 1305 (EVEX byte 1, bits [7-5]) consists of the EVEX.R bit field (EVEX byte 1, bit [7]-R), the EVEX.X bit field (EVEX byte 1, bit [6]-X) and the 1257BEX byte 1, bit [5]-B). The EVEX.R, EVEX.X and EVEX.B bit fields serve the same function as the corresponding VEX bit fields and are encoded using one's complement format. That is, ZMM0 is encoded as 1111B and ZMM15 is encoded as 0000B. The other fields of the instruction encode the lower three bits of the register index (rrr, xxx and bbb) as known in the art, so that by adding EVEX.R, EVEX.X and EVEX.B, Rrrr, Xxxx and Bbbb may be formed.

[0133] REX' Field 1210 - This is the first part of the REX' field 1210, the EVEX.R' bit field (EVEX byte 1, bit [4]-R') that is used to encode either the top 16 or the bottom 16 of the extended 32 register set. In one embodiment of the disclosure, this bit is stored in a bit-reversed format along with others as shown below to distinguish (in the well-known x86 32-bit mode) from the BOUND instruction whose real opcode byte is 62, but the MOD R / M field (described below) does not accept a value of 11 in the MOD field. Alternative embodiments of the disclosure do not store this bit and the others shown below in an inverted format. A value of 1 is used to encode the bottom 16 registers. In other words, R'Rrrr is formed by combining EVEX.R', EVEX.R and other RRR from other fields.

[0134] Opcode map field 21315 (EVEX byte 1, bits [3:0] - mmmm) - its contents encodes the implied initial opcode byte (0F, 0F38, or 0F3).

[0135] The data element width field 264 (EVEX byte 2, bit [7]-W) is represented by the notation EVEX.W. EVEX.W is used to define the granularity (size) of the data type (either 32-bit data elements or 64-bit data elements).

[0136] EVEX.vvvv 1320 (EVEX byte 2, bits [6:3] - vvvv) - The role of EVEX.vvvv may include: 1) EVEX.vvvv encodes the first source register operand specified in inverted (one's complement) format and is valid for instructions with two or more source operands; 2) EVEX.vvvv encodes the destination register operand specified in one's complement format for certain vector shifts; or 3) EVEX.vvvv does not encode any operand, the field is reserved and should contain 1111b. Thus, the EVEX.vvvv field 1320 encodes the four least significant bits of the first source register specifier stored in inverted (one's complement) format. Depending on the instruction, additional different EVEX bit fields are used to extend the size of the specifier to 32 registers.

[0137] Class field of EVEX.U1268 (EVEX byte 2, bit [2] - U) - If EVEX.U=0, it indicates class A or EVEX.U0, if EVEX.U=1, it indicates class B or EVEX.U1.

[0138] Prefix encoding field 1325 (EVEX byte 2, bits [1:0]-pp) - provides additional bits to the base operation field. In addition to providing support for legacy SSE instructions in the EVEX prefix format, this also has the benefit of compressing the SIMD prefix (instead of needing a byte to represent the SIMD prefix, the EVEX prefix only requires 2 bits). In one embodiment, to support legacy SSE instructions that use SIMD prefixes (66H, F2H, F3H) in both the legacy and EVEX prefix formats, these legacy SIMD prefixes are encoded into the SIMD prefix encoding field and expanded to legacy SIMD prefixes at run-time before being provided to the decoder's PLA (so the PLA can execute both the legacy and EVEX formats of these legacy instructions without modification). Although newer instructions can directly use the contents of the EVEX prefix encoding field as an opcode extension, certain embodiments extend it in a similar manner for consistency but to allow different meanings to be specified by these legacy SIMD prefixes. Alternative embodiments may redesign the PLA to support 2-bit SIMD prefix encodings and thus not require the extension.

[0139] Alpha Field 1252 (EVEX Byte 3, Bit [7] - Also known as EH, EVEX.EH, EVEX.rs, EVEX.RL, EVEX.WriteMaskControl and EVEX.N, and denoted with an α) - As previously mentioned, this field is context specific.

[0140] Beta field 1254 (EVEX byte 3, bits [6:4] - SSS, EVEX.s 2-0 , EVEX.r 2-0, EVEX,rr1, EVEX.LL0, EVEX.LLB, and are denoted using βββ) - as mentioned above, this field is context specific.

[0141] REX' field 1210 - this is the remainder of the REX' field, the EVEX.V' bit field (EVEX byte 3, bit [3] - V') which can be used to encode either the top 16 or the bottom 16 of the extended 32 register set. This bit is stored in bit-reversed format. A value of 1 is used to encode the bottom 16 registers. In other words, V'VVVV is formed by combining EVEX.V', EVEX.vvvv.

[0142] Write mask field 2170 (EVEX byte 3, bits [2:0]-kkk) - its contents specify a register index within the write mask register, as previously described. In one embodiment of the present disclosure, a special value EVEX.kkk=000 has special behavior that implies that no write mask is used for the particular instruction (this may be implemented in a variety of ways, including a write mask that is hardwired into everything, or the use of hardware to bypass the masking hardware).

[0143] The real opcode field 2030 (byte 4) is also known as the opcode byte. Part of the opcode is specified in this field.

[0144] MOD R / M field 1340 (byte 5) includes MOD field 1342, Reg field 1344, and R / M field 1346. As previously mentioned, the content of MOD field 1342 distinguishes between memory access and non-memory access operations. The role of Reg field 1344 can be summarized in two situations: encoding either a destination register operand or a source register operand, or being treated as an opcode extension and not used to encode any instruction operand. The role of R / M field 1346 may include encoding an instruction operand that references a memory address, or encoding either a destination register operand or a source register operand.

[0145] Scale, Index, Base (SIB) Byte (Byte 6) - As previously mentioned, the content of the scale field 1250 is used in memory address generation. SIB.xxx 1354 and SIB.bbb 1356 - The contents of these fields have already been mentioned in connection with the register indices Xxxx and Bbbb.

[0146] Displacement Field 1262A (Bytes 7-10) - If the MOD field 1342 contains 10, then bytes 7-10 are the displacement field 1262A and function the same as the legacy 32-bit displacement (disp32) and work at byte granularity.

[0147] Displacement factor field 1262B (byte 7) - When MOD field 1342 contains 01, byte 7 is the displacement factor field 1262B. The location of this field is the same as that of the 8-bit displacement (disp8) of the legacy x86 instruction set, which works at byte granularity. Since disp8 is sign-extended, it can only be addressed between -128 and 127 byte offsets, and for a 64-byte cache line, disp8 uses 8 bits that can only be set to four really useful values: -128, -64, 0, and 64. Since a wider range is often needed, disp32 is used, but disp32 requires 4 bytes. In contrast to disp8 and disp32, the displacement factor field 1262B is a reinterpretation of disp8. When using the displacement factor field 1262B, the actual displacement is determined by the contents of the displacement factor field multiplied by the size of the memory operand access (N). This type of displacement is referred to as disp8 x N. This reduces the average instruction length (a single byte used for displacement, but with a much larger range). Since such a compressed displacement is based on the assumption that the effective displacement is a multiple of the granularity of the memory access, the redundant lower bits of the address offset do not need to be encoded. In other words, the displacement factor field 1262B replaces the 8-bit displacement of the legacy x86 instruction set. The displacement factor field 1262B is therefore encoded in the same manner as the 8-bit displacement of the x86 instruction set, except only that disp8 is overloaded to disp8×N (so there is no change in the ModRM / SIB encoding rules). In other words, there is no change in the encoding rules or the encoding length, but only in the interpretation of the displacement value by the hardware (which needs to scale the displacement by the size of the memory operand to get the address offset in bytes). The immediate field 1272 works as described above. [Full Opcode Field]

[0148] 13B is a block diagram illustrating the fields of a specific vector specific instruction format 1300 that make up the full opcode field 1274, in accordance with one embodiment of the present disclosure. Specifically, the full opcode field 1274 includes a format field 1240, a base operation field 1242, and a data element width (W) field 1264. The base operation field 1242 includes a prefix encoding field 1325, an opcode map field 1315, and a real opcode field 1330. [Register index field]

[0149] 13C is a block diagram illustrating the fields of the specific vector instruction format 1300 that make up the register index field 1244, in accordance with one embodiment of the present disclosure. Specifically, the register index field 1244 includes a REX field 1305, a REX′ field 1310, a MODR / M.reg field 1344, a MODR / Mr / m field 1346, a VVVV field 1320, a xxx field 1354, and a bbb field 1356. [Extended operation field]

[0150] 13D is a block diagram illustrating the fields of the specific vector instruction format 1300 that make up the extended operation field 1250, according to one embodiment of the disclosure. The class (U) field 1268, if it contains a 0, represents EVEX.U0 (class A 1268A), and if it contains a 1, represents EVEX.U1 (class B 1268B). If U=0 and the MOD field 1342 contains 11 (signifying a non-memory access operation), the alpha field 1252 (EVEX byte 3, bit [7]) - EH) is interpreted as the RS field 1252A. If the RS field 1252A contains 1 (round 1252A.1), the beta field 1254 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the round control field 1254A. The round control field 1254A includes a 1-bit SAE field 1256 and a 2-bit round operation field 1258. If RS field 1252A contains 0 (data transformation 1252A.2), then beta field 1254 (EVEX byte 3, bits [6:4] - SSS) is interpreted as a 3-bit data transformation field 1254B. If U=0 and MOD field 1342 contains 00, 01, or 10 (signifying a memory access operation), then alpha field 1252 (EVEX byte 3, bits [7] - EH) is interpreted as an eviction hint (EH) field 1252B and beta field 1254 (EVEX byte 3, bits [6:4] - SSS) is interpreted as a 3-bit data operation field 1254C.

[0151] If U=1, then the alpha field 1252 (EVEX byte 3, bit [7]-EH) is interpreted as a write mask control (Z) field 1252C. If U=1 and the MOD field 1342 contains 11 (indicating a non-memory access operation), then a portion of the beta field 1254 (EVEX byte 3, bit [4]-S 0) is interpreted as RL field 1257A, and if it contains a 1 (round 1257A.1), the remainder of beta field 1254 (EVEX byte 3, bits [6-5]-S 2-1 ) is interpreted as the round operation field 1259A, whereas if the RL field 1257A contains 0 (VSIZE1257.A2), the remainder of the beta field 1254 (EVEX byte 3, bits [6-5]-S 2-1 ) is the vector length field 1259B (EVEX byte 3, bits [6-5]-L 1-0 If U=1 and the MOD field 1342 contains 00, 01, or 10 (indicating a memory access operation), then the beta field 1254 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the vector length field 1259B (EVEX byte 3, bits [6-5] - L 1-0 ) and broadcast field 1257B (EVEX byte 3, bit [4]-B). [Example Register Architecture]

[0152] 14 is a block diagram of a register architecture 1400 according to one embodiment of the disclosure. In the embodiment shown, there are 32 vector registers 1410 that are 512 bits wide. These registers are referenced as zmm0 through zmm31. The lower 256 bits of the lower 16 zmm registers are overlaid onto registers ymm0 through 16. The lower 128 bits of the lower 16 zmm registers (the lower 128 bits of the ymm registers) are overlaid onto registers xmm0 through 15. The vector specific instruction format 1300 operates on these overlaid register files as shown in the table below. [Table 1]

[0153] In other words, the vector length field 1259B selects between a maximum length and one or more other shorter lengths, each such shorter length being half the length of the aforementioned length, and instruction templates without the vector length field 1259B operate with the maximum vector length. Furthermore, in one embodiment, the class B instruction templates of the specific vector friendly instruction format 1300 operate on packed or scalar single / double precision floating point data and packed or scalar integer data. Scalar operations are operations performed on the lowest data element positions in zmm / ymm / xmm registers. The higher data element positions either remain the same as they were before the instruction or are zeroed out depending on the embodiment.

[0154] Write Mask Registers 1415 - In the embodiment shown, there are eight write mask registers (k0 through k7), each 64 bits in size. In an alternative embodiment, the write mask registers 1415 are 16 bits in size. As previously mentioned, in one embodiment of the present disclosure, vector mask register k0 cannot be used as a write mask; if an encoding that would normally indicate k0 is used for a write mask, selecting a hardwired write mask of 0xFFFF effectively disables write masking for that instruction.

[0155] General purpose registers 1425 - in the embodiment shown, there are sixteen 64-bit general purpose registers that are used with existing x86 addressing modes to address memory operands. These registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0156] Scalar floating-point stack register file (x87 stack) 1445 into which MMX packed integer flat register file 1450 is aliased - in the embodiment shown, the x87 stack is an 8-element stack used to perform scalar floating-point operations on 32-bit / 64-bit / 80-bit floating-point data using the x87 instruction set extensions, while the MMX registers are used to perform operations on 64-bit packed integer data and to hold operands for some operations performed between MMX and XMM registers.

[0157] Alternative embodiments of the present disclosure may use wider or narrower registers. Additionally, alternative embodiments of the present disclosure may use more, fewer, or different register files and registers. [Exemplary Core Architectures, Processors and Computer Architectures]

[0158] Processor cores may be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) a general purpose in-order core for general purpose computing, 2) a high performance general purpose out-of-order core for general purpose computing, 3) a specialized core primarily for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) a CPU including one or more general purpose in-order cores for general purpose computing and / or one or more general purpose out-of-order cores for general purpose computing, and 2) a co-processor including one or more specialized cores primarily for graphics and / or scientific (throughput). Such different processors result in different computer system architectures that may include: 1) coprocessors on a separate chip from the CPU, 2) coprocessors on a separate die in the same package as the CPU, 3) coprocessors on the same die as the CPU (in which case such coprocessors are sometimes referred to as special purpose logic or special purpose cores, e.g., integrated graphics and / or scientific (throughput) logic), and 4) systems-on-chips (sometimes referred to as application cores or application processors) that may be included on the same die as the described CPU, the coprocessors mentioned above and additional functionality. Exemplary core architectures are described next, followed by exemplary processor and computer architectures. [Example Core Architecture] [Block diagram of in-order and out-of-order cores]

[0159] FIG. 15A is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline, according to an embodiment of the present disclosure. FIG. 15B is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue / execution architecture core included in a processor, according to an embodiment of the present disclosure. The solid lined boxes in FIG. 15A and FIG. 15B indicate the in-order pipeline and the in-order core, while the optional additional dashed lined boxes indicate the register renaming, out-of-order issue / execution pipeline and the core. The out-of-order aspects will be described assuming that the in-order aspects are a subset of the out-of-order aspects.

[0160] In FIG. 15A , a processor pipeline 1500 includes a fetch stage 1502, a length decode stage 1504, a decode stage 1506, an allocation stage 1508, a renaming stage 1510, a scheduling (also known as dispatch or issue) stage 1512, a register read / memory read stage 1514, an execution stage 1516, a writeback / memory write stage 1518, an exception handling stage 1522 and a commit stage 1524.

[0161] 15B shows a processor core 1590 including a front end unit 1530 coupled to an execution engine unit 1550, both of which are coupled to a memory unit 1570. The core 1590 may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core 1590 may be a special-purpose core, such as, for example, a network or communication core, a compression engine, a co-processor core, a general purpose computing graphics processing unit (GPGPU) core, or a graphics core.

[0162] The front-end unit 1530 includes a branch prediction unit 1532 coupled to an instruction cache unit 1534, which is coupled to an instruction translation lookaside buffer (TLB) 1536, which is coupled to an instruction fetch unit 1538, which is coupled to a decode unit 1540. The decode unit 1540 (or a decoder or decoder unit) may decode instructions (e.g., macro-instructions) and generate as output one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals decoded from or otherwise reflective of or derived from the original instruction. The decode unit 1540 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memories (ROMs), and the like. In one embodiment, core 1590 includes a microcode ROM or other medium that stores microcode for particular macro instructions (e.g., in decode unit 1540 or otherwise within front end unit 1530). Decode unit 1540 is coupled to a renaming / allocator unit 1552 within execution engine unit 1550.

[0163] The execution engine unit 1550 includes a renaming / allocator unit 1552 coupled to a retirement unit 1554 and a set of one or more scheduler units 1556. The scheduler units 1556 represent any number of different schedulers including reservation stations, central instruction window, etc. The scheduler units 1556 are coupled to physical register file units 1558. Each of the physical register file units 1558 represents one or more physical register files, each of which stores one or more different data types, such as, for example, scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, status (e.g., an instruction pointer, which is the address of the next instruction to be executed), etc. In one embodiment, the physical register file units 1558 have a vector register unit, a write mask register unit, and a scalar register unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers. The physical register file unit 1558 is overlaid with the retirement unit 1554 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer and retirement register file, using a future file, a history buffer and retirement register file, using a register map and pool of registers, etc.). The retirement unit 1554 and the physical register file unit 1558 are coupled to the execution clusters 1560. The execution clusters 1560 include a set of one or more execution units 1562 and a set of one or more memory access units 1564. The execution units 1562 may perform various operations (e.g., shift, add, subtract, multiply) on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point).Some embodiments may include multiple execution units dedicated to a particular function or set of functions, while other embodiments may include only one execution unit, or multiple execution units that all perform all functions. Scheduler unit 1556, physical register file unit 1558, and execution cluster 1560 are sometimes shown as multiple because certain embodiments create separate pipelines for particular types of data / operations (e.g., scalar integer pipeline, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or memory access pipeline, each having its own scheduler unit, physical register file unit, and / or execution cluster, and in the case of a separate memory access pipeline, in certain embodiments, only the execution cluster of this pipeline is implemented in an embodiment with memory access unit 1564). It should also be understood that if separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution and the rest may be in-order.

[0164] The set of memory access units 1564 is coupled to a memory unit 1570, which includes a data TLB unit 1572 coupled to a data cache unit 1574 coupled to a level 2 (L2) cache unit 1576. In one exemplary embodiment, the memory access units 1564 may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 1572 in the memory unit 1570. The instruction cache unit 1534 is further coupled to a level 2 (L2) cache unit 1576 in the memory unit 1570. The L2 cache unit 1576 is coupled to one or more other levels of cache and ultimately to a main memory.

[0165] As an example, an exemplary register renaming, out-of-order issue / execution core architecture may implement pipeline 1500 as follows. 1) instruction fetch 1538 performs the fetch and length decode stages 1502 and 1504; 2) decode unit 1540 performs the decode stage 1506; 3) renaming / allocator unit 1552 performs the allocation stage 1508 and renaming stage 1510; 4) scheduler unit 1556 performs the scheduling stage 1512; 5) physical register file unit 1558 and memory unit 1570 perform the register read / memory read stage 1514; execution cluster 1560 performs the execution stage 1516; 6) memory unit 1570 and physical register file unit 1558 perform the writeback / memory write stage 1518; 7) various units may be involved in the exception handling stage 1522; and 8) retirement unit 1554 and physical register file unit 1558 perform the commit stage 1524.

[0166] Core 1590 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added in newer versions), the MIPS instruction set from MIPS Technologies of Sunnyvale, Calif., the ARM instruction set (with optional additional extensions such as NEON) from ARM Holdings of Sunnyvale, Calif.), including the instructions described herein. In one embodiment, core 1590 includes logic to support packed data instruction set extensions (e.g., AVX1, AVX2), thereby enabling operations used by many multimedia applications to be performed with packed data.

[0167] It will be appreciated that a core may support multithreading (executing two or more parallel sets of operations or threads) and may do so in a variety of manners including time sliced ​​multithreading, simultaneous multithreading (wherein a single physical core provides a logical core for each of the threads that the physical core is simultaneously multithreading), or a combination thereof (e.g., time sliced ​​fetch and decode followed by simultaneous multithreading such as Intel® Hyper-Threading Technology).

[0168] Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming may also be used in in-order architectures. The illustrated embodiment of the processor also includes separate instruction and data cache units 1534 / 1574 and a shared L2 cache unit 1576, although alternative embodiments may have a single internal cache, such as a level 1 (L1) internal cache or multiple levels of internal cache, for both instructions and data. In some embodiments, the system may include a combination of an internal cache and an external cache that is external to the core and / or processor. Alternatively, all of the cache may be external to the core and / or processor. [Specific Exemplary In-Order Core Architecture]

[0169] 16A and 16B show block diagrams of a more specific exemplary in-order core architecture. The core would be one of several logic blocks (including other cores of the same and / or different types) in a chip. The logic block communicates with some fixed function logic, memory I / O interfaces, and other necessary I / O logic, depending on the application, through a high bandwidth interconnect network (e.g., a ring network).

[0170] FIG. 16A is a block diagram of a single processor core shown with its connection to an on-die interconnect network 1602 and a local subset of a level 2 (L2) cache 1604, according to an embodiment of the disclosure. In one embodiment, the instruction decode unit 1600 supports the x86 instruction set with the packed data instruction set extension. The L1 cache 1606 allows low latency access to cache memory for the scalar and vector units. In one embodiment, the scalar unit 1608 and the vector unit 1610 (to simplify the design) use separate register sets (scalar registers 1612 and vector registers 1614, respectively), and data transferred between them is written to memory and then read back from the level 1 (L1) cache 1606, although alternative embodiments of the disclosure may use different approaches (e.g., using a single register set, or including a communication path that allows data to be transferred between the two register files without being written and read back).

[0171] The local subset of the L2 cache 1604 is part of a global L2 cache that is divided into separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset of the L2 cache 1604. Data read by a processor core is stored in its L2 cache subset 1604 and can be accessed quickly in parallel with other processor cores accessing their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset 1604 and is flushed from other subsets when necessary. The ring network ensures coherency of shared data. The ring network is bidirectional, allowing agents such as processor cores, L2 caches, and other logic blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide per direction.

[0172] FIG. 16B is an expanded view of a portion of the processor core in FIG. 16A according to an embodiment of the disclosure. FIG. 16B includes an L1 data cache 1606A, which is part of the L1 cache 1604, as well as more details regarding the vector unit 1610 and vector registers 1614. Specifically, the vector unit 1610 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 1628) that executes one or more of integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports swizzling of register inputs with swizzle unit 1620, numeric conversion with numeric conversion units 1622A-B, and duplication for memory inputs with duplication unit 1624. A write mask register 1626 allows prediction of the resulting vector writes.

[0173] 17 is a block diagram of a processor 1700 that may have more than one core, an integrated memory controller, and integrated graphics, according to an embodiment of the present disclosure. The solid lined box in FIG. 17 illustrates a processor 1700 with a single core 1702A, a system agent 1710, and a set of one or more bus controller units 1716, while an optional additional dashed lined box illustrates an alternative processor 1700 with multiple cores 1702A-N, a set of one or more integrated memory controller units 1714 in the system agent unit 1710, and dedicated logic 1708.

[0174] Thus, different implementations of the processor 1700 may include: 1) a CPU in which the special purpose logic 1708 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores) and the cores 1702A-1702N are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, a combination of the two), 2) a coprocessor in which the cores 1702A-1702N are multiple special purpose cores primarily for graphics and / or scientific (throughput), and 3) a coprocessor in which the cores 1702A-1702N are multiple general purpose in-order cores. Thus, the processor 1700 may be a general purpose processor, a coprocessor, or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit), a high throughput multiple integrated core (MIC) coprocessor (containing 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. The processor 1700 may be a part of and / or may be implemented on one or more substrates using any of a number of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.

[0175] The memory hierarchy includes one or more levels of cache within the core, a set of shared cache units 1706 or one or more shared cache units 1706, and an external memory (not shown) coupled to a set of integrated memory controller units 1714. The set of shared cache units 1706 may include one or more mid-level caches or other level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other level caches, a last level cache (LLC), and / or combinations thereof. In one embodiment, a ring-based interconnect unit 1712 interconnects the integrated graphics logic 1708, the set of shared cache units 1706, and the system agent unit 1710 / integrated memory controller unit 1714, while alternative embodiments may use any number of well-known techniques for interconnecting such units. In one embodiment, coherency is maintained between the one or more cache units 1706 and the cores 1702-AN.

[0176] In some embodiments, one or more of the cores 1702A-N are capable of multithreading. The system agent 1710 includes those components that coordinate and operate the cores 1702A-N. The system agent unit 1710 may include, for example, a power control unit (PCU) and a display unit. The PCU may be or may include the logic and components necessary to coordinate the power state of the cores 1702A-N and the integrated graphics logic 1708. The display unit is for driving one or more externally connected displays.

[0177] The cores 1702A-1702N may be homogenous or heterogeneous with respect to architectural instruction sets, i.e., two or more of the cores 1702A-1702N may be capable of executing the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set. [Example Computer Architecture]

[0178] 18-21 are block diagrams of exemplary computer architectures. Other system designs and configurations known in the art are also suitable for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and a variety of other electronic devices. In general, a wide variety of systems or electronic devices capable of incorporating the processors and / or other execution logic disclosed herein are generally suitable.

[0179] 18, a block diagram of a system 1800 according to one embodiment of the present disclosure is shown. The system 1800 may include one or more processors 1810, 1815, which are coupled to a controller hub 1820. In one embodiment, the controller hub 1820 includes a graphics memory controller hub (GMCH) 1890 and an input / output hub (IOH) 1850 (which may be on separate chips). The GMCH 1890 includes a memory and graphics controller to which the memory 1840 and coprocessor 1845 are coupled. The IOH 1850 couples input / output (I / O) devices 1860 to the GMCH 1890. Alternatively, one or both of the memory and graphics controller are integrated within the processor (as described herein), and the memory 1840 and coprocessor 1845 are directly coupled to the processor 1810 and the controller hub 1820 in a single chip with the IOH 1850. Memory 1840 may include, for example, branch predictor code 1840A for storing code that, when executed, causes the processor to perform any of the methods of this disclosure.

[0180] Additional processors 1815 of an optional nature are indicated in dashed lines in Figure 18. Each processor 1810, 1815 may include one or more of the processing cores described herein and may be some version of the processor 1700.

[0181] The memory 1840 may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two. In at least one embodiment, the controller hub 1820 communicates with the processors 1810, 1815 via a multi-drop bus, e.g., a front side bus (FSB), a point-to-point interface such as a Quickpath Interconnect (QPI), or similar connection 1895.

[0182] In one embodiment, coprocessor 1845 is a special purpose processor, such as a high throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, etc. In one embodiment, controller hub 1820 may include an integrated graphics accelerator.

[0183] There may be a wide variety of differences between the physical resources 1810, 1815 with respect to a wide range of value criteria including architectural, microarchitectural, thermal and power consumption characteristics, and the like.

[0184] In one embodiment, the processor 1810 executes instructions that control general types of data processing operations. Coprocessor instructions may be embedded within the instructions. The processor 1810 recognizes these coprocessor instructions as types of instructions that an attached coprocessor 1845 should execute. Thus, the processor 1810 issues these coprocessor instructions (or control signals representing the coprocessor instructions) on a coprocessor bus or other interconnect to the coprocessor 1845. The coprocessor 1845 accepts and executes the received coprocessor instructions.

[0185] 19, a block diagram of a first more specific exemplary system 1900 according to an embodiment of the present disclosure is shown. As shown in FIG. 19, the multiprocessor system 1900 is a point-to-point interconnect system and includes a first processor 1970 and a second processor 1980 coupled via a point-to-point interconnect 1950. Each of the processors 1970 and 1980 may be some version of the processor 1700. In one embodiment of the present disclosure, the processors 1970 and 1980 are the processors 1810 and 1815, respectively, while the coprocessor 1938 is the coprocessor 1845. In another embodiment, the processors 1970 and 1980 are the processors 1810 and the coprocessor 1845, respectively.

[0186] Processors 1970 and 1980 are shown to include integrated memory controller (IMC) units 1972 and 1982, respectively. Processor 1970 also includes point-to-point (PP) interfaces 1976 and 1978 as part of its bus controller unit, and similarly, second processor 1980 includes PP interfaces 1986 and 1988. Processors 1970, 1980 may exchange information using PP interface circuits 1978, 1988 via point-to-point (PP) interface 1950. As shown in FIG. 19, IMCs 1972 and 1982 couple the processors to their respective memories, i.e., memory 1932 and memory 1934, which may be part of a main memory locally attached to the respective processors.

[0187] Processors 1970, 1980 may each exchange information with chipset 1990 using point-to-point interface circuits 1976, 1994, 1986, 1998 via respective PP interfaces 1952, 1954. Chipset 1990 may optionally exchange information with coprocessor 1938 via high performance interface 1939. In one embodiment, coprocessor 1938 is a special purpose processor, such as a high throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, etc.

[0188] A shared cache (not shown) may be included either external to the processor or to both processors and may be further connected to the processors via the PP interconnect such that when the processors enter a low power mode, either or both of the processors' local cache information may be stored in the shared cache.

[0189] Chipset 1990 may be coupled to a first bus 1916 via an interface 1996. In one embodiment, first bus 1916 may be a bus such as a Peripheral Component Interconnect (PCI) bus, or a PCI Express bus or another third generation I / O interconnect bus, although the scope of the disclosure is not so limited.

[0190] As shown in FIG. 19, various I / O devices 1914 may be coupled to the first bus 1916, along with a bus bridge 1918 coupling the first bus 1916 to a second bus 1920. In one embodiment, one or more additional processors 1915, such as a co-processor, a high throughput MIC processor, an accelerator of a GPGPU (e.g., a graphics accelerator or a digital signal processing (DSP) unit, etc.), a field programmable gate array, or any other processor, are coupled to the first bus 1916. In one embodiment, the second bus 1920 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 1920, including, for example, a keyboard and / or mouse 1922, a disk drive or other mass storage device, which may include a communication device 1927 and a storage unit 1928, instructions / code and data 1930, etc. Additionally, an audio I / O 1924 may be coupled to the second bus 1920. It should be noted that other architectures are possible. For example, instead of the point-to-point architecture of FIG. 19, the system may implement a multi-drop bus or other such architecture.

[0191] Referring now to Figure 20, a block diagram of a second, more specific, exemplary system 2000 according to an embodiment of the present disclosure is shown. Like elements in Figures 19 and 20 are labeled with like reference numbers, and certain aspects of Figure 19 have been omitted from Figure 20 to avoid obscuring other aspects of Figure 20.

[0192] FIG. 20 shows that the processors 1970, 1980 may include integrated memory and I / O control logic ("CL") 1972 and 1982, respectively. Thus, the CL 1972, 1982 includes an integrated memory controller unit and includes I / O control logic. FIG. 20 shows that not only are the memories 1932, 1934 coupled to the CL 1972, 1982, but also the I / O devices 2014 coupled to the control logic 1972, 1982. Legacy I / O devices 2015 are coupled to the chipset 1990.

[0193] Referring now to FIG. 21, a block diagram of a SoC 2100 according to an embodiment of the present disclosure is shown. Similar elements in FIG. 17 are labeled with similar reference numbers. Also, the dashed boxes are optional features on a more advanced SoC. In FIG. 21, an interconnect unit 2102 is coupled to an application processor 2110 including a set of one or more cores 202A-N and a shared cache unit 1706, a system agent unit 1710, a bus controller unit 1716, an integrated memory controller unit 1714, a set or one or more coprocessors 2120 that may include integrated graphics logic, an image processor, an audio processor, and a video processor, a static random access memory (SRAM) unit 2130, a direct memory access (DMA) unit 2132, and a display unit 2140 for coupling to one or more external displays. In one embodiment, the coprocessor 2120 includes a dedicated processor, such as a network or communication processor, a compression engine, a GPGPU, a high-throughput MIC processor, or an embedded processor, etc.

[0194] The embodiments (e.g., mechanisms) disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation approaches. The embodiments of the present disclosure may be implemented as a computer program or program code running on a programmable system comprising at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0195] Program code, such as code 1930 shown in Figure 19, may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices, in known fashion. For purposes of this application, a processing system includes any system having a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0196] The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code may also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

[0197] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represent various logic within a processor, which, when read by a machine, cause the machine to assemble logic to perform the techniques described herein. Such representations, known as "IP cores," may be stored on tangible machine-readable media and supplied to various customers or manufacturing facilities for loading into manufacturing machines that actually create the logic or processor.

[0198] Such machine-readable storage media may include, but are not limited to, non-transitory tangible configurations of articles manufactured or formed by a machine or device, including storage media such as hard disks, floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk re-writeables (CD-RWs), and any other types of disks, including magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs), such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), phase change memories (PCMs), magnetic or optical cards, or any other type of medium suitable for storing electronic instructions.

[0199] Accordingly, embodiments of the present disclosure also include non-transitory, tangible, machine-readable media that include instructions or that include design data, such as hardware description language (HDL), that defines the functionality of the structures, circuits, devices, processors and / or systems described herein. Such embodiments may also be referred to as program products. [Emulation (including binary conversion, code morphing, etc.)]

[0200] In some cases, an instruction converter may be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter may convert, morph, emulate, or otherwise convert (e.g., using static binary translation, dynamic binary translation including dynamic compilation), instructions to one or more other instructions to be processed by the core. The instruction converter may be implemented in software, hardware, firmware, or a combination thereof. The instruction converter may be on the processor, off the processor, or partly on the processor and partly off the processor. FIG. 22 is a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set, according to an embodiment of the present disclosure. In the embodiment shown, the instruction converter is a software instruction converter, but may alternatively be implemented in software, firmware, hardware, or various combinations thereof. 22 illustrates that a program in a high-level language 2202 may be compiled using an x86 compiler 2204 to generate x86 binary code 2206 that may be natively executed by a processor having at least one x86 instruction set core 2216. Processor having at least one x86 instruction set core 2216 represents any processor that can perform substantially the same functions as an Intel processor having at least one x86 instruction set core by compatibly executing or otherwise processing (1) a majority of the instruction set of an Intel x86 instruction set core, or (2) object code versions of applications or other software intended to run on an Intel processor having at least one x86 instruction set core, to achieve substantially the same results as an Intel processor having at least one x86 instruction set core.The x86 compiler 2204 represents a compiler operable to generate x86 binary code 2206 (e.g., object code) that may be executed on a processor 2216 having at least one x86 instruction set core, with or without additional linkage processing. Similarly, FIG. 22 shows that a program in a high-level language 2202 may be compiled using an alternative instruction set compiler 2208 that generates alternative instruction set binary code 2210. The alternative instruction set binary code 2210 may be executed natively by a processor 2214 that does not have at least one x86 instruction set core (e.g., a processor having a core that executes a MIPS instruction set from MIPS Technologies of Sunnyvale, Calif. and / or executes an ARM instruction set from ARM Holdings of Sunnyvale, Calif.). The instruction converter 2212 is used to convert the x86 binary code 2206 into code that may be executed natively by a processor 2214 that does not have an x86 instruction set core. This converted code is unlikely to be identical to the alternative instruction set binary code 2210. 2212 is not an x86 binary code 2206 because an instruction converter capable of this conversion would be difficult to manufacture. However, the converted code implements common operations and is composed of instructions in an alternative instruction set. Thus, instruction converter 2212 represents software, firmware, hardware, or a combination thereof that enables a processor or other electronic device that does not have an x86 instruction set processor or core to execute x86 binary code 2206, through emulation, simulation, or any other process. [Other possible items] [Item 1] a pipeline circuit having a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions; a branch predictor circuit for generating a predicted path for a branch instruction; a branch redirection circuit for, for the branch instruction dependent on a result from a load instruction, checking whether an instruction received by the pipeline circuit is the load instruction, and if the instruction received by the pipeline circuit is the load instruction, checking a write-back of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuit, and redirecting the branch instruction in the pipeline circuit to the path if the predicted path differs from a path based on the result from the load instruction, and causing execution of the branch instruction for the path based on the result from the load instruction; A processor comprising: [Item 2] 2. The processor of claim 1, wherein the branch redirection circuitry checks the writeback of the result in a load value table that is separate from the final storage destination of the result. [Item 3] 3. The processor of claim 2, wherein the branch redirection circuitry assigns an index value of an entry in the load value table to the result of the load instruction if the instruction received by the pipeline circuitry is the load instruction, and causes the index value to be transmitted to the pipeline circuitry as a field of the branch instruction. [Item 4] 4. The processor of claim 3, wherein the branch redirection circuit updates an entry for the branch instruction in a load dependency branch table with the index value if the instruction received by the pipeline circuit is the load instruction. [Item 5] 4. The processor of claim 3, wherein the branch redirection circuitry assigns an index value for a second branch instruction that also depends on the outcome from the load instruction. [Item 6] 2. The processor of claim 1, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuit that allocates execution of the branch instruction to the execution circuit. [Item 7] 7. The processor of claim 6, wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the allocation stage. [Item 8] 2. The processor of claim 1, further comprising circuitry separate from an execution stage including the execution circuitry of the pipeline circuitry for performing one or more operations to determine whether the predicted path differs from the path based on the result from the load instruction. [Item 9] generating a predicted path for the branch instruction in a branch predictor circuit of the processor; a branch redirection circuit of the processor checking, for the branch instruction that depends on a result from a load instruction, whether an instruction received by a pipeline circuit of the processor, the pipeline circuit including a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions, is the load instruction; if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry checks for a writeback of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuitry; if the predicted path differs from a path based on the result from the load instruction, the branch redirection circuitry redirects the branch instruction in the pipeline circuitry to the path; if the predicted path differs from the path based on the result from the load instruction, the execution circuitry executes the branch instruction for the path based on the result from the load instruction; A method for providing the above. [Item 10] 10. The method of claim 9, wherein checking the writeback comprises checking the writeback of the result in a load value table that is separate from the final storage destination of the result. [Item 11] if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry assigns an index value of an entry in the load value table to the result of the load instruction; causing said index value to be transmitted to said pipeline circuitry as a field of said branch instruction; Item 11. The method of item 10, further comprising: [Item 12] 12. The method of claim 11, further comprising the step of: if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry updates an entry for the branch instruction in a load dependency branch table with the index value. [Item 13] 12. The method of claim 11, further comprising the step of the branch redirection circuit assigning an index value of a second branch instruction that also depends on the outcome from the load instruction. [Item 14] 10. The method of claim 9, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuit that allocates execution of the branch instruction to the execution circuit. [Item 15] 15. The method of claim 14, wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the allocation stage. [Item 16] 10. The method of claim 9, further comprising: performing one or more operations in a circuit separate from an execution stage including the execution circuit of the pipeline circuit to determine whether the predicted path differs from the path based on the result from the load instruction. [Item 17] a memory for storing branch and load instructions; a processor core coupled to the memory; Equipped with The processor core is a pipeline circuit having a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions; a branch predictor circuit for generating a predicted path for said branch instruction; a branch redirection circuit for, for the branch instruction dependent on a result from the load instruction, checking whether an instruction received by the pipeline circuit is the load instruction, and if the instruction received by the pipeline circuit is the load instruction, checking a write-back of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuit, and redirecting the branch instruction in the pipeline circuit to the path if the predicted path differs from a path based on the result from the load instruction, and causing execution of the branch instruction for the path based on the result from the load instruction; having system. [Item 18] 20. The system of claim 17, wherein the branch redirection circuitry checks the writeback of the result in a load value table that is separate from the final storage destination of the result. [Item 19] 19. The system of claim 18, wherein the branch redirection circuitry assigns an index value of an entry in the load value table to the result of the load instruction if the instruction received by the pipeline circuitry is the load instruction, and causes the index value to be transmitted to the pipeline circuitry as a field of the branch instruction. [Item 20] 20. The system of claim 19, wherein the branch redirection circuitry updates an entry for the branch instruction in a load dependency branch table with the index value if the instruction received by the pipeline circuitry is the load instruction. [Item 21] 20. The system of claim 19, wherein the branch redirection circuitry assigns an index value for a second branch instruction that also depends on the outcome from the load instruction. [Item 22] 20. The system of claim 17, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuit that allocates execution of the branch instruction to the execution circuit. [Item 23] 23. The system of claim 22, wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the assignment stage. [Item 24] 18. The system of claim 17, wherein the processor core further comprises circuitry separate from an execution stage including the execution circuitry of the pipeline circuitry for performing one or more operations to determine whether the predicted path differs from the path based on the result from the load instruction.

Claims

1. a pipeline circuit having a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions; a branch predictor circuit for generating a predicted path for a branch instruction; a branch redirection circuit for, for the branch instruction that depends on a result from a load instruction, checking whether an instruction received by the pipeline circuit is the load instruction, and if the instruction received by the pipeline circuit is the load instruction, checking a writeback of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuit, and redirecting the branch instruction in the pipeline circuit to the path if the predicted path differs from a path based on the result from the load instruction, and causing the execution of the branch instruction for the path based on the result from the load instruction; Equipped with A processor in which the branch redirection circuitry checks the writeback of the result in a load value table that is separate from the final storage destination of the result.

2. 2. The processor of claim 1, wherein the branch redirection circuitry is further configured to assign an index value of an entry in the load value table to the result of the load instruction if the instruction received by the pipeline circuitry is the load instruction, such that the index value is transmitted to the pipeline circuitry as a field of the branch instruction.

3. 3. The processor of claim 2, wherein the branch redirection circuitry updates an entry for the branch instruction in a load dependency branch table with the index value if the instruction received by the pipeline circuitry is the load instruction.

4. The processor of claim 2 , wherein the branch redirection circuitry assigns an index value for a second branch instruction that also depends on the result from the load instruction.

5. 2. The processor of claim 1, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuit that allocates execution of the branch instruction to the execution circuit.

6. The processor of claim 5 , wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the allocation stage.

7. 7. The processor of claim 1, further comprising circuitry separate from an execution stage including the execution circuitry of the pipeline circuitry for performing one or more operations to determine whether the predicted path differs from the path based on the result from the load instruction.

8. generating a predicted path for the branch instruction in a branch predictor circuit of the processor; a branch redirection circuit of the processor checking, for the branch instruction that depends on a result from a load instruction, whether an instruction received by a pipeline circuit of the processor, the pipeline circuit including a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions, is the load instruction; if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry checks for a writeback of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuitry; if the predicted path differs from a path based on the result from the load instruction, the branch redirection circuitry redirects the branch instruction in the pipeline circuitry to the path; if the predicted path differs from the path based on the result from the load instruction, the execution circuitry executes the branch instruction for the path based on the result from the load instruction; Equipped with The method, wherein the step of checking the writeback comprises checking the writeback of the result in a load value table that is separate from the final storage destination of the result.

9. if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry assigns an index value of an entry in the load value table to the result of the load instruction; causing said index value to be transmitted to said pipeline circuitry as a field of said branch instruction; The method of claim 8 further comprising:

10. 10. The method of claim 9, further comprising: if the instruction received by the pipeline circuitry is the load instruction, the branch redirection circuitry updating an entry for the branch instruction in a load dependency branch table with the index value.

11. 10. The method of claim 9, further comprising the branch redirection circuitry assigning an index value of a second branch instruction that also depends on the result from the load instruction.

12. 9. The method of claim 8, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuitry that allocates execution of the branch instruction to the execution circuitry.

13. 13. The method of claim 12, wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the allocation stage.

14. 14. The method of claim 8, further comprising: performing one or more operations in a circuit separate from an execution stage including the execution circuit of the pipeline circuit to determine whether the predicted path differs from the path based on the result from the load instruction.

15. a memory for storing branch and load instructions; a processor core coupled to the memory; Equipped with The processor core comprises: a pipeline circuit having a decoder for decoding a plurality of instructions into a plurality of decoded instructions and an execution circuit for executing the plurality of decoded instructions; a branch predictor circuit for generating a predicted path for said branch instruction; a branch redirection circuit for checking, for the branch instruction that depends on a result from the load instruction, whether an instruction received by the pipeline circuit is the load instruction, and if the instruction received by the pipeline circuit is the load instruction, checking a write-back of the result from the load instruction between the decoding of the branch instruction in the decoder and the execution of the branch instruction in the execution circuit, and if the predicted path differs from a path based on the result from the load instruction, redirecting the branch instruction in the pipeline circuit to the path, and causing the execution of the branch instruction for the path based on the result from the load instruction; having the branch redirection circuitry checks the writeback of the result in a load value table that is separate from the final storage destination of the result; system.

16. 16. The system of claim 15, wherein the branch redirection circuitry is further configured to assign an index value of an entry in the load value table to the result of the load instruction when the instruction received by the pipeline circuitry is the load instruction, such that the index value is transmitted to the pipeline circuitry as a field of the branch instruction.

17. 17. The system of claim 16, wherein the branch redirection circuitry updates an entry for the branch instruction in a load dependency branch table with the index value if the instruction received by the pipeline circuitry is the load instruction.

18. 17. The system of claim 16, wherein the branch redirection circuitry assigns an index value for a second branch instruction that also depends on the result from the load instruction.

19. 16. The system of claim 15, wherein the redirection of the branch instruction occurs in an allocation stage of the pipeline circuit that allocates execution of the branch instruction to the execution circuit.

20. 20. The system of claim 19, wherein the redirection of the branch instruction includes flushing data for the branch instruction for the predicted path from the pipeline circuitry to the assignment stage.

21. 21. The system of claim 15, wherein the processor core further comprises circuitry separate from an execution stage including the execution circuitry of the pipeline circuitry for performing one or more operations to determine whether the predicted path differs from the path based on the result from the load instruction.

Images