Data processing method, target processor, system on chip, and computing device

Abstract

Embodiments of the present specification provide a data processing method, a target processor, a system on chip and a computing device, wherein the data processing method is applied to a control unit of the target processor, wherein the target processor further comprises a data operation unit and an operand buffer, and the method comprises: obtaining a data operation instruction, wherein the data operation instruction carries a register number of a current operand; querying whether a data table item of the current operand is recorded in a buffer state table of the operand buffer based on the register number of the current operand, wherein the buffer state table records data table items of each buffered operand stored in the operand buffer, and each buffered operand is transferred from a register stack to the operand buffer; if yes, scheduling the data operation unit to read the buffered operand from the operand buffer as the current operand, executing the data operation instruction on the current operand, and outputting a current operation result, thereby improving instruction execution efficiency, energy efficiency ratio and resource utilization of the target processor.

Description

Technical Field

[0001] This specification relates to the technical field of hardware development, and in particular to a data processing method, a target processor, a system-on-a-chip, and a computing device. Background Technology

[0002] As hardware development evolves towards multi-core and high energy efficiency, modern processor architectures face the challenge of synergistic optimization between instruction-level parallelism and data provisioning efficiency.

[0003] Currently, the core operand storage medium relies on the register file, and the design of multiple physical read / write ports of the register file supports parallel access to multiple instructions. However, with the exponential growth in instruction throughput requirements, the number of physical read / write ports and access bandwidth of the register file have gradually become key bottlenecks restricting performance improvement. Frequent direct access to the register file during instruction execution can easily lead to contention for physical read / write ports of the register file, resulting in accumulated instruction execution latency and weakening instruction execution efficiency. At the same time, redundant operations caused by high-density data movement further aggravate dynamic power consumption. Moreover, the static storage mapping mechanism of the register file is difficult to adapt to the dynamic reuse characteristics of operands, causing highly reusable data to be unable to reside effectively in the nearest storage level, resulting in frequent storage resource conflicts, increased data migration overhead, and reduced processor energy efficiency and resource utilization. Summary of the Invention

[0004] In view of the above, embodiments of this specification provide a data processing method. One or more embodiments of this specification also relate to a target processor, a system-on-a-chip, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a data processing method is provided, applied to a control unit of a target processor, wherein the target processor further includes a data processing unit and an operand buffer, comprising: Get the data operation instruction, where the data operation instruction carries the register number of the current operand; Based on the register number of the current operand, query the buffer status table of the operand buffer to see if there is a data table entry for the current operand. The buffer status table records the data table entries for each buffer operand stored in the operand buffer. Each buffer operand is transferred from the register file to the operand buffer. If so, the scheduling data processing unit reads the buffered operand from the operand buffer as the current operand, executes the data processing instruction on the current operand, and outputs the current operation result.

[0006] According to a second aspect of the embodiments of this specification, a target processor is provided, including a control unit, a data processing unit, and an operand buffer; The control unit is used to acquire data operation instructions, which carry the register number of the current operand; based on the register number of the current operand, it queries the buffer status table of the operand buffer to see if there is a data table entry for the current operand, where the buffer status table records the data table entries of each buffered operand stored in the operand buffer, and each buffered operand is transferred from the register file to the operand buffer; if so, it schedules the data operation unit to read the buffered operand from the operand buffer as the current operand, executes the data operation instructions on the current operand, and outputs the current operation result.

[0007] According to a third aspect of the embodiments of this specification, a system-on-a-chip is provided, including a plurality of on-chip components, the plurality of on-chip components including a target processor; The target processor is used to execute computer programs / instructions, which, when executed by the processor, implement the steps of the data processing method described above.

[0008] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and target processor; The memory is used to store computer programs / instructions, and the target processor is used to execute the computer programs / instructions, which, when executed by the target processor, implement the steps of the above-described data processing method.

[0009] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a target processor, implement the steps of the data processing method described above.

[0010] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a target processor, implement the steps of the data processing method described above.

[0011] In one embodiment of this specification, a data processing method is provided, applied to a control unit of a target processor, wherein the target processor further includes a data processing unit and an operand buffer, comprising: acquiring a data processing instruction, wherein the data processing instruction carries the register number of the current operand; based on the register number of the current operand, querying whether the buffer status table of the operand buffer records a data table entry for the current operand, wherein the buffer status table records data table entries for each buffered operand stored in the operand buffer, and each buffered operand is transferred from the register file to the operand buffer; if so, scheduling the data processing unit, reading the buffered operand from the operand buffer as the current operand, executing the data processing instruction on the current operand, and outputting the current operation result.

[0012] Based on register renaming design, the data buffer is indexed by the register number of the operand. During the instruction execution phase, highly reusable buffered operands are preferentially obtained from the operand buffer to schedule and execute data operation instructions and output operation results. While maintaining the logical consistency of registers, the reusability of operands is utilized to reduce the frequency of direct access to the register file, reduce the read and write bandwidth requirements of the register file, and improve instruction execution efficiency, energy efficiency and resource utilization of the target processor. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a data processing method provided in one embodiment of this specification; Figure 2 This is a schematic diagram of the architecture of the target processor in a data processing method provided in one embodiment of this specification; Figure 3 This is a schematic diagram of the structure of a target processor provided in one embodiment of this specification; Figure 4 This is a schematic diagram of the structure of a system-on-a-chip provided in one embodiment of this specification; Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0014] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0015] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0016] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0017] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0018] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0019] Reduced Instruction Set Computing (RISC): A processor architecture design philosophy that emphasizes using a smaller number of simple instructions to build a processor in order to improve the processor's execution efficiency and speed.

[0020] Reduced Instruction Set Computing (RISC) Processor: A processor designed based on the RISC concept, characterized by a shorter instruction pipeline, fixed instruction format, and simple addressing modes, enabling high-speed processing.

[0021] Cache: A high-speed data temporary storage component located between the processor core and main memory. It is used to store copies of data that the processor has recently accessed frequently, thereby improving data access efficiency by reducing the number of direct accesses to main memory.

[0022] Tensor Processing Engine (TPE): A hardware acceleration unit dedicated to efficiently performing matrix / tensor operations. Through parallel computing architecture and dedicated data path design, it achieves hardware-level acceleration for large-scale matrix / tensor multiplication, convolution, and other operations.

[0023] Matrix Multiply-Accumulate Instruction (MMA): A composite computation instruction that can complete matrix multiplication and accumulation operations in a single instruction cycle. By reducing the explicit storage requirements of intermediate results, it significantly improves the throughput and energy efficiency of matrix computation.

[0024] Instruction Pipeline: A processor parallel execution technique that breaks down instruction processing into multiple stages such as instruction fetch, decode, execute, memory access, and write-back, thereby increasing instruction throughput by overlapping the processing stages of different instructions.

[0025] Data Path: A collection of hardware logic units within the processor used for transmitting and manipulating data. It includes components such as arithmetic logic units, inter-register connection channels, and multiplexers, and is responsible for executing the data processing flow defined by the instructions.

[0026] Currently, in processor architectures designed for matrix computation, there is a structural imbalance between the computational throughput of the arithmetic unit and the data supply capacity of the storage layer. Especially in intensive computing scenarios such as deep learning, the frequent repeated loading of the same matrix data blocks from memory significantly exacerbates the read bandwidth pressure on the register file. The explicit data reuse declaration mechanism of matrix instructions is difficult to adapt to the multidimensional data reuse characteristics of matrix operations.

