Dynamic reconfiguration of a single-core processor into a multi-core processor

Abstract

A first thread executes in a first pipeline of a first core of an integrated circuit (IC). The first core includes a first set of hardware structures. In response to an instruction to operate the IC with multiple cores, the first pipeline is flushed. The first core is partitioned to obtain a second core and a third core. The first pipeline is partitioned to obtain a second pipeline and a third pipeline. The first set of hardware structures is partitioned to obtain a second set of hardware structures and a third set of hardware structures. The first thread executes on the second pipeline of the second core of the IC, where the second core includes the second set of hardware structures. A second thread executes on the third pipeline of the third core of the IC, where the third core includes the third set of hardware structures.

Description

TECHNICAL FIELDEmbodiments of the present disclosure generally relate to a processor, and more particularly, to reconfiguring a processor from a unified core to multiple cores or from multiple cores to a unified core.BACKGROUNDHigh performance central processing unit (CPU) cores often improve performance at the expense of increased chip area occupied by the CPU cores. The performance of CPU cores with respect to the size of their chip area can be improved.BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1A shows a block diagram of an integrated circuit (IC) operating two cores, in accordance with aspects and implementations of the present disclosure. FIG. 1B shows a block diagram of an IC operating a unified core, in accordance with aspects and implementations of the present disclosure. FIG. 1C shows a block diagram of an IC operating three cores, in accordance with aspects and implementations of the present disclosure. FIG. 1D shows a block diagram of an IC operating a unified core, in accordance with aspects and implementations of the present disclosure. FIG. 1E shows a block diagram of an IC including a processor configured as separate cores and a processor configured as a unified core, in accordance with aspects and implementations of the present disclosure. FIG. 2 shows a block diagram of a processor, in accordance with aspects and implementations of the present disclosure. FIG. 3 shows a block diagram of a front end of a processor, in accordance with aspects and embodiments of the present disclosure. FIG. 4 shows a block diagram of a central core of a processor, in accordance with aspects and embodiments of the present disclosure. FIG. 5 shows a block diagram of a memory subsystem of a processor, in accordance with aspects and embodiments of the present disclosure. FIG. 6 shows a flowchart of an example method for dynamically reconfiguring a processor from multiple cores to a unified core, in accordance with aspects and embodiments of the present disclosure. FIG. 7 shows a flowchart of an example method for dynamically reconfiguring a processor from a unified core to multiple cores, in accordance with aspects and embodiments of the present disclosure. FIG. 8 is a block diagram illustrating an example computer system, in accordance with aspects and embodiments of the present disclosure.DETAILED DESCRIPTIONModern CPU cores are continuously developing to extract more power through various techniques. In many cases, high-performance processing cores extract power at the expense of area and power. For example, high-performance processing cores may add additional hardware resources (e.g., execution units, caches, interconnects, etc.), increasing an overall chip area used by the processing core with decreasing performance improvements. Accordingly, some high-performance CPU cores may be inefficient with respect to power extracted per square millimeter (mm) chip area and power per watt.Conventional techniques utilize a capability known as simultaneous multi-threading (SMT) or hyper-threading to extract additional power by executing multiple processes (e.g., threads) on a single processing core. For example, a single core CPU may be capable of executing two threads using SMT techniques. However, conventional SMT techniques have a number of disadvantages and may cause design and architectural problems. For example, conventional SMT techniques dynamically allocate and allocate resources (e.g., execution units, pipeline stages, register files, etc.) between threads executing on the same processing core. Moreover, CPUs utilizing SMT may remain vulnerable to side-channel attacks that exploit such dynamic sharing and allocation of resources to effectively retrieve data that should not be accessible to other threads running on the same core.In an additional example, dynamic resource sharing implemented by conventional SMT may cause one thread (e.g., a sequence of instructions) to negatively impact performance of another thread running on the same CPU core. For example, if multiple threads contend for the same resources simultaneously, they may potentially degrade performance and introduce delays, thereby reducing overall efficiency of the CPU core.In yet another example, design complications may arise from SMT CPU cores sharing pipelines and hardware structures in a CPU core. In particular, sharing pipelines and hardware structures may result in dead locks (e.g., multiple threads that are stalled indefinitely while each is waiting for resources held by the other), live locks (e.g., multiple threads, but cannot progress due to conflicts with other threads), and starvation issues (e.g., one thread consistently uses fewer resources than another thread). Such problems can be solved by carefully designing resource allocation, thread scheduling, and dependency management. Designing such mechanisms may be a challenge and introduce considerable overhead in terms of design complexity. Accordingly, adding additional features to SMT CPU cores may be a significant impediment to CPU designers.Aspects and implementations of the present disclosure address the foregoing shortcomings and other deficiencies of conventional SMT CPU systems by providing a technique that allows a processor to dynamically reconfigure (reconfigure) between a multi-core processor (e.g., executing threads on multiple cores) and a unified (i.e., executing a single thread on a unified core). A multi-core processor may include two or more independent processing units (e.g., cores) on a single chip. Each core may independently execute a thread (e.g., a process, sequence of instructions, etc.), enabling parallel execution of multiple threads. Aspects and implementations of the present disclosure enable static partitioning of resources (e.g., hardware structures, pipelines, etc.) between the cores. In one implementation, the processor may be dynamically reconfigured as a unified core processor (also single core processor). A unified core may be a single core that performs all computing tasks of the processor by executing a single thread on the unified core. The unified core may be a union (engl. Unifying) several smaller cores. For example, the unified core may unify (unify) pipelines and hardware structures associated with multiple cores.In at least one embodiment, processor may be dynamically reconfigured from a multi-core processor (also referred to herein as "multi-core mode" or "multi-threaded mode") to a unified core processor (also referred to herein as "unified core mode" or "single-threaded mode"). For example, the processor may execute a first thread on a first pipeline in a first core of the processor and execute a second thread on a second pipeline in a second core of the processor. In response to a reconfiguration to a unified core command, the processor may flush (first and second pipelines) to prepare for merging the first core and the second core. The command may be received by system software of the processor. In at least one embodiment, command may be received from firmware such as a basic input / output system (BIOS). In at least one embodiment, command may be received from an application or other software source. In at least one embodiment, a hardware component may detect a state that causes processor to be reconfigured into a unified core. For example, the hardware component may detect that the second core has been in an inactive state for more than a threshold number of clock cycles and, as a result, cause the processor to be reconfigured into a unified core. To unify the cores, the processor may unify the first pipeline with the second pipeline to obtain a unified pipeline, and unify the first set of hardware structures with the second set of hardware structures to obtain a unified set of hardware structures. The processor may execute a single thread (e.g., an active thread) on the unified core using the unified pipeline.In some embodiments, the instruction to operate the processor with the unified core may be issued in response to a determination that the second core was inactive for more than a threshold number (e.g., 50) of clock cycles. For example, the processor may receive an instruction (e.g., a wait-to-interrupt (WFI) instruction, a HALT instruction, etc.) indicating that the second thread transitions from the processor's system software to an inactive state, causing the core (or thread executing on the core) to enter an inactive state. An inactive state means that the core is not currently executing instructions (e.g., not executing a thread) or executing tasks. This may be advantageous because unifying the core may allow a single thread to achieve higher peak performance by executing on a wider unified core rather than executing on a non-unified core of the multi-core processor. If one of the cores is inactive, this can significantly increase the performance of the remaining active thread. For example, a first thread may be executed on the first core at a rate of N instructions per cycle (N-wide), and a second thread may be executed on the second core at a rate of N instructions per cycle (N-wide). When one of the threads / cores enters an inactive state, pipelines and hardware structures may be unified to obtain a 2N-wide unified core capable of executing the remaining active thread on a unified pipeline at a rate of 2N instructions per cycle.In at least one embodiment, processor may be dynamically reconfigured from a unified core processor to a multi-core processor. For example, the processor may execute a first thread on a unified pipeline of a unified core of the processor. In response to a command to reconfigure to a multi-core processor, such as a command received from system software (e.g., an operating system (OS), hypervisor, firmware, BIOS, etc.), the processor may flush the unified pipeline to prepare partitioning of the unified core. To partition the unified core, the processor may statically partition the unified pipeline to obtain a first pipeline and a second pipeline, and partition a unified set of hardware structures of the unified core into a first set of hardware structures and a second set of hardware structures. The processor may execute a first thread on the first core and a second thread on the second core. In at least one embodiment, sets of hardware structures may include cache, translation lookaside buffers (TLBs), register files, queues, branch predictors, branch target buffers, execution units, schedulers, and the like. Statically partitioned resources (e.g., hardware structures, pipelines, etc.) may allow separate threads to operate independently on a respective core of the processor with minimal interaction and low resource sharing.In some embodiments, the instruction to operate the processor with multiple cores may be issued in response to receiving an interrupt from the system software or IC hardware indicating that a second thread is ready for execution on the processor. For example, the processor may receive an interrupt from the OS that causes an inactive thread to become active ("awake"). As the inactive thread wakes up, this can significantly increase the efficiency, throughput, and performance of the processor by allowing the processor to independently execute multiple threads on the processor in parallel. For example, a first thread may be executed on the unified core at a rate of 2N instructions per cycle (2N-wide), but may not have a workload that may exploit the entire width of the unified core. As the second thread wakes up, pipelines and hardware structures may be statically partitioned to obtain a first N-wide core and a second N-wide core that are capable of executing the first thread and the second thread, respectively, on partitioned pipelines at a rate of N instructions per cycle, and may be capable of exploiting the width of the partitioned pipeline more easily than the width of a combined pipeline. This improves overall efficiency (e.g., per area power, per watt power, etc.), throughput, and performance.Advantages of the technology disclosed herein include, but are not limited to, increased frequency of the processor by reducing critical paths of design and logic to select which thread will use which pipeline in a given cycle. This can be accomplished by statically partitioning pipelines so that each thread can be executed on an independent pipeline with minimal resource division between the threads. Such static pipeline partitions may use entire clock cycles to continue instructions, unlike conventional SMT approaches that use a portion of each clock cycle to decide which thread is running on a given pipeline for a given cycle. Additionally, static partitioning hardware structures (e.g., caches, branch predictors, etc.) Performance variability problems and safety concerns associated with conventional SMT design resource sharing are negated. For example, static partitioning of structures and pipelines may avoid deadlocks, livelock, hunger problems and other problems associated with conventional SMT due to minimal interaction and resource sharing between threads. In another example, due to minimal resource sharing and increased thread isolation, it may be difficult to orchestrate particular attacks (e.g., side channel attacks) that are typically deployed against conventional SMT designs. Thus, the technical effect of the present disclosure may additionally include a more secure multi-threaded processor that limits or prevents extraction of data (e.g., via a side-channel attack) associated with processors sharing resources between multiple threads executing on the processor. Accordingly, aspects and implementations of the present disclosure may provide flexibility of transition between executing multiple threads and a single thread on a processor while avoiding the disadvantages of conventional SMT designs.It should be noted that various aspects of the above methods and systems are described in detail hereinbelow by way of example and not limitation. The embodiments and examples provided below may relate to a dual-core processor configuration that may be reconfigured only into a unified core for simplicity and brevity. However, embodiments and examples of the present disclosure may generally be applied to multi-core processors having any number of cores and to an integrated circuit (IC) configuration having multiple multi-core processors capable of transitioning between a multi-core mode and a unified core mode. For example, when describing pipeline depths and widths for dual core embodiments, the factor two may be used for simplicity, but not by way of limitation. For N-core embodiments, the factor may be generalized to any value between 2 and N, including.FIG. 1A shows a block diagram of an integrated circuit 100 (IC 100) that operates two cores, in accordance with aspects and implementations of the present disclosure. The IC 100 may be a general-purpose computing device (a CPU, a graphics processing unit (GPU), etc.), a specialized computing device (a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), and the like. The IC 100 is also referred to herein as a processor 100 for purposes of illustration and not limitation, and it is noted that aspects and embodiments of the present disclosure may be applied to a variety of computing devices, such as those mentioned above.As shown, the IC 100 includes a core 110A and a core 110B packaged on the same chip. The core 110A and the core 110B may each include separate pipelines. The core 110A may implement a pipeline 120A and the core 110B may implement a pipeline 120B. Cores 110A and 110B and their respective pipelines may be statically shared such that each core executes a separate sequence of instructions independently in parallel. For example, core 110A may execute a first thread (e.g., a first sequence of instructions) on pipeline 120A and core 110B may execute a second thread (e.g., a second sequence of instructions) on pipeline 120B such that the first thread does not affect the second thread executed on core 110B and the second thread does not affect the first thread executed on core 110A. In an illustrative example, the core 110A may independently execute a first thread on an N-wide pipeline 120A having a bandwidth of N instructions per cycle. The core 110B may independently execute a second thread on an N-wide pipeline 120B with a bandwidth of N instructions per cycle.The core 110A includes a set of hardware structures 130A and the core 110B includes a set of hardware structures 130B. The set of hardware structures 130A and 130B may each include one or more caches (e.g., L1 caches, L2 caches, etc.), buffers (e.g., translation lookaside buffers, branch target buffers, DCache miss trackers (DCMTs), write combination buffers (WCBs), etc.), queues (e.g., load replay queues, output queues, prefetch queues, etc.), register files, branch predictors, execution units, schedulers, and the like, as described in detail below with respect to FIGS. 2, 3, and 4. As shown, hardware structures 130A and 130B disposed on IC 100 may be statically partitioned between core 110A and core 110B, respectively.FIG. 1B shows a block diagram of an IC 100 operating a unified core 110C, in accordance with aspects and implementations of the present disclosure. The unified core 110C includes a unified pipeline 120C and a set of unified hardware structures 130C. Unified pipeline 120C may be a combination of pipeline 120A and pipeline 120B, such that IC 100 may individually execute a thread on a wider pipeline than pipelines 120A and 120B. For example, core 110A may independently execute a first thread on an N-wide pipeline 120A at a rate of up to N instructions per cycle, and core 110B may independently execute a second thread on an N-wide pipeline 120B at a rate of N instructions per cycle. The unified core 110C may execute the first thread, the second thread, or any other thread on a 2N-wide unified pipeline 120C at a rate of 2N instructions per cycle.The set of unified hardware structures 130C may include one or more caches (e.g., L1 caches, L2 caches, etc.), buffers (e.g., translation lookaside buffers, branch target buffers, DCMTs, WCBs, etc.), queues (e.g., load replay queues, output queues, prefetch queues, etc.), register files, branch predictors, execution units, schedulers, and the like. The unified hardware structures 130C may include the hardware structures 130A and 130B such that the unified core 110C may utilize a complete portion of hardware structures disposed on the IC. For example, the IC 100 may include a cache (e.g., an L1 instruction cache, an L1 data cache, etc.). The unified core 110C may write / allocate (allocate), read, and otherwise access the entire cache disposed on the IC 100.In at least one embodiment, IC 100 may dynamically transition (e.g., in response to a command) from multi-core configuration illustrated with respect to FIG. 1A to unified core configuration illustrated with respect to FIG. 1B, as described in detail with respect to FIG. 6. In at least one embodiment, IC 100 may dynamically transition (e.g., in response to a command) from unified core configuration of FIG. 1B to multi-core configuration of FIG. 1A, as described in detail below with respect to FIG. 7. The IC 100 configuration of FIG. 1A is referred to herein as "multi-threaded mode", "multi-core mode", and "processor operating with two active threads", where it is to be appreciated that each refers to an IC 100 (e.g., a processor) having multiple cores configured to execute a separate thread on a respective pipeline using a respective set of hardware resources, where the pipelines and hardware structures are statically partitioned on a per-core or per-thread basis. The IC 100 configuration of FIG. 1B is referred to herein as "single thread mode", "combined core", "unified core", "super core", and "processor operating with an active thread", it being appreciated that each refers to a single unified core IC 100 (e.g., a processor) configured to execute a thread on a unified pipeline using a respective set of unified hardware structures.FIG. 1C shows a block diagram of an IC 150 operating three cores, in accordance with aspects and implementations of the present disclosure. The IC 100 includes a core 160A, a core 160B, and a core 160C packaged on the same chip. Cores 160A-C may each include separate pipelines. The core 160A may implement a pipeline 170A, the core 160B may implement a pipeline 170B, and the core 160C may implement a pipeline 170C. Cores 160A-C and their respective pipelines may be statically shared such that each core executes a separate sequence of instructions independently in parallel. Cores 160A-C may each include separate hardware structures. The core 160A includes a set of hardware structures 180A, the core 160B includes a set of hardware structures 180B, and the core 160C includes a set of hardware structures 180C. Hardware structures 180A, 180B, and 180C may be statically partitioned between core 160A, core 160B, and core 160C, respectively.FIG. 1D shows a block diagram of an IC 150 operating a unified core 160D, in accordance with aspects and implementations of the present disclosure. The unified core 160D includes a unified pipeline 170D and a set of unified hardware structures 180D. The unified pipeline 170D may be a combination of pipelines 170A-C such that the IC 100 may individually execute a thread on a wider pipeline than the pipelines 170A-C. The set of unified hardware structures 180D may be a combination of hardware structures 180A-C.The same technique of dynamically transitioning the IC 100 between two cores and a unified core may be applied to reconfiguring the IC 150 between three cores and a unified core. In at least one embodiment, aspects and embodiments of present disclosure may implement more than three cores that may be reconfigured into a unified core. For example, an IC may include four cores that may be reconfigured into a unified core. Accordingly, aspects and embodiments of the present disclosure may be generally applied to multi-core configurations capable of being reconfigured into a unified core.FIG. 1E shows a block diagram of an IC 190 that includes a processor 191A configured as a separate core and a processor 191B configured as a unified core. The processor 191A includes a core 192A and a core 192B packaged on the same processor 191A. The core 192A may include a pipeline 193A and hardware structures 194A. The core 192B may include a pipeline 193B and hardware structures 194B. Cores 192A and 192B and their respective pipelines and hardware structures may be statically shared such that each core independently executes a separate sequence of instructions in parallel. In at least one embodiment, processor 191A may be reconfigured into a unified core, in accordance with aspects and implementations of present disclosure.Processor 191B may include unified core 192C with unified pipeline 193C and unified hardware structures 194C. The unified pipeline 192C may be a combination of pipelines. The set of unified hardware structures 194C may be a combination of hardware structures. In at least one embodiment, processor 191B may be reconfigured as separate cores, in accordance with aspects and implementations of present disclosure. It should be noted that some embodiments may be extended to many (e.g., two or more) processors, such as processor 191A and processor 191B, disposed on an IC 190. The processors may be configured as a unified core or separate cores to form an IC 190 that may adapt to changing workloads.Hardware structures described herein, such as hardware structures described below with respect to FIGS. 3-5, may be partitioned according to one or more methodologies. In at least one embodiment, a subset of hardware structures may be managed using wrap points or wrap pointers. A wrap point refers to an entry within a cyclic buffer where a subsequent insertion or read into the buffer returns to the beginning of the buffer to reuse memory space. For example, hardware structures described herein may include one or more cyclic buffers, such as a reorder buffer. The ROB may be a first-in, first-out (FIFO) cyclic buffer to track out-of-order execution of instructions and ensure that instructions are withdrawn in order. In an illustrative example, when the processor operates with an active thread on the unified core, the ROB may be a cyclic queue having a head pointer and an end pointer. The oldest instruction is pointed to by the head pointer and new instructions are added to the ROB at an entry pointed to by the end pointer. When an instruction is added to the ROB 434, the end pointer proceeds to the next available entry. When an instruction is withdrawn, the head pointer proceeds to reference the next instructions in the ROB. A wrap point of the ROB may be at the end of the ROB. The wrap point of the ROB may refer to a specific location (e.g., the end of the ROB) within the ROB where the indexing of the ROB 434 is reset to the beginning. In at least one embodiment, when processor is reconfigured from multiple active threads to one active thread or from one active thread to multiple active threads, wrap points of ROBs may be modified to statically partition ROBs. For example, when the processor is reconfigured from one active thread to two active threads (such as in a dual core embodiment), head and tail pointers associated with the first thread may begin at the first entry of the ROB and go back to the first entry of the ROB at a midpoint of the ROB. Head and tail pointers associated with the second thread may begin at the midpoint of the ROB and go back to the midpoint of the ROB at the last entry of the ROB. It should be appreciated that the ROB is used herein by way of example and not limitation, it being noted that other circular structures may be similarly partitioned herein using wrapping pointers.In at least one embodiment, dynamically allocated random access structures, such as a subset of caches and / or translation lookaside buffers described herein, may be partitioned into predefined patterns (also referred to herein as "partitioned by path"). For example, if a processor operates with two active threads, an L1 instruction cache may be statically partitioned into a first partition and a second partition of equal or unequal size. When the processor is operating in a multi-threaded mode, a first thread may write and allocate (allocate) L1 instruction cache entries within the first partition, and a second thread may write and allocate (allocate) L1 instruction cache entries within the second partition. It should be appreciated that the L1 instruction cache is used herein by way of example and not limitation, it being noted that other dynamically allocated random access structures described herein may be similarly partitioned through the path.In at least one embodiment, a subset of HW structures described in previous paragraph may be configured such that multiple threads may read from entirety of subset of HW structures while operating in multi-core mode. For example, dynamically allocated random access structures (e.g., caches, TLBs, etc.) may be configured such that multiple threads may have read access. In at least one embodiment, another subset of HW structures (e.g., branch predictors, register files, etc.) may be configured such that only one associated thread may read from a corresponding partitioned portion of HW structures.For example, because the L1 instruction cache is partitioned such that multiple threads have read access, the first thread and the second thread may read in parallel from the L1 instruction cache. For example, if one of the threads fails in the L1 instruction cache, a request may be sent to a second level cache within a memory subsystem to fetch the data. In at least one embodiment, an instruction fetch unit (IFU) may be connected to memory subsystem via a single bus. In some cases, the first thread and the second thread may fail in the L1 instruction cache simultaneously, and as a result, a bus-to-memory subsystem conflict may occur. In at least one embodiment, IFU may resolve such conflicts using an arbitration scheme (e.g., round-robin arbitration) that does not allow interaction between threads. For example, if the threads simultaneously request access to the memory subsystem over the bus on a first opportunity, the IFU may assign priority to the first thread. If the threads simultaneously request access to the memory subsystem over the bus on a second occasion, the IFU 310 may assign priority to the second thread, and so on. The IFU may accordingly arbitrate access to the memory subsystem over a single shared bus in a time multiplexed manner. In at least one embodiment, IFU 310 may be connected to memory subsystem via multiple buses. For example, a first bus may be dedicated to the first thread and the second bus may be dedicated to the second thread. It should be appreciated that arbitration of request buses between caches is used herein by way of example and not limitation, and it should be appreciated that the arbitration scheme(s) described above may / may be generally applied to any buses (e.g., request buses, response buses, etc.) in which multiple components may contend for access to a shared resource.In at least one embodiment, random access structures, such as register files, may be partitioned by bank. For example, if a processor operates with an active thread, that thread may use both banks to access all registers, thereby avoiding port conflicts to different banks. When the processor operates with two active threads, each bank may be dedicated to one thread, thereby eliminating cross-thread port conflicts. This bank partitioning can be applied to other random access structures in the processor.FIG. 2 shows a block diagram of a processor 200 including a front end 210, a center core 220, and a memory subsystem 230, in accordance with aspects and implementations of the present disclosure. Processor 200 may implement pipelined processing to fetch, decode, and execute instructions from memory, as described in detail below. In at least one embodiment, processor 200 may operate in a single-threaded mode or a multi-threaded mode. When operating in a single-thread mode, processor 200 may operate a single-thread with the full width of processor 200. When operating in a multi-threaded mode, processor 200 may operate multiple threads with a reduced width. To achieve thread isolation between multiple threads, structures and data paths may be statically partitioned between the threads such that each thread processes instructions in separate pipelines.BRANCH PREDICTIONFIG. 3 shows a block diagram of a front end 210 of a processor (e.g., a processor 200), in accordance with aspects and embodiments of the present disclosure. The front end 210 of the processor (e.g., the processor 200 of FIG. 2 ) includes a branch prediction unit 320 (BPU 320) to predict whether or not a branch is taken. A branch is a type of action that changes an execution path and determines a set of instructions to be executed next. Branches may occur as a result of instructions such as conditional branches, jumps, undispensed branches, and the like. The BPU 320 may include a collection of various predictors and branch target buffers (BTBs). In at least one embodiment, each component (branch predictor, buffer, etc.) of BPU 320 may be statically partitioned according to one or more of methods described above with respect to FIG. 1E such that each thread is associated with a separate branch prediction pipeline. Accordingly, each thread may issue mispredictions, invalidate instructions, flush its corresponding BPU pipeline, issue updates, etc., without affecting the other thread. When the processor operates a single thread on a unified core, the unified core may utilize the entire BPU pipeline of the processor and the entirety of any predictor structure (predictors, BTBs, etc.).INSTRUCTION FETCHThe front end 210 includes an instruction fetch unit 310 (IFU 310) to fetch instructions from memory and provide instructions to subsequent stages of a processor (e.g., the processor 200 or the IC 100). In at least one embodiment, IFU 310 may maintain a register (referred to herein as a "program counter (PC)") to manage addresses of instructions to be executed by processor. The IFU 310 may increment the PC to refer to the next instruction to be fetched in a sequence of instructions, or update the PC based on certain instructions such as branches, jumps, and the like. In at least one embodiment, IFU 310 may fetch instructions from main memory, such as dynamic random access memory (not illustrated). In at least one embodiment, IFU 310 may retrieve instructions from other memories of a memory hierarchy. For example, the IFU 310 may fetch instructions from an L1 instruction cache 312 residing on the processor or a memory subsystem (e.g., the memory subsystem 230).In at least one embodiment, IFU 310 includes an L1 instruction cache 312 for temporarily storing frequently accessed instructions. For example, the IFU 310 may store an instruction in the L1 instruction cache 312. Instead of subsequently reading the instruction from main memory, the instruction may be fetched from the L1 instruction cache 312. The L1 instruction cache 312 may operate based on the spatial and / or temporal locality of instructions to reduce the latency associated with accessing main memory to fetch instructions.In at least one embodiment, IFU 310 includes an instruction translation lookaside buffer 314 (ITLB 314). The ITLB 314 is a hardware buffer used to cache virtual to physical address translations of instructions. The ITLB 314 stores associations between virtual instruction addresses and corresponding physical addresses associated with instructions fetched by the IFU 310. When the IFU 310 fetches an instruction from memory, the IFU 310 may first check the ITLB 314. When the IFU 310 determines that a virtual-to-physical mapping for the instruction is stored in the ITLB 314, the IFU 310 may retrieve a physical address corresponding to the instruction from the ITLB 314. If the IFU 310 determines that the virtual-to-physical mapping is not stored in the ITLB 314, the processor may retrieve the physical address from the memory subsystem. In at least one embodiment, L1 instruction cache 312, ITLB 314, and instruction fetch instruction fetch unit pipeline may generally be statically partitioned and / or unified according to one or more of methodologies described above.DECODEInstructions fetched by the IFU 310 at instruction fetch 316 are provided to a decode queue 318 for instruction decode. The processor front end 210 includes a decode queue 318 operatively coupled to receive instructions from the instruction fetch 316. The decode queue 318 may be a hardware structure (e.g., a first-in-first-out (FIFO) queue) to store instructions prior to instruction decoding. In at least one embodiment, decode queue 318 may be statically divided into a decode queue 318A and a decode queue 318N.The processor front end 210 includes decode logic 330 operatively coupled to receive instructions from the decode queue 318 and decode the fetched instructions. The instructions may be executed by execution units of the processor at a later point in the pipeline. In at least one embodiment, decode logic 330 may be statically divided into decode logic 330A and decode logic 330N. In a multi-threaded mode, decode logic 330A may decode instructions read from decode queue 318A, and decode logic 330N may decode instructions read from decode queue 318N. In a single thread mode, decode logic 330A and decode logic 330N may be unified, and the active thread and unified decode logic may decode instructions read from the unified decode queue. For example, when the processor 200 is in a multi-threaded mode, the decode logic 330A may decode instructions associated with a first thread (i.e., received from the decode queue 318A) at a rate of N instructions per cycle (N-wide). Decode logic 330N may decode instructions associated with a second thread (i.e., received from decode queue 318N) at a rate of N instructions per cycle (N-wide). When the processor 200 is operating in a single-threaded mode, the decode logic 330A and the decode logic 330N may be unified, such that the unified decode logic may decode instructions associated with the active thread at an increased rate. For example, unified decode logic decodes instructions at a rate of 2*N instructions per cycle (2*N-wide).Because decode logic 330A and 330N are statically partitioned, the first thread and the second thread may operate independently of each other when processor 200 is in a multi-threaded mode. For example, if decode logic 330A receives backpressure from a later stage of its pipeline (e.g., from a rename stage) that prevents the first thread from propagating, the second thread may continue to operate because both threads have separate data paths in instruction decode and in other stages of processor 200. The decode logic 330A and the decode logic 330N may operate in an order different from the rename stage. Decode logic 330A-N is operatively coupled to send decoded instructions to the central core 220 of the rename, execute, etc. processor. It should be appreciated that other pipelines (e.g., fetch, issue, execute, etc.) may be similarly partitioned / combined.RENAME (RENAME)FIG. 4 shows a block diagram of a center core 220 of a processor in accordance with aspects and embodiments of the present disclosure. The middle core 220 may implement rename, issue, execute, and retirement (retire) stages of a pipelined processor (e.g., IC 100, processor 200). FIG. 4 illustrates a distributed (e.g., multiple output queues) output queue topology, however, aspects and implementations of the present disclosure may employ a unified output queue topology, as described in detail below.In a rename stage 432, instructions may be received from a front end (e.g., front end 210) of the processor. During rename 432, the processor allocates physical registers to architectural registers. Architectural registers are registers specified in the instruction set architecture (ISA). In rename stage 432, portions of the processor states may be renamed with the physical copies in a register file. Registers, flags, predicates, and the like may be renamed in rename stages 432. In an illustrative example, rename stage 432 includes a general purpose register (GPR) file 436 and an extended single instruction, multiple data (SIMD), and floating (FP) register file 438 used to support SIMD and FP operations. In at least one embodiment, GPR file 436 and extended SIMD & FP register file 438 may be statically shared. For example, when the processor is operating in a multi-threaded mode, a first thread may rename, assign, etc. a first portion (e.g., half) of the physical registers of the GPR file 436 and the extended SIMD & FP register file 438, and a second thread may rename, assign, etc. a second portion (e.g., the other half) of the physical registers of the GPR file 436 and the extended SIMD & FP register file 438, write ports and read ports of the first portion of the physical registers may be dedicated to the first thread, and write ports and read ports of the second portion of the physical registers may be dedicated to the second thread, such that conflicts between the first thread and the second thread are avoided. In another example, when the processor 200 is operating in a single thread mode, the active thread may rename, assign, etc. each register of the GPR file 436 and the extended SIMD & FP register file 438.In at least one embodiment, processor may include a speculative rename table (SRT) (not illustrated) to hold speculative assignments of logical registers (e.g., ISA registers) to physical registers. In at least one embodiment, SRT state may be replicated while operating in multi-threaded mode, and associated read / write ports may be replicated per thread or statically partitioned. It should be appreciated that any structure that references architectural registers may replicate a complete set of the reference architectural register for each thread while operating in a multi-threaded mode, and associated read / write ports may be replicated or statically partitioned.In at least one embodiment, processor may include a free list (not illustrated) to manage general purpose register file 436 and / or extended SIMD & FP register file 438. During the rename stage 432 of the processor, the free list may be used to track available physical registers of the general purpose register file 436 and / or the extended SIMD & FP register file. When an instruction requests a register, the processor may check the free list to determine if there is an unused physical register that the instruction can use. In at least one embodiment, free list may be statically partitioned per thread.The rename stage 432 of the processor includes a reorder buffer (ROB) 434. After instructions are renamed, they may be sent to ROB 434 and output stage 440. The ROB 434 may track inflex instructions and decouple instruction execution from instruction retirement, thereby increasing execution unit usage. In addition, ROB 434 may handle exceptions and interrupts (interrupts). For example, if an exception is thrown, the ROB 434 may scroll un-committed instructions back and restore an architectural state of the processor 200. In addition, the ROB 434 may ensure that instructions are withdrawn in program order even if the instructions are executed out of order. Accordingly, ROB 434 may cause the architectural state of processor 200 to appear as if the instructions were executed according to program order by allowing it to execute out-of-order and set and retract in order. When instructions go through rename to send, they may be broken down into smaller units of work tracked by ROB 434. For example, a single memory instruction may be divided into a memory address operation and a memory data operation. In at least one embodiment, ROB 434 may be statically partitioned on a per-thread basis. For example, the ROB 434 may be statically partitioned using wrap points as described above.In at least one embodiment, processor 200 may include one or more checkpoints and checkpoint logic to recover from branch mispredictions, exceptions, interrupts, and other discontinuities associated with out-of-order program execution. The checkpoints may periodically (e.g., dynamically, any fixed number of clock cycles, etc.) detect an architectural state (e.g., registers, program counters, etc.) of the processor 200. When a branch mispredication, an exception, an interrupt, etc. occurs, the processor 200 may restore the architectural state of the processor 200 to a stored state according to the one or more checkpoints and restart execution from the checkpoint or restart execution from an instruction more recent than the checkpoint by advancing from the checkpoint through a protocol of renames in the ROB 434 or a page structure and restore the architectural state of the more recent point. In at least one embodiment, checkpoints may be partitioned and / or unified according to one or more implementations discussed above.DISPATCH (DISTRIBUTE)After the rename stage 432, instructions may be sent to issue queues to be issued and subsequently executed. In at least one embodiment, transmit stage of processor may be statically partitioned in a similar manner as described above with respect to decode stage. Because partitioned pipelines operate independently, cross-thread delays may be avoided and safety issues prevented, as described above. In addition, the transmit stage may be unified while operating in a single-threaded mode.OUTPUT AND EXECUTIONThe processor 200 includes an output stage 440 to select and output instructions to appropriate execution units for execution. Processor 200 includes output queues (IQs) to receive instructions that have been fetched, decoded, and transmitted. The IQs may temporarily store instructions that cannot be executed immediately due to data dependencies or resource unavailability. The primary role of the output queues is to determine which instructions are ready for execution in the next clock cycle. Aspects and implementations of the present disclosure may be applied to a variety of topologies. For example, the IQs described herein may be distributed (one IQ per execution unit), centralized (one or more for all execution units), a hybrid approach of the two (e.g., an output queue services multiple but not all execution units), or any combination of the above approaches. Accordingly, each IQ may service one or more execution units. For example, processor 200 may include one or more integer IQs 460A- 460N, each of which may service one or more single cycle or multi-cycle instruction execution pipes, such as multiply, divide, add, subtract, divide, logical (AND, OR, XOR, etc.), bit shift and branch operations that all of the general-purpose / integer registers may read or write. In at least one embodiment, processor 200 includes vector / floating point IQs 464A- 464N that may serve vector execution units (for executing vector instructions and / or floating point (FP) instructions). The processor 200 may include one or more memory IQs 466A- 466N. Each memory IQ 466 may service one or more load execution units and / or one or more load memory execution units.In at least one embodiment, one or more of IQs described above may be vertically partitioned so that each entry of a given output queue may service a thread. In an illustrative example, processor 200 may include two or more integer IQs 460, two or more vector / floating point IQs 464, and two or more memory IQs 466. When the processor 200 is operating in a multi-core mode with two active threads, the integer IQs 460 may be vertically partitioned such that each integer IQ 460 services only a particular thread. In an illustrative example, processor 200 may include integer IQs 460A, 460B, 460C, and 460N. Each entry of integer IQs 460A and 460B may service a first thread of processor 200, and each entry of integer IQs 460C and 460N may service a second thread of processor 200. When the processor 200 is operating in a single core mode with an active thread, each entry of the integer IQs 460A- 460N may service the active thread. In at least one embodiment, vector / floating point IQs 464 and memory IQs 466 may also be vertically partitioned on a per-thread basis.In at least one embodiment, one or more of IQs described above may be horizontally partitioned so that a given output queue may service multiple threads. In an illustrative example, processor 200 may include integer IQs 460A, 460B, 460C, 460D, and 460N. When the processor 200 is operating in a multi-core mode with two active threads, each of the integer IQs 460A- 460N may be horizontally partitioned such that a first portion (e.g., a first half) of the entries of each of the integer IQs 460A- 460N services a first thread and a second portion (e.g., a second half) of the entries of each of the integer IQs 460A- 460N services a second thread. In at least one embodiment, more than one picker may each service an execution unit associated with each of integer IQs 460 and dedicated per thread. A picker is a hardware component responsible for selecting instructions from a corresponding output queue for sending to a correct execution unit. For example, a first picker dedicated to the first thread may service a first execution unit associated with integer IQs 460A. A second picker dedicated to the second thread may service a second execution unit associated with integer IQs 460A. Integer IQs 460B, 460C, 460D, and 460N may be horizontally partitioned in a similar manner. In at least one embodiment, when processor 200 is operating in a single core mode with an active thread, each of integer IQs 460A- 460N, corresponding pickers, and execution units may be dedicated to active thread.In at least one embodiment, pickers corresponding to an output queue serving multiple threads may be modulated according to a predefined pattern (e.g., not affected by dynamic nature of instruction being executed). In an illustrative example, the first picker and the second picker may fetch instructions from the integer IQs 460A as described above. The first picker may be dedicated to the first thread and may serve the first execution unit, while the second picker may be dedicated to the second thread and may serve the second execution unit. Alternatively, to preserve thread isolation and avoid security issues associated with the first thread and the second thread sharing resources, the first picker and the second picker retrieving instructions from the integer IQs 460A may be modulated according to a predefined pattern. For example, the first picker may fetch instructions from the integer IQs 460A for the first thread on odd clock cycles, and the second picker may fetch instructions from the integer IQs 460A for the second thread on even clock cycles. Accordingly, resources may be time multiplexed so that dynamic instructions do not cause a behavior variance.In at least one embodiment, one or more hardware structures and corresponding data paths (e.g., output queues and corresponding execution units of a single type) may be dynamically reconfigured to be dedicated to a single thread while processor is operating in multi-core mode. For example, a first workload may execute instructions that require vector execution resources (e.g., floating point (FP) instructions) on a first thread of processor 200, while a second workload may execute other instructions that do not require vector execution resources on a second thread of processor 200. Accordingly, processor 200 may be reconfigured such that each vector / floating point IQ 464, picker, and vector execution unit (for FP calculation and vector integer calculation) is dedicated to the first thread to extract increased vector execution performance on behalf of the first workload. The dynamic reconfiguration may be triggered by a timer, detection logic, specific instruction, user input, or other similar mechanisms. In at least one embodiment, hardware may determine to dynamically reconfigure one or more hardware structures to more than one thread when it is no longer advantageous to have it dedicated to a single thread. For example, this dynamic reconfiguration to more than one thread may be determined by logic that detects that the other thread will use the relevant fabric or data path, instruction, user input, or timer.As described above, pickers may fetch instructions from a corresponding output queue for execution at a corresponding execution unit. Execution units of the processor execute operations specified by the instruction. In at least one embodiment, execution units per thread may be statically shared. In an illustrative example, the branch execution units may be statically shared per thread. When the processor is operating in a multi-threaded mode, a first set of branch execution units may correspond to a first thread and a second set of branch execution units may correspond to a second thread. The first set of branch execution units may be associated with branch predictors associated with the first thread and the second set of branch execution units may be associated with branch predictors associated with the second thread. For example, in the case of a branch misprediction associated with the first thread, a branch execution unit of the first set of branch execution units may execute a corrective action (e.g., flush the pipeline corresponding to the first thread, discard speculative executed instructions beyond the misprediction, fetch the correct branch target, send updates to a BPU corresponding to the first thread, etc.) without affecting the pipeline corresponding to the second thread. Accordingly, branch predictors may receive two mispredictions (a first misprediction associated with the first thread and a second misprediction associated with the second thread) in a same clock cycle and handle the simultaneous mispredictions in parallel. The first set of branch execution units corresponding to the first thread and the second set of branch execution units corresponding to the second thread are used herein by way of example and not limitation. Aspects and implementations of the present disclosure may generally be applied to a multi-core processor (and associated sets of branch execution units) having more than two cores that may be reconfigured into a unified core processor. In at least one embodiment, execution units may be unified such that each execution unit of processor services single active thread.To perform operations specified by issued instructions, data may be retrieved from multiple sources (e.g., a general purpose register file 436; an extended SIMD & FP register file 438; caches, such as an L1 data cache 454; a bypass network, etc.). It should be appreciated that execution units and data sources may be statically partitioned on a per-thread basis when the processor is executed in a multi-threaded mode. For example, a first set of execution units may service a first thread and its corresponding first bypass network may also be dedicated to the first thread. A second set of execution units may service a second thread and its corresponding second bypass network may also be dedicated to the second thread. Accordingly, because execution units and corresponding bypass networks are statically partitioned per thread, a given execution unit may avoid the latency associated with crossing to the other bypass network to retrieve data. In addition, partitioned execution units may be unified to service the single active thread when operating in a single thread mode.In at least one embodiment, IQ pairs and corresponding execution units may be symmetric. An IQ pair may refer to two IQ units in which, when the processor 200 is operating in a dual core configuration (two separate cores), a first IQ of the IQ pair is dedicated to a first core and a second IQ of the IQ pair is dedicated to a second core. The IQ pair may be symmetric in that the first IQ and the second IQ have the same number and type of execution units and pickers. In an illustrative example, an integer IQ 460A and an integer IQ 460B may both include two ALUs and a branch execution unit. This may ensure that the first core and the second core may both use a same amount of instruction execution resources. In at least one embodiment, an IQ pair may be asymmetric. In at least one embodiment, an IQ pair may extend to an IQ set, for example, when N>2 in an N-core embodiment.LOAD STORESThe processor includes a memory buffer 448 to decouple execution of memory instructions from binding to the memory. The memory buffer 448 may hold memory operations after they are executed to ensure a withdrawal of memory operations in order. The processor may temporarily record memory operations in the memory buffer 448 to avoid unnecessary delays. In some embodiments, the memory buffer 448 may be statically shared. For example, when the processor 200 is operating in a multi-threaded mode, the memory buffer 448 may be statically shared such that a first thread of the processor 200 may record corresponding memory operations in a first portion of the memory buffer 448 and a second thread may store corresponding memory operations in a second portion of the memory buffer 448. When the processor 200 is operating in a single thread mode, the memory buffer 448 may be unified so that the active thread may record corresponding memory operations using the entirety of the memory buffer 448.In at least one embodiment, processor may include one or more memory IQs 466 as described above. In an illustrative example, a load instruction may be received and held in load store IQ 466A. If conditions are met (e.g., dependencies are resolved, execution units are available, instruction has priority, etc.), the load instruction may be sent for execution. A load instruction may be used to fetch data from memory (e.g., L1 data cache 454) and store the data within a register file of the processor. In at least one embodiment, processor may determine additional information about load instruction, such as an instruction source, load type (signed halfword, unsigned halfword, signed word, unsigned word, byte, doubleword, etc.), load size (number of bits or bytes to be fetched from memory), and the like. In at least one embodiment, processor may include an address generation unit (AGU) (not shown) to generate virtual memory addresses for accessing data in a memory cache (e.g., L1 data cache 454) or other memory (e.g., memory subsystem 230) according to transmitted load instruction.In response to the virtual memory address corresponding to the transmitted load instruction being generated by the address generation unit, a data translation lookaside buffer 452 (DTLB 452) may be queried to determine whether a physical address corresponding to the virtual memory address generated by the address generation unit is stored within the DTLB 452. The DTLB 452 may include multiple entries, each including a virtual address and a corresponding physical address translation. When a data access occurs (e.g., due to a load instruction), the processor first queries the DTLB 452 to determine whether the address translation is readily available. In response to determining that the translation is in the DTLB 452 (a DTLB hit), the physical address may be retrieved from the DTLB 452 and the load instruction may proceed. In response to determining that the translation is not in the DTLB 452 (a DTLB error), a page table run is initiated to locate the corresponding address translation in page tables (not illustrated) and update the DTLB 452 with the corresponding address translation. In at least one embodiment, DTLB 452 may be partitioned per thread according to one or more of partitioning methodologies described above.The processor includes an L1 data cache 454. The L1 data cache 454 may store data that has been recently accessed. A memory address generated from a load instruction may be checked within the L1 data cache 454 to determine whether the requested data is stored in the L1 data cache 454. When the data is stored in the L1 data cache 454, this results in a cache hit and the data can be fetched from the data cache 454. If the data is not stored in the L1 data cache 454, this results in a cache miss and the data may be retrieved from a higher level memory, such as a memory within the memory subsystem. In some embodiments, the L1 data cache 454 may be partitioned per thread. In at least one embodiment, a partitioned L1 data cache 454 may arbitrate access to memory subsystem on a per-thread basis.Memory address (STA) instructions may follow a similar path as load instructions. For example, an AGU may generate virtual memory addresses for accessing data in a memory cache, the DTLB 452 may be queried to determine whether a physical address corresponding to the virtual memory address generated by the AGU is stored within the DTLB 452, and arbitration for entry into the load memory pipeline may be performed. After arbitration into the load memory pipeline, an entry in the memory buffer 448 may be allocated to track addresses of memory instructions currently being processed by the load memory pipeline. In at least one embodiment, processor may determine which entry of memory buffer 448 is to be written to based on thread ID of memory instruction, where entries are partitioned per thread. In at least one embodiment, in response to memory address of memory instruction being written to memory buffer 448, memory instruction may be resolved. In response to the store instruction being released, a notification may be transmitted to the ROB 434 to remove the STA instruction from the ROB 434.Memory data instructions (STD instructions) may cause memory data to be calculated from the memory instruction and stored in the memory buffer 448. The memory buffer 448 may hold data until an appropriate time to write the data to a memory (e.g., a memory subsystem). The STD instruction may be written to the memory buffer 448 before or after the corresponding STA instruction is written to the memory buffer 448 with the same SID as the corresponding STA instruction. For a given memory buffer entry 448, when data associated with a corresponding STD instruction is received, the given memory buffer 448 may be rejected from the memory buffer 448. In addition, the corresponding data stored in the memory buffer 448 may be transferred to a write combination buffer (WCB), which may combine writes to a data line before committing and writing to the memory. In at least one embodiment, pipelines and hardware structures associated with memory operations may be statically shared on a per-thread basis according to one or more of methodologies described above.In at least one embodiment, load store pipeline may include a DCache miss tracker (DCMT) (not illustrated) along a miss path of load store pipeline. The DCMT is a hardware structure that keeps track of outstanding L2 memory read requests (e.g., within the memory subsystem) that failed L1. In at least one embodiment, DCMT may be statically shared on a per-thread basis according to one or more of methodologies described above.The center core 220 includes a load buffer 444 within the load store pipeline. The purpose of the load buffer 444 is to detect memory ordering violations and ensure consistency. In at least one embodiment, load buffer 444 may prevent read-by-read data conflicts / dependencies (RAR data conflicts / dependencies) with logic referred to as ready load buffer (FLB). For example, an RAR data dependency may occur when a first load instruction causes data to be read from a memory location (e.g., a register) and a subsequent load instruction causes the same data to be read from the same memory location (e.g., the same register). Such a situation may cause a data hazard, for example, if the subsequent load instruction causes the data to be read before it is available or if the data has been modified. To prevent RAR data hazards, load buffer 444 includes FLB logic that can track outstanding load instructions that do not yet have computed addresses. For example, a first load instruction may not yet have a calculated address. Subsequent load instructions may be stored within load buffer 444 until the first load address is calculated. When the first load address is calculated, the first load address is compared with addresses of the subsequent load instructions stored in the load buffer 444. Load instructions stored in load buffer 444 with calculated addresses matching the first load address may be discarded to prevent RAR data dependency hazards.In at least one embodiment, load buffer 444 may prevent a read-to-write (RAW) data risk with FLB logic. For example, a RAW risk violation may occur when a store instruction causes data to be written to a storage location (e.g., a register) and a subsequent load instruction causes data to be read from the same storage location (e.g., the same register). Such a situation may cause a data risk violation when the subsequent load operation reads data to be stored by the write operation. For example, a RAW data hazard violation may occur when the subsequent load instruction reads from the memory location before the write instruction writes the data to the memory location. To prevent RAW data risk violations, the load buffer 444 includes FLB logic that can track completed load instructions that are more recent than one or more store instructions with addresses that are still to be calculated. For example, a first stored instruction may not yet have a calculated address. Subsequent load instructions may be stored within load buffer 444 until the memory address is calculated. When the memory address is calculated, the memory address is compared with addresses of the subsequent load instructions stored within the load buffer 444. Load instructions stored in load buffer 444 with calculated addresses matching the address of the store instruction may be discarded to prevent read-to-write data dependency hazards. In at least one embodiment, load buffer 444 and associated structures (such as memory disambiguation buffers, FLB, and the like) may be statically shared on a per-thread basis according to one or more of methodologies described above.In at least one embodiment, processor may include one or more prefetchers (not shown). Prefetchers are structures for generating predictions of data requests and retrieving data from the memory subsystem before being requested by the processor. The one or more prefetchers may speculatively issue requests to the memory subsystem according to the predictions. The prefetchers may utilize spatial locality principles (e.g., a tendency for data to be accessed together or in patterns in proximity), temporal locality (e.g., anticipation of future iterations of a loop), and the like to generate predictions. In at least one embodiment, one or more prefetchers per core may be statically shared according to one or more of methodologies described above.WRITE BACK (RETIRE)In at least one embodiment, processor may include a re-stage (write back) (also referred to herein as "commit" (commit)) (not illustrated) to update an architectural state of processor to reflect effects of executed instructions. As described above, instructions in reorder buffer (ROB) 434 may be allocated in program order and executed out-of-order. In at least one embodiment, groups of instructions may be withdrawn in program order. For example, resources associated with the oldest group of instructions may be released to allow the processor to use and continue more recent instructions. In at least one embodiment, an engine may identify oldest entries in ROB 434 to be withdrawn. Accordingly, the ROB 434 may cause the architectural state of the processor to appear as if the instructions were executed according to program order by allowing it to execute out-of-order and set / retract in order. In at least one embodiment, ROB 434 may be statically partitioned per core according to one or more of methodologies described above.In at least one embodiment, instructions may be retracted in a time-multiplexed manner by alternately retracting instructions on a per-thread basis. For example, when the processor is operating in a multi-threaded mode, N instructions associated with a first thread may be withdrawn on a first clock cycle, and N instructions associated with a second thread may be withdrawn on a second clock cycle. Instructions may be further withdrawn in such an alternating manner.In at least one embodiment, processor may include one or more checkpoints and checkpoint logic to recover from branch mispredictions, exceptions, interrupts, and other discontinuities associated with out-of-order program execution, as described above. The checkpoints may periodically (e.g., dynamically, any fixed number of clock cycles, etc.) detect an architectural state (e.g., registers, program counters, etc.) of the processor. When a branch misprediction, an exception, an interrupt, etc. occurs, the processor may restore the architectural state to a stored state according to the one or more checkpoints and restart execution from the checkpoint. In at least one embodiment, checkpoints per thread may be statically partitioned. For example, if the processor is operating in a multi-threaded mode, a first core and a second core may independently have branch mispredictions and simultaneously flush and restore a respective checkpoint. Static partitioning on a per-thread basis may help prevent one thread from taking over all resources, starving the other thread, and generally avoiding unfair (e.g., unequal) resource allocation.STORAGE SUBSYSTEMFIG. 5 shows a block diagram of a memory subsystem 230 of a processor in accordance with aspects and embodiments of the present disclosure. The memory subsystem is operatively coupled to the instruction fetch unit 310 (IFU 310) of the front end 210 and the center core 220. The IFU 310 includes an L1 instruction cache 312 and an instruction translation lookaside buffer 314 (ITLB 314) as described above with respect to FIG. 3. The center core 220 includes an L1 data cache 454 and a data translation lookaside buffer 452 (DTLB 452) as described above with respect to FIG. 4.In at least one embodiment, memory subsystem 230 includes an L2 cache 562 and a second level unified translation lookaside buffer 564 L2 (unified STLB 564). The unified STLB 564 may be shared over both data address translations (e.g., DTLB 452) and instruction address translations (e.g., ITLB 314). If the processor finds an entry ("fails") in either the DTLB 452 or the ITLB 314, the processor may initiate a request to the unified STLB 564 to determine whether the requested translation is present in the unified STLB 564. If no entry is found in unified STLB 564, a page run may be performed to fill the entry. In at least one embodiment, a page-run unit may handle page-run and may be statically partitioned and / or combined according to one or more of methodologies described above. L2 cache 562 may be shared across data (e.g., L1 data cache 454) and instructions (e.g., L1 instruction cache 312). If the processor fails in either the data cache 454 or the L1 instruction cache 312, the processor may initiate a request to the L2 cache 562 to determine whether the requested data or instruction is present in the L2 cache 562. If no entry is found in the L2 cache 562, a cache line request may be sent to a system external to the memory subsystem 230.In at least one embodiment, port access to a dedicated interface (e.g., a bus) between memory subsystem 230 and IFU 310 and between memory subsystem 230 and center core 220 may arbitrate between cores (e.g., round robin arbitration, etc.) while processor is operating with multiple cores. The L1 instruction cache 312, the LTLB 314, and the DTLB 452 and the L1 data cache 454 may arbitration for port access to respective interfaces to the memory subsystem 230. In at least one embodiment, processor may include multiple interfaces dedicated to a respective core. It should be appreciated that arbitration to access the memory subsystem 230 may include other known arbitration methods such as priority-based arbitration (e.g., the priority assigned to a thread based on thread importance, thread type, application request, etc.) or other predefined arbitration policy.RECONFIGURATIONFIG. 6 shows a flowchart of an example method 600 for dynamically reconfiguring a processor from multiple cores to a unified core, in accordance with aspects and embodiments of the present disclosure. Although shown in a particular sequence or order, the order of operations may be modified unless otherwise indicated. Thus, the illustrated embodiments should be understood as examples only, and the illustrated operations may be performed in a different order, and some operations may be performed in parallel. In addition, one or more operations may be omitted in various embodiments. Thus, not all operations are required in each embodiment.At operation 602 of method 600, a first thread is executed in a first pipeline of a first core of an integrated circuit (IC). The first core includes a first set of hardware structures. In at least one embodiment, first set of hardware structures may include hardware structures described above with respect to FIGS. 2, 3, 4, and 5. For example, the first set of hardware structures may include one or more buffers (e.g., branch target buffers of FIG. 3, instruction translation lookaside buffers 314 (ITLB 314), reorder buffers 434 (ROB 434), memory buffers 448 (SB 448), data translation lookaside buffers 452 (DTLB 452), etc.); caches (e.g., L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.); branch predictors; queues associated with various stages of the first pipeline (e.g., decode queue 318); register files (e.g., general purpose register file 436, extended SIMD & FP register file 438, etc.); Execution units (e.g., arithmetic logic units (ALUs), load / store units, vector processing (VX) units, branch execution units, etc.), and the like.At operation 604, a second thread executes in a second pipeline of a second core of the IC. The second core includes a second set of hardware structures. In at least one embodiment, second set of hardware structures may include hardware structures described above with respect to FIGS. 2, 3, 4, and 5, which are separate from first set of hardware structures. For example, the first set of hardware structures may include one or more buffers (e.g., branch target buffers of FIG. 3, LTLB 314, ROB 434, SB 448, DTLB 452, etc.); caches (e.g., L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.); branch predictors; queues (e.g., decode queue 318); register files (e.g., general purpose register file 436, extended SIMD & FP register file 438, etc.); execution units (e.g., arithmetic logic units (ALUs), load / store units, vector processing (VX) units, branch execution units, etc.), and the like.In at least one embodiment, a subset of first set of hardware structures and second set of hardware structures may share read access to a subset of hardware structures statically partitioned between first core and second core. For example, one or more caches (e.g., L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.) located on the IC may be sets of associative caches statically partitioned into a subset of cache lines or paths of the cache where each partition serves a respective core of the IC, as described above. In another example, a static partitioning of a subset hardware structure between the first core and the second core may be managed by pointers and wrap points or wrap pointers as described above.At operation 606, operations 608 and 610 are performed in response to an instruction to operate the unified core IC. In at least one embodiment, instruction to operate IC with unified core is issued in response to a determination that second thread has been in an inactive state for more than a threshold number of clock cycles. In at least one embodiment, threshold number of clock cycles may be defined by a designer of processor. For example, a designer may define the threshold number of clock cycles as 50 clock cycles before switching between modes of the processor. In at least one embodiment, threshold number of clock cycles may be a configurable parameter. For example, the threshold number of clock cycles may be configured by system software in silicon to define a parameter of a hardware component that prescribes the threshold number of clock cycles. In at least one embodiment, threshold number of clock cycles may be configured via basic input / output system (BIOS) settings, unified extensible firmware interface (UEFI) settings, device drivers, and the like. An inactive state indicates that the core is not currently executing instructions or performing computing tasks. In at least one embodiment, second core may enter inactive state in response to receiving an instruction indicating that second thread transitions to inactive state, such as a wait-to-interrupt (WFI) instruction or a suspend instruction, system software (e.g., an operating system (OS), a virtual machine, a hypervisor, firmware, etc.) of IC. The instruction instructs a core (e.g., the second core) to stop execution until the core receives an interrupt signal from the system software. When an interrupt signal is received from a hardware component, such as an interrupt controller, the core may resume execution of the instruction (also referred to herein as "wake-up").In at least one embodiment, command may be received from system software of processor. In at least one embodiment, command may be received from firmware such as a basic input / output system (BIOS). In at least one embodiment, command may be received from an application or other software source. In at least one embodiment, a hardware component may detect a state that causes processor to be reconfigured into a unified core. For example, the hardware component may detect that the second core has been in an inactive state for more than a threshold number of clock cycles and, as a result, cause the processor to be reconfigured into a unified core, as described above.In at least one embodiment, command to operate IC with unified core is issued in response to a determination that first core has reached an interruptible point. In at least one embodiment, an interruptible point may indicate that first core is in a state that enables reconfiguration of pipelines and structures. An interruptible point is a specific point within execution of a sequence of instructions that the first core may be interrupted while maintaining a program state of the first core.In some embodiments, prior to merging the first core and the second core, the first pipeline and / or the second pipeline may be emptied. For example, to empty the first pipeline, instructions currently present in the first pipeline may be emptied. To flush instructions currently present in the first pipeline, instructions at various stages of the first pipeline may be deleted or invalidated to prevent execution of instructions that have been fetched and executed only partially. In at least one embodiment, flushing may be initiated by a flushing unit to ensure instructions that have not yet been specified or flushed are flushed from first pipeline. In at least one embodiment, a subset of first set of data structures may be emptied. For example, out-of-order execution structures, such as reorder buffer 434, may be flushed to discard instructions from the first pipeline that have been flushed. In at least one embodiment, BTBs and register files (e.g., general purpose register file 436, extended SIMD & FP register file 438) may be emptied. In at least one embodiment, data stored in another subset of first set of data structures may be maintained (e.g., not emptied). For example, the processor may refrain from flushing caches (e.g., L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.) and translation lookaside buffers (e.g., ITLB 314, DTLB 452, unified STLB 564, etc.). In at least one embodiment, register files and rename, micro-architectural, and / or architectural states may be stored before flushing to ensure that state may be restored before resuming execution of first thread.At operation 608, the first core is unified with the second core to obtain a unified core. The first pipeline is unified with the second pipeline to obtain a unified pipeline, and the first set of hardware structures is unified with the second set of hardware structures to obtain a unified set of hardware structures. In at least one embodiment, to unify first set of hardware structures with second set of hardware structures, IC may be reconfigured to allow unified core to assign (allocate) entries to first set of hardware structures and second set of hardware structures. The first and second sets of hardware structures may be unified according to one or more of the methodologies described above.In at least one embodiment, stages of first pipeline and second pipeline may be unified to obtain a unified pipeline in which unified core may operate. Accordingly, the unified pipeline may execute the active thread with an increased bandwidth compared to the first pipeline executing a first thread and the second pipeline executing a second thread. For example, prior to transitioning to the unified core, the IC may operate the first pipeline in the first core of the IC in parallel (referred to as N-wide) at a maximum bandwidth of N instructions per clock cycle, and may operate an N-wide second pipeline in the second core of the IC. The pipeline stages (e.g., fetch, decode, rename, etc.) of the first core and the second core may be unified such that the IC may operate the unified pipeline in the unified core with a full width of the IC. For example, the N-wide pipeline of the first core and the second core may be unified into a unified pipeline, so that the IC may operate a 2N-wide unified pipeline in the unified core.In at least one embodiment, method further includes storing an architectural state, a micro architectural state, and / or a rename state (referred to herein generally as "state") of first core and second core in a page structure of IC and restoring state of first core to (or even on) unified core in response to unifying first core and second core. In an illustrative example, a renamed state of the first and second cores may be stored and restored. The rename state or renamed architectural state may refer to values stored in physical registers (e.g., general purpose register file 436, extended SIMD & FP register file 438, control registers, special purpose registers, etc.) allocated to a particular core. Physical registers allocated to store the rename state of an inactive thread of the second core may be enabled to allow the active thread (e.g., the thread operating on the unified core) to access the physical register previously used by the inactive thread of the second core. To enable full use of the physical registers of the IC, values (referred to herein as "rename state") associated with the physical registers allocated to the inactive thread of the free second core may be stored in a page structure (e.g., a special storage element or special registers for storing the rename state) and restored when the inactive thread wakes up at a later time. In at least one embodiment, special registers for storing stored rename state may be accessed via a special register access bus.In response to unifying the first core and the second core, the renamed state of the first core may be restored to the unified core to execute the active thread on the unified core. It should be appreciated that storing and restoring rename states may be implemented by processing logic that may include hardware (e.g., a state machine), software (e.g., instructions executing on the IC), firmware, or a combination thereof.At operation 610, a single thread, such as the first thread, is executed in the unified pipeline of the unified core using the unified set of hardware structures.FIG. 7 shows a flowchart of an example method 700 for dynamically reconfiguring a processor from a unified core to multiple cores, in accordance with aspects and embodiments of the present disclosure. Although shown in a particular sequence or order, the order of operations may be modified unless otherwise indicated. Thus, the illustrated embodiments should be understood as examples only, and the illustrated operations may be performed in a different order, and some operations may be performed in parallel. In addition, one or more operations may be omitted in various embodiments. Thus, not all operations are required in each embodiment.At operation 702 of method 700, a first pipeline operates in a first core of an integrated circuit (IC), such as IC 100 of FIG. 1. In at least one embodiment, first set of hardware structures may include hardware structures described above with respect to FIGS. 2, 3, 4, and 5. For example, the first set of hardware structures may include one or more buffers (e.g., branch target buffers of FIG. 3, instruction translation lookaside buffers 314 (ITLB 314), reorder buffers 434 (ROB 434), memory buffers 448 (SB 448), data translation lookaside buffers 452 (DTLB 452), etc.); caches (e.g., L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.); branch predictors; queues associated with various stages of the first pipeline (e.g., decode queue 318); register files (e.g., general purpose register file 436, extended SIMD & FP register file 438, etc.); Execution units (e.g., arithmetic logic units (ALUs), load / store units, vector processing (VX) units, branch execution units, etc.), and the like.At operation 704, operations 706, 708, and 710 are performed in response to an instruction to operate the multi-core IC. In at least one embodiment, instruction to operate IC with multiple cores is issued in response to a determination that second thread is ready for execution on IC. In at least one embodiment, second thread is prepared for execution on IC in response to receiving an interrupt from a hardware component (e.g., an interrupt controller) of IC. For example, the second thread may be in an inactive state due to a prior receipt of an instruction, such as a wait-to-interrupt (WFI) instruction or a suspend instruction from the OS. The second thread may then receive an interrupt from the OS causing the second thread to resume execution of instructions (e.g., "wake up") on the IC.In at least one embodiment, command to operate IC with multiple cores is issued in response to a determination that first core (e.g., unified core) has reached an interruptible point. An interruptible point is a specific point within execution of the first thread that the first core may be interrupted while maintaining a program state of the first core.In some embodiments, the first pipeline is emptied before reconfiguring the IC for operation with multiple cores. To flush the first pipeline, instructions currently present in the first pipeline may be flushed. To flush instructions currently present in the first pipeline, instructions in various states of the first pipeline may be deleted or invalidated to prevent execution of instructions that have been fetched and executed only partially. In at least one embodiment, flushing may be initiated by a flushing unit to ensure instructions that have not yet been specified or flushed are flushed from first pipeline. In at least one embodiment, a subset of first set of data structures may be emptied. For example, out-of-order execution structures, such as reorder buffer 434, may be flushed to discard instructions from the first pipeline that have been flushed. In at least one embodiment, branch target buffers and register files (e.g., general purpose register file 436, extended SIMD & FP register file 438) may be flushed. In at least one embodiment, data stored in another subset of first set of data structures may be maintained (e.g., not emptied). For example, the processor may refrain from flushing caches (e.g., L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.) and translation lookaside buffers (e.g., ITLB 314, DTLB 452, unified STLB 564, etc.).At operation 706, the first core (e.g., unified core 110C) is partitioned to obtain a second core (e.g., core 110A) and a third core (e.g., core 110B). To partition the first core, the first pipeline may be partitioned to obtain a second pipeline and a third pipeline, and the first set of hardware resources may be partitioned to obtain a second set of hardware resources and a third set of hardware resources. In at least one embodiment, to partition first set of hardware structures with second set of hardware structures, IC may be reconfigured to prevent second core from assigning to third set of hardware structures and prevent third core from assigning to second set of hardware structures. Accordingly, the second core and the third core may have exclusive access to the second set of hardware structures and the third set of hardware structures, respectively. Partitioning of hardware structures and pipelines may be performed according to one or more of the methodologies described above.In at least one embodiment, stages of first pipeline may be partitioned to obtain a second pipeline and a third pipeline in which second core and third core, respectively, may operate. For example, prior to transitioning to multi-cores, the IC may operate the first pipeline in the first core (e.g., the unified core) of the IC in parallel (e.g., 2N-wide) with a maximum bandwidth of 2N instructions per clock cycle. The pipeline stages (e.g., fetch, decode, rename, etc.) of the unified core may be partitioned such that the IC may operate multiple independent pipelines in parallel. For example, the 2N-wide pipeline stages of the unified core may be partitioned such that the IC may independently execute threads on two separate N-wide pipelines.In some embodiments, the IC may be partitioned into a multi-core configuration with more than two cores. For example, stages of the first pipeline may be partitioned to obtain four separate pipelines within which four cores may each operate within a four-core configuration. The pipeline stages of the unified core may be partitioned such that the IC may operate four independent pipelines in parallel. For example, the N-wide pipeline stages of the unified core may be partitioned such that the IC may independently execute threads on four separate N / 4-wide pipelines.In at least one embodiment, method further includes storing an architectural state, a micro architectural state, and / or a rename state of first core in a page structure of IC, and restoring rename state of first core to (dt., also on) second core in response to partitioning first core. In some embodiments, the state may be stored before reconfiguration to multiple cores and restored after reconfiguration to multiple cores. For example, values (referred to herein as "state") associated with the physical registers of the first core may be stored in a page structure (e.g., a special storage element or special registers for storing the rename state) and restored to the second core after reconfiguration from a unified core to multiple cores. In some embodiments, an architectural state, a microarchitectural state, and / or a rename state associated with the second thread may be restored to the third core (dt., also on the) after reconfiguration from the unified core to multiple cores. In at least one embodiment, second thread architectural state, microarchitectural state, and / or rename state may have been previously stored in page structure in response to entering an inactive state. It should be appreciated that storing and restoring rename states may be implemented by processing logic that may include hardware (e.g., a state machine), software (e.g., instructions executing on the IC), firmware, or a combination thereof.At operation 708, the first thread executes on the second pipeline of the second core of the IC, where the second core includes the second set of hardware structures.At operation 710, the second thread executes on the third pipeline of the third core of the IC, where the third core includes the third set of hardware structures.FIG. 8 is a block diagram illustrating an example computer system 800 in accordance with aspects and embodiments of the present disclosure. The IC 100 described with respect to FIG. 1 may operate within the computer system 800. The computer system 800 may operate in the capacity of a server or endpoint machine in an endpoint server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a television, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Although only a single machine is illustrated, the term "machine" is also intended to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.The example computer system 800 includes a processing device (processor) 802, a main memory 804 (e.g., read only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), dual data rate (DDR SDRAM) or DRAM (RDRAM), etc.), a static memory 806 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 818 that communicate with each other via a bus 840. In at least one embodiment, processor 802 may be one of IC 100 of FIG. 1 or processor 200 of FIG. 2.The processor (processing device) 802 represents one or more general purpose processing devices, such as a microprocessor, a central processing unit, or the like. In particular, processor 802 may be a complex instruction set microprocessor (CISC), a reduced instruction set microprocessor (RISC), a very long instruction word microprocessor (VLIW), or a processor implementing other instruction sets, or processors implementing a combination of instruction sets. The processor 802 may also be one or more special-purpose processing devices, such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. Processor 802 is configured to execute instructions 826 for executing the operations discussed herein.The computer system 800 may further include a network interface device 808. The computer system 800 may also include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an input device 812 (e.g., a keyboard, an alphanumeric keyboard, a motion sensing input device, a touch screen), a cursor control device 814 (e.g., a mouse), and a signal generation device 818 (e.g., a speaker).The data storage device 816 may include a non-transitory machine readable storage medium 824 (also referred to as a non-transitory computer readable storage medium) having stored thereon one or more sets of instructions 826 embodying one or more of the methodologies or functions described herein. The instructions may also reside, completely or at least partially, in the main memory 804 and / or in the processor 802 during execution thereof by the computer system 800, wherein the main memory 804 and the processor 802 also form machine readable storage media. The instructions may be further transmitted or received over a network 830 via the network interface device 808.In one implementation, the instructions 826 include instructions to reconfigure a unified core processor to a multi-core processor or to reconfigure a multi-core processor to a unified core processor. Although the computer readable storage medium 824 (machine readable storage medium) is shown as a single medium in an example implementation, the terms "computer readable storage medium" and "machine readable storage medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) that store the one or more sets of instructions. The terms "computer-readable storage medium" and "machine-readable storage medium" are also intended to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the machine and that cause the machine to perform one or more of the methodologies of the present disclosure. The terms "computer readable storage medium" and "machine readable storage medium" are accordingly intended to include, but are not limited to, solid state memories, optical media, and magnetic media.Reference throughout this specification to "one implementation," "one embodiment," or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the implementation and / or embodiment is included in at least one implementation and / or embodiment. Thus, the occurrence of the phrase "in one implementation" or "in one implementation" at various places in this specification may refer to the same implementation as circumstances require, but is not necessarily required. Further, the particular features, structures, or characteristics may be combined in any suitable manner in one or more implementations.To the extent that the terms "includes," "including," "has," "includes," variants thereof, and other similar words are used in either the detailed description or the claims, these terms are intended to be inclusive, in a manner similar to the term "comprising," as an open-ended transition word without excluding additional or other elements.As used in this application, the terms "component", "module", "system", or the like are generally intended to refer to a computer-related entity, either hardware (e.g., a circuit), software, a combination of hardware and software, or an entity that refers to an operating machine having one or more specific functionalities. For example, a component may be, but is not limited to, a process running on a processor (e.g., a digital signal processor), a processor, an object, an executable, a thread of execution, a program, and / or a computer. For purposes of illustration, both an application running on a controller and the controller may be a component. One or more components may be in a process and / or execution thread, and one component may be on one computer and / or distributed between two or more computers. Further, a "device" may be in the form of specially designed hardware; generalized hardware specialized by execution thereon of software that enables the hardware to perform specific functions (e.g., generating points of interest and / or descriptors); software on a computer readable medium; or a combination thereof.The above-mentioned systems, circuits, modules, and so forth have been described with respect to interaction between multiple components and / or blocks. It should be appreciated that such systems, circuits, components, blocks, and so forth may include these components or specified subcomponents, some of the specified components or subcomponents, and / or additional components, and according to various permutations and combinations of the foregoing. Subcomponents may also be implemented as components communicatively coupled to other components rather than being included in parent components (hierarchical). Additionally, it should be noted that one or more components may be combined into a single component that provides aggregated functionality, or may be divided into multiple separate subcomponents, and any one or more middle layers, such as a management layer, may be provided to be communicatively coupled to such subcomponents to provide integrated functionality. Any components described herein may also interact with one or more other components not specifically described herein, but known to those skilled in the art.Moreover, the words "example" or "example" are used herein to serve as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the words "example" or "example" is intended to represent concepts in a particular manner. That is, unless otherwise specified or clear from context, "X uses A or B" is intended to mean any of the natural inclusive permutations. That is, when X uses A; X uses B; or X uses both A and B, then "X uses A or B" is satisfied under any of the above cases. Moreover, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless otherwise specified or clear from context to be directed to a singular form.

