Intracore parallelization in data processing devices and methods

Abstract

We provide a data processing device. [Solution] The data processing device comprises a multithreaded processing circuit that executes processing operations of multiple microthreads, a thread control circuit that collects runtime data indicating performance metrics related to processing operations, and a decoder circuit that provides a detach control signal to the thread control circuit in response to a detach instruction specifying an address within a first microthread of an instruction executed in a first execution context that defines a first architectural state. When the runtime data satisfies the parallelization criteria, the thread control circuit, in response to the detach control signal, generates a second microthread of instructions that includes a subset of instructions of the first microthread of instructions, which are executed in a second execution context that defines a second architectural state based on the first architectural state and start from an address.

Description

Technical Field

[0001] This disclosure relates to intra-core parallelization of code in a data processing device.

[0002] Parallelization of sequential instructions provides a means to improve the scaling of sequential performance within a data processing device. Typical out-of-order execution used in modern general-purpose CPU processors relies on fine-grained instruction-level parallel processing to transform a sequential instruction stream into a limited dataflow execution model. However, the performance gain is limited within the constraints of the instruction window size of the out-of-order processor. This mechanism cannot identify and utilize opportunities for coarse-grained task-level parallel processing within a sequential instruction scheme. Task-level parallel processing can improve the performance of sequential code. However, task-level parallel processing typically requires programmer intervention to rewrite the code based on extensive profiling of the runtime performance of the code to explicitly expose opportunities for parallel processing. Alternatively, when compiler support exists, code that utilizes task-level parallelization may incur significant overhead compared to optimized sequential code, thereby requiring two different code versions, namely, a code version for use when task-level parallelization is supported and a code version for sequential execution. For these reasons, typical approaches to task-level parallelization that rely on conventional multi-core processors that are highly software-dependent tend to exhibit insufficient performance scaling and insufficient efficiency.

[0003] At least one embodiment of the present disclosure provides a data processing device, the data processing device comprising: a multithreaded processing circuit that performs processing operations of a plurality of microthreads, each microthread operating in a corresponding execution context that defines an architectural state; a thread control circuit that collects runtime data indicating performance metrics related to the processing operations; and a decoder circuit that provides a detach control signal to the thread control circuit in response to a detach instruction in a first microthread of an instruction executed in a first execution context that defines a first architectural state, wherein the detach instruction specifies an address, and when the runtime data satisfies a parallelization criterion, the thread control circuit, in response to the detach control signal, generates a second microthread of an instruction executed in a second execution context that defines a second architectural state based on the first architectural state, the second microthread of an instruction including a subset of instructions of the first microthread of an instruction starting from an address.

[0004] At least one embodiment of the present disclosure provides a data processing method which includes: collecting runtime data indicating performance metrics relating to the processing operations of a plurality of microthreads in corresponding execution contexts defining an architectural state on a multithreaded processing circuit; generating a detach control signal in response to a detach instruction in a first microthread of an instruction executed in a first execution context defining a first architectural state, wherein the detach instruction specifies an address; and, in response to the detach control signal, generating a second microthread of an instruction executed in a second execution context defining a second architectural state based on the first architectural state, provided that the runtime data satisfies a parallelization criterion, wherein the second microthread of the instruction includes a subset of instructions of the first microthread of the instruction, starting from an address.

[0005] At least one embodiment of the present disclosure provides a data processing device, the data processing device includes means for collecting runtime data indicating performance metrics relating to the processing operations of a plurality of microthreads in corresponding execution contexts defining an architectural state on a multithreaded processing circuit; means for generating a detach control signal in response to a detach instruction in a first microthread of instructions executed in a first execution context defining a first architectural state, wherein the detach instruction specifies an address; and means for generating a second microthread of instructions executed in a second execution context defining a second architectural state based on the first architectural state, in response to the detach control signal, provided that the runtime data satisfies a parallelization criterion, wherein the second microthread of instructions includes a subset of instructions of the first microthread of instructions, starting from an address. [Brief explanation of the drawing]

[0006] The technique will be further explained, merely as an example, with reference to the embodiments shown in 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] This section outlines the detailed operation of a thread control circuit that can embody various embodiments of this technique. [Figure 3A] This section outlines the details of epoch identifier assignment, which can embody various embodiments of this technique. [Figure 3B] This section outlines the details of epoch identifier assignment, which can embody various embodiments of this technique. [Figure 4] This section outlines the details of microthreaded execution, which can embody various embodiments of this technique. [Figure 5] This section outlines the details of microthreaded execution, which can embody various embodiments of this technique. [Figure 6] This section outlines the details of microthreaded execution, which can embody various embodiments of this technique. [Figure 7] This section outlines the details of microthreaded execution, which can embody various embodiments of this technique. [Figure 8] This section outlines the details of microthreaded execution, which can embody various embodiments of this technique. [Figure 9] This section outlines the details of microthreaded execution, which can embody various embodiments of this technique. [Figure 10] A series of steps performed by some embodiments of the present invention are schematically shown.

[0007] In at least some embodiments, a data processing device is provided, the data processing device comprising: a multithreaded processing circuit that performs processing operations of multiple microthreads, each microthread operating in a corresponding execution context that defines an architectural state; a thread control circuit that collects runtime data indicating performance metrics related to the processing operations; and a decoder circuit that provides a detach control signal to the thread control circuit in response to a detach instruction in a first microthread of an instruction executed in a first execution context that defines a first architectural state, wherein the detach instruction specifies an address, and when the runtime data satisfies a parallelization criterion, the thread control circuit, in response to the detach control signal, generates a second microthread of an instruction executed in a second execution context that defines a second architectural state based on the first architectural state, the second microthread of an instruction includes a subset of the instructions of the first microthread of an instruction starting from an address.

[0008] The thread control circuit of a multithreaded processing circuit maintains and controls the execution of multiple microthreads, each having its own corresponding execution context. The execution context defines an architectural state that includes several architectural registers, which can be mapped to a corresponding subset of available physical registers, several control and status registers, and a program counter value indicating the position of the currently executing instruction within the execution context. A multithreaded data processing unit may be configured to execute some of multiple microthreads in parallel on multiple parallel pipelines, or, furthermore, may use time interleaving techniques that allow different microthreads to execute sequentially, for example, while one thread is waiting for data to be fetched, a different thread can utilize the data processing unit's resources. The thread control circuit is further configured to collect runtime data indicating performance metrics related to the microthread's processing behavior. In particular, as will be further described below, performance metrics provide indications of whether the currently executing instruction can benefit from parallelism.

