Execution ordering of load and store instructions handled by a core of a processor

Abstract

The implementation described herein involves the execution ordering of load and store instructions processed by the processor core. For example, the processor core within a computing device can execute a load instruction associated with an address. Loading follows off-core store instructions in program sequence. If the load is executed before other instructions preceding it in the program sequence have exited, an entry is added to the ordering structure of the load instruction. A danger is marked in the entry for the load instruction based on a snooping request for the cache line containing that address. When all instructions older than the load instruction exit, the core can then refresh the load instruction based on the danger in the entry. Corresponding processor cores and computing devices are also disclosed.

Description

Background Technology

[0001] Modern processors (e.g., Central Processing Units (CPUs)) can enhance performance by employing out-of-order processing, executing instructions as their operands become ready rather than strictly following program sequence. This can significantly reduce idle time caused by dependencies or latency, allowing the processor to utilize its execution resources more efficiently. However, out-of-order execution requires careful management of data dependencies to ensure program correctness. Mechanisms are needed to track instructions and their dependencies so that operations that depend on the results of earlier, incomplete instructions are not performed prematurely, which could lead to incorrect results and system failures. Summary of the Invention

[0002] The implementation described in this paper addresses the challenge of maintaining data consistency in computing devices employing out-of-order execution, particularly when coordinating memory operations between the processor core and separate computing resources such as coprocessors. Using the implementation described herein, the correct ordering of load instructions relative to older out-of-core memory instructions can be ensured in an out-of-order execution environment without requiring the core to track the addresses of all pending out-of-core memory. Furthermore, load instructions can detect potential ordering violations and initiate their own re-execution if necessary, thereby improving the efficiency of out-of-order processing. This method allows instructions to proceed out of order safely and provides a mechanism for recovering and maintaining program correctness when potential data inconsistencies arise due to interactions with out-of-core operations.

[0003] In some aspects, the techniques described herein relate to a method comprising: executing, by a core of a processor within a computing device, a load instruction associated with an address, the load instruction following an off-core memory instruction in a program sequence of an instruction set being executed by the computing device; adding an entry for the load instruction to a sorting structure of the core based on the execution of the load instruction while at least one instruction preceding the load instruction in the program sequence has not yet exited; marking a danger in the entry for the load instruction in the sorting structure based on a snooping request received by the core for a cache line including the address; and refreshing the load instruction based on the danger in the entry when the at least one instruction preceding the load instruction in the program sequence exits.

[0004] In some aspects, the techniques described herein relate to the core of a processor within a computing device, the core including: a sorting structure; and an execution unit configured to: execute a load instruction associated with an address, the load instruction following an off-core memory instruction in a program sequence of an instruction set being executed by the core; add an entry for the load instruction to the sorting structure based on the fact that at least one instruction preceding the load instruction in the program sequence has not yet exited; mark a danger in the entry for the load instruction in the sorting structure based on a snooping request received by the core for a cache line including the address; and refresh the load instruction based on the danger in the entry when the at least one instruction preceding the load instruction in the program sequence exits.

[0005] In some aspects, the technology described herein relates to a computing device comprising: a processor including a core having a sorting structure and an execution unit; and a computing resource decoupled from the processor and configured to execute instructions under the direction of the processor; wherein the execution unit of the core is configured to: execute a load instruction associated with an address, the load instruction following an out-of-core memory instruction in a program sequence of an instruction set being executed by the core; add an entry for the load instruction to the sorting structure; direct the computing resource to execute the out-of-core memory instruction; mark a danger in the entry for the load instruction in the sorting structure based on a snooping request received by the core for a cache line including the address; and refresh the load instruction based on the danger in the entry when all instructions preceding the load instruction in the program sequence have exited.

[0006] Other implementations may perform similar functions as described above and / or may use other types of hardware to perform the functions. Some implementations may involve systems, devices, media, and / or combinations thereof employing processors such as those described herein (e.g., having cores, caches, and / or buses configured to implement the execution order of load and store instructions in the manner described herein).

[0007] Details of these and other implementations are set forth in the accompanying drawings and the description below. Other features will also become apparent from the following description, drawings, and claims. Attached Figure Description

[0008] Figure 1 An illustrative implementation of the execution ordering of load and store instructions processed by the processor core, based on the principles described herein, is shown.

[0009] Figure 2An illustrative block diagram is shown of certain components of a computing device configured for the execution ordering of load instructions and store instructions processed by the processor core, based on the principles described herein.

[0010] Figure 3 An illustrative block diagram is shown of certain components of a processor that can be used to perform the execution ordering of load instructions and store instructions processed by the core, based on the principles described herein.

[0011] Figure 4 This illustrates the principles described herein. Figure 3 An illustrative block diagram of some components of the processor core.

[0012] Figures 5A to 5D Various illustrative methods relating to the execution ordering of load and store instructions processed by the processor core, based on the principles described herein, are shown.

[0013] Figures 6A to 6D The following diagrams illustrate the execution according to the principles described herein. Figures 5A to 5D The method is a data flow graph of various example interactions between components.

[0014] Figure 7 An illustrative computing system is shown that can implement the computing devices described herein and / or may include one or more processors such as those described herein. Detailed Implementation

[0015] This paper describes a method and system for ordering the execution of load and store instructions processed by a processor core (e.g., a central processing unit (CPU) configured to perform out-of-order processing). For example, the core's execution unit may execute a load instruction that follows an out-of-core store instruction. If the load instruction is executed before a previous instruction exits, an entry is added to an ordering structure within the core (e.g., a read-after-read (RAR) structure, etc.). If a snooping request is received for a cache line containing the address of the load instruction, a danger can be marked in that entry. When the previous instruction exits, if the danger has been marked, the load instruction is flushed, thereby ensuring correct data dependencies with out-of-core operations without tracking all previous store addresses.

[0016] Modern processors frequently utilize out-of-order execution to improve performance. This method allows the processor core to execute instructions as soon as the necessary data operands are available, rather than strictly adhering to the original program sequence. While this can significantly improve throughput by reducing pauses caused by data dependencies or memory latency, it introduces complexity in maintaining program correctness, particularly regarding memory access ordering. Ensuring that memory operations such as loads and stores are executed in the order specified by the program, or at least in the order that produces equivalent results, is necessary to prevent data inconsistencies and processor failures.

[0017] Then, certain technical problems arise in computing devices where the processor core interacts with separate computing resources, such as coprocessors or accelerators, to execute certain instructions. Maintaining correct data dependencies with subsequent load operations executed on the main core may require additional oversight and effort when instructions involving memory operations—especially store operations—point to these off-core resources. One technical problem involves coordinating memory operations between the processor core and off-core computing resources to ensure that load instructions executed on the core obtain the correct data when an older store instruction targeting the same memory address is being processed by the off-core resource. Specifically, if an older store instruction targeting the same address (i.e., a store instruction that appears earlier in the program sequence) is pending processing or being completed off-core (e.g., via external computing resources such as coprocessor or accelerator hardware), a newer load instruction on the core (i.e., a load instruction that appears later in the program sequence) may not correctly retrieve the stale data.

[0018] This technical problem is exacerbated by the out-of-order execution nature and the potential for large amounts of out-of-core operations. Because instructions are not executed in the order of their original program, load instructions may occur before older out-of-core memory has been completed. Furthermore, the sequence of instructions between the out-of-core memory instructions to be executed by the kernel and the load instructions can include many other out-of-core memory instructions pointing to various addresses. Therefore, maintaining a track of the addresses of all such pending out-of-core memory instructions can be a significant technical challenge for conventional methods.

[0019] More specifically, if the processor core is configured to maintain a complete list of addresses for every out-of-core memory operation that has been assigned but not yet completed (as might be the case with some conventional approaches), the necessary memory structures can become very large and complex. Moreover, the overhead of constantly checking whether the address of a load instruction conflicts with any address in this potentially vast list of out-of-core memory operations to be processed can introduce significant processing latency, directly offsetting the performance benefits of out-of-order execution. Therefore, a technical problem arises concerning how to efficiently detect and dispose of potential data hazards between locally loaded instructions and older out-of-core memory instructions without requiring the local core to track the addresses of all incomplete out-of-core memory operations.

[0020] Conventional solutions for load and store ordering typically involve tracking pending memory operations. For operations processed within the same core, the load / store unit can efficiently manage dependencies. Even dependencies between load and store operations performed by different cores can be efficiently managed by high-level (e.g., multiplexed) caches—such as L2 caches that provide memory data to both cores. These conventional intra-core and inter-core mechanisms become insufficient precisely when store operations point to off-core compute resources, as the main core may not have direct and immediate visibility into the state and addresses of off-core operations. As mentioned above, conventional methods involving cores attempting to track the addresses of off-core memory being allocated are inadequate because the number of off-core memories to be processed can be very large, making it impractical or impossible to track all associated addresses in hardware due to memory constraints and the overhead of managing such a large tracking structure. This limitation in conventional methods creates technical problems in maintaining data consistency when coordinating operations with off-core resources, as the core cannot reliably determine whether a load is prematurely accessing data that an older off-core memory will be updating.

