Hazard checks in task delegation

Abstract

The data processing apparatus comprises a data processing pipeline for performing data processing operations and an extension processing circuit for executing delegated tasks asynchronously to the data processing pipeline in response to a decoding circuit for decoding extension start instructions. The apparatus also comprises a hazard detection circuit for detecting data hazards associated with processing operations performed by the data processing pipeline. When the data processing pipeline is in an extension hazard check state, the presence of a hazard condition may be determined depending on whether a given memory access to be performed in program order in response to a given memory access instruction following an extension start instruction is for accessing an address that falls within a group of addresses expected to be accessed by the extension processing circuit during the execution of a delegated task.

Description

Technical Field

[0001] This technique relates to the field of data processing.

[0002] The apparatus may comprise a data processing pipeline configured to execute data processing operations in response to a sequence of received instructions. There may be a desire to improve performance while executing data processing operations without affecting the accuracy of the data processing operations being performed.

[0003] At least some examples are apparatuses for data processing, a data processing pipeline comprising a decoder circuit responsive to receipt of a sequence of instructions for generating control signals for controlling the data processing pipeline to perform data processing operations, an extension processing circuit associated with the data processing pipeline and configured to asynchronously execute delegated tasks with respect to the data processing operations performed by the data processing pipeline in response to the decoder circuit decoding an extension start instruction, a hazard detection circuit for detecting data hazards associated with the processing operations performed by the data processing pipeline when the data processing pipeline is in an extended hazard check state with respect to a delegated task, comprising, when the data processing pipeline is in an extended hazard check state with respect to a delegated task, the hazard detection circuit is configured to determine the presence of a hazard condition in response to execution by the data processing pipeline of a given memory access instruction following an extension start instruction in program order, depending on whether the given memory access being executed accesses an address within a group of addresses indicated by grouped address indication data, The hazard detection circuit provides an apparatus that executes a hazard resolution action in response to the presence of a hazard condition.

[0004] At least some examples herein provide non-temporary computer-readable media for storing computer-readable codes for the manufacture of the above-described devices.

[0005] At least a few examples are methods of data processing, The data processing pipeline executes data processing operations according to the instructions in the sequence of instructions decoded by the decoder. In response to the decoding circuit decoding the extension start instruction, the extension processing circuit associated with the data processing pipeline executes a delegated task asynchronously with respect to the data processing operations performed by the data processing pipeline, Using a hazard detection circuit, when the data processing pipeline is in an extended hazard check state with respect to a delegated task, data hazards associated with processing operations performed by the data processing pipeline are detected. When the data processing pipeline is in an extended hazard check state with respect to a delegated task, a hazard detection circuit is used to determine the existence of a hazard condition depending on whether a given memory access performed in response to the execution of a given memory access instruction by the data processing pipeline following an extended start instruction in the program sequence is for accessing an address that falls within a group of addresses indicated by grouped address instruction data. The present invention provides a method that includes taking hazard resolution actions in response to the presence of hazard conditions.

[0006] At least some examples provide a computer program that controls a host data processing device to provide an instruction execution environment, and the computer program is A data processing pipeline program logic comprising a decoder program logic that responds to the reception of instructions for a sequence of instructions for generating control signals to control the data processing pipeline program logic to perform data processing operations, An extension processing program logic associated with the data processing pipeline program logic, configured to asynchronously perform delegated tasks with respect to data processing operations performed by the data processing pipeline program logic in response to the decoding program logic decoding the extension start instruction, The system includes: a hazard detection program logic that detects data hazards associated with processing operations performed by the data processing pipeline program logic when the data processing pipeline program logic is in an extended hazard check state with respect to a delegated task; When the data processing pipeline program logic is in an extended hazard check state with respect to a delegated task, the hazard detection program logic is configured to determine the existence of a hazard condition depending on whether a given memory access performed in response to the execution of a given memory access instruction by the data processing pipeline program logic following an extended start instruction in the program sequence is for accessing an address that falls within a group of addresses indicated by grouped address instruction data. The hazard detection program logic performs hazard resolution actions in response to the presence of hazard conditions.

[0007] Computer programs may be stored on computer-readable media. These media may be non-temporary. [Brief explanation of the drawing]

[0008] Further aspects, features, and advantages of this technique will become apparent from the following example description, which should be read in conjunction with the attached drawings. [Figure 1] A schematic diagram of a data processing device that can embody various embodiments of this technique is shown. [Figure 2] A schematic diagram of a data processing device that can embody various embodiments of this technique is shown. [Figure 3] A schematic diagram of a data processing device that can embody various embodiments of this technique is shown. [Figure 4]This is a state diagram illustrating an exemplary set of states to which the extended processing circuit of this technique can transition. [Figure 5] The following diagram illustrates an extended start instruction that delegates a task to an extended processing circuit, based on several embodiments. [Figure 6] The extended start instruction, which delegates a task to one of several instances of the extended processing circuit according to several embodiments, is illustrated diagrammatically. [Figure 7] A schematic diagram of a data processing device that can embody various embodiments of this technique is shown. [Figure 8] This flowchart illustrates the sequence of steps taken in response to decoding an extended start instruction, using several examples. [Figure 9] This flowchart illustrates the sequence of steps taken in response to decoding a write command, using several examples. [Figure 10] This flowchart illustrates the sequence of steps taken in response to decoding a read command, using several examples. [Figure 11] This is a state diagram illustrating an exemplary set of states to which the hazard detection circuit of this technique may transition. [Figure 12] The following outlines the possible implementations of the simulator that may be used.

[0009] A device equipped with a data processing pipeline may be required to perform various data processing operations, as defined by the sequence of instructions provided to it. To efficiently perform these data processing operations, the data processing pipeline may consist of various functional units, each possessing a given special type of data processing capability, such as arithmetic logic units (ALUs), floating-point (FP) units, and load / store units. Furthermore, even when such specialized functional units are provided as part of the data processing pipeline, the inventors of this technique have established that there may be certain functions that require a processing load that is frequently executed in certain types of data processing, i.e., in specific programs (i.e., sequences of instructions), and can significantly impact the overall performance of the device, making it worthwhile to provide dedicated custom hardware to support these functions. In identifying such functions, two important characteristics were considered relevant: the ubiquity of the function (i.e., its presence in many other use cases) and the impact of the function (i.e., the proportion of time spent executing such a function is a significant portion of the total runtime, and as a result, improvements in the execution of that function make a significant difference to the overall use case). Such influential ubiquitous functions are known to include tasks or functions such as memcpy, memset, compression, encryption, and string processing, but the technique is not limited to these specific examples. The technique provides an extension processing circuit that is associated with a data processing pipeline and configured to perform such functions (delegated tasks) in response to delegation signals received from the data processing pipeline. Such an extension processing circuit may also be referred to herein as a threadlet extension (TE). The extension processing circuit is closely associated with (tightly coupled to) the data processing pipeline but is configured to perform delegated tasks asynchronously with respect to the data processing operations performed by the data processing pipeline. The data processing pipeline may also be referred to herein as the CPU.A threadlet is a set of functions or operations that, once initiated, can be executed asynchronously relative to other CPU activity. The asynchronous operation of extension circuits for data processing pipelines is possible because, unlike some conventional techniques, the extension circuit receives instructions or commands from threads currently running on the CPU and executes the necessary operations independently—that is, without requiring a stream of instructions from the CPU that directly controls or influences its internal operation. Therefore, the CPU is free to continue executing other code, potentially reducing overall runtime by overlapping the execution of the instruction stream after the instructions or commands are sent to the extension circuit with the operation of the extension circuit itself.

[0010] The data processing pipeline executes an extension start instruction to initiate the execution of a delegated task to the extension processing circuit, and then may advance subsequent processing instructions in the program order while the delegated task is being executed by the extension processing circuit. However, this may create the possibility of data hazards. While the delegated task is being executed, the extension processing circuit may perform memory accesses, such as reading and writing to addresses in the address space shared with the data processing pipeline. For example, the extension processing circuit and the data processing pipeline may share access to main memory and one or more levels of shared cache. Data dependencies may exist between memory accesses performed by the extension processing circuit and memory accesses performed by the data processing pipeline.

[0011] Access to specific locations in memory can be expected to be executed in an order corresponding to the order of the instructions that cause those accesses (program order). If this ordering is not respected, data hazards (including read-after-write, write-after-read, and write-after-write hazards) may occur, which can lead to the calculation of incorrect results. In particular, memory accesses performed as part of a delegated task may be associated with the same point in program order as the extension start instruction. Memory accesses caused by instructions following the extension start instruction in program order can, architecturally, be expected to be executed after any memory accesses of the delegated task. However, since extension processing circuits may operate asynchronously with respect to the data processing pipeline, the data processing pipeline may not be aware of which memory accesses were performed by extension processing circuits as part of a delegated task, and therefore it may be difficult to identify potential data hazards.

[0012] If the data processing pipeline performs memory accesses in response to instructions following the extension start instruction in program order, regardless of the extension processing circuit, there is a risk that those memory accesses may be performed before the extension processing circuit reaches part of the delegated task involving memory accesses to the same location. Therefore, there is a risk that memory accesses performed during the delegated task (earlier in program order) may actually be performed later than memory accesses performed by the data processing pipeline in response to instructions later in program order.

[0013] One approach to avoiding data hazards between delegated tasks and data processing operations executed in response to subsequent instructions is to write the program in a way that avoids potential hazards. For example, a program could be written to execute subsequent memory accesses that have data dependencies on a delegated task only in response to some confirmation that the delegated task has reached a specific point where a data hazard is unlikely to occur, such as the termination of the delegated task. For example, an extended synchronization instruction could be defined to determine whether a delegated task has reached a specific point, and a program that reaches a subsequent memory access instruction that has data dependencies on a delegated task could rely on a synchronization instruction that returns a value indicating that the delegated task has reached a specific point (for example, it might be located on a branch that is only reached in response to such an instruction).

[0014] However, writing programs to avoid hazards between delegated tasks and subsequent instructions can be a potentially high burden on programmers. In particular, determining the existence of data dependencies between delegated tasks and subsequent instructions can be difficult, and at least part of this difficulty may stem from the difficulty in determining the degree of producer-consumer relationships in the code. Programmers may overlook data dependencies, resulting in data hazards, or they may be overly cautious, unnecessarily preventing certain memory accesses from occurring and impairing performance. In either case, this difficulty may completely prevent the use of extension circuits, which is undesirable from a performance standpoint.