[0009] The data processing unit further includes a decoder circuit that can respond to several hint-based instructions for implicit task parallelization. In particular, the decoder circuit responds to a detach instruction that causes the decoder circuit to generate a detach control signal, which is passed to the thread control circuit. The detach instruction is a hint-based instruction that can be inserted by a programmer or compiler, indicating to the data processing unit that a set of instructions in the first microthread of the instruction can benefit from parallel execution. The determination of whether to act on the hint-based instruction is performed at runtime by the thread control circuit based on the detach control signal and performance indicators. For example, the decode circuit may decode the detach instruction when the performance metric indicates that there is no benefit in executing the set of instructions in parallel. In such a situation, the thread control circuit can continue executing the set of instructions sequentially. On the other hand, if the decode circuit decodes the detach instruction and the performance metric indicates that the set of instructions can benefit from parallelization, the thread control circuit may generate a second microthread of the instruction that at least partially inherits its execution context from the first microthread of the instruction. The detach instruction further specifies an instruction address that indicates the starting point of the second microthread of the instruction. In this way, the first microthread of the instruction and the second microthread of the instruction can execute in parallel when performance metrics indicate that such parallelization is beneficial to the execution of the instruction that would have been fully executed by the first microthread of the instruction if the detach instruction had not been present.

[0010] By relying on hint-based techniques, programmers or compilers are expected to be able to insert low-cost hints around sections of code where parallelization might be beneficial. However, it is the microarchitecture's job to determine at runtime whether parallelization across any particular set of hints is beneficial. This, in turn, reduces the compiler's burden by eliminating the need to perform overly complex analysis to assess profitability and the generation of fat binaries containing both parallelized and sequential copies of the same functionality. Programmers or compilers can conveniently insert these hints even when they have low confidence in the profitability of parallelization for a particular area, trusting that the microarchitecture can make a more informed determination at runtime. With hint-based instruction insertion left to the compiler, the compiler has a more manageable job, eliminating the need for programmers to rewrite code to benefit from thread-level speculation. Thus, aggressive compiler analysis or programmer assistance is no longer required when inserting parallelization hints.

[0011] In at least some embodiments, the address is a first address, the instruction subset is a first subset of instructions, the detach instruction further includes a second address, and when runtime data satisfies parallelization criteria, the thread control circuit, in response to the detach control signal, causes a first microthread of instructions to execute a second subset of instructions starting from the second address. In this way, a hint-based detach instruction can be used to execute a first subset of instructions and a second subset of instructions as part of a separate set of microthreads, each executed in its own execution context. The first subset of instructions is defined by a first address included in the detach instruction, and the second subset of instructions is defined by a second address included in the detach instruction. The first and second subsets of instructions can be defined in various ways. Specifically, the first and second subsets of instructions can correspond to different subsets of instructions. For example, if a second subset of instructions occurs sequentially before or after a first set of instructions in a static binary generated by the compiler, and runtime data identifies that these two subsets can be executed in favorably parallel, then a thread control circuit can generate a second execution environment based on the execution environment of a first microthread for executing the second subset of instructions.

[0012] In at least some embodiments, a first subset of instructions and a second subset of instructions are subsets of instructions in a first microthread that do not overlap during dynamic execution. The instructions executed by the first and second microthreads may correspond to the same instructions in the static binary generated by the compiler, but they correspond to instructions that do not overlap during dynamic execution. For example, the first subset of instructions may correspond to the first iteration of a loop defined by a loop index that takes a first value, and the second subset of instructions may correspond to the second iteration of a loop defined by a loop index that takes a second value. In this way, the thread control circuit can decide at runtime whether the loop benefits from parallel execution, and if so, can generate additional microthreads to take advantage of parallel execution.

[0013] In at least some embodiments, when runtime data does not meet the parallelization criteria, the thread control is adapted to interpret the detach instruction as either an unconditional branch instruction or no action. When the thread control interprets the detach instruction as no action, instruction execution moves sequentially to the next instruction. Alternatively, the thread control may treat the detach instruction as an unconditional branch instruction so that program execution continues sequentially from the branch target. In this way, program execution can be configured to continue as if the detach instruction had not occurred, and program execution continues from the instruction that would have occurred if the detach instruction had not been inserted by the compiler or programmer.

[0014] In at least some embodiments, the decoder circuit provides a reattach control signal to the thread control circuit in response to a reattach instruction within a particular microthread of the instruction, and the thread control circuit terminates the particular microthread of the instruction in response to the reattach control signal. In this way, a block of instructions that can benefit from parallelization by being executed as part of a particular microthread of the instruction can be bounded by placing the block of instructions between a detach instruction indicating a point where the particular microthread of the instruction can begin and a reattach instruction indicating a point where the particular microthread of the instruction terminates. The particular microthread in which the reattach instruction occurs is not limited and may be either the first microthread of the instruction or the second microthread of the instruction. If the reattach instruction occurs in the first microthread, execution may continue in the second microthread of the instruction. Alternatively, if the reattach instruction occurs in the second microthread, execution may continue in the first microthread of the instruction.

[0015] In at least some embodiments, the thread control circuit indicates the unsuccessful termination of a particular microthread in response to the occurrence of a data hazard between a particular microthread of an instruction and another microthread of the instruction. Because parallelization is based on a combination of hint-based instructions and instructions from runtime data where parallelization may be beneficial, unexpected data hazards may occur in one or more threads. In particular, when it is identified that parallel execution is beneficial, a particular microthread is running speculatively and can terminate gracefully by executing a reattach instruction, indicating that no memory hazards occurred during execution and that the particular microthread can eventually commit. However, the particular microthread may not terminate gracefully if a potential hazard is detected, such as a memory dependency violation like a read-after-write hazard, or an exception or interrupt event that causes a flush of speculative state (and potentially that of other microthreads associated with the particular microthread). In this way, hazards that occur during the speculative execution of a particular microthread can be avoided.

[0016] In at least some embodiments, the thread control circuit regenerates a specific microthread for an instruction in response to an instruction for unsuccessful termination. Regenerating a specific microthread may require re-executing the detach instruction from a known correct, less speculative, or non-speculative state until it can be determined that the specific microthread has terminated successfully.

[0017] In at least some embodiments, when runtime data does not meet the parallelization criteria, the thread control is adapted to interpret the reattach instruction as either an unconditional branch instruction or a no-action. When the thread control interprets the reattach instruction as a no-action, instruction execution moves sequentially to the next instruction. Alternatively, the thread control may treat the reattach instruction as an unconditional branch instruction so that program execution continues sequentially from the branch target. In this way, program execution can be configured to continue as if the reattach instruction had not occurred, and program execution continues from the instruction that would have occurred if the reattach instruction had not been inserted by the compiler or programmer.

[0018] In at least some embodiments, each microthread is identified by an epoch identifier. The thread control circuit must track the sequential semantics of the original program. Therefore, at any given time, the epoch identifier is used to track the total execution order among microthreads. When a new microthread is created, a new epoch identifier must be created. To make the handling of epoch identifiers practical, in some embodiments, they are processed cyclically. The thread control circuit assigns epoch identifiers in ascending order when a new microthread is created and wraps around when the largest supported epoch identifier value is reached. This scheme can be efficiently implemented using two counters, one storing the earliest assigned epoch identifier (assigned to the oldest speculative microthread) and the other the most recently assigned epoch identifier (assigned to the newest speculative microthread). This simplification is possible because the state of the microthreads is committed, that is, merged into the architecture state in the order of epoch identifiers from the oldest speculative microthread to the newest speculative microthread in order to preserve sequential semantics, and therefore the epoch identifiers are released in order.

