DE112018004006B4 - PROCESSING SYNONYMS OF EFFECTIVE ADDRESSES IN A LOAD MEMORY UNIT THAT WORKS WITHOUT ADDRESS CONVERSION - Google Patents

Abstract

Processing unit for executing one or more instructions, wherein the processing unit has: a load storage unit (LSU) (104) for transferring data between a memory and registers, the LSU being designed to store a plurality of instructions in an out- of Order (OoO) window, the execution comprising: in response to determining (610) that a first effective address is being used by a first instruction, the first effective address corresponding to a first real address, creating (615 ) an entry of an effective real table (ERT) (255) in an ERT, the ERT entry assigning the first effective address to the first real address; andin response to determining (830) a synonym of an effective address used by a second instruction, the synonym of the effective address being a second effective address that also corresponds to the first real address: creating an entry of a Synonym Detection Table (SDT) (800) in an SDT, the SDT entry assigning the second effective address to the ERT entry; and restarting (845) the second instruction by replacing the second effective address in the second instruction with the first effective address.

Description

BACKGROUND

Embodiments of the present invention relate generally to an out-of-order (OoO) processor and, more particularly, to processing synonyms of effective addresses with a synonym detection table (SDT) in FIG a load / store unit that works without address translation.

In an OoO processor, an instruction sequencing unit (ISU) dispatches instructions to various issue queues, renames registers to support OoO execution, issues instructions from the various issue queues to the execution pipelines, closes executed instructions, and handles exceptions . Register renaming is typically performed by mapping function logic in the ISU before the instructions are placed in their respective issue queues. The ISU contains one or more output queues that contain dependency matrices for keeping track of dependencies between instructions. A dependency matrix typically contains one row and one column for each instruction in the output queue.

In the field of the construction of central processing units (CPU) and in particular for OoO processors, risks pose technical problems for the instruction pipeline in the CPU microarchitectures if a next instruction cannot be executed in the following clock cycle, since this may lead to incorrect calculation results. Typical types of risks include data risks, structural risks and risks in the control process (branch risks). Data risks arise when instructions that have a data dependency change data at different stages of a pipeline, such as read after write (RAW), write after read (WAR), and write after write, WAW). A structural risk arises when part of the hardware of the processor is required by two or more instructions at the same time, for example when a memory unit is accessed both at the fetch level in which an instruction is fetched from memory and at the memory level , in which data is written and / or read from memory. Furthermore, branch risks (also referred to as control risks) occur when branches in the computer program are executed by the processor.

The WO 2016/105 961 A1 relates to a computer architecture that provides a memory cache that is not accessed via physical addresses but via virtual addresses directly from running processes. Ambiguities that can result from mapping multiple virtual addresses to a single physical address are resolved through dynamic tracking of synonyms and the connection of a limited number of virtual synonyms that are mapped to the same physical address with a single virtual key address that is exclusive to handle cache access.

SHORT REPRESENTATION

The invention relates to a method, a processing unit and a computer program product, the features of which are specified in the corresponding main claims. Embodiments of the invention are specified in the dependent claims.

One non-limiting example of a processing unit for executing one or more instructions includes a load store unit (LSU) for transferring data between memory and registers. The LSU executes a plurality of instructions in an out-of-order (OoO) window. In response to a determination, execution includes a first effective address by a first instruction is used, the first effective address corresponding to a first real address, creating an entry of an effective real table (ERT) in an ERT, the ERT entry being the first effective address of the first real Address assigns. Furthermore, in response to determining a synonym of an effective address that is used by a second instruction, the synonym of the effective address being a second effective address that also corresponds to the first real address, the execution includes: a creation an entry of a synonym recognition table (SDT) in an SDT, the SDT entry assigning the second effective address to the ERT entry, and restarting the second instruction by replacing the second effective address in the second instruction with the first effective address.

According to one or more embodiments of the present invention, an exemplary method implemented on a computer for executing one or more instructions out of order by a processing unit includes issuing or executing a plurality of instructions from an out-of-order (OoO) window by a Load storage unit (LSU). In response to determining that a first effective address is being used by a first instruction, the first effective address corresponding to a first real address, issuing includes creating an effective-real table (ERT) entry in an ERT, where the ERT entry assigns the first effective address to the first real address. Furthermore, in response to determining a synonym of an effective address that is used by a second instruction, the synonym of the effective address being a second effective address that also corresponds to the first real address, the execution includes: a creation an entry of a synonym recognition table (SDT) in an SDT, the SDT entry assigning the second effective address to the ERT entry, and restarting the second instruction by replacing the second effective address in the second instruction with the first effective address.

According to one or more embodiments, an exemplary computer program product includes a computer-readable storage medium in which program instructions are embodied, the ones being executable by a processing unit

Program instructions cause the processing unit to perform operations. The operations include issuing or executing a plurality of instructions from an out-of-order (OoO) window by a load store unit (LSU). In response to determining that a first effective address is being used by a first instruction, the first effective address corresponding to a first real address, issuing includes creating an effective-real table (ERT) entry in an ERT, where the ERT entry assigns the first effective address to the first real address. Furthermore, in response to determining a synonym of an effective address that is used by a second instruction, the synonym of the effective address being a second effective address that also corresponds to the first real address, the execution includes: a creation an entry of a synonym recognition table (SDT) in an SDT, the SDT entry assigning the second effective address to the ERT entry, and restarting the second instruction by replacing the second effective address in the second instruction with the first effective address.

Additional features and advantages are realized through 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 with the advantages and features, reference is made to the description and to the drawings.

Figure list

• 1 ein Blockschaubild eines Systems darstellt, das eine Lade-Speicher-Einheit auf Grundlage von effektiven Adressen in einem Out-of-Order(OoO)-Prozessor gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung enthält;
• 2 ein beispielhaftes Blockschaubild einer Prozessorarchitektur eines OoO-Prozessors ist, in dem ein Verzeichnis von effektiven Adressen (effective address directory, EAD) und die zugehörigen Mechanismen zum Verwenden dieses EAD gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung implementiert sind;
• 3 eine Lade-Speicher-Einheit (LSU) eines Verarbeitungskerns gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
• 4 ein beispielhafter Block einer Struktur (L1-Cache) eines Verzeichnisses von effektiven Adressen (EAD) gemäß einer veranschaulichenden Ausführungsform ist;
• 5 ein beispielhafter Block einer Struktur einer Effektiv-Real-Tabelle (ERT) gemäß einer veranschaulichenden Ausführungsform ist;
• 6 einen Ablaufplan eines beispielhaften Verfahrens zum Zugreifen auf einen Speicher zum Ausführen von Anweisungen durch eine LSU gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung veranschaulicht;
• 7 einen Ablaufplan für ein Verfahren zum erneuten Laden der ERT gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung veranschaulicht;
• 8 eine beispielhafte Struktur einer Synonymerkennungstabelle (SDT) gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung darstellt;
• 9 einen Ablaufplan für ein Verfahren zum Durchführen eines Austauschs einer EA in einer ERT und einer SDT gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung veranschaulicht; und
• 10 ein Blockschaubild eines Computersystems zum Implementieren einiger oder sämtlicher Aspekte einer oder mehrerer Ausführungsformen der vorliegenden Erfindung darstellt.

The particularities of the exclusive rights described herein are set out in detail and expressly claimed in the claims at the end of the description. The above and other features and advantages of embodiments of the invention will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, in which:

• 1 Figure 3 illustrates a block diagram of a system including an effective address based load store unit in an out-of-order (OoO) processor in accordance with one or more embodiments of the present invention;
• 2 Figure 13 is an exemplary block diagram of a processor architecture of an OoO processor that implements an effective address directory (EAD) and the associated mechanisms for using that EAD in accordance with one or more embodiments of the present invention;
• 3 Figure 12 illustrates a load store unit (LSU) of a processing core in accordance with one or more embodiments of the present invention;
• 4th Figure 3 is an exemplary block of a structure (L1 cache) of a directory of effective addresses (EAD) according to an illustrative embodiment;
• 5 Figure 3 is an exemplary block of an effective-real table (ERT) structure in accordance with an illustrative embodiment;
• 6th Figure 3 illustrates a flow diagram of an exemplary method of accessing memory for execution of instructions by an LSU in accordance with one or more embodiments of the present invention;
• 7th Figure 3 illustrates a flow diagram for a method of reloading the ERT in accordance with one or more embodiments of the present invention;
• 8th Figure 3 illustrates an exemplary structure of a Synonym Recognition Table (SDT) in accordance with one or more embodiments of the present invention;
• 9 Figure 11 illustrates a flow diagram for a method of performing a swap of an EA in an ERT and an SDT in accordance with one or more embodiments of the present invention; and
• 10 Figure 3 illustrates a block diagram of a computer system for implementing some or all aspects of one or more embodiments of the present invention.

The graphs presented herein are provided for illustrative purposes. Many variants of the diagram or of the processes described therein are possible without departing from the essence of the invention. For example, the operations can be performed in a different order, or operations can be added, omitted, or modified. In addition, the term “coupled” and variants thereof describe the existence of a data transmission path between two elements and do not imply a direct connection between the elements without intervening elements / connections between them. All of these variants are considered part of the description.

DETAILED DESCRIPTION

One or more embodiments of the present invention described herein provide an effective address (EA) based load store unit (EA) for an out-of-order (OoO) processor by dynamically removing entries in a table of effective addresses real addresses in the OoO processor. In addition to other components, the technical solutions described here use a directory of effective addresses (EAD) in conjunction with an effective real table (ERT) and a synonym recognition table (SDT) in order to facilitate a reduction in the chip area and a flow control of OoO -Processors to improve further.

As noted above, because of the OoO nature of modern processors, newer load instructions can be selected to execute before older store instructions to the same real address (RA). If a newer load instruction executes before an older store instruction to the same RA, the newer load instruction will return stale data and instructions in a processor pipeline must be deleted from the pipeline and fetched again to restore program consistency. Typically, it is desirable to delay a newer load instruction until an older store instruction is executed for a same RA so that other independent instructions can be executed and are not unnecessarily deleted from a processor pipeline. One step in reducing deletions from a processor pipeline due to execution of a newer load instruction prior to an older store instruction to the same RA is to identify a load / store sequence directed to the same RA and executing OoO, so that a processor pipeline must be deleted. Alternatively, or in addition, the older load instruction is deleted from a load reorder queue and all subsequent instructions therefrom from the load reorder queue or from an instruction fetching unit (IFU). Deleting an instruction includes sending a delete message (containing a corresponding identifier of the instruction) to the IFU.

