A multi-architecture instruction analysis method, device, equipment, medium and product

Abstract

This invention discloses a multi-architecture instruction analysis method, apparatus, device, medium, and product. The method includes: acquiring multi-architecture binary files and extracting the executable target file format segments of the corresponding processors, naming and storing them according to the architecture identifier specification; matching the disassembly parameter set according to the architecture identifier in the target output file name, and processing multiple target output files in parallel disassembly mode to obtain disassembly text files of various target architectures; scanning the disassembly text files line by line, identifying instruction prefixes, extracting opcodes and concatenating them; using a hash table to count the occurrence frequency of opcodes to obtain an opcode count mapping table corresponding to each disassembly text file; hierarchically classifying the opcodes and mapping them to instruction categories in the instruction set architecture specification; generating a multi-dimensional statistical report based on the opcode count mapping table; and further generating an instruction coverage change report based on historical analysis results, thereby improving the practicality and reliability of multi-architecture instruction analysis.

Description

Technical Field

[0001] This invention relates to the fields of embedded systems and chip technology, and in particular to a multi-architecture instruction analysis method, apparatus, device, medium, and product. Background Technology

[0002] In the process of compiler and instruction set architecture iteration for heterogeneous computing chips such as GPUs (Graphics Processing Units) and NPUs (Neural Processing Units), it is necessary to continuously grasp key information such as instruction coverage, instruction usage frequency, cross-architecture evolution differences, and historical iteration trends, so as to provide important basis for compiler optimization, instruction set upgrades, and software component adaptation.

[0003] Currently, the industry typically uses manual analysis or simple script statistics to conduct instruction analysis. Some tools rely on manually maintained static instruction lists, support only single architecture analysis, and output results in simple text or tables.

[0004] This approach is difficult to scale up to handle large-scale software stacks and massive amounts of files, reducing analysis efficiency. Because opcodes cannot be reduced to standard instruction categories, statistical results are difficult to align with instruction set architecture manuals. Furthermore, due to the disconnect between instruction set definitions and analysis tools, instruction set changes cannot be automatically identified. Moreover, it lacks the ability to handle multiple architectures in a unified manner, provide interactive visualizations, and compare historical baselines. It is also unable to effectively locate instruction degradation and new coverage, making it difficult to provide effective guidance for compiler iteration and architecture optimization. Summary of the Invention

[0005] This invention provides a method, apparatus, device, medium, and product for multi-architecture instruction analysis, in order to solve the technical problems of low efficiency, non-standard classification, and lack of practical guidance significance in multi-architecture instruction analysis.

[0006] According to one aspect of the present invention, a multi-architecture instruction analysis method is provided, comprising: Obtain the multi-architecture binary files generated by the compiler; Traverse the segment tables in the multi-architecture binary files, extract the executable object file format segment corresponding to at least one processor as the output file, name the output file according to the architecture identifier of the executable object file format segment, and save it to the target storage directory; Multiple target output files are read from the target storage directory. The matching disassembly parameter set is obtained according to the target architecture identifier in the target output file name. The multiple target output files are disassembled in parallel by the underlying virtual machine disassembly tool to obtain disassembly text files corresponding to various target architectures. The process involves scanning each disassembled text file line by line, identifying instruction prefixes and extracting opcodes, and concatenating the prefixes with opcodes containing conditional execution prefixes. A hash table is used to count the occurrences of each opcode to obtain the opcode count mapping table for each disassembled text file. The opcodes in the opcode count mapping table are hierarchically classified, and then mapped to instruction categories in the instruction set architecture specification to obtain the instruction classification results; Based on the opcode count mapping table and instruction classification results, a multi-dimensional statistical report is generated. Combined with historical analysis results, an instruction coverage change report is generated. This report helps to identify instruction usage degradation items and new coverage items in compiler iterations, guiding compiler optimization, instruction set architecture iteration, or software component instruction adaptation adjustments.

[0007] According to another aspect of the present invention, a multi-architecture instruction analysis apparatus is provided, comprising: The file acquisition module is used to acquire multi-architecture binary files generated by the compiler. The format segment extraction module is used to traverse the segment table in multi-architecture binary files, extract the executable target file format segment corresponding to at least one processor as the output file, name the output file according to the architecture identifier to which the executable target file format segment belongs, and save it to the target storage directory. The parallel disassembly module is used to read multiple target output files from the target storage directory, obtain the matching disassembly parameter set according to the target architecture identifier in the target output file name, and perform parallel disassembly on multiple target output files through the underlying virtual machine disassembly tool to obtain disassembly text files corresponding to various target architectures; The line-by-line scanning module is used to scan each disassembled text file line by line, perform operations to identify instruction prefixes and extract opcodes, and concatenate the prefix and opcode for opcodes containing conditional execution prefixes. It uses a hash table to count the occurrences of each opcode to obtain the opcode count mapping table corresponding to each disassembled text file. The specification mapping module is used to hierarchically classify the opcodes in the opcode count mapping table and map the opcodes to the instruction categories specified in the instruction set architecture to obtain the instruction classification results; The report generation module is used to generate multi-dimensional statistical reports based on the opcode count mapping table and instruction classification results, and to generate instruction coverage change reports by combining historical analysis results. Based on the instruction coverage change reports, the module can locate instruction usage degradation items and new coverage items in the compiler iteration, and guide compiler optimization, instruction set architecture iteration or software component instruction adaptation adjustment.

[0008] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the multi-architecture instruction analysis method of any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute and implement the multi-architecture instruction analysis method of any embodiment of the present invention.

[0010] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the method as described in any embodiment of the present invention.

[0011] The technical solution of this invention, by acquiring multi-architecture binary files generated by the compiler and extracting the executable target file format segment of the corresponding processor, and naming and storing them according to the architecture identifier specification, can achieve orderly management of multi-architecture instruction files, avoid confusion between instruction files of different architectures, and lay a well-organized data foundation for subsequent analysis. By matching the disassembly parameter set according to the architecture identifier in the target output file name and processing multiple target output files in parallel, disassembly efficiency can be improved, adapting to the needs of batch analysis of multi-architecture instructions and reducing analysis time. By scanning the disassembled text file line by line, identifying instruction prefixes, extracting opcodes and concatenating them, and combining the opcode occurrence count with a hash table, the usage of instructions for each architecture can be obtained, ensuring the accuracy of opcode counting and providing reliable data support for subsequent classification and statistics. By hierarchically classifying opcodes and mapping them to instruction categories in the instruction set architecture specification, standardized instruction classification can be achieved, facilitating the understanding of the distribution characteristics of different instruction categories and solving the problems of chaotic instruction classification and difficulty in unified analysis across multiple architectures. By combining the opcode count mapping table with instruction classification results to generate multi-dimensional statistical reports, and combining historical analysis results to generate instruction coverage change reports, it is possible to locate instruction usage degradation items and newly added coverage items in compiler iterations. This provides targeted guidance for compiler optimization, instruction set architecture iteration, and instruction adaptation adjustments for software components, improving compiler performance, refining instruction set architecture design, optimizing the compatibility of software components with multiple architectures, and solving the technical problems of low efficiency, non-standardized classification, and lack of practical guidance in existing multi-architecture instruction analysis, thereby enhancing the practicality and reliability of multi-architecture instruction analysis.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart of a multi-architecture instruction analysis method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of another multi-architecture instruction analysis method provided in Embodiment 2 of the present invention; Figure 3 This is a flowchart of another multi-architecture instruction analysis method provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram illustrating a multi-architecture instruction analysis applicable to an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating an instruction parsing and hierarchical classification method applicable to an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating a reflection definition based on an instruction set architecture applicable to an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating a multi-dimensional report generation method applicable to an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a multi-architecture instruction analysis device provided in Embodiment 4 of the present invention; Figure 9 This is a schematic diagram of the structure of an electronic device that implements the multi-architecture instruction analysis method of the present invention. Detailed Implementation

[0015] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0017] Example 1 Figure 1 This is a flowchart of a multi-architecture instruction analysis method provided in Embodiment 1 of the present invention. This embodiment is applicable to the analysis of multi-architecture instructions. The method can be executed by a multi-architecture instruction analysis device, which can be implemented in hardware and / or software and is generally configured in an electronic device. Figure 1 As shown, the method includes: S110. Obtain the multi-architecture binary file generated by the compiler.

[0018] In this embodiment of the invention, a multi-architecture binary file can be specifically understood as a binary file compiled by a compiler that contains executable code for multiple processor architectures, such as a dynamic library file and a fat binary container file. A dynamic library file can be specifically understood as a binary library file containing reusable executable code that is loaded and called during program runtime. A fat binary container file can be specifically understood as a binary file carrier that can encapsulate instruction code for multiple architectures, achieving cross-platform compatibility.

[0019] S120. Traverse the segment table in the multi-architecture binary file, extract the executable object file format segment corresponding to at least one processor as the output file, name the output file according to the architecture identifier of the executable object file format segment, and save it to the target storage directory.

[0020] In this embodiment of the invention, the segment table can be specifically understood as an index table within the binary file used to record information such as the location, size, and attributes of each functional segment. The processor can be specifically understood as a hardware unit that executes instruction operations, such as a GPU and an NPU.

[0021] The executable object file format segment can be specifically understood as: a program segment in a binary file that stores machine instructions that the processor can directly execute. The architecture identifier can be specifically understood as: a marker used to uniquely distinguish different processor architectures, used to identify the hardware platform to which the instructions belong, such as GCU (General Compute Unit) 3.0, GCU 4.0, GCU 5.0, DTU (Deep Thinking Unit), EFGCU (Enhanced General Compute Unit), GPU, and NPU architecture versions or platform type identifiers.

[0022] Specifically, the compiler-generated multi-architecture binary files, such as dynamic library files (.so files) or fat binary container files, are obtained. By traversing the segment table inside the multi-architecture binary files, executable target file format segments adapted to at least one processor (such as GPU or NPU) are filtered and extracted. These segments are standard ELF (Executable and Linkable Format) processor executable segments.

[0023] The extracted executable target file format segment is treated as an independent output file. The file is named according to its own architecture identifier, and the named output files are saved to the target storage directory.

[0024] Understandably, executable segments corresponding to multiple processor architectures can be extracted simultaneously and stored according to architecture type to meet the needs of parallel analysis of multi-architecture instructions.

[0025] Optionally, based on the above embodiments, naming the output file according to the architecture identifier of the executable object file format segment and saving it to the target storage directory may include: Create a new target first-level directory under the target storage directory, and combine the component name to which the multi-architecture binary file belongs with the original file name of the multi-architecture binary file as the directory name of the target first-level directory; combine the architecture identifier, segment number, chip type and file format in sequence to obtain the target file name, and use the target file name to name the output file; store the named output file in the target first-level directory.

[0026] In this embodiment of the invention, the component name can be specifically understood as: the name of the software module that generates the binary file, such as the name of the operator library, driver library, and computing library. The original file name can be specifically understood as: the file name of the multi-architecture binary file output by the compiler itself. The target first-level directory can be specifically understood as: a first-level folder named by a combination of the component name and the original file name, used to categorize executable segment files from the same source.

[0027] Segment number can be understood as: the number of the executable object file format segment in the segment table, used to distinguish multiple executable segments from the same source. Chip type can be understood as: the processor chip model to which the instructions are adapted, used to distinguish hardware platforms. File format can be understood as: the format type of the output file, such as ELF format.

[0028] Specifically, a new target first-level directory is created under the target storage directory. The component name to which the multi-architecture binary file belongs is combined with the original file name to form the name of the target first-level directory. The architecture identifier, segment number, chip type and file format are combined in sequence to form the target file name. The extracted executable target file format segment is named using the target file name. The named output file is stored in the corresponding target first-level directory.

[0029] In a specific example, since the compiler compiles the processor kernel functions into independent ELF segments and stores them in the host dynamic library, this step can use a dedicated binary parsing tool to traverse the section table of the .so format dynamic library file or fatbin container file to identify and extract the ELF segments corresponding to all processor executable code.

[0030] Name the components and original filenames in a way that combines the component name and the original filename (e.g., the naming rule "component name_original filename") and output them to a unified ELF directory structure.

[0031] This directory structure can use the `elf` directory under the working directory as the root directory. The root directory contains subdirectories named after each component library. These subdirectories store ELF files named according to architecture identifier, segment number, and chip type. It also supports storing relevant files extracted from the fat binary generated by just-in-time compilation. For example, the extracted directory structure could be: ".

