Data processing system and data processing method of RISC-V

Abstract

The embodiment of the present disclosure discloses a data processing system and method based on RISC-V, wherein the data processing system comprises an instruction encoding space and a reconfigurable execution unit; the instruction encoding space comprises an operation code area, a reserved area and an extension area; the instruction encoding space is used to define a basic operation to be performed by an instruction in the operation code area, define an extension operation to be performed by the instruction in the reserved area, and define the length of the instruction in the extension area, so as to configure different types of instructions; the reconfigurable execution unit is used to construct a data path matrix of the instruction based on configuration information of the instruction, transmit data required by the instruction during execution based on the data path matrix, and perform an operation corresponding to the instruction based on data of the instruction.

Description

Technical Field

[0001] This disclosure relates to, but is not limited to, the field of computer technology, and in particular to a RISC-V-based data processing system and data processing method. Background Technology

[0002] The Reduced Instruction Set Computer (RISC-V) is an open-source reduced instruction set architecture that allows developers to flexibly define instruction formats and functions according to application requirements, thereby optimizing system performance and resource utilization.

[0003] In related technologies, RISC-V-based instruction processing methods use fixed-length encoding, which lacks the ability to flexibly adapt to different instruction lengths, making it difficult to fully utilize the encoding space and resulting in low resource utilization. Summary of the Invention

[0004] In view of this, the present disclosure provides at least one data processing system and data processing method based on RISC-V.

[0005] The technical solution of this disclosure embodiment is implemented as follows:

[0006] On one hand, this disclosure provides a RISC-V-based data processing system, which includes an instruction encoding space and a reconfigurable execution unit; the instruction encoding space includes an opcode area, a reserved area, and an extension area;

[0007] The instruction encoding space is used to define the basic operation to be performed by the instruction in the opcode area, the extended operation to be performed by the instruction in the reserved area, and the length of the instruction in the extension area, so as to configure different types of instructions;

[0008] The reconfigurable execution unit is used to construct the instruction data path matrix based on the instruction configuration information; transmit the data required by the instruction during execution based on the data path matrix; and execute the corresponding operation based on the instruction data.

[0009] On the other hand, this disclosure provides a RISC-V-based data processing method applied to the aforementioned data processing system, the data processing method comprising:

[0010] Based on the repetition rate of multiple operation modes in the target algorithm, multiple instructions are generated for the target algorithm.

[0011] Based on the configuration information of each instruction, construct the data path matrix for each instruction.

[0012] The data required for the execution of the corresponding instruction is transmitted based on the data path matrix; the operation corresponding to the instruction is executed based on the data of each instruction to achieve the processing of the target algorithm.

[0013] In this embodiment, by dividing the instruction encoding space into an opcode area, a reserved area, and an extension area, it is compatible with the basic instructions of the existing RISC-V architecture, supports instructions that need to be set by the manufacturer at the time of shipment, and also supports extended instructions in addition to basic instructions. In this way, through the three-level division mechanism of the instruction encoding space, it can support the adaptive configuration of instructions of different types (different lengths), maximize the utilization of the encoding space, and improve the applicability and flexibility of instruction configuration. Through the reconfigurable execution unit, the data path matrix corresponding to the instruction can be configured in real time, and the operation mode can be switched within a single clock cycle, thereby improving the efficiency of instruction execution.

[0014] 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 disclosure. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the specification, serve to illustrate the technical solutions of this disclosure.

[0016] Figure 1 A schematic diagram of the composition structure of a RISC-V-based data processing system provided in this embodiment of the disclosure. Figure 1 ;

[0017] Figure 2 A schematic diagram illustrating the implementation flow of a RISC-V-based data processing method provided in this embodiment of the disclosure;

[0018] Figure 3 A schematic diagram of the composition structure of a RISC-V-based data processing system provided in this embodiment of the disclosure. Figure 2 ;;

[0019] Figure 4 This is a schematic diagram of the software architecture of a RISC-V-based data processing method provided in an embodiment of this disclosure. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure 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 disclosure. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0021] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0022] 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 disclosure described herein can be implemented in an order other than that illustrated or described herein.

[0023] 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 disclosure pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this disclosure.

[0024] In traditional RISC-V instruction set applications, instruction set extensions typically employ simple and direct methods. For example, in instruction encoding, fixed-length encoding is commonly used, lacking the ability to flexibly adapt to different instruction lengths and making it difficult to fully utilize the encoding space. For execution units, a fixed-function architecture is used, making it impossible to quickly switch operation modes at runtime according to different computational tasks, resulting in poor flexibility. In the instruction loading stage, a simple single-buffered loading mechanism is mostly used, and in instruction verification, the signature algorithms used have relatively weak security and resistance to attacks.

[0025] Based on this, embodiments of this disclosure provide a RISC-V-based data processing system, such as... Figure 1 As shown, the data processing system 10 includes an instruction encoding space 11 and a reconfigurable execution unit 12. The instruction encoding space 11 includes an opcode area, a reserved area, and an extension area. The instruction encoding space 11 is used to define the basic operation to be executed by the instruction in the opcode area, define the extended operation to be executed by the instruction in the reserved area, and define the length of the instruction in the extension area to configure different types of instructions. The reconfigurable execution unit 12 is used to construct a data path matrix for the instruction based on the configuration information of the instruction; transmit the data required by the instruction during execution based on the data path matrix; and execute the operation corresponding to the instruction based on the data of the instruction.

[0026] The instruction encoding space is used to generate different types of instructions, providing an expressive form for them. An instruction is a command used to perform a specific operation. Instruction types include at least one of the following: basic instructions and extended instructions.

[0027] In some implementations, the instruction encoding space includes, but is not limited to, an opcode area, a reserved area, and an extension area. The opcode area defines the basic operation to be performed by the instruction. The reserved area defines the extended operations to be performed by the instruction. The extension area defines the length of the instruction.

[0028] In some implementations, the opcode area can adopt the RISC-V standard encoding specification to ensure compatibility with the basic instructions of existing RISC-V architectures. The reserved area can employ a hierarchical encoding structure to support instructions that need to be configured at the manufacturer's factory. The extension area can use a prefix encoding mechanism to support instructions of different lengths. Extension-type instructions can be other instructions besides the basic instructions, with a length greater than the basic instructions.

[0029] The reconfigurable execution unit is used to dynamically reconfigure the data path matrix within 3 clock cycles based on the configuration information of the instructions, so as to achieve rapid switching between various different operation modes.

[0030] In some implementations, the reconfigurable execution unit may include, but is not limited to, registers and a programmable data path matrix. Registers may include, but are not limited to, vector registers and status registers. The programmable data path matrix is ​​a hardware structure used to configure data transmission paths in real time based on instruction configuration information. The programmable data path matrix is ​​a circuit structure that can dynamically adjust its internal connections based on configuration information.

[0031] It should be noted that since the programmable data path matrix configures the data transmission path in real time, when switching operation modes, the data transmission path can be changed in real time according to the configuration information of the switched operation mode. Thus, the data transmission of the switched operation mode is realized according to the changed data transmission path, and the operation mode switching can be completed within a single clock cycle through real-time configuration switching operation.

[0032] In this embodiment, by dividing the instruction encoding space into an opcode area, a reserved area, and an extension area, it is compatible with the basic instructions of the existing RISC-V architecture, supports instructions that need to be set by the manufacturer at the time of shipment, and also supports extended instructions in addition to basic instructions. In this way, through the three-level division mechanism of the instruction encoding space, it can support the adaptive configuration of instructions of different types (different lengths), maximize the utilization of the encoding space, and improve the applicability and flexibility of instruction configuration. Through the reconfigurable execution unit, the data path matrix corresponding to the instruction can be configured in real time, and the operation mode can be switched within a single clock cycle, thereby improving the efficiency of instruction execution.

[0033] In some embodiments, the opcode area is used to define the basic operation of the instruction with the binary value of the first bit; the reserved area is used to define the extended operation of the instruction with the binary value of the third bit using a hierarchical encoding structure; and the extension area is used to define the length of the instruction with the binary value of the fourth bit using a prefix encoding mechanism.

[0034] The opcode area is used to represent different basic operations, such as addition, subtraction, and multiplication, using the binary value of the first bit (i.e., the least significant bit). In some implementations, the binary value of the opcode area can be mapped to specific hardware logic circuits, enabling the processor to respond quickly and execute the corresponding operations, reducing hardware complexity and improving overall performance and stability.

[0035] The hierarchical coding structure of the reserved area allows for the support of multiple extended operations under the same opcode, thereby improving the flexibility and adaptability of the instruction set. When processing image or audio data, efficient parallel computing can be achieved by selecting different extension types to meet diverse application scenarios.

[0036] The prefix encoding mechanism in the extended region can avoid the space waste caused by fixed-length instructions and enhance the expressive power of instructions. Especially when dealing with complex algorithms, this design can make more efficient use of instruction space, thereby reducing storage overhead.

