Processing unit, method and computer program product with loading / storage unit with subdivided reorder queues with single cam port

Abstract

A processing unit for executing one or more instructions, wherein the processing unit comprises: A load-store unit (LSU) that is trained to execute a plurality of instructions in an out-of-order (OoO) window using multiple LSU pipes by: Selecting an instruction from the OoO window, where the instruction uses a first effective address; and in response to the fact that the instruction is a loading instruction: In response to the processing unit operating in single-thread mode, an entry is created in a first subdivision of a load reorder queue based on the instruction being issued in a first load pipe, and the entry is created in a second subdivision of the load reorder queue based on the instruction being issued in a second load pipe; and In response to the fact that the processing unit operates in a multi-threaded mode, where several threads are processed simultaneously, the entry is created in a first predefined section of the first subdivision of the load reorder queue based on the fact that the instruction is issued in the first load pipe and by a first thread of the processing unit. where the LSU is trained to be: Generating a real address based on the first effective address in the instruction; In response to the detection that an Effective Real Table (ERT) does not contain an entry for the real address, insert an entry into the ERT that includes the real address and at least part of the first effective address, accessing the real address from the entry in the ERT at the time of execution of the statement; In response to the detection that the ERT already contains an entry for the real address with a second effective address: in response to the fact that a page size associated with the first effective address is larger than a page size associated with the second effective address, remove the entry for the real address with the second effective address and insert a new entry into the ERT for the first effective address; otherwise, insert an entry into a Synonym Recognition Table (SDT) that facilitates the resolution of cases where two or more different effective addresses are associated with the same real address, the entry in the SDT containing an identifier of the entry in the ERT and at least part of the first effective address.

Description

BACKGROUND

[0001] Embodiments of the present invention relate generally to a computer program product, a computer system, and a method having a load-store unit with partitioned reorder queues with a single CAM port, and more particularly to an out-of-order (OoO) processor and a load-store unit (LSU) implementing partitioned load and store reorder queues with a single content address memory (CAM) port to efficiently support out-of-order execution of instructions in the OoO processor.

[0002] In an OoO processor, an instruction sequencing unit (ISU) assigns instructions to various issue queues, renames registers to support OoO execution, dispatches instructions from the various issue queues to the execution pipelines, completes executed instructions, and handles exceptions. Register renaming is typically performed by allocation function logic in the ISU before the instructions are placed in their respective issue queues. The ISU contains one or more issue queues, which contain dependency matrices for tracking dependencies between instructions. A dependency matrix typically contains one row and one column for each instruction in the issue queue.

[0003] The publication "IBM POWER8 processor core microarchitecture" concerns the architecture and functionality of the IBM POWER8 processor (Sinharoy, B. [et al.]: IBM POWER8 processor core microarchitecture. In: IBM Journal of Research and Development, 59, 02.02.2015, 1, pp. 2:1-2:21. - ISSN 0018-8646. https: / / doi.org / 10.1147 / JRD.2014.2376112 [accessed on 16.11.2022]).

[0004] The dissertation, "Reducing Address Translation Overheads With Virtual Caching," addresses the addressing overheads of virtual memory support, specifically the overheads of virtual-to-physical address translation (i.e., performance, power consumption, and energy) via a translation lookaside buffer (TLB). To overcome these overheads, virtually indexed, virtually tagged caches are used for addressing (Yoon, Hongil: Reducing Address Translation Overheads With Virtual Caching, Thesis, March 3, 2017, pp. 1-2, 7-10, 12-13, 17-19, 22-26, 29-65, 103-104, 111-112, 115-115118). URL: https: / / pages.cs.wisc.edu / ∼ ongal / thesis / Hongil_Yoon_PhD.pdf).

[0005] The publication “Study of an In-order SMT Architecture and Grouping Schemes” refers to a simultaneous multithreading architecture that improves instruction throughput by exploiting instruction-level parallelism and thread-level parallelism (Moon, Byung-In [et.al.]: Study of an In-order SMT Architecture and Grouping Schemes. In: International Journal of Control, Automation, and Systems, 1, 01.09.2003, 3, pp. 339-350. - ISSN 2005-4092, https: / / koreascience.kr / article / JAKO200311921873731.page).

[0006] The publication "Lee, Hsien-Hsin S.; Ballapuram, Chinnakrishnan S.: Energy Efficient D-TLB and Data Cache Using Semantic-Aware Multilateral Partitioning" refers to a memory subsystem. Memory energy issues are addressed by employing an optimized architectural partitioning technique that effectively reduces energy consumption in the memory subsystem without compromising performance. This is achieved by decoupling d-TLB lookups and data cache accesses into discrete reference substreams—stack, global static, and heap—based on the semantic regions defined by programming languages ​​and software conventions. Their unique access behavior and locality properties are analyzed and exploited to reduce performance (Lee, Hsien-Hsin S.; Ballapuram, Chinnakrishnan S.: Energy Efficient D-TLB and Data Cache Using Semantic-Aware Multilateral Partitioning).In: Proceedings of the 2003 International Symposium on Low Power Electronics and Design, 25.08.2003, S. 306-311. https: / / doi.org / 10.1145 / 871506.871583).

[0007] The paper “High-Bandwidth Address Translation for Multiple-Issue Processors” refers to four alternative mechanisms for high-bandwidth address translation: nested TLBs, multi-level TLBs, piggyback ports, and pre-translation. These translation mechanisms all have latency and area characteristics that are more scalable than a simple multi-ported TLB, giving architects better design options as architectural and workload trends make it increasingly difficult to rely on a multi-ported TLB for good performance (Austin, Todd M.; Sohi, Gurindar S.: High-Bandwidth Address Translation for Multiple-Issue Processors. In: SIGARCH Comput. Archit. News, 24, 01.05.1996, 2, pp. 158-167. - ISSN 0163-5964. https: / / doi.org / 10.1145 / 232973.232990).

[0008] The publication "Lecture Notes: Out-of-Order Processors" concerns an implementation of an out-of-order processor (Balasubramonian, Rajeev: Lecture Notes: Out-of-Order Processors, CS / EE 6810 Computer Architecture, University of Utah, October 13, 2007. URL: https: / / www.cs.utah.edu / ~ rajeev / cs6810 / , Archived at http: / / www.archive.org on 10 June 2010).

[0009] The Wikipedia entry "POWER4" refers to a functional layout of the POWER4 microprocessor (POWER4. In: Wikipedia, the free encyclopedia. Edited on: June 5, 2016. URL: https: / / en.wikipedia.org / w / index.php?title=POWER4&oldid=723726144).

[0010] The publication “Content-addressable memory (CAM) circuits and architectures: a tutorial and survey” concerns an overview of CAM circuits and architectures (PAGIAMTZIS, K. ​​; SHEIKHOLESLAMI, A.: Content-addressable memory (CAM) circuits and architectures: a tutorial and survey. In: IEEE Journal of Solid-State Circuits (J-SSC), Vol. 41, 2006, No. 3, pp. 712-727. - ISSN 1558-173X (E); 0018-9200 (P). DOl: 10.1109 / JSSC.2005.864128. URL: https: / / ieeexplore.ieee.org / stamp / stamp.jsp?tp=&arnumber=1599540).

[0011] The publication "A Survey of Techniques for Architecting TLBs" provides an overview of techniques for designing and optimizing TLBs. It provides TLB terminology and background information, as well as trade-offs in TLB management. It presents studies characterizing TLB workloads, techniques for reducing TLB latency, miss rate, and power consumption, as well as virtual cache designs for reducing TLB accesses (Mittal, Sparsh: A Survey of Techniques for Architecting TLBs. In: Concurrency and Computation: Practice and Experience, 29, April 17, 2017, 10, pp. 1-23. - ISSN 1532-0634. https: / / onlinelibrary.wiley.com / doi / abs / 10.1002 / cpe.4061). SUMMARY

[0012] The invention is based on the object of creating an improved computer program product, an improved computer system, and an improved method with a load-store unit with partitioned reorder queues and a single CAM port. This object is achieved by the subject matter of the independent patent claims.

[0013] Embodiments of the present invention include methods, systems, and computer program products for implementing a load-store unit based on effective addresses in out-of-order processors. One non-limiting example of a processing unit for executing one or more instructions includes a load-store unit (LSU) that executes a plurality of instructions in an out-of-order (OoO) window using multiple LSU pipes.Execution includes selecting an instruction from the OoO window, the instruction using an effective address; and in response to the instruction being a load instruction: in response to the processing unit operating in a single-threaded mode, creating an entry in a first subdivision of a load reorder queue based on the instruction being issued in a first load pipe, and creating the entry in a second subdivision of the load reorder queue based on the instruction being issued in a second load pipe.The execution further includes, in response to the processing unit operating in a multi-threaded mode in which multiple threads are processed concurrently, creating the entry in a first predetermined portion of the first subdivision of the load reorder queue based on the instruction being issued in the first load pipe and by a first thread of the processing unit.

[0014] According to one or more embodiments, a computer-implemented method for out-of-order execution of one or more instructions by a processing unit includes receiving, by a load-store unit (LSU) of the processing unit, an out-of-order window of instructions including a plurality of instructions to be executed out of order, and issuing, by the LSU, instructions from the out-of-order window.Dispatching the instructions includes selecting an instruction from the OoO window, the instruction using an effective address; and in response to the instruction being a load instruction: in response to the processing unit operating in a single-threaded mode, creating an entry in a first subdivision of a load reorder queue based on the instruction being dispatched in a first load pipe, and creating the entry in a second subdivision of the load reorder queue based on the instruction being dispatched in a second load pipe.The execution further includes, in response to the processing unit operating in a multi-threaded mode in which multiple threads are processed concurrently, creating the entry in a first predetermined portion of the first subdivision of the load reorder queue based on the instruction being issued in the first load pipe and by a first thread of the processing unit.

[0015] According to one or more embodiments, a computer program product includes a computer-readable storage medium embodying program instructions, wherein the program instructions executable by a processing unit cause the processing unit to perform operations. The operations include receiving, by a load-store unit (LSU) of the processing unit, an out-of-order window of instructions including a plurality of instructions to be executed out of order, and issuing, by the LSU, instructions from the out-of-order window.Dispatching the instructions includes selecting an instruction from the OoO window, the instruction using an effective address; and in response to the instruction being a load instruction: in response to the processing unit operating in a single-threaded mode, creating an entry in a first subdivision of a load reorder queue based on the instruction being dispatched in a first load pipe, and creating the entry in a second subdivision of the load reorder queue based on the instruction being dispatched in a second load pipe.The execution further includes, in response to the processing unit operating in a multi-threaded mode in which multiple threads are processed concurrently, creating the entry in a first predetermined portion of the first subdivision of the load reorder queue based on the instruction being issued in the first load pipe and by a first thread of the processing unit.

[0016] Additional features and advantages are realized by the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered part of the claimed invention. For a better understanding of the invention, including its advantages and features, reference is made to the description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The specifics of the exclusive rights described herein are particularly pointed out and expressly claimed in the claims at the conclusion of the specification. The above and other features and advantages of embodiments of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: Fig. 1 illustrates a block diagram of a system including an effective address-based load-store unit in an out-of-order processor according to one or more embodiments of the present invention; Fig. 2 is an exemplary block diagram of a processor architecture of an OoO processor in which an effective address directory (EAD) and the associated mechanisms for using that EAD are implemented in accordance with one or more embodiments of the present invention; Fig. 3 illustrates a load-store unit (LSU) of a processing core according to one or more embodiments of the present invention; Fig. 4 is an exemplary block of an effective address directory (EAD) structure (L1 cache) according to an illustrative embodiment; Fig. 5 is an exemplary block of an Effective Real Implementation (ERT) table structure according to an illustrative embodiment; Fig. 6 illustrates a flowchart of an exemplary method for accessing memory to execute instructions by an LSU in accordance with one or more embodiments of the present invention; Fig. 7 illustrates a flowchart for a method for reloading the ERT according to one or more embodiments of the present invention; Fig. 8 illustrates an exemplary structure of a synonym recognition table (SDT) according to one or more embodiments of the present invention; Fig. 9 illustrates a flowchart for a method for performing an exchange of an EA in the ERT and the SDT according to one or more embodiments of the present invention; Fig. 10 illustrates an ERT Elimination (ERTE) table according to one or more embodiments of the present invention; Fig. 11 illustrates a flowchart of an exemplary method for adding entries to the ERTE table according to one or more embodiments of the present invention; Fig. 12 illustrates an exemplary flowchart for an exemplary set of instructions initiated in accordance with one or more embodiments of the present invention; Fig. 13 illustrates a flowchart of an exemplary method for issuing instructions by an LSU in a multi-pipe mode and an OoO manner depending on whether the processor is operating in single-thread (ST) mode or multi-thread (MT) mode, according to one or more embodiments of the present invention; and Fig. 14 illustrates a block diagram of a computer system for implementing some or all aspects of one or more embodiments of the present invention. DETAILED DESCRIPTION