[0032] The directory structure is as follows: "work / elf / " is the unified root directory established for the instruction analysis process, used to centrally store all extracted ELF files. "pcals_libeccl.so / " and "topsop_libkernel_xxx.so / " are first-level subdirectories named after the component names (pcals library and topsop library) and the original dynamic library file names (libeccl.so and libkernel_xxx.so), used to distinguish executable segments generated from different software components and source files, achieving component-based categorization. "triton_gcu / " is a categorization directory established for executable segments extracted from Just-In-Time (JIT) fat binaries, used to distinguish between offline compilation libraries and instruction files generated by JIT compilation. "gcu300" represents the architecture identifier and chip type, indicating the processor architecture version and chip model to which the file is adapted (e.g., General Computing Unit 3.0 architecture). "gcu" indicates the processor architecture type, specifying that the file is applicable to the General Computing Unit architecture. "0001" and "0002" are segment numbers, used to uniquely identify executable segments with different functions in different locations within the same dynamic library, avoiding conflicts with files of the same name. The ELF file format identifier indicates that the file is an executable and linkable file.

[0033] By using a combination of component names and original file names to name the target top-level directory, and using a combination of architecture identifier, segment number, chip type, and file format to name the output files, it is possible to clearly distinguish and orderly classify executable target files from different sources, architectures, and segment numbers. This avoids naming conflicts or storage chaos in multi-architecture and multi-component files, while constructing a hierarchical directory structure, which facilitates the rapid location, reading, and management of target files. This provides a well-organized and easily traceable data foundation for subsequent parallel disassembly, instruction statistics, and analysis, improving the standardization and execution efficiency of the entire multi-architecture instruction analysis process.

[0034] S130. Read multiple target output files from the target storage directory, obtain the matching disassembly parameter set according to the target architecture identifier in the target output file name, and perform parallel disassembly on multiple target output files through the underlying virtual machine disassembly tool to obtain disassembly text files corresponding to multiple target architectures.

[0035] In this embodiment of the invention, the disassembly parameter set can be specifically understood as: configuration parameters for disassembly tools adapted to the corresponding architecture. The underlying virtual machine disassembly tool can be specifically understood as: an objdump (object dump, a standard tool for viewing and disassembling binary object files) disassembly tool based on LLVM (Low Level Virtual Machine, a collective term for a complete compilation infrastructure), used to convert machine code into assembly text. The disassembly text file can be specifically understood as: an assembly instruction text file generated by the disassembly tool, such as a .dis (disassembly) format file.

[0036] Specifically, the input data is the ELF file extracted in the previous stage. A thread pool is used for task scheduling, and threads can be allocated to handle the corresponding file conversion tasks.

[0037] Multiple target output files are read in batches from the target storage directory. The system automatically matches and obtains the corresponding disassembly parameter sets by scanning the architecture identifiers in the filenames. The system maintains a mapping table between architecture identifiers and disassembly parameter sets to achieve multi-architecture compatibility. A thread pool scheduling mode is used to allocate disassembly tasks. The underlying virtual machine disassembly tool is used to perform disassembly processing on multiple target output files in parallel, resulting in disassembly text files corresponding to various target architectures. The generated disassembly text files are stored in a directory structure grouped by component name.

[0038] S140. Scan each disassembled text file line by line, perform the operations of identifying instruction prefixes and extracting opcodes, and concatenate the prefix and opcode for opcodes containing conditional execution prefixes. Count the occurrence of each opcode using a hash table to obtain the opcode count mapping table corresponding to each disassembled text file.

[0039] In this embodiment of the invention, the instruction prefix can be specifically understood as: an identifier located at the beginning of the instruction, used to limit execution conditions and extended functions, etc. The conditional execution prefix can be specifically understood as: a prefix marker indicating that the instruction is executed only when a specific condition is met. The opcode can be specifically understood as: a core identifier in assembly instructions representing the specific operation to be performed. The hash table can be specifically understood as: a data structure that quickly stores and updates instruction counts using key-value pairs. The opcode count mapping table can be specifically understood as: a table recording the correspondence between each opcode and its corresponding number of occurrences.

[0040] Specifically, each disassembled text file is scanned line by line, identifying instruction prefixes and extracting opcodes. For example, the line indicating "Disassembly of section" is located; the content before this line is the file header information and is skipped. Only the valid disassembled code region after this line is processed.

[0041] For each line in the valid region, check whether it contains an instruction prefix. Valid instruction lines are identified using a pre-defined set of instruction prefixes for various types, including Load (load operation), matrix, vector, and scalar.

[0042] The predefined set of multiple instruction prefixes used to identify valid instructions can be: {"\tl.", "\tm.", "\ts.", "\tv.", "\tc.", "\tgemm.", "\tmld.", "\tmli.", "\tmst.", "\ts0."}.

[0043] In this context, \t represents a tab character, l represents a load or scalar operation slot, m represents a matrix operation slot, s represents a scalar / store slot, v represents a vector operation slot, c represents a compression instruction slot, and gemm, mld, mli, mst, and s0 represent special function unit instructions. When parsing disassembled text, only lines containing any of the above instruction prefixes are considered valid instruction lines and proceed to the opcode extraction process; all other lines are skipped as invalid content.

[0044] Specifically, a slot can be understood as a channel or instruction dispatch port for a hardware execution unit. In other words, a chip contains multiple execution units with different functions, each corresponding to an instruction slot. Compilers and assembly instructions use different prefixes to specify the matching slot or hardware unit to execute the instruction.

[0045] Locate the instruction prefix, skip the tabs in the prefix, and extract the text starting from the prefix character until you encounter the separator (such as a space character) between the next instruction and operand. Use the extracted substring as the complete opcode.

[0046] Since the opcodes of some extended instructions contain suffix identifiers, followed by special registers or macro operands in uppercase, truncation using conventional delimiters can lead to incomplete opcode extraction. By detecting uppercase letter features and continuing truncation up to the comma delimiter, we can ensure that the opcodes of such extended instructions are extracted completely, avoiding instruction recognition omissions and statistical distortions, and improving the accuracy and completeness of opcode statistics.

[0047] Therefore, for special instructions where the opcode is followed by uppercase operands (such as c.movsr2spr.ext INTR_MASK_SD, where the opcode is followed by uppercase operands), adaptation processing is performed. That is, it checks whether the first character after the separator between the instruction and the operand is an uppercase letter. If it is an uppercase letter, it continues to extract text until it encounters a comma separator, and finally extracts the accurate complete opcode.

[0048] Because some instructions are not executed unconditionally, but have a conditional execution prefix in the format if (xpr) (conditional predicate execution, i.e., execution when the condition in the predicate register xpr is true), they will only run if the predicate register condition is met. For example, if (lpr) l.adda means that if the condition in the lpr scalar predicate register is true, then the l.adda scalar address addition instruction will be executed.

[0049] Therefore, it is also necessary to concatenate the prefix and opcode for opcodes containing conditional execution prefixes to form a complete instruction identifier.

[0050] For example, during parsing, the system checks whether the instruction line contains the "if (" marker. If it does, the system extracts the conditional expression between "if (" and ")", then concatenates it with the extracted opcode to form a whole, such as if (lpr) l.adda. This concatenated result is counted as an independent and unique opcode, avoiding confusion between conditional execution instructions and ordinary instructions without preconditions, and ensuring accurate distinction in instruction statistics.

[0051] Finally, the occurrence count of each opcode is recorded using a hash table to generate an opcode count mapping table corresponding to each disassembled text file.

[0052] For example, each complete opcode extracted from the disassembled file (including ordinary opcodes and complete instructions concatenated with conditional execution prefixes) is used as a unique key. The count of each occurrence of the same opcode is incremented in a hash table. Once all instruction lines of a single .dis disassembled file have been parsed, the hash table stores all opcodes in the file and their occurrence counts. A mapping table with opcodes as keys and occurrence counts as values ​​is output for subsequent instruction classification and coverage analysis.

[0053] S150. Perform hierarchical classification of the opcodes in the opcode count mapping table, and map the opcodes to the instruction categories specified in the instruction set architecture to obtain the instruction classification results.

[0054] In this embodiment of the invention, hierarchical classification can be specifically understood as: classifying opcodes level by level according to multi-level rules to achieve standardized instruction grouping. Instruction Set Architecture (ISA) specification instruction categories can be specifically understood as: standard instruction types defined in the Instruction Set Architecture (ISA) manual. Instruction classification results can be specifically understood as: standardized instruction classification information aligned with the ISA manual and conforming to the ISA standard.

[0055] S160. Based on the opcode count mapping table and instruction classification results, generate a multi-dimensional statistical report and combine it with historical analysis results to generate an instruction coverage change report. Based on the instruction coverage change report, locate the instruction usage degradation items and new coverage items in the compiler iteration, and guide the compiler optimization, instruction set architecture iteration or software component instruction adaptation adjustment.

[0056] In this embodiment of the invention, the multi-dimensional statistical report can be specifically understood as an analysis report that statistically analyzes data from the perspectives of instructions, categories, components, architecture, and versions. The instruction coverage change report can be specifically understood as a comparative report that compares historical data to reflect changes in instruction coverage. Instruction usage degradation items can be specifically understood as instructions that are no longer used or whose usage has decreased after compiler iterations. New coverage items can be specifically understood as instructions that are newly used after compiler iterations.

[0057] Specifically, hierarchical classification processing is performed on various opcodes in the opcode count mapping table, mapping each opcode to an instruction category specified in the instruction set architecture specification, resulting in standardized instruction classification results that conform to the instruction set architecture manual.

[0058] For example, a multi-level classification model based on instruction function semantics and architecture standards can be pre-built. Each opcode in the opcode count mapping table is input into the classification model. Hierarchical classification is completed through instruction semantic matching, architecture standard alignment and automatic reduction processing. Then, according to the pre-imported instruction set architecture specification definition, the classified opcodes are mapped to the corresponding standard instruction categories to form a standardized instruction classification result consistent with the official instruction set architecture manual. Stable and efficient instruction classification can be achieved without relying on manual operation.

[0059] Based on the opcode count mapping table and instruction classification results, a multi-dimensional statistical report is generated, and combined with historical analysis results, an instruction coverage change report is generated. This helps to locate instruction usage degradation items and new coverage items in the compiler iteration process, providing guidance for compiler optimization, instruction set architecture iteration, and software component instruction adaptation adjustments. It also facilitates the compilation and architecture accounting teams to check the usage of hardware optimization instructions and the testing teams to verify the completeness of test case coverage of the instruction set.

[0060] For example, based on the opcode count mapping table and instruction classification results, the system aggregates and quantitatively analyzes the number, proportion, and distribution of instructions used according to a custom granularity dimension. It automatically generates a multi-dimensional statistical report containing visual charts and detailed data. At the same time, it retrieves historical archived data stored locally or in the cloud as a benchmark, compares the differences between the current data and historical data through difference calculation and trend analysis algorithms, automatically identifies changes in instruction coverage, and generates an instruction coverage change report containing change details, trend analysis, and optimization suggestions.

[0061] The technical solution of this invention, by acquiring multi-architecture binary files generated by the compiler and extracting the executable target file format segment of the corresponding processor, and naming and storing them according to the architecture identifier specification, can achieve orderly management of multi-architecture instruction files, avoid confusion between instruction files of different architectures, and lay a well-organized data foundation for subsequent analysis. By matching the disassembly parameter set according to the architecture identifier in the target output file name and processing multiple target output files in parallel, disassembly efficiency can be improved, adapting to the needs of batch analysis of multi-architecture instructions and reducing analysis time. By scanning the disassembled text file line by line, identifying instruction prefixes, extracting opcodes and concatenating them, and combining the opcode occurrence count with a hash table, the usage of instructions for each architecture can be obtained, ensuring the accuracy of opcode counting and providing reliable data support for subsequent classification and statistics. By hierarchically classifying opcodes and mapping them to instruction categories in the instruction set architecture specification, standardized instruction classification can be achieved, facilitating the understanding of the distribution characteristics of different instruction categories and solving the problems of chaotic instruction classification and difficulty in unified analysis across multiple architectures. By combining the opcode count mapping table with instruction classification results to generate multi-dimensional statistical reports, and combining historical analysis results to generate instruction coverage change reports, it is possible to locate instruction usage degradation items and newly added coverage items in compiler iterations. This provides targeted guidance for compiler optimization, instruction set architecture iteration, and instruction adaptation adjustments for software components, improving compiler performance, refining instruction set architecture design, optimizing the compatibility of software components with multiple architectures, and solving the technical problems of low efficiency, non-standardized classification, and lack of practical guidance in existing multi-architecture instruction analysis, thereby enhancing the practicality and reliability of multi-architecture instruction analysis.