[0015] An alternative approach to preventing incorrect processing due to data hazards between delegated tasks and data processing operations executed in response to subsequent instructions is to enable execution of code that does not rely on prior knowledge that reaching a memory access instruction following an extended start instruction in program order will not cause a data hazard (e.g., due to synchronization between the CPU and the TE) without imposing too much burden on the programmer. Instead, accesses made by both the CPU and the TE can be tracked, and then a tracking mechanism can be provided to identify and handle data hazards when they occur.

[0016] Such an approach for identifying data hazards can involve tracking reads and writes made by an extended processing circuit during execution of a delegated task, tracking reads and writes made by a processing pipeline while the delegated task is being executed, and generating read and write sets by identifying hazards based on a comparison between the sets of tracked memory accesses. However, such an approach potentially requires tracking a large number of memory accesses, which are potentially tracked until completion of the delegated task. As the size of the delegated task, and typically the number of memory accesses involved in execution of the delegated task, increases, the overhead associated with maintaining and using the set of memory accesses tracked for hazard checking also increases. In addition to the potentially large hardware expense for storing the set of memory accesses to be tracked, having a large amount of information related to the memory addresses being tracked can be undesirable when encountering a context switch, such as when the program is interrupted, as this information must be saved and restored along with the rest of the current context. This can negatively impact the context size and potentially slow down the context switch. Therefore, the inventors have recognized that an approach based on tracking reads and writes does not scale well for large delegated tasks.

[0017] However, the inventors have observed that certain delegated tasks can have memory access characteristics that can be used to provide a scheme for identifying potential data hazards with lower overhead than tracking read and write sets. In particular, tasks that can benefit from being delegated to an extended processing circuit can include tasks that operate on data stored in a region of memory designated as a source buffer and store the result of the operation in a region of memory designated as a destination buffer, where the positions of the source buffer and the destination buffer (which are not necessarily contiguous regions of memory) are known in advance. Examples of such tasks include memcpy, which involves moving data from a first region of memory (source buffer) to a second region of memory (destination buffer), encryption or compression of data stored in a first region of memory, where the encrypted or compressed data is stored in a second region of memory, encryption or compression, certain matrix processing operations, and the like. More generally, there are processing tasks that can be offloaded to an asynchronous extended processing circuit, and it is known in advance that there is a group of addresses that are expected to be accessed by the extended processing circuit during the execution of the delegated task.

[0018] When a task is delegated to an extension processing circuit in which a specific group of addresses is expected to be accessed, knowledge of the group of addresses in which memory access is expected can be used by a hazard detection circuit to identify data hazards. Grouped address instruction data may be made available to the hazard detection circuit and may indicate one or more groups of addresses that are expected to be accessed by the extension processing circuit during the execution of the delegated task. The hazard detection circuit can determine whether a data hazard may exist based on whether the memory access performed in response to the execution of the data processing pipeline of the instruction following the extension start instruction in program order is for accessing a location in memory that falls within the group of addresses indicated by the grouped address instruction data. A particular memory access can be compared to a specific group of accesses expected to be performed by the extension processing circuitry. For example, a subsequent read in program order can be compared only to writes (not reads) expected to be performed by the extension processing circuitry, such that it is identified by grouped address indication data showing the addresses used for such write accesses. However, some memory accesses can be compared to all types of accesses expected to be performed by the extension processing circuitry. For example, the address of a subsequent write can be compared to a group of one or more identified addresses for both reads and writes expected to be performed by the delegated task (to identify both WAR and WAW hazards).

[0019] Therefore, since it is possible to know when a task is delegated by the processing pipeline and which groups of memory addresses the delegated task is expected to access, hazard checks for data processing operations performed by the processing pipeline can be performed by referring to those groups without tracking individual reads and writes. This can result in a significant reduction in the state that needs to be maintained during the execution of delegated tasks, while enabling support for implementations that do not rely on programmer write code to avoid data hazards.

[0020] If a data hazard is detected, it can be handled in several ways, depending on the type of memory access involved, but generally, action is taken to resolve the potential data hazard, thereby preventing incorrect calculations from occurring as a result of a later memory access instruction in program order executing before an earlier memory access instruction in program order. In a basic example where a potential data hazard is identified, memory access of an instruction following an extended start instruction may be delayed until the delegated task is complete. Further examples are given below.

[0021] When a data processing pipeline is in an extended hazard-checking state with respect to a particular delegated task, a hazard detection circuit can be considered to be in a hazard-checking state with respect to that particular delegated task, capable of determining whether a hazard condition exists for that task. While a hazard detection circuit can remain in a hazard-checking state, it may also terminate the hazard-checking state under certain conditions. For example, there may be areas of code where the programmer is not concerned with the possibility of data hazards and the use of a hazard detection circuit is not required. In these situations, the hazard-checking state may be terminated to reduce overhead such as power and storage usage associated with the hazard detection circuit. An extended processing circuit may support processing two or more delegated tasks at once, and a hazard detection circuit may support being in a hazard-checking state with respect to a subset of delegated tasks and not being in a hazard-checking state with respect to other delegated tasks.

[0022] A programmer may provide control over entering an extended hazard check state for a particular delegated task through the use of instructions. For example, a decoder circuit associated with a processor pipeline may be configured to generate a control signal in response to an extended hazard check start instruction, instructing the processing pipeline to enter an extended hazard check state for the delegated task.

[0023] An extended hazard check start instruction may be an instruction that, when executed at any point in the program, such as while the extension circuit is executing a delegated task, causes the pipeline to enter a hazard check state with respect to the delegated task. The instruction may be associated with a particular delegated task via parameters (e.g., a TE identifier that identifies the specific TE on which a hazard check is desired). However, it has been confirmed that programmers can generally know whether a delegated task can be executed entirely without the risk of data hazards, and therefore, at the point in which a delegated task is started, they can generally know whether a hazard check is required during the execution of that delegated task. Thus, it may be useful to enter a hazard check state with respect to a delegated task when starting that task. To reduce the number of instructions executed when starting such a task, the extended hazard check start instruction may also be an extended start instruction, and the extension processing circuit is configured to both start a delegated task and enter an extended hazard check state with respect to that delegated task in response to the decoding circuit decoding an extended hazard check start instruction.

[0024] When an extended hazard check instruction triggers an extended hazard check state for a particular delegated task, the hazard detection circuit is provided with access to grouped address indication data that shows which addresses are expected to be accessed by the extended processing circuit during the execution of that delegated task. This allows the hazard detection circuit to compare the addresses of subsequent memory accesses with that group(s) of addresses to determine whether a data hazard condition exists. The hazard detection circuit may be configured to access this information from some known location, such as a location where the grouped address indication data is pre-stored by the processing pipeline. For example, the information may be stored in a control register accessible by the hazard detection circuit. However, in some examples, the grouped address indication data may be specified by an extended hazard check start instruction. Specifying the grouped address indication data using this instruction may be particularly efficient when the extended hazard check start instruction also starts a delegated task. For example, in the extended start modification of the extended hazard check start instruction, the process of describing the delegated task may specify several areas of memory as the source buffer and destination buffer of the delegated task, and such definitions of the source buffer and destination buffer may be reused to define a group of addresses that the extended processing circuit is expected to access when executing the delegated task.

[0025] An extended hazard check initiation instruction can specify grouped address instruction data in several ways. For example, grouped address instruction data may be specified as an immediate value in the instruction encoding. However, in practice, the amount of encoding space in an instruction is limited, and it may be preferable to specify grouped address instruction data by identifying at least one register whose contents are used to determine the grouped address instruction data within a set of registers for holding data values ​​on which data processing operations are performed. If the grouped address instruction data is identified by several parameters, it may be implicit in the instruction encoding which register stores which parameter (i.e., registers identified in a particular field of the instruction may always be assumed to store the same parameter). However, in other examples, additional registers may provide information identifying which parameter is stored in which identified register. This may occur because there may be two different application programming interfaces (APIs): one matching the functional signature of a delegated task, and the other indicating parameters that may be used by a hazard detection circuit. It may be advantageous for the two APIs to be aligned, but they do not need to be aligned, and additional registers may provide mappings between the two APIs. The hazard detection circuit may store in its internal memory circuit information that defines one or more groups of addresses expected to be accessed by the delegated task, based on the information specified in the extended hazard check start instruction.

[0026] In some cases, a group of addresses expected to be accessed by an extension processing circuit while it is performing a delegated task may be described using a range of addresses in memory. There are several workloads that can be delegated to an extension processing circuit where the source and destination buffers may be described as a range. Not all addresses within a range may actually be accessed, but describing a group as a range can be particularly efficient for performing hazard checks because, instead of comparing an address to many different, discontinuous addresses, it is possible to determine whether there is a potential data hazard using a maximum of two comparisons (a first comparison with the first address in the range, and a second comparison with the last address in the range). Furthermore, less storage may be required to define an address range than, for example, to maintain a record of many different groups of addresses. When a group of addresses expected to be accessed by an extension processing circuit is an address range, in one exemplary implementation, the address instruction data may include a first parameter and a second parameter, at least one of the first and second parameters providing an address instruction, and the first and second parameters are used together to determine the starting address and size of the range. For example, the first and second parameters may be the first and last addresses within the range. Alternatively, they may specify parameters that describe the addresses (such as the first address, last address, some intermediate address, or an address at some predetermined distance outside the range) and the size of the range. The hazard detection circuit may calculate the range based on the two parameters, for example, by calculating the last address if the last address is not included in the two parameters.

[0027] The inventors have recognized that there are certain delegated tasks in which it may be determined that certain addresses will not be accessed again as the task progresses. For example, some delegated tasks involve a linear data stream (sometimes called a channel) in which addresses in a source buffer are read a certain number of times and addresses in a destination buffer are written a certain number of times. After being read a certain number of times or written a certain number of times, a given address may be determined not to be accessed again by the extension circuit. When such a task is being executed, memory accesses associated with subsequent instructions can no longer access those addresses before the extension circuit, so the risk of data hazard may be eliminated for addresses that have already been accessed a certain number of times by the extension circuit. Therefore, hazard checks may be relaxed with respect to addresses that will not be accessed again as part of a delegated task.

