Instruction processing method and device, chip product, computer equipment and storage medium

Abstract

The invention provides an instruction processing method and device, a chip product, computer equipment and a storage medium. The method comprises the following steps: in response to a received to-be-processed vector instruction, splitting the vector instruction into a plurality of microoperations respectively corresponding to a plurality of destination registers; the micro-operation is used for acquiring data access information required by the destination register corresponding to the micro-operation; executing each item of microoperation in parallel; triggering an execution unit to execute a calculation operation under the condition of determining that all the micro-operations are executed; wherein the execution unit, in response to the calculation operation, performs a vector operation on the plurality of destination registers based on the data access information acquired by all the micro-operations. The number of micro-operations can be greatly reduced, and the problem of pipeline blockage caused by the fact that a transmitting queue is filled is avoided.

Description

Technical Field

[0001] This application relates to the field of processor technology, and in particular to an instruction processing method, instruction processing apparatus, chip product, computer equipment, and computer-readable storage medium. Background Technology

[0002] In modern processor architectures, computational efficiency can be improved by processing multiple data elements in parallel. In related technologies, when processing vector instructions based on vector extensions, a common approach is to break down an instruction into multiple micro-operations, where each micro-operation corresponds to a destination register and independently reads data from the source register set.

[0003] However, with this approach, each micro-operation needs to access all source registers independently. As the number of destination registers increases, the number of micro-operations increases exponentially, severely blocking the processor pipeline and resulting in low overall processor execution efficiency. Summary of the Invention

[0004] This application provides at least one instruction processing method, instruction processing device, chip product, computer equipment, and computer-readable storage medium, which can significantly reduce the number of micro-operations and avoid pipeline blockage caused by the launch queue being filled.

[0005] This application provides an instruction processing method, the method comprising: in response to receiving a vector instruction to be processed, splitting the vector instruction into multiple micro-operations corresponding to multiple destination registers respectively; the micro-operations being used to obtain data access information required by their corresponding destination registers; executing each of the micro-operations in parallel; and, upon determining that all the micro-operations have been completed, triggering an execution unit to perform a computation operation; wherein, in response to the computation operation, the execution unit performs vector operations on the multiple destination registers based on the data access information obtained from all the micro-operations.

[0006] This application provides an instruction processing apparatus, which includes a splitting unit, a parallel execution unit, and an execution unit. The splitting unit, in response to receiving a vector instruction to be processed, splits the vector instruction into multiple micro-operations corresponding to multiple destination registers. Each micro-operation is used to obtain data access information required by its corresponding destination register. The parallel execution unit is used to execute each micro-operation in parallel. Upon determining that all micro-operations have been completed, the execution unit is triggered to perform a computation operation. The execution unit, in response to the computation operation, performs vector operations on the multiple destination registers based on the data access information obtained from all the micro-operations.

[0007] This application provides a chip product, which includes the instruction processing device provided in this application.

[0008] This application provides a computer device, which includes the chip product provided in this application.

[0009] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the instruction processing method provided in this application.

[0010] The technical solutions provided by the embodiments of this application may include the following beneficial effects.

[0011] This application provides an instruction processing method that, in response to receiving a vector instruction to be processed, decomposes the vector instruction into multiple micro-operations corresponding to multiple destination registers; each micro-operation is used to obtain the data access information required by its corresponding destination register; each micro-operation is executed in parallel; and when all micro-operations are determined to be completed, an execution unit is triggered to perform a computation operation; wherein, in response to the computation operation, the execution unit performs vector operations on the multiple destination registers based on the data access information obtained from all the micro-operations. In this way, each decomposed micro-operation is only responsible for generating the data access information of its corresponding destination register, making the number of micro-operations linearly related to the number of destination registers, reducing the number of micro-operations, improving the throughput of the processor pipeline, and thus improving the overall execution efficiency of the processor.

[0012] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0014] Figure 1 This is a flowchart illustrating an instruction processing method provided in an embodiment of this application;

[0015] Figure 2 This is a block diagram of an instruction processing device provided in an embodiment of this application;

[0016] Figure 3 This is a schematic diagram of a register group structure provided in the background technology of this application;

[0017] Figure 4 This is a schematic diagram of the element dependency relationship in a register group provided by the background technology of this application;

[0018] Figure 5 This is a schematic diagram of a splitting micro-operation provided in the background technology of this application;

[0019] Figure 6 This is a schematic diagram illustrating the dependency relationship between the destination register and the source register of an instruction, as provided in the background technology of this application.

[0020] Figure 7 This is a schematic diagram of the micro-operation breakdown of an instruction provided in the background technology of this application;

[0021] Figure 8 This is a schematic diagram illustrating the clock cycles required for instruction execution, as provided in the background section of this application.

[0022] Figure 9 This is a schematic diagram of a processor pipeline architecture provided in an embodiment of this application;

[0023] Figure 10 This is a schematic diagram of a special launch queue architecture provided in an embodiment of this application;

[0024] Figure 11 This is a flowchart of a method for processing vector permutation instructions provided in an embodiment of this application;

[0025] Figure 12 This is a schematic diagram illustrating the breakdown of a vector permutation instruction provided in an embodiment of this application;

[0026] Figure 13 This is a schematic diagram illustrating the clock cycles required to execute a vector permutation instruction according to an embodiment of this application;

[0027] Figure 14 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0030] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0031] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0032] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0033] 1) Vector Instruction: A type of instruction that processes multiple data elements, widely used in high-performance computing and artificial intelligence. Vector instructions can operate on multiple data elements simultaneously, improving computational efficiency. For example, in the Vector Extended Instruction Set (RVV) of the fifth-generation Reduced Instruction Set Computer (RISC-V) architecture, vector instructions can be used to perform massively parallel operations.

[0034] 2) Micro-Operation (UOP): Also known as a microinstruction, it is the basic unit inside the processor used to execute complex instructions. Macro instructions (such as vector instructions) are usually broken down into multiple UOPs for more efficient scheduling and execution in the pipeline. Each UOP is responsible for completing a smaller operation task.

[0035] 3) Source Register: A register that stores the data elements used for computation. In vector permutation instructions, the source register may include a data source register and an index register, providing the actual data and the index information for accessing that data, respectively.

[0036] 4) Destination Register: A register used to store the calculation results. In vector permutation instructions, the calculation results may be distributed across multiple destination registers, each corresponding to a different data element.

[0037] 5) Index Register: A register used to store index values, often used in vector permutation instructions to indicate the order of data elements.

[0038] Currently, in modern processor architectures, RISC-V-based vector extensions are widely used in high-performance computing and artificial intelligence to improve computational efficiency by processing multiple data elements in parallel. In related technologies, to simplify hardware design and reuse pipelines designed for ordinary vector instructions, a complex vector permutation instruction is decomposed into multiple simple, independently executable micro-operations when processing vector permutation instructions.

[0039] During the splitting process, for each destination physical register in the destination register set, the entire source register set needs to be checked. This is to determine which source register the data in the destination register might have come from. Therefore, for the i-th register in the destination register set, an independent micro-operation needs to be generated for each possible source register (m in total) in the source register set. These m micro-operations are all responsible for writing data to the same destination physical register.