[0021] The technical solutions described in this paper address these technical problems by providing mechanisms for the execution ordering of load and store instructions processed by the processor's core, particularly when interacting with off-core computing resources. Instead of the core attempting to track the addresses of all older off-core store instructions, some of the technical solutions described in this paper leverage existing hardware architecture and introduce modified operational behaviors of these structures to detect and resolve potential data hazards. Specifically, the core can be configured to address the technical problems described above by using ordering structures—such as read-after-read (RAR) structures commonly used to manage load-to-load ordering issues. As detailed below, the technical solutions described in this paper extend the use of such ordering structures to identify data hazards involving both local load instructions and older off-core store instructions.

[0022] For example, at least one technical solution involves adding an entry for the loaded instruction to the sorting structure if a load of an older instruction (potentially including out-of-core memory) is executed out of order. This entry includes information about the loaded instruction, such as its address and age relative to other instructions. The technical solution further provides a mechanism to flag this entry as dangerous if the core receives a snooping request for a cache line containing the address of the loaded instruction. A snooping request, typically initiated by a multiplexed cache that coordinates memory access, indicates that another entity (such as another core, or in this case, an out-of-core compute resource working on older memory) is attempting to access or modify data at that address. Therefore, when this snooping request targets a cache line corresponding to the loaded instruction in the sorting structure, it acts as a signal that a potential sorting violation may have occurred in the older out-of-core memory.

[0023] As will be described in more detail below, the core of this technical solution can be incorporated into logic to dispose of a load instruction when an older instruction finally exits the program sequence and the load instruction becomes the oldest non-exited instruction. Specifically, when the load instruction reaches this point (i.e., the point where all instructions preceding it in the program sequence have been exited), the entry for that load instruction in the sorting structure is checked. If the entry has been marked as dangerous (due to the aforementioned snooping), the technical solution described herein provides to refresh the load instruction and subsequent instructions that can depend on it. This refresh action effectively discards the potentially incorrect out-of-order execution result of the load and allows it to be re-executed so that it can obtain the correct data from the older off-core memory that caused the snooping. Conversely, if the entry has not been marked as dangerous at this point, it means that the load instruction is completed without intermediate off-core memory, thus ensuring correct memory consistency. In this case, the benefits of out-of-order processing can be realized because the load instruction is exited and processed in the normal way without being refreshed or re-executed.

[0024] By deferring the final completion of the load instruction until it is the oldest non-exit instruction, the technical solution described in this paper allows load instructions to perform self-checks based on their entries in the sorting structure. If a danger exists, the load itself initiates a recovery process (flush and re-execution) to resolve sorting conflicts. This set of technical solutions allows the core to maintain the correct program order and data consistency with off-core operations without needing to track the individual addresses of all pending off-core memory operations, thereby alleviating the technical problems of maintaining strict memory consistency across all memory operations (including off-core operations) and the technical problems of excessive hardware complexity and performance overhead.

[0025] As a result of the technical solution described in this paper, various beneficial technical effects can be achieved. For example, one such effect is the efficient maintenance of load / store ordering for operations involving off-core computing resources in an out-of-order execution environment. By leveraging existing ordering structures (such as RAR structures) and using snooping requests as indicators of the potential dangers of older off-core memory, this technical solution avoids the technical problem of tracking the addresses of large numbers of pending off-core operations. This results in reduced hardware complexity and lower resource utilization compared to conventional address tracking methods.

[0026] Another technical effect is improved performance through reduced pauses. Load instructions can proceed out of order when operands are available, and a recovery action (flush and re-execution) is initiated only in the event of a potential danger (detected via snooping). This allows the processor core to continue executing other instructions, minimizing idle time and thus improving processor performance. Furthermore, enabling load instructions to self-detect and initiate recovery based on their state in the sorted structure without requiring older instructions to identify problems (as is typical in conventional RAR architecture operations) simplifies control logic and enhances the responsiveness of danger resolution mechanisms. This approach provides a robust and efficient technical solution for ensuring data consistency and correct program execution in complex computational systems involving out-of-order execution and interaction with external resources.

[0027] Various implementations will now be described in more detail with reference to the accompanying drawings. It should be understood that the specific implementations described below are provided as non-limiting examples and can be used in various situations. Furthermore, it should be understood that other implementations not explicitly described herein may also fall within the scope of the claims set forth below. The execution ordering of load and store instructions processed by the processor core according to the principles described herein can result in any or all of the technical effects mentioned above, as well as various additional and / or alternative beneficial technical effects described below and / or becoming apparent.

[0028] Figure 1 An illustrative implementation 100 of the execution ordering of load and store instructions processed by the processor core, based on the principles described herein, is shown. As will now be described, implementation 100 shows how out-of-order execution of instructions can be handled, with a particular focus on load and store operations in scenarios where load instructions need to be re-executed due to the later execution of older out-of-core store instructions.

[0029] like Figure 1As shown, implementation 100 depicts instruction set 102, which includes store instruction 104-ST and load instruction 104-LD, the load instruction depending on the completion of store instruction 104-ST (i.e., because both involve the same address "address 0" or the abbreviated symbol "A_0"). For simplicity and to highlight the interaction between local load and off-core storage, only these two instructions are shown.

[0030] In program sequence 106, the load instruction 104-LD is shown as newer than the store instruction 104-ST, in which instruction set 102 is listed to the left of implementation 100. As indicated by this program sequence 106, the store instruction 104-ST can follow any number of other instructions (indicated by the first ellipsis in instruction set 102), and possibly, after other instructions (indicated by the second ellipsis in instruction set 102), the load instruction 104-LD can follow the store instruction 104-ST. In other words, in program sequence 106 of instruction set 102, the store instruction 104-ST can precede the load instruction 104-LD. Due to this program ordering, the store instruction 104-ST is referred to as "older" than the load instruction 104-LD, and the load instruction is referred to as "newer" than the store instruction 104-ST, regardless of the actual order in which these instructions are executed.

[0031] Store instruction 104-ST is shown as an off-core store instruction pointing to address 0 (i.e., a write to address 0). As used herein, an off-core store instruction is a store operation dispatched by the processor core but executed by a separate computing resource (off-core) such as a coprocessor or graphics processing unit, rather than by the core's local memory execution unit. In some implementations, off-core store instruction 104-ST may be one of several off-core instructions (e.g., including multiple store instructions) preceding the load instruction in the program sequence. In such an implementation, the core may be configured to suppress local tracing of the address of the off-core store instruction preceding the load instruction in the program sequence, as already described.

[0032] Load instruction 104-LD is shown as a regular (local or on-core) load instruction that also points to address 0 (i.e., a read from address 0). As used herein, a load instruction refers to an operation that reads data from a memory location. In contrast to the off-core storage of instruction 104-ST, load instruction 104-LD can be executed by the core's local memory execution unit (on-core or local load). As mentioned, the ellipses above and below the instructions indicate that instruction set 102 may include any number of other instructions before, after, and between these two instructions in the program sequence. For simplicity and to highlight the interaction between local load and off-core storage, only these two instructions are shown.

[0033] The arrow marked "Out-of-order processing" indicates that the processor core can be configured to execute instructions as their operands become ready, which can result in instructions being executed in an order different from that specified by program order 106. The same instruction set 102 is shown to the right of implementation 100, but this time in execution order 108, indicating the actual execution order of these instructions under a given out-of-order processing method. Again, the ellipsis will be interpreted as indicating that other instructions (not shown) may be included in the execution flow in the order in which load instructions 104-LD and store instructions 104-ST are explicitly shown, or not in that order.

[0034] The reason why three instructions are explicitly shown in execution order 108 is that, in this illustrative scenario, the load instruction 104-LD is actually executed twice, once by load instruction 104-LD1 and a second time by load instruction 104-LD2. This occurs because, due to out-of-order execution, the older off-core memory instruction 104-ST, which is older than load instruction 104-LD, is executed after the initial execution of load instruction 104-LD1. As mentioned above, this situation creates a potential data hazard: load instruction 104-LD1 may have retrieved stale data from address 0 because off-core memory instruction 104-ST had not yet updated this location when the load was initially executed.

[0035] To maintain program correctness, the core mechanism (in...) Figure 1(Not explicitly shown, but outlined above and described in more detail below) is configured to detect such potential dangers. This mechanism determines that the previously executed load instruction 104-LD1 may have accessed incorrect data when the older off-core store instruction 104-ST finally completes and updates address 0. This mechanism can involve sorting structures and snooping requests, as further described below. Therefore, a "flush and re-execute" operation for the load instruction ("LD A_0") is triggered. As will be described in further detail below, this operation discards the results of the initial execution of the load instruction 104-LD1 and subsequent related instructions (referred to in this example as sub-instructions of the load instruction and indicated within ellipses following the load instruction 104-LD1 and / or store instruction 104-ST). Then, this operation causes the load instruction to be re-executed as load instruction 104-LD2, and further re-executed any sub-operations it may have had (indicated by the ellipsis following load instruction 104-LD2) to ensure that the correct, updated data from address 0 is used in the program sequence following all instructions after store instruction 104-ST.

[0036] Figure 2 An illustrative block diagram is shown of certain components of a computing device 200 configured for the execution ordering of load and store instructions processed by the processor core, based on the principles described herein. This diagram provides... Figure 1 The principles shown are a high-level view of the system within which the system can be implemented.