Most modern computing devices support virtual storage. Virtual memory is a technique that gives application programs the impression that they have contiguous memory or address space, even though the physical memory may be fragmented and may even spill onto disk. Essentially, the application program receives a view of the memory of the data processing unit, with the application using an EA to access a seemingly contiguous memory in the EA space visible to the application, which is then stored in a physical address of the actual physical memory or memory unit (s ) is implemented to actually perform the access operation. An EA is a value that is used to indicate a memory position to which the operation accesses from the perspective of the entity, e.g. an application, a process, a thread, an interrupt routine, a kernel component, etc. . that the operation issues is to be accessed.

That is, if a data processing unit does not support the concept of virtual storage, the EA and the physical address are identical. However, if the data processing unit supports virtual memory, the EA of the respective operation transmitted by the application is converted by the memory allocation unit of the data processing unit into a physical address that indicates the position in the physical memory or the physical memory unit (s) at which the Operation is to be performed.

Furthermore, in modern data processing units, processors of the data processing units use processor instruction pipelines which have a series of data processing elements in order to process instructions (operations) which are transmitted by entities, eg applications, processes, etc. Instruction pipelining is a technique of increasing instruction throughput by dividing the processing of computer instructions into a series of steps with a save at the end of each step. The instruction pipelining facilitates 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 considerably faster than the time required to perform all the steps simultaneously. Instruction pipelined processors, ie processors placed in a pipeline, are organized internally in stages that can work semi-independently on separate tasks. Each stage is organized and linked to a next stage in an ongoing chain so that the output of each stage is fed to another stage up to the last stage of the pipeline.

Such pipeline processors may take the form of pipeline in-order or out-of-order processors. With in-order processors placed in a pipeline, instructions are executed in order so that if there is no data available for the instruction to be processed at a particular stage in the pipeline, execution of instructions through the pipeline may be delayed until the data is available. On the other hand, pipelined OoO processors allow the processor to avoid delays that occur when the data required to perform an operation is not available. An OoO processor's instruction pipeline avoids these delays by timely filling "areas" with other instructions that are ready to be processed and then rearranging the results at the end of the pipeline to make the instructions appear to be were processed in the order. The way in which the instructions are arranged in the original computer code is called program order, whereas in the processor they are processed in data order, i.e., in the order in which the data and operands become available in the registers of the processor.

Modern processor instruction pipelines track an EA of an instruction as the instruction progresses through the instruction pipeline. It is important to keep track of the EA of the instruction, as this EA is used whenever the processing of an instruction results in an exception occurring, the instruction is deleted to a previous state, the instruction relative to its current storage location to a branches to the new location or the execution of the statement completes.

Tracking the EA of an instruction is laborious in terms of the chip area of the processor, power consumption and the like. This is because these EAs are large in size (e.g. 64 bits) and modern processor instruction pipelines are deep, that is, have many stages, which results 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 is very long. This effort can increase further with OoO processors with strong multithreading, ie with processors that execute instructions from several threads in OoO fashion, since a large number of instructions from different address ranges can be processed "in flight", ie simultaneously .

In one or more examples, computing devices use a combination of pipeline latches, a branch information queue (BIQ), and a global completion table (GCT) to keep track of the EA of an instruction. The base EA for a group of instructions is latched from the front end of the pipeline until it can be placed and tracked in the GCT of the instruction sequencer unit (ISU). The number of latches that are required to store this data is of the order of magnitude of the number of pipeline stages between a retrieval stage and an allocation stage of the pipeline. This is wasteful as the EA is typically not needed during these stages. Rather, it is simply user data that is “carried along” with the instruction group as it runs through the pipeline. In addition, this method leads to double storage, since branch instructions have their EAs in both the BIQ and the GCT.

Accordingly, data processing units have been developed that eliminate this inefficiency by tracking the EA exclusively in the GCT. For example, in these new data processing units, an instruction flow control unit creates an entry in the GCT at the time of the request. The EA is loaded into the GCT at this point and then removed when the statement completes. This eliminates numerous pipeline latches across the machine. Instead of a complete EA that is as long as the number of address lines, for example an EA of 64 bits, a small tag is carried through the pipeline together with the instruction group. This tag points back to the entry in the GCT that contains the base EA for this instruction group. It is no longer necessary to store addresses in the BIQ, since branches can retrieve their EA directly from the GCT when they are output. Such techniques improve area efficiency, but they are not applicable to an OoO processor. Furthermore, they lack sufficient data to process address requests outside of the Arrive program sequence. In addition, these techniques cannot support the allocation and termination bandwidth required for OoO execution because they are unable to keep track of instruction groups that may have been formed from multiple non-contiguous address ranges. In the past, such mechanisms have only supported groups of instructions from a single address range, which can significantly reduce the number of instructions available for OoO execution. A content addressable memory (CAM) is also used to search for corresponding addresses such as an RA that corresponds to an EA (or vice versa). A CAM implements a look-up table function in a single clock cycle using a dedicated compare circuit. The overall function of a CAM is to pick up a search term and return the appropriate memory location. However, such a CAM takes up chip area and consumes power for such searches.

Furthermore, such conversions of an EA into a corresponding RA are typically carried out on a second level of a memory nesting belonging to the processor. As used herein, the term memory interleaving refers to the various types of memories that can be used by a processor to store data. In general, memory interleaving contains a hierarchy of caches and physical memories. Generally, as the level of memory interleaving increases, the distance from the processor to the data increases, and an access latency of the processor to retrieve the data also increases. In this way, converting an EA to an RA slows processor execution.

The illustrative embodiments of technical solutions described herein improve these techniques by providing an Effective Address Directory (EAD), an Effective Real Table (ERT), and a Synonym Recognition Table (SDT) that enhances the area efficiency of the GCT described above Solution, but which can also support a wide-output OoO pipeline without sacrificing performance. The technical solutions described herein also make it easier for processors to only work 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 an instruction pipeline of the processor. By avoiding EA synonyms in the OoO window, the processor reduces the chip area and the power consumption for address translation, since the processor can avoid a translation for the EA in the OoO window.

In other words, the technical solutions described herein address the technical problem by taking action against EA aliasing within the OoO window and in this way reducing conversion data structures and hardware for the load / store connections. Accordingly, the technical solutions described herein facilitate a reduction in chip area by only tracking one address, the EA. Furthermore, the technical solutions make it easier for the OoO processor to work in a 2-load and 2-store mode with subdivided load / store queues, which further reduces the CAM connections that are typically used for address translation.

For example, a processor capable of issuing and executing instructions OoO may allow load instructions to be executed before store instructions. Assuming that a real address (RA) of a newer load instruction does not overlap with an RA of an older store instruction, OoO execution of the newer load instruction and the older store instruction can provide performance advantages. In a typical program, the likelihood that an RA of a newer load instruction will overlap with an RA of an older store instruction (which is executed after the newer load instruction) is relatively small. As is known, a store hit load (SHL) condition is indicated when a RA of a store instruction hits a load relocation queue (LRQ) of a load store unit (LSU). That is, if an RA of a newly issued older store instruction matches an RA of a newer load instruction, which is located in the LRQ of the LSU, an SHL is indicated. However, since a detection of an SHL typically occurs late in an instruction execution pipeline, restoring from an SHL typically results in a relatively severe penalty in processor performance. For example, restoring from an SHL typically includes invalidating the newer load instruction that caused the SHL and reissuing the newer load instruction as well as any instructions issued after the older store instruction.

Furthermore, if, for example, two load instructions are executed to the same address OoO and the value of the data at this address is changed between the executions of the two load instructions (e.g. by another processor), the later (ie, the newer) load receives an earlier (ie, old) value and the earlier (ie, older) store gets a later (ie, new) value. This situation is known as a “violation of the load-load sequence” or as a “load-hit-load” risk. The requirement that if a newer load instruction receives old data, an older load instruction at the same address must not receive any new data, is referred to as "sequential load consistency". In addition, if a later (ie, newer) load instruction is executed before an earlier (ie, older) store instruction to the same address (ie, memory location) completes, the load instruction is given an earlier (ie, old) value. This situation is called "Violation of the load-store sequence" or referred to as a "load hit store (load meets store) risk". (See for example "Power4 System Microarchitecture" by JM Tendler et al., IBM Journal of Research and Development, Volume 46, Number 1, January 2002, pp. 5 to 25 ).

However, the OoO processor using EAs (and not RAs) has technical problems in recognizing the SHL and LHL conditions based only on EAs and achieving further recovery from these situations. Typically, processors have dedicated hardware in order to avoid violations of the load-load and load-store sequence, which helps ensure that the program is correct. However, such hardware is typically complex and introduces time delays. Furthermore, such hardware relies on using RA to detect risk conditions, thereby taking up a larger chip area (for conversion / CAM connections) and more power for the EA-RA and / or RA-EA -Implementation (s) is consumed. The technical solutions described herein address such technical problems using the EA and using indexes of an effective-to-real translation table (ERT) stored with EAD entries. The technical solutions herein use a load-hit-load table to identify load-hit-load risks and react to such situations. In this way, the technical solutions make it easier for the OoO processor to provide less chip area for storing and processing real addresses.

With reference to 1 becomes a block diagram of a system 100 , which includes an instruction sequencing unit (ISU) of an OoO processor for implementing the technical solutions for avoiding EA synonyms in an OoO instruction window, illustrated generally in accordance with one or more embodiments of the present invention. This in 1 illustrated system 100 includes an instruction fetch unit / instruction decode unit (IFU / IDU) 106, the instructions for input into a facility block 108 retrieves and decrypts the decrypted instructions for input into a mapping function 110 prepared by the ISU. According to one or more embodiments of the present invention, six instructions can be issued simultaneously from a thread through the IFU / IDU 106 can be accessed and decrypted. According to one or more embodiments of the present invention, the six can be attached to the device block 108 instructions sent contain 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 device block verifies 108 whether there are sufficient resources such as entries in the output queues, termination table, allocation functions, and register files before the fetched instructions are transmitted to these blocks in the ISU.