[0040] On the one hand, as the number of destination registers increases, the number of micro-operations increases exponentially. This can cause a massive number of micro-operations generated by a single instruction to instantly fill the processor's micro-instruction cache, rename buffer, and issue queue, severely blocking the entry of subsequent instructions and compromising the processor's multi-instruction output capability.

[0041] On the other hand, since all m micro-operations target the same physical register, to prevent write-after-write conflicts, the hardware must artificially and forcibly establish sequential dependency chains between these micro-operations. That is, these m micro-operations must be executed serially; the next micro-operation can only begin execution after the previous micro-operation has completed updating the destination register. This causes the total number of instruction execution cycles to increase linearly with the number of destination registers, negating the core advantages of superscalar processors' multiple issue and out-of-order execution. The processor cannot execute these potentially parallel micro-operations in parallel, leaving hardware parallel resources idle and resulting in low actual instruction execution efficiency.

[0042] On the other hand, in the above-mentioned splitting, since index or mask information is not shared among micro-operations, each micro-operation needs to independently acquire and decode its assigned index or mask information to determine whether it needs the source register data it is responsible for. This leads to repeated access to the index or mask data. For example, in vector permutation instructions, when splitting micro-operations, each micro-operation repeatedly reads the entire mask register set, increasing the actual number of times the mask register set is read from the ideal m times to m × the number of micro-operations. More seriously, each micro-operation needs to read the entire data register set to process its assigned source data, resulting in an increased number of micro-operations that read the entire data register set, causing huge read port pressure and power consumption waste.

[0043] For example, for vector permutation instructions, each micro-operation needs to read the corresponding mask segment because it needs to determine whether to select the corresponding mask register group element based on the mask bits of each element. In practical applications, this results in each micro-operation repeatedly reading the entire mask register. Simultaneously, each micro-operation needs to access the entire data register group to determine whether to select a certain data register group element, causing the data register group to be repeatedly read several times by the micro-operation. In reality, most accesses to data register group elements are invalid (mask is 0), and this redundant access significantly increases dynamic power consumption.

[0044] The number of times index or mask data, as well as source data, are repeatedly read is proportional to the number of micro-operations, which puts unnecessary high pressure on the read port, easily causing pipeline stalls and consuming additional dynamic power due to a large number of invalid accesses.

[0045] This application proposes an instruction processing method that breaks down vector instructions into multiple micro-operations corresponding to multiple destination registers. Each micro-operation is only responsible for generating data access information for its corresponding destination register. In this way, the number of micro-operations is linearly related to the number of destination registers, avoiding quadratic growth and reducing the number of micro-operations. At the same time, since each destination register is handled by an independent micro-operation, there are no write conflicts between these micro-operations, and they can be executed in parallel without forcibly establishing dependency chains, thereby making full use of the processor's out-of-order execution capability. In addition, each micro-operation only needs to access the necessary source register data, reducing redundant readings of index data and source data, and reducing the pressure on register ports and dynamic power consumption.

[0046] Figure 1 This is a flowchart illustrating an instruction processing method provided in an embodiment of this application, as shown below. Figure 1 As shown, Figure 1 The instruction processing method described herein uses vector permutation instructions as an example. The instruction processing method provided in this embodiment can be executed by the processor's execution pipeline, which includes modules such as a decoding unit, a register renaming unit, a first issue queue, a second issue queue, and an execution unit. That is, the instruction processing method in this embodiment can be completed collaboratively by one or more modules in the aforementioned hardware structure.

[0047] The following will combine Figure 1 The steps shown are explained, and the method includes the following steps S101 to S103.

[0048] Step S101: In response to receiving the vector instruction to be processed, the vector instruction is split into multiple micro-operations corresponding to multiple destination registers respectively.

[0049] Among them, micro-operations are used to obtain the data access information required by their corresponding destination registers.

[0050] In this embodiment, vector instructions can refer to a specific category of macro instructions capable of operating on multiple data elements simultaneously and requiring micro-operation decomposition. For example, it can refer to vector permutation instructions in the vector extension instruction set of the RISC-V architecture, such as the `vrgather` instruction. This type of instruction selects data elements from the source data vector register set based on the index stored in the index data and arranges them into the destination vector register set. Furthermore, the vector compression instruction `vcompress` compresses the elements in the source data vector register set based on the mask data in the mask register, tightly arranging elements with a mask value of 1 into the destination register. Sliding instructions, such as vector sliding instructions, move elements in the source data vector register set using a scalar offset.

[0051] A micro-operation (UOP) is the basic unit within a processor used to execute complex instructions. Macro instructions (such as vector instructions) can be broken down into multiple micro-operations for more efficient scheduling and execution within the pipeline. Each micro-operation can be responsible for completing a data acquisition task.

[0052] In this application, micro-operations can be designed specifically to collect data access information required by the destination register, rather than to perform direct computation operations. This data access information can be source data from all vector registers required to execute vector instructions, i.e., elements in the source data vector register set, as well as control information in the index or mask vector registers.

[0053] Specifically, a corresponding micro-operation UOP_i can be generated for each destination physical register. The function of each micro-operation UOP_i can be configured to perform a data acquisition to read a portion of the global data necessary to perform a complete vector permutation calculation.

[0054] Specifically, in vector permutation instructions (such as the vrgather instruction) or vector compression instructions (such as the vcompress instruction), the result of a destination physical register depends on one or more specific source data from the source physical register set, and an index or mask value from the index register set that controls how that element is selected / computed. Each UOP_i can be used to be responsible for reading a slice of data from the source operands in the vector registers used to execute the full vector instruction. For example, for a micro-operation UOP_i, the entire source operand in the i-th source physical register can be read, as well as the index operand in the i-th index register in the index register set.

[0055] In this way, the combined data collected by all N micro-operations can cover the source operands in the vector register used to execute the complete vector instruction. Each micro-operation only collects a slice of data from the entire source operand, thus all micro-operations can work in parallel.

[0056] In some embodiments, the vector register accessed by each micro-operation can be pre-configured. During the configuration process, the correspondence between each micro-operation and the vector register does not need to be limited, but the vector register accessed by each micro-operation needs to be different.

[0057] Since the source register and index register accessed by each UOP_i are pre-allocated and do not overlap, and it only performs read operations and does not produce a final write-back result, there is no real data dependency between these N UOP_i, and they can be executed in parallel in subsequent steps.

[0058] Moreover, in related technologies, since each destination register's corresponding UOP needs to read all source registers, the source data is read repeatedly N times. However, with the embodiments of this application, each source register can be read only once by a dedicated UOP_i; similarly, each index register is read only once by a dedicated UOP_i. This can eliminate redundant register access, alleviate the read port pressure of the vector register file, and significantly reduce dynamic power consumption.

[0059] For example, if the destination register group includes N physical registers with indices vd[0], vd[1], ..., vd[N-1], then this split will generate exactly N micro-operations: UOP[0], UOP[1], ..., UOP[N-1].

[0060] Step S102: Execute each micro-operation in parallel.

