Hardware instruction-level scheduling in processors

Abstract

A processing core for executing threads is provided. The processing core comprises: one or more functional units; a shared register file comprising a plurality of registers, each register of the shared register file being configured to store data for executing any thread; and a multi-thread elaboration unit, MTEU, the MTEU comprising: a control module configured to: receive an indication of a plurality of active threads for a given scheduling window; and receive instructions for each of the plurality of active threads; a context manager module configured to load, for each of the plurality of active threads, data required for executing a next one or more of the instructions into a respective one or more registers of the shared register file; and an instruction scheduler module configured to schedule the instructions of the active threads for execution based on availability of the one or more functional units.

Description

HARDWARE INSTRUCTION-LEVEL SCHEDULING IN PROCESSORSBACKGROUND

[0001] In the computing industry, there is a need to provide components that deliver high performance, with faster processing being a significant driving force in the design of processors. In recent years, this has led to the development of various techniques for increasing performance. For example, modem central processing units (CPUs) utilize advanced architectural features to enhance performance, such as multiprocessing which enables processors to execute multiple processes, for increased computational throughput.

[0002] In traditional multiprocessing approaches, processors are provided with multiple processing cores, one for each additional process in concurrent execution. This enables multiple processes to be executed in parallel by a single processor. In another approach, the superscalar processor paradigm involves providing each processing core with multiple instruction pipelines so that multiple instructions can be executed at the same time by a single processing core.

[0003] In the hyper-threading paradigm, microarchitectures proposed by Intel and then the Blue Gene / Q e P0WER5 architectures of IBM, SPARC T3 of Oracle and Zen of AMD, enable physical multithreading on a single processing core. This involves a duplication of the control infrastructure inside each processing core for accommodating the additional thread that will then be executed. All the threads executed on the same processing core share the functional units with the other threads on the processing core. The number of threads executed on the same processing core depends on the physical implementation of the technology. These microarchitectures enable physical multithreading using multiple control infrastructures and register fdes where the number of threads depends on the processor in question (2 for Intel, AMD and IBM POWERS, 4 for IBM Blue Gene / Q and up to 8 for Oracle SPARC T3).

[0004] As will be appreciated, there is an ongoing need for high-performance processors that make efficient use of hardware resources.SUMMARY

[0005] The invention is defined in the independent claims. Various optional examples are set out in the dependent claims.

[0006] Some implementations described herein relate to a processor core for executing threads. The processor core comprises: one or more functional units; a shared register file comprising a plurality of registers, each register of the shared register file being configured to store data for executing any thread; and a multi-thread elaboration unit, MTEU. The MTEU comprises: a control module configured to: receive an indication of a plurality of active threads for a given scheduling window; and receive instructions for each of the plurality of active threads; a context manager module configured to load, for each of the plurality of active threads, data required for executing a next one or more of the instructions into a respective one or more registers of the shared register file; and an instruction scheduler module configured to schedule the instructions of the active threads for execution based on availability of the one or more functional units.

[0007] The control module may be configured to tag a register of the shared register file with an identifier that identifies a thread to which data loaded into or to be loaded into the register belongs. The processing core may comprise a shared set of general purpose registers or control registers, each general purpose register or control register of the shared set being configured to store data for managing the execution of any active thread. The control module may be configured to determine, for each of the active threads, an execution window comprising a number X of instructions. In this case, the context manager module is configured to continually load, for each of the plurality of active threads, data required for executing the next X instructions into the respective one or more registers of the shared register file. The context manager module may be configured to remove from the shared register file, for each of the plurality of active threads, data that are not required for executing the next X instructions. The instruction scheduler module may be configured to schedule the instructions of more than one of the active threads in order to reduce or minimize idle time of the one or more functional units. The instruction scheduler module may be configured to identify that a first instruction of a first active thread requires a stall and, in response to identifying that the first instruction of the first active thread requires a stall, schedule a first instruction of a second active thread for execution. The instruction scheduler module may be configured to identify that the first instruction of the first active thread that was stalled has been executed and, in response to identifying that the first instruction of the first active thread has been executed, schedule a second instruction of the first active thread for execution. The processing core may comprise a plurality of functional units. In this case, the instruction scheduler module may be configured to schedule at least one instruction of a first active thread for execution by a first subset of the functional units and schedule at least one instruction of one or more other active threads for execution by a second subset of the functional units that would otherwise be idle. The control module may be configured to receive a priority value for each of the active threads for the given scheduling window. In this case, the instruction scheduler module is configured to schedule the instructions of the active threads for execution based on the availability of the one or more functional units and the priority values of the active threads. The instruction scheduler module may be configured to schedule instructions from an active thread of a lower priority if and only if all higher priority active threads are stalling.