In the 1 mapping functions shown 110 assign programmer instructions (e.g. logical register names) to physical resources of the processor (e.g. physical register addresses). In 1 becomes a variety of mapping functions 110 shown, including a condition register (CR) mapping function; a link / count (LNK / CNT) register; 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.

The output from the facility block 108 is also included in a global closing table (GCT) 112 to keep track of all instructions currently in the ISU. The output from the facility block 108 is also in an allocation unit 114 to dispatch the instructions to an output queue. The embodiment of the in 1 The ISU shown contains a CR output queue, CR-ISQ116, which receives and tracks instructions from the CR mapping function and sends them to the instruction fetch unit (IFU) 124 issues 120 to execute CR logic and move instructions. In addition, in 1 a Branch Issue Queue, Branch ISQ 118 , which receives and tracks branch instructions and LNK / CNT physical addresses from the LNK / CNT mapping function. The branch ISQ 118 can send an instruction to the IFU 124 issue to redirect instruction fetching when a predicted branch address and / or direction was incorrect.

Instructions issued by the allocation logic and renamed registers from the LNK / CNT allocation function, the XER allocation function, the UMapper (GPR / VSR), the ARCH allocation function (GPR / VSR) and the FPSCR allocation function are placed in the output queue 102 entered. As in 1 shown tracks the output queue 102 allocated fixed point instructions (Fx), load instructions (L), store instructions (S) and instructions for the vector and counter unit (VSU). As in the embodiment of 1 shown is the output queue 102 split 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 output queue may 102 can be used as a single logical output queue containing both ISQ0 1020 and ISQ1 1021 to process all instructions (all N instructions in this example) of a single thread.

When the processor is running in Multi-Thread (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 .

As in 1 is the output queue 102 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, included in the 1 contain a unit for complete fixed-point execution (complete FX0, complete FX1); a load execution unit (LU0, LU1); one unit for simple fixed point, data memory and address memory execution (simple FX0 / STD0 / STA0, simple FX1 / STD1 / STA1); and a unit for floating point, vector multimedia expansion, decimal floating point and data storage execution (FP / VMX / DFP / STD0, FP / VMX / DFP / STD1). Together the LU0, the simple FX0 / STD0 / STA0 and the FP / VMX / DFP / STD0 form a load storage unit (LSU) 1042 out. Similarly, the LU1, the simple FX1 / STD1 / STA1 and the FP / VMX / DFP / STD1 form a load storage unit (LSU) 1043 out. The two LSUs 1042 and 1043 are collectively called the LSU of the system 100 designated.

As in 1 shown, when the processor is executing in ST mode, the first group of execution units performs 1040 Instructions issued by ISQ0 1020 and executes the second group of execution units 1041 Instructions issued by the ISQ1 1021. In alternative embodiments of the present invention, when the processor is running in ST mode, instructions issued by both ISQ0 1020 and ISQ1 1021 may be in the issue queue 102 are 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 are issued.

In accordance with one or more embodiments of the present invention, when the processor is executing in MT mode, the first group of execution units performs 1040 Instructions of the first thread, which are issued by ISQ0 1020, and executes the second group of execution units 1041 Instructions of the second thread, which are issued by the ISQ1 1021.

The number of entries in the output queue 102 and sizes of other elements (e.g. bus widths, queue sizes) that are included in 1 are intended to be exemplary in that embodiments of the present invention can 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.

In one or more examples, it is the system 100 an OoO processor in accordance with the illustrative embodiments. 2 Figure 13 is an exemplary block diagram of a processor architecture of an OoO processor that implements an EAD and the associated mechanisms for using that EAD in accordance with one or more embodiments of the present invention. As in 2 As shown, 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 passed through the instruction fetch buffer 204 from the instruction cache 202 fetched and the instruction decryption unit 206 provided. The instruction decryption unit 206 decrypts the instruction and provides the decrypted instruction to the instruction dispatch unit 208 ready. The output of the instruction dispatcher 208 becomes the global closure table 210 and depending on the instruction type one or more of the branch issue queues 212 , the condition register output queue 214 , the unified output queue 216 , the load reorder queue 218 and / or the memory reorder queue 220 provided. The instruction type is determined by the decryption and assignment of the instruction decryption unit 206 determined. The output queues 212 to 220 provide inputs for various execution units 222 to 240 ready. The data cache 250 and the register files contained in each respective unit provide the data for use with the instructions.

The instruction cache 202 receives instructions from L2 cache 260 via translation unit 262 the second level and a pre-decryption unit 270 . The implementation unit 262 the second level uses its associated segment relocation buffer 264 and the translation buffer 266 to translate addresses of the fetched instruction from effective addresses to system memory addresses. The pre-decryption unit partially decrypts instructions that arrive from the L2 cache and extends them with unique identification data which simplify the work of the downstream instruction decryption devices.

The ones in the instruction fetch buffer 204 Fetched instructions are also used by the branch prediction engine 280 provided if the instruction is a branch instruction. The branch prediction unit 280 contains a branch history table 282 , a return batch 284 and a counter cache 286 . These elements predict the next EA to be fetched from the instruction cache. A branch instruction is a point in a computer program at which the control sequence is changed. This is the low-level machine instruction generated from control constructs in a computer program, such as If-Then-Else or Do-While instructions. A branch cannot be chosen where the control flow remains unchanged and the next instruction to be executed is the immediately following instruction in memory, or it can be chosen where the next instruction to be executed is an instruction elsewhere in memory. If the branch is chosen, a new EA must be provided to the instruction cache.

The EA and related prediction data from the branch prediction unit are stored in a directory 290 written by effective addresses. This EA is subsequently carried out by the branch execution unit 222 approved. If it is correct, the EA remains in the directory until all instructions from this address range have been executed. If it is incorrect, the branch execution unit clears the address and the corrected address is written in its place. The EEAS 290 also contains a logic unit that facilitates the use of the directory as a CAM.

Instructions reading from or writing to memory (such as load or store instructions) are passed to the LS / EX execution unit 238 , 240 issued. The LS / EX execution unit retrieves data from the data cache 250 using a memory address specified by the instruction. This address is an EA and must first be converted to a system memory address via the second level translator before it is used. If no address is found in the data cache, the load failure queue is used to manage the failure request to the L2 cache. To reduce the cost of such cache failures, the advanced data prefetch engine predicts the addresses that instructions are likely to use in the near future. In this way, data is likely already in the data cache by the time an instruction needs it, thereby preventing a long latency error request to the L2 cache.

The LS / EX execution unit 238 , 240 executes instructions out of program order by keeping track of instruction age and memory dependencies in the load reorder queue 218 and the store reorder queue 220 out. These queues are used to detect when the OoO execution produced a result that is inconsistent with the order of execution of the same program. In such cases, the current program sequence is deleted and carried out again.

The processor architecture also contains the EAD 290 that centrally maintains the effective address of a group of instructions so that the EA is available when needed but does not need to be piped. In addition, the EEAS 290 circuit and / or logic to support OoO processing. 2 represents the EEAS 290 to the one about the branch prediction unit 280 is accessed, however, it should be understood that circuitry can be provided to allow various of the features shown in FIG 2 units shown on the EAD 290 without the branch prediction unit 280 having to go through.

It will be apparent to those skilled in the art that the hardware in 1 to 2 may vary depending on the implementation. Other internal hardware or peripheral units such as a flash memory, an equivalent non-volatile memory or optical disk drives and the like can be used in addition to or instead of the in 1 to 2 hardware shown. In addition, the processes of the illustrative embodiments can 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.

In addition, the data processing system 100 take the form of any of a number of different computing systems including client computing devices, server computing devices, a tablet computer, laptop computer, telephone or other communications device, personal digital assistant (PDA), or the like. In some illustrative examples, the data processing system may be 100 be a portable data processing unit which is set up with a flash memory to provide a non-volatile memory for storing, for example, operating system files and / or data generated by a user. Basically, it can be the data processing system 100 be any known or later developed data processing system without architectural restriction.

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

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 that store that software. The computer usable or readable medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or system -unit, without being limited to them. 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. only memory, EPROM or Flash memory) etc.

Typically, for each load and each store instruction, an EA is converted into a corresponding RA. Such a conversion of an EA into an RA is also carried out for an instruction fetch (I-Fetch). Such a conversion typically required an effective to real address table (ERAT) for retrieving instructions from lower order memory. In the technical solutions described here, the conversion of an EA into an RA is not carried out for every loading and storage instruction, but only in the event of loading errors, I-Fetch errors and all saves.

By using only EA for the operations, the technical solutions make it easier to remove RA bits (for example the bits 8th to 51 ) from one or more data structures such as an EA directory (also referred to as an L1 directory), LRQF entries, LMQ entries. Furthermore, no SRQ-LHS-RA comparison logic is carried out if only the EA is used. Removing such elements reduces the chip area of the processor used, which makes it easier to reduce the chip area compared to typical processors.

By using EA only, the technical solutions herein eliminate ERAT camming operations each time load and store addresses are generated. The technical solutions also eliminate switching of an RA bus in the entire unit and also avoid a fast SRQ-LHS-RA camming process. The technical solutions thus make it easier for the processor to consume less power compared to typical processors by not performing the above operations.

The technical solutions herein also facilitate improvements in the L1 latency even further. For example, the technical solutions herein are by eliminating the address conversions at least 1 cycle faster in determining a "final Dval" compared to typical processors that do the conversions from EA to RA. Latency is also improved because using EA only (no RA conversion) eliminates (a) "bad Dval" condition (s) such as multiple facility table hits, facility table hits / RA errors, and the like. Similarly, the technical solutions herein facilitate an improvement in L2 latency.

The technical problems when using only one LSU based on EA include that executing the instructions out of sequence can lead to risks (LHL, SHL, LHS) and that such risks have to be identified without corresponding real addresses for a pure EA implementation can be used. The technical solutions described herein address one such technical problem. The RA is not used for the detection of risks of an OoO execution of the type load-hit-store, store-hit-load or load-hit-load as it is typically used. The RA computation for stores takes place before the store is completed, as no interrupt is processed for the store instructions after completion (a store can generate an address translation related interrupt that must be processed before the store completes). Here the RA calculation is performed when saving is issued (and not when purging). The technical solutions described here determine LHS (Load-Hit-Store), SHL (Store-Hit-Load) and LHL (Load-Hit-Load) on the basis of the EA and the ERT index that is stored with the EA directory entries , and furthermore using a load reorder queue (LRQF) having a structure and operation as described herein.