[0037] like Figure 2 As shown, computing device 200 may include processor 202, main memory 204, and one or more computing resources 206, including but not limited to math coprocessor 208, graphics processing unit 210, and other computing resources 212. Computing resources 206 (i.e., math coprocessor 208, graphics processing unit 210, and other computing resources 212) are shown as separate from processor 202, but will be understood as being configured to execute instructions under the guidance of processor 202, as will be described in more detail below. Each of these elements will now be described in more detail.

[0038] The processor 202 can be implemented as a central processing unit (CPU) and utilizes instructions Figure 3 Further details are shown in the document ("see..."). Figure 3The processor 202 can be described using the annotation “”. The processor 202 can be configured to direct the execution of an instruction set (e.g., instruction set 102 described above), which can be part of an application or service running on the processor 202. The processor 202 can be designed from any number of computing architectures, including Complex Instruction Set Computer (CISC) or Reduced Instruction Set Computer (RISC) architectures, although any other suitable computer architecture can also be used. In some implementations, the processor 202 can be implemented as a multi-core processor, as will be shown in more detail below.

[0039] Main memory 204 can be implemented as dynamic random access memory (DRAM) or other suitable storage medium configured to store information accessed by processor 202. Main memory 204 can be used to store the set of instructions being executed by processor 202, as well as any data being used by processor 202 during program execution, such as input data and output data. In some implementations, some or all of the main memory in main memory 204 can be implemented on the same chip or die as processor 202, while in other implementations, some or all of the main memory in main memory 204 can be implemented on one or more separate chips or dies (e.g., DRAM chips, etc.).

[0040] Each computing resource in computing resource 206 can be implemented by any of various computing resources or peripheral devices configured to execute instructions under the guidance of processor 202. For example, as described, computing resource 206 such as math coprocessor 208 can be configured to accelerate the execution of mathematical operations, while computing resource 206 such as graphics processing unit 210 can be configured to accelerate the execution of graphics operations. Other computing resources 212 may include other types of resources configured to perform off-core operations (e.g., off-core memory instructions such as memory instruction 104-ST), such as coprocessors, peripheral devices, cryptographic accelerators, field-programmable gate arrays (FPGAs), etc.

[0041] Although these computing resources 206 are separate from the processor 202, they can be directed by the core of the processor 202 to execute certain instructions, such as off-core memory instructions (e.g., memory instruction 104-ST), as already described. The processor 202 can be configured to coordinate the operation of the computing resources 206—including memory operations—to ensure program correctness, especially in scenarios involving out-of-order execution.