[0008] Some implementations described herein relate to a method of manufacturing a processor core. The method comprises: providing one or more functional units; providing a shared register file comprising a plurality of registers, each register of the shared register file being configured to store data for executing any thread; and providing a multi-thread elaboration unit, MTEU. The MTEU comprises: a control module configured to: receive an indication of a plurality of active threads for a given scheduling window; and receive instructions for each of the plurality of active threads; a context manager module configured to load, for each of the plurality of active threads, data required for executing a next one or more of the instructions into a respective one or more registers of the shared register file; and an instruction scheduler module configured to schedule the instructions of the active threads for execution based on availability of the one or more functional units.

[0009] Optional features of the processor core may be provided in some implementations of the method of manufacture.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] A set of accompanying drawings will be referred to in the description that follows, in which: Fig. 1 is a diagram of an example processing core in accordance with implementations described herein;Fig. 2 is a diagram of a typical modem processing core that performs hyperthreading and has multiple register files;Fig. 3 is a diagram of a processing core that has a shared register file in accordance with implementations described herein;Fig. 4 is a diagram showing an instruction scheduling scheme in accordance with implementations described herein;Fig. 5 is a diagram showing an instruction scheduling scheme taking into account active thread priorities in accordance with example implementations described herein;Fig. 6 is a diagram of a worked example of a scheduling scheme taking into account active thread priorities in accordance with example implementations described herein; andFig. 7 is a flow chart of a method of manufacturing a processing core in accordance with implementations described herein.DETAILED DESCRIPTION

[0011] The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

[0012] When considering the existing techniques for providing high-performance processors, the inventors have appreciated that while these approaches enable multiple threads to be processed by the same processing core, they typically require duplication of microarchitectural structures in order to accommodate additional threads. This results in increased silicon area and power consumption.

[0013] For example, although the superscalar processor paradigm enables parallel processing of multiple instructions per cycle, it requires additional instructions pipelines in the processing cores. Similarly, while hyper-threading technologies enable physical multithreading by executing multiple threads using the same functional units, additional register fdes and control infrastructures must be provided for each additional thread. In both cases, this increases power consumption and silicon area of the processor. Furthermore, in the case of hyper-threading, the number of register fdes and control infrastructures added to the core is decided by design before manufacturing, and consequently the number of threads that can be multithreaded by the processing core is predetermined and inflexible.

[0014] In a significant departure from the typical functioning of modem processors, the inventors have developed a new approach for how to manage the data required to execute multiple threads in a processor. They have appreciated that the register file can be shared by multiple threads without needing to duplicate it for each thread. In this approach, each register of the shared register file is able to store data for executing any active thread, rather than being reserved for serving only a particular thread. This approach reduces redundancy in the register files since it avoids unused but reserved registers. It also provides flexibility as to the number of threads that can be executed concurrently on a processing core because thenumber of threads is not determined by the silicon design of the processing core but can be dynamically defined depending on the state of the processing core and the needs of the threads.

[0015] Referring to Fig. 1, an example processing core 100 is shown. The processing core 100 is suitable for executing threads in accordance with implementations described herein. As used herein, the term thread refers to a sequence of instructions of a process. A process is the run time instantiation and execution of a program.