[0027] By employing an extensible semantic tagging mechanism for matrix multiplication and accumulation instruction sets, this approach attempts to compress multi-stage computation processes into single-instruction operations through explicit instruction-level declarations (such as data preloading, buffer reuse, and resource release), thereby reducing the number of data transfer operations.

[0028] For example, a matrix instruction format is shown below: tcgen05.mma.cta_group.kind.collector_usage[d-tmem],a-desc,b-desc,idesc,{disable-output-lane},enable-input-d{,scale-input-d}; The "collector_usage" in the mnemonic specifies operand reuse information, controls the lifetime of the processor's internal buffer, supports buffer control of A and B matrices, and ensures that operands are reused internally as much as possible after being read. The specific meanings are as follows: collector_usage={.collector::buffer::op} ::buffer={::a} ::op={::fill,::use,::lastuse,::discard*} Taking operand A as an example, the following collector buffer operations can be specified, as shown in Table 1:

[0029] Table 1 tcgen05.mma.cta_group.kind.collector_usage[d-tmem],a-desc,b-desc,idesc,{disable-output-lane},enable-input-d{,scale-input-d}; tcgen05.mma.cta_group.kind.collector_usage[d-tmem],a-desc,b-desc,idesc,{disable-output-lane},enable-input-d{,scale-input-d}; This mechanism forces the software layer to explicitly declare hardware buffering strategies (such as specifying the precise timing of operand loading, reuse, or release) by embedding micro-architectural details like buffer hierarchy and data residency period into instruction semantic tags. This results in deep coupling between the programming interface and the underlying hardware resource management logic, significantly increasing the complexity of algorithm adaptation and the burden of code maintenance for developers. Furthermore, this mechanism only optimizes operand buffering control in one direction and lacks a dynamic awareness mechanism for the data reuse characteristics of the destination register. As a result, the write-back phase of the computation results is still limited by the fixed port allocation strategy of the register file, and it cannot adaptively adjust the data residency time and storage resource allocation priority according to the characteristics of the computation task, leading to low register port utilization efficiency and idle and wasted storage resources.

[0030] Therefore, there is an urgent need for a hardware and software collaboration mechanism that can implicitly perceive data reuse patterns, autonomously decide on buffer lifecycles, and maintain the transparency of programming interfaces, in order to solve the mutual exclusion problem between storage optimization and development efficiency, and achieve a dual improvement in bandwidth utilization efficiency and dynamic scheduling of hardware resources.

[0031] This specification provides a data processing method, and also relates to a target processor, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0032] See Figure 1 , Figure 1 The flowchart illustrates a data processing method according to an embodiment of this specification, applied to the control unit of a target processor. The target processor further includes a data processing unit and an operand buffer, and includes the following specific steps: Step 102: Obtain the data operation instruction, which carries the register number of the current operand.

[0033] The target processor is a hardware computing device that executes program instructions. It includes core components such as a control unit, data processing unit, register file, and operand buffer, used to achieve efficient processing of the instruction stream and data operations. The target processor can be designed based on different Instruction Set Architectures (ISAs) to support various computational tasks, from simple scalar operations to complex matrix operations. Its architecture design typically aims to improve throughput, reduce power consumption, and optimize resource utilization, and alleviates register file access bottlenecks by introducing mechanisms such as operand buffers. The target processor can be an ARM architecture processor, an x86 architecture processor, a RISC-V architecture processor, or a dedicated accelerated processor (such as a tensor execution engine optimized for deep learning, which accelerates large-scale matrix operations through dedicated hardware, significantly improving computational efficiency). No restrictions are placed on the processor architecture of the target processor here.

[0034] The control unit is a processor unit used to execute instruction fetching, decoding, reading, and writing back operations. The control unit coordinates various units, such as the data processing unit and operand buffer, to complete the instruction's lifecycle. For example, in a RISC-V-based processor, the control unit fetches an instruction from the instruction cache, analyzes the matrix multiplication and accumulation required by the instruction, and then issues corresponding control signals to the data processing unit and other relevant units to complete the operation.

[0035] The data processing unit (DMU) is a processor unit that performs data computations, including but not limited to arithmetic operations, logical operations, and bit manipulations. The DMU is the unit within the target processor that directly processes data, typically containing one or more Arithmetic Logic Units (ALUs) specifically designed for mathematical operations and logical comparisons. Optionally, the DMU is equipped with a size verification circuit, including a data alignment module and a bit-width matcher. When the verification circuit detects that the number of elements in the size field is less than the nominal matrix length required by the instruction, it triggers a data zero-padding extension unit to perform trailing zero padding on the buffer operands. When a bit-width mismatch is detected, it triggers a type conversion unit to perform fixed-point to floating-point or half-precision to full-precision data type conversion. For example, in a tensor execution engine that executes matrix multiplication and accumulation instructions, the DMU will perform the multiplication of two matrices and accumulate the results. This process involves a large number of floating-point operations, requiring the DMU to have efficient parallel processing capabilities. The operand buffer is a temporary storage medium located between the register file and the data operation unit. It is used to temporarily store highly reusable operands, reducing frequent accesses to the register file. The operand buffer optimizes data provisioning efficiency. By recording operand usage, it allows the reuse of data already loaded into the buffer, avoiding unnecessary memory read operations. For example, when executing a series of matrix multiplication and accumulation instructions that depend on the same set of matrix data, this matrix data can first be loaded into the operand buffer. Subsequent data operations can then directly read the required data from the buffer, reducing the number of accesses to main memory or the register file.

[0036] The data operation instruction is an instruction set instruction that instructs a target processor to perform a specific type of numerical calculation or data processing. Each data operation instruction explicitly specifies the type of operation to be performed (e.g., addition, multiplication), the source location of operands and the target location, which is represented as a hardware language. For example, the data operation instruction is a matrix multiply-accumulate instruction, whose operation form is C += A × B^T, where A and B are input matrix operands, C is an accumulated matrix operand, the buffered operands stored in the operand buffer are two-dimensional matrix data blocks, which can also be extended to three-dimensional or multi-dimensional, and the data scale thereof is defined by matrix dimensions (M×K, N×K, M×N) and element bit width. The matrix multiply-accumulate instruction can be expressed as: mfmacc md, ms1, ms2. Matrix A will be loaded from the memory to the operand buffer and filled into the internal buffer for subsequent reuse. It indicates that matrix B can be directly read from the operand buffer without reloading. A target register or memory address is specified for storing temporary calculation results and the final calculation result C. This instruction completes the multiplication operation of matrix A and matrix B in a single cycle, and accumulates the result into matrix C. Through the collector_usage tag, the matrix multiply-accumulate instruction can dynamically manage the lifecycle of operands, avoid reloading the same data, thereby reducing memory bandwidth consumption and power consumption. The matrix multiply-accumulate instruction is selected from the RISC-V matrix extension instruction set, including: for(int i=0; i<sizeM; i++) { / / The loop variable is i (corresponding to the M dimension) for(int j=0; j<sizeN; j++) { / / The loop variable is j (corresponding to the N dimension) for(int k=0; k<sizeK; k++) { / / The loop variable is k (corresponding to the K dimension) C[i,j] += A[i,k]* B[j,k]; / / It is clear that the matrix B is accessed as transposed elements (B[j,k] corresponds to the element at the k-th row and j-th column of B^T) } } } The current operand is the data value or set of data that the instruction operates on when executing a data operation instruction. The current operand can originate from the register file, main memory, or other temporary storage media (such as the operand buffer). In processor architecture, operands are the fundamental elements involved in computation. For matrix multiplication-accumulation instructions, the current operand may include two input matrices used for the multiplication operation and an initial accumulation matrix. The selection and acquisition of operands directly affect computational efficiency and system performance. For example, in the matrix multiplication-accumulation instruction C += A × B^T, A and B are the input matrix operands, and C is the accumulation matrix operand. In this example, A, B, and C are all considered as the current operands.