[0018] One or more embodiments of the present invention described herein provide an effective address (EA)-based load / store unit (LSU) for an out-of-order (OoO) processor by dynamically removing entries in a table of effective and real addresses in the OoO processor. The technical solutions described herein utilize, among other components, an effective address dictionary (EAD) in conjunction with an effective-real table (ERT) and a synonym detection table (SDT) to facilitate chip area reduction and further improve scheduling of OoO processors. Furthermore, the technical solutions described herein facilitate an OoO LSU to execute load / store instructions out of order. The OoO LSU executes the load / store instructions using multiple pipes to provide improved performance.The multi-pipe implementation of the LSU relies on a partitioned ERT, a load reorder queue (LRQ), and a store reorder queue (SRQ), as described herein.

[0019] Most modern computing devices support virtual memory. Virtual memory is a technique that allows application programs to believe they have a contiguous memory or address space, even though physical memory may be fragmented and possibly even spilling onto disk. Essentially, the application program is given a view of the computing device's memory, with the application accessing seemingly contiguous memory using an effective address in the application-visible effective address space, which is then translated into a physical address of the actual physical memory or memory device(s) to actually perform the access operation.An effective address is a value used to specify a memory location to be accessed by the operation from the perspective of the entity, e.g., an application, process, thread, interrupt routine, kernel component, etc., that issues the operation.

[0020] This means that if a computing device does not support the concept of virtual memory, the effective address and the physical address are identical. However, if the computing device supports virtual memory, the effective address of the particular operation submitted by the application is translated by the computing device's memory allocation unit into a physical address that specifies the location in the physical memory or physical memory device(s) where the operation is to be performed.

[0021] Furthermore, in modern data processing units, processors of the data processing units use processor instruction pipelines, which comprise a series of data processing elements to process instructions (operations) submitted by entities, e.g., applications, processes, etc. Instruction pipelining is a technique for increasing instruction throughput by dividing the processing of computer instructions into a series of steps with a save at the end of each step. Instruction pipelining makes it easier for the control circuitry of the data processing unit to issue instructions to the processor instruction pipeline at the processing speed of the slowest step, which is significantly faster than the time required to perform all steps simultaneously. Processors with instruction pipelining, i.e.Processors set in a pipeline are internally organized into stages that can work semi-independently on separate tasks. Each stage is organized and connected to the next stage in a continuous chain, so that the output of each stage is fed to another stage until the final stage of the pipeline.

[0022] Such pipelined processors can take the form of in-order or out-of-order pipelined processors. In in-order pipelined processors, instructions are executed in order, so if no data is available for the instruction to be processed at a particular stage of the pipeline, execution of instructions through the pipeline can be delayed until the data is available. Out-of-order pipelined processors, on the other hand, allow the processor to avoid delays that occur when the data required to perform an operation is unavailable.The instruction pipeline of an out-of-order processor avoids these delays by filling "panes" with other instructions ready for processing in a timely manner and then reordering the results at the end of the pipeline to give the appearance that the instructions were processed in order. The order in which instructions are arranged in the original computer code is called program order, whereas in the processor, they are processed in data order—that is, in the order in which the data and operands become available in the processor's registers.

[0023] Modern processor instruction pipelines track an instruction's effective address as the instruction progresses through the instruction pipeline. It's important to track the instruction's effective address because this effective address is used whenever the processing of an instruction results in an exception being thrown, the instruction is flushed to a previous state, the instruction branches to a new memory location relative to its current memory location, or the instruction's execution completes.

[0024] Tracking the effective address of an instruction is expensive in terms of processor chip area, power consumption, and the like. This is because these effective addresses are large (e.g., 64 bits) and modern processor instruction pipelines are deep, i.e., have many stages, resulting in the lifetime of an instruction from an instruction fetch stage of the processor instruction pipeline to a completion stage of the processor instruction pipeline being very long. This overhead can increase further in out-of-order processors with heavy multithreading, i.e., processors that execute instructions from multiple threads out of order, since a large number of instructions from different address ranges can be processed "in flight," i.e., concurrently.

[0025] In one or more examples, data processing units use a combination of pipeline latches, a branch information queue (BIQ), and a global completion table (GCT) to track the effective address of an instruction. The effective base address (EA) for a group of instructions is transferred from the front of the pipeline using latches until it can be placed in the GCT of the instruction sequencer unit (ISU) and tracked. The number of latches required to store this data is on the order of the number of pipeline stages between a fetch stage and a dispatch stage of the pipeline. This is wasteful because the EA is typically not needed during these stages.Rather, it is simply payload data that is "carried" along with the instruction group as it flows through the pipeline. Furthermore, this approach results in duplicate storage, since branch instructions have their EAs in both the BIQ and the GCT.

[0026] Accordingly, data processing units have been developed that eliminate this inefficiency by tracking the IO exclusively in the GCT. For example, in these new data processing units, an instruction sequencer creates an entry in the GCT at fetch time. The IO is loaded into the GCT at that time and subsequently removed when the instruction completes. This eliminates numerous pipeline latches throughout the machine. Instead of a full IO as long as the number of address lines, for example, a 64-bit IO, a small tag is carried through the pipeline along with the instruction group. This tag points back to the entry in the GCT containing the base IO for that instruction group. Storing addresses in the BIQ is no longer necessary, as branches can retrieve their IOs directly from the GCT when they are issued.Such techniques improve area efficiency, but they are not applicable to an out-of-order processor. Furthermore, they lack sufficient data to handle address requests that arrive out of program order. Furthermore, these techniques cannot support the allocation and completion bandwidth required for out-of-order execution because they are unable to track instruction groups that may have been formed from multiple non-contiguous address ranges. In the past, such mechanisms have only supported instruction groups from a single address range, which can significantly reduce the number of instructions available for out-of-order execution.To search for corresponding addresses, such as an RA corresponding to an EA (or vice versa), a content-addressable memory (CAM) is used. A CAM implements a lookup table function in a single clock cycle using a dedicated comparison circuit. The overall function of a CAM is to retrieve a search word and return the corresponding memory location. However, such a CAM requires chip area and consumes power for such searches.

[0027] The illustrative embodiments of technical solutions described herein lead to improvements in these techniques by providing an effective address dictionary (EAD), an effective real table (ERT), and a synonym detection table (SDT) that have the area efficiency of the GCT solution described above, but can also support a wide-issue out-of-order pipeline without compromising performance. The technical solutions described herein further facilitate processors operating only with EAs, provided the processor can avoid EA synonyms within an out-of-order (OoO) window. The OoO window is a set of instructions in a processor's instruction pipeline.By avoiding IO synonyms in the OoO window, the processor reduces chip area and power consumption for address translation because the processor can avoid translation for IOs in the OoO window. This is because load-hit-store (LHS), store-hit-load (SHL), and load-hit-load (LHL) conditions no longer need to be detected for currently executing instructions because IO synonyms are no longer present in the OoO window.

[0028] In other words, the technical solutions described herein address the technical problem by addressing IO aliasing within the OoO window, thereby reducing translation data structures and hardware for the load / store pins. Accordingly, the technical solutions described herein facilitate a reduction in chip area by tracking only one address, the IO. Furthermore, the technical solutions facilitate the OoO processor to operate in a 2-load, 2-store mode with partitioned load-store queues, further reducing the CAM pins typically used for address translation.

[0029] Furthermore, if the OoO processor supports multi-threaded (MT) operations, the OoO processor must facilitate multiple CAM ports for each load / store queue in a load / store unit for converting IOs to RAs and vice versa for each thread operating out of order. For example, consider an OoO processor executing four threads in MT mode, where each thread executes concurrently by executing independent instructions. In this case, a load / store unit (LSU) of the OoO processor typically uses four or more CAM ports for each load / store queue for translating effective addresses to real addresses and vice versa. Such multiple CAM ports for address translation occupy significant chip area and also consume power. The technical solutions described herein address such a technical problem of multiple CAM ports for multiple threads.

[0030] One or more example embodiments of the invention described herein address aspects of the technical problems described herein using a single CAM pin for the load / store queues, thereby reducing the chip area and power consumed for address translation. For example, the example embodiments of the invention described herein may facilitate the LSU being a multi-load and multi-store LSU with partitioned load / store queues, thereby facilitating a reduction in the number of CAM pins for address translation. A 'multi-load LSU' is an LSU that issues multiple load instructions concurrently in separate pipes for each load instruction. For example, a '2-load LSU' is an LSU that issues two load instructions concurrently in two separate pipes, LD0 and LD1.Similarly, a 'multi-store LSU' is an LSU that issues multiple store instructions concurrently in separate pipes for each store instruction. For example, a '2-store LSU' is an LSU that issues two store instructions concurrently in two separate pipes, ST0 and ST1.

[0031] With reference to Fig. 1, a block diagram of a system 100 including an instruction sequencing unit (ISU) of an out-of-order (OoO) processor for implementing the technical solutions for avoiding IO synonyms in an OoO instruction window is generally shown in accordance with one or more embodiments of the present invention. Fig. The system 100 illustrated in Figure 1 includes an instruction fetch unit / instruction decode unit (IFU / IDU) 106 that fetches and decode instructions for input to a facility block 108, which prepares the decode instructions for input to a mapping function 110 of the ISU. According to one or more embodiments of the present invention, six instructions may be fetched and decoded concurrently by a thread through the IFU / IDU 106. According to one or more embodiments of the present invention, the six instructions sent to the facility block 108 may include six non-branch instructions, five non-branch instructions, and one branch instruction, or four non-branch instructions and two branch instructions.According to one or more embodiments of the present invention, the setup block 108 checks whether sufficient resources, such as entries in the issue queues, the completion table, the allocation functions, and the register files, are present before the fetched instructions are transferred to these blocks in the ISU.

[0032] The Fig. The mapping functions 110 shown in Figure 1 map programmer instructions (e.g., logical register names) to physical resources of the processor (e.g., physical register addresses). Fig. 1 illustrates a variety of mapping functions 110, including a condition register (CR) mapping function; a link / count (LNK / CNT) register (LNK / CNT) mapping function; an integer exception register (XER) mapping function; a unified mapper (UMapper) for mapping general purpose registers (GPRs) and vector scalar registers (VSRs); an architected mapper (ARCH Mapper) for mapping GPRs and VSRs; and a floating point status and control register (FPSCR) mapping function.

[0033] The output from the setup block 108 is also input to a global completion table (GCT) 112 to track all instructions currently in the ISU. The output from the setup block 108 is also input to an arbitration unit 114 to arbitrate the instructions to an issue queue. The embodiment of the Fig. The ISU shown in Figure 1 contains a CR issue queue, CR-ISQ116, which receives and tracks instructions from the CR allocation function and issues them to the instruction fetch unit (IFU) 124 to execute logical CR instructions and move instructions. Furthermore, Fig. 1 illustrates a branch issue queue, Branch ISQ 118, that receives and tracks branch instructions and physical LNK / CNT addresses from the LNK / CNT mapping function. Branch ISQ 118 may issue an instruction to IFU 124 to redirect instruction fetch if a predicted branch address and / or direction was incorrect.

[0034] Instructions issued by the arbitration logic and renamed registers from the LNK / CNT mapper function, the XER mapper function, the UMapper (GPR / VSR), the ARCH mapper function (GPR / VSR), and the FPSCR mapper function are input to the issue queue 102. As in Fig. 1, the issue queue 102 tracks dispatched fixed-point instructions (Fx), load instructions (L), store instructions (S), and instructions for the vector and counter unit (VSU). As in the embodiment of Fig. As shown in Figure 1, the issue queue 102 is divided into two parts, ISQ0 1020 and ISQ1 1021, with each section containing N / 2 instructions. When the processor is running in single-threaded (ST) mode, the issue queue 102 can be used as a single logical issue queue containing both ISQ0 1020 and ISQ1 1021 to process all instructions (in this example, all N instructions) of a single thread.

[0035] When the processor is running in multi-threaded (MT) mode, ISQ0 1020 can be used to process N / 2 instructions from a first thread, and ISQ1 1021 is used to process N / 2 instructions from a second thread ISQ1 1021.