[0061] Parallel execution refers to the process in which multiple micro-operations are simultaneously or overlappingly scheduled, issued, executed, and completed in the processor pipeline.

[0062] In this embodiment of the application, for the received N micro-operations UOP[0], UOP[1], ..., UOP[N-1], the registers of the N micro-operations can be renamed and resources allocated first.

[0063] Specifically, after the renaming unit receives N micro-operations UOP[0] to UOP[N-1] from the decoding unit, for each micro-operation UOP[i], its source operand can be mapped to the corresponding physical register, and its index operand can be mapped to the corresponding physical register. In addition, a temporary physical target register P_temp_i can be allocated for each micro-operation to temporarily store the acquired data.

[0064] Then, the dispatch unit can allocate a reorder buffer (ROB) entry for each micro-operation UOP_i to record the program order, status, and exception information of the micro-operation, as well as a launch queue entry for waiting for operands to be ready and for launch arbitration.

[0065] Since the source and index operands of each UOP_i are immediately available after renaming, all micro-operations are marked as ready upon entering the issue queue. In this case, the issue arbitration logic of the issue queue can select up to M ready micro-operations from the issue queue for issuance each clock cycle, where M is the number of processor issue ports. Furthermore, since all micro-operations are independent, the issue logic can issue all micro-operations in consecutive cycles until all N micro-operations have been issued. The issue bandwidth is limited by the number of processor issue ports M. If N > M, then issuance requires ⌈N / M⌉ clock cycles.

[0066] Step S103: After confirming that all micro-operations have been completed, the execution unit is triggered to perform the calculation operation.

[0067] The execution unit responds to computational operations and performs vector operations on multiple destination registers based on data access information obtained from all micro-operations.

[0068] In this embodiment, the execution unit is a unit within the processor responsible for performing micro-operations. It can perform specific computational operations based on the received micro-operations and data access information, and generate the final computational result. Once all micro-operations have been executed, the execution unit is triggered and performs computations based on all the data access information collected from these micro-operations.

[0069] Once it is determined that all micro-operations have been completed, a trigger signal can be generated. This signal serves as a wake-up condition, causing the execution unit to enter the wake and iss phases of its pipeline.

[0070] In this step, during the wake-up phase, the execution unit can respond to a trigger signal to read all the data collected and aggregated by UOP from the shared data buffer at once during the iss phase, based on the pointer and other information carried by the trigger signal. At this point, the buffer already contains complete source operands and complete index operands.

[0071] After reading the data, the execution unit can enter the computation phase, performing calculations such as permutation selection logic on all destination registers in parallel based on the data collected and aggregated from all micro-operations. After the computation is complete, in the execution unit's write-back phase, the final results of all destination registers can be written back to the physical register file in parallel, completing the atomic commit of the entire vector permutation macro instruction.

[0072] By adopting the above technical solution, vector instructions are split into multiple micro-operations corresponding to multiple destination registers. Each micro-operation is only responsible for generating data access information for its corresponding destination register. In this way, the number of micro-operations is linearly related to the number of destination registers, avoiding quadratic growth and reducing the number of micro-operations. At the same time, since each destination register is handled by an independent micro-operation, there are no write conflicts between these micro-operations, and they can be executed in parallel without forcibly establishing dependency chains, thus making full use of the processor's out-of-order execution capability. In addition, each micro-operation only needs to access the necessary source register data, reducing redundant readings of index data and source data, and reducing the pressure on register ports and dynamic power consumption.

[0073] Considering that if all micro-operations (regardless of whether they are dependent) and triggering logic are put into the same launch queue, the arbitration logic, wake-up logic and completion tracking logic of the queue will become extremely complex, and micro-operations of different natures will compete for resources with each other, interfering with scheduling efficiency.

[0074] Therefore, in some embodiments, the above step S102 can be implemented by the following steps S1021 to S1023.

[0075] Step S1021: Send multiple micro-operations to the first launch queue.

[0076] The first launch queue can be a hardware structure used to temporarily store micro-operations to be executed. In this application, the first launch queue can be used to receive multiple micro-operations and serve as the first-level buffer during the data access information collection phase. After each micro-operation enters the first launch queue, it needs to wait for the operands of the source register and index register required by that micro-operation to be ready.

[0077] In this step, multiple micro-operations can be sent to the first transmit queue via the dispatch unit. Each UOP carries the physical address information of its corresponding source register, index register, and destination register.

[0078] Step S1022: Multiple micro-operations are executed in parallel through the first transmit queue to obtain the data access information required by the destination register corresponding to each micro-operation.

[0079] The data access information consists of the source operands and index operands in the source register corresponding to the destination register.

[0080] In this embodiment, after multiple micro-operations are sent to the first transmit queue, since there is no data dependency between each micro-operation, the source operands required by all micro-operations are immediately ready when they enter the first transmit queue. That is, each micro-operation can obtain the data access information required by its corresponding destination register when it enters the first transmit queue.

[0081] In this step, each micro-operation processed by the renaming unit can enter the storage area of ​​the first launch queue in the order of splitting. Then, the status management unit of the first launch queue can determine whether each micro-operation is ready, that is, whether each micro-operation has obtained the data access information required by its corresponding destination register.

[0082] Specifically, the status management unit of the first launch queue can determine whether the vector register corresponding to each micro-operation is available. If it is determined to be available, it can determine whether the micro-operation has obtained the data access information required by its corresponding destination register. In this case, the ready micro-operation can be put into the ready list to wait for launch.

[0083] Since the arbitration unit of the first transmission queue executes the scheduling logic of "ready to transmit", it can directly select m micro-operations (not exceeding the transmission port bandwidth) from the ready list and send parallel transmission signals to the reading unit. After receiving the transmission signals, the reading unit can synchronously initiate m read requests to the VRF. Each request corresponds to a physical address of UOP_i to request to read the source operand in the physical address of the i-th source operand.

[0084] After obtaining the source operand, it can be written to a specified address in the shared data buffer. The shared data buffer controller can allocate a unique storage address for each UOP_i and generate an address mapping table to record the correspondence between UOP_i, buffer address, and destination physical register.

[0085] After the data writing is complete, a signal can be sent to the status management unit of the first transmit queue to mark the UOP_i as completed.

[0086] Step S1023: For each micro-operation, if it is determined that the micro-operation in the first launch queue has obtained the data access information required by its corresponding destination register, the micro-operation is written into the second launch queue.

[0087] In this embodiment, the second launch queue can be used to store structured data units containing all relevant information of a single vector instruction, but it does not have instruction execution or data processing functions.

[0088] Specifically, when all the necessary data access information for a micro-operation is ready, the micro-operation can be moved from the first launch queue to the second launch queue so that subsequent execution units can process the micro-operation uniformly.

[0089] Considering that multiple vector instructions will be received, in order to ensure that the micro-operations of the same vector instruction will not be confused with the micro-operations of other instructions, in some embodiments, a unique special identifier (special_id) is assigned to the instruction during the instruction decoding stage, and all micro-operations of the instruction are carried by this special_id; the second transmit queue will allocate a dedicated free table entry for each special_id.

