Single instruction stream multithreaded microarchitecture

Abstract

The application provides a single instruction stream multi-fiber micro-architecture, which comprises a fiber front end and an execution back end; the fiber front end comprises a first instruction cache component, an instruction fetching component, a decoding component, a second instruction cache component, a scoreboard component, an instruction transmitting component and a fiber stack; and the execution back end comprises an operand collecting component and an instruction processing unit. The single instruction stream multi-fiber micro-architecture of the application realizes concurrent execution of asynchronous data streams, effectively improves resource utilization and eliminates redundant calculation.

Description

Technical Field

[0001] This invention relates to the technical field of dataflow architecture, and in particular to a Single Instruction Multiple Fiber (SIMF) microarchitecture. Background Technology

[0002] Currently, computer technology is constantly developing and making breakthroughs in natural language and vision processing, information retrieval, and personalized recommendations, placing higher demands on the performance, power consumption, and ease of use of computer systems. The current general-purpose Central Processing Unit (CPU) mainly adopts the von Neumann control-flow architecture, and its performance is gradually reaching saturation. In classic out-of-order execution CPUs, the power consumption for computation accounts for only 6%, while the overhead for instruction scheduling is close to 50% of the total power consumption. To address this, NVIDIA's general-purpose Graphics Processing Unit (GPU) employs a multi-threaded concurrent scheduling method, greatly reducing the instruction overhead in the von Neumann architecture, and improving the power consumption of the computation section by more than 20%.

[0003] Furthermore, with the rapid development of artificial intelligence (AI) technology, processors have shifted from general-purpose architectures to domain-specific architectures, such as Google's Tensor Processing Unit (TPU) for deep learning and NVIDIA's TensorCore integrated on top of GPUs. TensorCore focuses on General Matrix Multiply (GEMM) operations, offering 8 to 16 times faster processing speeds compared to traditional Compute Unified Device Architecture (CUDA) cores. Depending on the configured shape and data type (e.g., 16×16×16, 8×32×16, 32×8×16), TensorCore loads input data at the warp level and simultaneously performs computations using a large number of Arithmetic Logic Units (ALUs). This method of executing tasks in parallel across multiple warps is widely used for deep neural network workloads much larger in scale than TensorCore supports.

[0004] Taking GEMM applications as an example, NVIDIA libraries such as CUTLASS and CUBLAS employ a two-level block partitioning algorithm, dividing the entire GEMM into multiple sub-GEMMs in two stages. First, the original GEMM is decomposed into sub-GEMMs (TB-GEMMs) allocated to thread blocks (TBs). Subsequently, warps within a TB are further decomposed into TB-GEMMs, with each warp calculating a smaller sub-GEMM (warp-GEMM). After each TB completes its allocated TB-GEMMs, the entire GEMM is finally completed by accumulating and concatenating the results.

[0005] Streaming Multiprocessors (SMs) are the basic processing units of NVIDIA GPUs. Since the Volta architecture, each SM consists of four Processing Blocks (PBs), each with its own independent scheduler unit, functional units, and register file (RF). Thread groups within the same PB share these modules, but thread groups between different PBs cannot share them. Research suggests that the Turing architecture's scheduler follows a mapping rule of scheduler_id = warp_id % 4, indicating that the index of a thread group can statically determine its assigned PB.

[0006] Figure 1 The diagram shows the SM structure and its data mapping for executing an example GEMM (256×64×K) on the Tensor Core. Each numbered box in matrices A and B corresponds to a row (16×K) in matrix A and a column (K×16) in matrix B. The basic computational unit of the Tensor Core is assumed to be (16×16×16). The amount of data imported into the RF by each thread group in its allocated PB, and the repetition of this data in the RF, indicate that the data in matrix A is loaded four times in the same RF.