Referring again to the figures, represents 3 a load storage unit (LSU) 104 of a processing core in accordance with 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 here are not restricted to such an LSU. The execution sequence for the LSU is described below. The EA (as used by the programmer in a computer program) is generated from the load or save instructions. In a similar way, an EA is also generated for an instruction call. In addition to other technical problems, the EA was typically converted into an RA (a real address as used by the hardware after an EA-RA conversion) for each instruction, which required a larger chip area and frequent conversions. The technical solutions described here deal with such technical problems by using only the EA (without conversion to an RA) and only an effective real table (ERT) for load errors, I-fetch errors and saves. 255 use to generate the RA.

The LSU 104 contains a load relocation queue (LRQF) 218 which tracks all load operations from allocation to completion. The LSU 104 also includes a second load reorder queue LRQE 225 . If a load is rejected (in the event of a cache or translation error, or if a previous instruction on which it depends was rejected), the load is removed from the output queue and placed in an LRQE entry to be reissued from there becomes. The illustrated LRQE 225 is divided into 2 instances, LRQE0 and LRQE1 for the two-load mode with 12 entries each (a total of 24 entries). In ST mode, there is no subdivision based on threads / pipes. In MT mode, T0, T2 operations were started in the pipe LD0; and T1, T3 operations were started for a restart in the pipe LD1.

As shown, the LRQF is 218 divided into 2 instances LRQF0 and LRQF1 for the two-load mode with 40 entries each (for each instance). The LRQF 218 is revolving with respect to an order of entry allocation, revolving with respect to an order of entry cleanup, and revolving with respect to an order of entry release. In addition, T0, T2 operations in pipes LD0, ST0 were started in MT mode; and T1, T3 operations were started in pipes LD1, ST1. In ST mode, the LRQF has no pipes / threads.

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

In one or more examples, the LRQF is 218 (and other structures described herein) for SMT2 mode divided into T0: LRQF0 [0 to 39] wraparound queue, T1: LRQF1 [0 to 39] wrap around queue. Also in one or more examples for ST mode in an LRQF0 [0 to 39] wraparound queue, where LRQF1 is a copy of 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.

In the event of a deletion for mutual cancellation (cross invalidation flush, XI flush), any thread encountered by an XI or a garbage collector from another thread is deleted for the LRQF by NTC + 1, so that the XI deletion by the LSU 104 no explicit deletions in L / L order are performed during synchronization.

All storage is based on the LRQF 218 checked for an SHL detection, whereupon the LRQF 218 initiates a deletion of any load or all processes (any instructions / operations) after saving. Furthermore, DCB instructions are based on the LRQF 218 checked for SHL cases, whereupon the LRQF 218 causes a deletion of the load or all processes after the DCB. Furthermore, all loads are based on the LRQF 218 checked for an LHL detection (sequential load consistency), whereupon the: RQF 218 causes the newer load or all processes after the older load to be deleted. In one or more examples, the LRQF 218 a quadruple word atomicity ready, and the LQ compares the LRQF 218 to quadruple atomicity and clears the QL if it is not atomic. In the case of LARX instructions, the LSU checks 104 based on the LRQF 218 to Larx-Hit-Larx cases and in response deletes newer LARX or everything after the older LARX instruction.

In this way, the LRQF facilitates 218 keeping track of all loads from issue to completion. Entries in the LRQF 218 are indexed with 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 with a Virtual_Ltag (vltag) that is in the sequence. The LRQF clears a store using GMASK and performs a subgroup clear using GTAG and IMASK. The LRQF logic can delete from a current iTag or iTag + 1 or precisely load an iTag.

Furthermore, the LRQF does not contain a typically used RA field ( 8th to 51 ) and is instead based on an EA and contains an ERT-ID ( 0 to 6th ) and an EA ( 40 to 51 ) (a saving of 24 bits). The LRQF page match for SHL, LHL is based on an ERT-ID match. Each LRQ entry also has a “Force Page Match” bit. If an ERT-ID that matches the ERT-ID of the LRQ entry is invalidated, the Force Page Match bit is set. The LRQ recognizes LHL, SHL, and deletions in storage order associated with any entry with force match = 1.

The SRQ 220 the LSU 104 exhibits a structure similar to the LRQF 218 with two instances SRQR0 and SRQR1 of 40 entries (in each instance) which are circulating with regard to an order of entry allocation, are circulating with regard to an order of entry cleaning and are circulating with regard to an order of entry release. Furthermore, the SRQ 220 similar to the LRQ 218 divided, for example into T0, T2 operations that are started in the pipes LD0, ST0; T1, T3 operations that are started in the pipes LD1, ST1; and no pipe / thread division in ST mode. In the ST mode, both copies have identical values, whereas the copies in the MT modes are different. In SMT4 mode, both instances are further subdivided, with each thread 20th Entries from the SRQ 220 (see an exemplary subdivision for the LRQF described herein). In one or more examples, an intra-SRQ read pointer multiplexing is performed in the SMT4 mode for memory erasure arbitration. Alternatively or additionally, an inter-SRQ0 / 1 multiplex method is carried out in the modes SMT2 and SMT4. In the ST mode, a cleanup is only performed on SRQ0.

Every entry in the SRQ 220 contains a memory 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 {Memory Tid, EA (44 to 63)}, which eliminates the RA LHS alias check. The ERT-ID is used to "record" a false assumption of an EA (44 to 63) partial match. The SRQ entry has the RA (8 to 51), which is implemented at Store Agen and is only used when storage 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 if an ERT-ID is invalidated that matches the ERT-ID of the SRQ entry. The SRQ can recognize an LHS that is associated with any entry with Force Page Match = 1. For example, an LHS at an entry with Force Page Match = 1 causes the load instruction to be rejected. In addition, garbage collection forces an error in the L1 cache if Force Page Match = 1 applies to the SRQ entry. This works in conjunction with “Extended Store Hit Reload” LMQ operations.

For example, an LMQ has an LMQ address match = {ERT ID, EA page offset (xx to 51), EA (52 to 56)}. In addition, a “Force Page Match” bit is set for each LMQ entry (= 1) if an ERT-ID that matches the ERT-ID of the LMQ entry is made invalid. The LMQ rejects a loading error if a valid LMQ- Entry [x] ForcePageMatch = 1 and an Ld-Fehler-EA [52 to 56] = LMQEntry [X] EA (52 to 56) is present. The LMQ also has an extended store hit reload. For example, the LMQ suppresses activation of a reload if Reload EA (52 to 56) = SRQEntry [X] EA (52 to 56) and SRQEntry [X] ForcePageMatch = 1. Alternatively or in addition, the LMQ suppresses activation of a reload if LMQEntry [X] EA (52 to 56) = StDrain EA (52 to 56) and StDrainForcePageMatch = 1.

The LSU shown 104 compresses a Store Data Queue (SDQ) as part of the SRQ 220 even to save even more chip space. 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. In the case of 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 SRQ0 and SRQ1, for example 8 bytes each.

The SRQ 220 queues operations of the type stores, blocks, DCB, ICBI or operations of the type TLB. 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 charges issued are checked by the SRQ 220 checked to make sure there are no older stores with a data conflict. For example, the data conflict is recognized by comparing flags for load I / O and data bytes with older stores in the SRQ I / O array.

SRQ entries are assigned when they are assigned, with the assigned instruction tags (itags) being entered in the correct line. In addition, SRQ records are freed during a garbage collection. In one or more examples, the Itag arrays contain "overflow" allocations. For example, data is written to the Itag array during an allocation if the desired line in the SRQ, for example the SRQ entry x, is still in use. When the SRQ entry x is released, its corresponding line in the SRQ overflow Itag structure is read out and copied into the main SRQ Itag array structure (reading of the overflow Itag structure, which is controlled by whether there are valid entries in the overflow itag array for a respective thread / area). A camming process (or a ½ process in the case of SMT4) is performed on the main SRQ-0/1-Itag array to determine which physical line is to be written to when a store is output, so that the ISU stores based on the Itags. The SRQ 220 sends the Itag to the ISU when a store is cleaned up & released.

The ISU allocates memory allocations to virtual sub-areas in order to avoid problems due to overlapping. For example, the ISU does not give a virtual SRQ entry in ST mode 40 until the real SRQ entry 0 by cleaning up an entry 0 is released from memory. In addition, the ISU can use the virtual Tx-SRQ entry in SMT4 mode 20th only output when the real Tx-SRQ entry 0 cleaned up and released. The ISU divides each thread division further into 4 areas.

For example, for the ST mode, the SRQ 220 divided into 4 sub-areas: Ping A: SRQ entries 0 to 9 , Ping B: SRQ entries 10 to 19th , Ping C: SRQ entries 20th to 29 , Ping D: SRQ entries 30th to 39 , and Pong A: SRQ entries 0 to 9 , Pong B: SRQ records 10 to 19th , Pong C: SRQ entries 20th to 29 , Pong D: SRQ records 30th to 39 . Initially, the ISU issues ping A, B, C, D-Itags. Furthermore, the ISU will not issue Pong-A-Itags until Ping-A-Itags have been released. After all Ping-A-Itags have been released, the ISU will then issue Pong-A-Itags, but will not issue Pong-B-Itags until Ping-B-Itags have been released, similar to Case A. In one One or more examples, the ISU contains 3 additional bits in the entry of the output queue (1 wrap bit + 2 bits to describe the sub-area) in order to create a pseudo-output dependency based on the sub-area.

4th Figure 13 is an exemplary block of a directory of effective addresses (EAD) structure (L1 cache) 290, according to an illustrative embodiment. In one or more examples, the EAD is part of the LSU 104 . As in 3 shown, the EEAS exists 290 from one or more entries, e.g. entry 0 through entry N, each entry having a plurality of fields of data relating to a group of one or more statements. For example, in one illustrative embodiment, each entry in the EAD 290 represent between 1 and 32 statements. Entries in the EAD 290 are generated in response to a fetch of an instruction residing in a new cache line of the processor cache, e.g., L2 cache 260 in FIG 2 . The entry in the EAD 290 updated when additional instructions are fetched from the cache line. Every entry in the EEAS 290 is selected on a branch chosen (ie, a branch instruction fetched from the cache is resolved as "chosen"), a cache line exceeded (ie, the next instruction fetched is in a different cache line than the current cache line) or a clearing of the processor pipeline (for example, if an incorrect branch prediction or the like occurs) has ended.