[0062] Example 2 Figure 2 This is a flowchart of another multi-architecture instruction analysis method provided in Embodiment 2 of the present invention. This embodiment is a refinement of the above embodiment's "parallel disassembly of multiple target output files using a low-level virtual machine disassembler to obtain disassembled text files corresponding to multiple target architectures." Figure 2 As shown, the method includes: S210. Obtain the multi-architecture binary file generated by the compiler.

[0063] S220. Traverse the segment table in the multi-architecture binary file, extract the executable object file format segment corresponding to at least one processor as the output file, name the output file according to the architecture identifier of the executable object file format segment, and save it to the target storage directory.

[0064] S230. Read multiple target output files from the target storage directory, obtain the matching disassembly parameter set according to the target architecture identifier in the target output file name, create a thread pool matching the number of central processing unit cores, submit the disassembly task of each target output file as an independent work unit to the thread pool, and allocate each work thread through the thread pool to call the underlying virtual machine disassembly tool to independently perform the disassembly operation.

[0065] In this embodiment of the invention, the number of central processing unit cores can be specifically understood as the number of physical cores of a central processing unit (CPU), which determines the maximum efficiency of parallel processing. A worker thread can be specifically understood as an execution unit in the thread pool used to execute specific disassembly tasks. An independent worker unit can be specifically understood as: the disassembly task of each ELF file is independent of each other, without dependency or conflict.

[0066] S240. The disassembly results are written to the corresponding text files by each working thread to obtain disassembly text files corresponding to various target architectures.

[0067] Specifically, multiple target output files are read from the target storage directory, and the matching disassembly parameter set is obtained based on the target architecture identifier in the target output file name.

[0068] A thread pool parallel execution strategy is adopted, creating a thread pool with the number of worker threads equal to the number of CPU cores. Each disassembly task for an ELF format target output file is encapsulated as an independent work unit and submitted to the thread pool. The thread pool centrally schedules and allocates worker threads. Each worker thread independently calls the underlying virtual machine disassembly tool to complete the disassembly operation of its corresponding file and writes the result to the corresponding output file, resulting in a disassembled text file adapted to multiple target architectures. Since there are no data dependencies or execution conflicts between the disassembly tasks, a near-linear processing speedup can be achieved. Understandably, dynamic thread allocation and task priority scheduling can be used to further improve parallel processing efficiency and resource utilization.

[0069] S250. Scan each disassembled text file line by line, perform operations to identify instruction prefixes and extract opcodes, and concatenate the prefix and opcode for opcodes containing conditional execution prefixes. Count the occurrence of each opcode using a hash table to obtain the opcode count mapping table corresponding to each disassembled text file.

[0070] S260. Perform hierarchical classification of the opcodes in the opcode count mapping table, and map the opcodes to the instruction categories specified in the instruction set architecture to obtain the instruction classification results.

[0071] Furthermore, based on the above embodiments, before hierarchically classifying the opcodes in the opcode count mapping table, the following may also be included: The process involves: acquiring the assembly source file generated by the compiler; performing multi-process parallel parsing on the assembly source file: filtering compiler or assembler pseudo-instructions in the file using a pre-stored pseudo-instruction whitelist; tracing and filtering processor kernel function metadata blocks in the file using a state machine; for the filtered file content, matching the indentation identifier at the beginning of each line using regular expressions and concatenating subsequent instruction fragments separated by preset identifiers to form complete instruction names; filtering label lines and comment lines in the file; identifying instruction prefixes in instruction names and extracting the corresponding opcodes; concatenating the prefix and opcode for opcodes containing conditional execution prefixes; and counting the occurrences of each opcode using a hash table. After ensuring that each process independently completes the parsing and statistics of its corresponding assembly source file, the main process merges all statistical results according to the architecture dimension to obtain the opcode count mapping table corresponding to each assembly source file.

[0072] In this embodiment of the invention, the assembly source file can be specifically understood as: a text-format assembly code file generated by the compiler, which is readable text, not a binary file, such as a .s file.

[0073] Pseudo-instructions can be understood as auxiliary instructions used by the compiler or assembler, not actual machine instructions executable by the processor. A pseudo-instruction whitelist can be understood as a predefined set of pseudo-instructions that need to be filtered. A state machine can be understood as a logical control unit used to track, identify, and filter the start and end boundaries of kernel function metadata blocks. A processor kernel function metadata block can be understood as an information block in the assembly file that describes the attributes of the kernel function, but does not contain actual instructions.

[0074] The indentation identifier at the beginning of a line can be understood as an identifier at the start of the instruction line, used to locate valid instructions. The default identifier can be understood as a symbol in the instruction name used to separate functions, data types, and registers. The tag line can be understood as a marker line used for jump location in assembly language, not an instruction. The comment line can be understood as explanatory text, not an instruction, such as text starting with #.

[0075] Specifically, before performing the hierarchical classification of opcodes, a new processing flow for the assembly source files generated by the compiler is added. These files are text files and can be parsed using a multi-process parallel pool. The parsing of each file is executed as an independent process task to overcome the performance limitations of CPU-intensive tasks.

[0076] The compiler obtains the assembly source file generated by the compiler and parses it in a multi-process parallel manner. It filters pseudo-instructions by using a preset whitelist, such as filtering .file (file identifier pseudo-instruction, used to mark the source file name), .text (code segment pseudo-instruction, used to mark the start of the code segment), .section (segment definition pseudo-instruction, used to define custom segments), .globl (global symbol pseudo-instruction, used to declare global symbols), .p2align (alignment pseudo-instruction by powers of 2, used for instruction or data address alignment), etc.

[0077] A state machine is used to identify and filter processor kernel function metadata blocks, such as .gcu_kernel_code_t (identifier of the general computing unit kernel function code segment) and .gcu_kernel_metadata (identifier of the general computing unit kernel function metadata segment). Key-value pairs within the block (such as wavefront_size (size of the wavefront thread group) and vgpr_count (number of vector general-purpose registers)) are not instructions. The state machine is used to track the start and end positions of the block, and all lines within the block are skipped.

[0078] Instructions in an assembly source file may span multiple tokens (lexical units or tags) separated by preset identifiers (such as "."), such as mop.add.f32.vgpr4 (matrix operation, single-precision floating-point addition, vector four-register instruction), where mop (Matrix Operation) is matrix operation, add is addition, f32 is a 32-bit (single-precision) floating-point number, and vgpr4 represents four vector general-purpose registers.

[0079] Therefore, by matching the indentation identifier at the beginning of a line using regular expressions and concatenating subsequent instruction fragments that begin with a preset identifier (such as ".") to form a complete instruction name, it can also be uniformly converted to lowercase format, thus realizing instruction name extraction and concatenation.

[0080] Filter tag lines and comment lines, such as filtering tag lines ending with a colon (e.g., BB0_1:) and comment lines starting with #. Identify instruction prefixes and extract opcodes. Perform concatenation and integration on opcodes containing conditional execution prefixes. Use a hash table to count the occurrences of each opcode. After each process completes parsing, the main process merges the statistical results according to the architecture dimension to obtain the opcode count mapping table corresponding to the assembly source file.

[0081] This invention provides two sources for constructing mapping tables: one from disassembling binary files and the other from parsing assembly source files. This allows for flexible adaptation to compiler intermediate product analysis scenarios. In addition to a fixed multi-process parallel strategy, the number of processes can be dynamically adjusted based on file size to further improve parsing efficiency.

[0082] By employing multi-process parallel parsing of the assembly source files generated by the compiler, text processing efficiency is improved, avoiding single-process performance bottlenecks. Using pseudo-instruction whitelists and state machines to filter kernel function metadata blocks eliminates invalid information, ensuring the accuracy of instruction extraction. Regular expression matching is used to concatenate scattered instruction fragments, enabling complete reconstruction of the actual opcodes. Combined with label and comment filtering, statistical purity is further improved. Concatenating opcodes with conditional execution prefixes ensures the uniqueness of instruction identifiers. A hash table is used to count the number of occurrences, and the main process merges the results according to the architecture dimension. This achieves parallel statistics across multiple source files and forms a structured, clearly defined opcode count mapping table, providing a reliable data foundation for subsequent instruction classification and coverage analysis.

[0083] Optionally, based on the above embodiments, the opcodes in the opcode count mapping table are hierarchically classified, and the opcodes are mapped to instruction categories in the instruction set architecture specification to obtain instruction classification results. This can include: The opcodes in the opcode count mapping table are hierarchically classified using a preset priority strategy to determine the instruction category corresponding to each opcode. The preset priority strategy includes: a rule engine reduction strategy, a data type suffix stripping strategy, and an instruction set architecture definition reflection strategy. Based on the instruction category corresponding to the opcode, the opcode is mapped to the instruction category in the instruction set architecture specification to obtain the instruction classification result that matches the instruction set architecture manual.

[0084] In this embodiment of the invention, the preset priority strategy can be specifically understood as: a variety of pre-configured instruction classification rules used to achieve standardized classification of opcodes.

[0085] The rule engine reduction strategy can be understood as a strategy that performs pattern matching and category reduction on opcodes based on preset matching rules. The data type suffix stripping strategy can be understood as a strategy that classifies instructions by removing data type, register, and other suffixes from the opcode. The instruction set architecture definition reflection strategy can be understood as a strategy that automatically parses and maps instruction categories based on the native definition of the instruction set architecture.

[0086] Specifically, because there are many variant forms of assembly-level opcodes, directly counting at the opcode granularity will result in overly fragmented results that cannot be aligned with the standard instruction categories defined in the ISA specification manual.

[0087] In the process of hierarchically classifying opcodes in the opcode count mapping table to instruction categories defined by the instruction set architecture, any of the following strategies can be used to perform hierarchical classification: rule engine reduction strategy, data type suffix stripping strategy, or instruction set architecture (ISA) defined reflection strategy. Each strategy is independent of the others and can be selected to take effect.

[0088] Optionally, the ISA-defined reflection strategy takes precedence over the rule engine reduction strategy and the data type suffix stripping strategy. The rule engine reduction strategy or data type suffix stripping strategy will only be used for supplementary classification when the ISA-defined reflection strategy cannot determine the instruction category corresponding to the opcode. Because this strategy directly parses instruction categories based on the native ISA specification, it can more accurately and consistently reflect the official architecture definition, avoiding classification biases that may arise from manually configured rules or suffix stripping logic. When used in conjunction with other strategies, it is prioritized to ensure that the instruction classification results strictly align with the architecture manual, enhancing the authority and accuracy of the classification results.

[0089] The opcodes in the table are hierarchically categorized. Pre-defined strategies, such as rule engine reduction, data type suffix stripping, or instruction set architecture definition reflection, are used to classify the opcodes level by level to determine the instruction category corresponding to each opcode. For example, a pre-defined instruction matching rule base is used to perform pattern matching and rule determination on the opcodes, and the opcodes are grouped into their corresponding instruction categories according to a pre-defined classification logic. Alternatively, suffix information representing data type, bit width, register, etc., at the end of the opcode is removed, while retaining the core operator semantics, thus grouping instructions with similar functions into the same instruction category. Another approach is to read the official definition file of the instruction set architecture, automatically parse the correspondence between opcodes and standard instruction categories, complete the instruction classification mapping, and determine the instruction category corresponding to each opcode.

[0090] After determining the instruction category corresponding to the opcode, the opcode is mapped to the standard instruction category defined by the instruction set architecture specification based on the correspondence between the opcode and the instruction category in the instruction set architecture specification, thus obtaining the instruction classification result that matches the instruction set architecture manual.

[0091] For example, a two-level mapping is achieved based on the ISA specification instruction mapping table, which is maintained independently for each instruction architecture. This mapping table can be configured according to the ISA reference manual or automatically generated by the reflection strategy defined by the instruction set architecture. The mapping relationship supports a multi-target format where a single assembly class corresponds to multiple ISA specification instructions. For example, scalar addition instructions such as adda (address addition instruction, used for address calculation addition operation), addc (address addition instruction with carry, including carry flag addition operation), addf (floating-point addition instruction, used to perform floating-point addition operation), and addt (address addition instruction with truncation or saturation, used for addition operation with special processing logic) can be mapped. Let `mop.madd` (a matrix multiplication and accumulation instruction, belonging to the multiplication and addition operation of the matrix operation unit) and other matrix addition instructions be uniformly reduced to the standard addition instruction `add`. Let `beq` (jump instruction if equal, executes program jump when comparison result is equal), `bne` (jump instruction if not equal, executes program jump when comparison result is not equal), `bge` (jump instruction if greater than or equal to, executes program jump when greater than or equal to), `blt` (jump instruction if less than, executes program jump when less than) and other conditional branch instructions be classified as signed branch `b.signed` or unsigned branch `b.unsigned` instructions, thus achieving unified classification of conditional branches.