[0036] As in Fig. 1, the issue queue 102 issues instructions to the execution units 104, which are divided into two groups of execution units, 1040 and 1041. Both groups of execution units, 1040 and 1041, which are shown in Fig. 1, include a full fixed-point execution unit (full FX0, full FX1); a load execution unit (LU0, LU1); a simple fixed-point, data memory, and address storage execution unit (simple FX0 / STD0 / STA0, simple FX1 / STD1 / STA1); and a floating-point, vector multimedia extension, decimal floating-point, and data memory execution unit (FP / VMX / DFP / STD0, FP / VMX / DFP / STD1). Together, LU0, simple FX0 / STD0 / STA0, and FP / VMX / DFP / STD0 form a load-store unit (LSU) 1042. Similarly, the LU1, the single FX1 / STD1 / STA1, and the FP / VMX / DFP / STD1 form a load-store unit (LSU) 1043. The two LSUs 1042 and 1043 are collectively referred to as the LSU of the system 100.

[0037] As in Fig. 1, when the processor is executing in ST mode, the first group of execution units 1040 executes instructions issued by ISQ0 1020, and the second group of execution units 1041 executes instructions issued by ISQ1 1021. In alternative embodiments of the present invention, when the processor is executing in ST mode, instructions issued by both ISQ0 1020 and ISQ1 1021 in issue queue 102 may be issued to execution units in any of the execution units 1040 in the first group of execution units 1040 and the second group of execution units 1041.

[0038] According to one or more embodiments of the present invention, when the processor is executing in MT mode, the first group of execution units 1040 executes instructions of the first thread issued by the ISQ0 1020, and the second group of execution units 1041 executes instructions of the second thread issued by the ISQ1 1021.

[0039] The number of entries in the output queue 102 and sizes of other elements (e.g. bus widths, queue sizes) that are in Fig. 1 are intended to be exemplary, as embodiments of the present invention may be implemented for output queues and other elements of a variety of different sizes. According to one or more embodiments of the present invention, the sizes are selectable or programmable.

[0040] In one or more examples, the system 100 according to the illustrative embodiments is an OoO processor. Fig. 2 is an exemplary block diagram of a processor architecture of an OoO processor in which an effective address directory (EAD) and the associated mechanisms for using this EAD are implemented in accordance with one or more embodiments of the present invention. As shown in Fig. 2, the processor architecture includes an instruction cache 202, an instruction fetch buffer 204, an instruction decryption unit 206, and an instruction dispatch unit 208. Instructions are fetched from the instruction cache 202 by the instruction fetch buffer 204 and provided to the instruction decryption unit 206. The instruction decryption unit 206 decrypts the instruction and provides the decrypted instruction to the instruction dispatch unit 208. The output of the instruction dispatch unit 208 is provided to the global completion table 210 and, depending on the instruction type, to one or more of the branch issue queue 212, the condition register issue queue 214, the unified issue queue 216, the load reorder queue 218, and / or the store reorder queue 220. The instruction type is determined by decrypting and mapping the instruction decryption unit 206.The issue queues 212 through 220 provide inputs to various execution units 222 through 240. The data cache 250 and the register files contained in each respective unit provide the data for use with the instructions.

[0041] Instruction cache 202 receives instructions from L2 cache 260 via second-level translation unit 262 and a pre-decryption unit 270. Second-level translation unit 262 uses its associated segment translation buffer 264 and address translation buffer 266 to translate addresses of the fetched instruction from effective addresses to system memory addresses. The pre-decryption unit partially decrypts instructions arriving from the L2 cache and augments them with unique identifiers that simplify the work of downstream instruction decryption devices.

[0042] The instructions fetched into the instruction fetch buffer 204 are also provided to the branch prediction unit 280 if the instruction is a branch instruction. The branch prediction unit 280 includes a branch history table 282, a return stack 284, and a counter cache 286. These elements predict the next effective address (EA) to be fetched from the instruction cache. A branch instruction is a location in a computer program where the flow of control changes. This is the low-level machine instruction generated from control constructs in a computer program, such as if-then-else or do-while statements.A branch may not be taken where the flow of control remains unchanged and the next instruction to be executed is the immediately following instruction in memory, or it may be taken where the next instruction to be executed is an instruction at a different location in memory. When the branch is taken, a new IO must be provided to the instruction cache.

[0043] The EA and associated prediction data from the branch prediction unit are written to a directory 290 of effective addresses. This EA is subsequently validated by the branch execution unit 222. If it is correct, the EA remains in the directory until all instructions from that address range have completed execution. If it is incorrect, the branch execution unit deletes the address, and the corrected address is written in its place. The EAD 290 also includes a logic unit that facilitates the use of the directory as a CAM.

[0044] Instructions that read from or write to memory (such as load or store instructions) are issued to the LS / EX execution unit 238, 240. The LS / EX execution unit fetches data from the data cache 250 using a memory address specified by the instruction. This address is an effective address and must first be translated to a system memory address by the second-level translation unit before it is used. If no address is found in the data cache, the load miss queue is used to manage the miss request to the L2 cache. To reduce the penalty for such cache misses, the enhanced data prefetching engine predicts the addresses likely to be used by instructions in the near future.This way, data is likely already in the data cache when an instruction needs it, preventing a long-latency miss request to the L2 cache.

[0045] The LS / EX execution unit 238, 240 executes instructions out of program order by tracking instruction age and memory dependencies in the load reorder queue 218 and the store reorder queue 220. These queues are used to detect when out-of-order execution has produced a result that is inconsistent with the in-order execution of the same program. In such cases, the current program flow is discarded and reexecuted.

[0046] The processor architecture further includes the effective address directory (EAD) 290, which centrally manages the effective address of a group of instructions so that the effective address is available when needed but does not need to be passed through the pipeline. Furthermore, the EAD 290 includes circuitry and / or logic to support out-of-order processing. Fig. 2 illustrates the EAD 290 accessed via the branch prediction unit 280, however, it should be understood that circuitry may be provided to allow various of the Fig. 2 access the EAD 290 without having to go through the branch prediction unit 280.

[0047] Experts can see that the hardware in Fig. 1 to 2 may vary depending on the implementation. Other internal hardware or peripheral devices such as flash memory, equivalent non-volatile memory, or optical disk drives and the like may be used in addition to or instead of the Fig. 1 to 2. Furthermore, the processes of the illustrative embodiments may be applied to a multiprocessor data processing system other than the aforementioned SMP system without departing from the spirit and scope of the present invention.

[0048] Furthermore, the data processing system 100 may take the form of any of a number of different data processing systems, including client computing devices, server computing devices, a tablet computer, a laptop computer, a telephone or other data transmission device, a personal digital assistant (PDA), or the like. In some illustrative examples, the data processing system 100 may be a portable computing device configured with flash memory to provide non-volatile memory for storing, for example, operating system files and / or user-generated data. In essence, the data processing system 100 may be any known or later developed data processing system without architectural limitation.

[0049] As will be appreciated by one skilled in the art, the present invention may be embodied as a system, apparatus, or method. In one illustrative embodiment, the mechanisms are provided entirely in hardware, e.g., in circuits, hardware modules or units, etc. of a processor. However, in other illustrative embodiments, a combination of software and hardware may be used to provide or implement the features and mechanisms of the illustrative embodiments. The software may be provided, for example, in firmware, resident software, microcode, or the like. The various flowcharts set forth below provide an overview of operations that may be performed by this hardware and / or this combination of hardware and software.

[0050] In illustrative embodiments in which the mechanisms of the illustrative embodiments are implemented at least in part in software, any combination of one or more computer-usable or computer-readable media may be used to store this software. The computer-usable or computer-readable medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include: random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM, or Flash memory), etc.

[0051] Typically, for each load and store instruction, an EA is converted to a corresponding RA. Such a conversion of an EA to an RA is also performed for an instruction fetch (I-fetch). Such a conversion typically required an effective-to-real address table (ERAT) for fetching instructions from lower-order memory. In the technical solutions described herein, the conversion of an EA to an RA is not performed for each load and store instruction, but only in the case of load misses, I-fetch misses, and all stores.

[0052] By using only EA for operations, the technical solutions facilitate the removal of RA bits (e.g., bits 8 through 51) from one or more data structures such as an EA directory (also known as the L1 directory), LRQF entries, and LMQ entries. Furthermore, no SRQ-LHS RA comparison logic is executed when only EA is used. Removing such elements reduces the chip area of ​​the processor used, thereby facilitating a reduction in chip area compared to typical processors.

[0053] By using only EA, the technical solutions herein eliminate ERAT camming operations during each load and store address generation. The technical solutions further eliminate RA bus switching throughout the unit and avoid fast SRQ LHS RA camming. The technical solutions thus facilitate the processor's ability to consume less power compared to typical processors by eliminating the above operations.

[0054] Even further, the technical solutions herein also facilitate improvements in L1 latency. For example, by eliminating address conversions, the technical solutions herein are at least 1 cycle faster in determining a "final Dval" compared to typical processors that perform EA-to-RA conversions. Latency is further improved because using only EA (without RA conversion) eliminates "bad Dval" conditions such as multiple facility table hits, facility table hits / RA misses, and the like. Similarly, the technical solutions herein facilitate improvements in L2 latency.

[0055] Technical challenges associated with using a single EA-based LSU include the ability to process L2 snoops. For example, the LSU must be capable of reverse RA-to-EA conversion. Accordingly, the technical solutions herein facilitate converting an L2 RA-based snoop into an EA-based snoop for the LSU subunits.

[0056] Furthermore, the EA-only LSU has a technical problem of processing matching thread synonyms (i.e., two different EAs from a thread are mapped to the same RA). Technical solutions address such technical problems using either a synonym detection table (SDT) or an ERT elimination (ERTE) table, as described herein. For example, L1 accesses across LHS, SHL, and LHL, where a synonym is defined as follows: Tid=w,EA(0:51)=×=>RA(8:51)=z; Tid = w, EA (0 to 51) = y => RA(8 to 51) = z. In this way, different EAs correspond to the same RA. The technical solutions described herein facilitate the rejection of synonymous EAs and a restart with a corresponding primary EA.

[0057] Referring again to the figures, Fig. 3 illustrates a load-store unit (LSU) 104 of a processing core according to one or more embodiments of the present invention. The illustrated LSU 104 facilitates execution in a 2-load-2-store mode; however, it should be noted that the technical solutions described herein are not limited to such an LSU. The execution flow for the LSU is described below. From the load or store instructions, the EA (the effective address as used by the programmer in a computer program) is generated. Similarly, an EA is also generated for an instruction fetch. Among other technical issues, the EA for each instruction was typically converted to an RA (a real address as used by the hardware after an EA-to-RA translation), requiring larger chip area and frequent translations.The technical solutions described herein address such technical problems by using only the EA (without conversion to an RA) and using an Effective Real Table (ERT) 255 to generate the RA only in the case of load errors, I-fetch errors, and stores.

[0058] The LSU 104 contains a load reorder queue (LRQF) 218, in which all load operations are tracked from dispatch to completion, similar to an LRQ 218 in typical LSU designs. The LSU 104 further contains a second load reorder queue, LRQE 225. When a load is rejected (due to a cache miss or translation miss, or if a previous instruction on which it depends was rejected), the load is removed from the issue queue and placed in an LRQE entry for reissue. The illustrated LRQE 225 is divided into two instances, LRQEO and LRQE1 for two-load mode, each with 12 entries (24 entries total). In ST mode, there is no division based on threads / pipes. In MT mode, T0 and T2 operations were started on pipe LD0; and T1, T3 operations were started for a restart in pipe LD1.Here, Tx stands for thread-x, for example, To stands for thread-0, T1 for thread-1, T2 for thread-2, and T3 for thread-3. Note that although the examples herein use four threads in MT mode, in other examples, MT mode may include executing a different number of threads simultaneously, for example, 8, 16, or any other number. In one or more examples, the number of threads in MT mode is configurable. Furthermore, in the examples herein, the LSU 104 uses two load pipes LD0 and LD1, but in other examples, the number of pipes may be different, for example, 3, 4, 8, etc. In one or more examples, the LRQF 218 is divided into as many subdivisions as the number of pipes.

[0059] As shown, the LRQF 218 is divided into two instances, LRQF0 and LRQF1, for dual-load mode, each with 40 entries (each instance). The LRQF 218 is circular with respect to entry allocation order, circular with respect to entry cleanup order, and circular with respect to entry deallocation order. Furthermore, in MT mode, T0 and T2 operations were initiated in pipes LD0 and ST0; and T1 and T3 operations were initiated in pipes LD1 and ST1. In ST mode, the LRQF has no pipes / threads.