As in 3 shown, indicate the fields of the entry in the EAD 290 an effective base address 310 , an identifier 320 a first instruction, an identifier 330 a final instruction, a closed identifier 340 , a field of a global history vector 350 , a field 360 a link stack pointer, an identifier 370 a selected branch and a branch data field 380 on. The EEAS 290 is organized like an L1 data cache. An associative organization is established. For example, one or more examples are 32 indices, through an EA ( 52 to 56 ) addressed in 8 ways, selected with EA ( 0 to 51 ).

With the basic EA 310 it is the starting I / O 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 that contains the bits 0 to 63 having. The base EA, in an illustrative embodiment, may contain the bits 0 to 56 this EA include, the bits 57 to 61 represent the offset from the base EA for the specific instruction within the group of instructions. The bits 62 and 63 refer to a specific byte of each instruction. In the illustrative embodiment, each address points to an instruction 32 bits (ie, 4 bytes) in length, with each byte being addressable in memory. An instruction cannot be further divided into addressable sub-components, and therefore the bits for an instruction address 62 and 63 always set to zero. Hence the bits 62 and 63 are not saved and can always be assumed to be zero by the EAD.

The identifier field 320 of the first instruction stores the IO offset bits, e.g. the bits 57 to 61 the EA, for the first instruction in the group of instructions, that is the entry in the EAD 290 corresponds to. A combination of the basic I / O from the field 310 and the EA offset bits in the identifier field 320 of the first instruction provides the EA for the first instruction in the group of instructions identified by the entry in the EAD 290 is shown. This first field 320 As discussed below, it can be used to restore a retrieval address and branch prediction data in the event that the pipeline is deleted, for example.

The identifier field 330 the last instruction saves the IO offset bits, e.g. the bits 57 to 61 the EA, for the last instruction in the group of instructions, that is the entry in the EAD 290 corresponds to. EAD logic updates this field when there are additional instructions in the set of instructions identified by the entry in the EAD 290 can be displayed. The EAD logic provides the update of this field 330 in the respective entry in the EAD 290 in response to that the entry is in the EAD 290 is closed when a cache line exceeded or a selected branch is detected. This field is preserved unless a pipeline delete occurs that removes a portion of the EAD entry. In such cases, the EAD logic updates this field to store the IO offset bits of the instruction which, as a result of the deletion, is now the new last instruction in the entry. This field is ultimately used to complete the entry in the EAD, as discussed below 290 to release.

The closed identifier field 340 is used to indicate that the entry is in the EAD 290 has been closed and no further instruction fetches are made to fetch instructions for the instruction set corresponding to the entry in the EAD 290 corresponds to. An entry in the EAD 290 can be inferred from a variety of different reasons, including a cache line violation, a chosen junction, or a pipeline clearing. Any of these conditions can cause the value in the Closed field 340 is set to indicate that the EAD entry is closed, e.g. set to a value of "1". This field 340 is used on completion to make an entry in the EAD 290 as discussed in more detail below.

The field 350 of the global history vector identifies the global history vector for the first instruction fetch group containing the entry in the EAD 290 created. The global history vector is used to identify a history in terms of 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 chosen based on the most recent history of chosen or unselected branches.

The field 360 of the link stack pointer identifies the link stack pointer for the first instruction fetch group containing the entry in the EAD 290 created. The link stack pointer is another Branch prediction mechanism, which is described in more detail below.

The field 370 of the selected branch indicates whether the entry in the EAD 290 corresponding group of instructions had a branch instruction in which the branch was selected. The value in the field 370 the selected branch is updated in response to a branch instruction of the instruction set identified by the entry in the EAD 290 is represented as is predicted to be elected. In addition, after a branch in the instructions of the entry in the EAD 290 has been chosen, the entry in the EAD 290 also closed by entering the corresponding value in the closed field 340 is written. Since the field of the chosen branch is written speculatively at prediction time, it may need to be replaced with the correct value if the branch is actually taken. For example, a branch could be predicted as not chosen, in which case a “0” would be written in the field of the chosen branch. In the further course of the execution, however, it could turn out that the branch was selected, in which case the field must be corrected by writing a value "1" into it. The second write occurs only if the branch was mispredicted.

The branch data field 380 stores various branch data used to update branch prediction structures when a branch is resolved or an EA structured state when a branch instruction completes.

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

• eatag(0 bis 9)=Zeile(0 bis 4)||Versatz(0 bis 4)
• Zeile(0): Wrap-Bit für das EAD, das angibt, ob ein Umlaufen von dem obersten Eintrag zu dem untersten Eintrag des EAD aufgetreten ist.
• Zeile(1 bis 4): Index in dem EAD mit 14 Einträgen wird verwendet, um die EA(0 bis 56) der Anweisung zu ermitteln.
• Versatz(0 bis 4): Bits 57 bis 61 der EA der Anweisung.

On entries in the EEAS 290 is accessed using an effective address tag (eatag) that has at least two parts: a base eatag and an eatag offset. In an illustrative embodiment, this eatag is a 10-bit value, which is relatively much smaller than the 64-bit EA. With a 10-bit Eatag value and an EAD 290 With a size of 14 entries, in an exemplary implementation the Eatag consists of the first 5 bits, which are referred to as the base Eatag, around an entry within the EAD 290 and the second 5 bits called the Eatag offset to provide the offset of the specific instruction within the group of instructions identified by the entry in the EAD 290 is shown. A first bit in the 5 bits that make up the entry within the EAD 290 can be used as a wrap bit to indicate whether there is a wrap around from the top entry to the bottom entry of the EAD 290 occured. This can be used for age detection. The second through fifth bits of the 5 bits that make up the entry in the EAD 290 can be used for indexing in the EAD to indicate the base EA of the instruction, i.e. the EA ( 0 to 56 ). The 5-bit offset value can be used for this, for example the bits 57 to 61 to provide the EA of the respective instruction. This exemplary Eatag is illustrated below:

• eatag (0 to 9) = line (0 to 4) || offset (0 to 4)
• Line (0): Wrap bit for the EAD, which indicates whether a wrap around from the top entry to the bottom entry of the EAD has occurred.
• Line (1 to 4): Index in the EAD with 14 entries is used to determine the EA (0 to 56) of the instruction.
• Offset (0 to 4): Bits 57 to 61 of the EA of the instruction.

5 FIG. 10 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 includes 255 128 Entries in total, however, it should be noted that the total number of entries in other examples can be different, and further that the number of entries can be selectable or programmable. In the event that the LSU executes two instructions in parallel via separate threads, the LSU manages two instances of the ERT 255 with 64 (half) entries each, for example an ERTO and an ERT1. In the following description, any one of these instances is described unless otherwise indicated.

The ERT 255 contains a valid ERT entry, which generally exists for every page stored in the L1 I-cache or -D-cache directory (EAD 290 ) is active, or an SRQ entry or an LRQF entry or an LMQ entry. In other words, at ERT 255 it is a table of all active RPNs in the LSU and the IFU (L1-DC, SRQ, LRQE, LRQF, LMQ, IC). In one or more examples, if the processor 106 works in ST mode, all entries in the ERT 255 used for the single thread that is running. Alternatively, in one or more examples, the entries in the ERT 255 divided into sentences, and in the ST mode, each sentence has the same content. When the ERT 255 for example has a total of 128 entries and supports a maximum of two threads, the ERT 255 when the processor is in ST mode, two sets of 64 entries each, and the two sets have the same content.