[0037] In some implementations, the instruction encoding space can be 32 bits, which can be divided into an opcode area (0x00-0x7F), a reserved area (0x80-0xBF), and an extension area (0xC0-0xFF). The reserved area uses a hierarchical encoding structure, with the high-order 3 bits indicating the extension type (e.g., 000 for scalar operations, 001 for vector operations, 010 for security extensions, and 011 for real-time control), and the low-order 5 bits defining the specific operation. The extension area introduces a prefix encoding mechanism: the first byte 0xC0-0xCF represents a 16-bit short instruction, 0xD0-0xDF represents a 32-bit standard instruction, and 0xE0-0xEF represents a 48-bit long instruction; thus, the extension area uses a variable-length encoding format, supporting adaptive configuration of instruction lengths from 8 bits to 48 bits.

[0038] In some implementations, the standard opcode area can be pre-allocated with a 4-bit extension reserved area in the instruction encoding design. When a specific standard opcode needs functional expansion (e.g., adding a new function of "saturation operation" to the existing addition instruction), it is not necessary to redesign the encoding rules of the entire standard opcode area, thus avoiding disruption of the original instruction system compatibility. Expansion encoding is performed only through this 4-bit reserved area—assigning a specific 4-bit binary code to the new function and binding this code to the original standard opcode, thereby ensuring that the extended function instruction can be recognized without occupying the original opcode space and maintaining compatibility with older instructions. When the instruction enters the decoding stage, the hardware decoder first parses the standard opcode and then automatically detects the reserved 4-bit extension. If the extension is "0000" (no extension), the original logic is executed; if a preset extension code (e.g., "1010") is detected, the extended function processing flow is triggered.

[0039] Based on the above technical means, the encoding rules of instructions are further refined. Basic operations are defined in the opcode area, extended types and specific operations are described through hierarchical encoding in the reserved area, and the instruction length is specified through a prefix encoding mechanism in the extension area. This makes the instruction encoding more structured and hierarchical, which is convenient for subsequent parsing and execution, and improves the standardization and scalability of instruction encoding.

[0040] In some embodiments, the instruction encoding space 11 further includes an encoding space mapping unit; the encoding space mapping unit is used to store the length identifier of the instruction in a first-level table and to store the operand type and register mapping relationship of the instruction in a second-level table.

[0041] The encoding space mapping unit is used to manage instructions in the instruction encoding space. In some implementations, the encoding space mapping unit adopts a two-level lookup table structure, which includes a first-level table and a second-level table. The first-level table is used to store the length identifier of the instruction, which refers to the number of bits occupied by the instruction in the encoding space; the second-level table is used to store the operand types and register mapping relationships of the instruction.

[0042] In some implementations, when a 48-bit custom instruction enters the pipeline, the code space mapping unit can read the prefix byte of the custom instruction to determine the instruction length, and obtain the complete instruction length according to the first-level table; it can also query the second-level table to determine the operand type and register mapping relationship of the custom instruction, providing basic data support for subsequent decoding and execution.

[0043] Based on the aforementioned technical means, by introducing an encoding space mapping unit, the instruction length identifier, operand type, and register mapping relationship are stored in a first relation table and a second relation table, respectively, facilitating rapid lookup during instruction decoding and execution. Compared to the low decoding efficiency caused by the lack of an efficient mapping mechanism in existing technologies, this scheme can improve the accuracy and efficiency of instruction processing, thereby enhancing the operating speed and stability of the entire data processing system.

[0044] In some embodiments, the instruction encoding space 11 further includes an encoding offset register; the encoding offset register is used to determine the offset corresponding to the opcode of the instruction based on the available encoding space of the conflicting region when it is determined that the opcode of the instruction conflicts with the encoding of an existing instruction according to the first-level table and the second-level table; adjust the opcode of the instruction based on the offset to obtain a new opcode; the encoding space mapping unit is used to update the length identifier of the new opcode to the first-level table; and update the operand type and register mapping relationship of the new opcode to the second-level table.

[0045] The Coding Offset Register (COR) is used to adjust the allocation of opcodes, ensuring that no coding conflicts occur during instruction expansion, thereby improving the effectiveness of instruction coding. Especially when dealing with vendor-defined extensions, the COR can effectively avoid execution errors caused by extension conflicts, improving the flexibility and scalability of instruction expansion.

[0046] In some implementations, the specific implementation of adjusting the opcode allocation through the encoding offset register can be as follows: a two-level lookup table (the first level stores the instruction length identifier, and the second level stores the operand type and register mapping relationship) is used to detect whether there is a conflict between the opcode of the new extended instruction and the encoding of the existing instruction; when a conflict is detected between the opcode of the new extended instruction and the encoding of the existing instruction, the adjustment mechanism of the encoding offset register is automatically activated.

[0047] In some implementations, the adjustment mechanism of the encoding offset register can be as follows: read the original encoding of the conflicting opcode and its encoding region; calculate the offset based on the remaining available encoding space in the encoding region where the conflicting opcode is located; adjust the opcode of the new extended instruction based on the offset to obtain a new opcode; synchronously update the two-level lookup table of the encoding space mapping unit: in the first-level table, the length identifier of the new opcode is associated with the new opcode; in the second-level table, information such as operand type and register mapping relationship is also synchronously bound with the new opcode. Simultaneously, a new feature code is generated for the new opcode to ensure that the new encoding is unique in the space.

[0048] For example, if the manufacturer-reserved area 0x80-0x9F is occupied, the conflicting opcode 0x83 can be allocated to the unoccupied 0xA0-0xBF range. The encoding offset register will set the offset value to 0x1D (0x83+0x1D=0xA0) and write the offset value to the hardware register as the base adjustment value for the conflicting opcode allocation.

[0049] In some implementations, each instruction may include a 2-bit version number field to support four instruction iterations of the unified opcode. This maintains compatibility with older instruction versions as the instruction set is continuously expanded, while allowing the hardware platform to gradually support newer instruction extensions, effectively supporting backward compatibility and facilitating future instruction set updates.

[0050] In this case, during the adjustment of the encoding offset register, the 2-bit version number field will record the adjusted version of the opcode (such as updating from "00" to "01") to ensure that the old version of the instruction can still be adapted to the new encoding through the semantic mapping layer. If there are still potential conflicts after the adjustment, the encoding offset register will repeat the above adjustment process until the opcode allocation completely avoids the conflict area, so that the hardware decoder can identify the adjusted encoding and ensure that the instruction is executed normally.

[0051] In some implementations, a hash verification mechanism can be used to generate instruction signatures to ensure that each instruction has a unique identifier in the encoding space, thereby avoiding different instructions from sharing the same encoding space and ensuring the security and stability of the instruction set. After encoding, a hash verification mechanism can be used to verify the instruction signatures. For example, the hash verification mechanism can be Secure Hash Algorithm 3 (SHA-3).

[0052] In some implementations, a secure hash algorithm 3 can be used to regenerate the feature code after the offset, ensuring that the new code is unique in the space.

[0053] Based on the aforementioned technical methods, the instruction encoding conflict problem is resolved by automatically adjusting the opcode allocation through the encoding offset register, thus avoiding execution errors caused by encoding conflicts. Furthermore, updating the first-level and second-level tables ensures the accuracy of the encoding space mapping.

[0054] In some embodiments, the reconfigurable execution unit 12 includes a vector register, a status register, and a programmable data path matrix; the vector register is used to store configuration information of the instruction; the status register is used to determine routing rules according to the configuration information of the instruction; and the programmable data path matrix is ​​used to control the matrix switch corresponding to the instruction to be turned on according to the routing rules, so as to establish the data path matrix of the instruction.

[0055] A vector register is a register structure capable of storing multiple data elements, used to store instruction configuration information such as opcodes and parameters. A status register is a register used to record the operational state; its contents reflect operating conditions, such as the current operation mode and data flow direction. It is also used to generate routing rules based on instruction configuration information to guide the flow of data in the data transmission path. A programmable data path matrix can be a matrix structure composed of multiple switching elements, capable of establishing adjustable data transmission paths at different input / output ports to meet the differentiated data transmission path requirements of different computing tasks. The core of a programmable data path matrix is ​​the dynamic reconfiguration of the data transmission path through matrix switching; its energy consumption is directly related to the switching frequency.

[0056] Instruction configuration information is used to define, adjust, or control parameters during instruction execution. In some implementations, instruction configuration information includes, but is not limited to: operation table identifier, operand position, data width, operation type, and data processing rules. Routing rules are used to determine the path data takes from the source address to the destination address. Routing rules may include, but are not limited to: source address, destination address, gateway addresses traversed, and priority. Matrix switches are used to enable and disable corresponding paths.

[0057] In some implementations, the encoding space indirectly controls the flow and processing of data in the data path matrix by using at least one of the functional unit selection bits and opcodes.

[0058] In some implementations, the reconfigurable execution unit may include four 128-bit vector registers, two dedicated status registers, and a programmable data path matrix to support switching of operation modes within a single cycle via microcode reconfiguration.

[0059] In some implementations, the vector register provides the data pool, the status register issues routing rules based on microcode (such as configuration parameters in the instruction descriptor), and the data path matrix reconstructs the connection in real time based on the routing rules.

[0060] In some implementations, the specific method for switching operation modes based on vector registers, status registers, and programmable data path matrices can be as follows: During the instruction execution phase, the status register stores the configuration information (such as operation type, data processing rules, etc.) corresponding to the operation mode; the programmable data path matrix reconfigures the matrix switches according to the configuration information in the status register through microcode reconfiguration, thereby reconstructing the data transmission path; at the same time, the vector register, as a data storage carrier, provides the vector data required by the operation mode according to the reconstructed data path matrix, thereby realizing the switching of operation modes within a single cycle.