[0007] In the single-instruction, multi-threaded execution mode of GPUs, because each thread group processes data through its unique logical register number, PowerBuilder (PB) cannot identify duplicate data, leading to inefficiency. Currently, CUDA libraries and applications often use shared memory as a solution, allowing thread groups within a terabyte (TB) to quickly access on-chip resources. This method accumulates partial results by loading small blocks of matrices A and B into shared memory. However, since the amount of data stored in shared memory is much smaller than the size of a large-scale GEMM matrix, the time interval between data loading and computation is short, and the number of simultaneously scheduled thread groups is limited, resulting in poor latency hiding. Therefore, how to utilize limited shared memory space becomes a critical design issue. This burden can be alleviated when applying register renaming schemes. For example, in... Figure 1In this context, the blocks of matrix A can be fully reused, effectively replacing the role of shared memory. However, the segments of matrix B (such as 0, 1, 2, and 3 in the orange box) are distributed across the register files of all power banks (PBs), and register renaming schemes are only effective within a single PB, failing to address data duplication issues across PBs. Therefore, shared memory should only be used for the parts that register renaming cannot resolve, thus making more efficient use of the limited shared memory capacity while eliminating duplicate data generated by other PBs.

[0008] The L1 cache is the innermost cache level in the CPU cache hierarchy, belonging to the Level 1 cache. While the L1 cache can potentially help reduce memory access latency, studies have shown its inefficiency to be low. In multiple tests with GEMM matrix sizes ranging from 512 to 4096, the average L1 cache hit rate was only 26.5%, far below expectations. The main reasons for the low L1 cache hit rate include: segments of matrix A and B may share the same cache line, thus interfering with cache hits; and as the matrix size increases, the address spacing between adjacent rows or columns increases, potentially leading to collisions and misses.

[0009] In GPU architecture, the Single Instruction Multiple Thread (SIMT) model provides a higher level of concurrency, allowing programmers to launch a large number of concurrent threads using simple syntax extensions, building upon sequential thinking, thus fully utilizing the hardware's computing potential. The GPU's abstract machine model not only simplifies the programming process but also enhances the architecture's applicability and versatility, leading to its use far exceeding that of CPUs in emerging computing applications. However, in the traditional SIMT model, each thread has its own independent register file and execution path. Even if multiple threads execute the same instructions and access the same or regularly distributed memory addresses, they still need to perform address calculations and resource allocation independently. This design leads to a double waste of computational and register resources. On the one hand, multiple threads repeatedly perform the same or similar address calculations, causing redundant computational overhead; on the other hand, each thread exclusively occupies a register file, resulting in inefficient use of register resources. Summary of the Invention

[0010] In view of the above-mentioned problems, the purpose of this invention is to provide a single-instruction-stream multi-fiber microarchitecture that can realize the concurrent execution of asynchronous data streams, effectively improve resource utilization, and eliminate redundant calculations.

[0011] This invention provides a single-instruction-stream multi-fiber microarchitecture, comprising a fiber frontend and an execution backend. The fiber frontend includes a first instruction cache component, an instruction fetch component, a decoding component, a second instruction cache component, a scoreboard component, an instruction issue component, and a fiber stack. The first instruction cache component stores instructions. The instruction fetch component retrieves the instruction from the first instruction cache component when an idle fiber group is detected. The decoding component decodes the instruction. The second instruction cache component stores the decoded instruction. The scoreboard component handles write-after-write and write-after-read hazards of the decoded instruction. The instruction issue component issues the decoded instruction from the second instruction cache component. The fiber stack resolves branching for each fiber group. The execution backend includes an operand collection component and an instruction processing unit. The operand collection component stores corresponding instruction operands based on the decoded instruction. The instruction processing unit executes the decoded instruction based on the instruction operands.

[0012] In one implementation of the present invention, one thread corresponds to one fiber group, and each fiber group is set with an independent program counter.

[0013] In one implementation of the present invention, when a fiber group does not have any valid instructions in the second instruction cache component, the fiber group is determined to be idle.

[0014] In one implementation of the present invention, each entry of the second instruction cache component is divided into a preset number of parts of equal length, and each part is used to store the instruction corresponding to a fiber group; the preset number is the ratio of the maximum number of fibers to the number of fibers in the fiber group.