When the processor 106 works in MT mode, the ERT entries are alternatively divided among the executed threads. For example, in the case of two threads, the ERT entries are split 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 errors, ST0 pipe starts, T0 / T2 I fetches: ERT0 that processes T0 in SMT2 mode and T0 / T2 in SMT4 mode; and 1 copy for LD1 pipe L1 errors, ST1 pipe starts, T1 / T3 I fetches: ERT1 which processes T1 in SMT2 mode and T1 / T3 in SMT4 mode.

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), Page Size (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 can contain a sequential number that identifies the ERT entry. The ERT_ID is in the field 285 ERT_ID 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 ID of the instruction that uses the ERT entry. The page size also indicates the memory page size to which the ERT entry relates. The RA contains a real address that is associated with the ERT entry.

The LSU only then refers to the ERT 255 when the RA is to be used to complete an execution of an instruction. As described herein, the ERT 255 used by the LSU for the following four functions, 1. Ifetch, load or store errors in the L1 cache; 2. Saves from another thread within the core; 3. Snoops (XI) from another core; and 4. Invalidating TLB and SLB.

In the first case of ifetch, load or store errors in the L1 cache, the EA and the Thread_id are used in the ERT 255 to index, and the RA from the corresponding ERT entry is sent to the L2 cache if there is a valid ERT entry. In the event of an ERT error, i.e. if there is no valid ERT entry for the EA and the Thread_id, the SLB / TLB is used.

In the second case, when another thread is saving within the core, a save that has been cleaned up from the SRQ checks the ERT 255 . If there is no hit from another thread, there is no load from another thread using the same RA. If there is a hit from another thread using the same RA, the LSU checks the LRQ. Although rarely, if there is a hit from another thread when the RA is in use by one or more other threads. The LSU searches the ERT table accordingly 400 to find the relevant EA (s) for the common RA. Then the EA (s) is / are used to search for a match in the LRQ (to reject all memory outputs in this cycle). The LRQ is subdivided for each thread so that the LSU only examines the LRQ of the relevant thread. If there is (a) corresponding charge (s) in the LRQ, the LSU will delete the oldest of the corresponding charge (s).

In the third case of a snoop process from another core of the processor, the LSU works similarly to the second case and checks for a hit from one of the other executed threads. If the TLB / SLB are invalidated, the ERT 255 also invalidated.

The LRQF 218 comes along with the ERT table 400 used to identify and process risks such as LHL, SHL and LHS. For example, each memory instruction is based on the LRQF 218 checked for detection of an SHL, and if a load instruction is in the LRQF 218 for the same EA as is present in the storage instruction, the storage instruction and other entries from it are deleted in the IFU or the load instruction is removed from the LRQF 218 deleted. In the case of DCB instructions, the instructions are also based on the LRQF 218 checked for SHL cases, and a load instruction and everything after the DCB is deleted, or the load instruction is deleted. For every record that the system 100 configure an appropriate data control block (DCB) and data definition (DD) statement, or their dynamic mapping equivalent.

Furthermore, in one or more examples, when data is moved in and out of physical storage locations in system storage (e.g., in response to a new process being invoked or a context switch), the entries in the TLB are updated to reflect the presence of the new data, and the TLB entries associated with data that has been removed from system memory (e.g. into a non-volatile Mass storage devices have been swapped out) must be invalidated. Typically, invalidation of TLB entries is the responsibility of software and is accomplished by executing an explicit TLB entry invalidation instruction (e.g., TLBIE in the POWER ™ instruction set architecture (ISA)). The LRQF 218 provides TLBIE support by issuing a TLBIE statement to mark the entries in the LRQF 218 relieved, the LRQF 218 indicates whether valid entries are marked.

Furthermore, each loading instruction is based on the LRQF 218 checked for LHL detection (sequential load consistency), and in the case of an LHL, the newer load instruction is deleted or everything is deleted after the older load instruction.

Each LARX instruction is even further based on the LRQF 218 checked for Larx-Hit-Larx cases, and if the situation is detected, the newer LARX instruction is deleted, or everything after the older LARX instruction is deleted.

In this way, the technical solutions described here facilitate the identification of risks with EA only and without EA-RA implementation for each loading and storage path, which is important in terms of both time and chip area (to provide RA and CAM connections for saving an implementation) is more complex. Furthermore, the technical solutions facilitate improved process control in order to recognize an SHL and to suppress a DVAL in good time.

6th Figure 3 illustrates a flow diagram of an exemplary method of accessing memory for execution of instructions by an LSU in accordance with one or more embodiments of the present invention. The instruction can be a load, a store, or an instruction fetch for the OoO processor 106. When 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 in 505 and 510. In one or more examples, the parameters used for checking contain, among other things, a thread ID, a page size, an EA.

If there is an EAD hit in the EAD in the LSU 290 comes, that is, the EA of the instruction matches an entry in the EAD table 300 matches, 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 field 285 ERT_ID (0 to 6). As previously described, when an ERT entry is invalidated, the associated ERT_ID is invalidated, which also causes all associated entries in the EAD table 300 invalidated. Correspondingly, an EAD hit implies an ERT hit, since the field is used 285 ERT_ID an ERT entry for the load / save instruction can be found. Accordingly, in the case of the EAD hit, the LSU reads out the ERT_ID from the EAD entry after identifying the corresponding 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 recognized EAD entry. For store 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 that implements the technical solutions herein is referred to as the EA-only core, since the RA is not used anywhere except in the store instructions.

The following will consider the case where the instruction does not hit the EAD 290 that is, the EA of the statement does not have a corresponding entry in the EAD table 300 having. The Thread_id and the EA are taken from the ERT 255 as shown in 550. If there is an ERT hit, i.e. an ERT entry matches the parameters, the LSU reads the RA ( 8th to 51 ) from the ERT entry, as shown in 555 and 530. For load requests, the LSU sends the RA for access 530 to the L2 cache. For store instructions, the LSU stores the RA in the SRQ and then sends the RA to the L2 cache when the store in the L2 cache is cleaned up, as illustrated in 540-545.

If an ERT error occurs, the LSU initiates a reload for the ERT 255 as shown in 555 and 560. An exchange of ERT entries is also initiated. The exchange of ERT entries is based on the LRU, and the LSU ensures that synonyms are followed within the OoO window during this process.

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

In addition, the LSU must go through the ERT table in the method for storage described here in order to determine the RA, which is then stored in the SRQR in order to go down to the caches ( L1 , L2 , Memory) too Purge when the store is purged from the SRQ. The SRQR stores all RA for the stores. The RA is stored in the nest for cleaning only (ie, L2, storage, and other units of the storage subsystem). The RA is not used to identify risks of OoO execution of the load-hit-store, store-hit-load or load-hit-load types, as is the case with typical solutions. The RA calculation for stores takes place before the store is completed, since after completion the LSU is unable to process an interrupt for the store (a store can generate an interrupt related to an address translation that must be processed, before saving is completed). Here the RA calculation is performed when the store is issued (from the SRQR), which prevents the LSU from having to perform the address translation. In this way, saves are issued and executed out of order, and then complete in order, and then the in-order saves are purged from the SRQ. Until a save is cleaned up, no other thread or core has knowledge of the save (only the current thread has knowledge of it). After the store has been cleaned up from the SRQ, it is written to the L1 (if the line already exists in the L1) and L2 caches (if caching is enabled), and at this point the store is all other threads and cores in the system 100 known.

For instruction fetches that do not have a hit in the L1 I-Cache based on EA, the EA is determined using the ERT 255 is converted to an RA and the RA is sent to the interleave to fetch the I-cache line. LHS (Load-Hit-Store), SHL (Store-Hit-Load) and LHL (Load-Hit-Load) are all determined on the basis of the EA and the ERT index, which is based on the directory entries in the L1 cache Basis of EA (EAD 290 ) is saved. All entries in the EAD table 300 assign their valid implementation in the ERT table 400 that can be used once LHS, SHL, and LHL have been determined. When an ERT entry is invalidated, the corresponding L1 cache entries are invalidated.

The LRQF, which is the load reorder queue, ensures that all loads are tracked from dispatch to completion. If a load is refused (in the event of a cache or translation error, or if a previous instruction on which it depends was refused), the load is removed from the output queue and placed in the LRQE to be reissued from there.

6th Figure 11 illustrates a flow diagram for a method of reloading the ERT in accordance with one or more embodiments of the present invention. Reloading the ERT causes an entry to be created or updated in the ERT in response to and based on the ERT error. The ERT receives the RA, that of the ERT 255 is to be added and compares the RA with each entry in the ERTO and ERT1, as shown in 605. If the RA in the ERT 255 does not exist and if a new entry can be created, the ERT 255 a new entry with a new ERT_ID to store the RA as shown in 610 and 615. The new entry is created in ERTO or ERT1 on the basis of whether the thread being executed is the first thread or the second thread. When the processor is operating in ST mode, the ERTO is updated. When 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 illustrated in 615.

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 compares 255 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 newly loaded RA, the existing entries for this RA will be removed from the ERT 255 is removed 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 is the same or a larger page size, and if the implementation uses an SDT, an entry is created in the SDT for the newly loaded RA, as shown in 627.

If the page size of the existing entries matches the size of the newly loaded RA, the ERT checks 255 whether the existing entry is in the local ERT for the running thread, as shown in 630. In this case, a local ERT refers to the ERT that belongs to the thread being executed, 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, the ERT that is not the local ERT, creates the ERT 255 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 the ERTO with an ERT_ID that matches that of the entry in ERT1.

If the RA hit is in the local ERT instance and if the EA also matches because both the EA and the RA match an existing entry, but an ERT error has occurred for this thread, which leads to a reload When the ERT asks, the ERT assumes that this indicates that the two threads are sharing 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 for the bit corresponding to the newly loaded thread is turned ON to indicate this case, as shown in 634.

If the RA hit is in a local ERT instance, the EA does not match the existing entry, and if the existing entry is for the same thread as the newly loaded RA, the ERT detects the aliasing case in which two different EA from the same thread can be assigned to the same RA, as shown in 636. If the processor uses an implementation based on an SDT, a synonym entry is installed in the SDT that corresponds to the ERT ID, the EA offset ( 40 to 51 ) of the existing, matching entry.

If the RA hit is in the local ERT instance, the EA does not match the existing entry, and if the existing entry is for a different thread, the ERT detects the aliasing case where two EAs of different Threads are assigned to the same RA, as shown in 638. If the processor uses an implementation based on an SDT, a synonym entry is installed in the SDT that corresponds to the ERT ID, the EA offset ( 40 to 51 ) of the existing, matching entry.

The above method facilitates that in an implementation based on an SDT, if two threads have the same RA but different EA, one of the implementations will use the ERT entry and the other will use the SDT entry. In this way, the ERT entries facilitate the case where the same EA and 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 instance ERTO; and Tid_en (0 to 1) = {tid 1 en, tid 1 en} in the instance ERT1. Furthermore, the ERT entry facilitates the case in which the same EA corresponds to different RAs across different threads, in that there are several entries in the ERTO and ERT1 with their respective thread IDs. The ERT entries also support the case with different EAs corresponding to the same RA (in cases with either the same or different threads). The following describes two cases based on implementation using an SDT.

The LSU installs an entry in the SDT (Synonym Recognition Table) instead of the ERT 255 if, at the time of reloading the ERT, a new instruction is recognized with a different EA that corresponds to the same RA. The SDT hits are restarted with the EA of the original (or earlier) ERT entry. If the size of the new synonym page is larger than the page size in the existing ERT entry with matching RA, the existing ERT entry will be replaced with the new synonym (with the larger page size) instead of installing a synonym in the SDT. The old ERT entry is finally reinstalled as a synonym in the SDT.

With reference to the ERT cases, consider the case in which the LSU snooped from another core by the processor 106 receives. The snoop can originate from another core in the system (the snoop indicates another core or thread has changed the data at the same real address). The LSU also checks stores from a thread within the core as a potential snoop with the other threads within the core. All snoops (from other cores) or saves (from other threads within the core) are accompanied by an RA. In such cases, the LSU converts the RA back to the corresponding EA, ERT_ID and page size based on the ERT 255 to determine. The LSU compares this data with the ERT_ID, PS, EA ( 40 to 56 ) that are stored in each of the following structures in order to detect a snoop hit and take the appropriate action. For example, if a snoop hit is detected in an LRQF entry, the LSU will indicate a potential risk of a load hit load out of order. If in the EAD 290 a snoop hit is detected, the LSU initiates an L1 invalidation if the snoop originates from another core. If the save comes from another thread for a shared row, the row automatically receives the new save and is updated.

If the LSU is using an SDT and there is a snoop hit in the LMQ, the LSU also updates the LMQ entry so that it is not stored in the L1 cache, the SRQ entry not for snoops in the SRQ used, but only for an LHS style review EA Error RA Hit is used and a new SDT entry is created for the Snoop Hit.

und $$\text{Tid}=\text{w},\text{ EA }\left(0\text{ bis }51\right)=\text{ y }=>\text{ RA}\left(8\text{ bis }51\right)=\text{z}\text{.}$$

As previously described, there is consequently a technical problem in the LSU which is based only on EA, with an execution flow described herein in an EA synonym in a thread. For example, the same thread EA synonyms (that is, two different EA from one thread are associated with the same RA). Such a technical problem can extend over LHS, SHL, LHL if the OoO window has at least two L1 accesses, for example: $$\text{Tid}=\text{w},\text{EA}\left(0\text{to}51\right)=\text{x}=>\text{RA}\left(\mathrm{8th}\text{to}51\right)=\text{z};$$

and $$\text{Tid}=\text{w},\text{EA}\left(0\text{to}51\right)=\text{y}=>\text{RA}\left(\mathrm{8th}\text{to}51\right)=\text{z}\text{.}$$

The technical solutions described herein address the technical problem using an SDT, which is another LSU sub-unit. In one or more examples, the SDT contains 16 Entries for handling cases where different EAs have the same RA. Such different EAs are called synonyms because they are all converted into the same RA. The SDT is a table of such synonyms in the LSU. The SDT is accessed in the event of an AGEN (address generation) in the event of ERT errors. In one or more examples, the SDT can be accessed with restrictions, for example only if there is a valid SDT entry for the L / S operation thread that is Agen.

8th provides an exemplary structure of a synonym recognition table (SDT) 800 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 the SDT 800 other examples may contain a different number of entries than this example. An entry in the SDT 800 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)}. In one or more examples, each entry may also contain a 'Validity' field (not shown) that indicates whether the SDT entry is valid. In cases of instructions in which starts do not hit the L1, the LSU compares the instruction with the SDT 800 . If the started instruction has an SDT hit when compared with the original address, the LSU rejects the instruction and restarts the instruction with the corresponding substitute address from the SDT entry. For example, the LSU uses the substitute addr ( 40 to 51 ) for the SRQ-LHS and “Force Match” for the ERT ID in the execution pipeline.