[0037] The register number of the current operand is a unique identifier associated with it, used to locate and access the operand within the processor. Register numbers are typically included in data operation instructions, indicating to the control unit from which register or memory location to fetch the current operand. Each operand has a corresponding register number, which helps the target processor accurately locate and use the required data for computation. Register renaming techniques can optimize data feed flow without affecting logical consistency, reducing the number of direct accesses to the register file and improving instruction execution efficiency. For example, in the matrix multiplication-accumulation instruction mentioned above, ms1, ms2, and md specify the operands involved in the calculation (i.e., matrices A, B, and C), respectively, and include the register number information for the corresponding operands.

[0038] One possible way to obtain data operation instructions is to extract them from the instruction cache. For example, the control unit extracts the instruction stream from the instruction cache in the order of the program counter (PC) through the instruction prefetch unit. The instruction decoder then parses the opcode and operand field in the instruction format to identify the register number of the current operand and the instruction type.

[0039] Another possible way to obtain data operation instructions is to load data operation instructions based on memory mapping. For example, the control unit accesses the memory-mapped I / O space through the Memory Management Unit (MMU), loads data operation instructions from peripherals or shared memory into the instruction queue according to a predefined instruction address mapping table, and extracts the instruction operand descriptors.

[0040] Another option for acquiring data processing instructions is to asynchronously acquire them through an instruction prefetch queue. For example, the instruction prefetch unit of the control unit loads the instruction blocks to be executed into the prefetch queue in advance based on the branch prediction results and instruction access patterns, and the instruction scheduler dispatches them to the decoding unit in the pipeline stage order.

[0041] For example, the target processor is a RISC-V architecture processor, executing the following matrix multiplication and accumulation instruction: `mfmaccmd, ms1, ms2`, where `md` is the target register number, storing the accumulation result. `ms1` and `ms2` are operand register numbers, pointing to the two input matrices respectively. The control unit fetches this instruction from the instruction cache, decodes it, and identifies the register numbers of `ms1` and `ms2`.

[0042] In step 102, the data operation instruction carrying the register number of the current operand is obtained, which provides a query index for subsequent querying of the buffer status table and provides instruction support for subsequent execution of data operations.

[0043] Step 104: Based on the register number of the current operand, query the buffer status table of the operand buffer to see if there is a data table entry for the current operand. The buffer status table records the data table entries of each buffer operand stored in the operand buffer. Each buffer operand is transferred from the register file to the operand buffer.

[0044] The operand buffer status table is a metadata table maintained internally by the target processor for the operand buffer. It dynamically tracks the storage status, lifecycle, and access characteristics of each buffered operand temporarily stored in the operand buffer, reflecting them as data table entries for the buffered operands. The buffer status table associates register numbers with physical storage slots within the operand buffer through a logical mapping mechanism, recording status parameters such as the validity, reuse count, and last access time of each buffered operand, providing buffer data for instruction management by the control unit.

[0045] Optionally, the buffer status table records the validity (vld), source physical register number (pmreg), number of matrix elements and bit width (size), and occupancy status (use) of the buffer operand currently stored in the operand buffer, according to the one-to-one mapping relationship between physical register numbers and buffer slots. Each buffer data item corresponds to a data table entry containing a quadruple {vld, pmreg, size, use}, where the pmreg field directly maps to the register number of the current operand. The data table entry for the buffer operand is the metadata of the buffer operand recorded in the buffer status table, including but not limited to the following fields, as shown in Table 2:

[0046] Table 2 For example, the buffer state table includes 3 data entries: The first entry: vld=1, pmreg=R1, size=M×N, use=active, indicates that this is a valid entry, the data comes from register R1, the size is M×N units, and it is currently in use.

[0047] The second entry: vld=1, pmreg=R3, size=M / 2×N, use=waiting, indicates that this is a valid entry. The data comes from register R3 and is M / 2×N units in size, but it is currently in a waiting state because the relevant instruction has not yet reached the execution stage.

[0048] The third entry: vld=0, pmreg=R5, size=0, use=free, indicates that this is an invalid entry with no actual data associated with it, and it can be used for new operand storage.

[0049] The register file is a fast storage array in the target processor consisting of multi-port static random access memory. As a set of logical registers defined by the instruction set architecture, it provides the basic storage medium for operand storage and result write-back for data operation instructions. The register file adopts a multi-read, multi-write physical port design, supporting multiple instructions to access different registers simultaneously. Each register corresponds to a unique register number and follows the addressing rules specified by the instruction set (such as the x0-x31 general-purpose registers in RISC-V). The register file and operand buffer are connected through a dedicated data path with specific bandwidth, enabling on-demand transfer and synchronous updates of operands. For example, in the RISC-V Vector Extension (RVV) architecture, the register file contains 32 matrix registers, each capable of storing matrix data of variable length. When executing the instructions `mfmacc md, ms1, ms2`, the operand register numbers `ms1` and `ms2` point to the corresponding matrix registers in the register file. The data operation unit reads data from these registers, performs multiplication and accumulation operations, and writes the result back to the target register `md`.

[0050] For example, the control unit obtains operand register numbers ms1 and ms2 by parsing instructions, and then queries the buffer status table of the operand buffer. If there is a valid entry in the buffer status table with pmreg=ms1 and vld=1, and use=active, it indicates that the data of matrix ms1 has been cached in the operand buffer and can be used immediately. If the status of the entry corresponding to ms2 is valid, the data is read directly from the buffer; if either register number is not found in the buffer status table (e.g., vld=0), the operand loading process is triggered, transferring the data from the corresponding matrix register (e.g., ms1 or ms2) in the register file to the operand buffer, and updating the buffer status table.

[0051] In step 104, intelligent scheduling and access optimization of the operand buffer are achieved by querying the buffer status table based on the register number, which reduces register file access conflicts, reduces dynamic power consumption, and improves instruction-level parallelism.

[0052] Step 106: If yes, schedule the data processing unit, read the buffered operand from the operand buffer as the current operand, execute the data processing instruction on the current operand, and output the current operation result.

[0053] The current operation result is the output data after the data processing unit executes the instruction. This result is usually stored in a destination register or memory address for use by subsequent instructions. The current operation result is a direct result of the calculation process, reflecting the state after performing the specified operation on the input operands. For example, for a matrix multiplication-accumulation instruction, the current operation result might be a matrix processed by multiplication and accumulation operations. This result not only needs to accurately reflect the result of the mathematical operation, but also needs to ensure that it can be efficiently accessed by subsequent instructions to maintain smooth pipeline operation and maximize resource utilization. For example, in the matrix multiplication-accumulation instruction that executes the matrix multiplication-accumulation operation C += A × B^T, C is the current operation result.