[0028] Considering the above, in one exemplary implementation, the extension processing circuit may be configured to maintain a progress indicator that shows a subset of addresses that are accessed a certain number of times during the execution of a delegated task and are not expected to be accessed again during the delegated task. The progress indicator may simply indicate that an address has been accessed anyway when it has been accessed a certain number of times and is not expected to be accessed again by the extension processing circuit. If the address of a subsequent memory access falls within a group of addresses that are expected to be accessed by the delegated task, the hazard detection circuit can compare the address to the progress indicator to determine whether that address has already been accessed a certain number of times by the extension processing circuit, and if so, it can determine that the likelihood of a data hazard is low. Thus, the progress indicator can be used to eliminate false positives from a set of accesses identified using grouped address indication data that shows addresses that are expected to be accessed by the extension processing circuit. This can improve performance because data hazard resolution actions that may have a high performance impact, such as stalling the CPU to allow the delegated task to complete, can be avoided when they are not actually necessary (but appear necessary without any knowledge of the progress of the delegated task).

[0029] In one example, the progress indicator may have a bit corresponding to an address, the value of which indicates whether the corresponding address has been accessed a certain number of times. However, in some examples, addresses may be accessed in a predetermined order. In such cases, a more scalable progress indicator (whose size does not depend on the size of the group of addresses expected to be accessed) may be a pointer to a single address in memory, where each address in the group of addresses preceding the pointer address in a predetermined order is considered to have been accessed a certain number of times by the extension processing circuit during the execution of the delegated task, and each address following the pointer is still expected to be accessed. The address pointed to by the pointer can be considered the most recently accessed address, or an address that has not yet been accessed but is expected to be accessed next.

[0030] Hazard detection circuitry may compare candidate addresses with one or both of the groups of addresses expected to be read by the delegated task and the groups of addresses expected to be written by the delegated task. In such cases, different progress indicators may be maintained for each of the read and write groups. However, even when independent read and write groups exist, if data access is expected to occur at the same relative point within each group (for example, if memcpy is expected to write to essentially the same number of locations as it reads), there may be a single progress indicator that applies to both groups.

[0031] In some examples, the hazard detection circuit is configured to access a state that defines write groups of memory addresses that the extension processing circuit is expected to write data to during the execution of a delegated task. For example, the hazard detection circuit may maintain a record of a portion of grouped address indication data that indicates addresses that are expected to be written to during the execution of a delegated task. The hazard detection circuit may also access a write progress indicator that indicates a subset of write addresses within a write group to which data has been written by the extension processing circuit during the execution of a delegated task, as described above. Tracking write groups of memory addresses (and write progress indicators for filtering such write groups) can be useful in identifying write-after-write and read-after-write data hazards, as described below.

[0032] A hazard detection circuit may be configured to detect a read-after-write hazard condition in response to a determination that a given memory access instruction is intended to read data from a given address at a location within a write group indicated by a write progress indicator as an address where data has not yet been written by the extension processing circuit. When a memory access instruction that is later in the program sequence than an extension start instruction reads from a location that is the destination location of a delegated task, the correct sequence of operations includes the delegated task writing to that location before a subsequent read instruction reads from that location. Instead, a read-after-write hazard occurs when a subsequent read is attempted before the delegated task writes to a given memory address. If the subsequent read is allowed to proceed, it will read outdated information that leads to an incorrect result. It will be understood that a “read instruction” means any instruction that causes data to be read from a location in memory.

[0033] When a read-after-write hazard condition is detected, the hazard detection circuit may be configured to perform a hazard resolution action by suppressing at least one first attempt by the processing pipeline to read data from a given address. This can prevent subsequent memory access instructions from reading data at a given address until the delegated task has progressed to the point where the extended processing circuit has written the correct value to the given address. Subsequent attempts by the processing pipeline to read data from a given address may be permitted at the point where it is determined that the read-after-write hazard no longer exists. In some examples, a simple way to perform this check may be to allow subsequent attempts only when the delegated task is complete. However, this risks unnecessarily delaying read instructions (and subsequent dependent instructions).

[0034] This is because, after the extension processing circuit has written to a given address and removed the data hazard, it is no longer necessary to prevent attempts to read from that address. Therefore, in some examples, a subsequent attempt by the processing pipeline to read data from a given address may be permitted in response to the write progress indicator determining that the given address is the address to which data was written by the extension processing circuit during the execution of the delegated task.

[0035] Nevertheless, delaying a read instruction until a given address has been written by an extension processing circuit (essentially stalling the processing pipeline) can still impact performance. Generally, there is little that can be done about this delay, as it is typically necessary to wait for the data to be generated by a delegated task before it can be read. However, the inventors have identified cases where this performance degradation can be mitigated. In particular, the memcpy function involves moving data from a first region of memory to a second region of memory, and therefore, if the delegated task is memcpy and the data to be read is in the destination buffer of memcpy, this data actually already exists in memory, even though it is in the wrong location (source buffer). Instead of waiting for the delegated task to advance to the point where the relevant data has been moved from the source buffer to the destination buffer before performing the subsequent read, the read can be translated so that a given address (the destination buffer of the memcpy function in the write group) is translated to the corresponding address in the source buffer at the location where it will be copied to the given address. Subsequently, a read request may be issued to access the data from the corresponding address in the source buffer of the memcpy function, and thus data hazards can be resolved without waiting for delegated tasks, and the pipeline does not need to be stalled. This technique is not limited to memcpy, of course, but can be used in general when data is moved from one location in memory to another, and a read from the destination location can be translated into a read from the source location (for example, delegated tasks could be copying data from one location to many locations, transposing matrices, copying strings, network packet processing, etc.).

[0036] A hazard detection circuit may be configured to detect a write-after-write hazard condition in response to a determination that a given memory access instruction is intended to write data to a given address at a location within a write group indicated by a write progress indicator as an address where data has not yet been written by the extension processing circuit. When a memory access instruction that is later in the program order than an extension start instruction writes to a location that is the destination location of a delegated task, the correct operation sequence includes the delegated task writing to that location before a subsequent write instruction writes to that location. Instead, a write-after-write hazard occurs when a subsequent write is attempted before the delegated task writes to a given memory address. The delegated task, which is earlier in the program order, risks overwriting data written by the write instruction of the later program order. It should be understood that "write instruction" means any instruction that causes data to be written to memory.

[0037] An approach to handling write-after-write hazard conditions is to stall the pipeline until the delegated task is complete. However, this may not be necessary to address write-after-write hazards, since subsequent writes (unlike reads) do not directly depend on the delegated task's writes. In other words, a data processing pipeline does not require data to have been written to a given address by a delegated task before it can perform its own write; therefore, instead of stalling the pipeline, it may be more efficient to allow subsequent memory access instructions (and thus any subsequent instructions) to proceed with their writes, and then prevent the delegated task from overwriting data written with old data.

[0038] Therefore, the hazard detection circuit may perform a hazard resolution action in response to the detection of a light-after-light hazard by storing an instruction for a given address in a write address memory element associated with the extension processing circuit, and enabling the execution of a given memory access instruction to write data to the given address. Then, in response to the decision that the extension processing circuit will perform a delegated write memory access while a delegation task is being performed to the address indicated in the write address memory element, the extension processing circuit is configured to prevent the delegated write memory access from being performed. Thus, the write address memory element essentially tracks addresses to which data has already been written in response to an instruction following the extension start instruction in program order, and indicates addresses to which the delegation task should not attempt to overwrite with old data.

[0039] Write address memory elements can take various forms, but in one exemplary implementation, they may be entries in a write address buffer provided within the extension processing circuit. By providing write addresses in the buffer, the extension processing circuit can quickly determine whether an outgoing write request is for an address indicated in the write address memory element, and therefore, if necessary, prevent those write requests from occurring, while reducing the delay for those writes (which can cause delays for reading from the address being written). However, the write address buffer may have a limited number of entries. When the write address buffer is full, the hazard resolution action may revert to stalling the pipeline, which impacts performance. Therefore, it is desirable to evict entries from the write address memory buffer when they are no longer needed. In particular, this can be determined when the write progress indicator is updated to indicate that the address associated with a given entry in the write address memory buffer is an address to which data has been written (or at least attempted to be written) by the extension processing circuit during the execution of the delegated task (and therefore may not be written again, meaning it is unnecessary to retain the address indication). Therefore, the extension processing circuit may be configured to invalidate the write address memory element (e.g., a buffer entry) when it is detected that the entry is no longer needed. One exemplary technique is to invalidate an entry in response to an entry used to prevent a delegated write from being performed (indicating that the entry has completed its job and is no longer needed).

[0040] In some examples, the hazard detection circuit is configured to access a state that defines a group of read addresses from which the extension processing circuit is expected to read data during the execution of a delegated task. The hazard detection circuit may also access a read progress indicator that shows a subset of read addresses within a read group from which data has been read by the extension processing circuit during the execution of a delegated task, as described above. Accessing a read group of memory addresses (and a read progress indicator for filtering such read groups) can be useful in identifying write-after-read data hazards, as described below.

[0041] A hazard detection circuit may be configured to detect a write-after-read hazard condition in response to a determination that a given memory access instruction is intended to write data to a given address at a location within a read group indicated by a read progress indicator as an address from which data has not yet been read by the extension processing circuit. When a memory access instruction that is later in program order than an extension start instruction writes to a location that is the source location of a delegated task, the correct sequence of operations includes the delegated task reading from that location before a subsequent write instruction writes to that location. A write-after-read hazard occurs instead when a subsequent write is attempted before the delegated task reads from a given memory address. If this can be done normally, the extension processing circuit will read data that has been written in response to a later instruction in program order, thus reading incorrect data for the delegated task, which should not have been written at the time of the delegated task's read.

[0042] An approach to handling write-after-read hazard conditions is to stall the pipeline until the delegated task is complete. However, this may not be necessary to handle write-after-read hazards, as subsequent writes (similar to write-after-write hazards) do not directly depend on the delegated task's read. In other words, a data processing pipeline does not require data to have been read from a given address by a delegated task before it performs its own write, and therefore, instead of stalling the pipeline, it may be more efficient to allow subsequent memory access instructions (and thus any subsequent instructions) to proceed with their writes. To enable this while allowing extension processing circuits to read the correct data, some examples may provide a read-data memory element that can store "old" read data (before it is updated in response to a subsequent write instruction) so that it can be read by the extension processing circuit, while also storing "new" data whose location in memory is updated in response to a later write instruction so that it can be accessed by any subsequent instruction.