During the reloading of the ERT, as described herein, the SDT 800 an entry added. During the reloading of the ERT, for example, the reloaded RA is compared with valid ERT entries. If an ERT entry with a corresponding RA already exists and it is not a case of an EA hit in which only an additional bit tid_en is set in the original ERT entry, the EA ( 32 to 51 ) is read from the existing ERT entry and becomes an entry in the SDT 800 installed instead of the ERT 255 add an entry.

Since the SDT 800 has a limited number of entries, the entries are replaced. In one or more examples, entries are replaced based on least recently used (LRU) techniques or in any other order. In one or more examples, when an SDT entry is replaced, a subsequent start using the secondary address will re-initiate the SDT entry's installation process. The CAM further deletes (one) SDT entry / entries whose ERT ID matches an invalid ERT entry.

9 Figure 10 illustrates a flow diagram for a method of performing an exchange of an EA in the ERT and the SDT in accordance with 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 are the same page size. The exchange improves the efficiency of the processor 106 in cases of different EAs corresponding to the same RA, with different instructions in the same or a different thread. For example, consider two statements x and y such that EAx => RAz and EAy => RAz. If EAx does not first have a hit in the ERT, that is, before EAy, the LSU installs an ERT entry with EAx associated with RAz as described herein. If EAy does not have a hit in the ERT at a later point in time, the LSU then carries out a CAMming process on the ERT with the RAz, achieves an RA hit and installs an entry in the SDT 800 with original address = EAy, substitute address = EAx.

If most of the subsequent accesses to RAz are via EAy, the LSU must use the SDT more often than the EAD itself is used. In one or more examples, the technical solutions are included to improve efficiency the LSU by reducing such frequent accesses to the SDT providing an increment counter in each SDT entry. As in 8th As shown 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.

In one or more examples, the counter is a 4-bit field, which implies a maximum value of 15. It should be understood that in other examples the field has a different length and / or has a different maximum value that is used as a threshold value. For example, after the instruction starts, the counter value is compared to the threshold value, 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 matches the threshold, the LSU invalidates the ERT entry that corresponds to the SDT entry, as shown in 860. For example, the ERT entry with the ERT ID from the SDT entry is made invalid. The invalidation of the ERT entry has the effect that the corresponding entries from the EA directory, the LRQF, the LMQ and the SRQ are invalidated.

Furthermore, the LSU handles a technical problem with regard to exceptions in a started instruction that requires the original EA to exit in the following way. Consider, for example, the case in which the started instruction achieves an SDT hit and is to be restarted with the substitute address from the SDT entry instead of the original start address, but an exception occurs that requires the original EA to terminate. Such a condition may occur in the case of DAWR / SDAR, etc.

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 retains an SDT hit flag (bit), an SDT index ( 0 to 3 ) for each LRQE entry. In the event of a restart, the SDT index is read one cycle earlier in order to obtain the substitute address. The LRQE also multiplexes between the address of the LRQE entry (the original address) and the SDT substitute address (read from the SDT) before the restart. In exceptional cases like the above where the original address is required to exit, the LRQE will have an additional SDT hit overwrite flag (bit) for each entry that has been partially matched with the DAWR, and so on LRQE restarts the case of an SDT hit that exits with an exception and forces the original address to start. An SRQ restart is similar to the LRQE restart described here, which uses the SDT hit overwrite flag if prior to the restart it is determined that it will exit with an exception.

In this way, the technical solutions described herein facilitate using only the EA, offer technical advantages in that no reference is made to an ERAT (which was typically used in processors) in a load / store path, and furthermore a recognition of an SHL and a timely suppression of a DVAL will not cause any problems with the flow control. Furthermore, the technical solutions described herein deal with technical problems when using only the EA, for example that a detection of LHS, SHL, LHL can lead to an error if two different EA are assigned to the same RA. The technical solutions described herein address such a technical problem by each using a Synonym Recognition Table (SDT) for the instructions in the OoO window. The technical solutions offer various technical advantages, including a reduction in chip area (by not storing RA), a reduction in power consumption (by not converting EA to RA) and improvements in latency.

With reference to 10 becomes a block diagram of a computer system 1000 for implementing some or all aspects of one or more embodiments of the present invention. The processing described herein can be implemented in hardware, software (eg, firmware), or a combination of these. In an exemplary embodiment, the methods described are implemented at least in part in hardware and can be part of the microprocessor of a special purpose or general purpose computer 1000 such as a mobile unit, a personal computer, a workstation computer, a minicomputer or a mainframe computer.

In an exemplary embodiment, as shown in FIG 10 shown, contains the computer system 1000 a processor 1005 , a memory 1012 that with a storage control unit 1015 connected, and one or more input devices 1045 and / or output units 1047 such as peripheral devices that are used to transfer data via a local I / O control unit 1035 are connected. To these units 1047 and 1045 can include, for example, a printer, a scanner, a microphone, and the like. A traditional keyboard 1050 and mouse 1055 can with the I / O control unit 1035 be connected. At the I / O control unit 1035 it can be, for example, one or more buses or other wired or wireless connections according to the prior art. The I / O control unit 1035 may have additional elements such as control units, buffers (caches), drivers, repeaters and receivers, which are omitted for the sake of simplicity in order to enable data transfers.

The I / O units 1047 , 1045 You can also use units 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, units, systems or a network ), a radio frequency (RF) or other transceiver, a telephone interface, a bridge, a router and the like.

The processor 1005 is a hardware unit for executing hardware instructions or software, in particular those stored in memory 1012 are stored. The processor 1005 can be a custom-made or commercially available processor, a central processing unit (CPU), an auxiliary processor of several processors that make up the computer system 1000 be a microprocessor based on a semiconductor (in the form of a microchip or a chip set), a microprocessor or some other device for executing instructions. The processor 1005 may include a cache, for example, but not limited to, an instruction cache to expedite fetching of executable instructions, a data cache to expedite fetching and storage of data, and an address translation buffer (TLB), the is used to speed up a translation from virtual to physical addresses for executable instructions as well as for data. The cache can be organized as a hierarchy of several cache levels (L1, L2, etc.).

The memory 1012 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) , disk, floppy disk, cartridge, cassette or the like, etc.) or combinations of these. In addition, the memory 1012 electronic, magnetic, optical or other types of storage media. It should be noted that the memory 1012 may have a distributed architecture with various components remotely located but accessed by the processor 1005 can be accessed.

The instructions in memory 1012 may include one or more separate programs, each of which has an ordered listing of executable instructions for implementing logical functions. In the example of 10 contain the instructions in memory 1012 a suitable operating system (OS) 1011. The operating system 1011 can 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.

Additional data, including, for example, instructions for the processor 1005 or other retrievable data can be stored in the memory 1027 which can be a storage device such as a hard disk drive or a semiconductor drive. The stored instructions in memory 1012 or in the memory 1027 can include those that make it the processor 1005 enable one or more aspects of the allocation systems and methods of this disclosure to be carried out.

The computer system 1000 can furthermore be a display control unit 1025 included that with an ad 1030 connected is. In an exemplary embodiment, the computer system may 1000 also a network interface 1060 to connect to a network 1065 contain. At the network 1065 it can be an IP based network for transferring data between computers 1000 and an external server, client and the like over a broadband connection. The network 1065 transmits and receives data between the computer system 1000 and external systems. In an exemplary embodiment, the network 1065 be a managed IP network managed by a service provider. The network 1065 can be implemented wirelessly, for example using wireless protocols and technologies such as WiFi, WiMax, etc. On the network 1065 it can also be a packet-switched network such as a local area network, a wide area network, a high-speed network, the Internet, or some other similar type of network environment. The network 1065 can 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), be an intranet or any other suitable network system and can contain devices for receiving and transmitting signals.

Systems and methods for providing an address translation for sending a real address to a memory subsystem in a load-storage unit on the basis of effective addresses can be completely or partially in computer program products or in computer systems 1000 like the one in 10 illustrated be embodied.

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

The following definitions and abbreviations are to be used for the interpretation of the claims and the description. As used herein, the terms “has,” “having,” “comprises,” “comprising,” “has,” “having,” “contains,” or “containing”, or any other variant thereof cover non-exclusive inclusion. For example, a composition, a mixture, a process, a method, an object or a device that has a list of elements is not necessarily limited to just these elements, but can contain other elements that are not expressly listed or are inherent in such a composition, mixture, process, method, article or device.