[0054] If so, the data processing unit is scheduled to read the buffered operand from the operand buffer as the current operand, execute the data processing instruction on the current operand, and output the current operation result. Alternatively, if the data size of the buffered operand matches the operand size of the data processing unit, the data processing unit is scheduled to read the buffered operand from the operand buffer as the current operand, execute the data processing instruction on the current operand, and output the current operation result.

[0055] For example, the control unit schedules the data processing unit to perform a multiplication-accumulation operation based on the acquired current operand, outputs the current operation result, and stores the accumulated value C in md, which can be used for subsequent instruction processing.

[0056] In the embodiments described in this specification, based on the register renaming design, the data buffer is indexed by the register number of the operand. During the instruction execution phase, highly reusable buffered operands are preferentially obtained from the operand buffer to schedule and execute data operation instructions and output operation results. While maintaining the logical consistency of the registers, the reusability of the operands is utilized to reduce the frequency of direct access to the register file, reduce the read and write bandwidth requirements of the register file, and improve instruction execution efficiency, energy efficiency ratio and resource utilization of the target processor.

[0057] In one optional embodiment of this specification, the data table entry for each buffer operand includes the data size of each buffer operand; step 106 includes the following specific steps: If so, based on the data size in the data table entry of the current operand, determine whether it conforms to the operand size of the data operation unit; If so, the scheduling data processing unit reads the buffered operand from the operand buffer as the current operand, executes the data processing instruction on the current operand, and outputs the current operation result.

[0058] The data size of a buffered operand refers to the data structure dimension of the buffered operands stored in the operand buffer, used to characterize the physical storage space occupied or the logical data volume of the operand. The data size is determined by the operand's data type, number of elements, bit width, and storage format, reflected as quantization parameters such as matrix length, number of matrix rows and columns, or scalar bit width. For example, in the RISC-V matrix extension architecture, the data size of a buffered operand can be represented by the number of elements in the matrix register (e.g., M×N single-precision floating-point numbers) and the element bit width (e.g., 32 bits), recorded as a tuple of {number of elements, bit width} through the size field.

[0059] The operand size of a data processing unit (or data processing unit) is the dimension of the data structure of the input operands when the data processing unit executes a specific data processing instruction. It is subject to hardware constraints on the data processing unit's operational structure and is jointly defined by the instruction opcode, the operation mode, and the hardware parallelism. The operand size specifies the maximum amount of data the data processing unit can process in a single operation, the minimum alignment granularity, and data type compatibility. For example, a matrix multiplication and accumulation unit might require an M×N bit-aligned input matrix, and the output accumulation result must match the input size. The operand size is built into the control logic of the data processing unit as a hardware design parameter, and is parsed and a size verification signal is generated by the control unit during the instruction decoding stage.

[0060] For example, when the RISC-V processor executes the instructions `mfmacc md, ms1, ms2`, the control unit parses the instructions and determines that the data processing unit requires two M×N element single-precision floating-point matrices as input operands. It queries the buffer status table; the size field of the entry corresponding to `ms1` is `{M×N, FP32}`, which matches the operand size required by the instruction. Therefore, it directly reads the complete M×N data from the operand buffer and marks its use status as active.

[0061] In the embodiments described in this specification, a scale matching and verification mechanism is used to ensure that the data in the operand buffer meets the instruction execution constraints before reuse, thereby avoiding operational anomalies caused by data truncation or format errors, while minimizing redundant data loading and maintaining high throughput and low latency.

[0062] In one optional embodiment of this specification, if yes, after determining whether the data size meets the operand size of the data operation unit based on the data size in the data table entry of the current operand, the following specific steps are further included: If not, based on the operand size of the data processing unit, perform high-bit truncation or low-bit extension on the data size of the buffer operand to obtain a buffer operand that conforms to the operand size.

[0063] For example, when the RISC-V processor executes the instructions `mfmacc md, ms1, ms2`, the control unit parses the instruction and determines that the data processing unit requires two M×N single-precision floating-point matrices as input operands. The buffer status table is consulted; the size field of the entry for `ms2` is {64, FP32}, containing only the first 64 elements, which is insufficient for the operand size required by the instruction. The 64 elements of `ms2` in the operand buffer are copied to a temporary register and padded with zeros to expand it to M×N elements, forming a complete matrix that meets the operand size requirement. The expanded M×N elements are written to a new slot in the operand buffer, and the buffer status table is updated to {pmreg=ms2, size={M×N, FP32}, vld=1, use=active}. Simultaneously, the original 64-element entry is marked as vld=0 to release resources. After the data expansion is complete, the data processing unit is immediately scheduled to read the expanded `ms2` data from the buffer and perform a multiply-accumulate operation with the ready `ms1` data.

[0064] In the embodiments described in this specification, the number of accesses to the register file and the data path bandwidth occupation are reduced, dynamic power consumption is reduced, data loading latency is hidden by truncating or expanding the reuse of some data, instruction throughput is improved, scale adjustment is ensured to follow instruction semantics and hardware constraints, operation correctness is maintained, flexible data reuse scenarios are supported, and energy efficiency ratio and resource utilization are improved.

[0065] In one optional embodiment of this specification, the following specific steps are included after step 104: If not, create a data table entry for the current operand in the buffer state table, and read the current operand from the register file based on the register number of the current operand, and transfer the current operand to the operand buffer; The scheduling data processing unit reads the buffered operand from the operand buffer as the current operand, executes data processing instructions on the current operand, and outputs the current operation result.

[0066] For example, when the RISC-V processor executes the instructions `mfmacc md, ms1, ms2`, the control unit detects that the entry corresponding to `ms2` in the buffer status table is invalid (`vld=0`). It then traverses the buffer status table and finds the third entry (`pmreg=R5`, `vld=0`) to be invalid. This entry is marked as `vld=1`, and `pmreg=ms2`, `size=M×N` (according to instruction requirements), and `use=waiting` are updated, indicating that the slot has been allocated to store the `ms2` data. Through a dedicated data path, the M×N single-precision floating-point matrix data corresponding to `ms2` in the register file is loaded into the third slot of the operand buffer. Simultaneously, `use=active` in the status table is updated to mark the data as available. If there are no free slots in the buffer status table, the entry with `use=waiting` and `vld=1` is replaced based on the Least Recently Used (LRU) policy, marked as `vld=0`, and the above operations of loading data from the register file and updating the buffer status table are performed. After the data is loaded, the scheduling data processing unit reads the data from the ms2 slot of the buffer, performs a multiplication and accumulation operation with the cached ms1 data, and writes the result back to the md register.

[0067] In the embodiments described in this specification, efficient utilization of the operand buffer is achieved by dynamically managing the operand data entries in the buffer state table. When it is detected that the required operand is not cached, data is loaded from the register file and the buffer state table is updated, ensuring that the data is quickly available, reducing repeated loading, lowering memory bandwidth consumption, improving instruction execution efficiency and system energy efficiency, effectively alleviating the register file access bottleneck, and enhancing the overall performance and response speed of the processor.