[0090] In this embodiment, when a micro-operation is written to the second launch queue, the micro-operation carries a unique special_id assigned during the instruction decoding stage. Moreover, the second launch queue has reserved a dedicated free table entry for each vector instruction that has been assigned a special_id. During the writing process, the second launch queue will accurately match the dedicated table entry corresponding to the vector instruction based on the special_id carried by the micro-operation, thus avoiding confusion with the micro-operation table entries of other vector instructions.

[0091] After determining the write order based on the split order identifier (split_num) of the micro-operation, the micro-operation can be written to the specified position of the matched dedicated table entry according to the write order.

[0092] It should be noted that the dedicated free table entry is created synchronously when special_id is allocated during the decoding phase.

[0093] In this way, the targeted write process based on special_id can ensure that the micro-operations of different vector instructions are stored in complete isolation in the second launch queue, while all micro-operations of the same vector instruction are aggregated in the same dedicated table entry, which can avoid confusion with the micro-operation table entries of other vector instructions.

[0094] By employing the above technical solution, multiple micro-operations are sent to the first issue queue for parallel execution to obtain data access information. Finally, the ready micro-operations are written to the second issue queue. Through this process, the system can reduce the number of UOPs and avoid pseudo-dependencies, thereby allowing the processor to effectively unleash its out-of-order execution potential and further improve the execution efficiency of vector permutation instructions.

[0095] In some embodiments, step S103 can be implemented by steps S1031 and S1032.

[0096] Step S1031: Detect the number of micro-operations collected through the second launch queue.

[0097] In this step, the counting management module of the second launch queue can detect each special_id entry in the queue individually. Each special_id entry corresponds one-to-one with a vector permutation instruction to be processed, and only micro-operations carrying the same special_id are counted.

[0098] Specifically, for each special_id entry, the number of splits (split_cnt) of the vector instruction has been pre-written during the instruction decoding stage. This split_cnt can be used as the detection threshold for the second launch queue.

[0099] Whenever a micro-operation is written from the first launch queue to the second launch queue, it is written into a corresponding dedicated entry based on its own special_id. In this case, the counting management module of the second launch queue can increment the number of collected micro-operations in that entry by 1. For example, if the split_cnt of a vector instruction is 4, when two micro-operations are written to the corresponding entry, the real-time count of that entry will be 2.

[0100] It should be noted that the counting management module will continuously monitor each dedicated entry in the active state (Valid=1). As long as the real-time count of the entry has not reached the split_cnt threshold, it will remain in the monitoring state and wait for subsequent micro-operations to be written. If the real-time count of the entry reaches the threshold, a counting completion signal will be triggered.

[0101] Step S1032: If the number of micro-operations is consistent with the number of vector instructions split, determine that all micro-operations have been executed.

[0102] In this step, when the counting management module of the second launch queue detects that the real-time collection count of a special_id entry equals the split_cnt value of that entry, it can be determined that all micro-operations of the vector instruction corresponding to that special_id have completed data collection. Then, the status of that entry can be marked as ready (e.g., by setting the Ready flag of the entry).

[0103] By adopting the above technical solution, the omission of micro-operations can be eliminated through quantity matching, and the execution unit can be prevented from making calculation errors due to the lack of some micro-operations or data.

[0104] In some embodiments, step S103 can also be implemented by steps S1033 and S1034.

[0105] In step S1033, after determining that all micro-operations have been completed, the computation information of the source operands and vector instructions obtained from all micro-operations is sent to the execution unit through the second transmit queue.

[0106] In this step, we can first extract all the information required for the operation of the same instruction. This information includes the operation information of the source operands and vector instructions.

[0107] Specifically, based on the micro-operation split_num recorded in the table entry and the address mapping table recording the correspondence between micro-operations, buffer addresses, and destination registers, the system can batch read all collected source operands and index operands for all micro-operations corresponding to a special_id; and can extract the operation information of vector instructions from the preset storage area of ​​the dedicated table entry. The operation information of the vector instructions can be information that has been synchronously written into the table entry during the instruction decoding stage, including the instruction type (such as the specific algorithm for the substitution operation), operation precision, vector length, etc.

[0108] Once the necessary information for computation is obtained, all operands and computation information corresponding to the same special_id can be packaged into a complete data frame and sent to the execution unit, so that the execution unit can identify which vector instruction the currently received information belongs to.

[0109] Step S1034: The execution unit performs the calculation corresponding to the vector permutation instruction based on the calculation information and all received source operands.

[0110] The execution unit can be a hardware module responsible for actually performing computational operations. The execution unit receives operands and control signals from the transmit queue, and the opcode is used to guide the execution of the corresponding arithmetic or logical operations.

[0111] In this step, the execution unit can receive all the operation inputs corresponding to the same special_id sent by the second transmit queue to obtain the vector register data of the vector instruction. The vector register data includes the vector register data collected from all micro-operations, as well as operation information such as the specific permutation algorithm type, operation precision requirements, and vector length parameters of the instruction.

[0112] In one possible implementation, if the vector register includes a source register and an index register, the execution unit, after obtaining all the operation inputs, can first parse the operation information to determine the calculation rules of the vector instruction; then, based on the index operand, it can complete the directional addressing of the source operand.

[0113] Specifically, the execution unit can match the index operands with the source operands one by one according to the splitting order of the micro-operations (i.e., the split_num order). For example, for the index operand and source operand corresponding to the i-th micro-operation, the execution unit can use the value of the index operand corresponding to the i-th micro-operation as the address to extract the target data from the source data block corresponding to the source operand corresponding to the i-th micro-operation, and generate the intermediate permutation result Temp_i at that position. After obtaining the intermediate results corresponding to all micro-operations, the execution unit can concatenate these intermediate results in the split_num order according to the storage format defined by the operation information to form the final vector operation result that corresponds one-to-one with multiple destination registers.

[0114] In some embodiments, the execution unit can first perform vector operations on multiple destination registers based on the source operands according to the operation information to obtain the operation result corresponding to each destination register; then each operation result is written back to the corresponding destination register.

[0115] In this embodiment, since the number of micro-operations is equal to the number of destination registers, and the order of split_num is consistent with the numbering order of the destination registers, the execution unit binds each intermediate result Temp_i to the corresponding destination register physical address P_vd_i according to the order of split_num of the micro-operations.

[0116] Specifically, the execution unit sends the computation result to the Vector Register File (VRF) via a dedicated write-back bus, and then the write-back control module of the execution unit initiates the write-back action. Upon receiving the computation result, the VRF can directly locate the corresponding physical register storage unit based on the physical address of the destination register, and then write the computation result into the corresponding physical register storage unit.

[0117] By adopting the above technical solution, all the operation inputs of an instruction are transmitted to the execution unit at once. On the one hand, the number of bus interactions and hardware handshake overhead can be reduced, and the data transmission latency can be reduced. On the other hand, the execution unit receives a complete set of operands without any dependencies, and can directly start parallel operation without waiting for subsequent data to be transmitted or for a single instruction to be completed before processing the next one, which effectively improves the overall instruction processing throughput.