[0092] Understandably, the mapping values ​​in the mapping table support a multi-target format separated by slashes (such as b.signed / b.unsigned), enabling a single assembly instruction category to simultaneously correspond to multiple standard instructions in the instruction set architecture specification. For example, conditional branch instructions that are uniformly classified can be mapped to both signed and unsigned branch instructions. For hardware architectures that adopt reflection strategies defined by the instruction set architecture, the system can directly and automatically generate a complete mapping table based on the native architecture definition, without the need for manual writing, modification, and maintenance.

[0093] Furthermore, flexible reduction of opcodes can be achieved by extending regular expression matching rules and dynamic instruction feature libraries. Relying on this multi-strategy hierarchical reduction mechanism, a massive number of differentiated fine-grained opcodes can be reduced to a number of standardized instruction categories that are streamlined and aligned with the instruction set architecture manual, thereby obtaining standardized instruction classification results.

[0094] By setting up a first-level mapping to perform multi-strategy hierarchical initial classification of the original opcodes, and relying on the second-level mapping to further map the initial classification results to instruction categories in the instruction set architecture specification, it is possible to complete the reduction of massive fine-grained opcodes while ensuring that the classification results conform to the ISA manual standard, thereby improving the processing efficiency and adaptability of instruction classification, and enhancing the standardization and consistency of the classification results.

[0095] Optionally, based on the above embodiments, when the preset priority strategy is a rule engine reduction strategy, the opcodes in the opcode count mapping table are hierarchically classified according to the preset priority strategy to determine the instruction category corresponding to the opcode. This may include: The pre-defined classification function is called to classify the opcodes, split the opcodes by whitespace characters and remove the condition prefix, and take the last identifier segment to split it into the first component array by the first delimiter; The following classification rules are executed sequentially until the instruction category corresponding to the opcode is determined: When the number of elements in the first component array is less than two, the opcode is classified into a separate instruction category; when the first element of the first component array is a prefix for matrix operation, memory loading, or memory storage instructions, the first element of the first component array is used as the instruction category corresponding to the opcode; when the first element of the first component array is a prefix for matrix multiplication and addition instructions, the first and second elements of the first component array are concatenated to form the instruction category corresponding to the opcode; when the second element of the first component array is a preset vector loading or vector storage identifier, the instruction category corresponding to the opcode is generated based on the second element of the first component array; when the third element of the first component array is an expansion... When displaying the identifier, the second element of the first component array is concatenated with the extended identifier to form the instruction category corresponding to the opcode; when the second element of the first component array is a no-op identifier, the first element of the first component array is concatenated with the no-op identifier to form the instruction category corresponding to the opcode; when the second element of the first component array is a composite instruction family identifier, the second and third elements of the first component array are concatenated to form the instruction category corresponding to the opcode; when the first element of the first component array is a basic slot identifier, the second element of the first component array is used as the instruction category corresponding to the opcode; when all rules do not match, the opcode itself is classified as the corresponding instruction category.

[0096] In this embodiment of the invention, the classification function can be specifically understood as a dedicated processing function used for opcode splitting, judgment, and reduction. The condition prefix can be specifically understood as the conditional execution identifier of the instruction (e.g., if (lpr)), which needs to be removed before classification to ensure the accuracy of rule matching. The first component array can be specifically understood as the element sequence formed after splitting the opcode according to the first delimiter, used for bit-by-bit matching of classification rules. The basic slot identifier can be specifically understood as the instruction execution unit prefix, such as l, s, c, m, v, etc. The extension identifier can be specifically understood as identifiers such as ext that represent the extended functions of the instruction. The first delimiter can be specifically understood as the delimiter used to split the components of the instruction when the preset priority strategy is the rule engine reduction strategy.

[0097] Specifically, when using the rule engine reduction strategy, the preset classification function classify_single_instr is called to process the opcode. First, the opcode is split by whitespace and the conditional execution prefix is ​​removed. The last identifier segment (token) is taken and split into the first part array parts[] according to the first delimiter (such as ".").

[0098] Then, the classification rules are executed sequentially from highest to lowest priority: If the number of components in the first component array is less than two, the opcode is classified as the opcode itself as a separate instruction category. For example, the instruction eret (an exception return instruction used to return to the main program from an exception or interrupt handling flow) corresponds to the category eret.

[0099] If the first element of the first component array, parts[0], is a prefix of gemm (matrix operation), mld (memory loading), or mst (memory storage), then the first element of the first component array is used as the instruction category corresponding to the opcode, that is, the prefix is ​​used as the category.

[0100] If the first element of the first component array, parts[0], is a matrix multiplication and addition prefix of the mli (matrix multiplication and addition) class, then the first and second elements are concatenated to form the category. For example, the instruction mli.vldxoa (matrix index loading instruction, used to read matrix data by index) corresponds to the category mli.vldxoa.

[0101] If the second element of the first component array, parts [1], is a class identifier for tvldoa (vector loading) or tvstoa (vector storage), then the instruction category corresponding to the opcode is generated based on the second element of the first component array. For example, the instruction category corresponding to the opcode is generated by concatenating the elements hierarchically. For example, the instruction v.tvldoa (vector cache loading instruction, used for batch reading of vector data) corresponds to the category tvldoa; the instruction v.tvstoa (vector cache storage instruction, used for batch writing of vector data) corresponds to the category tvstoa.

[0102] If the third element of the first component array, parts[2], is an extended identifier (such as ext), then the second element of the first component array, parts[1], is concatenated with the extended identifier to form the category. For example, the instruction s.movsr2spr.ext (extened status register transfer instruction, used for data transfer between special registers) corresponds to the category movsr2spr.ext.

[0103] If the second element of the first component array, parts[1], is a no-op identifier, then the first element is concatenated with the no-op identifier to form the category. For example, the instruction l.nop (scalar slot no-op instruction, which only occupies the pipeline without performing operations) corresponds to the category l.nop; the instruction v.nop (vector slot no-op instruction) corresponds to the category v.nop.

[0104] If the second element of the first component array, parts [1], is a composite instruction family identifier, such as mop (matrix operation instruction), amo (atomic memory operation instruction), bc (branch control instruction), redv (vector reduction instruction), etc., then the second and third elements are concatenated as the category. For example, the instruction v.mop.add (matrix operation addition instruction, performs matrix addition) corresponds to the category mop.add; the instruction s.amo.add (atomic memory addition instruction, performs memory accumulation safely under multi-core synchronization) corresponds to the category amo.add; the instruction s.bc.eq (equality branch control instruction, jumps when the condition is met) corresponds to the category bc.eq; the instruction v.redv.sum (vector reduction summation instruction, accumulates a group of vector data into a single value) corresponds to the category redv.sum.

[0105] If the first element of the first component array, parts[0], is a basic slot identifier, then the second element of the first component array, parts[1], is taken as the category. For example, the category corresponding to the instruction l.add (scalar addition instruction) is add; the category corresponding to the instruction v.mul (vector multiplication instruction) is mul; and the category corresponding to the instruction s.ld (scalar loading instruction) is ld.

[0106] If none of the rules match, it is categorized as the opcode itself. For example, the directive custom.trap (a custom trap directive used to trigger custom exceptions or debug events) corresponds to the category custom.trap.

[0107] Ultimately, fine-grained opcodes are reduced to a unified instruction category, thus solving the problem of statistical fragmentation.

[0108] When using a rule engine reduction strategy to hierarchically classify opcodes, a preset classification function is invoked to first split the opcodes by whitespace, remove conditional prefixes, and split the component arrays. Then, various classification rules are executed sequentially according to a preset order. This achieves accurate classification for opcodes with different structures and functions (such as those containing matrix operation prefixes, composite instruction family identifiers, and basic slot identifiers). Opcodes that cannot match the rules retain their own categories. This approach not only solves the problem of statistical fragmentation caused by the numerous and varied forms of assembly-level opcodes, reducing fine-grained opcodes to a unified instruction category, but also avoids classification bias through standardized splitting and rule matching, ensuring the accuracy and consistency of instruction classification. At the same time, the preset classification rules can adapt to different types of opcodes, improving the versatility and adaptability of the classification strategy. This lays the foundation for subsequent opcode mapping to ISA-standard instruction categories and for aligning statistical results with the ISA manual, thus improving the efficiency and reliability of the entire instruction statistics and coverage analysis.

[0109] Optionally, based on the above embodiments, when the preset priority strategy is a data type suffix stripping strategy, the opcodes in the opcode count mapping table are hierarchically classified according to the preset priority strategy to determine the instruction category corresponding to the opcode. This may include: The opcode is divided into a second component array by the second delimiter. Each component is scanned sequentially from the end to the beginning of the second component array, determining whether it belongs to a preset strippable suffix category. The preset strippable suffix categories include data type suffixes, symbol type suffixes, modifier suffixes, register specification suffixes, and type conversion suffixes. If a scanned component belongs to a preset strippable suffix category, a stripping operation is performed on that component, and the scanning continues with the previous component. If a scanned component does not belong to the preset strippable suffix category, the scanning stops. The remaining components after the scanning stops are reassembled according to the second delimiter to obtain the core part of the opcode after suffix stripping. This core part of the opcode is used as the instruction category corresponding to the opcode.

[0110] In this embodiment of the invention, the second delimiter can be specifically understood as: a delimiter used to split the components of an instruction when the preset priority strategy is a data type suffix stripping strategy. The first and second delimiters are only used to distinguish different delimiters and have no order of precedence. The second component array can be specifically understood as: an ordered sequence of components formed after splitting the opcode according to the second delimiter. Again, the first and second delimiters are only used to distinguish different delimiters and have no order of precedence.

[0111] The predefined strippable suffix category can be understood as: predefined suffix types that are unrelated to the core instruction operation, which can include data types, symbol types, modifiers, register specifications, type conversion suffixes, etc. The opcode core part can be understood as: the combination of components that represent the essential function of the instruction after stripping away irrelevant suffixes.

[0112] Specifically, for architecture instructions such as GCU5.0 that adopt the "operation.data type.register specification" naming format, such as mop.add.f32.vgpr4, a data type suffix stripping strategy can be used to reduce instruction semantics.

[0113] When using the data type suffix stripping strategy, the opcode is first split into a second component array according to the second delimiter (such as "."). Each component is then scanned sequentially from the end of the array to the beginning to determine whether the current component belongs to any of the strippable categories: data type suffix, symbol type suffix, modifier suffix, register specification suffix, or type conversion suffix.

[0114] The data type suffixes can include: s8 (eight-bit signed number), s16 (sixteen-bit signed number), s32 (thirty-two-bit signed number), s64 (sixty-four-bit signed number), u8 (eight-bit unsigned number), u16 (sixteen-bit unsigned number), u32 (thirty-two-bit unsigned number), u64 (sixty-four-bit unsigned number), bf16 (sixteen-bit floating-point number), f16 (sixteen-bit floating-point number), f32 (thirty-two-bit floating-point number), f64 (sixty-four-bit floating-point number), f4e2m1 (four-bit binary exponent-mantissa floating-point number), f6e2m3 (six-bit binary exponent-triple floating-point number), f8e4m3 (eight-bit quadruple exponent-triple floating-point number). The following are some of the most common types of floating-point numbers: f8e5m2 (8-bit 5-exponential 2-mantissa floating-point number), v2bf16 (dual-channel 16-bit floating-point number), v2f16 (dual-channel 16-bit floating-point number), v2s16 (dual-channel 16-bit signed number), v2u16 (dual-channel 16-bit unsigned number), v4s8 (quad-channel 8-bit signed number), v4u8 (quad-channel 8-bit unsigned number), bf16mix (mixed-precision 16-bit floating-point number), f16mix (mixed-precision 16-bit floating-point number), f32mix (mixed-precision 32-bit floating-point number), i32mix (mixed-precision 32-bit integer number), b (byte), h (half-word), w (word), dw (double word), etc.

[0115] Symbol type suffixes can include: s (signed) and u (unsigned), etc.

[0116] Modifier suffixes can include: legacy (traditional mode), vm (vector mask), single (single channel), sext (symbol extension), etc.