[0068] In one optional embodiment of this specification, the data table entry for each buffer operand includes the execution status of each buffer operand; otherwise, creating a data table entry for the current operand in the buffer status table includes the following specific steps: If not, based on the execution status in the data table entries of each buffer operand, check whether the data table entries of each buffer operand can replace the data table entries of the buffer operand; If so, release the replaceable buffer operands stored in the operand buffer, delete the data table entry for the replaceable buffer operands, and create the data table entry for the current operand in the buffer state table.

[0069] The execution status of a buffer operand indicates its stage of use in the current instruction pipeline, representing whether it is occupied, awaiting release, or idle. The execution status is encoded as a discrete value through the `use` field, including but not limited to occupied, awaiting release, and idle states. For example, "active" indicates that the current buffer operand is being read by a data processing unit or is in an instruction execution dependency chain and cannot be replaced; "waiting" indicates that the buffer operand has been loaded but has not yet been scheduled for use by any active instruction, allowing it to be replaced during resource contention; and "free" indicates that the slot corresponding to the buffer operand does not store valid data and can be immediately allocated to a new operand.

[0070] Replaceable buffer operands are buffer operands in the buffer state table that meet preset replacement conditions. Replaceable buffer operands can be buffer operands with an execution state of "waiting" and not depended on by subsequent instructions, buffer operands with an execution state of "free", or buffer operands with the longest access interval and an "active" state selected according to the least recently used policy.

[0071] For example, when the RISC-V processor executes the instructions `mfmacc md, ms1, ms2`, the control unit detects that the buffer entry for `ms2` is invalid (`vld=0`) and the buffer status table is full (no `vld=0` entry). Traversing the buffer status table, the three entries are found to have the following states: Entry 1: `pmreg=R1`, `use=active`; Entry 2: `pmreg=R3`, `use=waiting`; Entry 3: `pmreg=R5`, `use=active`. Entry 2 (`use=waiting`) is selected as the replaceable buffer operand, marked as `vld=0`, and the `pmreg` and `size` fields are cleared. The M×N data of `ms2` in the register file is loaded into the slot corresponding to entry 2, and the status is updated to `pmreg=ms2`, `size=M×N`, `vld=1`, `use=active`.

[0072] In the embodiments described in this specification, an execution status management mechanism for buffered operands is introduced to optimize the dynamic allocation and replacement strategy of the operand buffer. Based on the execution status of each buffered operand, operands to be replaced are identified and released, ensuring efficient use of buffer resources. This not only reduces invalid data occupation and memory access latency but also improves instruction execution efficiency and processor throughput.

[0073] In one optional embodiment of this specification, before determining whether a data table entry of each buffer operand is a replaceable data table entry based on the execution status in the data table entries of each buffer operand, the following specific steps are further included: When a buffer operand is read, update the execution status recorded in the buffer operand's data table entry.

[0074] For example, when the RISC-V processor executes the instructions mfmacc md, ms1, ms2, after the control unit schedules the data processing unit to read the buffered operand ms1 (with the entry status being use=active) from the operand buffer, within the clock cycle during which the data processing unit completes the data reading of ms1, the control unit detects the use=active status of ms1. If the current instruction is the last instruction that depends on ms1 (determined by the instruction dependency table), then the use field of ms1 is updated from active to waiting; otherwise, the active status is maintained. During the status update, hardware locks are used to prevent other instructions from modifying the entry status.

[0075] In the embodiments described in this specification, precise management of the operand lifecycle is achieved by dynamically updating the execution status recorded in the data table entries. When a buffered operand is read, the system adjusts its execution status in real time according to instruction dependencies, ensuring the accuracy and efficiency of data usage.

[0076] In one optional embodiment of this specification, the target processor further includes other data units; the method further includes the following specific steps: If a buffered operand is read by another data unit, release the buffered operand stored in the operand buffer and delete the data table entry for the buffered operand.

[0077] Other data units are processor units in the target processor other than the control unit, data processing unit, register file, and operand buffer. They are used to perform specific tasks related to operand lifecycle management, including but not limited to register renaming units, data write-back units, and memory management units. For example, a register renaming unit dynamically allocates physical register numbers to eliminate write-after-read and read-after-write dependency conflicts between instructions, converts logical register numbers to physical register numbers through a mapping table, and releases the original physical register resources when logical registers are overwritten by new data. Another example is a data write-back unit, which writes the calculation results of the data processing unit back to the register file or memory and triggers a status update of the operand buffer after the write-back is completed. Yet another example is a memory management unit, which manages the loading and storing of operands between main memory and the register file / operand buffer.

[0078] For example, when the RISC-V processor executes the instructions `mfmacc md, ms1, ms2`, the register renaming unit detects that a subsequent instruction will write new data to the same architecture register `ms1`. The logical register `ms1` is mapped to the newly allocated physical register `P2`, and the original physical register `P1` is marked as pending release. The buffer status table of the operand buffer is traversed, all data entries where `pmreg=P1` (i.e., the original `ms1` data) are deleted, marked as `vld=0`, and the corresponding slots are released.

[0079] In the embodiments described in this specification, the associated old physical registers and buffered data are released synchronously through the architecture register-driven collaborative release mechanism to avoid invalid data occupying storage resources. Through the strict mapping relationship between logical registers and physical registers, it is ensured that the same architecture register accessed by the instruction sequence always points to the latest data version.

[0080] In one optional embodiment of this specification, the target processor further includes an operation result buffer; after step 106, the following specific steps are also included: Store the current operation result in the operation result buffer.

[0081] The current operation result is stored in the operation result buffer. One possible way is to write the current operation result into the operation result buffer through the output port of the data processing unit. Another possible way is to dynamically store the current operation result into the operation result buffer based on the amount of data in the current operation result. Yet another possible way is to store the current operation result into the operation result buffer through the register renaming mechanism. No further restrictions are imposed here.

[0082] For example, when the RISC-V processor executes the instructions `mfmacc md, ms1, ms2`, the accumulated result `C` output by the data processing unit is stored in the operation result buffer through the following steps: The control unit queries the free slots in the operation result buffer, selects slot S4 with a status of `vld=0`, marks it as `vld=1`, and associates it with the target register `md`. The M×N single-precision floating-point data of the result `C` is written to slot S4 through a dedicated write-back channel, and the buffer status table is updated with `pmreg=md`, `size=M×N`, and `use=active` through a register renaming mechanism.

[0083] In the embodiments described in this specification, by introducing an operation result buffer, the frequency of direct writes to the register file is reduced, memory access latency and power consumption are lowered, the data processing efficiency of the target processor is improved, and the energy efficiency ratio and resource utilization of the target processor are further enhanced.

[0084] In one optional embodiment of this specification, storing the current operation result in an operation result buffer includes the following specific steps: Assign a register number to the current operation result, and create a data table entry for the current operation result in the buffer state table based on the register number of the current operation result; Store the current operation result in the operation result buffer.

[0085] To assign a register number to the current operation result, one option is to rename the scheduling register and dynamically map the logical register number. Another option is to assign a register number to the current operation result based on the data size of the current operation result. This option is not limited here.