[0118] Considering that the second issue queue is used to aggregate multiple micro-operations of the same instruction and verify the matching of quantities, and that only one micro-operation is generated when the number of destination registers is 1, there is no need to aggregate multiple micro-operations. If this micro-operation is forcibly sent to the second issue queue, it will add multiple redundant steps such as entry lookup, count update, and status verification, resulting in increased instruction processing latency.

[0119] Therefore, in some embodiments, the method may further include steps S104 to S106.

[0120] Step S104: If there is only one destination register, the vector instruction is broken down into micro-operations corresponding to the destination register.

[0121] In this step, the specific implementation steps can be found in step S101. The difference is that there is only one destination register, so the decoding unit splits the macro instruction into one micro-operation (UOP). Since only one micro-operation is generated, there is no need to assign a special_id to it, nor is there a need to reserve a dedicated entry in the second transmit queue. The special_id binding and entry initialization process can be skipped directly.

[0122] Step S105: The micro-operation is sent to the first transmit queue to obtain the data access information required by the destination register corresponding to the micro-operation through the first transmit queue.

[0123] The data access information refers to the source operands in the vector register used to execute the full vector instruction.

[0124] In this step, after the micro-operation is sent to the first transmit queue, its corresponding source register physical address can be verified by the status management unit of the first transmit queue to determine its availability. If it is determined to be available, since there is only one micro-operation and no other UOP data dependencies, the operand will be ready immediately. The arbitration unit of the first transmit queue can use the ready-to-transmit logic to trigger the read unit to initiate a read request to the vector register file (VRF) to obtain the source operand corresponding to the micro-operation.

[0125] After the operands are acquired, the first launch queue marks the micro-operation as data ready and synchronously updates the status of the corresponding entry in the reorder buffer (ROB).

[0126] Step S106: If it is determined that the micro-operation in the first launch team has obtained the data access information required by its corresponding destination register, the micro-operation is sent to the execution unit so that the micro-operation can be executed by the execution unit.

[0127] In this step, after the first transmit queue determines that the micro-operation has acquired all data access information, the first transmit queue can package the micro-operation, the corresponding source operand, and the instruction's operation information (such as the permutation algorithm type and precision requirements) and send them to the execution unit so that the execution unit can parse the operation information, perform directional permutation calculation based on the source operand, generate the operation result corresponding to the unique destination register, and write the result directly back to the physical address of the destination register.

[0128] By adopting the above technical solution, when there is only one destination register, the second issue queue can be skipped directly, which can avoid redundant processes and reduce instruction execution latency.

[0129] Based on the foregoing embodiments, this application provides an instruction processing apparatus. Figure 2 This is a block diagram of an instruction processing device provided in an embodiment of this application, such as... Figure 2 As shown, the instruction processing device 200 includes a splitting unit 201, a parallel execution unit 202, and an execution unit 203.

[0130] The splitting unit 201 is used to split the vector instruction into multiple micro-operations corresponding to multiple destination registers in response to receiving the vector instruction to be processed; the micro-operations are used to obtain the data access information required by their corresponding destination registers; the parallel execution unit 202 is used to execute each micro-operation in parallel; and when it is determined that all micro-operations have been executed, the execution unit is triggered to execute the calculation operation; the execution unit 203 is used to perform vector operations on multiple destination registers based on the data access information obtained from all micro-operations in response to the calculation operation.

[0131] In some embodiments, the parallel execution unit 202 includes a first launch queue and a second launch queue.

[0132] The splitting unit 201 is used to send multiple micro-operations to a first launch queue; the first launch queue is used to execute multiple micro-operations in parallel to obtain the data access information required by the destination register corresponding to each micro-operation; and write the micro-operations with the obtained data access information into a second launch queue; the second launch queue is used to send the source operands obtained from all micro-operations and the operation information of the vector instruction to the execution unit when it is detected that the number of collected micro-operations is consistent with the number of splits of the vector instruction, so that the execution unit can perform the calculation corresponding to the vector instruction based on the operation information and all the received source operands.

[0133] In some embodiments, when there is only one destination register, the splitting unit 201 is further configured to split the vector instruction into micro-operations corresponding to the destination register and send the micro-operations to the first issue queue; the first issue queue is further configured to obtain the data access information required by the destination register corresponding to the micro-operation; and when it is determined that the micro-operation has obtained the data access information required by its corresponding destination register, the micro-operation is sent to the execution unit 203 so that the execution unit 203 can execute the micro-operation based on the data access information.

[0134] By adopting the above technical solution, vector instructions are split into multiple micro-operations corresponding to multiple destination registers. Each micro-operation is only responsible for generating data access information for its corresponding destination register. In this way, the number of micro-operations is linearly related to the number of destination registers, avoiding quadratic growth and reducing the number of micro-operations. At the same time, since each destination register is handled by an independent micro-operation, there are no write conflicts between these micro-operations, and they can be executed in parallel without forcibly establishing dependency chains, thus making full use of the processor's out-of-order execution capability. In addition, each micro-operation only needs to access the necessary source register data, reducing redundant readings of source data and lowering the pressure on register ports and dynamic power consumption.

[0135] In the embodiments of this application, specific implementation methods can be referred to the description of the foregoing instruction processing method. The description of the above method embodiments is similar to the description of the above device embodiments and has similar beneficial effects. For technical details not disclosed in the method embodiments of this application, please refer to the description of the device embodiments of this application for understanding.

[0136] The following describes the application of the instruction processing method provided in the embodiments of this application in a real-world scenario, mainly involving an execution pipeline and method for RISC-V vector permutation instructions.

[0137] The RISC-V Vector Extension (RVV) instruction set provides unprecedented computing power and flexibility for modern compute-intensive applications such as artificial intelligence and high-performance computing. Vector permutation instructions, such as `vrgather`, `vcompress`, and `vslide`, enable arbitrary rearrangement of data within vector registers, thus elevating the capabilities of vector extensions from simple data-parallel computation to complex data-dependent parallel computation, allowing computation results to depend on dynamic, data-driven indexes. This enables hardware to efficiently handle unstructured data access patterns that previously required extensive scalar code and branching statements.

[0138] As shown in Table 1, this table lists several types of computational optimizations and typical applications of vector permutation instructions. The `Vrgather` instruction can transform irregular memory access patterns such as "for loop + array index access" into efficient vectorized operations; the `vcompress` instruction can introduce "if-then" structures into vector computation, avoiding destructive branches and enabling efficient execution of loops with conditional judgments that were originally difficult to vectorize; the `vslide` instruction can transform serial dependencies on neighboring elements (data[i-1], data[i+1]) into parallel vector operations through data rearrangement.

[0139] Table 1

[0140]

[0141] Vector extension can combine multiple vector registers and treat them as a single vector register group, represented by the Vector Length Multiplier (LMUL). The bit width of each element in the vector register is represented by the Selected Element Width (SEW). Figure 3 This is a schematic diagram of a register group structure provided in the background art of this application. Figure 3 As shown, when LMUL=1, 2, 4, each register group contains registers 1, 2, and 4. In modern high-performance processors, breaking down macro instructions into a series of simpler micro-operations is a core design paradigm.