[0117] Register specification suffixes can include: matching the vgprN mode suffix as a vector general-purpose register channel specification identifier (e.g., vgpr4 indicates a four-way vector general-purpose register, vgpr8 indicates an eight-way vector general-purpose register), etc.

[0118] Type conversion suffixes can include: suffixes starting with cvt_to_ indicating the target type of the data type conversion, etc.

[0119] If the component is found to be a valid component, the scan continues forward. If it is not a valid component, the scan is terminated. The remaining components after the scan stops are reassembled according to the second separator. The core part of the resulting opcode is used as the instruction category corresponding to the opcode. This reduces instructions with complex suffixes, such as mop.add.f32.vgpr4 and mop.mul.bf16mix (matrix multiplication instructions executed by the matrix operation unit using mixed BF16 floating-point precision), to core instructions such as mop.add and mop.mul (matrix multiplication instructions). This eliminates the formal differences between similar instructions due to different data types and register configurations, and achieves the standardized reduction of fine-grained instructions to core operation categories.

[0120] By employing a data type suffix stripping strategy to hierarchically classify opcodes, the opcodes are first split into component arrays by delimiters, and then various non-core suffixes are stripped away by scanning from back to front. This removes additional information that only represents data type, symbol format, modifier attributes, register specifications, and type conversion, while retaining the core operational semantics of the instruction. As a result, multiple fine-grained opcodes with the same function but different configurations can be reduced to a unified instruction category. This not only reduces the number and fragmentation of instruction classifications but also makes the classification results more closely match the essential functions of the instructions, improving the simplicity, standardization, and universality of instruction statistics and classification. At the same time, it makes subsequent instruction mapping easier to align with ISA-standard instruction categories, enhancing the adaptability and accuracy of the entire classification process.

[0121] Optionally, based on the above embodiments, when defining a reflection strategy for the instruction set architecture using a preset priority strategy, the opcodes in the opcode count mapping table are hierarchically classified according to the preset priority strategy to determine the instruction category corresponding to the opcode. This may include: The system invokes a preset compilation tool to process the instruction set architecture definition source file in a specified mode, generating a record file containing complete metadata for all instructions. The record file is then segmented according to preset code block boundaries. From each segmented code block, the instruction assembly name, version predicate list, pseudo-instruction identifier, and namespace field are extracted. Records containing the target instruction set architecture version identifier in the version predicate list and whose pseudo-instruction identifier is not a pseudo-instruction are filtered out. Different variants of instructions with the same name are merged to obtain standardized instruction set data. For each instruction name in the standardized instruction set data, a data type suffix stripping strategy is used for hierarchical classification to generate the instruction category corresponding to each instruction.

[0122] In this embodiment of the invention, the compilation tool can be specifically understood as a dedicated tool for parsing architecture definition files, such as LLVM TableGen (Low Level Virtual Machine Table Generator). The instruction set architecture definition source file can be specifically understood as the source code file in the compiler used to describe the instruction set specification. The version predicate list can be specifically understood as a field identifying the architecture versions supported by the instructions. The pseudo-instruction identifier can be specifically understood as a field marking whether an instruction is a pseudo-instruction without actual machine code. The namespace can be specifically understood as a space that distinguishes the instruction to which different hardware targets belong. The standardized instruction set data can be specifically understood as a concise and unified set of instructions obtained after filtering and merging.

[0123] Specifically, when using an instruction set architecture to define a reflection strategy, there is no need to rely on manually maintained static instruction configuration files. The complete instruction set and its metadata are automatically extracted from the compiler's ISA definition source file (LLVM TableGen .td file, where td represents table definition file), thus achieving automatic synchronization between instruction set definition and analysis tools.

[0124] The pre-defined compiler is invoked to parse the instruction set architecture definition source file in a specified mode, generating a record file containing all instruction metadata. For example, instruction set information can be automatically extracted from the TableGen compiler architecture definition source code to synchronize the definition with the tool. The llvm-tblgen tool is invoked to process ISA definition files in .td format (such as GCU.td, EFGCU.td) in -print-records mode to generate a record file containing complete metadata for all instructions (such as an .inc metadata record file).

[0125] Understandably, it is possible to process the definitions of multiple targets (such as DTU and EFGCU) simultaneously, generating their respective .inc files.

[0126] The record file is segmented according to the preset code block boundaries. The instruction assembly name, version predicate list, pseudo-instruction identifier and key fields of the namespace are extracted from it. Valid records that are not pseudo-instructions for the target architecture version are filtered out. Different variants of instructions with the same name are merged to form standardized instruction set data. Then, the instruction names in the standardized instruction set are classified hierarchically using a data type suffix stripping strategy. Finally, the instruction category corresponding to each instruction is generated.

[0127] For example, the file is split according to the boundaries of the defined code block (such as the def{} code block) and the following data is extracted: AsmString assembly name (the assembly string representation of the instruction, taking the token before the first whitespace character as the instruction name), Predicates version predicates (the ISA version predicate list of the instruction (such as ISA50, ISAStd, ISA40OR50), used to determine the ISA version to which the instruction belongs), isPseudo pseudo-instruction flag (used to indicate whether it is a pseudo-instruction; pseudo-instructions do not correspond to real machine code and need to be filtered), and Namespace namespace field (the namespace to which the instruction belongs, such as DTU, EFGCU).

[0128] Valid records that are not pseudo-instructions and are retained according to the target ISA version are filtered out and merged with variants of the same-name instruction. That is, valid records that contain the target ISA version identifier in the Predicates list and arePseudo is 0 (not pseudo-instruction) are filtered out and retained. Different variants of the same-name instruction (from different targets or different encoding forms) are merged by taking the union of their namespaces and predicate sets.

[0129] The final instruction name is automatically generated by applying a data type suffix stripping algorithm. For example, the instruction category of mop.add.f32 is mop.add. This allows for adding or modifying instructions without manually updating the configuration file. It also supports parallel processing of multi-target architectures. Furthermore, it can improve reflection capabilities and compatibility by extending compiler tool parameters, customizing parsing rules, and adding instruction feature fields, ensuring that instruction classification is consistent with the compiler architecture definition.

[0130] By employing a hierarchical classification strategy based on instruction set architecture definition reflection, and by directly calling compiler tools to parse the architecture definition source file and extract instruction metadata, the system can automatically obtain a real and complete instruction set. This avoids omissions, errors, and delays caused by manually maintaining instruction lists. Standardized instruction data can be obtained through version filtering, pseudo-instruction filtering, and merging of variants with the same name. Combined with a suffix stripping strategy, the system achieves classification, ensuring that the instruction classification results are consistent with the compiler instruction definitions. This improves the accuracy of instruction classification, allows for automatic synchronization of changes during instruction set updates and iterations, reduces maintenance costs, and enhances the adaptability, scalability, and long-term stability of the entire classification system.

[0131] S270. Based on the opcode count mapping table and instruction classification results, generate a multi-dimensional statistical report and combine it with historical analysis results to generate an instruction coverage change report. Based on the instruction coverage change report, locate the instruction usage degradation items and new coverage items in the compiler iteration, and guide the compiler optimization, instruction set architecture iteration or software component instruction adaptation adjustment.

[0132] The technical solution of this invention obtains multi-architecture binary files generated by the compiler and extracts the executable target file format segment corresponding to the processor. These segments are then named and stored according to the architecture identifier specification. The disassembly parameter set is matched based on the architecture identifier in the target output file name. A thread pool matching the number of CPU cores is created, and each target output file's disassembly task is submitted to the thread pool as an independent work unit. This achieves even distribution of disassembly tasks, fully utilizing the CPU's multi-core computing resources and avoiding core resource idleness caused by single-threaded processing. Each worker thread in the thread pool independently executes disassembly operations by calling the underlying virtual machine disassembly tool. These worker threads operate independently and in parallel, reducing the total disassembly time for multiple target output files and improving disassembly efficiency. Each worker thread writes the disassembly results to a corresponding text file, ensuring that disassembly text files corresponding to different target architectures are stored independently and without confusion. This guarantees the integrity and accuracy of the disassembly results, providing a well-organized and clear data foundation for subsequent line-by-line scanning, opcode extraction, and other analysis steps. This solves the problems of low efficiency, insufficient resource utilization, and chaotic result storage in existing multi-architecture disassembly methods. By scanning and disassembling text files line by line, identifying instruction prefixes, extracting opcodes, and concatenating them, and combining this with a hash table to count the occurrences of opcodes, the usage of instructions for each architecture can be obtained. By hierarchically classifying opcodes and mapping them to instruction categories in the instruction set architecture specification, standardized instruction classification can be achieved. By combining the opcode count mapping table with the instruction classification results to generate multi-dimensional statistical reports, and combining historical analysis results to generate instruction coverage change reports, the practicality and reliability of multi-architecture instruction analysis can be improved.

[0133] Example 3 Figure 3 This is a flowchart of another multi-architecture instruction analysis method provided in Embodiment 3 of the present invention. This embodiment is a refinement of the step in the above embodiment of "generating a multi-dimensional statistical report based on the opcode count mapping table and instruction classification results". Figure 3 As shown, the method includes: S310. Obtain the multi-architecture binary file generated by the compiler.

[0134] S320. Traverse the segment table in the multi-architecture binary file, extract the executable object file format segment corresponding to at least one processor as the output file, name the output file according to the architecture identifier of the executable object file format segment, and save it to the target storage directory.

[0135] S330. Read multiple target output files from the target storage directory, obtain the matching disassembly parameter set according to the target architecture identifier in the target output file name, and perform parallel disassembly on multiple target output files through the underlying virtual machine disassembly tool to obtain disassembly text files corresponding to multiple target architectures.

[0136] S340. Scan each disassembled text file line by line, perform the operations of identifying instruction prefixes and extracting opcodes, and concatenate the prefix and opcode for opcodes containing conditional execution prefixes. Count the occurrence of each opcode using a hash table to obtain the opcode count mapping table corresponding to each disassembled text file.

[0137] S350. Perform hierarchical classification of the opcodes in the opcode count mapping table, and map the opcodes to the instruction categories specified in the instruction set architecture to obtain the instruction classification results.

[0138] S360, based on the opcode count mapping table and instruction classification results, performs multi-dimensional statistics at the instruction level, category level, component level, architecture level, and instruction set architecture version level. Based on the statistical results, it generates spreadsheet files, comma-separated value files, and interactive reports in Hypertext Markup Language as multi-dimensional statistical reports. Combined with historical analysis results, it generates an instruction coverage change report. Based on the instruction coverage change report, it can locate instruction usage degradation items and new coverage items in compiler iterations, and guide compiler optimization, instruction set architecture iteration, or software component instruction adaptation adjustments.

[0139] In this embodiment of the invention, instruction-level statistics can be understood as: statistics are performed on a per-operation-code basis (including variants and conditional instructions). Category-level statistics can be understood as: statistics are performed on a per-reduced instruction category basis. Component-level statistics can be understood as: statistics on instruction usage are performed on a per-software-component basis, such as dynamic libraries and modules. Architecture-level statistics can be understood as: global summary statistics are performed on a per-hardware-architecture basis.

[0140] Specifically, during the statistical report generation phase, based on the obtained opcode count mapping table and instruction classification results, the statistics are summarized from multiple dimensions, including instruction level, category level, component level, architecture level, and instruction set architecture version level. The results are then output in Excel (spreadsheet), CSV (Comma-Separated Values) files, and HTML (HyperText Markup Language) interactive reports to adapt to different usage scenarios.

[0141] The Excel workbook contains five worksheets: fine-grained distribution of instructions and components, summary of categories and components, summary by category, summary by component, and list of unused instructions. It can comprehensively display the overall picture of instruction usage, ISA utilization, and distribution of dead instructions.

[0142] The instruction / component fine-grained distribution worksheet lists rows for each individual opcode (including variants and conditional prefixes), columns for each software component (dynamic library), and cell values ​​for the number of times the opcode appears in that component. Additional "Category" and "Total Quantity" columns are also included. This table provides a comprehensive overview of instruction usage at the finest granularity.

[0143] In the Category × Component Summary worksheet, the instruction categories after the first level of reduction are listed as each software component, and the cell value is the sum of the number of times all opcodes under that category are used in that component. For new generation architectures, an additional label such as "New in X.0" (where X is the version number) is added to indicate whether the category is a new instruction added in that generation.

[0144] The summary worksheet by category displays each row as an instruction category, containing the corresponding ISA specification instruction name, total usage count, and a list of all assembly opcodes within that category. This table is used to quickly locate the actual usage of a specific ISA instruction.