Additionally, 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, ie, one, two, three, four, etc. The term “A plurality” can be understood to include any integer greater than or equal to two, ie, two, three, four, five, etc. The term “connection” can be both an indirect “connection” and a direct one "Connection" included.

The terms "approximately", "substantially", "approximately" and variations thereof are intended to include the degree of error associated with a measurement of the respective quantity based on the equipment available at the time of filing the application. For example, “about” can contain a range of ± 8% or 5% or 2% of a certain value.

For brevity, conventional techniques related to 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 briefly mentioned or omitted entirely herein without providing the well-known details of the system and / or processes.

The present invention can be a system, a method and / or a computer program product. The computer program product may contain (a) computer-readable storage medium (or media) on which (s) are computer-readable Program instructions are stored to cause a processor to carry out aspects of the present invention.

The computer readable storage medium can be any physical entity that can retain and store instructions for use by an instruction execution system. The computer-readable storage medium can be, for example, an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination thereof, without being limited to these. A non-exhaustive list of more specific examples of computer readable storage media include the following: a portable computer disk, hard drive, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a DVD (digital versatile disc), a memory stick, a floppy disk, a mechanically encoded unit such as for example punch cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. As used herein, a computer-readable storage medium is not intended to be construed as being transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves traveling through a waveguide or other transmission medium (e.g., through a fiber optic cable guided light pulses) or electrical signals transmitted through a wire.

Program instructions described herein, readable by a computer, can be transferred from a computer-readable storage medium to respective data processing / processing units or via a network such as the Internet, a local area network, a wide area network and / or a wireless network to an external computer or a external storage device. The network can have copper transmission cables, fiber optic transmission conductors, wireless transmission, routing computers, firewalls, switching units, gateway computers and / or edge servers. A network adapter card or network interface in each data 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 corresponding data processing / processing unit.

Computer-readable program instructions for performing work steps of the present invention can be assembler instructions, ISA instructions (Instruction-Set-Architecture), machine instructions, machine-dependent instructions, microcode, firmware instructions, condition-setting data, or either source code or object code that are written in any combination of one or more programming languages, including object-oriented programming languages such as Java, Smalltalk, C ++ or similar, as well as conventional procedural programming languages such as the "C" programming language or similar programming languages. The computer readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server will. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or the connection can be made to an external computer (for example via the Internet using an Internet service provider). In some embodiments, electronic circuitry, including, for example, programmable logic circuits, field programmable gate arrays (FPGA) or programmable logic arrays (PLA), can execute the computer-readable program instructions by using state information from the use computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flow charts and / or block diagrams or diagrams of methods, devices (systems) and computer program products according to embodiments of the invention. It should be noted that each block of the flowcharts and / or the block diagrams or graphs as well as combinations of blocks in the flowcharts and / or the block diagrams or graphs can be executed by means of program instructions that can be read by a computer.

These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special purpose computer or some other programmable data processing device in order to generate a machine, so that the instructions executed via the processor of the computer or the other programmable data processing device are a means for implementing the in the block or blocks of the flowcharts and / or the block diagrams or graphs to generate functions / steps specified. These computer-readable program instructions can also be stored on a computer-readable storage medium which can control a computer, a programmable data processing device and / or other units to function in a certain way, so that the computer-readable storage medium , on which instructions are stored, has a manufacturing product, including instructions which implement aspects of the function / step specified in the block or blocks of the flowchart and / or the block diagrams or diagrams.

The computer readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device to cause a series of process steps to be performed on the computer or other programmable device or other device, such as one on a computer executed process so that the instructions executed on the computer, another programmable device or another unit implement the functions / steps specified in the block or blocks of the flowcharts and / or the block diagrams or diagrams.

The flowcharts and the block diagrams or diagrams in the figures illustrate the architecture, functionality and operation of possible implementations of systems, methods and computer program products in accordance with various embodiments of the present invention. In this context, each block in the flowcharts or block diagrams or diagrams can represent a module, a segment or a part of instructions that have one or more executable instructions for performing the particular logical function (s). In some alternative implementations, the functions noted in the block may take place out of the order shown in the figures. For example, two blocks shown in sequence can in fact be executed essentially simultaneously, or the blocks can sometimes be executed in reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams or diagrams and / or the flowcharts and combinations of blocks in the block diagrams or diagrams and / or the flowcharts can be implemented by special hardware-based systems that carry out the specified functions or steps , or combinations of special hardware and computer instructions.

Claims (20)

Processing unit for executing one or more instructions, the processing unit comprising: a load / store unit (LSU) (104) for transferring data between a memory and registers, the LSU being configured to execute a plurality of instructions in an out-of-order (OoO) window, wherein the execution having: in response to determining (610) that a first effective address is used by a first instruction, the first effective address corresponding to a first real address, creating (615) an entry of an effective-real table (ERT) (255) in an ERT, the ERT entry assigning the first effective address to the first real address; and in response to determining (830) a synonym of an effective address used by a second instruction, the synonym of the effective address being a second effective address that also corresponds to the first real address: Creating an entry in a Synonym Detection Table (SDT) (800) in an SDT, the SDT entry associating the second effective address with the ERT entry; and Restarting (845) the second instruction by replacing the second effective address in the second instruction with the first effective address. Processing unit according to Claim 1 wherein in response to the second effective address also corresponding to the first real address: comparing (620) a first page size associated with the first instruction with a second page size associated with the second instruction; and wherein the SDT entry associating the second effective address with the ERT is created (627) in response to the first page size being larger than the second page size. Processing unit according to Claim 2 wherein in response to the first page size being smaller than the second page size: modifying the ERT entry by replacing the association between the first effective address and the first real address with an association between the second effective address and the first real address. Processing unit according to Claim 3 further responsive to the first page size being smaller than the second page size: creating (625) the SDT entry that maps the first effective address to the ERT entry. Processing unit according to Claim 1 , the SDT entry being a thread identifier of a thread in which the first instruction is started, the effective address of the first instruction, a page size of the first instruction, an effective restart address of the first instruction and an ERT entry identifier of the corresponding ERT entry having. Processing unit according to Claim 1 , the first instruction being one of a group of instructions consisting of a load instruction and a store instruction. Processing unit according to Claim 1 wherein a counter is maintained (835, 840) to indicate a number of instructions started with the first effective address and in response to the counter exceeding a predetermined threshold (850) invalidating the ERT entry becomes (860) corresponding to the first effective address. A method implemented on a computer for executing one or more out-of-order instructions by a processing unit, the method comprising: A load and store unit (LSU) (104) issuing a plurality of instructions from an out-of-order (OoO) window, the issuing comprising: in response to determining (610) that a first effective address is used by a first instruction, the first effective address corresponding to a first real address, creating (615) an entry of an effective-real table (ERT) (255) in an ERT, the ERT entry assigning the first effective address to the first real address; and in response to determining a synonym of an effective address that is used by a second instruction, the synonym of the effective address being a second effective address which also corresponds to the first real address: Creating an entry in a Synonym Detection Table (SDT) (800) in an SDT, the SDT entry associating the second effective address with the ERT entry; and Restarting (845) the second instruction by replacing the second effective address in the second instruction with the first effective address. Method implemented on a computer according to Claim 8 wherein in response to the second effective address also corresponding to the first real address: comparing (620) a first page size associated with the first instruction with a second page size associated with the second instruction; and wherein the SDT entry associating the second effective address with the ERT entry is created (627) in response to the first page size being larger than the second page size. Method implemented on a computer according to Claim 9 wherein in response to the first page size being smaller than the second page size: modifying the ERT entry by replacing the association between the first effective address and the first real address with an association between the second effective address and the first real address. Method implemented on a computer according to Claim 10 wherein in response to the first page size being smaller than the second page size: creating (625) the SDT entry that maps the first effective address to the ERT entry. Method implemented on a computer according to Claim 8 , the SDT entry being a thread identifier of a thread in which the first instruction is started, the effective address of the first instruction, a page size of the first instruction, an effective restart address of the first instruction and an ERT entry identifier of the corresponding ERT entry having. Method implemented on a computer according to Claim 8 , the first instruction being one of a group of instructions consisting of a load instruction and a store instruction. Method implemented on a computer according to Claim 8 wherein a counter is maintained (835, 840) to indicate a number of instructions started with the first effective address and in response to the counter exceeding a predetermined threshold (850) invalidating the ERT entry becomes (860) corresponding to the first effective address. A computer program product comprising a computer readable storage medium having embodied program instructions, the program instructions being executable by a processor to cause the processor to perform operations comprising: A load and store unit (LSU) (104) issuing a plurality of instructions from an out-of-order (OoO) window by: in response to determining (610) that a first effective address is provided by a first instruction is used, the first effective address corresponds to a first real address, creating (615) an entry of an effective real table (ERT) (255) in an ERT, the ERT entry assigning the first effective address to the first real address ; and in response to determining (830) a synonym of an effective address used by a second instruction, the synonym of the effective address being a second effective address that also corresponds to the first real address: creating an entry a synonym recognition table (SDT) (800) in an SDT, the SDT entry assigning the second effective address to the ERT entry; and restarting (845) the second instruction by replacing the second effective address in the second instruction with the first effective address. Computer program product according to Claim 15 wherein in response to the second effective address also corresponding to the first real address: comparing (620) a first page size associated with the first instruction with a second page size associated with the second instruction; and wherein the SDT entry associating the second effective address with the ERT entry is created (627) in response to the first page size being larger than the second page size. Computer program product according to Claim 16 wherein in response to the first page size being smaller than the second page size: modifying the ERT entry by replacing the association between the first effective address and the first real address with an association between the second effective address and the first real address. Computer program product according to Claim 17 wherein in response to the first page size being smaller than the second page size: creating (625) the SDT entry that maps the first effective address to the ERT entry. Computer program product according to Claim 15 , the SDT entry being a thread identifier of a thread in which the first instruction is started, the effective address of the first instruction, a page size of the first instruction, an effective restart address of the first instruction and an ERT entry identifier of the corresponding ERT entry having. Computer program product according to Claim 15 , the first instruction being one of a group of instructions consisting of a load instruction and a store instruction.

Images