[0042] Figure 3An illustrative block diagram of some components of an implementation of the processor 202 described above is shown. As described, the processor 202 can be used to perform an execution ordering of load instructions and store instructions processed by the cores, according to the principles described herein. As previously further mentioned, the processor 202 can be implemented as a central processing unit (CPU) or another suitable processor, and can include one or more cores and can be used with other computing resources ( Figure 3 (Not shown in the image) Communication. Figure 3 A more detailed view is provided of certain components within processor 202 that are related to coordinated memory operations.

[0043] like Figure 3 As shown, processor 202 may include multiple cores 302 (three of these cores are in...) Figure 3 The cores are explicitly depicted, and other cores among these cores may be included (indicated by ellipses). Each core 302 will be understood as being configured to execute instructions and may be capable of out-of-order execution as described herein. Any core 302 shown in the implementation of processor 202 may be configured to execute any of the methods, processes and / or techniques described herein. As stated (“see…”), Figure 4 (See below for reference) Figure 4 A specific example of core 302 is described in more detail.

[0044] A multiplexed cache 304 is further illustrated in processor 202. For example, multiplexed cache 304 may be a Level 2 (L2) cache accessible to each core in core 302 and configured to serve each core in core 302. Multiplexed cache 304 may manage memory access requests from core 302, including coordinating access to shared memory addresses (e.g., within main memory 204). As will be described in more detail below, multiplexed cache 304 may also be configured to play a role in maintaining data consistency between core 320 and external computing resources such as computing resource 206.

[0045] Communication bus 306 is shown connecting core 302 to multiplexed cache 304. This communication bus 306 facilitates the exchange of data, memory requests (such as load and store), snoop requests, and other coordination messages between the core and the cache. Communication bus 306 allows any core 302 to send a memory access request to multiplexed cache 304 and receive data in return. Multiplexed cache 304 can also use communication bus 306 to send snoop requests to the core, for example, when another entity attempts to access a cache line that the core has specifically cached.

[0046] The communication bus 306 can be configured to carry data transfers from core 302 to multiplexed cache 304, from multiplexed cache 304 to any or all cores of core 302, from one core 302 to another core 302, and / or between these components and / or other components not explicitly shown in the processor 202. For example, the communication bus 306 may include various transmission nodes arranged and interconnected in any suitable manner. Figure 2 (Not explicitly shown). For example, transmission nodes can be connected in any suitable topology, such as point-to-point, mesh, ring, star, tree, or a hybrid topology that includes two or more of these topologies. In this way, each core in the core can be connected to the multiplexed cache 304, as well as to each other (and possibly to other elements of the processor 202 not explicitly shown).

[0047] Processor 202 may further include a memory controller ( Figure 3 (Not shown in the image). The memory controller connects to the multiplexed cache 304 and is responsible for communication with main memory (e.g., ...). Figure 2 The main memory 204 shown interfaces with other external storage devices (e.g., memory-mapped devices). The memory controller can handle requests from the multiplexed access cache 304 for reading from or writing to external memory.

[0048] As in Figure 2 As discussed in the context, computing device 200 may include computing resources 206 separate from processor 202. Figure 3 In this context, processor 202 can communicate with any of these off-core computing resources 206. For example, as shown, a core 302 is illustrated as communicatively coupled to multiple computing resources 206, which can instruct these computing resources to perform certain operations (e.g., off-core memory instructions, etc.). Additionally, multiplexed cache 304 is illustrated as communicatively coupled to main memory 204 (e.g., via a memory controller, not explicitly shown) and to computing resources 206. This is because multiplexed cache 304 can coordinate memory operations not only with core 302 but also with these other components of computing device 200.

[0049] The interactions between these components are particularly relevant to the execution ordering of load and store instructions, especially when out-of-core operations are involved. For example, when a particular core 302 dispatches an out-of-core store instruction associated with an address, this core can instruct out-of-core compute resource 206 to execute the store instruction. Out-of-core compute resource 206 can then interact with multiplexed cache 304 to complete the store operation (e.g., to obtain a cache line associated with the address). Specifically, the core may be executing a load instruction targeting the same address while an older out-of-core store is pending or completed (i.e., before the older store is fully implemented), and may receive a snooping request from multiplexed cache 304 while the core has exclusive access to that cache line. This snooping request received by core 302 can thus indicate a potential data hazard, triggering mechanisms within the core that will be described in more detail below. For example, the snooping could cause the hazard to be flagged in the ordering structure associated with the load instruction (e.g., a read-after-read structure described in more detail below). The structure within the core helps ensure the programmed (e.g., correct, expected, etc.) ordering of memory operations, even when out-of-order execution and off-core operations are involved, without requiring the core to keep track of the addresses of all off-core memory to be processed.

[0050] Now let's turn to a more detailed diagram of a processor core that can be configured to implement some of the principles described in this article. Figure 4 The above shows Figure 3 An illustrative block diagram of certain components of one core in core 302 of processor 202 is shown. As illustrated, this implementation of core 302 includes (along with other elements not explicitly shown) an execution unit 402, a sorting structure 404 with multiple entries 406, and an exit unit 408. It will be understood that core 302 can represent the above-referenced... Figure 3 The core 302 described can be any core and can be configured to execute instruction set 102.

[0051] Execution unit 402 refers to any suitable execution unit of a processor core capable of performing the operations described herein—such as load instructions and store instructions. For example, execution unit 402 may be implemented as a load / store unit (LSU) and may be configured to execute the instruction set 102 assigned to the core, such as load instructions and store instructions (e.g., ...). Figure 1 The load instruction 104-LD and the store instruction 104-ST are shown in the figure.

[0052] In one example, as referenced above Figure 1As mentioned, execution unit 402 can be configured to execute a load instruction associated with an address, wherein the load instruction follows an out-of-core memory instruction in the program sequence of the instruction set being executed by the core. Based on the fact that at least one instruction preceding the load instruction in the program sequence has not yet exited, the execution unit can add an entry for the load instruction to the sorting structure 404. The execution unit can also be configured to direct the execution of out-of-core memory instructions by computational resources decoupled from the processor (such as a math coprocessor or graphics processing unit). Various methods can be implemented by execution unit 402 in conjunction with other components of core 302 (e.g., Figures 5A to 5D Further details of methods 500-A to 500-D are shown and described below.

[0053] The ordering structure 404 represents a hardware mechanism within core 302 configured to help ensure the correct ordering of memory operations. For example, in some implementations, the ordering structure 404 may be implemented using a read-after-read (RAR) structure. Such a structure is typically used to manage dependencies between load operations within a single core (i.e., ensuring that newer loads and older loads do not receive incorrect data if executed out of order). However, in the context of the described implementation, the use of the ordering structure 404 is extended to include the potential danger of tracking local load instructions (executed by core 302) and older off-core memory instructions (dispatched by core 302 but executed by separate compute resources).

[0054] As shown in the figure, the sorting structure 404 can store a set of entries 406, each of which is configured to include an address (Addr), an instruction age indicator (Age), and a danger indicator (Hazard), as well as other data fields, possibly not shown. While these data fields are explicitly shown for a single entry 406, it will be understood that each entry 406 within the sorting structure 404 may contain such fields (and / or combinations of other data). When a load instruction is executed out of order relative to an older instruction in the program sequence, an entry for that load instruction can be added to the sorting structure 404. This entry stores information about the address being accessed by the load instruction and the age of the instruction relative to other instructions in the program sequence. The danger indicator may be a bit within the entry that can be set to indicate a potential data danger, such as when a snooping request is received for a cache line including the address associated with the load instruction.

[0055] Exit unit 408 represents another hardware unit within core 302, configured to exit each instruction in the instruction set according to the program order. Despite the potential for out-of-order execution within core 302, exit unit 408 ensures that the results of instructions are committed in the correct sequence specified by the program, thereby ensuring program correctness and data consistency.

[0056] In the context of the described implementation, exit unit 408 can function in the hazard detection and resolution process, as already described and referred to below. Figures 5A to 5D Further details are provided. For example, execution unit 402 may be configured to use exit unit 408 to determine, before adding the entry of the load instruction to the sorting structure 404, that at least one instruction preceding the load instruction in the program sequence has not been exited (i.e., when the load instruction is not the oldest pending or unexited instruction and is being executed out of order). Alternatively, execution unit 402 may be configured to use exit unit 408 to determine, after marking a danger in the entry of the load instruction, that the instruction preceding the load instruction in the program sequence has been exited (i.e., the load instruction has become the oldest pending or unexited instruction).

[0057] When a load instruction associated with an entry in sorting structure 404 becomes the oldest non-exit instruction in exit unit 408, the entry 406 of that load instruction in sorting structure 404 can be checked. If a danger indicator is set in that entry, the load instruction is refreshed, requiring re-execution to obtain the correct data. If no danger indicator is set, the load instruction can exit normally. Execution unit 402 can be configured to suppress marking the load instruction as complete in exit unit 408 when the entry is added to sorting structure 404. This allows the load instruction to perform the self-check described above to identify any dangers before the load instruction is completely exited.

[0058] Now refer to Figures 5A to 5D and Figures 6A to 6D This paper describes various illustrative implementations of the execution ordering of load and store instructions processed by the processor core, based on the principles described herein. More specifically, Figures 5A to 5D Illustrative methods 500-A to 500-D are shown for the execution ordering of load and store instructions processed by the processor core, while Figures 6A to 6D It shows the relationship with Figures 5A to 5D The methods 500-A to 500-D correspond to the illustrative data flow diagrams 600-A to 600-D. As shown in the figures, each data flow diagram 600-A to 600-D includes the information referenced above. Figure 4Certain elements are shown in (and other earlier figures). In particular, these elements include computing resources 206, multiplexed cache 304, execution unit 402, sorting structure 404, and exit unit 408.

[0059] In each of methods 500-A to 500-D, the operations of these methods can be executed by the processor core. More specifically, the operations of methods 500-A to 500-D can be executed by the physical circuitry of execution unit 402, as it is integrated within core 302. Although Figures 5A to 5D Illustrative operations based on a particular implementation are shown, but it will be understood that other implementations of these methods may omit, add, reorder, and / or modify them. Figures 5A to 5D Any operation explicitly represented in the table. Additionally, although these operations are shown using arrows that suggest the sequential order of operations, it will be understood that one or more of these operations can be executed concurrently (e.g., in parallel).

[0060] The circles in data flow diagrams 600-A to 600-D will be interpreted as representing the performance of the indicated operations from the corresponding methods 500-A to 500-D, and the arrows extending from these circles will be interpreted as representing communication with another element, control of another element, and / or other interactions with another element, as will be described in more detail below.

[0061] refer to Figure 5A Method 500-A is similar to the other methods and procedures already described above for the execution ordering of load and store instructions processed by the processor's core.

[0062] In Operation 502, the processor core within the computing device can execute a load instruction associated with an address. In the program sequence of instructions being executed by the computing device, this load instruction can follow an off-core memory instruction. (See reference...) Figure 1 As described, this may involve the core's execution unit performing a load operation at a specific memory address (address 0 in this diagram). Because this load instruction appears later in the program sequence than the off-core memory instruction targeting the same address, a data dependency can exist between the two instructions. The core's out-of-order execution capability allows this load instruction to be executed relatively early in the execution sequence, potentially before older instructions including off-core memory.

[0063] At operation 504, an entry for a load instruction can be added to the core sorting structure. For example, the entry can be added based on the fact that the load instruction was executed before at least one instruction preceding it in the program sequence has been exited (as executed at operation 502). In other words, when it can be determined that the load instruction is being executed out of order, meaning that there are older instructions in the program sequence that have not yet completed and have been exited by the exit unit, an entry corresponding to this load instruction can be created and added to the sorting structure (e.g., a read-after-read structure, etc.). This may include, as referenced... Figure 4 This entry for the address, age, and danger indicator can be added to the sorting structure to allow for the tracking of the out-of-order load instructions.

[0064] In operation 506, a danger can be marked in the entry of a load instruction in the sorting structure. For example, the danger can be marked (e.g., stored, flagged, etc.) based on a snooping request received by the core for a cache line containing the address of the load instruction. As already described, a snooping request received by the core for a cache line containing the address of the load instruction can indicate that another entity, such as an off-core computing resource completing older storage for that address, is accessing or modifying data. When such a snooping request is detected and corresponds to the address of a load instruction with an active entry in the sorting structure, a danger indicator can be set or marked in that entry. This marking indicates potential data inconsistencies due to out-of-order execution of the load instruction.

[0065] In Operation 508, load instructions can be refreshed based on the danger listed in the entry. For example, this refresh can be performed when at least one instruction preceding the load instruction in the program sequence has exited, making the load instruction the oldest non-exiting instruction. (See above regarding...) Figure 4 As described in exit unit 408, the core exit unit can be configured to ensure that instructions exit in program order. Therefore, when a load instruction reaches a point where all instructions preceding it in the program order have been exited, the entry for that load instruction in the sorting structure is checked. If a danger indicator in this entry has been marked (e.g., set due to a previous snooping request, as described with respect to operation 506), the load instruction is refreshed. This refresh operation discards the results of the initial execution and can trigger a re-execution of the load instruction to ensure it obtains the correct data, thus maintaining program correctness despite out-of-order execution and off-core memory operations.

[0066] Turn now Figure 6AData flow diagram 600-A illustrates the elements of method 500-A in different ways, demonstrating how the various core components interact to perform these operations. Specifically, as shown, execution unit 402 is shown performing operation 502 (“Perform Load”), followed by operation 504 (“Add Entry”), which is shown as involving interaction 602 with sorting structure 404, in which the entry is added to the sorting structure. As shown, execution unit 402 may later perform operation 506 (“Mark Danger”), resulting in interaction 604 with sorting structure 404, in which a danger is marked by setting a danger indicator in the entry of the load instruction. Finally, as shown, execution unit 402 may ultimately perform operation 508 (“Refresh Load”), which, as described above, involves refreshing the load instruction based on the danger in the entry once other instructions preceding the load instruction in the program sequence have been exited.

[0067] Now go to Figure 5B and Figure 6B These diagrams illustrate the relationship with Figure 5A and Figure 6A The scenes depicted are more common and beneficial compared to those in the text. Despite Figure 5A and Figure 6A A method for handling specific hazardous scenarios requiring refresh is shown, but Figure 5B and Figure 6B The beneficial results obtained in a more frequent scenario are shown, in which no dangers are indicated for load instructions, and therefore refresh is not necessary. (See reference...) Figure 5A and Figure 6A The earlier scenario described, which addresses potential hazards, makes the benefits received in this scenario possible by adding entries to a sorting structure and appropriately labelling the hazards. This allows mechanisms to be in place for detecting and addressing hazards (such as...). Figure 5A and Figure 6A As mentioned above, the core can safely continue execution out of order, knowing that if a danger does occur, it will be detected and resolved. This allows the core to efficiently exit load instructions when no danger exists, which can be a more frequent occurrence.

[0068] refer to Figure 5B Method 500-B builds upon the concepts introduced in Method 500-A to describe how the core handles subsequent load instructions when no danger is detected.

[0069] In operation 510, the kernel can execute a second load instruction. For example, in program sequence, this second load instruction can follow the first load instruction described in method 500-A. However, similar to the first load instruction, this second load instruction will be understood as being executed out of order with respect to other instructions in the program.

[0070] In operation 512, a second entry for the second load instruction can be added to the sorting structure. For example, this second entry can be added based on the execution of the second load instruction before at least one instruction preceding it in the program sequence has been exited (executed in operation 510). Similar to the above reference regarding... Figure 5A The entry described suggests that adding this second entry to the sorting structure would allow the kernel to track the state of this out-of-order load instruction in a similar manner to the first load instruction, including tracking for any potential dangers. However, as mentioned above, in this scenario, no danger was ultimately detected, and therefore the kernel could safely continue with out-of-order execution.

[0071] In operation 514, the second load instruction can be exited based on the absence of a marked danger in the second entry. For example, the exit of a load instruction can occur when at least one instruction preceding the second load instruction in the program sequence is exited, making the second load instruction the oldest surviving instruction. Unlike the scenario in method 500-A, in this more common case, no snooping request for the cache line associated with the second load instruction is received while the entry for the second load instruction is active in the sorting structure. Therefore, no danger is marked in the second entry. When the second load instruction becomes the oldest surviving instruction, the exit unit checks the entry for the second load instruction in the sorting structure, and if no marked danger is found, the exit unit confirms the successful completion of the second load instruction. Therefore, the instruction is exited, allowing subsequent instructions in the program sequence to continue toward exit.

[0072] Turn now Figure 6BData flow diagram 600-B illustrates the elements of method 500-B in different ways, demonstrating how the various core components interact to perform these operations. As shown, execution unit 402 is depicted performing operation 510 (“Execute Load 2”), instructing the execution of the second load instruction. Subsequently, execution unit 402 performs operation 512 (“Add Entry 2”), which involves interaction 606 with sorting structure 404, in which a second entry of the second load instruction is added to the sorting structure. Finally, execution unit 402 is shown performing operation 514 (“Exit Load 2”), which involves execution unit 402 exiting the second load instruction based on the absence of an indicated danger in the entries of the second load instruction in the sorting structure. This diagram highlights the simplified flow of handling and exiting when no data danger arises for a load instruction executed out of order.

[0073] Now will describe Figure 5C and Figure 6C .although Figures 5A to 5B and Figures 6A to 6B Typical implementations and beneficial scenarios resulting from them are shown at a relatively high level of abstraction, but Figure 5C and Figure 6C Various details that may not have been explicitly illustrated in the earlier figures are provided. For illustration, operations 502 to 508 (of method 500-A) are shown left-aligned and connected by a long dashed line representing method 500-A within method 500-C; other operations 516 and 518 related to the exit determination are centered and connected by a middle dashed line 515; and other operations 520 to 526 related to other specific details are right-aligned and connected by a dashed line 519.

[0074] In operation 516, using an exit unit (such as exit unit 408), before adding the entry for the load instruction to the sorting structure (operation 504), it is possible to determine whether the execution of the load instruction is being carried out before at least one instruction preceding the load instruction in the program sequence has been exited. As described, the core can be configured for out-of-order execution, thereby allowing load instructions to be executed before older instructions have been completed and exited. The exit unit within the core is configured to track the program sequence and the exit status of instructions. This operation represents a step in which the exit unit assists in identifying that the load instruction is being executed out of order, thereby triggering the creation of an entry in the sorting structure (in operation 504) to manage potential dependencies. This determination is made before adding the entry to the sorting structure (operation 504), thereby ensuring that only out-of-order loads are tracked in this manner.

[0075] In operation 518, the exit unit (e.g., exit unit 408) can be used to determine that at least one instruction preceding the load instruction in the program sequence has been exited (e.g., because the load instruction has become the oldest non-exit instruction). As shown, operation 518 can be executed after marking a danger (operation 506) in the entry of the load instruction. Instructions in the program sequence are exited when they complete their execution and reach the head of the exit unit, thus ensuring that instructions are executed either in the specified program order or in an alternative (unordered) sequence that achieves the same result. This operation indicates the point where all instructions preceding the load instruction in the program sequence have been exited, making the load instruction the oldest non-exit instruction. The exit unit signals this situation to the execution unit, which can then perform a self-check on the entry of the load instruction in the sorting structure to determine whether a danger has been marked, as described in operation 508.

[0076] In operation 520, the core can direct a processor-decoupled computing resource (such as any computing resource in computing resource 206) to execute an off-core memory instruction (e.g., memory instruction 104-ST described above). As already described, a computing device can include computing resources decoupled from the processor and configured to execute instructions under the direction of the processor. In the scenario addressed by this method, the load instruction follows the off-core memory instruction in the program sequence, and this off-core memory instruction is associated with the same address as the load instruction. Operation 520 can therefore represent the core dispatching the off-core memory instruction to the designated computing resource for execution. This highlights the interaction between the core and the decoupled computing resource, as the off-core nature of the memory requires attention to instruction ordering (such as by using the ordering mechanisms described herein).

[0077] In operation 522, the core may receive a snoop request from a multiplexed cache (such as multiplexed cache 304). For example, the snoop request may be made and received as part of an off-core memory instruction being executed by a computing resource. As described, the multiplexed cache may be configured to manage not only memory for the processor core but also memory for external computing resources within the computing device. Therefore, since the off-core memory instruction may be associated with the same address as the load instruction, the multiplexed cache may provide the snoop request to the core as part of the off-core memory instruction being executed by the external computing resource. Operation 522 may indicate that the core receives a snoop request for a cache line including the address associated with the load instruction. The snoop request issued by the multiplexed cache may indicate that the off-core computing resource is accessing or modifying the cache line as part of completing the off-core memory, thereby signaling a potential data hazard for a load instruction to be executed earlier. As already described, this snoop request may trigger the marking of the hazard in the sorting structure entry of the load instruction (operation 506).

[0078] In operation 524, the kernel can obtain (e.g., re-obtain) the cache line containing the address. As shown, this can be performed in response to a load instruction flush (operation 508). When a load instruction is flushed due to a danger indicated in its sorting structure entry, it means that the data obtained during initial execution may be stale. Therefore, operation 524 represents the kernel's action of obtaining the correct updated cache line from the memory hierarchy (e.g., from the multiplexed cache or main memory) after a flush. Obtaining the updated cache line can be performed when a load instruction is expected to be re-executed to ensure that it loads the latest data value written by an older off-core memory instruction.

[0079] In operation 526, the kernel can re-execute the load instruction based on the cache line obtained at operation 524. Operation 526 represents the re-execution of the load instruction after the load instruction has been flushed (operation 508) and the updated cache line has been obtained (operation 524). This re-execution uses a newly obtained (e.g., re-obtained) cache line containing correct data from an older off-core memory (which may have previously retrieved the cache line in conjunction with a snooping request). This ensures that the load instruction retrieves the accurate data value, thereby resolving data hazards and maintaining program correctness. Any subsequent instructions (referred to herein as sub-instructions of the load instruction) that depend on the original, potentially stale, loaded data may also need to be re-executed based on this corrected load result, as will be further described below.

[0080] Turn now Figure 6CData flow diagram 600-C illustrates the elements of the method in a different way. Data flow diagram 600-C visually represents the interactions between various components of the computing device when method 500-C is executed. The diagram depicts computing resources 206, multiplexed access cache 304, execution unit 402, sorting structure 404, and exit unit 408, and shows how they interact through different data and control flows during the process of disposing of load instructions in off-core memory operations and potentially hazardous environments.

[0081] Starting with operation 502, execution unit 402 executes a load instruction (“Execute Load”), as already described. Execution unit 402 then executes operation 516 to determine, through interaction 608 with exit unit 408, that the load instruction is not the oldest instruction (“Load Non-Oldest”). In response to this determination, execution unit 402 is then shown executing operation 504 (“Add Entry”), which involves the interaction 602 described above for adding the entry for the load instruction to the sorting structure 404.

[0082] Execution unit 402 then performs operation 520 (“allocate off-core memory”), which is shown as involving interaction 610 with compute resource 206. As already described, this operation is performed by execution unit 402 instructing the compute resource to execute off-core memory instructions in any suitable manner. As part of the off-core memory execution, compute resource 206 may send a request to multiplexed cache 304 for a cache line associated with a specific address (“request address” shown in interaction 612). Multiplexed cache 304 may then send a listen request (“listen request” shown in interaction 614) to execution unit 402, which is received in operation 522. For example, the cache may send the listen request based on the determination of a core-exclusive cache line.

[0083] Upon receiving the listening request, execution unit 402 is instructed to perform operation 506 (“mark danger”), which involves interaction 604 with sorting structure 404 to mark danger in the entries of load instructions. As instructions exit in program sequence, exit unit 408 then assists execution unit 402 in determining when a load instruction becomes the oldest non-exit instruction (operation 518), as indicated by interaction 616 between exit unit 408 and execution unit 402 (“load is the oldest”).

[0084] Once the load instruction is determined to be the oldest non-exit instruction and the danger is identified as already marked in its entry, execution unit 402 is shown performing operation 508 (“refresh load”). In response to this refresh, execution unit 402 can perform operation 524 (“obtain cache line”), which is shown as involving interaction 618 with multiplexed cache 304, whereby the execution unit obtains the updated cache line (e.g., from compute resource 206, or from another entity that has exclusive access to the cache line at this point in time). Finally, execution unit 402 can use the obtained cache line to perform operation 526 (“re-execute load”).

[0085] Figure 5D and Figure 6D This illustrates additional aspects of managing load instructions that follow off-kernel store instructions, with a particular focus on the use of loaded data by subinstructions and the implications of re-execution. Similar to... Figure 5C and Figure 6C , Figure 5D and Figure 6D Details that might not have been explicitly shown in earlier figures have been added. In method 500-D, operations 502 to 508 (of method 500-A) are shown left-aligned and connected by a long dashed line representing method 500-A. Operation 528 is shown as a sub-operation of operation 504 (i.e., details indicating how a particular aspect of operation 504 is performed). Operations 530 to 534 then relate to sub-instructions of the load instruction and are right-aligned and connected by dashed line 529.

[0086] In operation 528, when an entry is added to the sorting structure (operation 504), the kernel can suppress marking a load instruction as complete in an exit unit (e.g., exit unit 408). This operation describes a specific control action within the kernel's exit unit. Even if a load instruction has already been executed (operation 502) and an entry has been added to the sorting structure (operation 504), the exit unit is explicitly prevented from marking the instruction as complete in its internal state or buffer. This is performed so that the exit of the instruction remains conditional on a danger check in the sorting structure (which will be performed in conjunction with operation 508, as already described). By not marking it as complete, the exit unit will not attempt to completely exit the instruction until it reaches the head of the exit queue (i.e., becomes the oldest non-exited instruction) and passes the danger check associated with operation 508. This supports ensuring that the completion of the load instruction is synchronized with the program sequence, and that any potential dangers in older out-of-core storage are resolved before exiting.

[0087] In operation 530, loaded data received from the execution of the load instruction can be provided for use by one or more sub-instructions of that load instruction. As described above, in an out-of-order execution environment, even before the original instruction exits, the result of an instruction (such as data loaded by the load instruction) can be made available to subsequent instructions that depend on this data. These related instructions are referred to herein as sub-instructions of the load instruction. Operation 530 indicates that the execution unit provides the data obtained from the initial execution of the load instruction to the actions of one or more sub-instructions that are waiting for this data. This allows the sub-instruction to potentially execute ahead of schedule, thereby improving performance through out-of-order execution. The load instruction provides this data even though the load instruction has not yet been marked as complete in the exit unit, thereby allowing downstream related operations to continue without waiting for the load to completely exit.

[0088] In operation 532, the loaded data can be used to execute one or more subinstructions before the load instruction is flushed. After the loaded data is provided in operation 530, the subinstructions that depend on this data can then continue their own execution. Operation 532 represents this execution of subinstructions using the data provided by the load instruction. This execution of subinstructions can occur after the load instruction has been executed out of order (operation 502), after its entry has been added to the sorting structure operation (504), and after the loaded data has been provided (operation 530), but before the load instruction is potentially flushed (operation 508). This illustrates the speculative nature of executing subinstructions based on data from an out-of-order load, where these out-of-order loads may still need to be re-executed if a danger is detected later.

[0089] In operation 534, one or more sub-instructions can be re-executed. As shown, this can occur in response to a refresh of a load instruction (operation 508). It will be understood that this re-execution can be performed in conjunction with (e.g., based on) a re-execution of the load instruction (operation 526 of method 500-C, not explicitly shown in method 500-D, but understood to follow operation 508). If a danger is detected for the load instruction (operation 506) and the load instruction is subsequently refreshed (operation 508), and the load instruction is re-executed using corrected data (operation 526, previously mentioned...), the re-execution can proceed as follows: Figure 5C If, as described, any subinstructions previously executed using potentially stale data from the initial load execution must also be re-executed, then operation 534 indicates this re-execution of a subinstruction, thereby ensuring that it operates on the accurate data obtained from the re-executed load instructions. This recovery mechanism maintains program correctness when out-of-order execution coupled with off-core operations results in inconsistent data requiring load re-execution.

[0090] Turn now Figure 6DData flow diagram 600-D in the figure illustrates the elements of method 500-D in a different way, thus providing a visual representation of the interactions between various components as method 500-D is executed. As shown, this diagram is similar to data flow diagram 600-C, but with the addition of elements related to sub-instructions.

[0091] Starting with operation 502, execution unit 402 executes the load instruction (“Execute Load”). (As already referenced...) Figure 6C As described, execution unit 402 then determines with exit unit 408 that the load is not the oldest (operation 516, not in...). Figure 6D (Explicitly shown, but represented by interaction 608), thereby triggering operation 504 (“Add Entry”) involving interaction 602 for adding an entry to sorting structure 404. Operation 528 (“Incomplete”) shows that operation 504 is executed by execution unit 402 in a manner that prevents the loading instruction from being marked as complete in exit unit 408. Interaction 620 between execution unit 402 and exit unit 408 is shown as a dashed line to indicate that no completion marking has been performed at this time.

[0092] After the loading and entry addition, execution unit 402 performs operation 530 (“broadcast the loaded data”) to make the loaded data available to any relevant instructions. Subinstructions (not explicitly shown as dissimilar components) can then be executed using this data in operation 532 (“execute subinstruction”). Simultaneously, execution unit 402 can also utilize interaction 610 with computing resource 206 to perform operation 520 (“allocate off-core memory”). Figure 6C This can cause computing resource 206 to request a cache line associated with the address of interest from multiplexed cache 304 (interaction 612), which in turn sends a snoop request to execution unit 402 (interaction 614), which is received at operation 522 (in Figure 6D (Not explicitly shown but understood to lead to operation 506). Once a listening request is received (operation 522), execution unit 402 performs operation 506 ("mark danger") using interaction 604 with sorting structure 404.

[0093] Upon instruction exit, exit unit 408 determines when the load instruction is the oldest (operation 518, not in...). Figure 6D (This is explicitly shown in the diagram, but indicated by interaction 616), thus prompting execution unit 402 to check for a dangerous state. Since the danger is indicated (in operation 506), execution unit 402 performs operation 508 (“refresh load”). In response to this refresh, execution unit 402 performs operation 524 (“get cache line”) with multiplexed cache 304. Figure 6D(Not explicitly shown, but understood to be represented by interaction 618), to obtain the updated cache line. Then, execution unit 402 performs operation 526 ("re-execute load"). After the re-execution of the load instruction, the previously executed sub-instructions are also re-executed in operation 534 ("re-execute sub-instructions").

[0094] Therefore, this diagram illustrates the flow from out-of-order load execution and speculative subinstruction execution to danger detection, refresh, load re-execution, and subinstruction re-execution, thus demonstrating some of the component interactions involved in maintaining procedure correctness. This approach allows subinstructions to complete without delay, thus utilizing the data as soon as it becomes available. It will be understood that if no danger has been detected for that load instruction (e.g., as for the one regarding...),... Figure 5B and Figure 6B In the case of the second load instruction described, the calculations performed by the subinstruction based on the initially loaded data remain valid, and the subinstruction can also exit sequentially without requiring re-execution.

[0095] As already mentioned, the various methods and processes described herein can be implemented, at least in part, as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices. Generally, a processor (e.g., a microprocessor) receives instructions from a non-transitory computer-readable medium (e.g., memory, etc.) and executes those instructions, thereby performing one or more operations such as those described herein. Such instructions can be stored and / or transmitted using any of the various known computer-readable media.

[0096] Computer-readable media (also known as processor-readable media) include any non-transitory medium that contributes to providing data (e.g., instructions) that can be read by a computer (e.g., by the computer's processor). Such media can take many forms, including but not limited to non-volatile and / or volatile media. Non-volatile media may include, for example, optical discs or magnetic disks or other permanent storage. Volatile media may include, for example, dynamic random access memory (DRAM), which typically constitutes main memory.

[0097] Figure 7 An illustrative computing system 700 is shown, which can be implemented by a computing device described herein (e.g., computing device 200) and uses or implements one or more processors (e.g., CPUs, etc.), such as those processors described herein (e.g., processor 202). Figure 7As shown, the computing system 700 may include a communication interface 702, a processor 704 (which may represent an implementation of processor 202 with various components such as a processor core, multiple-access cache, communication bus, memory controller, etc.), a storage device 706, and an input / output (I / O) module 708, all communicatively connected via a communication infrastructure 710. Although in Figure 7 The illustration shows a computing system 700, but... Figure 7 The components shown are not intended to be limiting. Additional or alternative components may be used in other implementations. A more detailed description will follow. Figure 7 The components of the computing system 700 shown are illustrated.

[0098] Communication interface 702 can be configured to communicate with one or more computing devices. Examples of communication interface 702 include, but are not limited to, wired network interfaces (such as network interface cards), wireless network interfaces (such as wireless network interface cards), modems, audio / video connections, and any other suitable interfaces.

[0099] Processor 704 generally refers to any type or form of processing unit capable of processing data or interpreting, executing, and / or directing the execution of one or more of the instructions, procedures, and / or operations described herein. Processor 704 may direct the execution of operations according to one or more applications 712 or other computer-executable instructions, such as those that may be stored in storage device 706 or other computer-readable media.

[0100] Storage device 706 may include one or more data storage media, devices, or configurations, and may take any type, form, and combination of data storage media and / or devices. For example, storage device 706 may include, but is not limited to, hard disk drives, network drives, flash drives, magnetic disks, optical disks, RAM, dynamic RAM, other non-volatile and / or volatile data storage units, or combinations or sub-combinations thereof. Electronic data, including the data described herein, may be temporarily and / or permanently stored in storage device 706. For example, data representing one or more executable applications 712 configured to direct processor 704 to perform any of the operations described herein may be stored within storage device 706. In some examples, data may be arranged in one or more databases residing within storage device 706.

[0101] I / O module 708 may include one or more I / O modules configured to receive user input and provide user output. One or more I / O modules may be used to receive input for a single virtual experience. I / O module 708 may include any hardware, firmware, software, or combinations thereof that support input and output capabilities. For example, I / O module 708 may include hardware and / or software for capturing user input, including but not limited to a keyboard or keypad, a touchscreen component (e.g., a touchscreen display), a receiver (e.g., an RF or infrared receiver), a motion sensor, and / or one or more input buttons.

[0102] I / O module 708 may include one or more means for presenting output to a user, including but not limited to a graphics engine, a display (e.g., a screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers. In some implementations, I / O module 708 is configured to provide graphical data to a display for presentation to a user. The graphical data may represent one or more graphical user interfaces and / or any other graphical content that may serve a particular implementation.

[0103] The following clauses describe how the execution order of load and store instructions processed by the processor core is implemented according to the principles described herein.

[0104] Clause 1. A method comprising: executing, by a core of a processor within a computing device, a load instruction associated with an address, the load instruction following an off-core memory instruction in a program sequence of an instruction set being executed by the computing device; adding an entry for the load instruction to a sorting structure of the core based on the execution of the load instruction being performed while at least one instruction preceding the load instruction in the program sequence has not been exited; marking a danger in the entry for the load instruction in the sorting structure based on a snooping request received by the core for a cache line including the address; and refreshing the load instruction based on the danger in the entry when the at least one instruction preceding the load instruction in the program sequence has been exited.

[0105] Clause 2. The method as described in Clause 1, wherein the load instruction is a first load instruction, the entry is a first entry, and the method further comprises: executing a second load instruction by the core; adding a second entry of the second load instruction to the sorting structure based on the execution of the second load instruction while at least one instruction preceding the second load instruction in the program sequence has not been exited; and exiting the second load instruction based on the absence of a specified danger in the second entry when at least one instruction preceding the second load instruction in the program sequence has been exited.

[0106] Clause 3. The method as described in Clause 1, wherein the core includes an exit unit configured to exit each instruction in the instruction set according to the program order, and the method further includes: using the exit unit to determine, before adding the entry of the load instruction to the sorting structure, that the execution of the load instruction preceding the load instruction in the program order is being executed when at least one instruction has not been exited; and using the exit unit and after marking the danger in the entry of the load instruction, determining that at least one instruction preceding the load instruction in the program order has been exited.

[0107] Clause 4. The method as described in Clause 1, wherein: the computing device further includes computing resources, the computing resources being decoupled from the processor and configured to execute instructions under the direction of the processor; and the method further includes the core directing the computing resources to execute the off-core memory instructions.

[0108] Clause 5. The method as described in Clause 4, wherein: the off-core storage instruction is associated with the address; and the snoop request is received from a multiplexed access cache configured to manage memory for the core and the computing resources, the multiplexed access cache providing the snoop request to the core as part of the off-core storage instruction being executed by the computing resources.

[0109] Clause 6. The method as described in Clause 4, wherein the computing resources are implemented by: a mathematical coprocessor configured to accelerate the execution of mathematical operations; or a graphics processing unit configured to accelerate the execution of graphics operations.

[0110] Clause 7. The method as described in Clause 1, wherein the core includes an exit unit configured to exit each instruction of the instruction set according to the program sequence, and the method further includes: suppressing the marking of the load instruction as complete in the exit unit when the entry is added to the sorting structure; providing loaded data received from the execution of the load instruction for use by a sub-instruction of the load instruction; and executing the sub-instruction using the loaded data prior to the refresh of the load instruction.

[0111] Clause 8. The method of Clause 1 further comprises: in response to the refresh of the load instruction: obtaining the cache line including the address; and re-executing the load instruction based on the cache line.

[0112] Clause 9. The method of Clause 8 further comprises: executing a sub-instruction using loaded data received from the execution of the load instruction prior to the refresh of the load instruction; and re-executing the sub-instruction in response to the refresh of the load instruction and the re-execution of the load instruction.

[0113] Clause 10. The method as described in Clause 1, wherein the sorting structure is implemented by a read-after-read RAR structure within the core, the RAR structure being configured to store a set of entries for ensuring a programmed sorting of the load operation, each of the entries including an entry address, an instruction age indicator, and a danger indicator.

[0114] Clause 11. The method as described in Clause 1, wherein: the off-core memory instruction is one of a plurality of off-core memory instructions preceding the load instruction in the program sequence; and the kernel suppression local tracks the addresses of the plurality of off-core memory instructions preceding the load instruction in the program sequence.

[0115] Clause 12. A processor core within a computing device, the core comprising: a sorting structure; and an execution unit configured to: execute a load instruction associated with an address, the load instruction following an off-core memory instruction in a program sequence of an instruction set being executed by the core; add an entry for the load instruction to the sorting structure based on the fact that at least one instruction preceding the load instruction in the program sequence has not yet exited; mark a danger in the entry for the load instruction in the sorting structure based on a snooping request received by the core for a cache line including the address; and refresh the load instruction based on the danger in the entry when the at least one instruction preceding the load instruction in the program sequence exits.

[0116] Clause 13. The core as described in Clause 12, wherein the load instruction is a first load instruction, the entry is a first entry, and the execution unit is further configured to: execute a second load instruction; add a second entry of the second load instruction to the sorting structure based on the fact that at least one instruction preceding the second load instruction in the program sequence has not been exited; and exit the second load instruction based on the absence of a specified danger in the second entry when the at least one instruction preceding the second load instruction in the program sequence has been exited.

[0117] Clause 14. The core as described in Clause 12 further includes an exit unit configured to exit each instruction in the instruction set according to the program sequence; wherein the execution unit is further configured to: use the exit unit to determine, before adding the entry of the load instruction to the sorting structure, that at least one instruction preceding the load instruction in the program sequence has not been exited; and use the exit unit and after marking the danger in the entry of the load instruction, determine that at least one instruction preceding the load instruction in the program sequence has been exited.

[0118] Clause 15. The core as described in Clause 12, wherein: the computing device further includes computing resources, the computing resources being decoupled from the processor and configured to execute instructions under the direction of the processor; and the execution unit is further configured to direct the computing resources to execute the off-core memory instructions.

[0119] Clause 16. The core as described in Clause 12 further includes an exit unit configured to exit each instruction in the instruction set according to the program order; wherein the execution unit is further configured to: suppress marking the load instruction as complete in the exit unit when the entry is added to the sorting structure; provide loaded data received from the execution of the load instruction for use by sub-instructions of the load instruction; and execute the sub-instructions using the loaded data prior to the refresh of the load instruction.

[0120] Clause 17. A computing device comprising: a processor including a core having a sorting structure and an execution unit; and computing resources decoupled from the processor and configured to execute instructions under the direction of the processor; wherein the execution unit of the core is configured to: execute a load instruction associated with an address, the load instruction following an out-of-core memory instruction in a program sequence of an instruction set being executed by the core; add an entry of the load instruction to the sorting structure; direct the computing resource to execute the out-of-core memory instruction; mark a danger in the entry of the load instruction in the sorting structure based on a snooping request received by the core for a cache line including the address; and refresh the load instruction based on the danger in the entry when all instructions preceding the load instruction in the program sequence have exited.

[0121] Clause 18. The computing device as described in Clause 17, wherein the load instruction is a first load instruction, the entry is a first entry, and the execution unit of the core is further configured to: execute a second load instruction; add a second entry of the second load instruction to the sorting structure based on the fact that the second load instruction is being executed while at least one instruction preceding the second load instruction in the program sequence has not been exited; and exit the second load instruction when at least one instruction preceding the second load instruction in the program sequence has been exited, based on the absence of a specified danger in the second entry.

[0122] Clause 19. The computing device as described in Clause 17, wherein: the processor further includes a multiplexed cache configured to manage memory for the core and the computing resources; the off-core memory instruction is associated with the address; and the probe request is received from the multiplexed cache as part of the off-core memory instruction being executed by the computing resources.

[0123] Clause 20. The computing device as described in Clause 17, wherein the computing resources are implemented by: a mathematical coprocessor configured to accelerate the execution of mathematical operations; or a graphics processing unit configured to accelerate the execution of graphics operations.

[0124] Various implementations of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system, which includes at least one programmable processor, which may be dedicated or general-purpose, and is coupled to receive and transmit data and instructions from and to a storage system, at least one input device, and at least one output device.

[0125] Various implementations have been described. However, it will be understood that various modifications may be made without departing from the spirit and scope of the specification and claims. Furthermore, the logical flow depicted in the figures does not require the desired result to be achieved in the specific order or sequence shown. Additionally, other steps may be provided, or steps may be removed from the described flow, and other components may be added to or removed from the described system. Therefore, other implementations are within the scope of the following claims.

[0126] The specific structural and functional details disclosed in this article are representative only for the purpose of describing the example implementation. However, the example implementation can be embodied in many alternative forms and should not be construed as being limited to the implementation described in this article.

[0127] It should be understood that although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. A first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the implementations of this disclosure. As used herein, the term "and / or" includes any and all combinations of one or more of the associated items.

[0128] The terminology used herein is for the purpose of describing a particular implementation only and is not intended to limit the implementation. As used herein, unless the context clearly indicates otherwise, the singular forms “a / an” and “the” are intended to include the plural forms as well. It should be further understood that the terms “comprises, comprising, includes, and / or including” as used in this specification specify the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0129] It should be understood that when an element is referred to as being “coupled” to, “connected” to, or “in response to” or “on” another element, the element may be directly coupled to, connected to, or in response to, or on the other element, or there may be intermediate elements present. Conversely, when an element is referred to as being “directly coupled” to, “directly connected” to, or “directly in response to” another element or “directly on” another element, there are no intermediate elements present. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0130] For ease of description, spatially relative terms such as “below,” “under,” “down,” “above,” and “above” may be used herein to describe the relationship between one element or feature and another element or feature as shown in the figures. It should be understood that spatially relative terms are intended to cover different orientations of the device in use or operation, in addition to those depicted in the figures. For example, if the device in the figures is flipped, then an element described as “below” or “under” other elements or features would be oriented as “above” other elements or features. Therefore, the term “below” can encompass both above and below orientations. The device may be oriented in other ways (rotated 130 degrees or in other orientations), and the spatially relative descriptors used herein may be interpreted accordingly.

[0131] Unless otherwise defined, the terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which these concepts belong. It should further be understood that terms such as those defined in common dictionaries should be interpreted as having a meaning consistent with their meaning in the relevant field and / or the context of this specification, and should not be interpreted in an overly formal sense unless expressly defined herein.

[0132] In addition to the description above, users can be provided with controls that allow them to choose whether and when the system, program, or feature described herein enables the collection of user information (e.g., information about the user's social networks, social actions or activities, occupation, user preferences, or the user's current location) and whether to send content or communications to the user from the server. Furthermore, some data may be processed in one or more ways before it is stored or used, resulting in the removal of personally identifiable information. For example, a user's identity may be processed to the point that their personally identifiable information cannot be determined, or the user's geographic location may be generalized, or location information (such as down to the city, zip code, or state level) may be obtained, making it impossible to determine the user's specific location. Therefore, users can control what information is collected, how that information is used, and what information is provided to them.

[0133] While certain features of the described implementations have been exemplified as described herein, many modifications, substitutions, alterations, and equivalents will occur to those skilled in the art. Therefore, it should be understood that the appended claims are intended to cover such modifications and alterations falling within the scope of the implementations. It should be understood that they are presented by way of example only and not limitation, and various changes in form and detail are possible. Any part of the apparatus and / or method described herein can be combined in any combination, except for mutually exclusive combinations. The implementations described herein may include various combinations and / or sub-combinations of the functions, components, and / or features of the different implementations described. Thus, the scope of this disclosure is not limited to the specific combinations claimed below, but instead extends alternatively to encompass any combination of features or exemplary implementations described herein, regardless of whether such specific combination has been specifically enumerated in the appended claims herein.

Claims

1. A method comprising: Load instructions associated with addresses are executed by the core of the processor within the computing device. These load instructions follow off-core memory instructions in the program sequence of the instruction set being executed by the computing device. The execution of the loading instruction is carried out when at least one instruction preceding the loading instruction in the program sequence has not been exited, and the entry of the loading instruction is added to the sorting structure of the core. Based on the snooping request received by the core for a cache line including the address, a danger is marked in the entry of the load instruction in the sorting structure; as well as When at least one instruction preceding the load instruction in the program sequence is exited, the load instruction is refreshed based on the danger in the entry.

2. The method as described in claim 1, wherein, The load instruction is a first load instruction, the entry is a first entry, and the method further includes: The core executes the second loading instruction; The execution of the second load instruction is carried out when at least one instruction preceding the second load instruction in the program sequence has not yet been exited, and the second entry of the second load instruction is added to the sorting structure; and When at least one instruction preceding the second load instruction in the program sequence is exited, the second load instruction exits based on the absence of the indicated danger in the second entry.

3. The method as described in claim 1, wherein, The core includes an exit unit configured to exit each instruction in the instruction set according to the program sequence, and the method further includes: The exit unit determines, before adding the entry of the load instruction to the sorting structure, that the execution of the load instruction is carried out when at least one instruction preceding the load instruction in the program sequence has not been exited; and After using the exit unit and marking the danger in the entry of the load instruction, it is determined that at least one instruction preceding the load instruction in the program sequence has been exited.

4. The method of claim 1, wherein: The computing device further includes computing resources, which are decoupled from the processor and configured to execute instructions under the guidance of the processor; and The method further includes the core directing the computing resources to execute the off-core storage instructions.

5. The method of claim 4, wherein: The off-core storage instruction is associated with the address; and The snoop request is received from a multiplexed cache configured to manage memory for the core and the computing resources, the multiplexed cache providing the snoop request to the core as part of an off-core memory instruction being executed by the computing resources.

6. The method of claim 4, wherein, The computing resources are implemented in the following ways: A mathematical coprocessor, configured to accelerate the execution of mathematical operations; or A graphics processing unit configured to accelerate the execution of graphics operations.

7. The method of claim 1, wherein, The core includes an exit unit configured to exit each instruction in the instruction set according to the program sequence, and the method further includes: When the entry is added to the sorting structure, the loading instruction is prevented from being marked as complete in the exit unit; Provide the loaded data received during the execution of the load instruction for use by the sub-instructions of the load instruction; and The sub-instruction is executed using the loaded data prior to the refresh of the loading instruction.

8. The method of claim 1, further comprising: The refresh in response to the load command: Obtain the cache line containing the address; as well as The load instruction is re-executed based on the cache line.

9. The method of claim 8, further comprising: Prior to the refresh of the load instruction, a sub-instruction is executed using the loaded data received from the execution of the load instruction; as well as In response to the refresh of the load instruction and the re-execution of the load instruction, the sub-instruction is re-executed.

10. The method of claim 1, wherein, The sorting structure is implemented by a read-after-read RAR structure within the core. The RAR structure is configured to store a set of entries used to ensure the programmed sorting of the load operation. Each of the entries includes an entry address, an instruction age indicator, and a danger indicator.

11. The method of claim 1, wherein: The off-core store instruction is one of a plurality of off-core store instructions preceding the load instruction in the program sequence; and The core suppression local traces the addresses of the plurality of off-core memory instructions preceding the load instruction in the program sequence.

12. The core of a processor within a computing device, the core comprising: Sorting structure; as well as Execution unit, the execution unit being configured as follows: Execute load instructions associated with addresses, which follow off-core memory instructions in the program sequence of the instruction set being executed by the core; The entry of the loading instruction is added to the sorting structure based on the fact that at least one instruction preceding the loading instruction in the program sequence has not been exited. Based on the snooping request received by the core for a cache line including the address, a danger is marked in the entry of the load instruction in the sorting structure; as well as When at least one instruction preceding the load instruction in the program sequence is exited, the load instruction is refreshed based on the danger in the entry.

13. The core as described in claim 12, wherein, The load instruction is a first load instruction, the entry is a first entry, and the execution unit is further configured to: Execute the second load instruction; Based on the fact that at least one instruction preceding the second load instruction in the program sequence has not been exited before the second load instruction is executed, a second entry of the second load instruction is added to the sorting structure; as well as When at least one instruction preceding the second load instruction in the program sequence is exited, the second load instruction exits based on the absence of the indicated danger in the second entry.

14. The core of claim 12, further comprising an exit unit configured to exit each instruction in the instruction set according to the program sequence; in, The execution unit is further configured as follows: Before adding the entry of the load instruction to the sorting structure, the exit unit determines that the load instruction is executed when at least one instruction preceding the load instruction in the program sequence has not been exited. as well as After using the exit unit and marking the danger in the entry of the load instruction, it is determined that at least one instruction preceding the load instruction in the program sequence has been exited.

15. The core as described in claim 12, wherein: The computing device further includes computing resources, which are decoupled from the processor and configured to execute instructions under the guidance of the processor; and The execution unit is further configured to direct the computing resources to execute the off-core memory instructions.

16. The core of claim 12, further comprising an exit unit configured to exit each instruction in the instruction set according to the program sequence; in, The execution unit is further configured as follows: When the entry is added to the sorting structure, the loading instruction is prevented from being marked as complete in the exit unit; Provide the loaded data received during the execution of the load instruction for use by the sub-instructions of the load instruction; and The sub-instruction is executed using the loaded data prior to the refresh of the loading instruction.

17. A computing device, comprising: The processor includes a core having a sorting structure and an execution unit; as well as Computing resources, which are decoupled from the processor and configured to execute instructions under the guidance of the processor; The core execution unit is configured as follows: Execute load instructions associated with addresses, which follow off-core memory instructions in the program sequence of the instruction set being executed by the core; Add the entry of the load instruction to the sorting structure; Instruct the computing resources to execute the off-core memory instructions; Based on the snooping request received by the core for a cache line including the address, a danger is marked in the entry of the load instruction in the sorting structure; and When all instructions preceding the load instruction in the program sequence are exited, the load instruction is refreshed based on the danger in the entry.

18. The computing device of claim 17, wherein, The load instruction is a first load instruction, the entry is a first entry, and the core execution unit is further configured as follows: Execute the second load instruction; Based on the fact that at least one instruction preceding the second load instruction in the program sequence has not been exited before the second load instruction is executed, a second entry of the second load instruction is added to the sorting structure; as well as When at least one instruction preceding the second load instruction in the program sequence is exited, the second load instruction exits based on the absence of the indicated danger in the second entry.

19. The computing device of claim 17, wherein: The processor further includes a multiplexed cache configured to manage memory for the core and the computing resources; The off-core storage instruction is associated with the address; and The snooping request is received from the multiple access cache as part of the out-of-core storage instruction being executed by the computing resources.

20. The computing device of claim 17, wherein, The computing resources are implemented in the following ways: A mathematical coprocessor, configured to accelerate the execution of mathematical operations; or A graphics processing unit configured to accelerate the execution of graphics operations.

Images