[0019] In at least some embodiments, a particular microthread of an instruction is the first microthread of the instruction, and in response to a detach instruction, the thread control circuit is adapted to assign a new epoch identifier to the second microthread of the instruction. Thus, after the execution of the detach instruction, if the runtime data satisfies the parallelization criteria, the first microthread of the instruction retains its current epoch identifier and executes several instructions until it reaches a reattach instruction. When the first microthread of the instruction reaches a reattach instruction successfully, i.e., without the identification of hazards or interrupts, it may commit to the architecture state. Furthermore, when the detach instruction is executed, a second microthread of the instruction is created and assigned a new epoch identifier. In some embodiments, the second microthread of the instruction may include a detach instruction that causes a third microthread to be further created using the mechanism described above. Thus, for example, a loop can be parallelized in which a new thread is created for each iteration of the loop body. This approach may be advantageous when the number of loop iterations is small, as each microthread can be used to execute instructions in the loop body.

[0020] In at least some embodiments, a particular microthread of an instruction is a second microthread of the instruction, and prior to a detach instruction, a first microthread of the instruction is assigned a first epoch identifier, and in response to the detach instruction, the thread control circuit is adapted to assign a new epoch identifier to the first microthread of the instruction and assign the first epoch identifier to the second microthread of the instruction. In this way, after execution of the detach instruction, when the runtime data meets the parallelization criteria, a second microthread of the instruction is generated, inherits the epoch identifier of the first microthread of the instruction, a new epoch identifier is generated, and assigned to the first microthread of the instruction. When the second microthread of the instruction reaches a reattach instruction successfully, i.e., without identification of a hazard or interrupt, the second microthread of the instruction may commit to the architectural state. In some embodiments, the first microthread of the instruction may include a detach instruction that causes a third microthread to be further generated using the mechanism described above. In this way, for example, a loop can be parallelized, and the microthreads of the first microthread of the instruction generate separate microthreads of the instruction to process each iteration of the loop. This approach is advantageous because it can quickly generate multiple microthreads by the first microthread of the instruction without waiting for any generation overhead associated with each new thread that sequentially generates subsequent threads.

[0021] In at least some embodiments, a detach instruction specifies a region identifier, and at least one subsequent reattach instruction specifies a region identifier. In this way, the decode circuit can generate a control signal that the thread control circuit can use to identify which reattach-detach instruction pair corresponds to each other. In particular, this enables a programmer or compiler to insert nested hint-based reattach-detach pairs, and enables the thread control circuit to preserve the sequential semantics of the program.

[0022] In at least some embodiments, the region identifier is a first region identifier, a subsequent detach instruction specifies a second region identifier, a subsequent reattach instruction specifies a second region identifier, the epoch identifier includes an outer epoch identifier and an inner epoch identifier, and when the subsequent detach and reattach instructions are between a detach and a reattach instruction in program order, the outer epoch identifier is assigned in relation to the detach instruction and the inner epoch identifier is assigned in relation to the subsequent detach instruction. By dividing the epoch identifier into an outer epoch identifier associated with the outer reattach and detach instructions and an inner epoch identifier associated with the inner reattach and detach instructions, the overall program order can be maintained on the epoch identifier. It will be readily apparent to those skilled in the art that this disclosure is not limited to outer and inner epoch identifiers, and that any number of nested epoch identifiers can be defined and assigned to a corresponding number of nested detach and reattach instructions.

[0023] In some embodiments, the runtime data is first runtime data, the performance metric is a first performance metric associated with a first region identifier, and the thread control circuit is adapted to collect second runtime data indicative of a second performance metric associated with a second region identifier. In this way, the thread control circuit can determine, for a particular region identifier, whether it is beneficial for the thread control circuit to generate a new microthread associated with that region identifier or whether it is more beneficial to ignore hint-based parallelization instructions associated with that region identifier. For example, the thread control circuit may determine that it is not beneficial to parallelize an outer loop corresponding to an outer set of detach-reattach instructions based on the first runtime data and the first performance metric, but based on the second runtime data and the second performance metric, the thread control circuit may determine that it is beneficial to parallelize an inner loop corresponding to an inner set of detach-reattach instructions. Alternatively, it may be determined that it is beneficial to parallelize the outer loop rather than the inner loop.

[0024] In some embodiments, when the number of currently active microthreads is equal to the maximum number of microthreads supported, the data processing apparatus is configured to treat a detach instruction as one of an unconditional branch instruction and a no-operation. This prevents the data processing apparatus from generating microthreads due to microthreads that cannot be supported by the thread control circuit, the number of physical registers available in the data processing apparatus, the available memory bandwidth, or the execution unit throughput. These are merely examples of situations where additional microthreads cannot be supported, and it will be readily apparent to those skilled in the art that the data processing apparatus can treat a detach instruction as one of an unconditional branch instruction and a no-operation in response to any limitations of the hardware depending on the particular embodiment.

[0025] In some embodiments, the decoder circuit, in response to a synchronization instruction in the microthread of the instruction with the most recent epoch identifier, suspends the execution of subsequent instructions in the most recent microthread of the instruction until all generated microthreads with older epoch identifiers and the same region identifier have finished. The synchronization instruction is associated with a specific region identifier selected by the programmer or compiler and matches the region identifier of a paired detach-reattach instruction. The role of the synchronization instruction is to act as a synchronization barrier for all microthreads generated within a particular parallel region. Once all generated microthreads have completed execution by issuing a reattach instruction, the microthread issuing the synchronization instruction can continue execution as the sole executing microthread associated with the region identifier. The microthread issuing the synchronization instruction is the thread with the most recent epoch identifier running in the parallel region. The initial merging of all generated microthreads, preserving the expected sequentially observable semantics, requires that all microthreads with older epoch identifiers have successfully terminated and committed to the architecture state in strict epoch identifier order by executing their reattach instructions, and that the synchronously issued microthreads, once they have the oldest uncommitted speculative state, commit to the architecture state and continue sequential execution beyond the synchronous instruction. This approach ensures that any operation after a potential parallel region can continue execution in the same architecture state as if the parallelization hint had been omitted or treated as one of the no-operation and unconditional branch instructions.

[0026] In at least some embodiments, when runtime data does not meet the parallelization criteria, the thread control circuit is adapted to interpret synchronization instructions as no action. In this way, program execution can be configured to continue as if the synchronization instruction had not occurred, and program execution continues from the instruction that would have occurred if the synchronization instruction had not been inserted by the compiler or programmer.