[0016] The processing core 100 comprises one or more functional units 102. A functional unit 102 is a processing unit that performs operations and computations required to execute instructions of a thread. The processing core 100 also comprises a multi -thread elaboration unit, MTEU, 104 and a shared register file 106.

[0017] The shared register file 106 comprises a plurality of registers that can be shared among a plurality of threads. Instead of having a duplicated register file for each additional thread to be executed, the shared register file 106 can accommodate the execution of multiple threads by making each register available to store data for executing instructions of any thread. Thus, each register of the shared register file 106 is configured to store data for executing any active thread. An active thread is a thread whose instructions are available to be scheduled for execution. At any given time, all active threads shared the register file. At any given time, instructions of one or more active threads may be in execution on one or more functional units of the processing core. Furthermore, the active threads may be of the same or different processes, thus introducing further flexibility. The flexible allocation of registers to active threads enables the shared register file 106 to accommodate a dynamic number of threads rather than only being able to accommodate a fixed number of threads that is predetermined by the extent of register file duplication in silicon. The flexible allocation of registers to active threads also reduces redundancy and wastage of registers in the shared register file 106 because it avoids unused but reserved registers.

[0018] The MTEU 104 comprises components for managing the use of the shared register file 106 and for managing the execution of threads whose data is stored in the shared register file 106. The MTEU 104 comprises a control module 108, a context manager module 110 and an instruction scheduler module 112. The control module 108 is configured to receive instructions for each of the plurality of active threads. The received instructions are the next incoming instructions to be executed of the active threads in a present scheduling window. A scheduling window is a period of time for which a set of active threads is defined. The set of active threads may change from one scheduling window to a subsequent one.

[0019] The context manager module 110 is responsible for ensuring that the shared register file 106 contains the data required by the one or more functional units 102 to execute the next one or more instructions of each active thread. As such, for each active thread, the context manager module 110 is configured to load data required for executing a next one or more of the received instructions into a respective one or more registers of the shared register file 106. In this way, one or more registers of the shared register file 106 are used to store the data that is needed to execute the next one or more instructions of a given active thread. The context manager module 110 closely manages the use of the shared register file 106 so that when a functional unit 102 is ready to process another instruction, the datarequired for doing so is available in the shared register fde 106. This level of management is provided for all active threads.

[0020] The instruction scheduler module 112 is responsible for scheduling instructions for execution by the one or more functional units 102. Each instruction is scheduled for execution by one or more functional units. The instructions may be distributed between the one or more functional units to create a schedule for their execution depending on functional unit availability. As such, the instruction scheduler module 112 is configured to schedule instructions from the instructions of the active threads for execution based on availability of the one or more functional units 102.

[0021] Referring to Fig. 2, aspects of a typical modem processor that performs hyper-threading are shown. The processor comprises a processing core 200 having two register files: a first register file 202 of registers 1 to n for storing data for executing instructions of a first thread, and a second register file 204 of registers 1 to n for storing data for executing instructions of a second thread. As such, the processing core 200 supports hyper-threading of two threads by virtue of the duplication of its register files in silicon. In this arrangement, all the registers of a single register file are reserved to store data of the same thread, and as a result the processing core can only support the concurrent execution of two threads which is predetermined by the way it is manufactured.

[0022] Referring to Fig. 3, aspects of a processing core 300 in accordance with the present disclosure are shown. The processing core 300 includes a shared register file 302 that can store data for executing instructions of multiple threads. In accordance with an example register sharing mechanism, each of the registers 1 to n of the shared register file 302 is tagged with an identifier 304 of the thread to which data it stores belongs. For example, if Register 1 stores data for executing instructions of a thread a, then Register 1 is tagged with an identifier a that identifies thread a. As such, the control module 108 of the MTEU 104 may be configured to tag a register of the shared register file 106, 302 with an identifier that identifies a thread to which data loaded into or to be loaded into the register belongs. The control module may be configured to perform this tagging for each register that is in use for storing data required for executing instructions.