[0043] Therefore, in some examples, in response to the detection of a write-after-read hazard condition, the hazard detection circuit may be configured to perform a hazard resolution action by causing a copy of the read data from a given address in memory to be stored in a read data storage element associated with the extension processing circuit, and then allowing the execution of a given memory access instruction to proceed to write the write data to the given address. A delegated read memory access performed by the extension processing circuit during the execution of a delegated task may be performed by the extension processing circuit accessing the read data storage element rather than the address in memory, in response to the determination that the read data is for an address stored in the read data storage element.

[0044] Similar to write address memory elements, read data memory elements may be entries in a read data buffer associated with an extension processing circuit. Providing read data to a location such as a buffer that is quickly accessed by the extension processing circuit means means that delays in processing delegated tasks associated with checking and / or accessing data from the read data buffer can be reduced. It is desirable to evict entries from the read data memory buffer when the entries are no longer needed. In particular, this can be determined when a read progress indicator is updated to indicate that the address associated with a given entry in the read data memory buffer is an address where data has been read (or at least attempted to be read) by the extension processing circuit during the execution of a delegated task (and therefore may not be read again, meaning it is unnecessary to retain a copy of the old read data). The extension processing circuit may be configured to invalidate a read data memory element (e.g., a buffer entry) when it is detected that the entry is no longer needed. One exemplary technique is to invalidate an entry in response to an entry used to provide read data for a delegated read performed by the extension processing circuit (indicating that the entry has completed its job and is no longer needed).

[0045] The ways in which a processing pipeline may enter an extended hazard check state with respect to a delegated task have been described above. Similarly, a processing pipeline may exit an extended hazard check state with respect to a delegated task. For example, when an extended hazard check state is exited, the hazard detection circuit may disable the state that defines the expected access and stop checking whether the address of a subsequent memory access is for accessing data from an address that the extended processing circuit is expected to access. In one exemplary implementation, this may be done in response to an explicit extended hazard check exit instruction. However, in a manner similar to how entering a hazard check state may be associated with initiating a delegated task, a processing pipeline may be configured to exit an extended hazard check state with respect to a particular delegated task in response to the completion of that delegated task. The completion of a delegated task can be determined in several ways. For example, a “complete” signal may be asserted when the delegated task is completed. Alternatively, an instruction may be executed to return a value depending on whether the delegated task is complete. Furthermore, if read and / or write progress indicators are provided, the delegated task may be determined to be complete when the progress indicators show that all addresses expected to be accessed have actually been accessed by the delegated task.

[0046] In some cases, the assumption that a delegated task exclusively reads and writes to a certain predefined group of memory addresses, such as source and destination buffers, may not hold true. In these cases, the techniques described above can still be used, but they can be supplemented by capturing read and write sets for data access outside the expected group of addresses.

[0047] If read and write sets can still be captured to some extent, remembering the large amount of state required to track memory access can become cumbersome. Similarly, in the above example where read data can be stored in a read data memory element in response to the detection of a write-after-read hazard, and / or write addresses can be stored in a write address memory element in response to a write-after-write hazard, the amount of state maintained in those elements can become very large. In general, the amount of memory required to store state for hazard checking may exceed a certain fixed threshold. In these cases, the pipeline may be stalled until the necessary space becomes available (for example, by disabling memory elements when a progress indicator is updated). In some situations, these stalls can become frequent and detrimental to performance.

[0048] Therefore, the inventors recognized that there is a range of additional instructions that can be used by programmers to reduce the burden on hazard detection hardware by indicating areas of code where some hazard checks can be relaxed. This can reduce the amount of state that can be tracked and reduce the possibility of pipeline installation. This stems from the observation that while it is difficult to determine the exact producer-consumer relationships in the code (and therefore, as mentioned above, not to rely on the programmer to prevent all data hazards), programmers can nevertheless find pockets of irrelevant functions if they can be confident that hazard checks are not required.

[0049] The decoder circuit may generate a control signal to selectively modify the operation of the hazard detection circuit in response to an extended hazard check relaxation instruction, with respect to determining the presence of a hazard condition for at least one type of memory access instruction following an extended start instruction in the program sequence.

[0050] The first encoding of an extended hazard check mitigation instruction may cause a hazard detection circuit to disable hazard checking for at least one type of memory access. The first encoding of an instruction may be identified based on a unique opcode that identifies the instruction as the first encoding of an extended hazard check mitigation instruction. Alternatively, parameters specified by a more general extended hazard check mitigation instruction may identify the instruction as the first encoding of that instruction (there may be a second encoding that similarly identifies the instruction, as described below).

[0051] Different variations of the first coding of the relaxation instruction may allow programmers to have greater control over the disabling of hazard checking by disabling hazard checking for reads only, writes only, or both reads and writes. For example, there may be areas of code where the programmer is confident that reads will not encounter data hazards, but writes may, and therefore hazard checking may be disabled for reads only (and vice versa).

[0052] A second encoding of the extended hazard check relaxation instruction may enable hazard checking for at least one type of memory access in the hazard detection circuit. This may include re-enabling hazard checking that was previously disabled by the relaxation instruction having the first encoding, or enabling hazard checking that was never enabled in the initial stage (for example, if the hazard check state was entered with respect to only one type of memory access). Similar to the first encoding of the relaxation instruction, variations of the second encoding may increase the level of control by enabling read-only, write-only, or both hazard checking.

[0053] Here, we will explain a specific example with reference to a diagram.

[0054] Figure 1 schematically illustrates a data processing device 10 in several examples. The data processing device 10 is schematically shown to have a pipeline configuration, and for the sake of brevity and clarity, it is schematically shown here. The illustrated pipeline stages include an instruction cache 11, a fetch stage 12, a decode stage 13, a micro-op cache 14, an issue stage 15, and a register access stage 16. A sequence of instructions is retrieved from memory (not shown) and cached in the instruction cache 11. The fetch stage 12 controls which instructions are retrieved as a sequence of instructions, and these instructions are then decoded in the decode stage 13. This decodement essentially identifies the type of each instruction, as well as any further operands specified by the instruction, and generates control signals to control the rest of the device to perform the data processing operations defined by the instruction. Decoded instructions may also involve splitting the instruction into one or more micro-ops, which may be cached in the micro-op cache 14. The final stage of the pipeline before execution is the issue stage 15, where instructions (or micro-ops) are queued, with the availability of the register values ​​they specify as operands and the corresponding functional units of the data processing pipeline that perform the defined operations reserved. Generally, the data processing operations defined by the instructions are executed by functional units that form part of the data processing pipeline, namely the load / store unit 17, the execution unit 18, and the execution unit 19. These latter execution units may be, for example, an arithmetic logic unit (ALU) or a floating-point unit (FPU). The functional units that form part of the data processing pipeline perform their data processing operations on data values ​​provided from a set of registers (conceptually represented by the register access stage 16 in the figure), and the resulting values ​​of these data processing operations are returned to the set of registers. The load / store unit 17 is provided for the purpose of storing values ​​from the set of registers in the memory system, of which only the level 1 cache 21 and the level 2 cache 22 are shown in the figure.The L1 cache 21 is dedicated to the data processing unit 10, while the L2 cache 22 may be shared with another data processing unit if it is part of a broader data processing system. The data processing unit 10 is also shown to include a branching unit 20, which monitors the execution flow of a sequence of instructions and attempts to predict, based on previous execution history, whether a given branch will occur. The prediction from the branching unit 20 informs the sequence of instructions to be fetched by the fetching stage 12.

[0055] The data processing unit 10 further comprises an extension processing circuit 23 provided to support the efficient execution of one or more defined functions that are influential on the data processing operations performed by the data processing unit 10 and established to be ubiquitous. Exemplary functions of this type are known to include tasks or functions such as memcpy, memset, compression, encryption, and string processing, but the technique is not limited to these specific examples. The extension processing circuit is closely associated with the data processing pipeline and configured to execute defined functions (also referred to herein as delegated tasks) in response to delegate signals received from the data processing pipeline. The extension processing circuit 23 is an example of a threadlet extension (TE) according to the technique. A sequence of operations performed to execute a defined function is referred to herein as a threadlet. The extension processing circuit 23 is closely associated with the data processing pipeline but is configured to execute delegated tasks asynchronously with respect to the data processing operations performed by the data processing pipeline. The data processing pipeline is sometimes referred to herein as the CPU. A threadlet is a set of functions or operations that, once invoked, can be executed asynchronously with respect to other CPU activity. The instruction or command sent to the extension processing circuit 23 to initiate a delegated task is generated in response to an extension start instruction defined for this purpose in the instruction set of the data processing pipeline. Thus, the extension start instruction proceeds along the data processing pipeline as any other CPU instruction does, but once the decoding circuit 13 identifies the extension start instruction, it can signal directly to the extension processing circuit 23. The close integration of the extension processing circuit 23 with the data processing pipeline is demonstrated by the fact that the extension processing circuit 23 has direct access to the load / store unit 17 and therefore shares the data processing pipeline's path to memory. The extension processing circuit 23 can also access a set of registers 16, for example, an extension start instruction can specify one or more registers as operands, and the values ​​from these registers are then passed directly to the extension processing circuit 23 in connection with the command sent to initiate the delegated task.Once the task is complete, the result of the delegated task can be returned to a register value via an extended synchronization instruction.