[0145] In the component summary worksheet, each row represents a software component, showing the number of instruction types used, the number of unused instruction types, the total number of instructions, the usage rate, and the unused rate. This table is used to evaluate the ISA utilization of each component.

[0146] The Unused Instructions List worksheet lists all instructions that are used zero times across all components, along with their corresponding ISA specification instruction names. This table directly reflects dead instructions in the ISA that were not generated by the compiler.

[0147] The CSV format outputs a structured list of unused instructions and a complete list of instructions, which is convenient for automation tools to process. At the same time, the report fields can be expanded or visualization charts can be added as needed to achieve a complete analysis from fine-grained opcodes to macro-architecture utilization, providing data support for compiler optimization, instruction set trimming and architecture iteration.

[0148] The unused instruction list outputs the mapping relationships of all unused instructions in the format "SPEC Instruction, ASM Name". SPEC Instruction is the standard instruction name, and ASM Name is the assembly instruction name.

[0149] The complete instruction list includes four fields: instruction name, namespace, ISA version, and instruction category, which facilitates use by downstream automation tools.

[0150] Based on historical analysis results, an instruction coverage change report is generated. This report helps identify instruction usage degradation and new coverage items in compiler iterations, guiding compiler optimization, instruction set architecture iteration, or instruction adaptation adjustments for software components.

[0151] Optionally, based on the above embodiments, an interactive Hypertext Markup Language report is generated, including: The statistical results obtained from multi-dimensional statistics are serialized into script object format data, which is then injected into a predefined report template and rendered as a single-file hypertext markup language page. The single-file hypertext markup language page is then parsed in a browser to dynamically draw instruction coverage statistical charts and display instruction set architecture version-level statistical data, and provide search, filtering, and drill-down functions for the statistical content.

[0152] In this embodiment of the invention, the script object format data can be specifically understood as JSON (JavaScript Object Notation), a format used for storing and transmitting statistical data. The report template can be specifically understood as an HTML template file with built-in styles, charts, and interactive logic.

[0153] Specifically, when generating interactive Hypertext Markup Language reports, an architecture of JSON data injection plus a template engine is used, which can be opened and used directly in the browser without the need for backend server support.

[0154] First, serialize the results obtained from multi-dimensional statistics into script object format data, such as serializing information like file paths, instruction data matrices, ISA version sets, statistical summaries, and timestamps into JSON objects.

[0155] The data is injected into a predefined report template, which is then rendered into a standalone single-file Hypertext Markup Language page. For example, it can be injected into a predefined HTML template placeholder containing embedded CSS (Cascading Style Sheets) and JavaScript logic to generate a fully self-contained single-file report.

[0156] This page can be directly parsed and run in a browser, dynamically drawing instruction coverage statistics charts, displaying statistical data at the instruction set architecture version level, and providing interactive functions such as search, filter, expand, and drill down.

[0157] For example, after the page loads, the front-end script reads data and dynamically renders interactive components such as coverage cards, pie charts, ISA version statistics tables, file details tables, and instruction category views. It supports progress bar visualization, expanding to view details, real-time fuzzy search, table header sorting, and filtering by coverage status. It can also expand chart types and add dimension views as needed to achieve intuitive, efficient, and portable instruction coverage analysis.

[0158] The interactive components include: a coverage statistics card area displaying key indicators such as total number of instructions, number of covered instructions, number of uncovered instructions, coverage percentage, and number of analysis files in the form of numerical cards; a coverage pie chart showing the proportion of covered and uncovered instructions to intuitively display the overall coverage status; an ISA version dimension statistics table grouping statistics by ISA version (e.g., ISA50, ISAStd, ISA40OR50) to show the total number, number of covered instructions, and coverage rate, with a progress bar for visualization; a file details table displaying the instruction usage of each analysis file in an expandable row format, where clicking on a row expands to view the detailed count of each instruction in that file, supporting search and filtering by instruction name and sorting by coverage rate; an instruction category view grouping instruction coverage by category, where clicking on a category expands to view detailed information on all instructions under that category, including a list of file tags using the instruction, supporting search by category name and filtering by covered or uncovered status; and a global search and sorting function where all table columns support sorting by clicking the table header (ascending or descending order), with the search box supporting real-time fuzzy matching.

[0159] By serializing multi-dimensional statistical results into script object format data and injecting them into predefined templates, a single-file interactive report in Hypertext Markup Language is generated. This achieves integrated processing of statistical data and front-end display logic, allowing direct parsing and execution in a browser without relying on back-end services or external resources. This ensures report portability and cross-platform usability, while also providing intuitive visualization through dynamically drawn coverage charts and display of instruction set architecture version-level data. Furthermore, it is equipped with search, filtering, and drill-down functions to improve the efficiency of data querying and in-depth analysis, enabling users to quickly locate key information and fully grasp instruction coverage. This provides efficient, reliable, and easy-to-use analytical support for instruction set evaluation, compiler optimization, and architecture design.

[0160] Optionally, based on the above embodiments and incorporating historical analysis results, generating an instruction coverage change report may include: Historical analysis results are retrieved from a remote storage server as the analysis baseline. The set of unused instructions in this multi-dimensional statistical report and the set of unused instructions in the analysis baseline are extracted. A difference operation is performed on the set of unused instructions in this report and the set of unused instructions in the historical baseline. Newly added covered instructions and newly added unused instructions in the difference operation result are marked. The marked newly added covered instructions, newly added unused instructions and related information of the difference operation are sorted and summarized to generate an instruction coverage change report.

[0161] In this embodiment of the invention, historical analysis results can be specifically understood as: past instruction coverage analysis data stored on a remote server. Analysis baseline can be specifically understood as: historical benchmark data used for comparison and reference. Unused instruction set can be specifically understood as: a set of instructions that have not been used in the current or historical analysis. Newly added coverage instructions can be specifically understood as: instructions that were not used historically but have been used this time. Newly added unused instructions can be specifically understood as: instructions that were previously covered but are now unused. Remote storage server can be specifically understood as: a remote file server used to store historical analysis results.

[0162] Specifically, the historical baseline incremental comparison supports automatically obtaining historical analysis results from remote storage servers as a comparison baseline. For example, it can pull the latest historical unused instruction data from remote storage servers by timestamp as the analysis baseline, extract the unused instruction sets from the current statistical report and the historical baseline respectively, and perform a difference operation on the two sets.

[0163] Instructions that existed in the baseline but are not present in the current implementation correspond to newly overridden instructions that were previously unused but are now being used, indicating that the compiler has newly overridden these instructions. Instructions that exist in the current implementation but are not present in the baseline correspond to newly unused instructions that were previously overridden but are now unused, indicating that instruction usage has degraded. Instructions that were previously unused but are now used are marked as newly overridden instructions, and newly unused instructions are marked as instruction usage degraded.

[0164] The result of the difference operation is written into the change report in a structured format that includes the date and architecture identifier, forming an instruction coverage change report that can track coverage changes.

[0165] By introducing historical analysis results as a baseline and performing difference operations to generate instruction coverage change reports, it is possible to accurately identify newly covered instructions and newly added unused instructions compared to historical versions. This allows for the quantification of instruction coverage improvement and degradation during compiler iteration, which not only intuitively reflects the optimization effect but also promptly identifies potential feature rollback issues. It provides a quantifiable and comparable basis for continuously tracking instruction coverage evolution trends and evaluating the quality of development iterations, thereby enhancing the closed-loop capability of instruction set analysis and compiler optimization.

[0166] Figure 4 This is a schematic diagram illustrating a multi-architecture instruction analysis applicable to an embodiment of the present invention, such as... Figure 4 As shown, this multi-architecture instruction analysis process starts with input .so (dynamic shared library file), fatbin (fat binary file), and .s (assembly source file) files, and executes six stages sequentially: Stage 1 is binary ELF segment extraction, parsing the .so file segment table to extract the GPU executable ELF segment, and extracting it from the fatbin container in a JIT scenario; Stage 2 is multi-architecture parallel disassembly, automatically detecting the filename architecture identifier and mapping the disassembly parameter set, and executing objdump (object file disassembler) in parallel using a thread pool to support GCU3.0, GCU4.0, and GCU5.0 architectures; Stage 3 is instruction parsing and counting, supporting Mode A: .dis disassembly text parsing (operation code extraction based on instruction prefix) and Mode B: .s assembly source file parsing (pseudo-instruction filtering, metadata block state machine); Stage 4 is hierarchical instruction reduction and classification, using rule engine-based opcode reduction, data type stripping-based semantic reduction, and ISA definition. The system employs three strategies: reflection (automatically extracting instruction sets from TableGen source code) and association with ISA definition sources (TableGen (.td file), llvm-tblgen, Records (.inc file)). Phase 5 generates multi-dimensional statistical reports, outputting an Excel workbook containing worksheets for instructions × components and categories × components, CSV structured data including unused_asm.csv (unused instruction list) and instructions.csv (complete instruction list export), and an interactive HTML report containing a coverage pie chart, ISA version statistics, and expandable drill-down tables. Phase 6 performs incremental comparison of historical baselines, pulling remote baselines and generating an instruction coverage change report through set difference operations. The final output includes complete results in Excel (.xlsx), CSV (.csv), HTML (.html), and isa.changes (instruction coverage change report).

[0167] Figure 5 This is a schematic diagram illustrating an instruction parsing and hierarchical classification method applicable to an embodiment of the present invention, such as... Figure 5As shown, the instruction parsing and hierarchical classification process starts with a line of disassembled or assembled text as input. It determines whether the line contains instruction prefixes such as l, m, s, v, c, gemm. If not, the line is skipped. If it does, the opcode after the prefix and before the space is extracted. Then, it determines whether it contains the if() conditional execution prefix. If it does, it is concatenated into "if(xpr) opcode". If not, it is directly split into a component array parts[0..n] by ".". If the number of components is less than 2, it returns directly. Otherwise, it enters the priority rule chain (returns upon the first match). This rule chain contains rules R1 to R10: R1 is that if parts[0] is a prefix of gemm, mld, or mst, then the category is parts[0]. R2 is that if parts[0] is mli, then the category is parts[0].parts[1]. R3 is that if parts[1] is tvldoa or tvstoa, then it is concatenated hierarchically. xt / .reg, R4 is if parts[2] is .ext then the category is parts[1].ext, R5 is if parts[1] is nop then the category is parts[0].nop (preserving the slot prefix), R6 is if parts[1] is mop, amo, bc, redv then the category is parts[1].parts[2], R7 is if parts[0] is l, s, c, m, v basic slot then the category is parts[1] (removing the prefix), GCU5.0 extended rules R8-9 are used to strip data types, vgpr, modifier suffixes (30+ types), R10 if there is no match then directly returns the opcode itself; after the rule chain is processed, it enters the second-level mapping asm_spec_map, which maps the instruction category to ISA specification instructions (supports multi-target format), and finally outputs a result containing (instruction category, ISA specification instructions, count).

[0168] Figure 6 This is a schematic diagram illustrating a reflection definition based on an instruction set architecture applicable to an embodiment of the present invention, as shown below. Figure 6As shown, the instruction set architecture defines the reflection process starting from the compiler ISA definition source (including the GCU.td and EFGCU.td files of LLVM TableGen, used to define the assembly format, predicates, and namespaces). It then uses llvm-tblgen in -print-records mode to generate Records files (.inc files) containing dtu_records.inc and efgcu_records.inc, each containing complete instruction metadata. Subsequently, the Records parser segments the records by def {} block boundaries, extracts the key fields AsmString, Predicates, Namespace, and isPseudo, and filters to match the target ISA version and exclude pseudo-instructions. It merges variants of the same name and removes the type suffix to generate instruction categories, finally outputting a result containing the complete instruction set (name) and instruction metadata (namespace, ISA version, category). The diagram also contrasts the traditional manual method, which requires manual reading of the ISA manual and writing of the isa_instr_list.txt static instruction list and asm_spec_map.json static mapping table. In contrast, this solution generates the instruction set and metadata through an automated process, avoiding the lag and errors of manual maintenance.