[0023] In some processing cores in accordance with the present disclosure, further registers in addition to the ones in the register file may be available. For example, additional control registers and general purpose registers in the processing core architecture or functional units may be available. In this case, register sharing may also be applied to the additional registers in the processing core 100, for example using the above-described tagging method.

[0024] In some implementations, the control module 108 may be configured to determine, for each active thread, an execution window comprising a number X of instructions. In this case, the context manager module 110 is configured to continually load, for each active thread, data required for executing the next X instructions 306 of the active threads into a respective one or more registers of the shared register file 106, 302. The number X is the number of instructions whose data is loaded into the shared register file 106, 302 for a given active thread.

[0025] Suitably, the context manager module 110 may be configured to remove from the shared register file 106, 302, for each of the plurality of active threads, data that are not required for executingthe next X instructions. This may be performed continually, periodically or as necessary to ensure adequate availability of registers.

[0026] Referring to Fig. 4, an example instruction scheduler module 400 in accordance with the present disclosure is shown. The instruction scheduler module 400 is configured to schedule instructions 402 of the active threads. In the example shown, there are three active threads, Threads 1, 2 and 3, and there is one functional unit 404. The instruction scheduler module 400 is responsible for scheduling instructions 402 for execution by the functional unit 404. Since there is more than one active thread, the instruction scheduler module 400 can determine which active thread to schedule instructions from in case of a stall. For example, if instructions from Thread 1 are scheduled for execution by the functional unit 404, but one of them requires a stall, for example comprising a cache miss and a subsequent access to a main memory, the instructions scheduler module 400 may schedule instructions from another thread for execution while data from the main memory is retrieved. This reduces idle time of the functional unit 404, thus increasing processing throughput. In this way, the instruction scheduler module 112, 400 of the present disclosure may be configured to schedule instructions of more than one of the active threads in order to reduce or minimize idle time of the one or more functional units. Since neither duplication of functional units nor duplication of registers of the shared register file 106, 302 is required to achieve this, the processing core 100 of the present disclosure has increased processing throughput without an increased silicon area or power consumption.

[0027] Thus, the instruction scheduler module 112, 400 may be configured to identify that an instruction of a first active thread requires a stall, and, in response to this, schedule an instruction of a second active thread for execution. After one or more instructions of the second active thread have been executed, the instruction scheduler module 112, 400 may identify that the stall condition of the stalling instruction of the first thread (that may have been stalled, for example, by a cache miss) has now been resolved, and therefore that execution of instructions of the first thread may resume. In this case, the instruction scheduler module 112, 400 may be configured to schedule a next instruction of the first active thread for execution by the functional unit 404.

[0028] The functional unit 404 can therefore execute instructions for most of the time, with idle time being minimal. Suitably, the only time the functional unit 404 is idle may be when an instruction from each of the active threads requires a stall.

[0029] This scheduling scheme can also be applied to more than one functional unit. The approach is the same and the instruction scheduler module 112, 400 is configured to schedule instructions of the active threads for execution by the functional units in such a way as to reduce or minimise idle time of the functional units.

[0030] Referring to the example in Fig. 5, a scheduler may be configured to determine a priority level of each active thread for a given scheduling window. This lets the scheduler dictate to the processing core 100 the order of preference in which processing resources should be assigned for executing the active threads. For example, in the example shown there are three active threads, Threads 1, 2 and 3. The priority levels 500 of the active threads are shown in the table: in this example, Thread 1 has the highest priority of 1.0; Thread 2 has a second highest priority of 0.5; and Thread 3 has a lowest priority of 0.2Thus, the instruction scheduler module 502 may be configured to take priority values of active threads into account when scheduling instructions from the active threads.

[0031] Suitably, in this case, the instruction scheduler module 112, 400 may be configured to schedule instructions only from active threads with the highest priority, unless an instruction of one or more of those threads requires a stall. As such, the instruction scheduler module 112, 400 may be configured to schedule instructions from an active thread with a lower priority if and only if all active threads with higher priorities are stalling.