[0056] Figure 2 schematically shows a data processing unit 30 in several examples. Note that the arrangement of the components of the data processing unit 30 is similar to the arrangement of the components of the data processing unit 10 shown in Figure 1. One difference is that the data processing unit 10 in Figure 1 is intended to represent an in-order processor, while the data processing unit 30 is an out-of-order processor. As one consequence of this, the data processing pipeline of the data processing unit 30 includes a rename stage 35 that allows the data processing unit 30 to change the order in which it executes instructions in an instruction sequence, so that the instructions in the instruction sequence may be executed in an order determined not by the order in which they appear in the sequence, but by when their operands become available and the availability of functional units. The illustrated pipeline stages include an instruction cache 31, a fetch stage 32, a decode stage 33, a micro-op cache 34, a rename stage 35, an issue stage 36, and a register access stage 37. The instruction sequence is retrieved from memory (not shown) and cached in the instruction cache 31. Instructions pass through the data processing pipeline in the manner described above, with reference to the data processing unit 10 in Figure 1, and further register renaming is performed by the rename stage 35. The functional units of the data processing pipeline in this example are the load unit 38, the store unit 39, the FPU 41, the integer ALU 42, and the vector unit 43. The throughput of the FPU 41, the integer ALU 42, and the vector unit 43 is sufficient so that the result cache 44 acts as an intermediary before the results of their data processing are returned to the register 37. A branch prediction unit 45 is also provided, whose predictions inform the operation of the fetch stage 32.

[0057] The data processing unit 30 further comprises an extension processing circuit ("threadlet extension") 49 provided to support the efficient execution of one or more defined functions that are influential on the data processing operations performed by the data processing unit 30 and established to be ubiquitous. The extension processing circuit 49 is closely associated with the data processing pipeline and is configured to execute defined functions in response to delegation signals received from the data processing pipeline. In the example in Figure 2, this delegation signal is shown to originate from the issue queue stage 36. In particular, this is after the rename stage 35, so that the extension processing circuit 49 can operate with respect to the physical registers of the set of registers 37 according to the same mapping of architectural registers used for the rest of the device. As in the example in Figure 1, the data processing pipeline (from the instruction cache 31 to the register read stage 37, load / store units 38 and 39, and function units 41-45) is sometimes referred to as the CPU. Once activated, the threadlet extension 49 operates asynchronously with respect to other CPU activity. The instruction or command sent to the extension processing circuit 49 to initiate a delegated task is generated in response to an extended start instruction defined for this purpose in the instruction set of the data processing pipeline. The close integration of the extension processing circuit 49 with the data processing pipeline is also evident in this example, by the fact that the extension processing circuit 49 has direct access to the load unit 38 and the store buffer 40, and therefore shares the data processing pipeline's path to memory. The extension processing circuit 49 can also access a set of registers 37, for example, an extended start instruction can specify one or more registers as operands, and the values ​​from these registers are then passed directly to the extension processing circuit 49 in connection with the command sent to initiate the delegated task. The output of the branch prediction unit 45 is also supplied to the extension processing circuit 49. Once the task is complete, the result of the delegated task can be returned to the register values ​​via an extended synchronization instruction.

[0058] Figure 3 schematically illustrates a data processing unit 50 in several examples. This example provides a comparison with the examples in Figures 1 and 2, where the extension processing circuit is tightly integrated into the data processing pipeline, to the extent that its instances can be considered to reside within the CPU. In the exemplary device 50 of Figure 3, the CPU 51 and the extension processing circuit (threadlet extension) 52 are not so tightly integrated. This is shown, for example, by the fact that each has its own path to memory, the L1 cache 53 is dedicated to the CPU 51, and the L1 cache 54 is dedicated to the threadlet extension 52. They share the L2 cache 55. Nevertheless, the threadlet extension 52 remains tightly coupled to the CPU 51 and can be quickly invoked when an extension start instruction specifying the function that this threadlet extension 52 performs is encountered in the CPU pipeline. The threadlet extension 52 can obtain data directly from CPU registers at the start of its execution. Upon completion, it can return values ​​via an extension synchronization instruction. Figure 3 also shows the threadlet extension 52 having its own dedicated TLB 56, within which the currently used address translation can be cached. As a preparatory step prior to or related to the delegation signal, the contents of the TLB 57 in the CPU 51 can be copied to the dedicated TLB 56 to pre-warm up this cache before the threadlet starts operating.

[0059] Figure 4 is a state diagram showing an exemplary set of states to which an Extension Processing Circuit (TE) transitions in several examples. Initially, the TE is in the IDLE state 60. When an Extension Start (XSTART) instruction is encountered by the data processing pipeline, a delegation signal can cause the TE to switch to the SETUP state 61. This may also require a signal to be asserted indicating that the XSTART instruction has been committed. In the SETUP state 61, certain actions necessary to prepare the TE can be performed. For example, in an example where the TE has a separate path to memory (as in Figure 3), one setup task is to transfer the relevant entries currently in the CPU's TLB to a dedicated TLB in the TE. This allows the TE to perform translations independently at a faster speed than if it were entirely dependent on the existing translation mechanism in the CPU. If the TE was in a clock-gated or power-gated state while in the IDLE state 60, the SETUP state 61 may also include a task to terminate the TE from that clock-gated or power-gated state. Once the SETUP state 61 is complete, the TE can switch to the RUNNING state 62. If a TE encounters a memory failure during its processing, the TE asserts a signal that causes an interrupt in the CPU, causing the CPU to stop execution of the main thread and switch to a handler. The TE switches to the INTERRUPTED state 63. An indication of the fault source is placed in a special syndrome system register, the address associated with the fault is stored in the fault address system register, and a bit in the program status register (PSR) is set so that the handler can quickly determine the fault source. Setting the bit in the PSR simplifies communication of threadlet resumption because the handler can reset the corresponding bit in the SPSR, and if the CPSR is restored from the SPSR during an exception return, the TE can detect this bit reset and resume execution. The TE also switches to the INTERRUPTED state 63 if the main thread is switched out, for example during a context switch initiated by the operating system.In the INTERRUPTED state 63, the TE may be clock-gated or power-gated unless another thread invokes a new command directed at it, the associated thread resumes execution, or the handler returns. The TE returns from the INTERRUPTED state 63 to the RUNNING state 62 via the RELOAD state 64, in which it can restore any context or state related to its execution that was previously stored in memory. This is the case if another thread has used the previously interrupted TE. Finally, when the extension reaches the end of the granule (delegated task) of the offloaded computation, it moves to the IDLE state 60. The TE signals the completion of its task, allowing the Extended Synchronization Instruction (XSYNC) to pick up its "complete" signal and, if necessary, provide return values ​​to the specified registers. If the TE has residual data in its dedicated cache, these entries may need to be flushed upon completion.