[0027] In at least some embodiments, the decoder circuit further pauses the execution of subsequent instructions in the most recent microthread of an instruction in response to a synchronization instruction in the microthread of the instruction having the most recent epoch identifier, until all generated microthreads with older epoch identifiers and different region identifiers have finished. In this way, a synchronization instruction is executed that acts as a global synchronization instruction, so that at a given point in time, all microthreads from all region identifiers are committed, thereby ensuring that only one thread can exist after the execution of the global synchronization instruction, and that the existing thread is the thread that issued the synchronization instruction.

[0028] In at least some embodiments, based on a scheduling coefficient n, the thread control circuit is adapted to interpret the occurrence of detach instructions and reattach instructions as one of an unconditional branch instruction and one of a no-action. The default scheduling policy for parallel tasks assumes that a detach action, which is not treated as one of a no-action or unconditional branch instruction, triggers the creation of a new microthread. For auto-hint-based parallelization of some loops, this may be suboptimal, especially when the loop body contains a small number of instructions. However, if intra-loop dependencies are rare or nonexistent at runtime, the loop can still benefit from parallelization.

[0029] In at least some embodiments, the thread control circuit is adapted to generate a second microthread of the instruction in response to every n occurrence of the detach instruction, and to interpret all other occurrences of the detach instruction as either an unconditional branch instruction or a non-operation; and the thread control circuit is adapted to terminate a particular microthread of the instruction in response to every (n-1) occurrence of the reattach instruction, and to interpret all other occurrences of the reattach instruction as either an unconditional branch instruction or a non-operation. For example, when n=2, the first occurrence of the detach instruction generates a new microthread, but the first occurrence of the reattach instruction and the second occurrence of the detach instruction are treated as either a non-operation or an unconditional branch operation. In this way, each microthread is executed through two occurrences of a parallel region of code, reducing the burden of creating new threads while still gaining the benefits of parallelism.

[0030] In some embodiments, the scheduling coefficient n is based on runtime data. This mechanism allows the thread control circuit to adjust the number of times regions of parallel code are executed within each microthread based on runtime data. For example, runtime data may indicate that, based on the overhead of generating microthreads, a value of n less than 3 does not provide the benefits of parallelization, while a larger value of n may indicate a higher likelihood of data hazards. Therefore, the thread control circuit can favorably select a value of n between 3 to obtain the benefits of parallelization while minimizing the likelihood of data hazards.

[0031] In at least some embodiments, the decoder circuit further responds to a detach instruction specifying an alternate address, and when n is greater than 1, the thread control circuit is configured to start execution in a second execution context from the alternate address. When n is greater than 1, the instruction corresponding to the alternate address can be used to increment the inductive variable by a quantity n. For example, a hint-based parallelization instruction can be inserted so that the thread control circuit can choose whether to generate parallel threads with the value n=1 or n=2. When n=1, the second address to which the first microthread of the instruction continues execution can define a loop continuation block in which the inductive variable associated with the loop is incremented by 1. Furthermore, the alternate address can be used when n=2 to define an alternate continuation block in which the inductive variable associated with the loop is incremented by 2. The selection of n=1 and n=2 is for illustrative purposes, and it will be readily apparent to those skilled in the art that any value of n can be selected.

[0032] In at least some embodiments, the decoder circuit further responds to a detach instruction specifying an alternate address, and when n is greater than 1, the thread control circuit is configured to allow the first microthread of the instruction to continue execution from the alternate address. When n is greater than 1, the instruction corresponding to the alternate address can be used to increment the recursive variable by a quantity n. For example, a hint-based parallelization instruction can be inserted so that the thread control circuit can choose whether to generate a parallel thread with the value n=1 or n=2. When n=1, the thread control circuit can generate a second thread, and the address can define a loop continuation block in which the recursive variable associated with the loop is incremented by 1. Furthermore, the alternate address can be used when n=2 to define an alternate continuation block in which the recursive variable associated with the loop is incremented by 2. The selection of n=1 and n=2 is for illustrative purposes, and it will be readily apparent to those skilled in the art that any value of n can be selected.

[0033] In at least some embodiments, the decoder circuit further responds to a detach instruction specifying additional metadata, which includes at least one of the following: a parallelization confidence level representing the likelihood of dynamic dependencies between microthreads occurring at runtime; a parallelization value level providing an estimate of the number of instructions to be included in a second microthread of the instruction; and an instruction for the type of dynamic dependency expected to occur between microthreads at runtime. The additional metadata may be specified by the programmer or compiler, for example, based on profiling data and / or estimated use cases. The specified additional metadata can be interpreted by the thread control circuit in conjunction with runtime data to determine the most appropriate time to speculatively generate additional microthreads. For example, if the programmer or compiler indicates a high parallelization confidence level or a high parallelization value level, the thread control circuit may require the runtime data to meet a lower threshold before generating additional microthreads. Alternatively, if the programmer or compiler indicates a low parallelization confidence level or a low parallelization value level, the thread control circuit may require the runtime data to meet a higher threshold before generating additional microthreads.

[0034] In at least some embodiments, the performance metric includes at least one of the following: the average number of instructions executed per cycle, the average resource utilization within the multithreaded processing circuit, the number of memory reads after a write contention is detected, and the number of instructions executed per microthread of the instruction. In this way, the thread control circuit can determine at runtime whether, for a particular set of instructions, it is likely to be beneficial to execute the instructions in parallel, or whether there are insufficient resources to execute the instructions in parallel, whether the likelihood of data hazards is too high, or whether the overhead associated with parallelizing a particular set of instructions is too high to justify any benefit. In at least some embodiments, runtime data is constantly being updated, and as a result, it may be determined that the current set of parallel microthreads offers little or no benefit. In this regard, the thread control circuit may determine that it is better to stop parallel execution or correct a pair of detach and reattach instructions that were treated as one of the non-operating or unconditional branch instructions in order to improve the performance of the data processing unit.

[0035] In at least some embodiments, the data processing device comprises a set of physical registers and a register renaming circuit that maps a set of architectural registers to a subset of the set of physical registers, the register renaming circuit mapping a first set of architectural registers to a first set of physical registers associated with a first execution context, and the register renaming circuit mapping a second set of architectural registers to a second set of physical registers associated with a second execution context. In this way, a complete set of architectural registers can be maintained for each execution context associated with the set of currently executing microthreads.

[0036] In at least some embodiments, the first subset of the first set of physical registers and the first subset of the second set of physical registers are the same set of registers, while the second subset of the first set of physical registers and the second subset of the second set of physical registers are different sets of registers. In this way, where it is beneficial to do so, the thread control circuit can have several execution contexts share the first subset of physical registers and maintain a second subset of physical registers specific to each execution context. In other words, the architectural state of each execution context can be defined by several shared registers in addition to several registers specific to each execution context. When it is unlikely that data will be modified during the parallel execution of microthreads, it is beneficial to maintain only one copy of the physical registers in which that data is stored. This can increase the number of physical registers available to different execution contexts and thus increase the total number of supported execution contexts.