[0061] In some implementations, the status register parses the configuration information of the operation mode and generates matrix switching control signals (such as turning on cross points A0-B3); the matrix switches connections according to the control signals (such as configuring 8×8 / 16×16 sub-matrices through logic decoding of a Field-Programmable Gate Array (FPGA); the vector register group outputs data according to the new matrix.

[0062] Based on the above technical means, the configuration information of the instruction is stored in the vector register, the routing rules are determined by the status register according to the configuration information of the instruction, and the data path matrix is ​​established by the programmable data path matrix according to the routing rules. This enables the real-time configuration of the data path matrix corresponding to the instruction and the switching of the operation mode within a single clock cycle.

[0063] In some embodiments, the data processing system 10 further includes an address mapping unit 13; the address mapping unit 13 is used to offset the target address of the extended instruction to an idle basic register based on the association between the two-level mapping table and the register address when there is a register access conflict between the extended instruction and the basic instruction; the two-level mapping table includes a static mapping table and a dynamic mapping table; the static mapping table is used to map the virtual register identifier of the extended instruction to the physical addresses of the basic register and the floating-point register; the dynamic mapping table is used to adjust the address offset in real time according to the encoding offset register.

[0064] Extended instructions are new, user-defined instructions added to the standard RISC-V instruction set to implement specific functions or optimize performance. Basic instructions are the operational instructions already defined in the RISC-V standard instruction set.

[0065] When extended instructions and basic instructions use the same register resources during execution, register access conflicts may occur, leading to execution errors or data overwriting problems. To resolve potential conflicts or resource occupancy issues during register allocation for extended instructions, the address mapping unit introduces a two-level mapping table: a static mapping table and a dynamic mapping table.

[0066] A static mapping table is used to map the virtual register identifiers (i.e., logical register numbers) of extended instructions to actual physical addresses (i.e., physical registers), such as the general-purpose register set and the floating-point register set. The static mapping table is a pre-defined lookup table that stores a one-to-one correspondence between the virtual register identifiers of extended instructions and the underlying registers.

[0067] In some implementations, static mapping tables can be established during the initialization phase and remain unchanged throughout runtime. Static mapping ensures that extended instructions can directly access the corresponding physical registers in the absence of conflicts, thereby reducing additional mapping overhead.

[0068] A dynamic mapping table is used to calculate and adjust the offset of the target address in real time via the Coded Offset Register (COR). The contents of the dynamic mapping table can be dynamically updated according to the runtime state. In some implementations, whenever a register conflict is detected, the dynamic mapping table recalculates a new mapping path to ensure that extended instructions can continue to execute safely.

[0069] In some implementations, under conflict-free conditions, extended instructions can directly find the corresponding target register through a static mapping table without additional calculations, thus improving the execution efficiency of extended instructions. When a register is occupied by another instruction, the encoding offset register automatically increments by the offset, enabling the extended instruction to select the next free register as the target address. This achieves dynamic scheduling of register resources and effectively prevents deadlock or resource contention problems.

[0070] Based on the above technical solution, the two-level mapping table can avoid the occupied register space and instead use the physical address of the currently idle basic register. In this way, without modifying the original instruction execution logic, system abnormalities or performance degradation caused by register conflicts can be avoided, thereby improving the flexibility and stability of instruction set expansion.

[0071] In some embodiments, the address mapping unit 13 is further configured to map vector data to a floating-point register according to mapping rules; convert data in a custom format to a scalar format supported by the basic instructions, so as to store the custom format data in a general-purpose register; the conversion process is identified by the storage format of the status register.

[0072] The address mapping unit manages the mapping of address spaces between different data types. Mapping rules refer to the predefined rules followed by the address mapping unit during data mapping. Mapping rules can include the correspondence between source data types and target register types, data alignment, bit width matching, etc. For example, when mapping vector data to a floating-point register, the mapping rules specify how to split the multi-element vector into a format suitable for floating-point register storage. Mapping rules can be implemented through hardware configuration registers or microcode, ensuring that the mapping rules can be flexibly adjusted according to different application requirements.

[0073] In some implementations, the operand format of the extended instructions is mapped to the register file of the basic RISC-V instruction set through an address mapping unit, which can ensure that the extended instructions can access all 32 general-purpose registers and floating-point registers.

[0074] In some implementations, the operand address mapping method can be as follows: the operand identifier of the extended instruction, such as a custom vector operand index, is bound to the base register address through a two-level mapping table: the first level is a static mapping table, which maps the virtual register number of the extended instruction to the physical addresses of the 32 general-purpose registers and floating-point registers of the base RISC-V to ensure basic access compatibility; the second level is a dynamic mapping table, which adjusts the address offset in real time through the coded offset register (COR). When a register access conflict between the extended instruction and the base instruction is detected, the target address of the extended instruction is automatically offset to an empty register to avoid conflict.

[0075] In some implementations, the data format conversion can be as follows: the operand format of extended instructions is adapted to the data format of the base registers through a hardware format conversion unit. For vector data, it is mapped to the floating-point register file according to the segmentation rule of "high 128 bits → f24-f31, low 128 bits → f16-f23"; for custom formats, it is automatically converted to a 32-bit scalar format supported by the base instruction set and stored in a general-purpose register. The conversion process is recorded by a status register to ensure that the data can be correctly parsed during subsequent operations.

[0076] For variable-length instructions (8-48 bits) in the extended region, the mapping layer supports adaptive matching of operand length to the number of registers. Operands of 8-bit short instructions are automatically mapped to a single general-purpose register; operands of 48-bit long instructions are fragmented into 16-bit segments and mapped to x2, x3, and x4 (three registers), with the segment index recorded by the status register to avoid access errors due to length mismatch. Through these rules, the mapping layer enables extended instructions to access all 32 general-purpose registers and floating-point registers, while resolving conflicts and format incompatibility issues inherent in traditional static mapping through dynamic address offsets, adaptive format conversion, and permission checks.

[0077] Based on the above technical solution, the address mapping unit can map vector data to floating-point registers according to mapping rules, and convert custom-formatted data into scalar format for storage in general-purpose registers. This method can effectively utilize existing hardware resources, reduce additional hardware overhead, improve data processing efficiency, and thus enhance the overall performance and adaptability of the processor.

[0078] In some embodiments, the data processing system 10 further includes a detection unit 14; the detection unit 14 is used to detect the energy consumption of the instruction during data transmission and execution; and optimize the data processing system when the energy consumption of the data processing system is greater than the energy consumption threshold; the optimization includes at least one of the following: adjusting the switching frequency of the data path matrix, the read / write mode of the vector register, and the scheduling method of the instruction.

[0079] The detection unit is used to monitor the energy consumption of an instruction throughout its entire lifecycle in real time. It can also be replaced by a detection module, such as an energy consumption detection module or a dynamic energy consumption detection module. Specifically, the detection unit can track the energy consumed by the instruction during the data transmission phase (such as data transfer via bus, cache, etc.) and during the execution phase (such as operations in register sets and execution units).

[0080] In some implementations, the detection unit may include hardware structures such as sensors, counters, and energy harvesting circuits, and combine software algorithms to analyze and statistically process the collected data.

[0081] In some implementations, the detection unit can calculate power consumption by measuring current, voltage, etc., and record the power consumption value of each instruction. Furthermore, the detection unit can accumulate the power consumption of multiple instructions to evaluate overall performance. For example, when the processor is executing a intensive task, the detection unit can identify which instructions cause high power consumption, thus providing a basis for optimization.

[0082] In some implementations, optimization operations may include three aspects: first, adjusting the switching frequency of the data transmission path, that is, reducing unnecessary power consumption by reducing the frequency of switching on and off; second, changing the read and write mode of the vector register, such as using sequential access instead of random access, or optimizing the read and write timing, thereby reducing the power consumption of memory access; and third, rearranging the execution order of instructions so that high-power-consuming instructions are avoided from being executed simultaneously as much as possible, thereby balancing the load and reducing peak power consumption.

[0083] In some implementations, appropriate optimization combinations can be selected based on different application scenarios. For example, in low-power mode, priority may be given to adjusting the switching frequency and read / write mode; while in high-performance mode, more emphasis may be placed on optimizing instruction scheduling.

[0084] Based on the above technical solution, by introducing a detection unit to monitor the energy consumption of the data processing system in real time and dynamically adjusting the system parameters according to the energy consumption, the overall energy consumption can be effectively reduced, thereby improving the system's energy efficiency ratio and sustainable operation capability.

[0085] In some embodiments, the reconfigurable execution unit 12 further includes an instruction loading unit; the instruction loading unit is configured to load the relevant data of the instruction currently being processed into a first cache area, and load the relevant data of the instruction to be processed next into a second cache area.

[0086] The first cache can be the main cache, and the second cache can be the shadow cache.

[0087] In some implementations, the relevant data of the first instruction currently being processed is loaded into a first buffer, and the relevant data of the second instruction is preloaded into a second buffer. After the first instruction is sent to the execution unit, the contents of the first buffer are cleared or directly overwritten with the relevant data of the third instruction, and converted into the second buffer. The relevant data of the third instruction is preloaded, and the second buffer is converted into a new first buffer. The operation corresponding to the second instruction is then executed, and this process is repeated.

[0088] In some implementations, instruction descriptors are loaded during the instruction fetch phase using a double-buffering mechanism (32KB main buffer + 32KB shadow buffer) that decouples the instruction-level parallelism (DILP) protocol.

[0089] Based on the above technical solution, the double-buffering mechanism consisting of a first buffer and a second buffer can significantly improve the continuity and efficiency of instruction loading, avoiding pipeline stalls caused by waiting for instruction loading. Under the double-buffering mechanism, the current instruction can be processed in the first buffer, while the data for the next instruction is already prepared in the second buffer, thus achieving seamless instruction execution.

[0090] Based on the above technical solution, efficient and continuous instruction loading is achieved through an instruction loading unit and a dual-buffering mechanism involving a first cache and a second cache. The instruction loading unit reads the current instruction and its related data from memory and loads this data into the first cache. Simultaneously, the instruction loading unit also pre-loads the data for the next instruction into the second cache. After the current instruction enters the execution phase, the contents of the second cache are used as the first cache for the next cycle, forming a cyclical operation, thereby maintaining the smoothness and efficiency of instruction processing.

[0091] This disclosure provides a RISC-V-based data processing method, which can be applied to a RISC-V-based data processing system 10. For example... Figure 2 As shown, the method includes the following steps 201 to 203:

[0092] Step 201: Based on the repetition rate of multiple operation modes in the target algorithm, generate multiple instructions for the target algorithm.

[0093] The repetition rate of an operation pattern refers to the proportion of times an operation pattern is frequently invoked within the target algorithm. For example, in encryption algorithms (such as SM4), the S-box permutation operation pattern is used multiple times.

[0094] In some implementations, the multiple operation modes involved in the target algorithm can be divided into high-frequency operation modes and low-frequency operation modes based on the repetition rate of multiple operation modes in the target algorithm. Among them, the high-frequency operation modes can also be referred to as hotspot functions.

[0095] In some implementations, at least one of LVM Intermediate Representation (IR) and performance profiling tools (such as perf) can be used to analyze multiple operation modes in the target algorithm, identify high-frequency operation modes and low-frequency operation modes, and generate different types of instructions for high-frequency operation modes and low-frequency operation modes respectively.

[0096] Generating different types of instructions for different types of operation modes can improve the execution efficiency of algorithms, reduce code size, significantly reduce energy consumption, and improve overall system performance.

[0097] Step 202: Based on the configuration information of each of the multiple instructions, construct the data path matrix of each of the multiple instructions.

[0098] Configuration information refers to specific parameters required before an instruction is executed, including but not limited to register mapping relationships, data path connection methods, and operation mode selection. Configuration information can be dynamically adjusted according to the instruction type to ensure that the reconfigurable execution unit can correctly parse and execute the operation mode in the target algorithm. The operation corresponding to the instruction refers to completing the actual computational task based on the instruction content.

[0099] In some implementations, routing rules can be determined based on the configuration information of each instruction; the matrix switches corresponding to the instructions can be turned on according to the routing rules to establish a data path matrix for each instruction.

[0100] In some implementations, the internal structure design is refined when using a microarchitecture based on Verilog parameterized template automatic generation (Random Access Memory with Enhanced Understanding, REU). The data path employs time-division multiplexing technology combined with pipelined design to ensure efficient time-sharing execution of different computational tasks within a 256-bit wide data path. The interface design between REU and other modules follows standard bus protocols, such as the AXI bus, ensuring reliable and compatible data transmission. Simultaneously, the internal register file of REU is optimized with a dual-port design, allowing simultaneous read and write operations to improve data access speed.

[0101] Step 203: Transmit the data required for the execution of the corresponding instruction based on the data path matrix; execute the operation corresponding to the instruction based on the data of each of the multiple instructions to realize the processing of the target algorithm.

[0102] In this embodiment of the disclosure, multiple instructions are generated based on the repetition rate of multiple operation modes in the target algorithm. Data path matrices for each instruction are constructed based on the configuration information of each instruction. Data required by the corresponding instruction during execution is transmitted based on the data path matrices. Operations corresponding to the instructions are executed based on the data of each instruction. This enables efficient processing of the target algorithm, improves instruction execution efficiency and resource utilization, and further enhances the overall performance of the processor.

[0103] In some embodiments, step 201 above can be implemented by the following steps 2011 to 2014:

[0104] Step 2011: Analyze the execution process of the target algorithm and determine the repetition rate of each of the multiple operation modes.

[0105] In some implementations, the execution process of the target algorithm during compilation and during runtime can be analyzed to determine the repetition rate of each of the multiple operation modes.

[0106] Step 2012: From the multiple operation modes, determine the operation mode with a repetition rate greater than the repetition rate threshold to obtain at least one high-frequency operation mode.

[0107] High-frequency operation mode refers to the operation mode where the repetition rate is greater than the repetition rate threshold. The repetition rate threshold can be preset. For example, when the target algorithm is SM4 / SM3, the repetition rate threshold can be set to 85%. In this case, the high-frequency operation mode can be the S-box permutation method of the round function in the SM4 algorithm or the message expansion operation mode in the SM3 algorithm.

[0108] Step 2013: Generate an extended instruction for each of the high-frequency operation modes.

[0109] In some implementations, the extended operations to be performed and the instruction length can be defined through the instruction encoding space, so as to generate an extended instruction for each high-frequency operation mode.

[0110] Step 2014: Generate a basic instruction for each operation mode other than the high-frequency operation mode.

[0111] In some implementations, the basic operation to be performed and the instruction length can be defined through the instruction encoding space, so as to generate a basic instruction for each other operation mode.

[0112] In some embodiments, the data processing method provided in this disclosure further includes: verifying the data packet of the instruction based on the feature code in the instruction and verification information about the instruction obtained from the blockchain network to determine whether the data packet of the instruction is abnormal; the verification information includes at least one of the following: the result of at least one node in the blockchain network verifying the data packet of the instruction, and information obtained by hashing and / or signing the data packet of the instruction.

[0113] In some implementations, a dynamic hash allocation algorithm can be used to generate an opcode for each instruction; the opcode is used to uniquely identify the corresponding instruction. The dynamic hash allocation algorithm uses chaining to resolve hash collisions, using the lower 8 bits of the opcode as the hash value to map the instruction opcode to a hash table. The size of the hash table is dynamically adjusted according to the expected number of expanded instructions, ensuring that the load factor of the hash table remains within a reasonable range and avoiding excessive hash collisions that could impact performance. Simultaneously, the hash table is periodically cleaned and optimized to further improve the efficiency and accuracy of opcode allocation.

[0114] The data packet containing the instructions is called the instruction packet.

[0115] In some implementations, the specific methods for verifying the instruction data packet include at least one of the following: verifying the instruction data packet based on the feature code in the instruction, or verifying the instruction data packet based on verification information about the instruction obtained from the blockchain network, or verifying the instruction data packet based on the feature code in the instruction and the verification information about the instruction obtained from the blockchain network.

[0116] In some implementations, the EdDSA signature algorithm can be used to verify the integrity of the instruction packet, triggering an exception handling process upon verification failure. EdDSA signs the hash value of the instruction packet with a private key, generating a unique signature. The confidentiality of the private key is crucial to the signature's unforgeability. Due to the intractable nature of the elliptic curve discrete logarithm problem upon which EdDSA is based, attackers find it difficult to deduce the private key from the public key and the signature, thus preventing the forgery of a valid signature. Even if an attacker intercepts a legitimate instruction packet and signature, they cannot generate a new legitimate signature without possessing the private key, ensuring the integrity and authenticity of the instruction packet during transmission and loading.

[0117] Based on the above technical solution, by analyzing the repetition rate of each operation mode in the target algorithm and distinguishing between high-frequency and low-frequency operation modes according to the set repetition rate threshold, extended instructions are generated for high-frequency operation modes and basic instructions are generated for other operation modes. This can effectively utilize the instruction encoding space and avoid resource waste. As a result, the execution efficiency of high-frequency operation modes can be accurately optimized, and the overall algorithm performance can be improved. Furthermore, it can balance system stability and scalability, and realize the dynamic adjustment and flexible adaptation of the instruction set.

[0118] In some implementations, step 2011 above can be achieved by the following steps 2011a to 2011c:

[0119] Step 2011a: Analyze the execution process of the target algorithm during compilation based on the intermediate representation of the target algorithm to obtain a first analysis result; the intermediate representation is used to characterize the program structure of the target algorithm.

[0120] The intermediate representation of the target algorithm, generated by the compiler, lies between the source code and machine code. It preserves the program's logical structure and facilitates cross-platform optimization and analysis. For example, in the LLVM framework, the intermediate representation (IR) can express key information such as control flow and data dependencies, providing a foundation for subsequent optimization. Through the intermediate representation of the target algorithm, the general structural features of the algorithm can be extracted without depending on the specific hardware architecture.

[0121] In some implementations, the intermediate representation of the target algorithm can be used to collect information such as the number of function calls and branch probabilities during the compilation phase.

[0122] Step 2011b: Analyze the execution process of the target algorithm during runtime using a performance testing tool to obtain a second analysis result.

[0123] Performance testing tools are used to collect data generated by a target algorithm during program execution, such as CPU utilization, memory access patterns, and instruction execution time. Examples of performance testing tools include, but are not limited to, perf, gprof, and Valgrind.

[0124] The execution process of the target algorithm focuses more on its execution characteristics in real-world scenarios, such as the actual call frequency of hot functions, cache hit rate, and thread blocking. This analysis method can reveal problems that are difficult to find in static analysis, such as performance degradation caused by concurrency contention.

[0125] Step 2011c: Perform a comprehensive evaluation of the first analysis result and the second analysis result to determine the repetition rate of each of the multiple operation modes.

[0126] Comprehensive evaluation refers to integrating and comparing analytical results from different sources to comprehensively assess the execution characteristics of the target algorithm.

[0127] In some implementations, the first analysis result and the second analysis result can be standardized and aligned, and a comprehensive evaluation can be performed based on the aligned first analysis result and the aligned second analysis result to determine the repetition rate of each of the multiple operation modes.

[0128] Based on the above technical solutions, by analyzing the execution process of the target algorithm during compilation through the intermediate representation of the target algorithm, the structural features and potential hotspots of the target algorithm can be obtained; by analyzing the execution process of the target algorithm during runtime through performance testing tools, real execution behavior data can be obtained; by comprehensively evaluating the structural features and potential hotspots of the target algorithm with the execution behavior data, the repetition rate of each of the multiple operation modes can be accurately identified.

[0129] In some implementations, step 2011c above can be achieved by the following steps A1 to A4:

[0130] Step A1: Standardize the first analysis result and the second analysis result to obtain a standard first analysis result and a standard second analysis result; the standardization process includes at least one of the following: function name standardization and time standardization.

[0131] Because the data formats and meanings of intermediate representation analysis results and performance profiling tool analysis results may differ, a data standardization mechanism can be established. For example, a unified function naming convention can be implemented, mapping function names in the intermediate representation to their actual runtime counterparts, enabling the identification of corresponding functions from different data sources. Simultaneously, execution time, call frequency, and other data obtained from different tools can be standardized to the same time unit and statistical dimensions, facilitating subsequent comparative analysis.

[0132] Step A2: Based on the timestamps contained in the first analysis result and the second analysis result of the standard, establish a temporal correlation between the first analysis result and the second analysis result of the standard.

[0133] In some implementations, timestamps can be added during program execution to accurately correlate runtime and compile-time data. During the compilation phase, instrumentation techniques are used to insert timestamps at the entry and exit points of critical functions or code blocks. At runtime, performance profiling tools retrieve these timestamps and, combined with their own recorded time information, establish a time correlation between compile-time and runtime, ensuring that runtime performance data corresponds to compile-time code analysis.

[0134] Step A3: Based on the execution status of the first analysis result and the second analysis result of the standard, establish the correlation between the first analysis result and the second analysis result of the standard at the execution location.

[0135] In some implementations, a mapping relationship can be established between the intermediate representation code and the actual running machine code. By using debugging information during the compilation process (such as DWARF format), the execution position of the machine code can be traced back to the corresponding intermediate representation code line, thereby locating the intermediate representation code from the machine code for comprehensive analysis.

[0136] Step A4: Based on the correlation in time and the correlation in execution location, comprehensively evaluate the first analysis result and the second analysis result of the standard to determine the repetition rate of each of the multiple operation modes.

[0137] In some implementations, a data fusion algorithm can be used to combine data such as code structure and control flow from the first analysis result with data such as function call frequency and execution time from the second analysis result to calculate the probability (repetition rate) of each function or code block becoming a hotspot. For example, the data fusion algorithm can be a Bayesian fusion algorithm.

[0138] In some implementations, Bayes' formula can be: In hotspot function identification, let A represent the event that a function is a hotspot function, and B represent the first analysis result and the second analysis result. P(A) is the prior probability that the function is a hotspot function, set based on experience or preliminary analysis. For example, in a certain type of program, functions of specific functional modules are given a higher prior probability. P(B / A) is the likelihood probability of observed data given that the function is a hotspot function. For example, if the function is a hotspot function, the probability that performance profiling tools will count high call frequency and long execution time. P(B) is the total probability of observed data B, used for normalization. By continuously updating P(A / B), a more accurate posterior probability of the function being a hotspot function is obtained.

[0139] Based on the above technical solution, by standardizing the first and second analysis results and establishing a correlation based on timestamps and execution locations, a comprehensive evaluation can be conducted to more accurately identify high-repetition-rate operation patterns.

[0140] The following describes the application of the data processing method provided in the embodiments of this disclosure in real-world scenarios.

[0141] This disclosure provides a custom instruction set extension method based on RISC-V (corresponding to the aforementioned RISC-V-based data processing method), such as... Figure 3 As shown, it includes at least the following steps:

[0142] (1) Establish a three-level instruction encoding space partitioning mechanism, dividing the 32-bit instruction encoding space into an opcode area (0x00-0x7F), a reserved area (0x80-0xBF), and an extended area (0xC0-0xFF). The extended area adopts a variable-length encoding format, which supports adaptive configuration of instruction length from 8 bits to 48 bits.

[0143] (2) Design a reconfigurable execution unit, including a register set and a programmable data path matrix (corresponding to...). Figure 3 (Reconfiguration in the process); the register set includes four 128-bit vector registers and two dedicated status registers; the reconfigurable execution unit supports switching operation modes within three clock cycles via microcode reconfiguration.

[0144] (3) Implement a dynamic instruction loading protocol and adopt a double buffering mechanism to synchronously load extended instructions during the instruction fetching stage of the processor pipeline, including three parts of data: instruction semantic descriptor, hardware configuration parameters and verification signature.

[0145] (4) Construct an instruction compatibility guarantee system. Through the instruction semantic mapping layer, the operand format of the extended instructions is mapped to the register file of the basic RISC-V instruction set to ensure that the extended instructions can access all 32 general-purpose registers and floating-point registers.

[0146] In some implementations, the operand address mapping method can be as follows: the operand identifier of the extended instruction, such as a custom vector operand index, is bound to the base register address through a two-level mapping table: the first level is a static mapping table, which maps the virtual register number of the extended instruction to the physical addresses of the 32 general-purpose registers and floating-point registers of the base RISC-V to ensure basic access compatibility; the second level is a dynamic mapping table, which adjusts the address offset in real time through the coded offset register (COR). When a register access conflict between the extended instruction and the base instruction is detected, the target address of the extended instruction is automatically offset to an empty register to avoid conflict.

[0147] In some implementations, the data format conversion can be as follows: the operand format of extended instructions is adapted to the data format of the base registers through a hardware format conversion unit. For vector data, it is mapped to the floating-point register file according to the segmentation rule of "high 128 bits → f24-f31, low 128 bits → f16-f23"; for custom formats, it is automatically converted to a 32-bit scalar format supported by the base instruction set and stored in a general-purpose register. The conversion process is recorded by a status register to ensure that the data can be correctly parsed during subsequent operations.

[0148] For variable-length instructions (8-48 bits) in the extended region, the mapping layer supports adaptive matching of operand length to the number of registers. Operands of 8-bit short instructions are automatically mapped to a single general-purpose register; operands of 48-bit long instructions are fragmented into 16-bit segments and mapped to x2, x3, and x4 (three registers), with the segment index recorded by the status register to avoid access errors due to length mismatch. Through these rules, the mapping layer enables extended instructions to access all 32 general-purpose registers and floating-point registers, while resolving conflicts and format incompatibility issues inherent in traditional static mapping through dynamic address offsets, adaptive format conversion, and permission checks.

[0149] (5) Develop an instruction-level performance analysis module to monitor the execution efficiency of extended instructions in real time, and trigger a dynamic optimization process when the number of instruction execution cycles exceeds a preset threshold.

[0150] (6) A hybrid verification mechanism is adopted, combining formal verification tools to perform static verification of the timing characteristics of extended instructions, while dynamic behavior verification is performed through a hardware simulation platform.

[0151] In some implementations, the three-level instruction code space partitioning mechanism specifically includes:

[0152] (a) The opcode area adopts the RISC-V standard encoding specification, and the reserved bits are set in accordance with the RV32IMAFD instruction set architecture.

[0153] (b) The manufacturer-reserved area adopts a hierarchical coding structure, with the high-order 3 bits identifying the extension type (000-scalar operation, 001-vector operation, 010-security extension, 011-real-time control) and the low-order 5 bits defining the specific operation.

[0154] (c) The dynamic extension area introduces a prefix encoding mechanism. The first byte 0xC0-0xCF represents a 16-bit short instruction, 0xD0-0xDF represents a 32-bit standard instruction, and 0xE0-0xEF represents a 48-bit long instruction.

[0155] (d) The encoding space mapping unit adopts a two-level lookup table structure. The first-level table stores the instruction length identifier, and the second-level table stores the operand type and register mapping relationship.

[0156] (e) Supports dynamic remapping of instruction codes. When an instruction conflict is detected, the opcode allocation is automatically adjusted through the Code Offset Register (COR) to ensure that no encoding conflicts occur during instruction set expansion, thereby guaranteeing system stability. Especially when dealing with vendor-customized expansions, the dynamic remapping mechanism can effectively avoid execution errors caused by expansion conflicts, improving the flexibility and scalability of instruction set expansion.

[0157] The specific method for adjusting the opcode allocation using the encoding offset register is as follows: When a conflict is detected between the opcode of a new extended instruction and the encoding of an existing instruction, the encoding offset register adjustment mechanism is automatically activated through a two-level lookup table (the first level stores the instruction length identifier, and the second level stores the operand type and register mapping relationship). At this time, the encoding offset register will read the original encoding of the conflicting opcode (such as 0x83) and its encoding region (such as the manufacturer-reserved area 0x80-0xBF).

[0158] The encoding offset register calculates the offset based on the remaining available encoding space in the conflict region. For example, if the reserved region 0x80-0x9F is occupied, the conflicting opcode 0x83 can be allocated to the unoccupied 0xA0-0xBF range. The encoding offset register will set the offset value to 0x1D (0x83+0x1D=0xA0) and write this offset value to a hardware register as the base adjustment value for opcode allocation.

[0159] After the encoding offset register is adjusted, the two-level lookup table of the encoding space mapping unit is updated synchronously: in the first-level table, the length identifier of the conflicting opcode is associated with the new encoding after the offset (e.g., 0xA0); in the second-level table, information such as operand type and register mapping relationship is also bound synchronously with the new encoding. Simultaneously, the SHA-3 hash verification mechanism regenerates a signature for the new encoding, ensuring that the new encoding is unique in the space. During the adjustment process, a 2-bit version number field records the adjusted version of the opcode (e.g., updated from "00" to "01"), ensuring that the old version of the instruction can still adapt to the new encoding through the semantic mapping layer; if potential conflicts still exist after adjustment, the encoding offset register repeats the above process until the opcode allocation completely avoids the conflict area, and finally, the hardware decoder identifies the adjusted encoding, ensuring that the instruction executes normally.

[0160] (f) Implement version management for instruction codes. Each extended instruction includes a 2-bit version number field, supporting four instruction iterations for the same opcode. This version management mechanism ensures compatibility with older instruction versions while continuously expanding the instruction set, and allows the hardware platform to gradually support newer instruction extensions. This mechanism effectively supports backward compatibility and facilitates future instruction set iterations and updates.

[0161] (g) A hash verification mechanism is employed to ensure the uniqueness of the code space allocation. The SHA-3 algorithm is used to generate instruction signatures. To ensure the uniqueness of the code space allocation and avoid instruction encoding conflicts, the SHA-3 hash algorithm is used to verify the instruction signatures. By generating instruction signatures, it is ensured that each extended instruction has a unique identifier in the code space, thereby avoiding different instructions from sharing the same code space and ensuring the security and stability of the instruction set of the reconfigurable execution unit.

[0162] The above steps revolve around the three-level instruction encoding space partitioning mechanism in the RISC-V-based custom instruction set extension method. First, the 32-bit instruction encoding space is divided into an opcode region, a reserved region, and an extension region, clearly defining the scope of each region. The extension region uses variable-length encoding. Next, the specific encoding rules for each region are explained: the opcode region follows the RISC-V standard, the reserved region uses hierarchical encoding, and the extension region uses prefix encoding. Simultaneously, a two-level lookup table is used for encoding space mapping, supporting dynamic remapping to avoid encoding conflicts, implementing version management to ensure backward compatibility, and employing the SHA-3 hash verification mechanism to ensure the uniqueness of encoding space allocation, comprehensively guaranteeing the stability, flexibility, and security of the instruction set.

[0163] The specific process of the RISC-V-based custom instruction set extension method from a lifecycle perspective is as follows:

[0164] S1: Instruction definition stage;

[0165] By analyzing hotspot functions using LLVM intermediate representation (IR), we identify operation patterns with a repetition rate >85% in the SM4 / SM3 algorithm (such as S-box permutation in the SM4 round function), and use a dynamic hash allocation algorithm to generate a unique opcode for each extended instruction.

[0166] The microarchitecture of the Random Access Enhanced Unit (REU) is automatically generated based on Verilog parameterized templates, supporting 256-bit wide data paths (such as dedicated bus designs for knowledge bases).

[0167] During the instruction definition phase, LLVM intermediate representation is used to analyze hotspot functions, and performance profiling tools (gprof, perf) are introduced to obtain information such as function call frequency and execution time during program execution from the perspective of runtime statistics. This information is then corroborated with the LLVM analysis results to identify hotspots more comprehensively and accurately.

[0168] The following steps are required to cross-reference the results of performance profiling tools (gprof, perf) with LLVM analysis:

[0169] S100. Data Standardization and Integration: Since the data formats and meanings output by LLVM analysis results and performance profiling tools may differ, a data standardization mechanism needs to be established. For example, a unified function naming convention should be adopted, mapping function names in the LLVM intermediate representation to actual runtime function names, so that corresponding functions can be found in data from different sources. Simultaneously, execution time, call frequency, and other data obtained from different tools should be standardized to the same time unit and statistical dimension to facilitate subsequent comparative analysis.

[0170] S101. Timestamp Synchronization: Performance profiling tools acquire data during program runtime, while LLVM analysis occurs during the compilation phase. To accurately correlate runtime and compile-time information, timestamps need to be added during program runtime. During compilation, LLVM instrumentation technology inserts timestamps at the entry and exit points of critical functions or code blocks. At runtime, performance profiling tools acquire these timestamps and, combined with their own recorded time information, establish a time correlation between compile-time and runtime, ensuring that runtime performance data corresponds to compile-time code analysis.

[0171] S102. Code Location Mapping: LLVM analysis is based on intermediate representation code, while performance profiling tools obtain execution information from the actual machine code. It is necessary to establish a mapping relationship between IR code and machine code. Through debugging information during the compilation process (such as DWARF format), the execution location of the machine code can be traced back to the corresponding intermediate representation code line. This allows the machine code performance data obtained from performance profiling tools to be located in the intermediate representation code of LLVM analysis, facilitating comprehensive analysis of hotspot code.

[0172] S103. Data Analysis Algorithm: The Bayesian fusion algorithm, a data fusion algorithm, is employed. It combines code structure and control flow information obtained from LLVM analysis with function call frequency and execution time data acquired from performance profiling tools to calculate the probability of each function or code block becoming a hotspot. Based on this probability value, hotspot areas are identified more accurately, avoiding potential misjudgments that may occur with single-tool analysis.

[0173] In some implementations, Bayes' formula can be: In hotspot function identification, let A represent the event that a function is a hotspot function, and B represent the first analysis result and the second analysis result. P(A) is the prior probability that the function is a hotspot function, set based on experience or preliminary analysis. For example, in a certain type of program, functions of specific functional modules are given a higher prior probability. P(B / A) is the likelihood probability of observed data given that the function is a hotspot function. For example, if the function is a hotspot function, the probability that performance profiling tools will count high call frequency and long execution time. P(B) is the total probability of observed data B, used for normalization. By continuously updating P(A / B), a more accurate posterior probability of the function being a hotspot function is obtained.

[0174] The dynamic hash allocation algorithm uses chaining to resolve hash collisions, using the lower 8 bits of the opcode as the hash value to map the instruction opcode to the hash table. The hash table size is dynamically adjusted based on the expected number of expanded instructions, ensuring the hash table's load factor remains within a reasonable range and preventing excessive hash collisions from impacting performance. Simultaneously, the hash table is periodically cleaned and optimized to further improve the efficiency and accuracy of opcode allocation.

[0175] When automatically generating the REU microarchitecture based on Verilog parameterized templates, its internal structure design was refined. The data path employs time-division multiplexing technology combined with pipelined design to ensure efficient time-sharing execution of different computational tasks within a 256-bit wide data path. The interface design between REU and other modules follows standard bus protocols, such as the AXI bus, guaranteeing data transmission reliability and compatibility. Simultaneously, the internal register file of REU was optimized with a dual-port design, allowing simultaneous read and write operations to improve data access speed.

[0176] S2: Instruction loading stage;

[0177] The dynamic loading protocol is executed. During the instruction fetching phase, the instruction descriptor is loaded through the double buffering mechanism of the DILP protocol (32KB main buffer + 32KB shadow buffer). The EdDSA signature algorithm is used to verify the integrity of the instruction packet. If the verification fails, an exception handling process is triggered.

[0178] EdDSA signs the hash value of the command packet with a private key, generating a unique signature. The confidentiality of the private key is crucial to the signature's unforgeability. Due to the intractable nature of the elliptic curve discrete logarithm problem upon which EdDSA is based, attackers find it extremely difficult to deduce the private key from the public key and the signature, thus making it impossible to forge a valid signature. Even if an attacker intercepts a legitimate command packet and signature, they cannot generate a new legitimate signature without possessing the private key, ensuring the integrity and authenticity of the command packet during transmission and loading.

[0179] S3: Instruction execution phase;

[0180] Data path reconstruction: Based on the configuration parameters in the instruction descriptor, the matrix switch reconfiguration of REU is completed within 3 clock cycles.

[0181] Exception handling involves real-time monitoring of instruction CPI (ClocksPerInstruction) via the IPA module. Dynamic optimization is triggered when the execution cycle of a single instruction exceeds a preset threshold.

[0182] S4: Verification and optimization phase;

[0183] Formal verification was performed using the UCLID5 tool to examine the timing properties of the instructions to ensure compliance with the RISC-V memory consistency model.

[0184] Dynamic optimization: Based on a genetic algorithm, the number of pipeline stages of the REU is automatically adjusted to find the optimal energy efficiency ratio configuration.

[0185] Regarding the instruction encoding space partitioning mechanism, a 4-bit extension bit reserve area is set for the opcode region. When functional expansion of a specific standard opcode is required, this reserved area is used for encoding expansion. At the hardware level, a dedicated hardware decoder is designed, which can automatically identify the extension bits and adjust the instruction execution logic, ensuring that functional expansion is achieved without redesigning the entire opcode region. This effectively guarantees the scalability and compatibility of the standard opcode region within a limited space, while reducing the impact of functional expansion on the original instruction set.

[0186] In instruction encoding design, a 4-bit extension area is pre-allocated in the opcode region. When a function extension is needed for a specific standard opcode (e.g., adding a new function with saturation operation to the existing addition instruction): there is no need to redesign the encoding rules of the entire standard opcode region, thus avoiding disruption of the original instruction system's compatibility. Extension encoding is performed solely through this 4-bit reserved area—a specific 4-bit binary code is assigned to the new function, and this code is bound to the original standard opcode, ensuring that the extended function instruction can be recognized without occupying the original opcode space, maintaining compatibility with older instructions.

[0187] When the instruction enters the decoding stage, the hardware decoder first parses the standard opcode, and then automatically detects the reserved 4-bit extension bit. If the extension bit is "0000" (no extension), the original logic is executed; if the preset extension code (such as "1010") is detected, the extension function processing flow is triggered.

[0188] A new dynamic energy consumption monitoring module has been added to the reconfigurable execution unit. This module is closely connected to the programmable data path matrix and vector register set, enabling real-time monitoring of energy consumption during data transmission and computation. Once energy consumption exceeds a preset threshold, an energy-saving adjustment mechanism is automatically triggered. This mechanism reduces energy consumption by adjusting the switching frequency of the data path and the read / write mode of the vector registers. Furthermore, the energy consumption data is fed back to the processor's control unit, allowing it to comprehensively consider energy consumption factors during task scheduling and instruction allocation, thereby improving the overall system's energy efficiency management.

[0189] The core of the programmable data path matrix is ​​to dynamically reconfigure the data transmission path through matrix switches. Its energy consumption is directly related to the switching frequency. When the dynamic energy consumption monitoring module detects that the energy consumption exceeds the threshold, it will reduce the switching frequency of non-critical operation paths to reduce the energy loss caused by high-frequency switching. For critical paths, it will maintain the necessary frequency to ensure performance, realizing on-demand frequency allocation. That is, without affecting the core function, dynamic power consumption is reduced by reducing the switching activity of non-essential paths.

[0190] The energy consumption of the vector register set mainly comes from the circuit activation during data read and write processes, such as the switching of register ports and the level switching of data transmission. Multiple scattered register accesses are merged into a single batch access, reducing the number of times register ports are switched and reducing trigger energy consumption. For vector registers that do not need to be accessed temporarily (such as registers that have completed data caching and are not needed for subsequent operations), switch to low-power read and write mode, that is, turn off some of the internal drive circuits of the register and only retain the data holding function to reduce static power consumption.

[0191] In the signature verification stage of the dynamic instruction loading protocol, in addition to employing the EdDSA signature algorithm, a blockchain-based distributed verification technology is also introduced. Specifically, the hash value and signature information of the instruction packet are uploaded to specific nodes in the blockchain network. During instruction loading, in addition to local verification, verification results from multiple nodes in the blockchain network are obtained for cross-verification. If the local verification results are inconsistent with the verification results from a majority of nodes, the system will immediately trigger a security alert and stop instruction loading, greatly enhancing the security and reliability of instruction packet verification and effectively preventing malicious tampering and forgery of instructions.

[0192] In the three-level instruction encoding space partitioning mechanism of this disclosure, the variable-length encoding format of the dynamic extension area flexibly adjusts the length from 8 to 48 bits according to the actual needs of the instruction, effectively improving the utilization rate of the encoding space. For example, in complex algorithm processing, frequently used short instructions can be compactly encoded to reduce storage overhead; long instructions with complex operations can also be fully accommodated, enhancing the expressiveness of the instructions. Dynamic remapping, version management, and hash verification mechanisms work together to ensure system stability and security. Dynamic remapping resolves instruction conflicts through the encoding offset register, avoids execution errors when manufacturers customize extensions, and improves flexibility and scalability; the 2-bit version number supports four generations of instruction iteration, maintaining compatibility with older versions and helping hardware adapt to newer versions; the SHA-3 hash algorithm generates a feature code to ensure the uniqueness of the encoding, prevent conflicts, stabilize the instruction set architecture, reduce the risk of system failure, enhance reliability, and lay a solid foundation for the long-term stable operation of the system.

[0193] The reconfigurable execution unit (REU) comprises four 128-bit vector register sets, two dedicated status registers, and a programmable data path matrix. Its ability to reconfigure and switch operational modes within a single cycle significantly enhances operational flexibility and efficiency. In multi-tasking scenarios, it can quickly adapt to different computational tasks, such as rapidly switching between image processing and data encryption tasks, avoiding the performance losses associated with frequent task switching in traditional fixed-function architectures. The internal structure is significantly optimized. The 256-bit wide data path employs time-division multiplexing and pipeline technology, enabling efficient time-sharing execution of computational tasks and improving data throughput. The REU connects to other modules via standard protocols such as the AXI bus, ensuring reliable and compatible data transmission. The dual-port register file design enables simultaneous read and write operations, accelerating data access and enhancing overall processor performance and system execution efficiency.

[0194] The dynamic instruction loading protocol's dual-buffering mechanism (32KB main buffer + 32KB shadow buffer) effectively ensures efficient and continuous instruction loading. During the processor's instruction fetching phase, extended instructions can be quickly retrieved, avoiding pipeline stalls caused by waiting for instruction loading and improving operational efficiency. The EdDSA signature algorithm provides robust protection for instruction packet integrity verification. Based on the elliptic curve discrete logarithm problem, its strong security and private key secrecy ensure that the signature cannot be forged. Throughout instruction transmission and loading, it effectively resists malicious tampering attacks, maintaining system data security. Compared to traditional single-buffering and weakly secure signature algorithms, this scheme significantly reduces the risk of instruction transmission errors and security vulnerabilities, enhances system security and stability, and ensures stable and reliable processor operation, which is particularly important in complex network environments and security-sensitive applications.

[0195] The instruction-level performance analysis module and hybrid verification mechanism have yielded significant results. Real-time monitoring of extended instruction execution efficiency triggers dynamic optimization when instruction execution cycles exceed thresholds based on metrics such as CPI, accurately pinpointing performance bottlenecks. For example, in loop-intensive algorithms, it can quickly identify and optimize inefficient instructions. The combination of static verification using the UCLID5 tool and dynamic behavior verification from the hardware simulation platform comprehensively ensures the correctness of instruction timing characteristics and functions. During the verification and optimization phases, a genetic algorithm intelligently adjusts the REU pipeline stages to search for the optimal energy efficiency ratio configuration. Under different load scenarios, it automatically adapts to hardware resources, balancing performance and energy consumption, improving overall system performance, extending device battery life, enhancing the system's adaptability and competitiveness in diverse application scenarios, and effectively improving resource utilization efficiency.

[0196] like Figure 4 As shown, the software architecture of this embodiment may include: an application layer, an intermediate representation layer, a runtime system layer, a hardware abstraction layer, and a physical device layer. The application layer provides an inline assembly interface and compiler built-in functions; the intermediate representation layer supports extended nodes of the LLVM intermediate representation to support custom pattern matching; the runtime system layer includes a DILP protocol stack and a REU configuration manager; the hardware abstraction layer provides an instruction encoding mapping table and a performance counter interface; and the physical device layer provides a REU register file interface and a dynamic configuration bus.

[0197] The embodiments disclosed herein can also be extended as follows:

[0198] 1. The four 128-bit vector register sets can be replaced with more flexible configurable vector register sets. For example, an FPGA-based reconfigurable vector register set can be used, and the number, bit width, and other parameters of the vector registers can be dynamically configured at runtime according to different application requirements to adapt to different computing tasks.

[0199] 2. The programmable data path matrix uses a crossbar-based structure instead. Crossbars provide more direct data path connections, reduce signal transmission delay, and improve data transmission efficiency.

[0200] 3. In addition to the double buffering mechanism of main buffer and shadow buffer, a circular buffering mechanism can also be used. A circular buffer is a cyclically used buffer; when the buffer is full, new data overwrites the oldest data. This reduces memory usage and performs better in terms of data loading continuity, especially for situations where the instruction packet size is uncertain.

[0201] This disclosure includes at least the following pre-protection points:

[0202] 1. A unique three-level instruction encoding space partitioning mechanism has been established, which meticulously divides the 32-bit instruction encoding space into an opcode area, a reserved area, and an extension area. The extension area supports variable-length encoding formats from 8 bits to 48 bits, which can flexibly adjust the instruction length according to the actual needs of the instruction. Compared with traditional fixed-length instruction encoding, this greatly improves the utilization rate of the encoding space and enhances the expressive power of the instruction set.

[0203] 2. Dynamic remapping, version management, and hash verification mechanisms for instruction encoding are implemented. When an instruction conflict is detected, the opcode allocation is automatically adjusted through the encoding offset register to ensure that no encoding conflicts occur during instruction set expansion, thus guaranteeing system stability. The 2-bit version number field supports four generations of instruction iterations for the same opcode, ensuring backward compatibility. The SHA-3 algorithm is used to generate instruction signatures, ensuring the uniqueness of encoding space allocation, avoiding instruction encoding conflicts, and comprehensively guaranteeing the security and stability of the instruction set.

[0204] 3. A dynamic instruction loading protocol employs a double-buffering mechanism (32KB main buffer + 32KB shadow buffer) to synchronously load extended instructions during the instruction fetch stage of the processor pipeline. This includes three parts of data: instruction semantic descriptor, hardware configuration parameters, and verification signature. This approach ensures the efficiency and continuity of instruction loading, improving the processor's operating efficiency.

[0205] 4. The reconfigurable execution unit is designed to include multiple vector register groups, dedicated status registers and programmable data path matrices, and supports switching operation modes within a single cycle through microcode reconfiguration.

[0206] 5. The integrity of the instruction packet is verified using the EdDSA signature algorithm. EdDSA is based on the elliptic curve discrete logarithm problem, which has the characteristics of resistance to quantum attacks and the signature cannot be forged.

[0207] It should be understood that the phrase "an embodiment" or "one 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 disclosure. Therefore, "in one embodiment" or "one 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 disclosure, 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 disclosure. The sequence numbers of the above embodiments of this disclosure are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0208] 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.