[0060] An example of using threadlets is described here. The programmer or compiler identifies functions whose execution on custom hardware (extension processing circuits) satisfies the cost-benefit threshold for those use cases. An instruction (such as XSTART) is used to invoke the command within the specified CPU extension. A pseudocode example of its use (for such an identified function "funcX") is as follows: funcA (){ ... XSTART {x0 - x3},#imm_op / / funcX(a,b,c,d); I1 I2 I3 I4 ... XSYNC x0,#imm_op ... }

[0061] Therefore, within the function funcA, the XSTART instruction initializes the CPU extension and transfers the parameters (a, b, c, d) of funcX, located in registers x0, x1, x2, and x3 respectively, to the extension processing circuit. In this example, the XSTART instruction also specifies an immediate value #imm_op that defines the specific function to be executed. For example, there may be only one instance of the extension processing circuit, but it may be capable of executing two or more functions, or at least two or more variations of a function, and the immediate value #imm_op can select the desired variation and / or function. In other examples, there may be two or more instances of the extension processing circuit, and the immediate value #imm_op can select among them. Depending on the configuration, the extension may also automatically obtain a copy of the relevant entry in the TLB. The extension processing circuit then executes the required task (funcX), during which the CPU can continue executing other instructions I1, I2, I3, I4, etc. At some point in the future, the CPU executes an extension synchronization instruction (XSYNC) to automatically check whether the extension is complete. Otherwise, for some variations of the extended synchronization instruction, the CPU waits for the delegated task to complete. Other variations of the extended synchronization instruction (e.g., the XSYNCS variation) allow the CPU to continue executing other code (if there is an alternative routine available) or to stop execution and wait for the extension to complete (usually if there is nothing else to execute in the meantime). There are various variations of XSTART and XSYNC proposed herein, which will be described in more detail with reference to the following figures.

[0062] Figure 5 schematically illustrates an extended start instruction that delegates a task to an extended processing circuit, according to several examples. Here, the XSTART instruction takes the form XSTART {x0 - x7},#imm. Therefore, when the XSTART instruction 100 in this form is decoded by the CPU's decoder 101, it retrieves the contents of registers x0 to x7 from register 102 and passes them to the extended processing circuit 103. In this case, the extended processing circuit 103 can perform multiple types of operations (tasks), and the immediate value #imm (or a signal based on the immediate value #imm) selects one of these.

[0063] Figure 6 schematically illustrates an extension start instruction that delegates a task to one of several instances of an extension processing circuit, according to several examples. Here, the XSTART instruction also takes the form XSTART {x0 - x7},#imm. However, in this example, there are multiple instances of the extension processing circuit, and the immediate value #imm is used to select among them. Thus, when the XSTART instruction 105 in this form is decoded by the CPU's decoder 106, it causes the contents of registers x0 to x7 to be retrieved from register 102. The extension control circuit 108 instructs the selected extension processing circuit 110 to use the register values ​​based on the immediate value #imm (or a signal based on the immediate value #imm). In this case, the other instances of extension processing circuits 109 and 111 are not activated by this instruction.

[0064] Figure 7 schematically shows a data processing device 50, as shown in Figure 3, which includes a circuit related to hazard detection. In particular, a hazard detection circuit (also called a collision detection and resolution (CDR) circuit) 58, a read data storage buffer 590, and a write address storage buffer 591 are shown. It will be understood that such a circuit is not limited to the example in Figure 3, and similar circuits may be provided, for example, in the examples in Figures 1 and 2.

[0065] The inclusion of CDR 58 allows the CPU 51 (or, in more tightly coupled examples, the processing pipeline) to execute the code following the extended start instruction in program order while the TE 52 is executing the threadlet, even if that subsequent code may include memory access to addresses also accessed by the threadlet. In a typical approach where memory access is expected to occur according to program order, memory access associated with a threadlet is expected to occur before any memory access associated with subsequent instructions. However, because the TE 52 executes the threadlet asynchronously with respect to the CPU 51, the actual point at which a particular memory access is performed by the TE 52 can be difficult to predict and may vary between different instances executing the same code, and in any case, may occur after the subsequent instructions have been executed. In addition to writing code to prevent subsequent memory accesses from being performed until the threadlet has terminated, an approach to address potential data hazards could be to track the set of writes and reads performed by TE 52 and CPU 51 while the threadlet is running, and compare the read and write sets to identify data hazards (data accesses performed to the same address out of program order). However, this may require a large amount of state storage, which is undesirable due to hardware requirements for storage and the latency added to context switching, and does not scale well for large threadlets. The inventors have observed that tasks delegated as threadlets may have data access patterns that allow the use of lower overhead hazard detection schemes, because the addresses that a particular threadlet will access can often be predicted in advance. For example, when a task with well-defined source and destination buffers, such as memcpy, is delegated as a threadlet, it can be expected that the threadlet will access the function's source and destination buffers.CDR 58 can leverage expected access by identifying potential data hazards based on whether the instruction following the extended start instruction in program order requires a memory access to an address within a group of addresses that are expected to be accessed by the threadlet. Otherwise, subsequent memory access may be permitted to proceed on the basis that the threadlet does not access the address, and therefore no data hazard occurs (regardless of when TE 52 actually performs the memory access).

[0066] Furthermore, a threadlet can also access addresses within a channel, and each address is accessed in a clearly defined order. For example, a task can perform some operation on each address in a region of memory, and thus access that region by reading a first address, performing an operation, reading a second address, performing an operation, and so on. Thus, it can be inferred that once an address has been accessed a certain number of times, such an address will not be accessed again, and therefore the set of addresses that are expected to be accessed by a threadlet can be filtered based on some indication of the threadlet's progress. Thus, the TE 52 can maintain one or more progress indicators indicating which of the expected addresses have actually been accessed and which addresses are still expected to be accessed, and the CDR 58 can access one or more progress indicators. The threadlet extension 52 may include an internal cache that can be used to buffer writes resulting from the execution stream within the TE (typically used to store values ​​that need to be reused or duplicated), allowing the order to be restored before any writes are made visible outside the TE, and allowing the TE to externally conform to channel semantics even if this is not always the case internally.

[0067] In at least one example, CPU 51, in response to decoding a hazard-checking variant of the extended start instruction (XSTARTN), causes TE 52 to start a threadlet and causes the CPU to enter a hazard-checking state for that threadlet. Although not illustrated, both blocking and non-blocking variants of the XSTARTN instruction may exist that either prevent or allow further execution of subsequent instructions if TE is unable to start a threadlet in response to the XSTARTN instruction. The XSTARTN instruction specifies a register that identifies a group of addresses that are expected to be accessed by the threadlet (in addition to, or as part of, information identifying the delegated task). CDR 58 can calculate a range based on the data stored in the specified register and store the range information in local storage for use in hazard checking. When CPU 51 executes an instruction after the XSTARTN instruction in program order, CDR 58 can determine whether the instruction is for memory access to an address within the group of addresses that are expected to be accessed by the threadlet, and if so, this may indicate a potential data hazard. When CDR 58 identifies a potential hazard, TE 52 can use one or more progress indicators to identify how far along the delegated task is, allowing it to filter cases where the hazard does not actually occur because the threadlet has already accessed the address in question. An example is shown below.

[0068] One exemplary coding of the XSTARTN instruction has the following coding: XSTARTN x0,x1,x2,#imm, here: x0 identifies the register location containing a pointer to a region of memory defined as the destination buffer for the threadlet. x1 identifies the register location containing a pointer to the memory region defined as the threadlet's source buffer. x2 identifies the register location containing parameters that define the sizes of the source buffer and destination buffer. #imm is an immediate value that provides a threadlet identifier.

[0069] It should be understood that this is merely an example that does not limit the technique. For example, further parameters may identify a second size parameter, where the source buffer and destination buffer have different sizes. Also, the relative order of registers may differ in different instances of the instruction. Registers can provide information, for example, indicating which register stores which information item. Furthermore, certain parameters may be provided as immediate values ​​in the instruction encoding, rather than being provided within registers. In some examples, the read and write groups may not be ranges at all, and different information may be provided to identify which address is expected to be the source address of the threadlet and which address is expected to be the destination address.

[0070] In either case, in this example, CDR 58 can calculate the range of addresses that the threadlet is expected to read from and the range of addresses that the threadlet is expected to write to as follows: read range = {x1, x1+x2}, write range = {x0, x0+x2}.

[0071] Figure 8 is a flowchart illustrating an example of the execution of the XSTARTN instruction. In step 800, the CPU 51 executes the XSTARTN instruction. In step 802, in response to the XSTARTN instruction, the CPU 51 delegates the task to the TE 52 and provides the TE 52 with information identifying the task, as in the example above. As part of this information, grouped address instruction data is made available to the CDR 58, which in step 54 retrieves this information and calculates groups of read addresses and write addresses (read ranges and write ranges, etc.) that are expected to be read from or written to the TE 52 when executing the delegated task. Furthermore, in response to the XSTARTN instruction, in step 806, the device 50 enters a hazard check state, which means that in step 808, the CDR 58 begins to detect and process data hazards between the delegated task started in step 802 and the memory access instructions that follow XSTARTN in program order. While the threadlet is running, CDR 58 monitors the reads and writes issued by TE 52 and uses the monitored memory accesses to update the read and write progress indicators, which show which addresses were accessed during the threadlet's execution.

[0072] In step 810, it is determined whether the delegated task has completed execution on TE 52. This may include checking a progress indicator that can indicate that all expected reads and writes have been performed, and therefore the threadlet has completed. Alternatively, this determination may be based on signals asserted by the threadlet, or the execution of an instruction such as XSYNC to determine whether the threadlet has completed. If not, CDR 58 continues hazard checking and processing. If the threadlet has completed, in step 812, the device exits the extended hazard checking state for the threadlet started in step 802. However, the device may still remain in a hazard checking state with respect to other threadlets.

[0073] The checks and actions performed by CDR 58 in step 808 are shown in detail in Figures 9 and 10, which are flowcharts illustrating the process of checking for write and read-related hazards that appear after the XSTARTN instruction in program order.

[0074] In step 900 of Figure 9, the decoder (or CPU 51) of the processing pipeline encounters a write instruction that appears in program order after the XSTARTN instruction while it is in a hazard check state with respect to the delegated task started by the XSTARTN instruction. In step 902, it is checked whether hazard checking has been disabled for the write to the delegated task despite being in a hazard check state (this may occur, for example, in response to the XSYNCN instruction, as described below). If so, hazard checking is not performed for the write instruction, and the process proceeds to step 904, where the write is permitted to proceed.

[0075] However, if hazard checking is not disabled, in step 906, while hazard checking is being performed, the data associated with the write instruction is temporarily stored in the processing pipeline's store buffer.

[0076] In step 908, it is determined whether the write instruction is for performing a write to an address that falls within a group of addresses from which the threadlet is expected to read data, such as a source buffer, as indicated by the read group address instruction data. The group of addresses may, in some examples, be a range of consecutive addresses, but this is not required. If it is determined that the write address falls within a group of addresses from which the threadlet is expected to access, in step 910 it is determined whether a hazard is still possible because the write address has already been read by the threadlet, as indicated by the read progress indicator. If the read progress indicator is a pointer to a single address (assuming addresses are accessed sequentially), this may involve a comparison between the write address and the progress indicator to determine whether the progress indicator has advanced "before" the write address. If the write address has already been read by the threadlet, writing to that location does not affect what data the threadlet reads, and therefore the write can proceed. This is an example of a read progress indicator used to filter out a set of memory accesses that initially appear to indicate a data hazard because the write address is within the range of expected access by the threadlet, but in reality no longer indicate a hazard once the threadlet has progressed past a certain point in its processing. Due to the asynchronous nature of threadlets, it is not possible to know in advance how far the threadlet will be at a given point in its processing, and therefore, a progress indicator can be used to determine whether a data hazard exists.

[0077] In step 910, a write-after-read (WAR) hazard is identified if the write address is determined to be an address from which the threadlet has not yet read data. A write to the write address at this point could cause the threadlet to read incorrect data (data generated by a write instruction that occurred after the XSTARTN instruction in the program sequence) when it eventually performs that read (which, as far as the program is concerned, should be done by the XSTARTN instruction). However, preventing the write could stall all subsequent instructions that depend on that written data, potentially impacting performance. Therefore, in step 912, the data in memory at the write address that the threadlet has not yet accessed is stored in the read data buffer 590 associated with TE 52. In step 914, the write is permitted to proceed, overwriting the old value in memory. In step 916, future reads by TE 52 to the write address (each associated with a point in the program sequence prior to a subsequent write instruction, and therefore should be accessing the old data) are re-instructed to read the old data stored in the read data storage element 590, rather than the new data in memory. When the read progress indicator is updated to show that the write address is the address where the threadlet has the read data, the read data no longer needs to be stored in the read data storage buffer 590 and can therefore be removed from the read data storage element in step 918 to free up space for additional entries.

[0078] If, in step 908, it is found that the write address does not fall within the group of addresses that are expected to be read by the threadlet, it is also determined whether the write address falls within the group of addresses that are expected to be written to by the threadlet, as indicated by the write group address instruction data. If not, it may be determined that there is no risk of a WAR or write-after-write (WAW) hazard, and therefore, in step 904, the write may be permitted to proceed.

[0079] However, if it turns out that the write address falls within the group of addresses that are first expected to be read by the threadlet, then in step 922, it is determined whether the write progress indicator indicates that the threadlet has not yet written to the write address (in the example where the write progress indicator is a pointer to a single address, this could be a determination of whether the write address is before the write progress indicator, due to the write progress indicator being in a region not yet reached). Otherwise, the threadlet may have already written to the write address and therefore is unlikely to access that address again, and therefore unlikely to overwrite the written data with old data from the threadlet. Thus, the write may be allowed to proceed.

[0080] In step 922, a write-after-write hazard is identified if it is determined that the write address is an address that has not yet been written to by a threadlet. If a write instruction is executed at that point, there is a risk that the threadlet (related to the previous XSTARTN instruction) may overwrite the write data related to the subsequent write instruction. However, it is desirable to allow the write to be executed so that subsequent instructions can access the write data in memory. Therefore, in step 924, the instruction for the write address is stored in the write address memory element 591, and in step 926, the write is permitted to proceed. The write address memory element 591 is used to prevent a write executed as part of a threadlet from overwriting newer data written to memory in response to a later write instruction in the program sequence. Therefore, if a write is issued by a threadlet to the address indicated in the write address memory element 591, the write is prevented from being executed. After the write progress indicator has progressed past a specific address (for example, by TE attempting to write to that address), the corresponding write address memory element 591 can be disabled under the assumption that the address will not be accessed again, and the space in the write address memory buffer 591 can be freed.

[0081] Therefore, Figure 9 illustrates the use of grouped address instruction data indicating expected read and write accesses by the threadlet to identify and resolve hazards between the threadlet operation and the data processing operation after the threadlet start instruction in program order, when the data processing operation is executed asynchronously with the threadlet.

[0082] In step 1000 of Figure 10, the decoder (or CPU 51) of the processing pipeline encounters a read instruction that appears in program order after the XSTARTN instruction while in a hazard check state with respect to the delegated task started by the XSTARTN instruction. In step 1002, it is checked whether hazard checking has been disabled for writes related to the delegated task, despite being in a hazard check state (this may occur, for example, in response to an XSYNCN instruction, as described below). If so, hazard checking is not performed for the read instruction, and the process moves to step 1004, where the write is permitted to proceed.

[0083] However, if hazard checking is not disabled, step 1006 determines whether the read instruction is for performing a read from an address that falls within a group of addresses where the threadlet is expected to write data, such as a destination buffer, as indicated by the write group address instruction data. The group of addresses may, in some examples, be a range of contiguous addresses, but this is not required. If it is determined that the read address falls within a group of addresses where the threadlet is expected to access, step 1008 determines whether a hazard is still possible because the read address has already been written by the threadlet, as indicated by the write progress indicator. If the read address has already been written by the threadlet, reading from that location does not deviate from program order, and therefore the write can proceed. This is an example of a write progress indicator used to filter out a set of memory accesses that initially appear to indicate a data hazard because the read address is within the range of expected access by the threadlet, but in reality no longer indicate a hazard once the threadlet has progressed past a certain point in its processing.

[0084] In step 1008, a read-after-write (RAW) hazard is identified if the read address is determined to be an address to which the threadlet has not yet written data. A read from the read address at this point could cause the CPU 51 (or the data processing pipeline) to read incorrect data, because it should instead read data generated by the threadlet (or subsequent instructions). Therefore, in step 1010, the read is prevented from accessing the data at the read address in memory.

[0085] In step 1012, it is determined whether the threadlet is in a special case where the read can be converted. For example, it is determined whether the threadlet is performing a task that moves data from another address in memory (such as memcpy) to the read address. If so, in step 1014, the read to the read address can be converted to a read from another address, and the process can proceed to step 1016.

[0086] However, if this is not the case, it may be necessary to wait for the threadlet to generate the data to be read. Therefore, in step 1018, it can be determined whether the progress indicator indicates that the read address is the address to which the threadlet wrote the data. If this condition is met, in step 1020, the read can proceed to read the data from the read address. After the threadlet has written the data to the memory system, the latest copy of that data may be stored in a cache dedicated to TE 52 (e.g., L1 cache 54). To ensure that the processing pipeline can access this data, the read may be accompanied by a flush to flush the data from L1 cache 54 to a lower shared location in memory, such as L2 cache 55 or main memory. Alternatively, by relying on a coherency protocol, it may be possible to ensure that the read performed in step 1020 accesses the latest version of the data. For example, in response to a snoop request that hits the data in L1 cache 54, the data may be returned to the CPU 51.

[0087] In this way, by using grouped address instruction data that indicates the addresses to which the threadlet is expected to write, RAW hazards can be avoided.

[0088] Figure 11 is a state diagram showing different states of hazard checking for a particular TE and the transitions between those states in response to decoding the XSYNCN instruction, where the XSYNCN instruction is an example of an extended hazard checking relaxation instruction as described above. The use of the XSYNCN instruction allows for the selective enabling or disabling of hazard checking for a particular TE and for a particular type of memory access, resulting in a reduction in the amount of hazard checking storage required when executing areas of code that the programmer is confident will not hazard (after the XSTARTN instruction).

[0089] When hazard checking is disabled for a particular type of memory access, instructions for performing that type of memory access after an extended start instruction in the program sequence will not cause the hazard detection circuit to perform a hazard check. The hazard detection circuit will not compare the address to be accessed with a range of memory addresses that are expected to be accessed during a delegated task, for example, even if the data processing pipeline is in an extended hazard checking state for a delegated task. This can reduce the delay associated with hazard checking and can also provide power savings.

[0090] An example of the XSYNCN instruction has the following encoding: XSYNCN <imm1> , <imm2> , <imm3> Here, the immediate value has the following meaning: imm1: Valid or invalid guarantee that hazard checks are not required - #0 = invalid guarantee, #1 = valid guarantee imm2: Specifies the type of memory access associated with the XSYNCN instruction - #0 = read, #1 = write, #2 = read and write imm3: Identify a specific TE in an example where multiple TEs are supported and hazard checks can be enabled or disabled for each TE.

[0091] However, it should be understood that this is merely an illustrative implementation. In some examples, immediate values ​​may not be used, and instead, parameters may be set in registers (which may or may not be identified by the instruction). Also, while certain immediate values ​​are used here for different meanings, it should be understood that these are freely changeable and can be implemented in several different ways.

[0092] Figure 11 illustrates the use of the XSYNCN instruction in the above example for transitioning between different hazard check states. In state 140, the hazard detection circuit (e.g., the CDR unit) is configured to determine whether a hazard condition exists with respect to reads and writes performed by the data processing pipeline in response to instructions following the extended start instruction in program order. In states 142 and 144, the hazard detection circuit is configured to determine the presence of a hazard condition for reads only and writes only, respectively, and therefore does not need to track specific writes / reads and / or store data in the write address memory element or read data memory element, respectively. Therefore, the amount of stored state is less likely to exceed a threshold, and therefore the pipeline is less likely to stall, which can improve performance in some cases. In state 146, no hazard is detected for either reads or writes, and therefore the amount of state required is further reduced than in states 142 and 144.

[0093] The transition from state 140 to a state where a specific amount of hazard checks are disabled is as shown in Figure 14, XSYNCN #1 <imm2>This can be achieved using commands. XSYNCN #1 <imm2>The order is, <imm2>This ensures that hazard checks are not required for the type of memory access specified by ( <imm3>For clarification regarding the TE specified by (the third field is excluded in this example). The XSYNCN#1 instruction can also be used to transition from a state where one type of hazard checking is disabled to a state where both types are disabled (as shown in the transitions from states 142 and 144 to state 146).

[0094] The guarantee that hazard checks are not required for certain types of memory access can be applied to one or both types of memory access, as shown in the transitions from state 146 to 142 and 144, and from state 142 and 144 to state 140, in XSYNCN#0. <imm2>It can be reversed by using commands.

[0095] Figure 12 shows possible implementations of a simulator. While the embodiments described above implement the present invention in terms of devices and methods for operating specific processing hardware that supports the technology, it is also possible to provide an instruction execution environment according to the embodiments described herein, which are implemented by the use of a computer program. Such a computer program is often referred to as a simulator, insofar as it provides a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 730, optionally running a host operating system 720 and supporting a simulator program 710. In some configurations, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple different instruction execution environments may be provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such techniques may be justified in certain circumstances, such as when it is desirable to run native code on a different processor for reasons of compatibility or reuse. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or it may provide an instruction execution environment typically associated with a different hardware architecture. An overview of the simulation is provided in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990 USENIX Conference, pages 53-63.

[0096] While embodiments have been described so far with reference to specific hardware components or features, in simulated embodiments, equivalent functionality may be provided by suitable software components or features. For example, certain circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in simulated embodiments. In arrangements where one or more of the hardware elements referenced in the embodiments described above reside on host hardware (e.g., host processor 730), some simulated embodiments may utilize the host hardware where appropriate.

[0097] The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-temporary medium) and provides a program interface (instruction execution environment) to target code 700 (which may include an application, operating system, and hypervisor) that is the same as the interface of the hardware architecture modeled by the simulator program 710. Thus, the program instructions of the target code 700 described above, including the XSTARTN and XSYNCN instructions, can be executed from within the instruction execution environment using the simulator program 710, thereby allowing a host computer 730, which does not actually possess the hardware functions of the device 50 described above, to emulate these functions.