[0169] Figure 7 This is a schematic diagram illustrating a multi-dimensional report generation method applicable to an embodiment of the present invention, such as... Figure 7As shown, this multi-dimensional report generation process centers on the core data structure asm_instr_map ({category → {opcode → count}} × component × architecture). Its left input is the {opcode:count} × component × architecture data (opcode count mapping table) output from stage 3, and its right input is the classification and mapping results (instruction classification results) output from stage 4 via classify() + asm_spec_map. Based on this core data structure, the process generates multiple report formats: First, Excel worksheet 1, the "Instruction × Component" table, with rows for each opcode, columns for each software component, and cell values ​​for the occurrence count; second, worksheets 2-3, the "Category × Component" table, containing aggregated counts, standardized instruction mappings, and the "New X.0" identifier; third, worksheet 4... -5. A "Summary + Unused" table, including summary statistics by component, coverage percentage, and a list of unused instructions; fourth, CSV output, including unused_asm.csv and instructions.csv (including name, ISA version, and category fields); fifth, an interactive HTML report, including a coverage pie chart, an ISA version statistics table, and drill-down details; the workflow also supports pulling baseline data from a remote baseline server, proceeding to stage 6 "Historical Baseline Incremental Comparison," which generates an isa.changes change report through set difference operations, and finally outputs a complete result including Excel (.xlsx), CSV (.csv), HTML (.html), and isa.changes (instruction coverage change report).

[0170] The technical solution of this invention achieves orderly management of multi-architecture instruction files by acquiring multi-architecture binary files generated by the compiler, extracting the executable target file format segment of the corresponding processor, naming and storing them in accordance with the architecture identifier specification; improving disassembly efficiency by matching the disassembly parameter set according to the architecture identifier in the target output file name and processing multiple target output files in parallel; obtaining the usage of instructions for each architecture by scanning the disassembly text file line by line, identifying instruction prefixes, extracting opcodes and concatenating them, and using a hash table to count the occurrence of opcodes; and achieving standardized classification of instructions by hierarchically classifying opcodes and mapping them to instruction categories in the instruction set architecture specification. By leveraging opcode count mapping tables and instruction classification results, statistical analysis is conducted across multiple dimensions—instruction-level, category-level, component-level, architecture-level, and instruction set architecture version-level—to comprehensively and meticulously reflect instruction usage and distribution at different granularities, ensuring the completeness and hierarchy of instruction usage analysis. Interactive reports in various formats, including spreadsheets, comma-separated values, and Hypertext Markup Language, are generated to meet the needs of data viewing, archiving, reuse, and secondary processing in different scenarios. The interactive reports also enhance data readability and ease of access, providing developers with intuitive and comprehensive data support for quickly grasping instruction usage patterns and identifying instruction distribution characteristics, thus improving the practicality and usability of multi-architecture instruction analysis results. Combining historical analysis results to generate instruction coverage change reports allows for the identification of instruction usage degradation and new coverage items during compiler iterations, further enhancing the practicality and reliability of multi-architecture instruction analysis.

[0171] Example 4 Figure 8 This is a schematic diagram of a multi-architecture instruction analysis device provided in Embodiment 4 of the present invention. Figure 8 As shown, the device includes: a file acquisition module 810, a format segment extraction module 820, a parallel disassembly module 830, a line-by-line scanning module 840, a canonical mapping module 850, and a report generation module 860, wherein: File acquisition module 810 is used to acquire multi-architecture binary files generated by the compiler; The format segment extraction module 820 is used to traverse the segment table in the multi-architecture binary file, extract the executable target file format segment corresponding to at least one processor as the output file, name the output file according to the architecture identifier to which the executable target file format segment belongs, and save it to the target storage directory. The parallel disassembler module 830 is used to read multiple target output files from the target storage directory, obtain the matching disassembly parameter set according to the target architecture identifier in the target output file name, and perform parallel disassembly on multiple target output files through the underlying virtual machine disassembler to obtain disassembled text files corresponding to multiple target architectures; The line-by-line scanning module 840 is used to scan each disassembled text file line by line, perform operations to identify instruction prefixes and extract opcodes, and concatenate the prefix and opcode for opcodes containing conditional execution prefixes. It uses a hash table to count the occurrence of each opcode and obtains the opcode count mapping table corresponding to each disassembled text file. The specification mapping module 850 is used to hierarchically classify the opcodes in the opcode count mapping table and map the opcodes to the instruction categories in the instruction set architecture specification to obtain the instruction classification results; The report generation module 860 is used to generate multi-dimensional statistical reports based on the opcode count mapping table and instruction classification results, and to generate instruction coverage change reports in combination with historical analysis results. Based on the instruction coverage change reports, the module can locate instruction usage degradation items and new coverage items in the compiler iteration, and guide compiler optimization, instruction set architecture iteration or software component instruction adaptation adjustment.

[0172] The technical solution of this invention, by acquiring multi-architecture binary files generated by the compiler and extracting the executable target file format segment of the corresponding processor, and naming and storing them according to the architecture identifier specification, can achieve orderly management of multi-architecture instruction files, avoid confusion between instruction files of different architectures, and lay a well-organized data foundation for subsequent analysis. By matching the disassembly parameter set according to the architecture identifier in the target output file name and processing multiple target output files in parallel, disassembly efficiency can be improved, adapting to the needs of batch analysis of multi-architecture instructions and reducing analysis time. By scanning the disassembled text file line by line, identifying instruction prefixes, extracting opcodes and concatenating them, and combining the opcode occurrence count with a hash table, the usage of instructions for each architecture can be obtained, ensuring the accuracy of opcode counting and providing reliable data support for subsequent classification and statistics. By hierarchically classifying opcodes and mapping them to instruction categories in the instruction set architecture specification, standardized instruction classification can be achieved, facilitating the understanding of the distribution characteristics of different instruction categories and solving the problems of chaotic instruction classification and difficulty in unified analysis across multiple architectures. By combining the opcode count mapping table with instruction classification results to generate multi-dimensional statistical reports, and combining historical analysis results to generate instruction coverage change reports, it is possible to locate instruction usage degradation items and newly added coverage items in compiler iterations. This provides targeted guidance for compiler optimization, instruction set architecture iteration, and instruction adaptation adjustments for software components, improving compiler performance, refining instruction set architecture design, optimizing the compatibility of software components with multiple architectures, and solving the technical problems of low efficiency, non-standardized classification, and lack of practical guidance in existing multi-architecture instruction analysis, thereby enhancing the practicality and reliability of multi-architecture instruction analysis.

[0173] Based on the above embodiments, the format segment extraction module 820 is specifically used for: Create a new target first-level directory under the target storage directory, and combine the component name to which the multi-architecture binary file belongs with the original file name of the multi-architecture binary file as the directory name of the target first-level directory; combine the architecture identifier, segment number, chip type and file format in sequence to obtain the target file name, and use the target file name to name the output file; store the named output file in the target first-level directory.

[0174] Based on the above embodiments, the parallel disassembler module 830 is specifically used for: A thread pool matching the number of CPU cores is created. The disassembly task of each target output file is submitted to the thread pool as an independent work unit. Each worker thread is allocated by the thread pool to call the underlying virtual machine disassembly tool to independently perform the disassembly operation. The disassembly results are written to the corresponding text files by each worker thread to obtain disassembly text files corresponding to various target architectures.

[0175] Furthermore, based on the above embodiments, the multi-architecture instruction analysis device may further include: an assembly source acquisition module, a parallel parsing module, a whitelist filtering module, a tracing filtering module, a regular expression matching module, a tag annotation module, a statistics module, and a mapping table module, wherein: The assembly source acquisition module is used to acquire the assembly source file generated by the compiler before performing hierarchical classification of the opcodes in the opcode count mapping table; The parallel parsing module is used to perform multi-process parallel parsing operations on assembly source files: The whitelist filtering module is used to filter compiler or assembler pseudo-instructions in a file using a pre-stored pseudo-instruction whitelist. The tracing and filtering module is used to trace and filter processor kernel function metadata blocks in a file through a state machine; The regular expression matching module is used to match the indentation identifier at the beginning of the line in the filtered file content using regular expressions and then concatenate it with subsequent instruction fragments separated by preset identifiers to form a complete instruction name; The tag and comment module is used to filter tag lines and comment lines in a file; The statistics module is used to identify instruction prefixes in instruction names and extract the corresponding opcodes. For opcodes with conditional execution prefixes, the prefix and opcode are concatenated. A hash table is used to count the occurrences of each opcode. The mapping table module is used to merge all statistical results by the main process according to the architecture dimension after it is determined that each process has independently completed the parsing and statistics of the corresponding assembly source file, so as to obtain the opcode count mapping table corresponding to each assembly source file.

[0176] Based on the above embodiments, the standard mapping module 850 is specifically used for: The opcodes in the opcode count mapping table are hierarchically classified using a preset priority strategy to determine the instruction category corresponding to each opcode. The preset priority strategy includes: a rule engine reduction strategy, a data type suffix stripping strategy, and an instruction set architecture definition reflection strategy. Based on the instruction category corresponding to the opcode, the opcode is mapped to the instruction category in the instruction set architecture specification to obtain the instruction classification result that matches the instruction set architecture manual.

[0177] Based on the above embodiments, the standard mapping module 850 is further used for: When the preset priority strategy is rule engine reduction, the preset classification function is called to classify the opcode, splitting the opcode by whitespace and removing the condition prefix. The last identifier segment is then divided into a first component array by the first delimiter. The following classification rules are executed sequentially until the instruction category corresponding to the opcode is determined: when the number of elements in the first component array is less than two, the opcode is classified into a separate instruction category; when the first element of the first component array is a matrix operation, memory loading, or memory storage instruction prefix, the first element of the first component array is taken as the instruction category corresponding to the opcode; when the first element of the first component array is a matrix multiplication / addition instruction prefix, the first and second elements of the first component array are concatenated as the instruction category corresponding to the opcode; when the second element of the first component array is a preset direction... When a quantity is loaded or a vector is stored, the instruction category corresponding to the opcode is generated based on the second element of the first component array. When the third element of the first component array is an extended identifier, the second element of the first component array is concatenated with the extended identifier to form the instruction category corresponding to the opcode. When the second element of the first component array is a no-operation identifier, the first element of the first component array is concatenated with the no-operation identifier to form the instruction category corresponding to the opcode. When the second element of the first component array is a composite instruction family identifier, the second and third elements of the first component array are concatenated to form the instruction category corresponding to the opcode. When the first element of the first component array is a basic slot identifier, the second element of the first component array is used as the instruction category corresponding to the opcode. When all rules do not match, the opcode itself is classified into the corresponding instruction category.

[0178] Based on the above embodiments, the standard mapping module 850 is further used for: When the preset priority strategy is a data type suffix stripping strategy, the opcode is divided into a second component array according to the second delimiter. Each component is scanned sequentially from the end to the beginning of the second component array to determine whether it belongs to a preset strippable suffix category. The preset strippable suffix categories include data type suffixes, symbol type suffixes, modifier suffixes, register specification suffixes, and type conversion suffixes. If the scanned component belongs to a preset strippable suffix category, the stripping operation is performed on that component, and the scanning continues with the previous component. If the scanned component does not belong to the preset strippable suffix category, the scanning stops. The remaining components after the scanning stops are reassembled according to the second delimiter to obtain the core part of the opcode after suffix stripping. This core part of the opcode is used as the instruction category corresponding to the opcode.

[0179] Based on the above embodiments, the standard mapping module 850 is further used for: When defining a reflection strategy for the instruction set architecture using a preset priority strategy, a preset compilation tool is invoked to process the instruction set architecture definition source file in a specified mode, generating a record file containing complete metadata for all instructions. The record file is then segmented according to preset code block boundaries, and the instruction assembly name, version predicate list, pseudo-instruction identifier, and namespace field are extracted from each segmented code block. Records containing the target instruction set architecture version identifier in the version predicate list and whose pseudo-instruction identifier is not a pseudo-instruction are filtered out, and different variants of instructions with the same name are merged to obtain standardized instruction set data. For each instruction name in the standardized instruction set data, a data type suffix stripping strategy is used for hierarchical classification to generate the instruction category corresponding to each instruction.

[0180] Based on the above embodiments, the report generation module 860 is specifically used for: Based on the opcode count mapping table and instruction classification results, multi-dimensional statistics are performed at the instruction level, category level, component level, architecture level, and instruction set architecture version level. Spreadsheet files, comma-separated value files, and interactive reports in Hypertext Markup Language are generated based on the statistical results as multi-dimensional statistical reports.

[0181] Based on the above embodiments, the report generation module 860 is further used for: The statistical results obtained from multi-dimensional statistics are serialized into script object format data, which is then injected into a predefined report template and rendered as a single-file hypertext markup language page. The single-file hypertext markup language page is then parsed in a browser to dynamically draw instruction coverage statistical charts and display instruction set architecture version-level statistical data, and provide search, filtering, and drill-down functions for the statistical content.