[0037] In at least some embodiments, the data processing method includes: collecting runtime data indicating performance metrics related to the processing operations of multiple microthreads in corresponding execution contexts defining an architectural state on a multithreaded processing circuit; generating a detach control signal in response to a detach instruction in a first microthread of an instruction executed in a first execution context defining a first architectural state, wherein the detach instruction specifies an address; and, in response to the detach control signal, generating a second microthread of an instruction executed in a second execution context defining a second architectural state based on the first architectural state, provided that the runtime data satisfies parallelization criteria, wherein the second microthread of the instruction includes a subset of instructions from the first microthread of the instruction, starting from an address.

[0038] In at least some embodiments, the data processing device includes means for collecting runtime data indicating performance metrics related to the processing operations of multiple microthreads in corresponding execution contexts defining an architectural state on a multithreaded processing circuit; means for generating a detach control signal in response to a detach instruction in a first microthread of an instruction executed in a first execution context defining a first architectural state, wherein the detach instruction specifies an address; and means for generating a second microthread of an instruction executed in a second execution context defining a second architectural state based on the first architectural state, in response to the detach control signal, when the runtime data satisfies a parallelization criterion, wherein the second microthread of the instruction includes a subset of instructions of the first microthread of the instruction starting from an address.

[0039] Here, several specific embodiments will be described with reference to the figures.

[0040] Figure 1 schematically shows a data processing device that can embody various embodiments of this technique. The data processing device 10 comprises a multithreaded processing circuit 12 and a thread control circuit 14. The thread control circuit 14 is adapted to support multiple microthreaded contexts 16. The multithreaded processing circuit 12 is a set of multithreaded execution resources and comprises multiple execution pipelines 18, a set of physical registers 20, an instruction cache 22, a level 1 data cache 26, and a level 2 cache 24. Each of the multiple execution pipelines includes a fetch circuit 28 that fetches instructions from the instruction cache 22. The fetched instructions are passed to a decode circuit 30 and a rename circuit 32 that generate control signals for other components of the multithreaded processing circuit, including the thread control circuit 14. The rename circuit 32 maps several physical registers 20 to a corresponding set of architectural registers associated with the execution context running on the pipeline 18, then passes the decoded instruction to the issue circuit 43, which issues it to the execution circuit 36. The execution circuit may include, but is not limited to, arithmetic logic units, floating-point units, and load / store units. Once the instruction has completed execution, it is passed to the rewrite circuit 40. The pipelines of components 28, 30, 32, 34, 36, and 40 are intended to be examples of a typical multithreaded data processing unit, and it will be readily apparent to those skilled in the art that any pipeline component may be a dedicated component provided for each pipeline, or may be shared among any number of pipelines 18. For example, each pipeline 18 may have several dedicated pipeline components and several components shared with one or more other pipelines 18. However, additional structures not explicitly shown may be added to the data processing unit 10. It will be readily apparent to those skilled in the art that the multithreaded processing circuit 12 may also include a single pipeline 18 that interleaves its resources across multiple microthread contexts.

[0041] Figure 2 schematically illustrates the operation details of a thread control circuit that can embody various embodiments of the present technique. In some embodiments, this thread control circuit 42 may provide the thread control circuit 14 of Figure 1. The thread control circuit 42 stores several counters used to control and track different microthreads running on the data processing unit. In particular, the thread control circuit uses an epoch counter 44 to track, for each region identifier corresponding to the currently executing set of code indicated by instruction detach-reattach pairs, the oldest epoch identifier issued to the microthread having that region identifier and the newest epoch identifier issued to the microthread having that region identifier. In this way, in-flight epoch identifiers may be maintained for each region identifier, as further described in relation to Figure 3A. In addition, the thread control circuit 42 may maintain an execution context table 46 showing each execution context, corresponding epoch identifier, and corresponding region identifier currently maintained by the multithreading unit. It will be readily apparent to those skilled in the art that the information indicated to be held in the execution context table 46 is not exhaustive, and any information associated with an execution context may also be stored there. For example, the execution context table 46 may maintain a mapping between physical registers and architectural registers assigned to each execution context. In addition, the thread control circuit maintains runtime data 48 based on performance metrics related to processing operations. The runtime data may be continuously updated based on the currently executing instruction and / or maintained independently for each region identifier. In this way, the thread control circuit can control and maintain, for each region identifier, whether additional microthreads are created, and, if so, which epoch identifiers are associated with which execution contexts and which region identifiers.

[0042] Figures 3A and 3B schematically illustrate the details of epoch identifier assignment, which can embody various embodiments of this technique. Starting from Figure 3A, the epoch identifier 50 is processed cyclically. The thread control circuit assigns epoch identifiers in ascending order as new microthreads are created, and wraps around when the largest supported epoch identifier is reached. This scheme is implemented using two counters that track the oldest epoch identifier 52 and the newest epoch identifier 54. When a new epoch identifier is assigned, the newest epoch identifier is incremented, and when the oldest epoch identifier is assigned, it wraps around to 0. When a microthread is committed (this happens in order), the oldest epoch identifier is incremented, thereby freeing the epoch identifier for use by subsequent microthreads. As shown in Figure 2, the newest epoch counter 54 and the oldest epoch counter 52 are maintained for each region identifier.

[0043] As shown in Figure 3B, in embodiments where nested parallelization regions are supported, the epoch identifier 56 associated with each microthread may be defined hierarchically. In the illustrated embodiment, the epoch identifier 56 is defined by the outermost identifier 58 associated with the outermost pair of detach-reattach instructions, the outer identifier 60 defined by the outer pair of detach-reattach instructions nested within the outermost pair of detach-reattach instructions, the inner identifier 62 associated with the inner pair of detach-reattach instructions nested within the outer pair of detach-reattach instructions, and the innermost identifier associated with the innermost pair of detach-reattach instructions nested within the inner pair of reattach instructions. The definition of the four layers of epoch identifiers associated with nested pairs of detach-reattach instructions is for illustrative purposes only, and it will be readily apparent to those skilled in the art that any number of sets of nested pairs of detach-reattach instructions can be supported based on the mechanism described. In some embodiments, the bit width assigned to each layer of epoch identifiers may be dynamically changed by hardware at runtime, while in other embodiments, the bit width assigned to each layer of epoch identifiers may be statically determined. Similar to the example described in relation to Figure 3A, each of the outermost identifiers 58, 60, 62, and 64 requires maintenance of a pair of counters associated with the oldest and newest epoch identifiers. In particular, the outermost epoch identifier 58 is one of the available set of outermost identifiers 66 and is associated with the oldest outermost identifier 68 and the newest outermost identifier 70. Similarly, the assignments of each of the outer identifiers 60, 62, and 64 are maintained through the corresponding oldest outer identifier and newest outer identifier, oldest inner identifier and newest inner identifier, and oldest innermost identifier 74 and newest innermost identifier 76.

[0044] Figures 4 to 7 schematically illustrate details of microthreaded execution examples that can embody various embodiments of this technique. In particular, these figures are based on the following exemplary C code, which has corresponding optimized assembly code.

[0045] [Table 1]