[0142] Ordinary vector expansion instructions follow a static, position-dependent pattern, i.e., a one-to-one correspondence computation model. In this model, the computation of each element in the target vector depends only on the elements in the two source vectors that occupy the same position. This strict, position-independent correspondence makes the decomposition of its micro-operations extremely simple and efficient. Figure 4 This is a schematic diagram illustrating the element dependency relationship in a register group, as provided in the background technology of this application. Figure 4 As shown, when the vector register width is 128 bits, LMUL is 4 and SEW is 32. Taking the vadd.vvv8,v16,v24 instruction as an example, Figure 4 It shows the register numbers in each register group of the instruction and the elements that the calculation of each element in the destination register depends on.

[0143] Figure 5 This is a schematic diagram of a splitting micro-operation provided in the background technology of this application. Figure 5 As shown, based on Figure 4As shown by this clear dependency, the vadd.vv instruction can be broken down into LMUL (i.e., 4) completely independent micro-operations, each of which computes a destination register result and depends only on the corresponding source register.

[0144] Figure 6 This is a schematic diagram illustrating the dependency relationship between the destination register and the source register of an instruction, as provided in the background technology of this application. Figure 6 As shown, Figure 6 It demonstrates the dependency relationship between the destination and source registers of vrgather.vv (vector permutation instruction), vcompress.vm (vector compression instruction), and vslidedown.vi (vector shift instruction).

[0145] At the microarchitecture level, existing technologies employ a naive micro-operation decomposition scheme when implementing vector substitution instructions to reduce control logic complexity and utilize the decomposition and execution pipeline of ordinary vector extension instructions. Since the result in the destination register of a substitution instruction may depend on any physical register in the source register set, the source register set needs to be traversed for each destination register in the vd register set when decomposing micro-operations. Under these conditions, to ensure the correctness of the result, operations related to a destination register need to be manually decomposed into LMUL micro-operations, each with the same logical destination register, by introducing a dependency chain.

[0146] Therefore, a vector permutation instruction will be split into LMUL^2 micro-operations. This number of micro-operations, which increases with the square of LMUL, can severely congest the pipeline. When LMUL is large, the micro-operations split from a single instruction may quickly fill the issue queue, blocking the entry and execution of all subsequent instructions.

[0147] Figure 7 This is a schematic diagram of the micro-operation breakdown of an instruction provided in the background technology of this application, such as... Figure 7 As shown, for the splitting of vector permutation instructions (such as the vrgather.vv instruction), since it is necessary to traverse the source register group for each destination register, 64 micro-operations need to be split during instruction splitting, which can be specifically split into micro-operations 1 to 64.

[0148] Figure 8 This is a schematic diagram illustrating the clock cycles required for instruction execution, provided in the background section of this application. Figure 8 As shown, Figure 8The demonstration shows the clock cycles required to execute the vrgather.vv instruction with LMUL=4 in the existing scheme. The artificially introduced dependency chain forces micro-operations with the same destination register to be executed sequentially, preventing the utilization of the multi-issue and out-of-order execution capabilities of the superscalar processor. This limits the parallelism of vector computation and causes the instruction execution latency to increase linearly. Furthermore, the repeated traversal of the entire source register set leads to a large number of redundant reads of the index register and data register, greatly wasting valuable vector register read port bandwidth and power consumption.

[0149] As shown in Table 2, Table 2 lists the number of micro-operations, instruction execution cycles, and source register reads for each LMUL vector permutation instruction under the existing scheme.

[0150] Table 2

[0151]

[0152] In related technologies, when splitting micro-operations according to existing schemes, it is necessary to traverse the source register group for each destination register, and at the same time, dependency chains are artificially introduced, which has the following problems.

[0153] 1. The number of micro-operations exploded.

[0154] The number of micro-operations increases quadratically with LMUL. When LMUL is large (such as 4 or 8), the micro-operations generated by a single instruction will quickly fill the issue queue, completely blocking the entry and execution of all subsequent instructions.

[0155] 2. False dependencies and resource waste.

[0156] To ensure the correctness of the results, the LMUL micro-operations targeting the same physical register are artificially constructed into a serial dependency chain, forcing them to be executed sequentially, and causing the instruction execution latency to increase linearly with the LMUL size. In addition, the repeated traversal of the entire source register set greatly wastes the bandwidth and power consumption of the vector register read port.

[0157] Therefore, this application proposes an optimization scheme to address the problems of the exploding number of micro-operations in splitting vector substitution instructions and the low execution efficiency caused by dependency chains between micro-operations in the prior art. By establishing a special pipeline for vector substitution instructions, the values ​​of all dependent registers of the vector substitution instruction are first collected, and then sent together to the execution unit. In this way, a vector substitution instruction only needs to be split into LMUL micro-operations, and there are no dependencies between the micro-operations. This scheme can avoid pipeline blockage, eliminate pseudo-dependencies, effectively unleash the potential of out-of-order execution, and significantly improve the execution efficiency of vector substitution instructions.

[0158] In this embodiment, a dedicated pipeline for vector permutation instructions is designed, employing different micro-operation splitting schemes to significantly improve the execution efficiency of vector permutation instructions. Compared with existing technologies, the scheme of traversing the source register group for each destination register is abandoned. Instead, a scheme is adopted that first collects the dependent data into a special issue queue, and then sends them together to the execution unit. This significantly reduces the number of micro-operations that need to be split and eliminates the dependency chains between micro-operations, allowing all micro-operations to be executed independently. This unlocks the potential of out-of-order execution, improves execution efficiency, and reduces vector register read port bandwidth and power consumption. The core improvements are reflected in the following two aspects.

[0159] 1. The number of micro-operations is effectively controlled.

[0160] The existing scheme requires traversing the source register group for each destination register. Each micro-operation in the existing scheme is only responsible for collecting data. The number of micro-operations is reduced from LMUL^2 to LMUL, eliminating the possibility of pipeline blockage and reducing redundant reads of registers, thus saving valuable vector register read port bandwidth and power consumption.

[0161] 2. Eliminate pseudo-dependencies, and micro-operations can be executed out of order.

[0162] In existing schemes, each micro-operation only calculates and updates a subset of elements in the destination register. Therefore, among micro-operations related to the same destination register, older micro-operations need to serve as source operands for younger micro-operations to ensure the accuracy of the final result. This necessitates that these micro-operations be executed sequentially, leading to inefficiency. The existing scheme, however, splits micro-operations into smaller ones that only collect data, and there are no dependencies between them. After all data collection is complete, the execution unit can directly calculate the complete results for all destination registers, effectively utilizing the concurrency of out-of-order execution and improving execution efficiency.

[0163] Figure 9 This is a schematic diagram of a processor pipeline architecture provided in an embodiment of this application, such as... Figure 9 As shown, the processor includes an instruction fetch unit 901, a decoding unit 902, a renaming unit 903, a dispatch unit 904, a first issue queue 905, a second issue queue 906, an execution unit 907, and a write-back unit 908.