[0060] In one or more examples, the LRQF 218 (and other structures described herein) for SMT4 mode is divided into T0: LRQF0[0 to 19] recirculating queue, T1: LRQF1[0 to 19] recirculating queue; and T2: LRQF0[20 to 39] recirculating queue, T3: LRQF1[20 to 39] recirculating queue.

[0061] In one or more examples, the LRQF 218 (and other structures described herein) for SMT2 mode is divided into T: LRQF0[0 to 39] circular queue, T1: LRQF1[0 to 39] circular queue. Further, in one or more examples for ST mode, into an LRQF0[0 to 39] circular queue, where LRQF1 is a copy of the LRQF0. A similar subdivision pattern is used for other data structures, with the second instance being a copy of the first instance in ST mode.

[0062] During a cross invalidation flush (XI flush), for the LRQF, NTC+1 flushes any thread encountered by an XI or garbage collection from another thread, so that during XI flush by the LSU 104, no explicit flushes are performed in L / L order during synchronizations.

[0063] All stores are checked against LRQF 218 for SHL detection, after which LRQF 218 initiates a flush of any load or all operations (any instructions / operations) after the store. DCB instructions are also checked against LRQF 218 for SHL cases, after which LRQF 218 flushes the load or all operations after the DCB. All loads are also checked against LRQF 218 for LHL (sequential load consistency) detection, after which LRQF 218 flushes the newer load or all operations after the older load. In one or more examples, LRQF 218 provides quad-word atomicity, and LQ compares LRQF 218 for quad-word atomicity and flushes the LQ if it is not atomic.In the case of LARX instructions, the LSU 104 checks for Larx-Hit-Larx cases using LRQF 218 and, in response, deletes newer LARX or everything after the older LARX instruction.

[0064] In this way, the LRQF 218 facilitates tracking all load operations from issue to completion. Entries in the LRQF 218 are indexed using Real_Ltag (rltag), which is the physical position in the queue structure. The age of a load operation / entry in the LRQF 218 is determined using an in-order Virtual_Ltag (vltag). The LRQF deletes a load using GMASK and performs a subset delete using GTAG and IMASK. The LRQF logic can delete from a current iTag or iTag+1, or precisely load an iTag.

[0065] Furthermore, the LRQF does not contain the typically used RA field (8 to 51) and instead relies on an EA and contains an ERT ID (0 to 6) and an EA (40 to 51) (a saving of 24 bits). LRQF page matching with respect to SHL and LHL is based on an ERT ID match. Furthermore, each LRQ entry has a Force Page Match bit. If an ERT ID that matches the LRQ entry's ERT ID is invalidated, the Force Page Match bit is set. The LRQ detects LHL, SHL, and in-memory-order erasures that accompany any entry with Force Match=1.

[0066] In this way, the LRQF 218 addresses the technical problem of multiple CAM pins occupying chip area and consuming power for address translation by maintaining a partitioned load request queue that is partitioned for a given number of instructions and a given number of threads that the OoO processor can execute simultaneously.

[0067] The SRQ 220 of the LSU 104 has a similar structure to the LRQF 218, with two instances SRQRO and SRQR1 of 40 entries (in each instance) that are circular with respect to entry allocation order, circular with respect to entry scavenging order, and circular with respect to entry deallocation order. Furthermore, the SRQ 220 is partitioned similarly to the LRQ 218, for example, into T0, T2 operations started in pipes LD0, ST0; T1, T3 operations started in pipes LD1, ST1; and no pipe / thread partitioning in ST mode. In ST mode, both copies have matching values, whereas the copies in MT modes are different. In SMT4 mode, both instances are further partitioned, with each thread being allocated 20 entries from the SRQ 220 (see an example partition for the LRQF described herein).In one or more examples, intra-SRQ read pointer multiplexing is performed for memory flush arbitration in SMT4 mode. Alternatively or additionally, inter-SRQ0 / 1 multiplexing is performed in SMT2 and SMT4 modes. In ST mode, flushing is performed only on SRQ0.

[0068] Here, Tx stands for thread-x, for example, To stands for thread-0, T1 for thread-1, T2 for thread-2, and T3 for thread-3. Note that although the examples herein use four threads in MT mode, in other examples, MT mode may include executing a different number of threads simultaneously, for example, 8, 16, or any other number. In one or more examples, the number of threads in MT mode is configurable. Furthermore, in the examples herein, the LSU 104 uses two memory pipes ST0 and ST1, but in other examples, the number of memory pipes may be different, for example, 3, 4, 8, etc. In one or more examples, the SRQR 220 is divided into as many subdivisions as the number of pipes.

[0069] Each SRQ 220 entry contains a store TID (0 to 1), an ERT ID (0 to 6), an EA (44 to 63), and an RA (8 to 51). To detect an LHS, the LSU uses the {store TID, EA (44 to 63)}, which eliminates the RA-LHS alias check. The ERT ID is used to "catch" a false guess of an EA (44 to 63) partial match. The SRQ entry has the RA (8 to 51), which is enforced at Store Agen and is only used when store requests are sent to the L2 (store instruction cleaned up, not issued). Each SRQ entry also has a "Force Page Match" bit. The Force Page Match bit is set when an ERT ID that matches the SRQ entry's ERT ID is invalidated. The SRQ can detect an LHS associated with any entry with Force Page Match=1. For example, an LHS on an entry with Force Page Match=1 causes the load instruction to be rejected.Furthermore, garbage collection forces a miss in the L1 cache if the SRQ entry has Force Page Match=1. This works in conjunction with extended store hit reload LMQ operations.

[0070] For example, for an LMQ, a match of LMQ address match = {ERT ID, EA page offset(xx to 51), EA(52 to 56)} exists. Furthermore, a "Force Page Match" bit of each LMQ entry is set (=1) if an ERT ID is invalidated that matches the ERT ID of the LMQ entry. The LMQ rejects a load error if there is a valid LMQEntry[x]ForcePageMatch=1 and an LdError EA[52 to 56] = LMQEntry[X]EA(52 to 56). Furthermore, the LMQ has an extended store hit reload. For example, the LMQ suppresses reload activation if Reload EA(52 to 56) = SRQEntry[X] EA(52 to 56) and SRQEntry[X]ForcePageMatch=1. Alternatively, or in addition, the LMQ suppresses reload activation if LMQEntry[X]EA(52 to 56) = StDrain EA(52 to 56) and StDrainForcePageMatch=1.

[0071] The illustrated LSU 104 compresses a Store Data Queue (SDQ) as part of the SRQ 220 itself to further save chip area. The operands are stored in an entry of the SRQ itself if the operand size is smaller than the SRQ entry size, for example, 8 bytes. For wider operands, such as vector operands that are 16 bytes wide, the SRQ stores the operands using two consecutive entries in the SRQ 220 in MT mode. In ST mode, the wider operands are stored in the SRQ0 and SRQ1, for example, 8 bytes each.

[0072] The SRQ 220 queues store, block, DCB, ICBI, or TLB operations. A single s tag is used for both store_agen and store_data. The SRQ 220 handles load-hit-store (LHS) cases (same thread only). For example, all issued loads are checked by the SRQ 220 to ensure that no older stores with a data conflict exist. For example, the data conflict is detected by comparing flags for load IO and data bytes with older stores in the SRQ IO array.

[0073] SRQ entries are allocated at allocation, with the allocated instruction tags (itags) being placed in the correct row. Furthermore, SRQ entries are freed during garbage collection. In one or more examples, the Itag arrays contain "overflow" allocations. For example, data is written to the Itag array at allocation if the desired row in the SRQ, e.g., SRQ entry x, is still in use. When SRQ entry x is freed, its corresponding row in the SRQ overflow Itag structure is read and copied into the main SRQ Itag array structure (reading the overflow Itag structure is controlled by whether valid entries exist in the overflow Itag array for a given thread / scope).The main SRQ 0 / 1 Itag array is processed through the CAM pins (or, in SMT4, a 1 / 2 camming operation is performed) to determine which physical row to write to when a store is issued, so that the ISU issues stores based on the Itag. The SRQ 220 sends the Itag to the ISU when a store is cleared and released.

[0074] Fig. 4 is an example block of an effective address directory (EAD) structure (L1 cache) 290 according to an illustrative embodiment. In one or more examples, the EAD is a portion of the LSU 104. As shown in Fig. 3, the EAD 290 consists of one or more entries, e.g., entry 0 through entry N, where each entry includes a plurality of fields with data relating to a group of one or more instructions. For example, in one illustrative embodiment, each entry in the EAD 290 may represent between 1 and 32 instructions. Entries in the EAD 290 are generated in response to an instruction fetch located in a new cache line of the processor cache, e.g., the L2 cache 260 in Fig. 2. The entry in EAD 290 is updated when additional instructions are fetched from the cache line. Each EAD 290 entry is terminated upon a chosen branch (i.e., a branch instruction fetched from the cache is resolved as "chosen"), a cache line traversal (i.e., the next fetched instruction is in a different cache line than the current cache line), or a processor pipeline flush (e.g., when a branch misprediction or the like occurs).

[0075] As in Fig. 3, the entry fields in EAD 290 include an effective base address 310, a first instruction identifier 320, a last instruction identifier 330, a closed identifier 340, a global history vector field 350, a link stack pointer field 360, a selected branch identifier 370, and a branch data field 380. EAD 290 is organized like an L1 data cache. An associative organization is specified. For example, in one or more examples, there are 32 indexes addressed in 8 ways by an EA(52 through 56) selected by EA(0 through 51).

[0076] The effective base address 310 is the effective starting address (EA) of the group of instructions. Each instruction in the group of instructions has the same base EA and then an offset from it. For example, in one illustrative embodiment, the EA is a 64-bit address comprising bits 0 through 63. The base EA, in one illustrative embodiment, may include bits 0 through 56 of that EA, with bits 57 through 61 representing the offset from the base EA for the specific instruction within the group of instructions. Bits 62 and 63 point to a specific byte of each instruction. In the illustrative embodiment, each address points to a 32-bit (i.e., 4 bytes) long instruction, where each byte is addressable in memory.An instruction cannot be further divided into addressable subcomponents, and therefore, for an instruction address, bits 62 and 63 are always set to zero. Therefore, bits 62 and 63 do not need to be stored and can always be assumed to be zero by the EAD.

[0077] The first instruction tag field 320 stores the effective address offset bits, e.g., bits 57 through 61 of the EA, for the first instruction in the group of instructions to which the entry in the EAD 290 corresponds. A combination of the base EA from field 310 and the effective address offset bits in the first instruction tag field 320 provides the EA for the first instruction in the group of instructions represented by the entry in the EAD 290. This first field 320 may be used, as discussed below, to restore a refetch address and branch prediction data, for example, in the event that the pipeline is erased.

[0078] The last instruction tag field 330 stores the effective address offset bits, e.g., bits 57 through 61 of the EA, for the last instruction in the group of instructions to which the entry in EAD 290 corresponds. EAD logic updates this field when additional instructions in the group of instructions represented by the entry in EAD 290 are fetched. The EAD logic stops updating this field 330 in the respective entry in EAD 290 in response to the entry in EAD 290 being closed when a cache line overrun or a branch taken is detected. This field is retained unless a pipeline flush occurs that removes a portion of the EAD entry. In such cases, the EAD logic updates this field to store the offset bits of the effective address of the instruction that is now the new last instruction in the entry as a result of the deletion.This field is ultimately used for closing, as discussed below, to release the entry in the EAD 290.

[0079] The closed flag field 340 is used to indicate that the entry in the EAD 290 has been closed and no further instruction fetches will be performed to fetch instructions for the instruction group corresponding to the entry in the EAD 290. An entry in the EAD 290 may be closed for a variety of different reasons, including a cache line exceedance, a branch taken, or a pipeline flush. Any of these conditions may result in the value in the closed field 340 being set to indicate that the EAD entry is closed, e.g., set to a value of "1." This field 340 is used at close to release an entry in the EAD 290, as discussed in more detail below.

[0080] The global history vector field 350 identifies the global history vector for the first instruction fetch group that created the entry in the EAD 290. The global history vector is used to identify a history with respect to whether branches have been taken, as discussed in more detail below. The global history vector is used for branch prediction purposes to determine whether a current branch is likely to be taken based on the recent history of taken or untaken branches.

[0081] The link stack pointer field 360 identifies the link stack pointer for the first instruction fetch group that created the entry in the EAD 290. The link stack pointer is another branch prediction mechanism, which is described in more detail below.