[0086] For example, after the RISC-V processor executes the instructions `mfmacc md, ms1, ms2`, the data processing unit generates an M×N single-precision floating-point matrix C as the current operation result. The register renaming unit detects that the current mapping relationship of the logical register `md` is physical register P4 and confirms that P4 is in an unoccupied state. The control unit dynamically assigns the physical register number of the operation result C to P4 and creates a data table entry in the buffer status table of the operation result buffer: `{vld=1, pmreg=P4, size={M×N, FP32}, use=active}`. The M×N data of C is written to the 4th storage slot of the operation result buffer via the parallel data bus, establishing a hardware mapping relationship between the physical register number P4 and the storage slot.

[0087] In the embodiments described in this specification, a dynamic register number allocation mechanism and a buffer state table are used in conjunction to achieve precise addressing and data isolation of the operation result buffer. Based on the uniqueness of physical register numbers, the storage independence of operation results during concurrent execution of multiple instructions is guaranteed, avoiding data overwriting conflicts. Simultaneously, a pre-defined scale matching strategy optimizes register resource allocation, ensuring high-throughput data storage and fast access, further improving the processor's instruction-level parallelism efficiency.

[0088] In one optional embodiment of this specification, after storing the current operation result in the operation result buffer, the following specific steps are further included: Write the current operation result back to the register file from the operation result buffer; Once the current operation result has been written back, release the current operation result stored in the operation result buffer and delete the data table entry for the current operation result.

[0089] For example, after the RISC-V processor executes the instructions `mfmacc md, ms1, ms2`, the operation result `C` is stored in slot S4 of the operation result buffer (pmreg=md, size=M×N, use=active). When a subsequent instruction needs to read the data from `md`, if the data in the operation result buffer is not depended upon by the subsequent instruction (determined by the instruction dependency table), a data write-back process is triggered: the `M×N` data in slot S4 is written back to the physical register P4 corresponding to the logical register `md` through the write port of the register file. After the write-back is completed, slot S4 is marked as `vld=0`, and the `pmreg` and `size` fields are cleared for new data storage.

[0090] In the embodiments described in this specification, a write-back mechanism and a resource release strategy are used to ensure that subsequent instructions obtain the latest results when accessing the register file, thus guaranteeing data consistency, timely releasing consumed data in the buffer, and improving buffer utilization.

[0091] Reference content: The latest data in the C buffer needs to be written back to the physical register to ensure the correctness of subsequent consumer functions. After the data is written back, the entry should be released. In one optional embodiment of this specification, the method further includes the following specific steps: Obtain update data operation instructions, where the update operand of the update data operation instructions is the current operation result; Based on the register number of the current operation result, query whether the buffer status table of the operation result buffer records the data table entry of the current operation result; If so, after the current operation result has been written back, create a data table entry in the buffer status table of the operand buffer based on the register number of the current operation result, and transfer the current operation result from the register file to the operand buffer; The scheduling data processing unit reads the current operation result from the operand buffer as the update operand, executes the update data processing instruction, and outputs the update operation result.

[0092] Update data operation instructions are operations that depend on the results of preceding instructions. Their update operands are the current operation results output by the preceding instructions. For example, `md` is the current operation result of the preceding instructions `mfmacc md, ms1, ms2`, which needs to be obtained from the operation result buffer or register file.

[0093] The update operand is the current result of the preceding instruction's output, which the update data operation instruction depends on. Its data source includes the operation result buffer or the register file. The validity of the update operand's data is identified by the `vld` field of the buffer status table, and the data in the operation result buffer must be the latest version before writing the data back to the register file. For example, if the update operand is `md` (the output of the preceding instructions `mfmacc md, ms1, ms2`), it must be obtained from the operation result buffer or the register file.

[0094] The data entries for the current operation result are the metadata recorded in the buffer status table of the operation result buffer. For example, if the data entry for operation result C is {vld=1, pmreg=P4, size=M×N, use=active}, it indicates that it is valid and being used.

[0095] The register number of the current operation result is the physical register number mapped from the logical register number through the register renaming mechanism. For example, the logical register md is mapped to the physical register P4, and the entry for this data in the operation result buffer is associated with pmreg=P4. For example, after executing mfmacc md, ms1, ms2, the logical register md is mapped to the physical register P4, and the operation result C is stored in the pmreg=P4 slot of the operation result buffer.

[0096] The result of an update operation is the new data generated after executing the update data operation instruction, and it needs to be stored in the operation result buffer or register file. For example, the output of the instruction mfadd md, ms1, ms2 is md, which is the result of the update operation, and its storage procedure follows the same buffer management strategy as the current operation result.

[0097] One possible way to obtain update data operation instructions is to extract them from the instruction cache. For example, the control unit extracts the instruction stream from the instruction cache in the order of the program counter through the instruction prefetch unit, and the instruction decoder parses the opcode and operand field in the instruction format to identify the register number of the current operand and the instruction type.

[0098] Another possible way to obtain update data operation instructions is to load update data operation instructions based on memory mapping. For example, the control unit accesses the memory-mapped I / O space through the memory management unit, loads update data operation instructions from peripherals or shared memory into the instruction queue according to a predefined instruction address mapping table, and extracts instruction operand descriptors.

[0099] Another option for obtaining update data operation instructions is to asynchronously obtain update data operation instructions through the instruction prefetch queue. For example, the instruction prefetch unit of the control unit loads the instruction blocks to be executed in advance into the prefetch queue based on the branch prediction results and instruction access patterns, and the instruction scheduler dispatches them to the decoding unit in the pipeline stage order.

[0100] If so, schedule the data processing unit, read the current operation result from the operand buffer as the update operand, execute the update data processing instruction, and output the update operation result. Alternatively, if the data size of the current operation result matches the operand size of the data processing unit, schedule the data processing unit, read the current operation result from the operand buffer as the update operand, execute the update data processing instruction, and output the update operation result.

[0101] For example, when the RISC-V processor executes the `mfmacc` instructions `m5`, `m3`, and `m4`, the control unit queries the buffer status table based on the physical register number P4 of `m3`. It finds valid data (an M×N single-precision matrix) in slot S4 of the operation result buffer with `pmreg=P4` and `vld=1`. The control unit transfers the data in S4 to the free slot S2 of the operand buffer and updates the entry to `pmreg=P4`, `size=M×N`, and `use=active`. The data processing unit reads the N×K matrix data of `m3` (S2) from the operand buffer and `m4` (physical register P6) from the register file, performs a matrix multiplication and accumulation operation C=A×B^T (A=M×N, B=N×K), and writes the result `m5` (an M×K matrix) to slot S5 of the operation result buffer. After subsequent `mfmacc` instructions `m7`, `m5`, and `m8` complete reading `m5`, the data in S5 is written back to the physical register P7 in the register file, and `vld=0` is set for S5.

[0102] In the embodiments described in this specification, a hardware-level data consistency guarantee mechanism is used to eliminate the risk of data conflicts caused by out-of-order execution while maintaining the parallelism of the instruction pipeline, thus ensuring the correctness of the computation results. Furthermore, the data caching strategy is adjusted according to the real-time requirements of the computation task to optimize storage resource utilization and reduce system dynamic power consumption. This improves computational throughput while achieving synergistic optimization of energy efficiency and resource utilization, enhancing the overall performance of the processor architecture.