[0032] Referring to Fig. 6, a worked example of scheduling instructions according to the priorities of active threads is shown. At the start of the scheduling window, the instruction scheduler module 600 schedules instructions from the highest priority active thread. This is Thread 1. The instruction scheduler module 600 therefore schedules instructions 1, 2 and 3 of Thread 1 for execution by the functional unit 602. However, instruction 3 of Thread 1 requires a stall (as indicated by the asterisk in the Schedule shown of the functional unit 602). The instruction scheduler module 600 therefore schedules an instruction from a lower priority active thread for execution while Thread 1 is stalling. Thus, the instruction scheduler module 600 schedules the next instruction of Thread 2, which is instruction 10 of Thread 2. Thread 2 was already partially executed at the start of this scheduling window. However, instruction 10 of Thread 2 also requires a stall (as indicated by an asterisk in the schedule of the functional unit 602). As such, the instruction scheduler module 600 schedules an instruction from Thread 3 which is the lowest priority active thread. This is instruction 27 of Thread 3. Thread 3 was also partially executed at the start of this scheduling window. While instruction 3 of Thread 1 and instruction 10 of Thread 2 remain stalled, the instruction scheduler module causes the functional unit 602 to execute instructions 27, 28 and 29 of Thread 3. However, at a certain point instruction 3 of Thread 1 is no longer stalled (for example because data has now been successfully retrieved from a main memory), and so the execution of instruction 3 of Thread 1 can be resumed and completed. The instruction scheduler module 600 identifies that instruction 3 of Thread 1 is no longer stalled, and schedules the completion of its execution, followed by the execution of instruction 4 of Thread 1.

[0033] In accordance with example implementations of the present disclosure, instruction-level scheduling may additionally or alternatively be implemented in the absence of a stall condition. In this case, the processing core 100 has multiple functional units 102 and the instruction scheduler module 112 is configured to schedule at least one instruction of a first active thread for execution by a first subset of the functional units, and then schedule at least one instruction of one or more other active threads for execution by a second subset of the functional units that would otherwise be idle.

[0034] This approach will now be described using a worked example. In this worked example, the processing core 100 has have five functional units and there are two active threads. The first active thread has four instructions, but the fourth instruction requires the same functional unit as the first instruction to be executed. The second active thread has five instructions. In this case, the instruction scheduler module 112 may be configured to schedule the first, second and third instructions of the first active thread for execution by the first, second and third functional units, respectively, and schedule the first and second instructions of the second active thread for execution by the fourth and fifth functional units, respectively.As a result of the instruction-level scheduling, instructions of the second active thread can be scheduled on the fourth and fifth functional units that would otherwise be idle.

[0035] In order to facilitate instruction-level scheduling in the ways described herein, the context manager module 604 may be configured to continually load data required to execute the next X instructions of each active thread into the shared register file 606, and may additionally be configured to remove data that is not required to execute the next X instructions of each active thread, for example by moving them to a processor memory 602.

[0036] Referring to Fig. 7, a method 700 of manufacturing a processing core in accordance with the present disclosure is shown. The method 700 comprises: providing 702 one or more functional units; providing 704 a shared register file comprising a plurality of registers, each register of the shared register file being configured to store data for executing any thread; and providing 706 a multi -thread elaboration unit, MTEU, the MTEU comprising: a control module configured to: receive an indication of a plurality of active threads for a given scheduling window; and receive instructions for each of the plurality of active threads; a context manager module configured to load, for each of the plurality of active threads, data required for executing a next one or more of the instructions into a respective one or more registers of the shared register file; and an instruction scheduler module configured to schedule the instructions of the active threads for execution based on availability of the one or more functional units.

[0037] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the implementations.

[0038] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of various implementations includes each dependent claim in combination with every other claim in the claim set. As used herein, a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiple of the same item.