[0164] In this embodiment, the instruction fetch unit 901 reads the instruction stream from the instruction cache and sends it to the decoding unit 902. The decoding unit 902 identifies vector permutation instructions (such as vrgather) and determines the number of micro-operations (split_cnt) to be split based on the LMUL value. When LMUL > 1, an idle entry can be found in the second issue queue 906, and a unique number special_id is generated for that entry. This special_id will serve as a tag, following all the micro-operations split from the macro instruction.

[0165] The renaming unit 903 renames the logical registers in the UOP and maps them to physical registers to eliminate pseudo-data dependencies such as write-after-write (WAW) and read-after-write (WAR), preparing for subsequent out-of-order execution. Micro-operations from the same macro instruction will carry the same special_id.

[0166] The distribution unit 904 can send micro-operations carrying special_id (i.e., instructions with LMUL>1) to the first transmit queue 905; and also send UOPs without special_id (i.e., instructions with LMUL=1 or ordinary scalar instructions) to the first transmit queue 905.

[0167] For UOPs carrying special_id, after the operands are read in the first launch queue 905, they are not sent directly to the execution unit 907. Instead, the data is packaged and sent to the corresponding entry in the second launch queue 906 according to the special_id. For UOPs without special_id, they can be directly launched to the execution unit 907 below for calculation.

[0168] The second transmit queue 906 maintains a counter. When the number of collected micro-operation data equals the split_cnt determined during decoding, it indicates that all data for the instruction is ready. At this point, the complete data of all micro-operations within the entire entry (multiple source operands, index operands, etc.) is transmitted as a single packet to the execution unit 907 above for batch computation.

[0169] By adopting the above technical solution, a special processing path involving the second launch queue 906 can be introduced, which can efficiently process vector instructions that need to be broken down into multiple micro-operations.

[0170] Figure 10 This is a schematic diagram of a special launch queue architecture provided in an embodiment of this application, such as... Figure 10As shown, this special launch queue (i.e., the second launch queue in the above embodiment) can collect and synchronize all the data of a vector macro instruction that needs to be split into multiple micro-operations, and then submit it to the execution unit in batches at once.

[0171] The special launch queue can include multiple entries, each entry corresponding to a vector macro instruction, specifically including vector macro instruction 1 to vector macro instruction N; for each vector macro instruction, it can include multiple fields, specifically including but not limited to Valid (valid bit field), split_cnt (split count field), and micro-operation field 1 to micro-operation field N.

[0172] In this embodiment, the decoding unit allocates an entry for a vector instruction, writing Valid=1 and split_cnt. Subsequently, the various micro-operations split from this instruction read data in parallel from the first transmit queue and then place the data into the micro-operation slot specified by this entry.

[0173] The internal logic of the special launch queue continuously monitors each valid entry. When the number of micro-operation slots filled with data in an entry reaches its split_cnt value, it indicates that all data for that instruction is ready, and at this point, the entry gains launch rights. It can then send the entire data packet—that is, all ready data in slots UOP0-7, along with shared information not listed in the diagram (such as eu_sel, frm, vl, vtype, etc.)—to the execution unit at once.

[0174] The shared information may include, but is not limited to, eu_sel (which execution unit to select), frm (rounding mode), vl (vector length), etc.

[0175] In this way, the complex and serial scheduling and dependency problems of multi-micro-operations in traditional pipelines can be transformed into a simple process of collection, packaging and batch execution. This can solve the problems of the explosion of the number of micro-operations when the LMUL is large, serialization caused by pseudo-dependencies, and intense resource contention, thereby significantly improving the execution efficiency of vector permutation instructions.

[0176] Figure 11 This is a flowchart of a method for processing vector permutation instructions provided in an embodiment of this application, as shown below. Figure 11 As shown, the method includes the following steps.

[0177] Step S1101, command acquisition.

[0178] In this step, the instruction fetch unit retrieves vector permutation instructions from the instruction cache and passes the value of the control and status register (VTYPE) and instruction-related data to the decode unit.

[0179] Step S1102: Break down the macro instruction into multiple micro-operations.

[0180] In this step, if LMUL > 1, a special_id can be assigned to the vector permutation macro instruction, and the macro instruction is marked as an instruction that needs to be sent to the Special Issue Queue (second send queue), where special_id is the sequence number of any free entry in the Special Issue Queue. Then, the Decode unit sets the Valid entry corresponding to special_id to 1 and writes LMUL to split_cnt. If LMUL ≤ 1, the macro instruction can only be split into a single micro-operation, and no special_id or marking is required.

[0181] After splitting the macro instruction into LMUL micro-operations, each micro-operation can be assigned a split number spilt_num and sent to the Rename unit.

[0182] Step S1103: Rename the register.

[0183] The source and destination registers of each UOP can be renamed and mapped to physical registers through the renaming unit.

[0184] Step S1104, out-of-order scheduling.

[0185] The Dispatch unit can sequentially assign reorder buffer (ROB) numbers to all micro-operations and send the micro-operations to the Issue Queue to collect source operands and related data.

[0186] The ready micro-operations are arbitrated through the Issue Queue (first issue queue), and tagged micro-operations are sent to the Special Issue Queue (second issue queue). Untagged micro-operations are sent directly to the execution unit to calculate the result. Because the dependency chain between micro-operations is eliminated in this embodiment, younger micro-operations do not need to wait for older micro-operations to complete, and all micro-operations can be ready simultaneously, making full use of the out-of-order processor's issue bandwidth.

[0187] Step S1105: The second launch queue collects data and executes.

[0188] The corresponding micro-operation position for the entry can be written through the Special Issue Queue based on the special_id and split_num sent by the Issue Queue. When the number of collected micro-operations equals split_cnt, the instruction for this entry is ready and can be sent to the execution unit.

[0189] Step S1106: After the execution unit completes the calculation, the result is written back to the physical register.

[0190] Figure 12 This is a schematic diagram illustrating the breakdown of a vector permutation instruction provided in an embodiment of this application, as shown below. Figure 12 As shown, for the splitting of vector permutation instructions (such as the vrgather.vv instruction), since it is not necessary to traverse the source register group for each destination register, only 8 micro-operations are needed, specifically micro-operations 1 to 8. Furthermore, since there are no dependencies between micro-operations, each micro-operation is only responsible for reading the required source registers and related data, and all micro-operations can be executed concurrently and ready at the same time.

[0191] Figure 13 This is a schematic diagram illustrating the clock cycles required to execute a vector permutation instruction according to an embodiment of this application, as shown below. Figure 13 As shown, since there is no dependency chain, all micro-operations can be ready at the same time. Multiple micro-operations in the special launch queue collect all the required data in parallel, send them to the execution unit, and write them back. It takes a total of 6 clock cycles, which is a significant reduction in time compared to the original scheme.

[0192] In this embodiment, multiple micro-operations may include micro-operations 1 to 7, which can be executed simultaneously and in parallel within the same clock cycle, representing their respective pipeline stages. Specifically, micro-operations 1 to 7 can simultaneously be in the wake-up phase in the first cycle, in the transmit phase in the second cycle, and in the data preparation phase in the third cycle. Furthermore, once all the data for micro-operations 1 to 7 is prepared, an independent micro-operation is added to perform calculations on the prepared data.