[0015] In one implementation of the present invention, the instruction issuing component determines the issuing order of the decoded instructions through a scheduler.

[0016] In one implementation of the present invention, a fiber stack corresponds to a fiber group. When the next program counter of the top entry of the fiber stack is not equal to the program counter of the current instruction, a branching is determined to have occurred.

[0017] In one implementation of the present invention, the entries of the scoreboard component are of fixed length, and each entry is used to record all registers corresponding to an operand required for an instruction and whether the registers are ready.

[0018] In one implementation of the present invention, the storage content of the operand collection component includes instruction name, fiber group ID, start register, and operand; each fiber group corresponds to a preset number of consecutive registers, and the register corresponding to each instruction is obtained according to the start register and the fiber group ID to read the operand from the register.

[0019] In one implementation of the present invention, the operand collection component and the instruction processing unit communicate in a one-to-one correspondence.

[0020] In one implementation of the present invention, the instruction processing unit includes a stream processor pipeline, a special function unit pipeline, and a memory pipeline; the stream processor pipeline is used to execute arithmetic logic instructions; the special function unit pipeline is used to execute special instructions; and the memory pipeline is used to execute memory access instructions.

[0021] As described above, the single-instruction-stream multi-fiber microarchitecture of the present invention has the following beneficial effects:

[0022] (1) Concurrent execution of asynchronous data streams was achieved through a single instruction stream multi-fiber microarchitecture;

[0023] (2) It improves resource utilization efficiency, eliminates redundant calculations, enhances overall performance, and brings new solutions to the field of parallel computing.

[0024] (3) It solves the problems of redundant address calculation, waste of register resources, static parallelism and inability to reuse resources between the Kernel in the SIMT architecture. Attached Figure Description

[0025] Figure 1 The diagram shows a mapping schematic of the general matrix multiplication in a streaming multiprocessor in one embodiment of the prior art.

[0026] Figure 2 The diagram shown is a structural schematic of the single-instruction-stream multi-fiber microarchitecture of the present invention in one embodiment.

[0027] Figure 3 The diagram shown is an architectural schematic of a single-instruction-stream multi-fiber microarchitecture of the present invention in one embodiment. Detailed Implementation

[0028] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0029] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0030] The single-instruction-stream multi-fiber microarchitecture of this invention introduces a fiber, a more lightweight concurrent execution unit than a thread, further refining the smallest unit of concurrency, resulting in smaller context information and lower resource overhead. This single-instruction-stream multi-fiber microarchitecture solves the problems of redundant address calculations, wasted register resources, static parallelism, and the inability to reuse resources between the kernel and the architecture inherent in SIMT. It not only reduces hardware overhead but also avoids data redundancy, improving overall efficiency.

[0031] The technical solutions of the present invention will now be described in detail with reference to the accompanying drawings.

[0032] A fiber is a user-mode lightweight thread, a type of coroutine implementation. Fibers have the following core characteristics: (1) User-mode scheduling: independent of the operating system kernel, managed and scheduled by the application itself; (2) Cooperative execution: actively yielding execution rights via `yield`, rather than kernel preemption; (3) Shared thread resources: multiple fibers can reuse the same operating system thread; (4) Minimal overhead: creation / destruction costs are approximately 1 / 100th of traditional threads, and memory usage is only a few KB. Therefore, the context of a fiber only contains the unique identifier of the physical fiber (Fiber ID), the address of the currently executing instruction, and the execution status flag, and no longer has its own register file and stack space.

[0033] In this invention, the concurrency module, from high to low, comprises three levels: Task, Thread, and Fiber. The Task is set on the Host; the Thread and Fiber are set on the Device. This invention uses Fiber configuration instructions to set the number of concurrent fibers and create the corresponding number of fibers; and uses Thread configuration instructions to set the number of concurrent threads and create the corresponding number of threads. After a task is completed, the number of concurrent threads and concurrent fibers is set, and these numbers vary depending on the task.