[0039] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Further, as used herein, the article “the” is intended to include one or more items referenced in connection with the article “the” and may be used interchangeably with “the one or more.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, or a combination of related and unrelated items), and may be used interchangeably with “one or more.” Where only one item is intended, the phrase “only one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Also, as used herein, the term “or” is intended to beinclusive when used in a series and may be used interchangeably with “and / or,” unless explicitly stated otherwise (e.g., if used in combination with “either” or “only one of’).

[0040] Thus, from one perspective, there has now been described a processing core for executing threads. The processing core comprises: one or more functional units; a shared register fde comprising a plurality of registers, each register of the shared register fde being configured to store data for executing any thread; and a multi -thread elaboration unit, MTEU, the MTEU comprising: a control module configured to: receive an indication of a plurality of active threads for a given scheduling window; and receive instructions for each of the plurality of active threads; a context manager module configured to load, for each of the plurality of active threads, data required for executing a next one or more of the instructions into a respective one or more registers of the shared register file; and an instruction scheduler module configured to schedule the instructions of the active threads for execution based on availability of the one or more functional units.

[0041] Further examples of feature combinations taught by the present disclosure are set out in the following numbered clauses:1. A processing core for executing threads, the processing core comprising: one or more functional units; a shared register file comprising a plurality of registers, each register of the shared register file being configured to store data for executing any thread; and a multi-thread elaboration unit, MTEU, the MTEU comprising: a control module configured to: receive an indication of a plurality of active threads for a given scheduling window; and receive instructions for each of the plurality of active threads; a context manager module configured to load, for each of the plurality of active threads, data required for executing a next one or more of the instructions into a respective one or more registers of the shared register file; and an instruction scheduler module configured to schedule the instructions of the active threads for execution based on availability of the one or more functional units.2. The processing core of clause 1, wherein the control module is configured to tag a register of the shared register file with an identifier that identifies a thread to which data loaded into or to be loaded into the register belongs.3. The processing core of clause 1 or 2, comprising a shared set of general purpose registers or control registers, each general purpose register or control register of the shared set being configured to store data for managing the execution of any active thread.4. The processing core of any preceding clause, wherein: the control module is configured to determine, for each of the active threads, an execution window comprising a number X of instructions; and the context manager module is configured to continually load, for each of the plurality of active threads, data required for executing the next X instructions into the respective one or more registers of the shared register file.5. The processing core of clause 4, wherein the context manager module is configured to remove from the shared register file, for each of the plurality of active threads, data that are not required for executing the next X instructions.6. The processing core of any preceding clause, wherein the instruction scheduler module is configured to schedule the instructions of more than one of the active threads in order to reduce or minimize idle time of the one or more functional units.7. The processing core of any preceding clause, wherein the instruction scheduler module is configured to: identify that a first instruction of a first active thread requires a stall; and in response to identifying that the first instruction of the first active thread requires a stall, schedule a first instruction of a second active thread for execution.8. The processing core of clause 7, wherein the instruction scheduler module is configured to: identify that the first instruction of the first active thread that was stalled has been executed; and in response to identifying that the first instruction of the first active thread has been executed, schedule a second instruction of the first active thread for execution.9. The processing core of any preceding clause, wherein: the processing core comprises a plurality of functional units; and the instruction scheduler module is configured to: schedule at least one instruction of a first active thread for execution by a first subset of the functional units; and schedule at least one instruction of one or more other active threads for execution by a second subset of the functional units that would otherwise be idle.10. The processing core of any preceding clause, wherein: the control module is configured to receive a priority value for each of the active threads for the given scheduling window; andthe instruction scheduler module is configured to schedule the instructions of the active threads for execution based on the availability of the one or more functional units and the priority values of the active threads.11. The processing core of clause 10, wherein the instruction scheduler module is configured to schedule instructions from an active thread of a lower priority if and only if all higher priority active threads are stalling.12. A method of manufacturing a processing core, the method comprising: providing one or more functional units; providing a shared register file comprising a plurality of registers, each register of the shared register file being configured to store data for executing any thread; and providing a multi -thread elaboration unit, MTEU, the MTEU comprising: a control module configured to: receive an indication of a plurality of active threads for a given scheduling window; and receive instructions for each of the plurality of active threads; a context manager module configured to load, for each of the plurality of active threads, data required for executing a next one or more of the instructions into a respective one or more registers of the shared register file; and an instruction scheduler module configured to schedule the instructions of the active threads for execution based on availability of the one or more functional units.