[0098] For example, the simulator program 710 may include data processing pipeline program logic 1200 for simulating a data processing pipeline as shown in Figure 1. The simulator program 710 may also include decoder program logic 1202, extension processing program logic 1204, and hazard detection program logic 1206 for simulating the decoder, extension processing circuit 52, and hazard detection circuit 58, respectively.

[0099] The concepts described herein may be embodied in computer-readable code for the fabrication of devices that embody the described concepts. For example, computer-readable code can be used in one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising a device that embodies the concepts. The computer-readable code described herein may additionally or alternatively enable the definition, modeling, simulation, verification, and / or testing of devices that embody the concepts described herein.

[0100] For example, computer-readable code for fabricating a device embodying a concept described herein may be embodyed by code that defines a hardware description language (HDL) representation of the concept. For example, the code may define register-transfer-level (RTL) abstractions of one or more logic circuits for defining a device embodying the concept. The code may define HDL representations of one or more logic circuits embodying the device in Verilog, SystemVerilog, Chisel, or an intermediate representation such as Very High-Speed ​​Integrated Circuit Hardware Description Language (VHDL) and FIRRTL. The computer-readable code may provide definitions that embody the concept using system-level modeling languages ​​such as SystemC and SystemVerilog, or other behavioral representations of the concept that may be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concept.

[0101] Additionally or alternatively, computer-readable code may define low-level descriptions of integrated circuit components that embody the concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. One or more netlists or other computer-readable representations of integrated circuit components may be generated by applying one or more logic synthesis processes to the RTL representations to generate definitions used for fabricating devices that embody the invention. Alternatively or additionally, one or more logic synthesis processes can generate bitstreams from computer-readable code that are loaded into a field-programmable gate array (FPGA) to configure the FPGA to embody the concepts described herein. The FPGA may be deployed for the purpose of verifying and testing the concept before fabrication in an integrated circuit, or the FPGA may be deployed directly into a product.