[0209] In the several embodiments provided in this disclosure, 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 may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0210] 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.

[0211] In addition, each functional unit in the various embodiments of this disclosure 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 the form of hardware plus software functional units.

[0212] 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 that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0213] Alternatively, if the integrated units described above are implemented as software functional units 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 disclosure, 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 a computer 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 disclosure. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0214] The above description is merely an embodiment of this disclosure, but the scope of protection of this disclosure 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 disclosure should be included within the scope of protection of this disclosure.

Claims

1. A data processing system based on RISC-V, characterized in that, The data processing system includes an instruction encoding space and a reconfigurable execution unit; the instruction encoding space includes an opcode area, a reserved area, and an extension area. The instruction encoding space is used to define the basic operation to be performed by the instruction in the opcode area, to define the extended operation to be performed by the instruction in the reserved area, and to define the length of the instruction in the extended area, so as to configure different types of instructions; The reconfigurable execution unit is used to construct the data path matrix of the instruction based on the configuration information of the instruction; The data required for the execution of the instruction is transmitted based on the data path matrix; the operation corresponding to the instruction is executed based on the data of the instruction. The instruction encoding space also includes an encoding space mapping unit and an encoding offset register; The encoding space mapping unit is used to store the length identifier of the instruction in the first-level table and the operand type and register mapping relationship of the instruction in the second-level table. The encoding offset register is used to determine the offset corresponding to the opcode of the instruction when the opcode of the instruction conflicts with the encoding of an existing instruction according to the first-level table and the second-level table, based on the available encoding space of the conflict area; and to adjust the opcode of the instruction based on the offset to obtain a new opcode. The encoding space mapping unit is used to update the length identifier of the new opcode to the first-level table; Update the operand types and register mappings of the new opcode to the second-level table.