[0103] Corresponding to the above method embodiments, Figure 2 This specification illustrates a schematic diagram of the architecture of a target processor in a data processing method according to an embodiment of this specification, as shown below. Figure 2 As shown: The matrix multiplication and accumulation execution unit is configured with three dedicated data buffers to optimize matrix operation efficiency: The first operand buffer is configured with two data entries, each storing an M×K dimension data block of the input matrix A. It employs a port design with one read port and one write port, supporting single-cycle parallel read and write operations. Data entry elements include: vld (valid bit), pmreg (physical register number), size (data specification), and use (execution status).

[0104] The second operand buffer is configured with two data entries, each storing an N×K dimension data block of the transposed matrix B^T (the original matrix B is K×N dimension). It employs a port design with one read port and one write port, supporting single-cycle parallel read and write operations. Data entry elements include: vld (valid bit), pmreg (physical register number), size (data size), and use (execution status). Implicit transpose access to the B matrix is ​​achieved by connecting to the data processing unit via a transpose crossbar switch.

[0105] Four data entries are configured, each storing the M×N intermediate results of the accumulation matrix C. An accumulation write port + dual read port design is adopted, integrating in-situ update circuitry, supporting the accumulation operation of C += Δ while reading the current C value. The size field of each entry is forcibly constrained to a fixed dimension of M×N.

[0106] 1. Prefetching multiplicative operands: The control unit parses the mfmacc instruction to obtain the operand identifier: The identifier for matrix A is mapped to pmreg=R1 (M×K dimensions); Matrix B identifier mapping pmreg=R2 (K×N dimensions); The cumulative matrix C identifier is mapped to pmreg=R3 (M×N dimensions).

[0107] Execute a three-level buffered query: Search for valid entries in R1 in the first operand buffer. If a match is found, directly obtain the A matrix block. The second operand buffer is used to search for valid entries in the transpose of R2. If no entry is found, the column-wise prefetch transpose operation of matrix B is triggered. Retrieve valid entries for R3 in the operation result buffer; if no match is found, load the initial C matrix from the register file.

[0108] 2. Multiplication and accumulation execution phase: The data processing unit performs the following atomic operations: for (int m=0; m <M; m++) for (int n=0; n <N; n++) C_buffer[m][n]+= sum_{k=0}^{K-1} (A_buffer[m][k]* Bt_buffer[n][k]) A_buffer is read from the first operand buffer, Bt_buffer is read from the transposed second operand buffer, and C_buffer is updated in place in the operation result buffer.

[0109] like Figure 2 The target processor architecture shown optimizes matrix operation performance through a three-level data buffering coordination mechanism. An automatic tracking mechanism based on physical register number tags allows operands reused twice to be directly retrieved from the buffer, reducing register read bandwidth requirements to less than half of the original scheme. The operation result buffer locally caches continuously accumulated intermediate results, compressing C operand read / write bandwidth to one-tenth of the original scheme. A cross-buffer synchronization protocol enables block reuse, reducing register file access frequency by over 68%. This architecture eliminates explicit data movement instructions through automated hardware management, improving programming efficiency while simultaneously increasing instruction throughput and reducing dynamic power consumption in matrix multiplication and addition operations.

[0110] Corresponding to the above method embodiments, this specification also provides target processor embodiments. Figure 3 A schematic diagram of the structure of a target processor according to one embodiment of this specification is shown. Figure 3 As shown, the target processor 300 includes a control unit 310, a data processing unit 320, and an operand buffer 330; The control unit 310 is used to acquire data operation instructions, wherein the data operation instructions carry the register number of the current operand; based on the register number of the current operand, it queries the buffer status table of the operand buffer 330 to see if there is a data table entry for the current operand, wherein the buffer status table records the data table entries of each buffer operand stored in the operand buffer 330, and each buffer operand is transferred from the register file to the operand buffer 330; if so, it schedules the data operation unit 320 to read the buffer operand from the operand buffer 330 as the current operand, executes the data operation instructions on the current operand, and outputs the current operation result.

[0111] Optionally, the operand buffer 330 includes a first operand buffer and a second operand buffer; the current operand includes the current first operand and the current second operand; The control unit 310 is specifically used to query whether the buffer status table of the first operand buffer records a data table entry for the current first operand based on the register number of the current first operand; and to query whether the buffer status table of the second operand buffer records a data table entry for the current second operand based on the register number of the current second operand; if both are true, the control unit 320 is scheduled to read the first buffer operand from the first operand buffer as the current first operand, read the second buffer operand from the second operand buffer as the current second operand, execute data operation instructions on the current first operand and the current second operand, and output the current operation result.

[0112] Optionally, the target processor 300 further includes an operation result buffer, the operand buffer 330 further includes an operation result buffer, and the current operand also includes historical operation results; The control unit 310 is specifically configured to query, based on the register number of the current first operand, whether the buffer status table of the first operand buffer records a data entry for the current first operand; based on the register number of the current second operand, whether the buffer status table of the second operand buffer records a data entry for the current second operand; and based on the register number of the historical operation result, whether the buffer status table of the operation result buffer records a data entry for the historical operation result. If all are true, the control unit 320 is scheduled to read the first buffer operand from the first operand buffer as the current first operand, read the second buffer operand from the second operand buffer as the current second operand, read the historical operation result from the operation result buffer as the current third operand, and execute data operation instructions on the current first operand, the current second operand, and the current third operand, and output the current operation result.

[0113] Optionally, the target processor 300 also includes an operation result buffer; The control unit 310 is also used to store the current operation result to the operation result buffer.

[0114] In the embodiments described in this specification, the target processor is based on a register renaming design. By indexing the data buffer with the register number of the operand, it prioritizes obtaining highly reusable buffered operands from the operand buffer during the instruction execution phase to schedule and execute data operation instructions and output the operation results. This approach can reduce the frequency of direct access to the register file and lower the read / write bandwidth requirements of the register file while maintaining the logical consistency of the registers. This improves the instruction execution efficiency, energy efficiency, and resource utilization of the target processor.

[0115] The above is an illustrative scheme of a target processor according to this embodiment. It should be noted that the technical solution of this target processor and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the target processor, please refer to the description of the technical solution of the data processing method described above.

[0116] Corresponding to the above method embodiments, this specification also provides on-chip system embodiments. Figure 4 A schematic diagram of the structure of a system-on-a-chip provided in one embodiment of this specification is shown. Figure 4 As shown, the system-on-chip 400 includes a plurality of on-chip components 410, the plurality of on-chip components 410 including a target processor 4110; The target processor 410 is used to execute computer programs / instructions, which, when executed by the target processor 410, implement the steps of the above-described data processing method.

[0117] In the embodiments of this specification, the target processor in the on-chip system is based on register renaming design. By indexing the data buffer with the register number of the operand, it prioritizes obtaining highly reusable buffered operands from the operand buffer during the instruction execution phase to schedule and execute data operation instructions and output operation results. While maintaining the logical consistency of the registers, it utilizes the reusability of the operands to reduce the frequency of direct access to the register file, reduce the read and write bandwidth requirements of the register file, and improve instruction execution efficiency, energy efficiency, and resource utilization of the target processor.

[0118] The above is an illustrative scheme of a system-on-a-chip (SoC) according to this embodiment. It should be noted that the technical solution of this SoC and the technical solution of the data processing method described above belong to the same concept. Details not described in detail in the SoC technical solution can be found in the description of the data processing method technical solution described above.