[0034] In one embodiment, for a given register, a stride field is set in the corresponding register access instruction. When the stride field is a first preset value (e.g., Stride = 1), it indicates that a preset number of fibers read a consecutive preset number of registers starting from the given register. When the stride field is a second preset value (e.g., Stride = 0), it indicates that a preset number of fibers read the same register. In one embodiment, the stride field is as follows:

[0035]

[0036] The Stride field mentioned above adds a Stride field to the source operand registers (RS1, RS2). Stride = 1 indicates that multiple fibers read multiple consecutive registers. For example, assuming the current number of fibers is 4, Stride of RS1 = 1 means that the 4 fibers read 4 consecutive registers starting from RS1. Stride = 0 indicates that multiple fibers read the same register. For write operations, Stride must be 1 because multiple fibers cannot write to the same register simultaneously, so there is no need to explicitly mark the Stride field for writing to register Rd. Therefore, through the Stride field, fibers can directly know the required load or store address during execution, avoiding redundant address calculations and thus saving computational resources.

[0037] like Figure 2 As shown, in one embodiment, the single-instruction-stream multi-fiber microarchitecture of the present invention includes a fiber front end 1 and an execution back end 2. Figure 3 As shown, the green part represents fiber front-end 1, and the yellow part represents execution back-end 2. The division between fiber front-end 1 and execution back-end 2 is essentially a decoupling of control flow and data flow. Fiber front-end 1 focuses on instruction flow / control flow, while execution back-end 2 focuses on single instruction execution / data flow.

[0038] The fiber front end 1 includes a first instruction cache component (I-Cache) 11, an instruction fetch component (Fetch) 12, a decoding component (Decode) 13, a second instruction cache component (I-Buffer) 14, a scoreboard component (Score-Board) 15, an instruction issue component (Issue) 16, and a fiber stack (Fiber-Stack) 17.

[0039] The first instruction cache component 11 is used to store instructions.

[0040] The instruction fetch component 12 is connected to the first instruction cache component 11 and is used to fetch the instruction from the first instruction cache component 11 when it is determined that an idle fiber group exists. One thread corresponds to one fiber group, and each fiber group has an independent program counter (PC) and independently processes a portion of each instruction. Specifically, after reading the fiber count setting instruction Set_fiber_count(N), a synchronization is performed to ensure that all instructions before switching the fiber count are completed. Then, ceil(N / Fiber GroupSize) fiber groups are allocated to handle all subsequent instructions. Here, N represents the total number of fibers, and Fiber GroupSize represents the number of fibers in each fiber group. Each fiber group processes the corresponding portion of the instruction sequentially. For example, when the fiber count is set to 64 (assuming the fiber group size is 16), 4 fiber groups are allocated to handle all subsequent instructions. For each instruction, the first Fiber Group contains 0 to 15 Fibers, the second Fiber Group contains 16 to 31 Fibers, and so on.

[0041] The decoding component 13 is connected to the instruction fetching component 12 and is used to decode the instruction.

[0042] The second instruction cache component 14 is connected to the decoding component 13 and is used to store decoded instructions. The format of entries in the second instruction cache component 14 includes the instruction body, fiber offset, fiber length (Len), step size (Stride), valid bit, and ready bit. When a fiber group has no valid instructions in the second instruction cache component 14, the fiber group is considered idle. In one embodiment, each entry in the second instruction cache component 14 is divided into a preset number of equal-length parts, each part storing the instructions corresponding to one fiber group; the preset number is the ratio of the maximum number of fibers to the number of fibers in the fiber group. In one embodiment, the content of each entry in the second instruction cache component 14 is shown in Table 1.

[0043] Table 1. Entry storage content of the second instruction cache component

[0044]

[0045] In one embodiment, if a fiber group has no valid instructions in the second instruction cache component 14, then this fiber group is eligible to fetch instructions. All eligible fiber groups will access the first instruction cache component (I-Cache) 11 in a round-robin manner, fetch one or more consecutive instructions corresponding to the program counter (depending on the number of entries held by this fiber group), store the decoded instructions in the second instruction cache component 14, and activate the valid bit of the corresponding entry.