2. The data processing system according to claim 1, characterized in that, The opcode area is used to define the basic operation of the instruction using the binary value of the first bit. The reserved area is used to define the extended operation of the instruction using a hierarchical coding structure and a binary value of the second bit. The extended region is used to define the length of the instruction using a prefix encoding mechanism with the binary value of the third bit.

3. The data processing system according to claim 1 or 2, characterized in that, The reconfigurable execution unit includes a vector register, a status register, and a programmable data path matrix; The vector register is used to store the configuration information of the instruction; The status register is used to determine the routing rules based on the configuration information of the instruction; The programmable data path matrix is ​​used to control the conduction of the matrix switch corresponding to the instruction according to the routing rules, so as to establish the data path matrix of the instruction.

4. The data processing system according to claim 1 or 2, characterized in that, The data processing system also includes an address mapping unit; The address mapping unit is used to offset the target address of the extended instruction to an idle base register based on the association between the two-level mapping table and the register address when there is a register access conflict between the extended instruction and the base instruction. The two-level mapping table includes a static mapping table and a dynamic mapping table; the static mapping table is used to map the virtual register identifier of the extended instruction to the physical addresses of the base register and the floating-point register; the dynamic mapping table is used to adjust the address offset in real time according to the encoding offset register.

5. The data processing system according to claim 4, characterized in that, The address mapping unit is also used to map vector data to a floating-point register according to the mapping rules; to convert data in a custom format to a scalar format supported by the basic instructions, so as to store the custom format data in a general-purpose register; the conversion process is identified by the storage format of the status register.