[0046] In the illustrated examples, the compiler makes the following modifications to the assembly code in order to utilize the task-level parallelization described in some embodiments of the present invention.

[0047] [Table 2]

[0048] The detach instruction used in the modified assembly code above contains multiple inputs. The loop_body and loop_cont fields are the addresses of the instruction's detach block and continuation block, respectively. These can be encoded using a program counter-based offset to represent such addresses. The detach block field can be omitted if it corresponds to an instruction following the detach instruction in program order. The region_id field is a region identifier that must be unique at runtime and associated with a particular annotated region. In practice, it is sufficient for the region identifier to be unique only within a region nest, meaning that the same region identifier can be reused across different nests. Metadata fields may capture extra information that can be passed to the thread control circuit. In particular, metadata can be used to encode a parallelization confidence level, representing the likelihood of dynamic dependencies materializing at runtime, based on profiling data, for example, to encode a parallelization value level by including additional information about the estimated length of parallel paths expressed in terms of the number of instructions, which may include both the best-case and worst-case number of instructions, and other information related to the expected types of dependencies within a region, such as the presence or absence of read-after-write hazards. Similarly, the reattach instruction specifies the loop_cont address and region identifier, while the synchronization instruction specifies the region identifier.

[0049] Figure 4 schematically illustrates the details of an example of microthread execution that can embody various embodiments of this technique. In particular, the thread executing the detach instruction (in this case, uthread 0) continues execution starting from a continuation path (loop_cont) with a newly assigned epoch identifier, reflecting the fact that in the original serial program, the continuation path would have been executed after the detach path (loop body) in program order. The generated microthread (uthread 1) starts execution from the detach path (loop_body) with an epoch identifier inherited from the parent microthread. In this exemplary embodiment, uthread 0 executes the instruction after loop_cont, increments the value initially stored in x10 by 1, compares the value of x10 with x3, and updates the condition flag based on the result before branching to loop_head and re-executing the detach instruction. This generates a new microthread, uthread 2, which continues from loop_body with the updated value in register x10 imported from the execution context associated with uthread 0 to the execution context associated with uthread 2. As illustrated, the creation of the microthread by uthread 0 continues until the condition flag associated with the b.ne instruction is set to 0, i.e., the value held in register x10 is equal to x3. At this point, a synchronization instruction is issued, and the execution of uthread 0 is paused until all microthreads with old epoch identifiers have completed, i.e., until the microthreads have successfully executed the reattach instruction.

[0050] Figure 5 schematically illustrates the details of an example of microthread execution that can embody various alternatives to this technique. In particular, the thread executing the detach instruction (initially uthread 0) continues execution from loop_body without changing its epoch identifier. The generated microthread (initially uthread 1) starts execution from loop_cont using the newly assigned epoch identifier, reflecting the fact that in the original serial program, the continuation path would have been executed after the detach path in program order. In this case, uthread 0 continues until it reaches the reattach instruction, uthread 1 starts at the continuation address, increments the value stored in register x10 by 1, compares the value stored in x10 with the value stored in x3, and updates the condition flag based on the result before branching to loop_head (assuming successful execution without data hazards). Execution of uthread 1 continues from loop_head with the issuance of a detach instruction that creates microthread 2, before uthread 1 continues until it reaches the reattach instruction from loop_body (assuming no data hazards and successful execution). As illustrated, the creation of a new microthread by each previous microthread continues until the condition flag associated with the b.ne instruction is set to 0, i.e., the value held in register x10 is equal to x3. At this point, the execution of the microthread issuing the synchronization instruction (in this case, uthread n) is paused until all microthreads with old epoch identifiers have completed, i.e., successfully executed the reattach instruction.

[0051] Figure 6 schematically illustrates the details of an example of microthread execution that can embody various embodiments of this technique. In the illustrated example, the creation of microthreads follows the method described in Figure 4, with the additional feature that a scheduling coefficient n>1 is set. As a result, the microthreads must serially delete specific occurrences of detach and reattach instructions by treating them as one of the non-operational and unconditional branch instructions. Specifically, if detach-reattach instructions are indexed within a microthread starting i=0 and ascending in program order, the i-th detach should be serially deleted if (i%n)≠0, and the microthread issuing the detach is the parent thread of all created threads (uthread 0 in this example), where i%n refers to i modulo n. For other created microthreads, all detach instructions must be serially deleted because only the parent microthread can create new microthreads. In addition, the i-th reattach instruction should be serially deleted only if (i%n)≠n-1. In particular, in this embodiment, the scheduling coefficient is set to n=2. As a result, uthread 0 generates a new microthread for odd-numbered occurrences of the detach instruction and serially deletes even-numbered occurrences of the detach instruction. Furthermore, uthread 0 increments the loop index i twice between each detach instruction that is not serially deleted. Each generated microthread runs through two iterations of the loop body, incrementing the loop index i each time the loop_cont block of the instruction is executed. As a result, uthread 0 generates uthread 1 with index i=0, and uthread 0 then increments the loop index before serially deleting the second occurrence of the detach instruction. The loop index is incremented again by uthread 0 before encountering a third detach instruction, and uthread 2 is generated with loop index i=2, and this process continues until uthread 0 encounters a synchronization instruction, as described in relation to Figure 4.

[0052] Figure 7 schematically illustrates the details of an example of microthread execution that can embody various embodiments of this technique. If the number of loop iterations is not an integer multiple of the scheduling coefficient, both the parent microthread (uthread 0 in the illustrated embodiment) and the last created microthread may execute a synchronization instruction. This scenario is handled by introducing a rule that states synchronization removes or squashes microthreads that have an epoch identifier newer than the epoch identifier of the microthread issuing the synchronization instruction itself. In the illustrated embodiment, microthread uthread n / 2 reaches the execution of synchronization with epoch identifier (x + (n / 2) - 1) % max_epochs, where x is the initial epoch identifier of uthread 0 and max_epochs is the highest defined epoch identifier. The epoch identifier of microthread uthread 0 is (x + (n / 2)) % max_epochs when it reaches the synchronization instruction. In this embodiment, the epoch identifier of microthread uthread 0 is newer than the epoch identifier of microthread uthread n / 2, resulting in squashing, and sequential execution continues from the execution context of microthread uthread n / 2 at the end of the parallel section.

[0053] Figures 8 and 9 schematically illustrate details of microthreaded execution examples that can embody various embodiments of the technique. Specifically, these figures are based on the same exemplary C code corresponding to Figures 4 to 7, with the following modifications made by the compiler to the assembly code in order to utilize task-level parallelization with a scheduling coefficient n > 1 as described in some embodiments of the present invention.

[0054] [Table 3]

[0055] It is common for loops to have relatively simple sequential paths, and the code primarily deals with incrementing and decrementing an inductive variable. Therefore, the thread generation rate can be relatively high, and further optimizations can be leveraged by providing an alternative version of the continuation block that starts with an alternative continuation path (loop_cont_x2) that allows for faster generation speeds by incrementing the inductive variable once to cover multiple loop iterations. In the exemplary code above, a scheduling coefficient n=2 is used, but those skilled in the art will recognize that this is chosen for illustrative purposes only and any integer greater than 1 can be used.