[0193] As shown in Table 3, this table illustrates the number of micro-operations, instruction execution cycles, and source register reads required for vector permutation instructions under various LMUL values. In this scheme, the clock cycles required for all vector permutation instructions with LMUL > 1 become a fixed value of 6. When LMUL ≤ 1, there is no need to enter a special issue queue, and the required clock cycles remain unchanged compared to existing schemes. When LMUL = 2, 4, and 8, the number of clock cycles can be reduced by 1-13, significantly improving execution efficiency. The number of micro-operations is reduced by 2-56, eliminating the possibility of pipeline congestion. Simultaneously, the number of reads for each source register becomes only 1, resolving the issue of repeated reads compared to existing schemes.

[0194] Table 3

[0195]

[0196] In this embodiment, the method for splitting vector permutation instructions has been modified. The method of traversing source registers for each destination register has been eliminated, thereby removing the dependency chains between micro-operations. This significantly reduces the number of micro-operation splits, resolving the issues of excessive micro-operations potentially blocking the pipeline and the low execution efficiency caused by dependencies between micro-operations, thus improving the parallelism of instruction execution. A special issue queue (the second issue queue in the above embodiment) has been added to collect micro-operation data. Furthermore, the number of split micro-operations (LMUL) is used to select whether to enter the special issue queue, ensuring that execution efficiency remains the same when LMUL ≤ 1, and significantly improves execution efficiency when LMUL > 1.

[0197] This application provides a chip product that includes the instruction processing device described in the above embodiments.

[0198] This application provides a computer device that includes the chip described above.

[0199] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the instruction processing method in any of the above embodiments.

[0200] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above methods, chip products, and computer device embodiments are similar to the descriptions of the above instruction processing method embodiments, and have similar beneficial effects. For technical details not disclosed in the embodiments of the methods, chip products, and computer devices of this application, please refer to the descriptions of the instruction processing method embodiments of this application for understanding.

[0201] Figure 14 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application, such as... Figure 14 As shown, the hardware entity of the computer device 1400 includes a processor 1401 and a memory 1402, wherein the memory 1402 stores a computer program that can run on the processor 1401, and the processor 1401 executes the program to implement the steps in the method of any of the above embodiments.

[0202] The memory 1402 stores computer programs that can run on the processor. The memory 1402 is configured to store instructions and applications that can be executed by the processor 1401. It can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 1401 and various modules in the computer device 1400. It can be implemented by flash memory or random access memory (RAM).

[0203] The processor 1401 implements the steps of the above method when executing the program. The processor 1401 typically controls the overall operation of the computer device 1400.

[0204] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0205] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0206] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device 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, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0207] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0208] Furthermore, in the various embodiments of this application, all functional units can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units. Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0209] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also 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 related technologies, 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 an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part 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 mobile storage devices, ROM, magnetic disks, or optical disks.

[0210] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. An instruction processing method, characterized in that, The method includes: In response to receiving a vector instruction to be processed, the vector instruction is split into multiple micro-operations corresponding to multiple destination registers; the micro-operations are used to obtain the data access information required by their corresponding destination registers. Each of the micro-operations described is executed in parallel; Upon determining that all the micro-operations have been completed, the execution unit is triggered to perform a computation operation; wherein, in response to the computation operation, the execution unit performs vector operations on the plurality of destination registers based on the data access information obtained from all the micro-operations.

2. The method according to claim 1, characterized in that, The parallel execution of each of the micro-operations includes: Send the multiple micro-operations to the first launch queue; Multiple micro-operations are executed in parallel through the first launch queue to obtain the data access information required by the destination register corresponding to each micro-operation; the data access information is the source operand in the vector register used to execute the full vector instruction. For each micro-operation, if it is determined that the micro-operation in the first launch queue has obtained the data access information required by its corresponding destination register, the micro-operation is written into the second launch queue.

3. The method according to claim 2, characterized in that, The determination that all the micro-operations have been completed includes: The number of micro-operations collected is detected by the second launch queue; If the number of micro-operations is consistent with the number of splits of the vector instruction, then all micro-operations are determined to have been executed.

4. The method according to claim 3, characterized in that, The triggering execution unit performs calculation operations, including: Once it is determined that all the micro-operations have been completed, the computation information of the source operands and the vector instructions obtained from all the micro-operations is sent to the execution unit through the second transmission queue; The execution unit performs the calculation corresponding to the vector instruction based on the received source operands, according to the computation information.

5. The method according to claim 4, characterized in that, The step of performing the calculation corresponding to the vector instruction through the execution unit, based on the calculation information and all received source operands, includes: The execution unit performs vector operations on multiple destination registers based on the source operands according to the operation information to obtain the operation result corresponding to each destination register. Write each of the operation results back to the corresponding destination register.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: When there is only one destination register, the vector instruction is broken down into micro-operations corresponding to the destination register; The micro-operation is sent to the first transmit queue to obtain the data access information required by the destination register corresponding to the micro-operation through the first transmit queue; the data access information is the source operand in the vector register used to execute the full vector instruction; If it is determined that the micro-operation in the first launch team has obtained the data access information required by its corresponding destination register, the micro-operation is sent to the execution unit so that the micro-operation can be executed by the execution unit.

7. An instruction processing device, characterized in that, The instruction processing device includes a splitting unit, a parallel execution unit, and an execution unit; wherein... The splitting unit is configured to, in response to receiving a vector instruction to be processed, split the vector instruction into multiple micro-operations corresponding to multiple destination registers respectively; the micro-operations are used to obtain the data access information required by their corresponding destination registers. The parallel execution unit is used to execute each of the micro-operations in parallel; and, upon determining that all the micro-operations have been completed, triggers the execution unit to perform a computational operation. The execution unit is configured to perform vector operations on the plurality of destination registers in response to the computation operation, based on the data access information obtained from all the micro-operations.

8. The instruction processing apparatus according to claim 7, characterized in that, The parallel execution unit includes a first launch queue and a second launch queue; wherein... The splitting unit is used to send multiple micro-operations to the first transmission queue; The first transmit queue is used to execute multiple micro-operations in parallel to obtain the data access information required by the destination register corresponding to each micro-operation; and to write the micro-operation with the obtained data access information into the second transmit queue. The second transmission queue is used to send the source operands obtained from all the micro-operations and the operation information of the vector instruction to the execution unit when it is detected that the number of collected micro-operations is consistent with the number of splits of the vector instruction. The execution unit then performs the calculation corresponding to the vector instruction based on the received source operands according to the operation information.

9. The instruction processing apparatus according to claim 8, characterized in that, When the number of destination registers is one, The splitting unit is further configured to split the vector instruction into micro-operations corresponding to the destination register, and send the micro-operations to the first transmit queue; The first transmit queue is further configured to acquire the data access information required by the destination register corresponding to the micro-operation; and, upon determining that the micro-operation has acquired the data access information required by the destination register corresponding to it, send the micro-operation to the execution unit so that the execution unit can execute the micro-operation based on the data access information.

10. A chip product, characterized in that, The chip product includes the instruction processing apparatus as described in any one of claims 7 to 9.

11. A computer device, characterized in that, The computer device includes the chip product as described in claim 10.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

Images