[0082] The chosen branch field 370 indicates whether the group of instructions corresponding to the entry in the EAD 290 included a branch instruction in which the branch was taken. The value in the chosen branch field 370 is updated in response to a branch instruction of the instruction group represented by the entry in the EAD 290 being predicted to be taken. In addition, after a branch is taken among the instructions of the entry in the EAD 290, the entry in the EAD 290 is also closed by writing the corresponding value to the closed field 340. Because the chosen branch field is speculatively written at the time of prediction, it may need to be replaced with the correct value when the branch is actually executed.For example, a branch might be predicted as not being taken, in which case a "0" would be written to the branch chosen field. However, later in execution, it might turn out that the branch was taken, in which case the field must be corrected by writing a value of "1" to it. The second write operation only occurs if the branch was incorrectly predicted.

[0083] The branch data field 380 stores various branch data used to update branch prediction structures when a branch is resolved or structured IO state when a branch instruction completes.

[0084] The ERT_ID field 385 stores an index in the ERT table (described in more detail) that identifies a corresponding ERT entry. When an ERT entry is invalidated, the associated ERT_ID is invalidated, and all associated entries in the L1 cache and L1 D-cache are also invalidated.

[0085] Entries in the EAD 290 are accessed using an effective address tag (eatag), which includes at least two parts: a base eatag and an eatag offset. In one illustrative embodiment, this eatag is a 10-bit value that is relatively much smaller than the 64-bit effective address. With a 10-bit eatag value and an EAD 290 with a size of 14 entries, in one exemplary implementation, the eatag consists of a first 5 bits, referred to as the base eatag, to identify an entry within the EAD 290, and a second 5 bits, referred to as the eatag offset, to provide the offset of the specific instruction within the group of instructions represented by the entry in the EAD 290.A first bit in the 5 bits that identify the entry within the EAD 290 can be used as a wrap bit to indicate whether a wrap-around from the top entry to the bottom entry of the EAD 290 has occurred. This can be used for age detection. The second through fifth bits of the 5 bits that identify the entry in the EAD 290 can be used for indexing in the EAD to identify the base EA of the instruction, i.e., EA(0 through 56). The 5-bit offset value can be used to provide, for example, bits 57 through 61 of the effective address of the respective instruction. This example EA tag is illustrated below. eatag(0 to 9)=Line(0 to 4)IIOffset(0 to 4) Line(0): Wrap bit for the EAD, indicating whether a wrap-around from the top entry to the bottom entry of the EAD has occurred. Line(1 to 4): Index in the 14-entry EAD is used to determine the EA(0 to 56) of the instruction. Offset(0 to 4): Bits 57 to 61 of the instruction EA.

[0086] Fig. 5 illustrates an exemplary structure of an Effective Real Table (ERT) according to one or more embodiments of the present invention. In one or more examples, the ERT 255 includes 128 entries in total, however, it should be noted that the total number of entries may vary in other examples, and further, that the number of entries may be selectable or programmable. If the LSU 104 uses multiple pipes, each pipe further has a separate subdivision in the ERT 255. In one or more examples, the predetermined

[0087] Maximum number of entries in the ERT 255 divided equally among the pipes. For example, in the case of two pipes (i.e., two instructions executed separately in parallel), the LSU manages two subdivisions of the ERT 255, each with 64 (half) entries, for example, one ERT0 and one ERT1. For example, LD0 and ST0 use ERT0, and LD1 and ST1 use ERT1. In ST mode, a first subdivision of the ERT 255 is used, the other being a copy of the first subdivision, for example, ERT0 is used with ERT1, a copy of ERT0. Alternatively, in one or more examples, the entire ERT 255 is used as a single subdivision when the LSU uses a single load pipe and a single store pipe. In the following description, an arbitrary subdivision of the ERT 255 is described unless otherwise noted.

[0088] The ERT 255 contains one valid ERT entry, which is generally present for each page active in the L1 I-cache or D-cache directory (EAD 290), or one SRQ entry, one LRQF entry, or one LMQ entry. In other words, the ERT 255 is a table of all active RPNs in the LSU and IFU (L1-DC, SRQ, LRQE, LRQF, LMQ, IC). In one or more examples, when the processor 106 is operating in ST mode, all entries in the ERT 255 are used for the single thread being executed. Alternatively, in one or more examples, the entries in the ERT 255 are divided into sets, and in ST mode, each set has the same contents. For example, if the ERT 255 has a total of 128 entries and supports a maximum of two threads, when the processor is operating in ST mode, the ERT 255 contains two sets of 64 entries each, and the two sets have the same content.

[0089] When processor 106 operates in MT mode, the ERT entries are divided alternatively among the executing threads. For example, in the case of two threads, the ERT entries are divided into two equal sets: a first set of entries associated with a first thread and a second set of entries associated with a second thread. For example, 1 copy for LD0 pipe L1 misses, ST0 pipe starts, T0 / T2 I-fetches: ERT0, which processes T0 in SMT2 mode and T0 / T2 in SMT4 mode; and 1 copy for LD1 pipe L1 misses, ST1 pipe starts, T1 / T3 I-fetches: ERT1, which processes T1 in SMT2 mode and T1 / T3 in SMT4 mode.

[0090] In one or more examples, each ERT entry contains at least the following ERT fields: ERT_ID (0 to 6), Tid_en (0 to 1), PageSize (0 to 1), EA (0 to 51), and RA (8 to 51). The ERT_ID field is a unique index for each ERT entry. For example, the ERT_ID may contain a sequential number that identifies the ERT entry. The ERT_ID is stored in the ERT_ID field 285 of the EAD 290 and other data structures used by the LSU. The TID_en field indicates whether the entry is enabled for use in MT mode and, in one or more examples, indicates the thread identifier of the instruction that uses the ERT entry. Furthermore, the PageSize indicates the memory page size to which the ERT entry refers. The RA contains a real address associated with the ERT entry.

[0091] The LSU only refers to the ERT 255 when the RA is to be used to complete instruction execution. As described herein, the ERT 255 is used by the LSU for the following four functions: 1. Ifetch, load, or store misses in the L1 cache; 2. Stores from another thread within the core; 3. Snoop operations (XI) from another core; and 4. TLB and SLB invalidation.

[0092] In the first case of an ifetch, load, or store miss in the L1 cache, the EA and thread_id are used to index into the ERT 255, and the RA from the corresponding ERT entry is sent to the L2 cache if a valid ERT entry exists. In the case of an ERT miss, that is, if no valid ERT entry exists for the EA and thread_id, the SLB / TLB is used.

[0093] In the second case, where a store is being plucked from the SRQ by another thread within the core, a store plucked from the SRQ checks the ERT 255 and the ERTE table (described in more detail) for a match from another thread. If there is no match from another thread, there is no load from another thread using the same RA. If there is a match from another thread using the same RA, the LSU checks the LRQ. Although rare, a match from another thread occurs when the RA is being used by one or more other threads. Accordingly, the LSU searches the ERT table 400 to find the relevant EA(s) for the shared RA. The EA(s) are then used to search the LRQ for a match (rejecting all store outputs this cycle).The LRQ is divided per thread, so the LSU only examines the LRQ of the relevant thread. If a corresponding load(s) is / are present in the LRQ, the LSU deletes the oldest of the corresponding load(s).

[0094] In the third case of a snoop from another core of the processor, the LSU operates similarly to the second case and checks for a hit from one of the other executing threads. If the TLB / SLB is invalidated, the ERT 255 is also invalidated.

[0095] Fig. 6 illustrates a flowchart of an example method for accessing memory to execute instructions by an LSU, in accordance with one or more embodiments of the present invention. The instruction may be a load, a store, or an instruction fetch for the OoO processor 106. Upon receiving the instruction, the LSU uses parameters of the instruction to check whether the EAD 290 has an entry corresponding to the instruction, as shown at 505 and 510. In one or more examples, the parameters used for checking include, among others, a thread identifier, a page size, an EA.

[0096] When an EAD hit occurs in the LSU in the EAD 290, that is, the instruction's EA matches an entry in the EAD table 300, the LSU reads the contents of the matching EAD entry to determine a corresponding ERT entry, as shown at 520. Each EAD entry contains the ERT_ID field 285 (0 through 6). As previously described, when an ERT entry is invalidated, the associated ERT_ID is invalidated, which also invalidates all associated entries in the EAD table 300. Accordingly, an EAD hit implies an ERT hit, since the ERT_ID field 285 is used to locate an ERT entry for the load / store instruction. Accordingly, in the case of an EAD hit, after identifying the corresponding EAD entry, the LSU reads the ERT_ID from the EAD entry and sends it to the SRQ, LMQ, and / or LRQF, as shown in 530. The SRQ, LMQ, and / or LRQF use the EA from the detected EAD entry.For memory instructions that use an RA, the RA is read from the ERT entry for an L2 access, as shown in 540 and 545. Therefore, the core implementing the technical solutions herein is referred to as an EA-only core, since the RA is not used anywhere except in the memory instructions.

[0097] The following considers the case where the instruction does not hit the EAD 290, that is, the instruction's EA does not have a corresponding entry in the EAD table 300. The thread_id and the EA are compared with each entry from the ERT 255, as shown in 550. If there is an ERT hit, that is, an ERT entry matches the parameters, the LSU reads the RA (8 to 51) from the ERT entry, as shown in 555 and 530. For load requests, the LSU sends the RA to the L2 cache for access 530. For store instructions, the LSU stores the RA in the SRQ and then sends the RA to the L2 cache when the store to the L2 cache is flushed, as shown in 540 to 545.

[0098] If an ERT error occurs, the LSU initiates a reload for the ERT 255, as shown in steps 555 and 560. Furthermore, an ERT entry swap is initiated. ERT entry swapping relies on the LRU, and the LSU ensures that synonyms within the out-of-order window are tracked during this process.

[0099] In this way, by implementing the above method for a load, if an EA hit is present in the L1 directory based on EA, no address translation is performed. This improves on the typical processor where the L1 directory is based on RA, which, in the event of a miss in the L1 directory for a load, results in the EA being sent to an ERAT table for translation to obtain the RA, which is sent to the L2 directory and beyond.

[0100] Furthermore, in the method described here, the LSU must traverse the ERT table for stores to determine the RA, which is then stored in the SRQR for eviction down to the caches (L1, L2, memory) when evicting the store from the SRQ. The SRQR stores all RA for stores. The RA is stored only for eviction in the interleaving (i.e., L2, memory, and other units of the memory subsystem). The RA is not used to detect out-of-order execution risks such as load-hit-store, store-hit-load, or load-hit-load, as is the case with typical solutions.The RA calculation for stores occurs before the store completes, because after completion, the LSU is unable to handle an interrupt for the store (a store may generate an address translation-related interrupt that must be handled before the store completes). Here, the RA calculation is performed when the store is issued (from the SRQR), preventing the LSU from having to perform the address translation. This way, stores are issued and executed out of order and then complete in order, and after that, the stores are flushed in order from the SRQ. Until a store is flushed, no other thread or core is aware of the store (only the current thread is aware of it).After the store is plucked from the SRQ, it is written to the L1 (if the line already exists in the L1) and L2 caches (if caching is enabled), at which time the store is known to all other threads and cores in the system 100.

[0101] For instruction fetches that do not hit the L1 I-cache based on EA, the EA is translated to an RA using ERT 255, and the RA is sent to the interleaver to fetch the I-cache line. LHS (Load-Hit-Store), SHL (Store-Hit-Load), and LHL (Load-Hit-Load) are all determined based on EA and the ERT index stored with the directory entries in the L1 I-cache (EAD 290). All entries in EAD table 300 have their valid translation in ERT table 400, which is available for use once LHS, SHL, and LHL have been determined. When an ERT entry is invalidated, the corresponding L1 cache entries are invalidated.

[0102] The LRQF, the load reorder queue, ensures that all load operations are tracked from allocation to completion. If a load is rejected (due to a cache miss or translation error, or if a previous instruction on which it depends was rejected), the load is removed from the issue queue and placed in the LRQE for reissue.

[0103] Fig. 7 illustrates a flowchart for a method for reloading the ERT in accordance with one or more embodiments of the present invention. Reloading the ERT causes an entry in the ERT to be created or updated in response to and based on the ERT failure. The ERT receives the RA to be added to the ERT 255 and compares the RA to each entry in ERT0 and ERT1, as illustrated in 605. If the RA does not exist in the ERT 255 and if a new entry can be created, the ERT 255 creates a new entry with a new ERT_ID to store the RA, as illustrated in 610 and 615. The new entry is created in ERT0 or ERT1, respectively, based on whether the executing thread is the first thread or the second thread. If the processor is operating in ST mode, ERT0 is updated.If the ERT 255 does not have an open area for a new entry, an existing entry is replaced based on the least recently used or other such techniques, as shown in 615.