[0182] Based on the above embodiments, the report generation module 860 is further used for: Historical analysis results are retrieved from a remote storage server as the analysis baseline. The set of unused instructions in this multi-dimensional statistical report and the set of unused instructions in the analysis baseline are extracted. A difference operation is performed on the set of unused instructions in this report and the set of unused instructions in the historical baseline. Newly added covered instructions and newly added unused instructions in the difference operation result are marked. The marked newly added covered instructions, newly added unused instructions and related information of the difference operation are sorted and summarized to generate an instruction coverage change report.

[0183] The multi-architecture instruction analysis device provided in the embodiments of the present invention can execute the multi-architecture instruction analysis method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0184] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0185] Example 5 Figure 9 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0186] like Figure 9 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0187] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network device, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0188] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as multi-architecture instruction analysis methods, i.e.: Obtain the multi-architecture binary files generated by the compiler; Traverse the segment tables in the multi-architecture binary files, extract the executable object file format segment corresponding to at least one processor as the output file, name the output file according to the architecture identifier of the executable object file format segment, and save it to the target storage directory; Multiple target output files are read from the target storage directory. The matching disassembly parameter set is obtained according to the target architecture identifier in the target output file name. The multiple target output files are disassembled in parallel by the underlying virtual machine disassembly tool to obtain disassembly text files corresponding to various target architectures. The process involves scanning each disassembled text file line by line, identifying instruction prefixes and extracting opcodes, and concatenating the prefixes with opcodes containing conditional execution prefixes. A hash table is used to count the occurrences of each opcode to obtain the opcode count mapping table for each disassembled text file. The opcodes in the opcode count mapping table are hierarchically classified, and then mapped to instruction categories in the instruction set architecture specification to obtain the instruction classification results; Based on the opcode count mapping table and instruction classification results, a multi-dimensional statistical report is generated. Combined with historical analysis results, an instruction coverage change report is generated. This report helps to identify instruction usage degradation items and new coverage items in compiler iterations, guiding compiler optimization, instruction set architecture iteration, or software component instruction adaptation adjustments.

[0189] In some embodiments, the multi-architecture instruction analysis method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the multi-architecture instruction analysis method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the multi-architecture instruction analysis method by any other suitable means (e.g., by means of firmware).

[0190] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0191] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0192] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0193] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0194] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0195] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0196] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0197] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A multi-architecture instruction analysis method, characterized in that, include: Obtain the multi-architecture binary files generated by the compiler; Traverse the segment tables in the multi-architecture binary files, extract the executable object file format segment corresponding to at least one processor as the output file, name the output file according to the architecture identifier of the executable object file format segment, and save it to the target storage directory; Multiple target output files are read from the target storage directory. The matching disassembly parameter set is obtained according to the target architecture identifier in the target output file name. The multiple target output files are disassembled in parallel by the underlying virtual machine disassembly tool to obtain disassembly text files corresponding to various target architectures. The process involves scanning each disassembled text file line by line, identifying instruction prefixes and extracting opcodes, and concatenating the prefixes with opcodes containing conditional execution prefixes. A hash table is used to count the occurrences of each opcode to obtain the opcode count mapping table for each disassembled text file. The opcodes in the opcode count mapping table are hierarchically classified, and then mapped to instruction categories in the instruction set architecture specification to obtain the instruction classification results; Based on the opcode count mapping table and instruction classification results, a multi-dimensional statistical report is generated. Combined with historical analysis results, an instruction coverage change report is generated. This report helps to identify instruction usage degradation items and new coverage items in compiler iterations, guiding compiler optimization, instruction set architecture iteration, or software component instruction adaptation adjustments.

2. The method according to claim 1, characterized in that, The output file is named according to the architecture identifier of the executable object file format segment and saved to the target storage directory, including: Create a new target top-level directory under the target storage directory, and combine the component name to which the multi-architecture binary file belongs with the original file name of the multi-architecture binary file as the directory name of the target top-level directory; The architecture identifier, segment number, chip type, and file format are combined sequentially to obtain the target file name, and the output file is named using the target file name; Store the named output file in the target top-level directory.

3. The method according to claim 1, characterized in that, By using a low-level virtual machine disassembler to perform parallel disassembly on multiple target output files, disassembled text files corresponding to various target architectures are obtained, including: Create a thread pool that matches the number of CPU cores, submit the disassembly task of each target output file as an independent work unit to the thread pool, and allocate each work thread through the thread pool to call the underlying virtual machine disassembly tool to independently perform the disassembly operation; The disassembly results are written to corresponding text files by each worker thread, resulting in disassembly text files for various target architectures.

4. The method according to claim 1, characterized in that, Before hierarchically classifying the opcodes in the opcode count mapping table, the following steps are also included: Obtain the assembly source file generated by the compiler; Perform multi-process parallel parsing operations on the assembly source file: Filter compiler or assembler pseudo-instructions in the file using a pre-stored pseudo-instruction whitelist; The processor core function metadata blocks in the file are traced and filtered using a state machine. The filtered file content is matched with the indentation identifier at the beginning of the line using regular expressions and then concatenated with subsequent instruction fragments separated by preset identifiers to form a complete instruction name; Filter tag lines and comment lines in the file; Identify the instruction prefix in the instruction name and extract the corresponding opcode. For opcodes containing conditional execution prefixes, concatenate the prefix and opcode. Use a hash table to count the occurrences of each opcode. After determining that each process independently completes the parsing and statistics of the corresponding assembly source file, the main process merges all statistical results according to the architecture dimension to obtain the opcode count mapping table corresponding to each assembly source file.

5. The method according to claim 1, characterized in that, The opcodes in the opcode count mapping table are hierarchically categorized, and then mapped to instruction categories in the instruction set architecture specification, resulting in instruction classification results, including: The opcodes in the opcode count mapping table are hierarchically classified according to a preset priority strategy to determine the instruction category corresponding to the opcode. The preset priority strategy includes: rule engine reduction strategy, data type suffix stripping strategy, and instruction set architecture definition reflection strategy. Based on the instruction category corresponding to the opcode, the opcode is mapped to the instruction category in the instruction set architecture specification, resulting in an instruction classification result that matches the instruction set architecture manual.

6. The method according to claim 5, characterized in that, When the preset priority strategy is the rule engine reduction strategy, the opcodes in the opcode count mapping table are hierarchically classified according to the preset priority strategy to determine the instruction category corresponding to the opcode, including: The pre-defined classification function is called to classify the opcodes, split the opcodes by whitespace characters and remove the condition prefix, and take the last identifier segment to split it into the first component array by the first delimiter; The following classification rules are executed sequentially until the instruction category corresponding to the opcode is determined: When the number of elements in the first component array is less than two, the opcode is classified into a separate instruction category; When the first element of the first component array is a prefix of matrix operation, memory loading, or memory storage instruction, the first element of the first component array is used as the instruction category corresponding to the opcode. When the first element of the first component array is a matrix multiplication and addition instruction prefix, the first element of the first component array is concatenated with the second element to form the instruction category corresponding to the opcode; When the second element of the first component array is a preset vector loading or vector storage identifier, the instruction category corresponding to the opcode is generated based on the second element of the first component array; When the third element of the first component array is an extended identifier, the second element of the first component array is concatenated with the extended identifier to form the instruction category corresponding to the opcode; When the second element of the first component array is a no-operation flag, the first element of the first component array is concatenated with the no-operation flag to form the instruction category corresponding to the opcode; When the second element of the first component array is a composite instruction family identifier, the second element and the third element of the first component array are concatenated to form the instruction category corresponding to the opcode; When the first element of the first component array is the basic slot identifier, the second element of the first component array is used as the instruction category corresponding to the opcode; When all rules do not match, the opcode itself is classified into the corresponding instruction category.

7. The method according to claim 5, characterized in that, When the preset priority strategy is the data type suffix stripping strategy, the opcodes in the opcode count mapping table are hierarchically classified according to the preset priority strategy to determine the instruction category corresponding to the opcode, including: The opcode is divided into a second component array by the second delimiter. Each component is scanned sequentially from the end to the beginning of the second component array to determine whether the scanned component belongs to a preset strippable suffix category. The preset strippable suffix categories include data type suffix, symbol type suffix, modifier suffix, register specification suffix, and type conversion suffix. If the scanned component belongs to the preset peelable suffix category, then after performing the peel operation on that component, continue scanning the previous component; If the scanned component does not belong to the preset peelable suffix category, the scan stops; After the scan stops, the remaining components are reassembled according to the second separator to obtain the opcode core part after removing the suffix. The opcode core part is used as the instruction category corresponding to the opcode.

8. The method according to claim 5, characterized in that, When defining a reflection strategy for the instruction set architecture using a preset priority strategy, the opcodes in the opcode count mapping table are hierarchically categorized according to the preset priority strategy to determine the instruction category corresponding to the opcode, including: The default compilation tool is invoked to process the instruction set architecture definition source file in the specified mode, generating a log file containing complete metadata for all instructions; The record file is divided according to the preset code block boundaries, and the instruction assembly name, version predicate list, pseudo-instruction identifier and namespace field are extracted from each divided code block. Filter out records in the version predicate list that contain the target instruction set architecture version identifier and whose pseudo-instruction is identified as non-pseudo-instruction, and merge different variants of the same instruction to obtain standardized instruction set data; The instruction names in the standardized instruction set data are hierarchically classified using a data type suffix stripping strategy to generate instruction categories corresponding to each instruction.

9. The method according to claim 1, characterized in that, Based on the opcode count mapping table and instruction classification results, a multi-dimensional statistical report is generated, including: Based on the opcode count mapping table and instruction classification results, multi-dimensional statistics are performed at the instruction level, category level, component level, architecture level, and instruction set architecture version level. Spreadsheet files, comma-separated value files, and interactive reports in Hypertext Markup Language are generated based on the statistical results as multi-dimensional statistical reports.

10. The method according to claim 9, characterized in that, Generate interactive Hypertext Markup Language reports, including: The statistical results obtained from multi-dimensional statistics are serialized into script object format data, which is then injected into a predefined report template and rendered as a single-file hypertext markup language page. The single-file hypertext markup language page is then parsed in a browser to dynamically draw instruction coverage statistical charts and display instruction set architecture version-level statistical data, and provide search, filtering, and drill-down functions for the statistical content.

11. The method according to claim 1, characterized in that, Based on historical analysis results, a report on changes in instruction coverage is generated, including: Historical analysis results are retrieved from a remote storage server as the analysis baseline. The set of unused instructions in this multi-dimensional statistical report and the set of unused instructions in the analysis baseline are extracted. Perform a difference operation on the current set of unused instructions and the historical baseline set of unused instructions, and mark the newly added overridden instructions and newly added unused instructions in the difference operation result; The newly added covered instructions, newly added unused instructions, and information related to difference operations are compiled and summarized to generate an instruction coverage change report.

12. A multi-architecture instruction analysis device, characterized in that, include: The file acquisition module is used to acquire multi-architecture binary files generated by the compiler. The format segment extraction module is used to traverse the segment table in multi-architecture binary files, extract the executable target file format segment corresponding to at least one processor as the output file, name the output file according to the architecture identifier to which the executable target file format segment belongs, and save it to the target storage directory. The parallel disassembly module is used to read multiple target output files from the target storage directory, obtain the matching disassembly parameter set according to the target architecture identifier in the target output file name, and perform parallel disassembly on multiple target output files through the underlying virtual machine disassembly tool to obtain disassembly text files corresponding to various target architectures; The line-by-line scanning module is used to scan each disassembled text file line by line, perform operations to identify instruction prefixes and extract opcodes, and concatenate the prefix and opcode for opcodes containing conditional execution prefixes. It uses a hash table to count the occurrences of each opcode to obtain the opcode count mapping table corresponding to each disassembled text file. The specification mapping module is used to hierarchically classify the opcodes in the opcode count mapping table and map the opcodes to the instruction categories specified in the instruction set architecture to obtain the instruction classification results; The report generation module is used to generate multi-dimensional statistical reports based on the opcode count mapping table and instruction classification results, and to generate instruction coverage change reports by combining historical analysis results. Based on the instruction coverage change reports, the module can locate instruction usage degradation items and new coverage items in the compiler iteration, and guide compiler optimization, instruction set architecture iteration or software component instruction adaptation adjustment.

13. An electronic device, characterized in that, Electronic devices include: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the multi-architecture instruction analysis method according to any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the multi-architecture instruction analysis method according to any one of claims 1-11.

15. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the multi-architecture instruction analysis method according to any one of claims 1-11.

Images