[0046] The scoring board component 15 is connected to the decoding component 13 and is used to handle write-after-write (WAW) and read-after-write (WAR) hazards of the decoded instructions. A write-after-write hazard occurs when two instructions perform write operations on the same memory unit or register, and their execution order is inconsistent with the order specified by the program. A read-after-write hazard occurs when an instruction needs to read the value of a memory unit or register, but another instruction has not yet completed a write operation on that memory unit or register. Both types of hazards affect the correctness and performance of the computer system. This invention addresses these issues through the scoring board component 15 to ensure that instructions access data in the correct order and guarantee correct program execution. In one embodiment, the entries in the scoring board component 15 are of fixed length. Each entry records all registers corresponding to an operand required by an instruction and whether the registers are ready. The entries in the scoring board component 15 include a start register, fiber offset, fiber length (Len), step size (Stride), and a ready bit (Ready). The scoreboard component 15 tracks all issued but not written-back instructions, preserving the registers to which these instructions were written (in the form of the start register, Len, and Stride). These reserved registers are released during the write-back phase. When all bits occupied by the Ready bit of a valid instruction entry are 1, the Ready bit of that instruction in the second instruction cache component 14 is set to 1.

[0047] The instruction issuing component 16 is connected to the second instruction buffer component 14 and the scoreboard component 15, and is used to issue the decoded instructions from the second instruction buffer component 14. The instruction issuing component 16 determines the issuance order of the decoded instructions through a scheduler. The scheduler may employ a scheduling strategy such as round-robin.

[0048] The fiber stack 17 is connected to the instruction issuing component 16 and is used to resolve branching for each fiber group. Fiber group branching typically refers to the performance degradation caused by fibers within a fiber group executing different control flow paths in GPU computing. When the valid value of an entry in the second instruction cache component 14 is set, the ready value is also set by the scoreboard component 15, there is no branching, and it is not waiting for synchronization, the instruction corresponding to that entry can be issued. One fiber stack corresponds to one fiber group. When the next program counter of the top entry of the fiber stack 17 is not equal to the program counter of the current instruction, a branching is determined to have occurred, and the issuance of the decoded instruction is prevented. In one embodiment, when a branching is detected, a new entry is pushed to the top of the fiber stack. The entry includes: a target program counter (Target PC), an immediate postdominator reconvergence (Immediate postdominator reconvergence) value, and an active mask (ActiveMask). The length of ActiveMask is the FiberGroup Size. When this Fiber Group reaches the convergence point again, the top entry is popped.

[0049] The execution backend 2 includes an operand collection component 21 and an instruction processing unit 22.

[0050] The operand collection component 21 is connected to the instruction issuing component 16 and is used to store the corresponding instruction operands based on the decoded instruction. Since the stride can only be 0 or 1, this means that all the registers required for executing an instruction must be the same or a series of consecutive registers. In this invention, the strategy for allocating fibers in a fiber group is linear. Therefore, for a fiber group, the registers it processes can be stored in the form of (offset relative to the starting fiber, length Len, stride). The advantage of this is that it can express all the registers that need to be processed with fewer fields. It should be noted that when the stride is 0, regardless of the offset relative to the starting fiber, the same register is always read. In one embodiment, the storage content of the operand collection component 21 includes the instruction name, fiber group ID, starting register, and operands. Each fiber group corresponds to a predetermined number of consecutive registers. The register corresponding to each instruction is obtained according to the starting register and the fiber group ID to read the instruction operands from the register. The number of fibers is obtained based on the fiber ID, and then the product of the fiber count and the preset number is calculated. The registers containing the instruction operands are the number of registers following the product from the start register. Therefore, the operand collection component 21 does not need to store the offset. Each instruction operand records the valid bit, the ready bit, and the register value. The storage contents of the operand collection component 21 are shown in Table 2.

[0051] Table 2. Storage contents of the operand collection component

[0052]