[0104] If it is determined that the existing entry(s) in the ERT 255 has / have the same RA as the received RA (reloaded RA), the ERT 255 compares the page size (0 to 1) of the existing entry(s) with that of the received RA, as shown in 620. If the page size of the existing entries is smaller than that of the reloaded RA, the existing entries for that RA are removed from the ERT 255, and a new entry with a new ERT_ID is added for the RA with the larger page size, as shown in 625. If the existing entry has the same or larger page size and if the implementation uses an SDT, an entry for the reloaded RA is created in the SDT, as shown in 627. Note that this operation may not be performed if the LSU uses an ERTE.

[0105] If the page size of the existing entries matches the size of the newly loaded RA, the ERT 255 checks whether the existing entry is in the local ERT for the executing thread, as shown in 630. A local ERT in this case refers to the ERT associated with the executing thread, for example, the ERTO for the first thread and the ERT1 for a second thread. If the RA hit is in the other ERT, that is, in the ERT that is not the local ERT, the ERT 255 creates a new entry in the local ERT with an ERT_ID that matches that in the non-local ERT, as shown in 632. For example, if the RA hit is in ERT1 for an instruction executed by thread 0, an entry is created in ERT0 with an ERT_ID that matches that of the entry in ERT1.

[0106] If the RA hit is in the local ERT instance, and if the EA also matches because both the EA and RA matched an existing entry, but an ERT error occurred for that thread, prompting an ERT reload, the ERT assumes this indicates that the two threads share the same EA-RA mapping (with the same page size). Accordingly, the tid_en(0) or tid_en(1) bit in the existing matching entry is turned ON for the bit corresponding to the newly loaded thread to indicate this case, as shown in 634.

[0107] If the RA hit is in a local ERT instance, the EA does not match the existing entry, and if the existing entry is destined for the same thread as the newly loaded RA, the ERT detects the aliasing case where two different EAs from the same thread are mapped to the same RA, as shown in 636. If the processor uses an SDT-based implementation, a synonym entry is installed in the SDT that maps to the ERT ID and EA offset (40 to 51) of the existing matching entry. If the processor uses an ERTE-based implementation, the LSU rejects the instruction until it is non-speculative, at which point it evicts the entry from the ERT and adds an entry to the ERTE.

[0108] If the RA hit is in the local ERT instance, the EA does not match the existing entry, and if the existing entry is intended for a different thread, the ERT detects the aliasing case, where two EAs from different threads are mapped to the same RA, as shown in 638. If the processor uses an SDT-based implementation, a synonym entry is installed in the SDT that maps to the ERT ID and EA offset (40 to 51) of the existing matching entry. If the processor uses an ERTE-based implementation, a new local ERT entry is added using a new ERT ID, where tin_en applies only to the thread that had the ERT miss.

[0109] The above method facilitates that, in an ERTE-based implementation, two threads that have the same RA but different EA use two different ERT entries; and in an SDT-based implementation, when two threads have the same RA but different EA, one of the implementations uses the ERT entry and the other uses the SDT entry. Thus, the ERT entries facilitate the case where the same EA and the same RA are used across different threads by having a tid_en field in the ERT entry. For example, Tid_en(0 to 1) = {tid 0 en, tid 1 en} in the ERTO instance; and Tid_en(0 to 1) = {tid 1 en, tid 1 en} in the ERT1 instance. Furthermore, the ERT entry facilitates the case where the same EA corresponds to different RAs across different threads by having multiple entries in ERT0 and ERT1 with their respective thread identifiers.The ERT entries also support the case of different EAs corresponding to the same RA (in cases with either the same or different threads). Two cases are described below based on whether the implementation uses an ERTE or an SDT, both of which are described in more detail.

[0110] If the LSU uses the SDT implementation, the LSU installs an entry in the SDT (synonym detection table) instead of the ERT 255 when a new instruction with a different EA matching the same RA is encountered at the time of an ERT reload. SDT hits are restarted with the EA of the original (or previous) ERT entry. If the size of the new synonym page is larger than the page size in the existing ERT entry with the matching RA, the existing ERT entry is replaced with the new synonym (with the larger page size) instead of installing a synonym in the SDT. The old ERT entry is eventually reinstalled as a synonym in the SDT.

[0111] Alternatively, if the LSU uses an ERTE implementation, the LSU installs a new entry in the ERT table with the corresponding Tid_en enabled if the instructions with different EAs corresponding to the same RA are intended for different threads. If the instructions are intended for the same thread, the LSU rejects the load / store until it is non-speculative. The LSU then removes the existing ERT entry and places it in the ERTE table, tagged with the ITAG of the most recent instruction currently being executed by the thread. Furthermore, the LSU installs the new EA-RA pair in the ERT table 400. This ensures that no situation occurs where two different EAs are assigned to the same RA by the same thread.

[0112] With reference to the ERT cases, further consider the case where the LSU receives a snoop from another core of processor 106. The snoop may originate from another core in the system (the snoop indicates another core or thread has modified data at the same physical address). The LSU also checks stores from a thread within the core as a potential snoop against the other threads within the core. All snoops (from other cores) or stores (from other threads within the core) are accompanied by an RA. In such cases, the LSU performs a reverse translation of the RA to determine the corresponding EA, ERT_ID, and page size based on the ERT 255. The LSU compares this data with the ERT_ID, PS, EA(40 to 56) stored in each of the following structures to detect a snoop hit and take the appropriate action.For example, if a snoop hit is detected in an LRQF entry, the LSU indicates a potential risk of an out-of-order load hit. If a snoop hit is detected in EAD 290, the LSU initiates an L1 invalidation if the snoop operation originated from a different core. If the store originated from another thread for a shared row, the row automatically receives the new store and is updated.

[0113] Accordingly, the technical solutions described herein facilitate a reduction in the chip area of ​​the LSU by tracking only one address, an EA. Furthermore, the technical solutions enable the processor cores to operate in a 2-load and 2-store mode with partitioned load-store queues, further reducing the CAM pins for translation and thus the power consumption for translation. By using only the EA, the technical solutions further have the advantage that a translation to an RA is not performed in a load / store path unless an EAD miss occurs. Furthermore, detection of risks such as LHL, SHL, LHS and timely inhibition of a DVAL do not cause any flow control issues.Since the LSU only uses the EA, detecting LHS, SHL, or LHL can result in an error if two different EAs are mapped to the same RA. The technical solutions described here address such technical issues using the EA and the ERT index from the EAD. Furthermore, when detecting EA synonyms, the LSU processes the instructions using an SDT or an ERTE table for the instructions in the OoO window.

[0114] If the LSU uses an SDT (as opposed to an ERTE) and a snoop hit is present in the LMQ, the LSU also updates the LMQ entry so that it is not stored in the L1 cache, the SRQ entry is not used for snoop operations on the SRQ but is used only for an LHS-EA-Error-RA-Hit style check, and a new SDT entry is created for the snoop hit.

[0115] Fig. 8 illustrates an exemplary structure of a synonym recognition table (SDT) 700 according to one or more embodiments of the present invention. The illustrated example shows a case with 16 entries; however, it should be noted that in other examples, the SDT 700 may contain a different number of entries than this example. The SDT 700 is shared across the multiple threads and pipes of the LSU 104. For example, LD0, LD1, ST0, and ST1 all access entries in the SDT 700, and the SDT 700 does not have separate partitions for each.

[0116] An entry in the SDT 700 contains at least the fields output address {output Tid(0 to 1), output EA(0 to 51)}, page size(0 to 1) (e.g., 4 k, 64 k, 2 MB, 16 MB), and restart address {EA(40 to 51), ERT-ID(0 to 6)}. The Tid (thread-identifier) ​​field specifies which thread of the OoO processor is executing the instruction associated with the entry in the SDT 700. In cases of instructions where starts do not have a hit in the L1, the LSU compares the instruction with the SDT 700. If the started instruction has an SDT hit when comparing with the original address, the LSU rejects the instruction and restarts the instruction with the appropriate replacement address from the SDT entry. For example, the LSU uses the surrogate address (40 to 51) for the SRQ LHS and Force Match for the ERT ID in the execution pipeline.

[0117] During ERT reloading, an entry is added to the SDT 700 as described herein. During ERT reloading, for example, the reloaded RA is compared with valid ERT entries. If an ERT entry with a corresponding RA already exists and this is not an EA hit case, in which an additional tid_en bit is simply set in the original ERT entry, the EA(32 through 51) is read from the existing ERT entry and an entry is installed in the SDT 700 instead of adding an entry to the ERT 255.

[0118] Since the SDT 700 has only a limited number of entries, the entries are replaced. In one or more examples, the entries are replaced based on least recently used (LRU) techniques or in some other order. In one or more examples, when an SDT entry is replaced, a subsequent boot using the secondary address retriggers the SDT entry installation flow. Further, the CAM deletes any SDT entry(s) whose ERT ID matches an invalid ERT entry.

[0119] Fig. 9 illustrates a flowchart for a method for performing a swap of an EA in the ERT and the SDT according to one or more embodiments of the present invention. In one or more examples, the LSU performs the swap when the entries in the ERT and the SDT have the same page size. The swap improves the efficiency of the processor 106 in cases of different EAs corresponding to the same RA for different instructions in the same or a different thread. For example, consider two instructions x and y such that EAx => RAz and EAy => RAz. If EAx first has no match in the ERT, that is, before EAy, the LSU installs an ERT entry where EAx is mapped to RAz, as described herein.If EAy does not have a hit in the ERT at a later time, the LSU subsequently performs a CAMming operation on the ERT with the RAz, achieves an RA hit, and installs an entry in the SDT 700 with Original Address = EAy, Backup Address = EAx.

[0120] If most subsequent accesses to RAz are made via EAy, the LSU must use the SDT more frequently than the EAD itself is used. In one or more examples, the technical solutions to improve the efficiency of the LSU by reducing such frequent accesses to the SDT include providing an increment counter in each SDT entry. As described in Fig. 8, the LSU starts an instruction with an ERT ID that matches an ERT ID from an SDT entry, as shown in 810. If the ERT ID of the SDT entry matches, the LSU further compares the EA of the started instruction with an original EA in the SDT entry, as shown in 820. If the SDT entry has an original address value that matches the EA from the instruction, the counter of the SDT entry is incremented, as shown in 830 and 835. If the started instruction has a different EA than the original address of the SDT entry, the counter of the SDT entry is reset, as shown in 840.

[0121] In one or more examples, the counter is a 4-bit field, implying a maximum value of 15. It should be understood that in other examples, the field may have a different length and / or a different maximum value used as a threshold. For example, after the instruction starts, the counter value is compared to the threshold, as shown in 845 and 850. If the counter is below the threshold, the LSU continues to operate as described. If the counter exceeds the threshold, or in some cases, equals the threshold, the LSU invalidates the ERT entry corresponding to the SDT entry, as shown in 860. For example, the ERT entry with the ERT ID from the SDT entry is invalidated. Invalidating the ERT entry causes the corresponding entries from the EA directory, LRQF, LMQ, and SRQ to be invalidated.

[0122] Furthermore, the LSU handles a technical issue regarding exceptions in a started instruction that require the original EA to complete in the following way. For example, consider the case where the started instruction encounters an SDT hit and should restart with the replacement address from the SDT entry instead of the original start address, but an exception occurs that requires the original EA to complete. Such a condition can occur in the case of DAWR / SDAR, etc.

[0123] The LSU implementing the technical solutions described herein addresses such a technical problem by keeping the original address in a queue in the LRQE. The LRQE also maintains an SDT hit flag (bit), an SDT index (0 to 3), for each LRQE entry. Upon restart, the SDT index is read one cycle earlier to obtain the replacement address. The LRQE further multiplexes between the address of the LRQE entry (the original address) and the SDT replacement address (read from the SDT) before restarting. In exceptional cases such as the ones above, where the original address is required for termination, the LRQE maintains an additional SDT hit overwrite flag (bit) for each entry for which a partial match with the DAWR has been established, etc.The LRQE restarts the case where there was an SDT hit that terminated with an exception, forcing the original address to be restarted. An SRQ restart is similar to the LRQE restart described here, using the SDT hit override flag if it is determined before the restart that it will terminate with an exception.