[0102] Computer-readable code may include a mixture of code representations for the fabrication of a device, for example, a mixture of one or more RTL representations, netlist representations, or other computer-readable definitions used in semiconductor design and fabrication processes for fabricating a device embodying the present invention. Alternatively or additionally, the concept may be defined as a combination of computer-readable definitions used in semiconductor design and fabrication processes for fabricating a device and computer-readable code that defines instructions to be executed by the device once it is fabricated.

[0103] Such computer-readable code may be placed on any known temporary computer-readable medium (such as wired or wireless transmission of code over a network) or on a non-temporary computer-readable medium such as a semiconductor, magnetic disk, or optical disk. Integrated circuits fabricated using computer-readable code may include components such as a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or one or more other components that individually or collectively embody a concept.

[0104] In this application, the phrase "configured to..." is used to mean that an element of the device has a configuration that enables it to perform a defined operation. In this context, "configuration" means the arrangement or interconnection of hardware or software. For example, the device may have dedicated hardware to provide the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that an element of the device must be modified in any way to provide the defined operation.

[0105] In this application, the enumeration of features preceded by the phrase "at least one of ~" means that any one or more of those features can be provided individually or in combination. For example, "[A], [B], and [C]" () includes any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), a combination of A and B (without C), a combination of A and C (without B), a combination of B and C (without A), or a combination of A, B, and C.

[0106] While illustrative embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it will be understood that the present invention is not limited to those exact embodiments, and that various changes and modifications can be made to the embodiments without departing from the scope of the present invention as defined by the appended claims. < / imm2> < / imm1>

Claims

1. A device for data processing, A data processing pipeline comprising a decoder circuit that responds to the reception of instructions for a sequence of instructions for generating control signals to control the data processing pipeline to perform data processing operations, An extension processing circuit associated with the data processing pipeline and configured to asynchronously perform delegated tasks with respect to the data processing operations performed by the data processing pipeline in response to the decoding circuit decoding an extension start instruction, The system includes a hazard detection circuit that detects data hazards associated with processing operations performed by the data processing pipeline when the data processing pipeline is in an extended hazard check state with respect to the delegated task, When the data processing pipeline is in the extended hazard check state with respect to the delegated task, the hazard detection circuit is configured to determine the existence of a hazard condition depending on whether a given memory access performed in response to the execution of a given memory access instruction by the data processing pipeline following the extended start instruction in the program sequence is for accessing an address that falls within a group of addresses indicated by grouped address instruction data. The hazard detection circuit is a device that performs a hazard resolution action in response to the presence of the hazard condition.

2. The decoder circuit, in response to an extended hazard check start command, generates a control signal that commands the processing pipeline to enter the extended hazard check state with respect to the delegated task. The apparatus according to claim 1.

3. The extended hazard check start instruction is the extended start instruction, and the extended processing circuit is configured to execute the delegated task in response to the decoding circuit decoding the extended hazard check start instruction. The apparatus according to claim 2.

4. The extended hazard check start command is configured to specify the grouped address instruction data. The apparatus according to claim 2 or 3.

5. The data processing pipeline includes a set of registers for holding data values ​​on which the data processing operation is performed, The extended hazard check start instruction is configured to specify the grouped address instruction data by identifying at least one register in the set of registers, the contents of the set of registers being used to determine the grouped address instruction data. The apparatus according to claim 4.

6. The grouped address instruction data includes a first parameter and a second parameter, at least one of the first parameter and the second parameter providing an address instruction, and the first parameter and the second parameter are used in combination to determine the starting address and size of an address range. The apparatus according to any one of claims 1 to 5.

7. In the extended hazard check state, the extended processing circuit is configured to maintain a progress indicator showing a subset of addresses accessed by the extended processing circuit during the execution of the delegated task. The hazard detection circuit is configured to detect the hazard condition in accordance with a comparison between the given address and the progress indicator. The apparatus according to any one of claims 1 to 6.

8. In the extended hazard check state, the hazard detection circuit, During the execution of the delegated task, the extension processing circuit defines a write group of memory addresses where it is expected to write data, During the execution of the delegated task, the system is configured to access a write progress indicator that shows a subset of write addresses in the write group to which data has been written by the extended processing circuit. The apparatus according to claim 7.

9. The hazard detection circuit is configured to detect a read-after-write hazard condition in response to a determination that the given memory access instruction is for reading data from the given address at a location within the write group indicated by the write progress indicator as an address where data has not yet been written by the extension processing circuit. The apparatus according to claim 8.

10. In response to the detection of the read-after-write hazard condition, the hazard detection circuit is configured to perform the hazard resolution action by suppressing at least a first attempt by the processing pipeline to read data from the given address. The apparatus according to claim 9.

11. In response to the detection of the read-after-write hazard condition and the determination that the delegated task is for copying data from a first region of memory to the write group, the processing pipeline is configured to translate the given address in the write group to the translated address in the first region of memory at the location where the delegated task will copy to the given address, and to issue a read request to the translated address. The apparatus according to claim 10.

12. The hazard detection circuit is configured to detect a write-after-light hazard condition in response to a determination that the given memory access instruction is for writing data to the given address at a location within the write group indicated by the write progress indicator as an address to which data has not yet been written by the extension processing circuit. The apparatus according to any one of claims 8 to 11.

13. In response to the detection of the light after light hazard condition, the hazard detection circuit is configured to perform the hazard resolution action by causing the instruction for the given address to be stored in a write address memory element associated with the extension processing circuit, and by enabling the execution of the given memory access instruction to write the data to the given address. In response to a decision by the extension processing circuit to perform a delegated write memory access while the delegation task is being performed to the address indicated in the write address memory element, the extension processing circuit is configured to prevent the delegated write memory access from being performed. The apparatus according to claim 12.

14. In response to a determination that the write progress indicator has been updated to indicate that the address associated with the write address memory element is the address to which data was written by the extension processing circuit during the execution of the delegated task, the extension processing circuit is configured to disable the write address memory element. The apparatus according to claim 13.

15. In the extended hazard check state, the hazard detection circuit, During the execution of the delegated task, the state defines a group of memory addresses from which the extension processing circuit is expected to read data, During the execution of the delegated task, the system is configured to access a read progress indicator that shows a subset of read addresses in the read group from which data has been read by the extended processing circuit. The apparatus according to any one of claims 7 to 14.

16. The hazard detection circuit is configured to detect a write-after-read hazard condition in response to a determination that the given memory access instruction is for writing write data to the given address at a location within the read group indicated by the read progress indicator as an address where data has not yet been read by the extension processing circuit. The apparatus according to claim 15.

17. In response to the detection of the write-after-read hazard condition, the hazard detection circuit is configured to perform the hazard resolution action by causing a copy of the read data from the given address in memory to be stored in a read data storage element associated with the extension processing circuit, and then enabling the execution of the given memory access instruction to write the write data to the given address. During the execution of the delegated task, the delegated read memory access performed by the extension processing circuit is configured such that, in response to a determination that the read data is for an address stored in the read data storage element, the extension processing circuit performs the delegated read memory access by accessing the read data storage element instead of the memory. The apparatus according to claim 16.

18. In response to a determination that the read progress indicator has been updated to indicate that the address associated with the read data storage element is the address from which data was read by the extension processing circuit during the execution of the delegated task, the extension processing circuit is configured to disable the read data storage element. The apparatus according to claim 17.

19. The processing pipeline is configured to terminate the extended hazard check state with respect to the delegated task in response to the completion of the delegated task. The apparatus according to any one of claims 1 to 18.

20. The decoder circuit generates a control signal to selectively modify the operation of the hazard detection circuit in response to an extended hazard check relaxation instruction, with respect to determining the presence of the hazard condition for at least one type of memory access instruction following the extended start instruction in the program sequence. The apparatus according to any one of claims 1 to 19.

21. The decoder circuit, in response to the first encoding of the extended hazard check relaxation instruction, generates a control signal to the hazard detection circuit that causes the determination of whether a hazard condition exists for at least one type of memory access instruction following the extended start instruction in the program sequence. The apparatus according to claim 20.

22. The decoder circuit, in response to the second encoding of the extended hazard check relaxation instruction, generates a control signal to the hazard detection circuit that enables the determination of whether a hazard condition exists for at least one type of memory access instruction following the extended start instruction in the program sequence. The apparatus according to claim 20 or 21.

23. A non-temporary computer-readable medium for storing computer-readable codes, for the manufacture of the apparatus according to any one of claims 1 to 22.

24. A method of data processing, The data processing pipeline executes data processing operations according to the instructions in the sequence of instructions decoded by the decoder. In response to the decoding circuit decoding the extension start instruction, the extension processing circuit associated with the data processing pipeline executes a delegated task asynchronously with respect to the data processing operation performed by the data processing pipeline, Using a hazard detection circuit, when the data processing pipeline is in an extended hazard check state with respect to the delegated task, a data hazard associated with the processing operation performed by the data processing pipeline is detected. When the data processing pipeline is in the extended hazard check state with respect to the delegated task, the hazard detection circuit is used to determine the existence of a hazard condition depending on whether a given memory access performed in response to the execution of a given memory access instruction by the data processing pipeline following the extended start instruction in the program sequence is for accessing an address that falls within a group of addresses indicated by grouped address instruction data. In response to the existence of the aforementioned hazard conditions, a hazard resolution action is performed, Methods that include...

25. A computer program for controlling a host data processing device to provide an instruction execution environment, wherein the computer program is The data processing pipeline program logic includes a decoder program logic that responds to the reception of instructions for a sequence of instructions for generating control signals to control the data processing pipeline program logic to perform data processing operations, An extension processing program logic associated with the data processing pipeline program logic and configured to asynchronously execute a delegated task with respect to the data processing operation performed by the data processing pipeline program logic in response to the decoding program logic decoding an extension start instruction, The system includes a hazard detection program logic that detects data hazards associated with processing operations performed by the data processing pipeline program logic when the data processing pipeline program logic is in an extended hazard check state with respect to the delegated task, When the data processing pipeline program logic is in the extended hazard check state with respect to the delegated task, the hazard detection program logic is configured to determine the existence of a hazard condition depending on whether a given memory access performed in response to the execution of a given memory access instruction by the data processing pipeline program logic following the extended start instruction in the program sequence is for accessing an address that falls within a group of addresses indicated by grouped address instruction data. The hazard detection program logic is a computer program that performs a hazard resolution action in response to the presence of the hazard condition.

Images