6. The data processing system according to claim 3, characterized in that, The data processing system also includes a detection unit; The detection unit is used to detect the energy consumption of the instruction during data transmission and execution; when the energy consumption of the data processing system is greater than the energy consumption threshold, the data processing system is optimized; the optimization includes at least one of the following: adjusting the switching frequency of the data path matrix, the read / write mode of the vector register, and the scheduling method of the instruction.

7. The data processing system according to claim 1 or 2, characterized in that, The reconfigurable execution unit further includes an instruction loading unit; The instruction loading unit is used to load the relevant data of the instruction currently being processed into the first cache area, and at the same time load the relevant data of the instruction to be processed into the second cache area.

8. A data processing method based on RISC-V, characterized in that, The data processing method, applied to a RISC-V-based data processing system, includes: Based on the repetition rate of multiple operation modes in the target algorithm, multiple instructions are generated for the target algorithm; Based on the configuration information of each of the multiple instructions, construct the data path matrix of each of the multiple instructions; Based on the data path matrix, the data required for the execution of the corresponding instruction is transmitted; The operation corresponding to each instruction is executed based on the data of each of the multiple instructions, so as to realize the processing of the target algorithm; The data processing method further includes: If, based on the first-level table and the second-level table, it is determined that the opcode of the instruction conflicts with the encoding of an existing instruction, the offset corresponding to the opcode of the instruction is determined based on the available encoding space of the conflict area; the first-level table stores the length identifier of the instruction, and the second-level table stores the operand type and register mapping relationship of the instruction; The opcode of the instruction is adjusted based on the offset to obtain a new opcode; Update the length identifier of the new opcode to the first-level table; Update the operand types and register mappings of the new opcode to the second-level table.