[0124] Fig. 10 illustrates an ERT Eviction (ERTE) table 900 according to one or more embodiments of the present invention. The ERTE table 900 facilitates the LSU to track evicted (or invalid) rows from the ERT 255. The ERTE table 900 further facilitates checking whether another EA for the same RA exists in the same thread when creating an entry in the ERT 255. The ERTE table 900 is shared by all concurrent threads. In one or more examples, a portion of the ERTE table 900 is reserved for NTC entries. An entry in the ERTE table 900 includes fields for a thread ID, an ITAG, an EA, and an RA. In one or more examples, the ERTE table may include additional fields. The thread ID may be a four-bit field in one or more examples.

[0125] The ERTE table 900 can be considered a combination of two tables: ERT_EA and ERT_RA, with a 1:1 correspondence between them. The ERT_EA table uses EA-to-CAM, and the ERT_RA table uses RA-to-CAM. In one or more examples, each table has 64 entries, although the number of entries may vary / be programmable in other examples. When an EA-RA translation is removed from the ERTE table 900, the corresponding cache line is also invalidated from the EAD table 300. In this way, the ERT 255 is a superset of all translations within a processor core (except the TLB, SLB).

[0126] The ERTE table 900 tracks all translations that are not in the ERT 255 but are used by a currently executing instruction. The entries in the ERTE table are marked with the most recent possible instruction that may have used an evicted entry. Due to the OoO issue of load-stores, the most recent ITAG of all active instructions in the OoO window is stored in the ERTE table 900. On a flush, the ITAG of the last surviving instruction is stored in all valid entries. On a close, all entries with the same or an older ITAG are deallocated. When full, the block is allocated to the ERTE table 900, waiting for instructions to complete (and / or be flushed) and eventually completely deallocate the table.Note that although examples described herein use the ITAG to track the age of started instructions, other examples may instead use another tag (such as EATAG, LSTAG, or the like) that increases and rolls over monotonically.

[0127] When a translation in the ERT 255 or the EAD 290 is eliminated / invalidated, the EA-RA of the eliminated entry is added to the ERTE table 900 without the last specified number of bits from the eliminated entry, for example, the last 12 bits. Furthermore, the entry in the ERTE table 900 is marked with the most recent valid ITAG for the same thread to which the eliminated translation belongs, for example, using a flag (bit).

[0128] When a new address translation is performed (EA to RA), the LSU compares the RA with the ERT 255 to check if another EA-to-RA from the same thread already exists in the ERT 255. If one exists, the LSU installs the new translation in the ERT 255 as a synonym. This way, the ERT 255 (when using the ERTE) can have two entries with different EAs pointing to the same RA for the same thread. Because synonyms of the currently executing instructions are not allowed, the LSU initiates an NTC+1 flush in one or more instances to ensure continued progress.

[0129] A rebalance deletion is a thread control mechanism that completely deletes a delayed and / or resource-intensive target thread from the system to restore balance or equilibrium in resource usage. A rebalance deletion comprises a next-to-complete (NTC+1) deletion, which deletes all instruction groups in a selected thread following the next-to-complete instruction group. The NTC+1 rebalance delete deletes the execution units, the global completion table, and the EAD for the selected thread. Threads are only subject to a rebalance deletion when a thread is delayed in dispatch. Rebalance deletions can be configured using the <bf:1>be enabled or disabled within the thread switching control register.

[0130] In one or more examples, entries in the ERTE are marked as invalid after the OoO window execution is complete. Note that an ERTE entry is marked as valid when a write is made to the ERTE entry, eliminating a new EA-RA translation pair from the ERT table 255.

[0131] Fig. 11 illustrates a flowchart of an exemplary method for adding entries to the ERTE table 900 according to one or more embodiments of the present invention. As described herein, when a new entry is added to the ERT 255, the LSU writes both the EA and RA of a new implementation to a respective row, possibly managed by the LRU, as illustrated at 1010. The ERTE table 900 performs a CAMming operation on the RA to check if the RA already exists in an entry in the ERTE table 900 that corresponds to another EA to check for a possible case of multiple hits with the same thread during installation, as illustrated at 1012. If the RA already exists in the ERTE table 900, the ERT table rejects creating the entry for the EA-RA until an NTC is detected, and installs it if an NTC is detected, as illustrated at 1015.

[0132] The LSU reads the EA and RA of an existing entry in the ERT that will be overwritten by the new entry before overwriting the entry in the ERT 255, as shown in 1020; and further stores the read entry in the ERTE table 900, as shown in 1030. If there is a snoop from another core of the processor or a garbage collection, the ERTE table 900 performs a CAMming operation on the EA and reads it, as shown in 1040 and 1050.

[0133] Fig. 12 illustrates an example flowchart for an example set of instructions launched in accordance with one or more embodiments of the present invention. The instructions are shown in program order on the left, which are launched OoO, resulting in a different flow of operations than the flow of instructions. For example, assume that the following events occur in chronological order: 1. Instruction M, issued OoO, used the implementation "ea1, ra1"; 2. Instruction K, issued OoO, encountered an ERT fault, installed a new entry, and eliminated "ra2 ea2" from the ERT. At this time, the last used ITAG = N (all lines from the same thread eliminated); that is, instructions up to N may have used "ra2 ea2," and after N, no instruction may have used "ra2 ea2." 3.Instruction H, issued OoO, encountered an ERT fault and removed "ra1 ea1" from the ERT. At this time, the last used ITAG = Q. 4. The deleted pipeline and the last surviving instruction have ITAG = E; furthermore, the next fetched instruction is R, S. 5. Instructions E through R complete in a respective cycle, freeing all entries in the ERT.

[0134] In this way, the technical solutions described herein facilitate the use of only the EA, offer technical advantages in that an ERAT (which was typically used in processors) is not referenced in a load / store path, and furthermore, detecting an SHL and preventing a DVAL in a timely manner does not cause flow control problems. Furthermore, the technical solutions described herein address technical problems with the use of only the EA, for example, that detecting LHS, SHL, or LHL can lead to an error if two different EAs are assigned to the same RA. The technical solutions described herein address such a technical problem by using either a synonym detection table (SDT) or an ERT elimination table for the instructions in the OoO window.The technical solutions offer several technical advantages, including a reduction in chip area (by not storing RA), a reduction in power consumption (by not converting IO to RA), and latency improvements.

[0135] Furthermore, the technical solutions facilitate power savings by eliminating camming operations for determining RAs for IOs each time load and store addresses are generated. Instead, IOs are used until an EAD fault and an ERT fault occur. Furthermore, the technical solutions facilitate the removal of RA bus switching throughout the entire unit, as only a single CAM pin is used.

[0136] Fig. 13 illustrates a flowchart of an exemplary method for dispatching instructions by the LSU 104 in a multi-pipe and OoO manner, depending on whether the processor is operating in ST mode or MT mode, according to one or more embodiments of the present invention. For example, the LSU may be operating in a 2-load-2-store (multi-pipe) mode. The LSU 104 selects an instruction to dispatch from the OoO window, as shown in block 1310. The selected instruction may be a load instruction, a store instruction, or any derivative of such instructions that the LSU 104 dispatches, for example, a LARX instruction.

[0137] The LSU 104 determines whether the OoO processor is operating in ST mode or MT mode, as illustrated in block 1320. If ST mode is used, the processor uses a single thread, and the LSU 104 simply determines the LSU pipe associated with the instruction, as illustrated in block 1330. For example, if the instruction is a load instruction, the LSU 104 may assign the load instruction to pipe LD0, pipe LD1, or any other load pipe. Alternatively, if the instruction is a store instruction, the LSU 104 may assign the store instruction to pipe ST0, pipe ST1, or any other store pipe.

[0138] The LSU 104 further uses partitions in the LRQF 218, the SRQR 220, the LRQE 222, and the ERT 255 associated with the pipe to create / access entries for issuing the instruction, as illustrated in block 1340. For example, if the instruction is a load instruction and the associated pipe is LD0, the instruction uses entries from partitions LRQF0, LRQE0, and ERT0. Similarly, a store instruction in pipe ST0 uses partitions SRQR0 and ERT0. For pipes LD1 or ST1, partitions LRQF1, LRQE1, ERT1, and SRQR1 are used. Entries are created in the partitions on a first-in, first-out basis.

[0139] Alternatively, if the processor is operating in MT mode, that is, multiple threads are executing concurrently, the LSU 104 determines a thread ID of the thread associated with the selected instruction, as illustrated in block 1350. The LSU 104 further determines the LSU pipe associated with the instruction, as illustrated in block 1360. Furthermore, the LSU 10 identifies partitions and positions within the partitions of the LRQF 218, the SRQR 220, the LRQE 222, and the ERT 255 to create / access entries to issue the instruction based on a combination of {thread ID and pipe}, as illustrated in block 1370. For example, the LSU restricts certain threads to certain pipes, for example, even-numbered threads to LD0 and ST0 and odd-numbered threads to LD1 and ST1. Please note that the categorization of threads and pipes may be different in other examples.The pipes LD0 and ST0 belong to the subdivisions with the suffix '0' and the pipes LD1 and ST1 belong to the subdivisions with the suffix '1' (or vice versa).

[0140] In one or more example embodiments of the present invention, each partition is further divided into sections according to a number of threads the processor is executing in MT mode. For example, if the processor is executing four threads, the two partitions in the LSU are each further divided into two sections, a first partition for a first thread and a second section for a second thread, with each partition associated with a pair of threads. In one or more other example embodiments where the number of threads in MT mode is other than four, the partitions are divided into a different number of sections based on the number of threads associated with each partition.In the above example, where a pair of threads belongs to each partition, and each partition is further divided into equal sections, the first thread of the pair uses the first section, and the second thread uses the second section. Thus, an instruction executing in T0 in LD0 / ST0 belongs to a first section of the partitions LRQF0, LRQE0, SRQR0, and ERT0; and an instruction executing in T2 in LD0 / ST0 belongs to a second section of the partitions LRQF0, LRQE0, SRQR0, and ERT0. Furthermore, an instruction executing in T1 in LD1 / ST1 belongs to a first section of the partitions LRQF1, LRQE1, SRQR1, and ERT1; and an instruction in T3 in LD1 / ST1 belongs to a second section of the subdivisions LRQF1, LRQE1, SRQR1 and ERT1.

[0141] With reference to Fig. 14, a block diagram of a computer system 1400 for implementing some or all aspects of one or more embodiments of the present invention is shown. The processing described herein may be implemented in hardware, software (e.g., firmware), or a combination thereof. In an exemplary embodiment, the described methods are implemented at least in part in hardware and may be part of the microprocessor of a special-purpose or general-purpose computer 1400, such as a mobile device, a personal computer, a workstation, a minicomputer, or a mainframe.

[0142] In an exemplary embodiment, as in Fig. 14, the computer system 1400 includes a processor 1405, a memory 1412 connected to a memory controller 1415, and one or more input devices 1445 and / or output devices 1447, such as peripherals, connected for data transmission via a local I / O controller 1435. These devices 1447 and 1445 may include, for example, a printer, a scanner, a microphone, and the like. A conventional keyboard 1450 and mouse 1455 may be connected to the I / O controller 1435. The I / O controller 1435 may, for example, be one or more buses or other wired or wireless connections known in the art. The I / O controller 1435 may include additional elements such as controllers, buffers (caches), drivers, repeaters, and receivers, which are omitted for simplicity to enable data transfers.

[0143] The I / O units 1447, 1445 may further include devices that transfer data between inputs and outputs, for example, disk and tape storage, a network interface card (NIC) or a modulator / demodulator (for accessing other files, devices, systems, or a network), a radio frequency (RF) or other transceiver, a telephone interface, a bridge, a router, and the like.

[0144] Processor 1405 is a hardware unit for executing hardware instructions or software, particularly those stored in memory 1412. Processor 1405 may be a custom-built or off-the-shelf processor, a central processing unit (CPU), an auxiliary processor of multiple processors associated with computer system 1400, a semiconductor-based microprocessor (in the form of a microchip or chipset), a microprocessor, or other unit for executing instructions. Processor 1405 may include a cache, for example, but not limited to, an instruction cache to accelerate fetching executable instructions, a data cache to accelerate fetching and storing data, and a translation buffer (TLB) used to accelerate virtual-to-physical address translation for executable instructions as well as for data.The cache can be organized as a hierarchy of multiple cache levels (L1, L2, etc.).