Claims

WHAT IS CLAIMED IS:

1. A processing core for executing threads, the processing core comprising: one or more functional units; a shared register fde comprising a plurality of registers, each register of the shared register fde being configured to store data for executing any thread; and a multi-thread elaboration unit, MTEU, the MTEU comprising: a control module configured to: receive an indication of a plurality of active threads for a given scheduling window; and receive instructions for each of the plurality of active threads; a context manager module configured to load, for each of the plurality of active threads, data required for executing a next one or more of the instructions into a respective one or more registers of the shared register file; and an instruction scheduler module configured to schedule the instructions of the active threads for execution based on availability of the one or more functional units.

2. The processing core of claim 1, wherein the control module is configured to tag a register of the shared register file with an identifier that identifies a thread to which data loaded into or to be loaded into the register belongs.

3. The processing core of claim 1 or 2, comprising a shared set of general purpose registers or control registers, each general purpose register or control register of the shared set being configured to store data for managing the execution of any active thread.

4. The processing core of any preceding claim, wherein: the control module is configured to determine, for each of the active threads, an execution window comprising a number X of instructions; and the context manager module is configured to continually load, for each of the plurality of active threads, data required for executing the next X instructions into the respective one or more registers of the shared register file.

5. The processing core of claim 4, wherein the context manager module is configured to remove from the shared register file, for each of the plurality of active threads, data that are not required for executing the next X instructions.

6. The processing core of any preceding claim, wherein the instruction scheduler module is configured to schedule the instructions of more than one of the active threads in order to reduce or minimize idle time of the one or more functional units.

7. The processing core of any preceding claim, wherein the instruction scheduler module is configured to: identify that a first instruction of a first active thread requires a stall; and in response to identifying that the first instruction of the first active thread requires a stall, schedule a first instruction of a second active thread for execution.

8. The processing core of claim 7, wherein the instruction scheduler module is configured to: identify that the first instruction of the first active thread that was stalled has been executed; and in response to identifying that the first instruction of the first active thread has been executed, schedule a second instruction of the first active thread for execution.

9. The processing core of any preceding claim, wherein: the processing core comprises a plurality of functional units; and the instruction scheduler module is configured to: schedule at least one instruction of a first active thread for execution by a first subset of the functional units; and schedule at least one instruction of one or more other active threads for execution by a second subset of the functional units that would otherwise be idle.

10. The processing core of any preceding claim, wherein: the control module is configured to receive a priority value for each of the active threads for the given scheduling window; and the instruction scheduler module is configured to schedule the instructions of the active threads for execution based on the availability of the one or more functional units and the priority values of the active threads.

11. The processing core of claim 10, wherein the instruction scheduler module is configured to schedule instructions from an active thread of a lower priority if and only if all higher priority active threads are stalling.

12. A method of manufacturing a processing core, the method comprising: providing one or more functional units;providing a shared register file comprising a plurality of registers, each register of the shared register file being configured to store data for executing any thread; and providing a multi -thread elaboration unit, MTEU, the MTEU comprising: a control module configured to: receive an indication of a plurality of active threads for a given scheduling window; and receive instructions for each of the plurality of active threads; a context manager module configured to load, for each of the plurality of active threads, data required for executing a next one or more of the instructions into a respective one or more registers of the shared register file; and an instruction scheduler module configured to schedule the instructions of the active threads for execution based on availability of the one or more functional units.

Images