Processing method of risc-v vector data load instruction and processor
By issuing vector load instructions in advance and temporarily storing memory access results in a buffer in the RISC-V vector extension processor, the latency problem caused by old value dependency is solved, achieving more efficient instruction-level parallelism and computational throughput.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- YIHUA TECHNOLOGY (BEIJING) CO LTD
- Filing Date
- 2026-03-24
- Publication Date
- 2026-06-26
AI Technical Summary
In RISC-V vector extension processors, the execution of vector load instructions is delayed due to old value dependencies, which prevents full utilization of the out-of-order execution window and affects computational throughput.
The vector load instruction is issued when the source operand is ready. The memory access result is temporarily stored in a buffer and merged to generate the final result when the destination register is ready, thus decoupling the memory access and write-back operations.
It effectively hides memory access latency, improves instruction-level parallelism, and enhances the processing efficiency of vector loading instructions.
Smart Images
Figure CN121900812B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of processor technology, and more specifically, to a method for processing RISC-V vector data loading instructions and a processor. Background Technology
[0002] With the widespread adoption of the RISC-V instruction set architecture and the rapid growth in demand for vector computing, RISC-V VExtension has become an important component of processor design. Modern high-performance processors commonly employ out-of-order execution mechanisms to improve instruction-level parallelism, with register renaming being a key implementation method. In traditional scalar processing scenarios, the target register of an instruction is renamed using a physical register renaming mechanism. Newly allocated physical registers can directly write the result value without considering dependencies on old values.
[0003] In processor designs that support vector extension, the execution of vector instructions has significant unique characteristics. This is especially true for masked vector load instructions, whose execution results may partially depend on the target vector register. Specifically, when `vm=1`, the `v0` register is used as a mask; elements with a mask of 0 must retain their old values or be set to all 1s (controlled by `vtype.vma`); the behavior of elements exceeding the current vector length (defined by the `vl` register) is controlled by `vtype.vta`, which may also retain their old values. Before executing a vector load instruction, the target vector register must be fully ready before subsequent mask merging operations can proceed. While this mechanism ensures the correctness of the execution result, it reveals significant performance defects in practical applications. This problem is particularly pronounced in high-performance computing fields such as AI training and inference, and scientific computing, where the high frequency of vector load instructions exacerbates the issue. Memory access operations are delayed due to waiting for old values to become ready, leading to pipeline dangling cycles; simultaneously, due to the dependency on old values, vector load instructions cannot fully utilize the parallel potential of out-of-order execution windows, ultimately limiting overall computational throughput. Summary of the Invention
[0004] The purpose of this application is to provide a method and processor for processing RISC-V vector data loading instructions, so as to solve the above-mentioned technical problems.
[0005] In a first aspect, the present invention provides a method for processing RISC-V vector data loading instructions, comprising:
[0006] Once a vector load instruction enters the issue queue, it is issued only when its source operand is ready, without waiting for the destination vector register to be ready; the source operand includes scalar operands for address calculation, vector source operands, and mask operands;
[0007] In response to the launch, the memory access address is calculated and a memory access is initiated to load the memory unit;
[0008] After the loading storage unit completes the memory access, it stores the returned loaded data into the vector data buffer instead of writing it directly back to the vector register file;
[0009] When the vector loading instruction is the oldest write-back instruction and the destination vector register is ready, the old value is read from the vector register file, the new data is read from the vector data buffer, the mask and vector configuration information are obtained, the merging unit generates the final result, and writes it to the destination vector register.
[0010] In an optional implementation, the source operand readiness includes the availability of values for a scalar base register, a scalar offset register, a vector register serving as a data source or index, and a vector register serving as mask control bits.
[0011] In an optional implementation, the method further includes: checking whether the physical register corresponding to the scalar operand has been written back, checking whether the physical register corresponding to the vector source operand has been written back, and checking whether the physical register corresponding to the mask operand has been written back.
[0012] When the physical register corresponding to the scalar operand has been written back, the physical register corresponding to the vector source operand has been written back, and the physical register corresponding to the mask operand has been written back, the source operand is determined to be ready.
[0013] In an optional implementation, the vector data buffer is used to temporarily store data for at least one vector load instruction that has completed a memory access but has not yet been merged and written back.
[0014] In an optional implementation, the oldest write-back instruction refers to the earliest instruction in the program order among all vector load instructions that have completed memory access but have not yet been written back.
[0015] In an optional implementation, the vector configuration information includes the value of the vector length control register and / or configuration bits that are independent of the vector mask and the tail element.
[0016] In an optional implementation, the merging unit generates the final result element by element, including:
[0017] If the mask bits of the current element are valid and within the vector length range, then the newly loaded data is used as the result of that element.
[0018] Otherwise, the destination register is retained or the element is filled with all 1s, depending on the vector configuration information.
[0019] In an optional implementation, the method is applied to an out-of-order execution processor that supports RISC-V vector extensions.
[0020] In an optional implementation, the method is implemented via hardware circuitry, which includes:
[0021] The launch queue logic unit is used to launch the vector loading instruction;
[0022] The address calculation unit is used to calculate the memory access address;
[0023] Vector data buffer, used to temporarily store loaded data;
[0024] The write-back control logic unit is used to monitor write-back conditions and trigger merging;
[0025] The merging unit is used to generate the final result.
[0026] In a second aspect, the present invention provides a RISC-V processor, comprising: an issue queue, a load memory unit, a vector physical register file, a scalar physical register file, a vector data buffer, a merging unit, and write-back control logic, wherein the processor is configured to execute the method described in any of the foregoing embodiments.
[0027] This application allows for early initiation of memory address calculation and memory access only when the source operands (scalar, vector source, mask) are ready during vector load instruction issuance, without waiting for the old value of the destination register, thus avoiding issue blocking caused by old value dependency. By temporarily storing the loaded data in the vector data buffer, the memory access operation is decoupled from the subsequent merge-write-back, allowing the memory access latency and the old value readiness waiting time to overlap. When the instruction becomes the oldest write-back instruction and the old value is ready, the merging unit then merges the new and old data element by element according to the mask and vector configuration, ensuring RISC performance. The invention achieves a correct implementation of complex semantics for V-vector extensions. Therefore, without compromising functional correctness, it effectively hides memory access latency, improves instruction-level parallelism, and significantly enhances the processing efficiency of vector loading instructions. Attached Figure Description
[0028] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0029] Figure 1 A schematic flowchart illustrating a method for processing RISC-V vector data loading instructions provided in an embodiment of this application;
[0030] Figure 2 An example provided for an embodiment of this application;
[0031] Figure 3 This is a schematic diagram of a RISC-V processor architecture provided for an embodiment. Detailed Implementation
[0032] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.
[0033] Figure 1 This is a schematic flowchart illustrating a method for processing RISC-V vector data loading instructions, provided in an embodiment of this application. Figure 2 This is an example provided for an embodiment of this application. For example... Figure 1 as well as Figure 2 As shown, the method may include the following steps:
[0034] S110, after a vector load instruction enters the issue queue, it is issued only when its source operand is ready, without waiting for the destination vector register to be ready; the source operand includes scalar operands for address calculation, vector source operands, and mask operands.
[0035] Among them, the ready source operands may include: the values of the scalar base address register, the scalar offset register, the vector register that serves as the data source or index, and the vector register that serves as the mask control bits, all of which are available.
[0036] In some embodiments, it can be checked whether the physical register corresponding to the scalar operand has been written back, whether the physical register corresponding to the vector source operand has been written back, and whether the physical register corresponding to the mask operand has been written back; when the physical register corresponding to the scalar operand has been written back, the physical register corresponding to the vector source operand has been written back, and the physical register corresponding to the mask operand has been written back, the source operand is determined to be ready.
[0037] For example, combining Figure 2 As shown, after a vector loading instruction enters the launch queue, the scheduler only checks whether its source operands are ready, without waiting for vd to be ready. The source operands include scalar source operands, vector source operands, and mask operands, typically the data of rs1, rs2, vs2, and v0.
[0038] Here, rs1 is the first scalar source operand register, rs2 is the second scalar source operand register, vs2 is the vector source operand register, v0 is the mask register, and vd is the destination vector register.
[0039] The scalar source operands are stored in the scalar physical register file and used to generate memory access addresses. rs1 is typically the base register, and rs2 can be the offset register.
[0040] Vector source operands are stored in a vector physical register file, providing a set of index values in certain instructions (such as index loading).
[0041] The mask operand specifically refers to the data of v0, and each bit controls whether the corresponding data element is updated (a mask bit of 1 indicates that it is valid).
[0042] like Figure 2 As shown, the condition for a source operand to be ready is that the corresponding physical register has been written back, meaning its value is available. Specifically, it checks whether rs1 and rs2 in the scalar physical register file, and vs2 and v0 in the vector physical register file, have all been written back. When all these source operands are ready, the instruction can be issued without waiting for vd.
[0043] like Figure 2 As shown, the Issue Queue selects the oldest load instruction whose source operand is ready and sends it to the subsequent pipeline stage. This step breaks the dependency of waiting for an old value of vd in traditional designs, creating conditions for early memory access.
[0044] S120, in response to the transmission, calculates the memory access address and initiates a memory access to the load memory unit.
[0045] like Figure 2 As shown, in response to the instruction issuance, the address calculation unit (AGU) immediately calculates the memory access address based on the source operand and initiates a memory access request to the load memory unit (LSU).
[0046] The address calculation method depends on the instruction type:
[0047] Contiguous address access (e.g., cell step size instruction vlb.v): The address of each element is obtained by adding the element index to the base address and multiplying by the element's byte length. The hardware needs to generate a set of contiguous addresses, but in practice, LSUs typically access them in burst mode.
[0048] Index address access (e.g., index loading vlxei8.v): The address is obtained by adding the index value stored in vs2 to the base address.
[0049] In this application, address calculation relies only on the already ready source operands and can therefore be performed immediately. The calculated address is sent to the LSU, which then begins reading data from the data cache or memory. Figure 2In the process, the "read scalar source" obtains the data of rs1 and rs2 from the scalar physical register file, and sends them together with the data of vs2 obtained by the "read vector source" into the LSU (marked as "command" in the figure).
[0050] S130: After the memory access is completed, the returned loaded data is stored in the vector data buffer instead of being written directly back to the vector register file.
[0051] The vector data buffer is used to temporarily store data for at least one vector load instruction that has completed a memory access but has not yet been merged and written back.
[0052] The oldest write-back instruction is the earliest in the program sequence among all vector load instructions that have completed memory access but have not yet been written back.
[0053] like Figure 2 As shown, after the LSU completes the memory access, it does not write the returned load data directly back to the vector physical register file, but instead stores it in a dedicated vector data buffer (VPU Data Buffer). This buffer is used to temporarily store data from at least one vector load instruction that has completed a memory access but has not yet been merged and written back. Each buffer entry typically contains the load data, the corresponding instruction identifier, and necessary control information.
[0054] like Figure 2 As shown, the "read load data" output by LSU is written to the vector data buffer. This step decouples the memory access operation from the subsequent merge write-back, so that memory access latency no longer blocks subsequent instructions, while allowing memory access to still occur even if the old value is not ready.
[0055] The vector data buffer can be implemented using a queue structure, organized sequentially according to the program. When multiple load instructions are issued consecutively and complete memory access, their data is temporarily stored in the buffer sequentially, waiting for the merging condition to be met.
[0056] S140: When the vector loading instruction is the oldest write-back instruction and the destination vector register is ready, the old value is read from the vector register file, the new data is read from the buffer, the mask and vector configuration information are obtained, the merging unit generates the final result, and writes it to the destination vector register.
[0057] The vector configuration information includes the value of the vector length control register and / or configuration bits that are independent of the vector mask and the tail element.
[0058] In some embodiments, the merging unit generates the final result element by element, including: if the mask bits of the current element are valid and within the vector length range, then the newly loaded data is used as the result of the element; otherwise, the destination register is retained or the element is filled with all 1s according to the vector configuration information.
[0059] In some embodiments, write-back conditions can be continuously monitored. The merge write-back process is triggered when both of the following conditions are met:
[0060] This instruction is the oldest instruction yet to be written back: that is, among all vector load instructions that have completed memory access but have not yet been written back, it is the earliest one in the program sequence;
[0061] vd is ready: This means that the physical register corresponding to vd has completed the previous write-back and the current value is available.
[0062] Write back to the control logic unit (e.g.) Figure 2 (Not explicitly stated, but implicitly included in the process) is responsible for judging these two conditions. Once met, the following operations are performed:
[0063] Read vd from the vector physical register file ( Figure 2 ("old value of vd" in the middle)
[0064] Read the newly loaded data corresponding to this instruction from the vector data buffer. Figure 2 (Newly loaded data in the middle)
[0065] Obtain the data and vector configuration information for v0, including: the current vector length vl (provided by the vl register); mask-independent (vma) and tail-element-independent (vta) configuration bits, from the vtype register.
[0066] Send all data into the Merge Unit.
[0067] In some embodiments, the merging unit generates the final result. For the i-th element (i ranges from 0 to the maximum vector length - 1), the specific process can be as follows:
[0068] The following for loop is used to assign a value to each element i of the vd_new array:
[0069] for (i = 0; i < array length; i++) {
[0070] When the i-th bit of v0 is 1 and i is less than the current vector length VL, vd_new[i] takes load_data[i].
[0071] if {
[0072] vd_new[i] = load_data[i];
[0073] }
[0074] When the i-th bit of v0 is 0 or i is greater than or equal to the current vector length VL, and both the mask-independent configuration vma and the tail element-independent configuration vta are 0, vd_new[i] takes vd_old[i].
[0075] else if {
[0076] vd_new[i] = vd_old[i];
[0077] }
[0078] When the i-th bit of v0 is 0 or i is greater than or equal to the current vector length VL, and at least one of the mask-independent configuration vma and the tail-element-independent configuration vta is 1, vd_new[i] takes all 1s;
[0079] else if {
[0080] vd_new[i] = all_ones;
[0081] }
[0082] }
[0083] Where mask[i]: the i-th element of v0, 1 indicates that the element needs to be updated, and 0 indicates that it does not need to be updated.
[0084] VL: Current vector length, specified by the vl register, representing the number of valid elements.
[0085] vma / vta: These correspond to mask-independent and tail-element-independent configurations, respectively. When vma = 1, elements with a mask of 0 are filled with all 1s; when vta = 1, elements exceeding VL are filled with all 1s. In actual hardware, these two configurations can be controlled independently. For simplicity, the above formula combines them into a single condition (i.e., filling with all 1s when either configuration is 1). In specific implementations, they need to be handled separately.
[0086] This code iterates through each element i of the vd_new array using a for loop, assigning values to vd_new[i] based on different conditions, and includes detailed comments explaining the meaning of each condition.
[0087] The merging unit typically processes multiple elements in parallel, with each element having independent comparison and selection logic. After generating the final result, it is written to the vd via a write-back channel, completing the instruction submission. Figure 2 The "Merge Unit" is output to "Write vd" to update the vector physical register file.
[0088] In some embodiments, the method is applied to out-of-order execution processors that support RISC-V vector extensions.
[0089] In some embodiments, the method is implemented via hardware circuitry, the hardware circuitry including:
[0090] The launch queue logic unit is used to launch vector loading instructions;
[0091] The address calculation unit is used to calculate the memory access address;
[0092] Vector data buffer, used to temporarily store loaded data;
[0093] The write-back control logic unit is used to monitor write-back conditions and trigger merging;
[0094] The merging unit is used to generate the final result.
[0095] Figure 3 A schematic diagram of a RISC-V processor architecture is provided for an embodiment. This processor is configured to perform the aforementioned... Figure 1 The method shown. (As illustrated) Figure 3 As shown, the RISC-V processor includes the following main functional modules:
[0096] The processor comprises an issue queue (301), a load store unit (LSU) (302), a vector physical register file (303), a scalar physical register file (304), a vector data buffer (305), a merge unit (306), and write-back control logic (307). These modules are interconnected via a data bus and control signals to jointly implement the functions of early issuance of vector load instructions, data temporary storage, and delayed merge write-back. The processor adopts an out-of-order execution architecture and supports all instructions and configurations of the RISC-V Vector Extension (V Extension).
[0097] The transmit queue 301 is used to store decoded but not yet transmitted instructions. In the processing of vector loading instructions, the transmit queue integrates active operand readiness detection logic, which is connected to the scalar physical register file and the vector physical register file to monitor the write-back status of the source operands required by the instruction in real time.
[0098] For a vector load instruction, the issue queue only checks if the following source operands are ready: rs1, rs2 (if the instruction uses it), vs2, and v0. When the physical registers corresponding to all these source operands have been written back (i.e., their values are available), the issue queue selects the instruction to issue to the next pipeline stage, without waiting for vd to become ready. This design breaks the dependency chain of traditional architectures that required waiting for the old value of vd.
[0099] The scalar physical register file 304 stores the physical values (data) of all scalar registers (x0~x31). It provides multiple read and write ports and supports register renaming during out-of-order execution. During the execution of vector load instructions, the scalar physical register file 304 responds to read requests from the issue queue 301 and outputs the data of rs1 and rs2 to the address calculation unit (which can be integrated into the LSU or exist independently).
[0100] The LSU302 handles all memory access operations, including address calculation, cache access, and memory interface control. In this embodiment, the LSU includes the following key components: Address Calculation Unit: Receives data from rs1 and rs2 of the scalar physical register file and data from vs2 of the vector physical register file (for index loading), and calculates the memory access address based on the instruction type. Memory Access Control Logic: Manages cache or memory access requests, handling misses, refills, and other similar transactions. Data Return Path: Outputs loaded data to the vector data buffer instead of writing it directly back to the vector register file.
[0101] A dedicated data bus is provided between LSU302 and vector data buffer 305 for transmitting load data and its corresponding instruction identifier.
[0102] Vector physical register file 303 stores data from all vector registers (v0~v31), each register capable of holding variable-length vector data (e.g., 128 bits, 256 bits, 512 bits, etc.). It provides multiple read and write ports, supporting: reading vs2 and v0 during the instruction issue phase; reading vd during the merge write-back phase; and writing new values after the merge is complete.
[0103] There is an old value read path and a new value write path between the vector physical register file 303 and the merging unit 306.
[0104] The vector data buffer 305 is a core new module of this invention, located between the LSU 302 and the merging unit 306. Its function is to temporarily store vector loading data that has been accessed but not yet merged and written back. Specifically, this buffer has the following characteristics: it is organized sequentially according to the program; each entry stores the return data of a vector loading instruction, the instruction identifier (such as a program counter or tag), and necessary control information. Its depth is at least 2 to support multiple loading instructions being in a temporary state simultaneously, improving parallelism. It has an LSU write port and a merging unit read port, supporting simultaneous reading and writing of different entries.
[0105] When LSU302 completes a vector loading, it writes the data along with the instruction identifier to the end of the vector data buffer 305. The merging unit 306 reads the data of the oldest instruction from the beginning when the conditions are met.
[0106] The write-back control logic 307 is responsible for monitoring the status of instructions in the vector data buffer and determining when to trigger the merge write-back. Its core functions include: determining the oldest instruction to be written back by comparing the program order (or enqueue order) of instructions in the buffer; connecting to the vector physical register file to monitor whether the vd of the oldest instruction has completed its previous write-back (i.e., the old value is available); and sending control signals to the merge unit 306, the vector physical register file 303, and the vector data buffer 305 when the old value of the oldest instruction's vd is ready, thus initiating the merge write-back process.
[0107] The write-back control logic 307 works in conjunction with the launch queue 301 to ensure the correct order of command submission.
[0108] The merging unit 306 receives data from multiple sources and generates the final result element-wise based on the mask and vector configuration. Its inputs include: the old value of vd read from the vector physical register file; newly loaded data read from the vector data buffer; mask data obtained from v0 or a mask copy stored in the buffer; and vector configuration information, including the current vector length vl and vma / vta configuration bits, from the control status register.
[0109] The merging unit can contain multiple parallel element processing channels, each of which executes the following logic independently.
[0110] The output of the merging unit is written to vd via the write-back path, completing the instruction submission.
[0111] The following example, using a typical vector loading instruction (such as cell step size loading vlb.v), illustrates the collaborative process of the modules:
[0112] When the transmit queue 301 detects that rs1, vs2 (if any) and v0 of the vlb.v command are all ready, it immediately transmits the command to LSU302 and records the program sequence of the command.
[0113] The address calculation unit within the LSU302 uses rs1 and rs2 (if they exist) to calculate the base address, generate a continuous address sequence, and initiate an access request to the data cache.
[0114] After LSU302 completes the memory access, it writes the returned vector data and its corresponding instruction identifier to the end of the vector data buffer 305. At this point, the instruction enters the "pending write-back" state.
[0115] The write-back control logic 307 continuously monitors the header instruction (i.e., the oldest instruction to be written back) of the vector data buffer 305. Assuming the header instruction is the aforementioned vlb.v instruction, and its vd is not yet ready (e.g., vd was written by the previous instruction but has not yet been completed), the write-back control logic 307 waits.
[0116] When the old value of vd is written back (vector physical register file update), write-back control logic 307 detects the state change.
[0117] The write-back control logic 307 sends a read request to the vector physical register file 303 to obtain the old value of vd, sends a read request to the vector data buffer 305 to obtain the newly loaded data, and simultaneously obtains the data of v0 and the configuration of vl / vma / vta.
[0118] The merging unit 306 receives all inputs, processes all elements in parallel, and generates the final result based on the mask and configuration.
[0119] The merging unit 306 writes the result to vd in the vector physical register file 303, and the instruction is committed. The header entry of the vector data buffer 305 is released.
[0120] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0121] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0122] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0123] It should be noted that if the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0124] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.
[0125] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A method for processing RISC-V vector data loading instructions, characterized in that, include: Once a vector load instruction enters the issue queue, it is issued only when its source operand is ready, without waiting for the destination vector register to be ready. The source operands include scalar operands for address calculation, vector source operands, and mask operands. Specifically, the source operands include the data for rs1, rs2, vs2, and v0. rs1 is the first scalar source operand register, rs2 is the second scalar source operand register, vs2 is the vector source operand register, v0 is the mask register, and vd is the destination vector register. The scalar source operands are stored in rs1 and rs2 and are used to generate the memory access address. The vector source operands are stored in vs2. The mask operands specifically refer to the data in v0, and each bit controls whether the corresponding data element is updated. In response to the launch, the memory access address is calculated and a memory access is initiated to load the memory unit; After the loading storage unit completes the memory access, it stores the returned loaded data into the vector data buffer instead of writing it directly back to the vector register file; When the vector loading instruction is the oldest write-back instruction and the destination vector register is ready, the old value is read from the vector register file, the new data is read from the vector data buffer, the mask and vector configuration information are obtained, the merging unit generates the final result, and writes it to the destination vector register; the vector configuration information includes the value of the vector length control register and / or configuration bits that are independent of the vector mask and the tail element. The merging unit generates the final result element by element, including: assigning a value to each element i of the vd_new array, implemented by the following for loop: when the i-th bit of v0 is 1 and i is less than the current vector length VL, vd_new[i] takes load_data[i]; when the i-th bit of v0 is 0 or i is greater than or equal to the current vector length VL, and both the mask-independent configuration and the tail element-independent configuration are 0, vd_new[i] takes vd_old[i]; when the i-th bit of v0 is 0 or i is greater than or equal to the current vector length VL, and at least one of the mask-independent configuration and the tail element-independent configuration is 1, vd_new[i] takes all 1s. Where vd_new is the new data in the destination vector register; vd_old is the old value in the vector register file; VL is the current vector length, specified by vl, representing the number of valid elements; and load_data is the new data to be retrieved at the corresponding position.
2. The method according to claim 1, characterized in that, Also includes: Check whether the physical register corresponding to the scalar operand has been written back, check whether the physical register corresponding to the vector source operand has been written back, and check whether the physical register corresponding to the mask operand has been written back. When the physical register corresponding to the scalar operand has been written back, the physical register corresponding to the vector source operand has been written back, and the physical register corresponding to the mask operand has been written back, the source operand is determined to be ready.
3. The method according to claim 1, characterized in that, The vector data buffer is used to temporarily store data for at least one vector load instruction that has completed memory access but has not yet been merged and written back.
4. The method according to claim 3, characterized in that, The oldest write-back instruction refers to the earliest instruction in the program sequence among all vector load instructions that have completed memory access but have not yet been written back.
5. The method according to claim 1, characterized in that, The method is applied to out-of-order execution processors that support RISC-V vector extensions.
6. The method according to claim 1, characterized in that, The method is implemented through hardware circuitry, which includes: The launch queue logic unit is used to launch the vector loading instruction; The address calculation unit is used to calculate the memory access address; Vector data buffer, used to temporarily store loaded data; The write-back control logic unit is used to monitor write-back conditions and trigger merging; The merging unit is used to generate the final result.
7. A RISC-V processor, characterized in that, include: The processor is configured to perform the method described in any one of claims 1 to 6, comprising a transmit queue, a load storage unit, a vector physical register file, a scalar physical register file, a vector data buffer, a merging unit, and write-back control logic.