[0145] The memory 1412 may include a volatile memory element (e.g., a random access memory (RAM, such as a DRAM, SRAM, SDRAM, etc.)) and a non-volatile memory element (e.g., a ROM, an erasable programmable read-only memory (EPROM), an electronically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a tape, a CD-ROM (compact disc read-only memory), a disk, a floppy disk, a cartridge, a cassette, or the like, etc.), or combinations thereof. In addition, the memory 1412 may include electronic, magnetic, optical, or other types of storage media.It should be noted that memory 1412 may have a distributed architecture, with various components located remotely from each other but accessible by processor 1405.

[0146] The instructions in memory 1412 may include one or more separate programs, each of which comprises an ordered collection of executable instructions for implementing logical functions. In the example of Fig. 14, the instructions in memory 1412 include a suitable operating system (OS) 1411. Operating system 1411 may essentially control the execution of other computer programs and provides scheduling, input / output control, file and data management, memory management, and data transfer control, as well as related services.

[0147] Additional data, including, for example, instructions for processor 1405 or other retrievable data, may be stored in memory 1427, which may be a storage device such as a hard disk drive or a solid-state drive. The stored instructions in memory 1412 or memory 1427 may include those that enable processor 1405 to perform one or more aspects of the dispatch systems and methods of this disclosure.

[0148] Computer system 1400 may further include a display controller 1425 connected to a display 1430. In an exemplary embodiment, computer system 1400 may further include a network interface 1460 for connecting to a network 1465. Network 1465 may be an IP-based network for transmitting data between computer 1400 and an external server, client, and the like over a broadband connection. Network 1465 transmits and receives data between computer system 1400 and external systems. In an exemplary embodiment, network 1465 may be a managed IP network managed by a service provider. Network 1465 may be implemented wirelessly, e.g., using wireless protocols and technologies such as WiFi, WiMax, etc.Network 1465 may also be a packet-switched network such as a local area network, a wide area network, a high-speed network, the Internet, or any other similar type of network environment. Network 1465 may be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN), a personal area network (PAN), a virtual private network (VPN), an intranet, or any other suitable network system, and may include devices for receiving and transmitting signals.

[0149] Systems and methods for providing a partitioned load request queue and a store request queue may be implemented in whole or in part in computer program products or in computer systems 1400 such as the one described in Fig. 14 illustrated may be embodied.

[0150] Various embodiments of the invention are described herein with reference to the accompanying drawings. Alternative embodiments of the invention may be devised without departing from the scope of this invention. Various connections and positional relationships (e.g., above, below, adjacent to, etc.) between elements are set forth in the following description and in the drawings. Unless otherwise indicated, these connections and / or positional relationships may be direct or indirect, and the present invention is not intended to be limiting in this regard. Accordingly, a coupling of entities may refer to either a direct or an indirect coupling, and a positional relationship between entities may be a direct or an indirect positional relationship.In addition, the various tasks and process steps described herein may be integrated into a more comprehensive procedure or process with additional steps or functions not described in detail herein.

[0151] The following definitions and abbreviations are to be used for the interpretation of the claims and the description. As used herein, the terms "comprises," "having," "includes," "comprising," "has," "having," "containing," "includes," or "containing" or any other variations thereof are intended to cover non-exclusive inclusion. For example, a composition, mixture, process, method, article, or device that includes a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent in such composition, mixture, process, method, article, or device.

[0152] Furthermore, the term "exemplary" is used herein to mean "serving as an example, example, or illustration." Any embodiment or construction described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or constructions. The terms "at least one" and "one or more" may be understood to include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "a plurality" may be understood to include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connection" may include both an indirect "connection" and a direct "connection."

[0153] The terms "about," "substantially," "approximately," and variations thereof are intended to convey the degree of error inherent in a measurement of the respective quantity based on the equipment available at the time the application is filed. For example, "about" may convey a range of ± 8%, 5%, or 2% of a particular value.

[0154] For the sake of brevity, conventional techniques associated with making and using aspects of the invention may not be described in detail herein. In particular, various aspects of data processing systems and specific computer programs for implementing the various technical features described herein are well known. Accordingly, for the sake of brevity, numerous details of a conventional implementation are only briefly mentioned or omitted entirely without providing the well-known details of the system and / or processes.

[0155] The present invention may be a system, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions stored thereon for causing a processor to perform aspects of the present invention.

[0156] The computer-readable storage medium may be any physical device capable of retaining and storing instructions for use by an instruction-executing system. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM).Flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded device such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium, as used herein, shall not be construed as containing transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., pulses of light carried through a fiber optic cable), or electrical signals carried through a wire.

[0157] Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing units or to an external computer or storage unit via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing unit.

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

Claims

[1] Processing unit for executing one or more instructions, the processing unit comprising: a load-store unit (LSU) configured to execute a plurality of instructions in an out-of-order (OoO) window using a plurality of LSU pipes by: Selecting an instruction from the OoO window, the instruction using a first effective address; and in response to the fact that the instruction is a load instruction: in response to the processing unit operating in a single-threaded mode, creating an entry in a first subdivision of a load reorder queue based on the instruction being issued in a first load pipe, and creating the entry in a second subdivision of the load reorder queue based on the instruction being issued in a second load pipe; and in response to the processing unit operating in a multi-threaded mode in which multiple threads are processed concurrently, creating the entry in a first predetermined portion of the first subdivision of the load reorder queue based on the instruction being issued in the first load pipe and by a first thread of the processing unit, The LSU is designed to be: Generating a real address based on the first effective address in the instruction; in response to detecting that an effective real table (ERT) does not contain an entry for the real address, inserting an entry into the ERT comprising the real address and at least a portion of the first effective address, wherein the real address is accessed from the entry in the ERT at the time of instruction execution; in response to detecting that the ERT already contains an entry for the real address with a second effective address: in response to a page size associated with the first effective address being larger than a page size associated with the second effective address, removing the entry for the real address with the second effective address and inserting a new entry into the ERT for the first effective address, otherwise inserting an entry into a synonym detection table (SDT) that facilitates resolving cases where two or more different effective addresses are associated with the same real address, the entry in the SDT including an identifier of the entry in the ERT and the at least part of the first effective address. [2] The processing unit of claim 1, wherein in multi-threaded mode, the first predetermined portion of the first partition of the load reorder queue is specific to load instructions issued by the first thread of the processing unit using the first load pipe. [3] Processing unit according to claim 1, wherein the load-store unit is further configured to: in response to the fact that the instruction is a memory instruction: in response to the processing unit operating in single-threaded mode, creating a store entry in a first subdivision of a store reorder queue based on the store instruction being issued in a first store pipe, and creating the store entry in a second subdivision of the store reorder queue based on the store instruction being issued in a second store pipe; and in response to the processing unit operating in multi-threaded mode, creating the store entry in a first predetermined portion of the first subdivision of the store reorder queue based on the store instruction being issued in the first store pipe and by the first thread of the processing unit. [4] The processing unit of claim 1, wherein the load reorder queue comprises a partition for each load pipe of the LSU. [5] The processing unit of claim 4, wherein the LSU processes multiple load instructions concurrently, each load instruction using a corresponding load pipe. [6] The processing unit of claim 1, wherein the memory reorder queue comprises a partition for each memory pipe of the LSU. [7] The processing unit of claim 6, wherein the LSU processes multiple store instructions concurrently, each store instruction using a corresponding load pipe. [8] A computer-implemented method for out-of-order execution of one or more instructions by a processing unit, the method comprising: Receiving, by a load-store unit (LSU) of the processing unit, an out-of-order window of instructions comprising a plurality of instructions to be executed out of order; and Issuing instructions from the OoO window through the LSU by: Selecting an instruction from the OoO window, where the instruction uses a first effective address; in response to the fact that the instruction is a load instruction: in response to the processing unit operating in a single-threaded mode, creating an entry in a first subdivision of a load reorder queue based on the instruction being issued in a first load pipe, and creating the entry in a second subdivision of the load reorder queue based on the instruction being issued in a second load pipe; and in response to the processing unit operating in a multi-threaded mode, creating the entry in a first predetermined portion of the first subdivision of the load reorder queue based on the instruction being issued in the first load pipe and by a first thread of the processing unit, The LSU is designed to be: Generating a real address based on the first effective address in the instruction; in response to detecting that an effective real table (ERT) does not contain an entry for the real address, inserting an entry into the ERT comprising the real address and at least a portion of the first effective address, wherein the real address is accessed from the entry in the ERT at the time of instruction execution; in response to detecting that the ERT already contains an entry for the real address with a second effective address: in response to a page size associated with the first effective address being larger than a page size associated with the second effective address, removing the entry for the real address with the second effective address and inserting a new entry into the ERT for the first effective address, otherwise inserting an entry into a synonym detection table (SDT) that facilitates resolving cases where two or more different effective addresses are associated with the same real address, the entry in the SDT including an identifier of the entry in the ERT and the at least part of the first effective address. [9] The computer-implemented method of claim 8, wherein in multi-threaded mode, the first predetermined portion of the first partition of the load reorder queue is specific to load instructions issued by the first thread of the processing unit using the first load pipe. [10] A computer-implemented method according to claim 8, further comprising: in response to the fact that the instruction is a memory instruction: in response to the processing unit operating in single-threaded mode, creating a store entry in a first subdivision of a store reorder queue based on the store instruction being issued in a first store pipe, and creating the store entry in a second subdivision of the store reorder queue based on the store instruction being issued in a second store pipe; and in response to the processing unit operating in multi-threaded mode, creating the store entry in a first predetermined portion of the first subdivision of the store reorder queue based on the store instruction being issued in the first store pipe and by the first thread of the processing unit. [11] The computer-implemented method of claim 8, wherein the load reorder queue comprises a partition for each load pipe of the LSU. [12] The computer-implemented method of claim 11, wherein the LSU processes multiple load instructions concurrently, each load instruction using a respective load pipe. [13] The computer-implemented method of claim 8, wherein the memory reorder queue comprises a partition for each memory pipe of the LSU. [14] The computer-implemented method of claim 13, wherein the LSU processes multiple store instructions concurrently, each store instruction using a corresponding load pipe. [15] A computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processing unit to cause the processing unit to perform operations comprising: Receiving, by a load-store unit (LSU) of the processing unit, an out-of-order window of instructions comprising a plurality of instructions to be executed out of order; and Issuing instructions from the OoO window through the LSU by: Selecting an instruction from the OoO window, where the instruction uses a first effective address; in response to the fact that the instruction is a load instruction: in response to the processing unit operating in a single-threaded mode, creating an entry in a first subdivision of a load reorder queue based on the instruction being issued in a first load pipe, and creating the entry in a second subdivision of the load reorder queue based on the instruction being issued in a second load pipe; and in response to the processing unit operating in a multi-threaded mode, creating the entry in a first predetermined portion of the first subdivision of the load reorder queue based on the instruction being issued in the first load pipe and by a first thread of the processing unit, wherein the issuing of instructions by the LSU further comprises: Generating a real address based on the first effective address in the instruction; in response to detecting that an effective real table (ERT) does not contain an entry for the real address, inserting an entry into the ERT comprising the real address and at least a portion of the first effective address, wherein the real address is accessed from the entry in the ERT at the time of instruction execution; in response to detecting that the ERT already contains an entry for the real address with a second effective address: in response to a page size associated with the first effective address being larger than a page size associated with the second effective address, removing the entry for the real address with the second effective address and inserting a new entry into the ERT for the first effective address, otherwise inserting an entry into a synonym detection table (SDT) that facilitates resolving cases where two or more different effective addresses are associated with the same real address, the entry in the SDT including an identifier of the entry in the ERT and the at least part of the first effective address. [16] The computer program product of claim 15, wherein in multi-threaded mode, the first predetermined portion of the first partition of the load reorder queue is specific to load instructions issued by the first thread of the processing unit using the first load pipe. [17] The computer program product of claim 15, wherein in response to the instruction being a memory instruction: in response to the processing unit operating in single-threaded mode, creating a store entry in a first subdivision of a store reorder queue based on the store instruction being issued in a first store pipe, and creating the store entry in a second subdivision of the store reorder queue based on the store instruction being issued in a second store pipe; and in response to the processing unit operating in multi-threaded mode, creating the store entry in a first predetermined portion of the first subdivision of the store reorder queue based on the store instruction being issued in the first store pipe and by the first thread of the processing unit. [18] The computer program product of claim 15, wherein the load reorder queue comprises a partition for each load pipe of the LSU. [19] The computer program product of claim 18, wherein the LSU processes multiple load instructions concurrently, each load instruction using a respective load pipe. [20] The computer program product of claim 15, wherein the memory reorder queue comprises a partition for each store pipe of the LSU, and wherein the LSU processes multiple store instructions concurrently, each store instruction using a corresponding load pipe.

Images