Virtual Load Store Queue Dynamic Dispatch Window
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current processor architectures face inefficiencies in handling multiple threads due to the need for context switching and the overhead of duplicating architecture state elements, which limits fine-grain parallelism and increases complexity, especially when the number of software threads exceeds hardware-supported threads.
Innovation Solution
Implementing a virtual load store queue with a dynamic dispatch window that allows out-of-order instruction scheduling, enabling the allocation and execution of loads and stores beyond physical queue limits, and facilitating speculative execution with recovery mechanisms for miss-predictions and errors.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If hardware duplicates all architecture state elements for each supported thread, then context switch is eliminated for hardware-supported threads, but area, power and complexity increase significantly
Solution Approach 1:
The processor state is segmented into multiple contexts (thread contexts, process contexts) that can be independently managed. The context switch mechanism is divided into hardware-supported fast context switching for frequently switched threads and software-managed context switching for less frequent switches, allowing selective optimization without duplicating full state for all possible contexts.
Solution Approach 2:
The patent introduces a multi-dimensional context management approach where contexts are organized in layers (hardware contexts, software contexts, process contexts) rather than a single flat structure. This allows the system to switch between hardware contexts rapidly while using software mechanisms for broader context management, effectively adding a temporal and hierarchical dimension to context switching.
2Productivity
If the number of software threads exceeds the number of hardware-supported threads, then fine-grain parallelism is enabled, but context switch must still be performed
Solution Approach 1:
The system performs preliminary context setup and management through software mechanisms before hardware context switching is needed. Thread descriptors and context information are prepared in advance in software, allowing the hardware to perform rapid switching between pre-configured contexts without incurring full context switch overhead for each thread transition.
Solution Approach 2:
A context descriptor structure acts as an intermediary between software thread management and hardware context switching. The descriptor contains essential context information that can be quickly loaded into hardware registers, serving as a buffer that reduces the frequency and cost of actual hardware context switches while supporting a large number of software threads.
3Quantity of substance
If a large number of registers are used for modern architectures, then more threads can be supported, but context switch time increases to 10's or hundreds of cycles
Solution Approach 1:
The patent extracts only the essential context information needed for rapid switching into hardware registers, while leaving less critical context data in software-managed structures. This selective extraction allows the hardware to switch contexts in fewer cycles by only loading essential register states, while other context information remains in faster-access software structures.
Solution Approach 2:
Different parts of the processor state are treated with different quality levels - frequently accessed register states are maintained in hardware with fast access, while less frequently accessed context information is stored in software structures. This local differentiation optimizes the overall context switch performance by focusing hardware resources on the most critical state elements.
Data Source
AI summary
An out of order processor. The processor includes a virtual load store queue for allocating a plurality of loads and a plurality of stores, wherein more loads and more stores can be accommodated beyond an actual physical size of the load store queue of the processor; wherein the processor allocates other instructions besides loads and stores beyond the actual physical size limitation of the load/store queue; and wherein the other instructions can be dispatched and executed even though intervening loads or stores do not have spaces in the load store queue.