[0119] Figure 5 A structural block diagram of a computing device according to one embodiment of this specification is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a target processor 520. The target processor 520 is connected to the memory 510 via a bus.

[0120] Optionally, the computing device 500 also includes an access device that enables the computing device 500 to communicate via one or more networks. Examples of such networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0121] In one embodiment of this specification, the above-described components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0122] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 500 can also be a mobile or stationary server.

[0123] The target processor 520 is used to execute the following computer program / instructions, which, when executed by the target processor, implement the steps of the above-described data processing method.

[0124] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the data processing method described above.

[0125] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a target processor, implement the steps of the above-described data processing method.

[0126] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the data processing method described above.

[0127] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a target processor, implement the steps of the above-described data processing method.

[0128] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the data processing method described above.

[0129] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0130] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0131] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0132] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0133] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A data processing method applied to the control unit of a target processor, wherein, The target processor further includes a data processing unit and an operand buffer, including: Obtain a data operation instruction, wherein the data operation instruction carries the register number of the current operand; Based on the register number of the current operand, query whether the buffer status table of the operand buffer records the data table entry of the current operand. The buffer status table records the data table entries of each buffer operand stored in the operand buffer. Each buffer operand is transferred from the register file to the operand buffer. If so, the data processing unit is scheduled to read the buffered operand from the operand buffer as the current operand, execute the data processing instruction on the current operand, and output the current operation result.

2. The method according to claim 1, wherein, The data entries for each buffer operand include the data size of each buffer operand; If so, the data processing unit is scheduled to read the buffered operand from the operand buffer as the current operand, execute the data processing instruction on the current operand, and output the current operation result, including: If so, based on the data size in the data table entry of the current operand, determine whether it conforms to the operand size of the data processing unit; If so, the data processing unit is scheduled to read the buffered operand from the operand buffer as the current operand, execute the data processing instruction on the current operand, and output the current operation result.

3. The method according to claim 1, after querying the buffer status table of the operand buffer based on the register number of the current operand to determine whether the register of the register number in the operand buffer stores a buffered operand, further includes: If not, create a data table entry for the current operand in the buffer state table, and read the current operand from the register file based on the register number of the current operand, and transfer the current operand to the operand buffer; The data processing unit is scheduled to read the buffered operand from the operand buffer as the current operand, execute the data processing instruction on the current operand, and output the current operation result.

4. The method according to claim 3, wherein, The data entries for each buffer operand include the execution status of each buffer operand; If not, create a data table entry for the current operand in the buffer state table, including: If not, based on the execution status in the data table entries of each buffer operand, detect whether the data table entries of each buffer operand can replace the data table entries of the buffer operand; If so, release the replaceable buffer operand stored in the operand buffer, delete the data table entry of the replaceable buffer operand, and create the data table entry of the current operand in the buffer status table.

5. The method according to claim 4, further comprising, before determining whether a data table entry of each buffer operand is a replaceable data table entry based on the execution status in the data table entry of each buffer operand, if not: When the buffer operand is read, update the execution status recorded in the data table entry of the buffer operand.

6. The method according to claim 1, wherein, The target processor further includes other data units; the method further includes: If the buffer operand is read by other data units, the buffer operand stored in the operand buffer is released, and the data table entry of the buffer operand is deleted.

7. The method according to any one of claims 1-6, wherein, The target processor also includes an operation result buffer; If so, after scheduling the data processing unit, reading the buffered operand from the operand buffer as the current operand, executing the data processing instruction on the current operand, and outputting the current operation result, the method further includes: The current operation result is stored in the operation result buffer.

8. The method according to claim 7, wherein storing the current operation result into the operation result buffer comprises: Assign a register number to the current operation result, and create a data table entry for the current operation result in the buffer state table based on the register number of the current operation result; The current operation result is stored in the operation result buffer.

9. The method according to claim 8, further comprising, after storing the current operation result in the operation result buffer: Write the current operation result back to the register file from the operation result buffer; Once the current operation result is written back, the current operation result stored in the operation result buffer is released, and the data table entry of the current operation result is deleted.

10. The method according to claim 8, further comprising: Obtain an update data operation instruction, wherein the update operand of the update data operation instruction is the current operation result; Based on the register number of the current operation result, query whether the buffer status table of the operation result buffer records the data table entry of the current operation result; If so, if the current operation result is written back, a data table entry is created in the buffer status table of the operand buffer based on the register number of the current operation result, and the current operation result is transferred from the register file to the operand buffer; The data processing unit is scheduled to read the current operation result from the operand buffer as the update operand, execute the update data processing instruction, and output the update operation result.

11. A target processor, comprising a control unit, a data processing unit, and an operand buffer; The control unit is used to acquire data processing instructions, wherein, The data operation instruction carries the register number of the current operand; based on the register number of the current operand, the buffer status table of the operand buffer is queried to see if the current operand's data table entry is recorded, wherein the buffer status table records the data table entries of each buffer operand stored in the operand buffer, and each buffer operand is transferred from the register file to the operand buffer; if so, the data operation unit is scheduled to read the buffer operand from the operand buffer as the current operand, and the data operation instruction is executed on the current operand to output the current operation result.

12. The target processor according to claim 11, wherein the operand buffer includes a first operand buffer and a second operand buffer; the current operand includes a current first operand and a current second operand; The control unit is specifically used to query, based on the register number of the current first operand, whether the buffer status table of the first operand buffer records the data table entry of the current first operand; Based on the register number of the current second operand, query whether the buffer status table of the second operand buffer records the data table entry of the current second operand; If both are true, the data processing unit is scheduled to read the first buffered operand from the first operand buffer as the current first operand, read the second buffered operand from the second operand buffer as the current second operand, and execute the data processing instruction on the current first operand and the current second operand to output the current operation result.

13. The target processor according to claim 12, wherein, The target processor further includes an operation result buffer, the operand buffer further includes the operation result buffer, and the current operand further includes historical operation results; The control unit is specifically used to query, based on the register number of the current first operand, whether the buffer status table of the first operand buffer records the data table entry of the current first operand; Based on the register number of the current second operand, query whether the buffer status table of the second operand buffer records the data table entry of the current second operand; Based on the register number of the historical operation result, query whether the buffer status table of the operation result buffer records a data table entry of the historical operation result; if both are true, schedule the data operation unit, read the first buffer operand from the first operand buffer as the current first operand, read the second buffer operand from the second operand buffer as the current second operand, read the historical operation result from the operation result buffer as the current third operand, and execute the data operation instruction on the current first operand, the current second operand, and the current third operand, and output the current operation result.

14. The target processor according to any one of claims 11-13, wherein, The target processor also includes an operation result buffer; The control unit is also configured to store the current operation result into the operation result buffer.

15. A system-on-a-chip (SoC) comprising a plurality of on-chip components, the plurality of on-chip components including a target processor; The target processor is used to execute a computer program / instruction that, when executed by the target processor, implements the steps of the method according to claims 1 to 10.

16. A computing device, comprising: Memory and target processor; The memory is used to store computer programs / instructions, and the target processor is used to execute the computer programs / instructions, which, when executed by the target processor, implement the steps of the method according to any one of claims 1 to 10.

Images