[0056] Figure 8 schematically illustrates the details of an example of microthreaded execution that can embody various embodiments of this technique based on the exemplary assembly code described above. In the illustrated embodiments, execution proceeds as described in relation to Figure 7, with the notable exception that when the detach instruction is executed, the microthread uthread 0 jumps to the alternate continuation address (loop_cont_x2). The alternate continuation block starts from the alternate continuation address and increments the value of the loop index in register x10 by 2. Next, the value in x10 is checked against x3 and a condition flag is set. If the value of x10 is less than x3, the b.lt (branch if less than) instruction causes the flow to jump to loop_head; otherwise, the flow proceeds to jump to the synchronous instruction. In these illustrated embodiments, the microthread uthread 0 does not need to decrement the loop index twice. Instead, the value is decremented once by 2 in the alternate continuation block.

[0057] Figure 9 schematically illustrates the details of an example of microthread execution that can embody various embodiments of this technique based on the exemplary assembly code described above. In particular, the thread executing the detach instruction (initially uthread 0) continues execution from loop_body without changing its epoch identifier. The generated microthread (initially uthread 1) starts execution from an alternate continuation path (loop_cont_x2) with a newly assigned epoch identifier, reflecting the fact that in the original serial program, the alternate continuation path would have been executed after the detach path in program order. In the illustrated example, the scheduling coefficient is set to n=2. As a result, the microthreads must serially remove specific occurrences of detach and reattach instructions by treating them as one of the non-operating and unconditional branch instructions. Specifically, this applies when indexing detach-reattach instructions within microthreads in ascending order of program order, starting from i=0 or less. The i-th detach instruction should be serially deleted if (i%n)≠0, and the i-th attach instruction should be serially deleted only if (i%n)≠n-1. As a result, uthread 0 generates uthread 1 with index i=0, which is immediately incremented to i=2 in the alternate continuation block before returning to loop_head where the detach instruction is executed and the microthread uthread 2 is generated with index i=2. Once the first detach instruction is executed by the microthread (using microthread uthread 0 as an example), the loop body is executed with index i=0, then the first occurrence of the reattach instruction is serially deleted, and the flow jumps to the continuation block (loop_cont) where the loop index is incremented again (i=1). Next, the flow moves to the loop head, the detach instruction is serially deleted, the loop body is executed before encountering the second reattach instruction, and uthread 0 completes.The detach instruction following the alternate continuation block (loop_cont_x2) is not serially deleted because the scheduling coefficient n is hardwired to this version by the compiler. This process continues until the value in register x10 is greater than or equal to x3, as the flow branches to a synchronous instruction, and at this point, the execution of the microthread issuing the synchronous instruction (in this case, uthread(n / 2)) is paused until all microthreads with old epoch identifiers have completed, i.e., successfully executed the reattach instruction.

[0058] Figure 10 schematically illustrates a series of steps performed by several embodiments of the present invention. In step S1, runtime data is collected showing performance metrics related to the processing operations of multiple microthreads in a corresponding execution context that defines an architectural state on a multithreaded processing circuit. In step S2, a detach control signal is generated in response to a detach instruction in a first microthread of an instruction executed in a first execution context that defines a first architectural state, and the detach instruction specifies an address. In step S3, in response to the detach control signal and when the runtime data satisfies a parallelization criterion, a second microthread of an instruction is generated that is executed in a second execution context that defines a second architectural state based on the first architectural state, and the second microthread of the instruction includes a subset of the instructions of the first microthread of the instruction, starting from an address. It will be readily apparent to those skilled in the art that the parallelization criterion may be an indication that it is beneficial to generate an additional microthread, or it may be the absence of an indication that it is not worthwhile to generate an additional microthread.

[0059] In summary, an outline of a data processing device and method for processing data is disclosed. The data processing device comprises a multithreaded processing circuit that executes processing operations of multiple microthreads, each microthread operating in a corresponding execution context that defines an architectural state. The thread control circuit collects runtime data indicating performance metrics related to the processing operations. The decoder circuit provides a detach control signal to the thread control circuit in response to a detach instruction in a first microthread of an instruction executed in a first execution context that defines a first architectural state, the detach instruction specifying an address. When the runtime data satisfies parallelization criteria, the thread control circuit, in response to the detach control signal, generates a second microthread of an instruction executed in a second execution context that defines a second architectural state based on the first architectural state, the second microthread of instructions containing a subset of the instructions of the first microthread of instructions, starting from an address.

[0060] In this application, the term "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 configuration 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 any modifications must be made to the device element to provide the defined operation.

[0061] While exemplary embodiments have been described in detail in this specification with reference to the accompanying drawings, it should be understood that the present invention is not limited to embodiments identical thereto, and various changes, additions, and modifications can be made by those skilled in the art without departing from the scope and spirit of the invention as defined in the appended claims. For example, various combinations of features of the independent claims may be made of features of the dependent claims without departing from the scope of the invention.

Claims

1. A data processing device, A multithreaded processing circuit that executes processing operations of multiple microthreads, wherein each microthread operates in a corresponding execution context that defines the architectural state, A thread control circuit that collects runtime data showing performance metrics related to the aforementioned processing operation, A decoder circuit that provides a detach control signal to a thread control circuit in response to a detach instruction in a first microthread of an instruction executed in a first execution context defining a first architectural state, wherein the decoder circuit specifies an address of the detach instruction, Equipped with, When the runtime data satisfies the parallelization criteria, the thread control circuit, in response to the detach control signal, generates a second microthread of instructions to be executed in a second execution context that defines a second architecture state based on the first architecture state, the second microthread of instructions including a subset of instructions of the first microthread of instructions starting from the address, the data processing device.

2. The aforementioned address is a first address, the aforementioned subset of instructions is a first subset of instructions, and the aforementioned detach instruction further includes a second address. The data processing device according to claim 1, wherein when the runtime data satisfies the parallelization criteria, the thread control circuit, in response to the detach control signal, causes the first microthread of the instruction to execute a second subset of instructions that start at the second address.

3. The data processing apparatus according to claim 2, wherein the first subset of instructions and the second subset of instructions are subsets of the first microthread of instructions that do not overlap during dynamic execution.

4. The data processing device according to any one of claims 1 to 3, wherein when the runtime data does not satisfy the parallelization criteria, the thread control circuit is adapted to interpret the detach instruction as one of an unconditional branch instruction and no operation.

5. The decoder circuit, in response to a reattach instruction within a specific microthread of an instruction, provides a reattach control signal to the thread control circuit. The data processing apparatus according to any one of claims 1 to 4, wherein the thread control circuit terminates a specific microthread of the instruction in response to the reattach control signal.