Claims

A method of operating an integrated circuit (IC), the method comprising: executing a first thread on a first pipeline of a first core of the IC, the first core comprising a first set of hardware structures; and responsive to an instruction to operate the IC with multiple cores: partitioning the first core to obtain a second core and a third core, wherein partitioning the first core comprises partitioning the first pipeline to obtain a second pipeline and a third pipeline, and partitioning the first set of hardware structures to obtain a second set of hardware structures and a third set of hardware structures; executing the first thread on the second pipeline of the second core of the IC, the second core comprising the second set of hardware structures; and executing a second thread on the third pipeline of the third core of the IC, the third core comprising the third set of hardware structures.The method of claim 1, further comprising issuing the instruction to operate the multi-core IC in response to determining that one or more additional threads are prepared for execution on the IC.The method of claim 2, wherein the second thread is ready for execution on the IC in response to receiving an interrupt from the IC.The method of any preceding claim, further comprising: storing an architectural state and / or a micro architectural state of the first core in a page structure of the IC; restoring the architectural state and / or the micro architectural state of the first core to the second core in response to partitioning the first core; and restoring an architectural state and / or a micro architectural state associated with the second thread to the third core.The method of any preceding claim, further comprising flushing the first pipeline in response to the instruction to operate the multi-core IC.The method of claim 5, wherein flushing the first pipeline comprises flushing instructions currently present in the first pipeline and / or flushing one or more hardware structures of the first set of hardware structures.The method of any preceding claim, wherein partitioning the first set of hardware structures to obtain the second set of hardware structures and the third set of hardware structures comprises modifying wrapping pointers associated with the first set of hardware structures such that the first thread can allocate to the second set of hardware structures and the second thread can allocate to the third set of hardware structures.The method of any preceding claim, wherein partitioning the first set of hardware structures to obtain the second set of hardware structures and the third set of hardware structures comprises preventing the second core from assigning to the third set of hardware structures and preventing the third core from assigning to the second set of hardware structures.The method of any preceding claim, wherein the second set of hardware structures and the third set of hardware structures each comprise one or more caches, translation lookaside buffers (TLBs), register files, queues associated with different stages of the first pipeline and the second pipeline, respectively, branch predictors, branch target buffers, execution units, prefetchers, and schedulers.The method of any preceding claim, further comprising: determining that the first thread has not used one or more hardware structures of the second set of hardware structures and corresponding data paths for a predetermined amount of time; and in response to the determination, reconfiguring the one or more hardware structures and corresponding data paths to be usable by the second thread.The method of claim 10, wherein the one or more hardware structures and corresponding data paths include vector issue and execution resources associated with the IC.A processor comprising a first core, the first core corresponding to a first pipeline and a first set of hardware structures, the processor to: execute a first thread on the first core; and in response to an instruction to operate the processor with multiple cores: partition the first core to obtain a second core and a third core, the second core comprising a second pipeline and a second set of hardware structures, and the third core comprising a third pipeline and a third set of hardware structures; execute the first thread on the second pipeline of the second core; and execute a second thread on the third pipeline of the third core.The processor of claim 12, wherein the instruction to operate the processor with multiple cores is issued in response to a determination that one or more additional threads are prepared for execution on the processor.The processor of claim 13, wherein the second thread is prepared for execution on the processor in response to receiving an interrupt from the processor.The processor of any of claims 12 to 14, wherein the processor is further configured to: store an architectural state and / or a micro architectural state of the first core in a page structure of the processor; restore the architectural state and / or the micro architectural state of the first core to the second core; and restore an architectural state and / or a micro architectural state associated with the second thread to the third core.The processor of any of claims 12 to 15, wherein the processor is further configured to flush the first pipeline in response to an instruction to operate the processor with multiple cores.The processor of claim 16, wherein to flush the first pipeline, the processor is configured to flush instructions currently present in the first pipeline and / or one or more hardware structures of the first set of hardware structures.The processor of any of claims 12 to 17, wherein to partition the first core to obtain a second core and a third core, the processor is configured to modify wrapping pointers associated with the first set of hardware structures such that the first thread may assign to the second set of hardware structures and the second thread may assign to the third set of hardware structures.The processor of any of claims 12 to 18, wherein to partition the first core to obtain the second core and the third core, the processor is configured to prevent the second core from assigning to the third set of hardware structures and to prevent the third core from assigning to the second set of hardware structures.A system, comprising: a memory subsystem; and a processing device coupled to the memory subsystem, the processing device configured to: execute a first thread on a first pipeline of a first core of the processing device, the first core comprising a first set of hardware structures; and in response to a command to operate the processing device with multiple cores: partition the first core to obtain a second core and a third core, wherein to partition the first core, the processing device is configured to partition the first pipeline to obtain a second pipeline and a third pipeline and partition the first set of hardware structures to obtain a second set of hardware structures and a third set of hardware structures; executing the first thread on the second pipeline of the second core of the processing device, the second core comprising the second set of hardware structures; and executing a second thread on the third pipeline of the third core of the processing device, the third core comprising the third set of hardware structures.

Images