9. The data processing method according to claim 8, characterized in that, Based on the repetition rate of multiple operation modes in the target algorithm, multiple instructions are generated for the target algorithm, including: The execution process of the target algorithm is analyzed to determine the repetition rate of each of the multiple operation modes; From the multiple operation modes, determine the operation mode with a repetition rate greater than the repetition rate threshold to obtain at least one high-frequency operation mode; Generate an extended instruction for each of the aforementioned high-frequency operation modes; Generate a basic instruction for each operation mode other than the high-frequency operation mode.

10. The data processing method according to claim 9, characterized in that, The analysis of the execution process of the target algorithm to determine the repetition rate of each of the multiple operation modes includes: The execution process of the target algorithm during compilation is analyzed based on the intermediate representation of the target algorithm to obtain a first analysis result; the intermediate representation is used to characterize the program structure of the target algorithm. The execution process of the target algorithm during runtime is analyzed using performance testing tools to obtain a second analysis result; The first analysis result and the second analysis result are comprehensively evaluated to determine the repetition rate of each of the multiple operation modes.

11. The data processing method according to claim 10, characterized in that, The step of comprehensively evaluating the first analysis result and the second analysis result to determine the repetition rate of each of the multiple operation modes includes: The first analysis result and the second analysis result are standardized to obtain standard first analysis result and standard second analysis result; the standardization process includes at least one of the following: function name unification and time unification; Based on the timestamps contained in the first and second analysis results of the standard, a temporal correlation is established between the first and second analysis results of the standard. Based on the execution status of the first analysis result and the second analysis result of the standard, establish the correlation between the first analysis result and the second analysis result of the standard at the execution location; Based on the correlation in time and the correlation in execution location, the first analysis result and the second analysis result of the standard are comprehensively evaluated to determine the repetition rate of each of the multiple operation modes.

12. The data processing method according to any one of claims 8 to 11, characterized in that, The data processing method further includes: The data packet of the instruction is verified based on the feature code in the instruction and the verification information about the instruction obtained from the blockchain network to determine whether the data packet of the instruction is abnormal; the verification information includes at least one of the following: the result of verification of the data packet of the instruction by at least one node in the blockchain network, and information after hashing and / or signing the data packet of the instruction.

Images