6. The data processing apparatus according to claim 5, wherein the thread control circuit indicates the unsuccessful termination of the particular microthread in response to the occurrence of a data hazard between the particular microthread of the instruction and another microthread of the instruction.

7. The data processing device according to claim 6, wherein the thread control circuit respawns the specific microthread of the instruction in response to the instruction for unsuccessful termination.

8. The data processing device according to any one of claims 5 to 7, wherein when the runtime data does not satisfy the parallelization criteria, the thread control circuit is adapted to interpret the reattach instruction as one of an unconditional branch instruction and no operation.

9. A data processing device according to any one of claims 5 to 8, wherein each microthread is identified by an epoch identifier.

10. The specified microthread of the instruction is the first microthread of the instruction, The data processing apparatus according to any one of claims 5 to 9, wherein, in response to the detach instruction, the thread control circuit is adapted to assign a new epoch identifier to the second microthread of the instruction.

11. The aforementioned specific microthread of the instruction is the aforementioned second microthread of the instruction, Prior to the detach instruction, the first microthread is assigned a first epoch identifier, and in response to the detach instruction, the thread control circuit is adapted to assign a new epoch identifier to the first microthread of the instruction and to assign the first epoch identifier to the second microthread of the instruction, according to any one of claims 5 to 9.

12. The data processing apparatus according to any one of claims 5 to 11, wherein the detach instruction specifies a region identifier, and at least one subsequent reattach instruction specifies the region identifier.

13. The aforementioned region identifier is a first region identifier, a subsequent detach instruction specifies a second region identifier, and a subsequent reattach instruction specifies the second region identifier. The aforementioned epoch identifier includes an outer epoch identifier and an inner epoch identifier, The data processing device according to claim 12, wherein if the subsequent detach instruction and the subsequent reattach instruction are between the detach instruction and the reattach instruction in the program sequence, the outer epoch identifier is assigned in association with the detach instruction and the inner epoch identifier is assigned in association with the subsequent detach instruction.

14. The runtime data is first runtime data, and the performance metric is a first performance metric associated with the first domain identifier. The data processing apparatus according to claim 13, wherein the thread control circuit is adapted to collect second runtime data indicating a second performance metric associated with the second region identifier.

15. The data processing device according to any one of claims 1 to 14, wherein when the number of currently active microthreads is equal to the maximum number of supported microthreads, the data processing device is configured to treat the detach instruction as one of an unconditional branch instruction and no operation.

16. The data processing apparatus according to any one of claims 12 to 15, wherein the decoder circuit, in response to a synchronization instruction in the microthread of the instruction having the most recent epoch identifier, suspends the execution of subsequent instructions in the most recent microthread of the instruction until all generated microthreads having older epoch identifiers and the same region identifier have finished.

17. The data processing device according to claim 16, wherein when the runtime data does not satisfy the parallelization criteria, the thread control circuit is adapted to interpret the synchronization instruction as no operation.

18. The data processing apparatus according to claim 16 or 17, wherein the decoder circuit further responds to the synchronization instruction in the microthread of the instruction having the most recent epoch identifier by suspending the execution of subsequent instructions in the most recent microthread of the instruction until all generated microthreads having older epoch identifiers and different region identifiers have finished.

19. When dependent on claim 5, the data processing device according to any one of claims 1 to 18, wherein the thread control circuit is adapted to interpret the occurrence of the detach instruction and the occurrence of the reattach instruction as one of an unconditional branch instruction and no operation, based on a scheduling coefficient n.

20. The thread control circuit is configured to generate the second microthread of the instruction in response to every n occurrence of the detach instruction, and to interpret all other occurrences of the detach instruction as one of the unconditional branch instruction and the no operation. The data processing apparatus according to claim 19, wherein the thread control circuit is adapted to terminate the instruction of the particular microthread in response to each (n-1) occurrence of the reattach instruction, and to interpret all other occurrences of the reattach instruction as one of the unconditional branch instruction and the no operation.

21. The scheduling coefficient n is based on the runtime data, as described in claim 19 or 20.

22. The decoder circuit further responds to the detach command specifying an alternative address, The data processing device according to any one of claims 19 to 21, wherein when n is greater than 1, the thread control circuit is configured to start execution in the second execution context from the alternative address.

23. The decoder circuit further responds to the detach command specifying an alternative address, The data processing device according to any one of claims 19 to 21, wherein when n is greater than 1, the thread control circuit is configured to cause the first microthread of the instruction to continue execution from the alternative address.

24. The decoder circuit further responds to the detach command specifying additional metadata, the additional metadata being: The parallelization confidence level represents the likelihood of dynamic dependencies between microthreads that occur at runtime, A parallelization value level that provides an estimated number of instructions included in the second microthread of the instructions, Instructions for the types of dynamic dependencies that are expected to occur between microthreads at runtime, A data processing device according to any one of claims 1 to 23, comprising at least one of the following.

25. The aforementioned performance metric is The average number of instructions executed per cycle, The average resource utilization rate within the multithreaded processing circuit, The number of memory reads after detected write conflicts, The number of instructions executed per instruction microthread, A data processing apparatus according to any one of claims 1 to 24, comprising at least one of the following.

26. A set of physical registers, A register renaming circuit that maps a set of architectural registers to a subset of the set of physical registers, The data processing apparatus according to any one of claims 1 to 25, further comprising: the register renaming circuit maps a first set of architecture registers to a first set of physical registers associated with the first execution context; and the register renaming circuit maps a second set of architecture registers to a second set of physical registers associated with the second execution context.

27. The first subset of the first set of physical registers and the first subset of the second set of physical registers are the same set of registers. The data processing apparatus according to claim 26, wherein the second subset of the first set of physical registers and the second subset of the second set of physical registers are different sets of registers.

28. A data processing method, This involves collecting runtime data that shows performance metrics related to the processing operation of multiple microthreads in the corresponding execution context that defines the architectural state on the multithreaded processing circuit, and A detach control signal is generated in response to a detach instruction in a first microthread of an instruction executed in a first execution context defining a first architectural state, wherein the detach instruction specifies an address. In response to the detach control signal and when the runtime data satisfies the parallelization criteria, a second microthread of instructions is generated for execution in a second execution context that defines a second architecture state based on the first architecture state, wherein the second microthread of instructions includes a subset of instructions of the first microthread of instructions that starts from the address. A data processing method that includes this.

29. A data processing device, A means for collecting runtime data that shows performance metrics related to the processing operations of multiple microthreads in a corresponding execution context that defines the architectural state on a multithreaded processing circuit, A means for generating a detach control signal in response to a detach instruction in a first microthread of an instruction executed in a first execution context defining a first architectural state, wherein the detach instruction specifies an address; Means for generating a second microthread of an instruction to be executed in a second execution context that defines a second architecture state based on the first architecture state, in response to the detach control signal and when the runtime data satisfies parallelization criteria, wherein the second microthread of the instruction includes a subset of instructions of the first microthread of the instruction that starts at the address, A data processing device, including a data processing device.

Images