[0053] The instruction processing unit 22 is connected to the operand collection component 21 and is used to execute the decoded instruction based on the instruction operands. The operand collection component 21 and the instruction processing unit 22 communicate in a one-to-one correspondence.

[0054] In one embodiment, the instruction processing unit 22 includes a Streaming Processor Pipeline (SP Pipeline), a Special Function Unit Pipeline (SFUPpipeline), and a Memory Pipeline (MEM). The Streaming Processor Pipeline is the core computing unit of the GPU, used to execute arithmetic logic instructions (such as addition, subtraction, multiplication, division, vector operations, etc.). The SFUPpipeline is used to execute special instructions (such as trigonometric functions, exponential functions, logarithms, square roots, etc.), thereby reducing the burden on the SP Pipeline and improving the overall computational throughput. The Memory Pipeline is used to execute memory access instructions.

[0055] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0056] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of the present invention, depending on actual needs. For example, the functional modules / units in the various embodiments of the present invention may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0057] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0058] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A single-instruction-stream, multi-fiber microarchitecture, characterized in that: The microarchitecture includes a fiber front-end and an execution back-end; The fiber front end includes a first instruction cache component, an instruction fetch component, a decoding component, a second instruction cache component, a scoreboard component, an instruction dispatch component, and a fiber stack; The first instruction cache component is used to store instructions; The instruction fetching component is used to retrieve the instruction from the first instruction cache component when it is determined that there is an idle fiber group; The decoding component is used to decode the instruction; The second instruction cache component is used to store the decoded instructions; The scoreboard component is used to handle write-after-write and read-after-write hazards of the decoded instructions; The instruction issuing component is used to issue the decoded instruction from the second instruction buffer component; The fiber stack is used to resolve branch divergences for each fiber group; The execution backend includes an operand collection component and an instruction processing unit; The operand collection component is used to store the corresponding instruction operands based on the decoded instructions; The instruction processing unit is used to execute the decoded instruction based on the instruction operand.

2. The single-instruction-stream multi-fiber microarchitecture according to claim 1, characterized in that: One thread corresponds to one fiber group, and each fiber group is set with an independent program counter.

3. The single-instruction-stream multi-fiber microarchitecture according to claim 1, characterized in that: When a fiber group does not have any valid instructions in the second instruction cache component, the fiber group is determined to be idle.

4. The single-instruction-stream multi-fiber microarchitecture according to claim 1, characterized in that: Each entry in the second instruction cache component is divided into a preset number of parts of equal length, and each part is used to store the instruction corresponding to a fiber group; the preset number is the ratio of the maximum number of fibers to the number of fibers in the fiber group.

5. The single-instruction-stream multi-fiber microarchitecture according to claim 1, characterized in that: The instruction issuing component determines the issuing order of the decoded instructions through a scheduler.

6. The single-instruction-stream multi-fiber microarchitecture according to claim 1, characterized in that: A fiber stack corresponds to a fiber group. A branching is determined when the next program counter of the top entry of the fiber stack is not equal to the program counter of the current instruction.

7. The single-instruction-stream multi-fiber microarchitecture according to claim 1, characterized in that: The entries in the scoreboard component are of fixed length, and each entry is used to record all the registers corresponding to one operand required for an instruction and whether the registers are ready.

8. The single-instruction-stream multi-fiber microarchitecture according to claim 1, characterized in that: The operand collection component stores the instruction name, fiber group ID, start register, and operands. Each fiber group corresponds to a predetermined number of consecutive registers. The register corresponding to each instruction is obtained based on the start register and the fiber group ID to read the operands from the register.

9. The single-instruction-stream multi-fiber microarchitecture according to claim 1, characterized in that: The operand collection component and the instruction processing unit communicate in a one-to-one correspondence.

10. The single-instruction-stream multi-fiber microarchitecture according to claim 1, characterized in that: The instruction processing unit includes a stream processor pipeline, a special function unit pipeline, and a memory pipeline; the stream processor pipeline is used to execute arithmetic logic instructions; the special function unit pipeline is used to execute special instructions; and the memory pipeline is used to execute memory access instructions.

Images