Simulation analysis method and device for program fragments

Abstract

The invention relates to a simulation analysis method and device for program fragments. Comprises: constructing an original program file of a target program; running a target program fragment in the original program file through a simulator, capturing a corresponding running state, and generating check point data; merging the check point data into the original program file to obtain a to-be-tested program file; and according to the check point data in the to-be-tested program file, recovering the running state of the target program fragment in the to-be-tested program file in the test environment, and obtaining the performance data of the target program fragment during running of the target program. By optimizing storage and recovery processes of check points, the number of times of operation of a specified program on a simulator is reduced, tracking of a CPU register, codes and data is avoided, and the performance is improved; meanwhile, the construction method of the test instruction slicing system is improved, so that the generated program slices can run in target environments such as a simulator, a simulation environment and an FPGA without depending on a specific test system, and portability and test efficiency are improved.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of computer technology, and more particularly to a method and device for simulating and analyzing program fragments. Background Art

[0002] A checkpoint is a snapshot of the program state saved at a specific point in time during program execution. Checkpoints can be used to back up and restore program state. For example, after extracting a representative segment of a program, it is necessary to save the checkpoint corresponding to the starting point of the segment to facilitate the recovery of the segment in a simulator or hardware environment. This segment can then be simulated and analyzed to obtain performance data for the representative segment.

[0003] After obtaining a feature slice, existing technologies (e.g., Chinese patent application CN115270699A) require modifying the simulator and re-running the feature slice using developed instructions and instruction tracing capabilities. Tracing (tracing data includes CPU registers, code, and data) begins at the beginning of the feature slice and continues until the feature slice completes before generating the corresponding slice assembly code. When a program slice itself contains a large number of instructions, tracing the CPU registers, code, and data in the simulator consumes a significant amount of time. Combined with the execution of Gem5 in step S1.1 and the subsequent execution of Gem5, this solution requires executing the specified program three times to obtain program feature information, further increasing the time consumption. Furthermore, the program slice generated in step S3 of this solution cannot be run directly; it must be linked to a specific test system to generate an executable file that can run on the target test system. This additional linking process not only increases operational complexity but can also introduce compatibility issues, especially when test system configurations vary or the target hardware environment changes. Furthermore, this reliance on a specific test system limits the portability of program slices, making this solution inefficient for cross-platform verification or rapid deployment, further increasing the time and resource consumption during the development and debugging phases.

[0004] How to improve the efficiency of program fragment simulation analysis, enhance portability and reduce operational complexity is a technical problem that needs to be solved urgently. Summary of the Invention

[0005] To solve the problems existing in the prior art, the embodiments of this specification provide a simulation analysis method and device for program fragments. By optimizing the checkpoint saving and recovery process, the number of times a specified program is run on the simulator is reduced and the tracking of CPU registers, code and data is avoided, thereby improving the performance when processing large-scale programs. At the same time, the construction method of the test instruction slicing system is improved, so that the generated program slices can run in target environments such as simulators, simulation environments, FPGAs, etc. without relying on a specific test system, providing portability and testing efficiency.

[0006] The specific technical solutions of the embodiments of this specification are as follows:

[0007] On the one hand, an embodiment of this specification provides a simulation analysis method for a program fragment, the method comprising:

[0008] Build the original program files of the target program;

[0009] Running the target program fragment in the original program file through the simulator, capturing the corresponding running state, and generating checkpoint data;

[0010] Merging the checkpoint data into the original program file to obtain a program file to be tested;

[0011] The running state of the target program fragment in the program file to be tested is restored in a test environment according to the checkpoint data in the program file to be tested, and the target program is run in the test environment to obtain performance data of the target program fragment.

[0012] Further, the checkpoint data includes memory data;

[0013] The steps of capturing the memory data include:

[0014] Extracting corresponding memory data blocks from the runtime memory according to the address range and data block size of each type of memory data stored in the runtime memory;

[0015] Construct each memory data block into a corresponding ELF file section.

[0016] Furthermore, the runtime memory includes a firmware memory area;

[0017] The types of the memory data include static memory data and dynamic memory data;

[0018] Extracting corresponding memory data blocks from the runtime memory according to the address range and data block size of each type of memory data stored in the runtime memory further includes:

[0019] extracting a first memory data block from the firmware memory area according to an address range and a data block size of the static memory data stored in the firmware memory area;

[0020] Obtain operating parameters of dynamic memory data from the simulator, calculate an address range and a data block size of the dynamic memory data stored in the firmware memory area based on the operating parameters, and extract a second memory data block from the firmware memory area based on the calculated address range and data block size.

[0021] Furthermore, the runtime memory includes a Payload memory area;

[0022] The type of the memory data includes one or more data areas in the Payload memory area, where the data areas are obtained by performing a byte scan on the Payload memory area;

[0023] Extracting corresponding memory data blocks from the runtime memory according to the address range and data block size of each type of memory data stored in the runtime memory further includes:

[0024] One or more third memory data blocks are extracted from the Payload memory area according to the address range and data block size of the data area.

[0025] Furthermore, merging the checkpoint data into the original program file to obtain the program file to be tested further comprises:

[0026] Judge whether there is the original ELF file section corresponding to the ELF file section in the original program file;

[0027] If so, the ELF file section is overwritten by the corresponding original ELF file section in the original program file;

[0028] If not, add the ELF file section to the original program file.

[0029] Furthermore, restoring the running state of the target program segment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested further includes:

[0030] Parsing the ELF file section in the program file to be tested in the test environment to obtain the memory data block;

[0031] The memory data block is loaded into the memory of the test environment.

[0032] Further, the checkpoint data includes register data;

[0033] Merging the checkpoint data into the original program file to obtain the program file to be tested further comprises:

[0034] The register data is stored in a workspace corresponding to the hardware thread of the original program file.

[0035] Furthermore, restoring the running state of the target program segment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested further includes:

[0036] Extracting register data in a workspace corresponding to a hardware thread of the original program file;

[0037] The register data is loaded into the hardware register of the test environment.

[0038] On the other hand, an embodiment of this specification further provides a simulation analysis device for a program fragment, the device comprising:

[0039] An original program file construction unit, used for constructing an original program file of a target program;

[0040] A checkpoint data generating unit, configured to run the target program fragment in the original program file through a simulator, capture the corresponding running state, and generate checkpoint data;

[0041] a program file to be tested generating unit, configured to merge the checkpoint data into the original program file to obtain the program file to be tested;

[0042] The test deployment unit is used to restore the running state of the target program fragment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested, and run the target program in the test environment to obtain performance data of the target program fragment.

[0043] On the other hand, an embodiment of this specification further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program implements the above method when executed by a processor.

[0044] Using the embodiments of this specification, the checkpoint data is merged with the original program file to obtain the program file to be tested, forming a unified structured layout, ensuring that the checkpoint data is completely preserved, and the program file to be tested can be directly loaded into the test environment. The running status of the target program fragment is restored in the test environment based on the checkpoint data, and then the target program fragment is run in the test environment to obtain performance data. This process does not require additional snapshot files, realizes efficient state recovery and performance analysis, and improves the format standardization and compatibility of checkpoint storage and recovery. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0046] Figure 1 The figure shows a flow chart of a simulation analysis method of a program fragment in an embodiment of this specification;

[0047] Figure 2 The figure shows a schematic diagram of memory distribution during runtime in the embodiment of this specification;

[0048] Figure 3 The figure shows a schematic diagram of the process of capturing the memory data in the embodiment of this specification;

[0049] Figure 4 FIG2 is a flow chart of extracting corresponding memory data blocks from the runtime memory according to the address range and data block size of each type of memory data stored in the runtime memory in an embodiment of this specification;

[0050] Figure 5 FIG2 is a first flow chart of restoring the running state of the target program segment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested in an embodiment of the present specification;

[0051] Figure 6 FIG2 is a second flow chart of restoring the running state of the target program segment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested according to the embodiment of this specification;

[0052] Figure 7 The figure shows a schematic diagram of the structure of a simulation analysis device for a program fragment in an embodiment of this specification;

[0053] Figure 8 The figure shows a schematic diagram of the structure of a computer device in an embodiment of this specification.

[0054]

Description of the accompanying drawings

[0055] 701. Original program file construction unit;

[0056] 702. Checkpoint data generating unit;

[0057] 703. Test program file generation unit;

[0058] 704, test deployment unit;

[0059] 802. Computer equipment;

[0060] 804. Processing equipment;

[0061] 806. Storage resources;

[0062] 808, driving mechanism;

[0063] 810, input / output module;

[0064] 812. Input devices;

[0065] 814. Output device;

[0066] 816. Presentation equipment;

[0067] 818. Graphical User Interface;

[0068] 820, network interface;

[0069] 822, communication link;

[0070] 824. Communication bus. DETAILED DESCRIPTION

[0071] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the embodiments described are only part of the embodiments of this specification, not all of them. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the embodiments of this specification.

[0072] It should be noted that the terms "first", "second", etc. in the description and claims of the embodiments of this specification and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the embodiments of this specification described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0073] It should be noted that the acquisition, storage, use, and processing of data in the technical solutions of the embodiments of this specification comply with the relevant provisions of national laws and regulations.

[0074] It should be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. They should be regarded as exemplary and their purpose is only to illustrate the feasibility of implementing the technical solution of this application, but it does not mean that the applicant has or will necessarily use the solution.

[0075] In response to the problems existing in the prior art, the embodiments of this specification provide a simulation analysis method for program fragments. By optimizing the checkpoint saving and recovery process, the number of times a specified program is run on the simulator is reduced and the tracking of CPU registers, code and data is avoided, thereby improving the performance when processing large-scale programs. At the same time, the construction method of the test instruction slicing system is improved so that the generated program slices can run in target environments such as simulators, simulation environments, FPGAs, etc. without relying on a specific test system, thereby providing portability and testing efficiency. Figure 1 The figure shows a flow chart of a simulation analysis method of a program fragment in an embodiment of this specification. This figure describes the process of saving and restoring checkpoint data and building a test system. The order of steps listed in the embodiment is only one way of executing the steps among many, and does not represent the only execution order. When the actual system or device product is executed, it can be executed in sequence or in parallel according to the method shown in the embodiment or the accompanying drawings. Specifically, Figure 1 As shown, the method may include:

[0076] Step 101: Constructing the original program file of the target program;

[0077] Step 102: Run the target program fragment in the original program file through the simulator, capture the corresponding running status, and generate checkpoint data;

[0078] Step 103: Merging the checkpoint data into the original program file to obtain a program file to be tested;

[0079] Step 104: Restore the running state of the target program fragment in the program file to be tested in a test environment according to the checkpoint data in the program file to be tested, and run the target program in the test environment to obtain performance data of the target program fragment.

[0080] Using the embodiments of this specification, the checkpoint data is merged with the original program file to obtain the program file to be tested, forming a unified structured layout, ensuring that the checkpoint data is completely preserved, and the program file to be tested can be directly loaded into the test environment. The running status of the target program fragment is restored in the test environment based on the checkpoint data, and then the target program fragment is run in the test environment to obtain performance data. This process does not require additional snapshot files, realizes efficient state recovery and performance analysis, and improves the format standardization and compatibility of checkpoint storage and recovery.

[0081] The main purpose of step 101 is to build the original program file (i.e., original Workload) of the target program. Specifically, a complete original Workload file is generated by compiling and packaging the firmware, operating system, and benchmark program. The original Workload file contains all the components required for operation and supports the complete operation of the firmware, operating system, and benchmark program from the beginning. In order to optimize the subsequent stages, the embodiment of this specification reserves space in the original Workload for the storage of checkpoint data, laying the foundation for efficiently saving the running status.

[0082] In order to facilitate the explanation of the technical solution of the present embodiment, the following examples are given. The software, components, models and other existing solutions in the industry described in the following examples are only for the purpose of illustrating the method of the present embodiment, and do not mean that these software, components or models are used in the present embodiment, nor do they mean that the method of the present embodiment is limited to use in the following software, components or models.

[0083] In this embodiment, a simulator is a software tool used to simulate the behavior and functionality of a hardware device, system, or other software, such as a functional simulator or a cycle-accurate simulator. It can create a virtual environment in which users can execute and test various operations without the need for actual physical hardware.

[0084] The workload of this embodiment includes firmware, an operating system, and a benchmark test program, wherein the firmware may be OpenSBI, the operating system may be Linux, and the benchmark test program may be SPEC 2006 Benchmark, forming a complete operating environment.

[0085] OpenSBI: As the workload firmware, OpenSBI is responsible for system startup, booting the Linux kernel, and providing the SBI (Supervisor Binary Interface) call interface. It initializes the hardware environment and loads subsequent components, ensuring the system successfully enters the operating system runtime phase. In this embodiment, an image containing Linux and related files is compiled and embedded into the OpenSBI firmware as a payload, achieving a seamless integration between the firmware and the operating system.

[0086] Linux: As the workload's operating system, Linux provides a runtime environment for user programs, including file system support, process management, and device driver functionality. In this embodiment, the Linux kernel is configured to support the RISC-V architecture and integrates a RAM file system (RamFS) as the root file system. RamFS contains the SPEC 2006 Benchmark binary. By loading this image, Linux provides a stable runtime platform, laying the foundation for benchmark execution.

[0087] SPEC 2006 Benchmark: As a user-mode program, SPEC 2006 is a widely used benchmark suite for CPU performance evaluation. It includes a variety of compute-intensive tasks and comprehensively measures processor performance. In this example, SPEC 2006 is cross-compiled using the RISC-V toolchain to generate executable files adapted for the RISC-V architecture. After compilation, these files are packaged into RamFS and embedded into the Linux image when it is generated, ensuring that the test program can be run directly without any external dependencies.

[0088] The checkpoint data may include register data. In step 101, memory is reserved for saving the checkpoint data. In this embodiment, space is reserved in the workspace (Scratch space) allocated by OpenSBI to each hardware thread (HART) for saving the checkpoint register data (Restore Data).

[0089] The scratch space is the context space used by OpenSBI when entering the machine mode (M-mode) trap handler. Its address is stored in the CSR_MSCRATCH register. By calling the unsigned long sbi_scratch_alloc_offset(unsigned long size) function, a memory space of size can be dynamically allocated for each HART. The starting address of this memory block is equal to the value of the CSR_MSCRATCH register plus the restore_data_offset offset. It is used to store register state data required for checkpoint recovery (such as general registers and program counters). This design ensures efficient storage and access of checkpoint data, providing a reliable foundation for the subsequent workload merging and recovery phases.

[0090] For example, the workload is stored in the Executable and Linkable Format (ELF) format by default. The ELF file encapsulates the checkpoint data and the merged memory layout through its standard ELF file section structure (such as .text, .data, .bss, etc.). The runtime memory is distributed as follows: Figure 2 As shown in the figure, the 2MB address space from 0x80000000 to 0x80200000 is a fixed space allocated to OpenSBI. Linux and RamFS are located in the space from 0x80200000 to the DDR End. The Restore Data space reserved for each HART is located in the Scratch space. restore_data_offset is a global variable whose address can be obtained by querying the ELF file's symbol table and then reading its value.

[0091] It should be noted that the register data may also be stored in other locations of the original program file, and this embodiment of the specification does not limit this.

[0092] In the embodiments of this specification, the target program fragment in the original program file can be specified by the staff, for example, the target program fragment is a program of a specified functional module, or the original program file can be analyzed by a prior art method (such as SimPoint) to extract a representative program fragment from the original program file and use it as the target program fragment. It is necessary to save the starting address of the target program fragment to facilitate the recovery of the program fragment in a simulator or hardware environment to obtain performance data of the target program fragment.

[0093] Therefore, in this embodiment, the checkpoint data may include the starting address of the target program fragment, and the starting address may be stored in the same location of the register data or in other locations in the original program file, which is not limited in this embodiment of the specification.

[0094] In this embodiment, the checkpoint data also includes memory data.

[0095] like Figure 3 As shown, the steps of capturing the memory data include:

[0096] Step 301: extracting corresponding memory data blocks from the runtime memory according to the address range and data block size of each type of memory data stored in the runtime memory;

[0097] Step 302: construct each memory data block into a corresponding ELF file section.

[0098] Continue as Figure 2As shown, the corresponding memory data block can be extracted from the Runtime Memory according to the address range and data block size of each type of memory data stored in . Then, each memory data block is constructed into a corresponding ELF file section.

[0099] In the embodiments of this specification, Runtime Memory includes a firmware memory area;

[0100] The types of memory data include static memory data and dynamic memory data;

[0101] like Figure 4 As shown, extracting corresponding memory data blocks from the runtime memory according to the address range and data block size of each type of memory data stored in the runtime memory further includes:

[0102] Step 401: extracting a first memory data block from the firmware memory area according to the address range and data block size of the static memory data stored in the firmware memory area;

[0103] In this step, the text, data, and bss segments of the firmware memory containing OpenSBI are typically already included in the original workload's ELF file and are considered static memory data. To process these segments, simply locate the corresponding data blocks in runtime memory based on the address ranges of each section in the ELF file.

[0104] Because the section corresponding to the static memory data exists in the original ELF file section in the workload, when merging the original workload, you can use the section corresponding to the static memory data to replace the content of the corresponding section in the ELF file of the original workload.

[0105] Step 402: Obtain operating parameters of the dynamic memory data from the simulator, calculate the address range and data block size of the dynamic memory data stored in the firmware memory area based on the operating parameters, and extract a second memory data block from the firmware memory area based on the calculated address range and data block size.

[0106] In this step, additional processing steps are required for dynamically allocated areas, such as Hart Stack, Scratch, and Heap memory data. The data in these areas are usually not statically defined in the ELF file of the original workload, but are dynamically generated by the runtime environment based on the hardware configuration. Therefore, it is necessary to calculate the address range and occupied space of these areas in memory based on specific runtime parameters (such as the number of Harts, the Stack size of each Hart, the Scratch space requirements, and the size of the Heap). For example, based on Figure 2 The Runtime Memory structure shown in Figure 4 The method has already obtained the first memory data block corresponding to the static memory data. Following the static memory data is the dynamic memory data, which includes memory data such as the Hart Stack, Scratch, and Heap. Based on the number of Harts, the stack size of each Hart, the required Scratch space, and the size of the Heap, the address range and occupied space of these areas in the memory space remaining after the static memory data can be calculated. This allows the second memory data block to be extracted.

[0107] Then, new sections are created: Because the dynamic memory data does not have a corresponding original section in the original workload's ELF file, new sections (such as .data_hart0 and .data_heap) are added to the original workload's ELF file during the original workload merging process. These sections are then filled with the calculated address range and extracted data. The Program Header and Section Header of the original workload's ELF file are then adjusted to ensure that the newly added sections are consistent with the original structure and can be correctly parsed by the loader.

[0108] In the embodiments of this specification, Runtime Memory also includes the Payload memory area. For the Payload memory area containing the Linux Kernel and SPEC 2006 Benchmark, since its data has been embedded in the Payload Section of the original Workload as a binary file (bin file), and no information other than Runtime Memory scanning can be used, the original Workload ELF file lacks specific symbols or structural information about these contents. Therefore, to identify the memory area used in the Payload, the only way is to directly scan the Runtime Memory data snapshot, analyze its content characteristics, merge these memory areas according to a certain strategy, and merge the original Workload by adding a corresponding section in the original Workload ELF file, such as .data_payloadN, to save this data.

[0109] Specifically, the type of memory data includes one or more data areas in the Payload memory area, and the data areas are obtained by byte scanning the Payload memory area; when extracting the memory data blocks with data areas from the Payload memory area of the Runtime Memory, one or more third memory data blocks can be extracted from the Payload memory area according to the address range and data block size of the data areas.

[0110] After obtaining the program file to be tested, the target program fragment in the program file to be tested can be simulated according to the actual simulation needs to obtain the performance data of the target program fragment, so that the staff can analyze the performance data, such as judging the execution efficiency of the target program fragment, and improve and optimize the target program fragment.

[0111] Specifically, if Figure 5 As shown, restoring the running state of the target program segment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested further includes:

[0112] Step 501: parsing the ELF file section in the program file to be tested in the test environment to obtain the memory data block;

[0113] Step 502: Load the memory data block into the memory of the test environment.

[0114] In the embodiments of this specification, the program file to be tested (Merged Workload) generated after the merger is completed supports recovery of operation on different test platforms such as performance simulators, simulation environments, or FPGAs, providing wide compatibility for system status recovery. Specifically, because the Merged Workload of this embodiment is stored in the ELF format, performance simulators or simulation environments (such as GEM5) that support direct loading of ELF files can directly parse the Section information of the Merged Workload's ELF file and load the data therein into the corresponding memory address of the test environment, thereby realizing the recovery of the running state.

[0115] Hardware devices such as FPGAs typically require support for a pure binary format. Therefore, this example uses the objcopy tool in the GNUBinutils toolkit to convert the Merged Workload's EIF file from ELF format to a pure binary BIN (binary) file. The converted BIN file can be written directly into the FPGA's memory via a hardware interface (such as JTAG or Flash programming) to complete the loading process.

[0116] like Figure 6 As shown, restoring the running state of the target program segment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested further includes:

[0117] Step 601: extracting register data in the workspace corresponding to the hardware thread of the original program file;

[0118] Step 602: Load the register data into the hardware register of the test environment.

[0119] In the embodiment of this specification, the register data stored in the Restore Data area (address CSR_MSCRATCH+restore_data_offset) in the Scratch space is read and loaded into the corresponding hardware registers (including general registers, program counters, etc.), thereby restoring the running environment of the workload at the checkpoint.

[0120] Thanks to the integration of checkpoint data (including memory and register data) into the Merged Workload file, whether loading via ELF or burning a BIN file, once the Merged Workload is loaded, the checkpoint's running state is restored. This design not only simplifies the recovery process but also ensures consistency across platforms.

[0121] According to one embodiment of the present specification, in order to enhance the scalability of checkpoint data preservation and recovery, a flag bit can also be set in the original workload, and the flag bit is used to determine whether the program file to be tested enters the checkpoint data recovery mode (Restore mode) to restore the checkpoint status, or initializes and runs according to the normal startup mode.

[0122] In this embodiment, the program for restoring the checkpointed operating state (Restore Code) is also pre-written in OpenSBI and integrated into the system as part of the firmware to support checkpoint recovery. The Restore Code flexibly controls the program's execution path using a flag set in the original workload (e.g., a predefined control variable or register value), thereby determining whether the system enters Restore mode to restore the checkpointed operating state or initializes in normal startup mode.

[0123] In Restore mode, the Restore Code reads the register information stored in the Restore Data area (address CSR_MSCRATCH+restore_data_offset) in the Scratch space and loads it into the corresponding hardware registers (including general registers, program counter, etc.), thereby restoring the workload's operating environment at the time of the checkpoint. In Normal Boot mode, the system skips the recovery logic and loads the Linux kernel and user-mode programs according to the standard OpenSBI boot process. This design achieves seamless compatibility between recovery and normal boot through dynamic switching of flags, providing flexible support for performance analysis and simulation scenarios.

[0124] To further support performance analysis, the restored target program fragment can be combined with a performance monitoring unit (PMU) or other hardware performance counters during runtime to collect key performance data (such as the number of instruction executions, cache hit rate, branch prediction accuracy, etc.).

[0125] It should be noted that the system construction in the aforementioned embodiment uses OpenSBI+Linux+SPEC 2006, but other firmware, operating systems and benchmark programs that support the RISC-V platform can also be used, such as RustSBI+Nuttx+Coremark, etc., as long as they can form a complete operating environment.

[0126] The default storage format of the original workload and the merged workload in the aforementioned embodiment is the ELF format, but it can also be other executable file formats, such as the PE (Portable Executable Format) format under the Windows system, as long as it can contain the instruction / data information required for the program to run and be loaded and run.

[0127] Based on the same inventive concept, the embodiment of this specification also provides a simulation analysis device for program fragments, such as Figure 7 As shown, including:

[0128] The original program file construction unit 701 is used to construct the original program file of the target program;

[0129] A checkpoint data generating unit 702 is configured to run the target program fragment in the original program file through a simulator, capture the corresponding running state, and generate checkpoint data;

[0130] A program file to be tested generating unit 703 is configured to merge the checkpoint data into the original program file to obtain the program file to be tested;

[0131] The test deployment unit 704 is used to restore the running state of the target program fragment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested, and run the target program in the test environment to obtain performance data of the target program fragment.

[0132] The beneficial effects achieved by the above-mentioned device are consistent with the beneficial effects achieved by the above-mentioned method, and will not be described in detail in the embodiments of this specification.

[0133] like Figure 8 The figure shows a schematic diagram of the structure of a computer device according to an embodiment of this specification. The method of the present invention can be applied to the computer device in this embodiment. The computer device 802 may include one or more processing devices 804, such as one or more central processing units (CPUs), each of which may implement one or more hardware threads.

[0134] The computer device 802 may also include any storage resources 806 for storing any kind of information such as code, settings, data, and the like.

[0135] For example, and without limitation, the storage resource 806 may include any one or a combination of the following: any type of RAM, any type of ROM, a flash memory device, a hard disk, an optical disk, and the like.

[0136] More generally, any storage resource can use any technology to store information.

[0137] Further, any storage resource may provide volatile or non-volatile retention of information.

[0138] Further, any storage resources may represent fixed or removable components of computer device 802 .

[0139] In one embodiment, when the processing device 804 executes the associated instructions stored in any storage resource or combination of storage resources, the computer device 802 can perform any operation of the associated instructions. The computer device 802 also includes one or more drive mechanisms 808 for interacting with any storage resources, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.

[0140] The computer device 802 may also include an input / output module 810 (I / O) for receiving various inputs (via input devices 812) and for providing various outputs (via output devices 814). A specific output mechanism may include a presentation device 816 and an associated graphical user interface (GUI) 818. In other embodiments, the input / output module 810 (I / O), input devices 812, and output devices 814 may not be included, and the computer device 802 may simply be a computer device in a network. The computer device 802 may also include one or more network interfaces 820 for exchanging data with other devices via one or more communication links 822. One or more communication buses 824 couple the components described above together.

[0141] The communication link 822 may be implemented in any manner, for example, via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 822 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0142] The embodiments of this specification also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program implements the above method when executed by a processor.

[0143] The embodiments of this specification also provide a computer-readable instruction, wherein when a processor executes the instruction, the program therein causes the processor to execute the above method.

[0144] It should be understood that in the various embodiments of the present specification, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present specification.

[0145] It should also be understood that in the embodiments of this specification, the term "and / or" is merely a description of the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent three situations: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, in the embodiments of this specification, the character " / " generally indicates that the associated objects are in an "or" relationship.

[0146] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the embodiments of this specification can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of this specification.

[0147] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0148] In the several embodiments provided in the embodiments of this specification, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, or can be electrical, mechanical or other forms of connection.

[0149] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of this specification.

[0150] In addition, the functional units in each embodiment of the present specification may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0151] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of this specification is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the embodiment of this specification. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0152] The embodiments of this specification use specific embodiments to illustrate the principles and implementation methods of the embodiments of this specification. The description of the above embodiments is only used to help understand the methods and core ideas of the embodiments of this specification. At the same time, for those skilled in the art, based on the ideas of the embodiments of this specification, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on the embodiments of this specification.

Claims

1. A simulation analysis method for a program fragment, characterized in that: The method comprises: Build the original program files of the target program; Running the target program fragment in the original program file through the simulator, capturing the corresponding running state, and generating checkpoint data; Merging the checkpoint data into the original program file to obtain a program file to be tested; The running state of the target program fragment in the program file to be tested is restored in a test environment according to the checkpoint data in the program file to be tested, and the target program is run in the test environment to obtain performance data of the target program fragment.

2. The method according to claim 1, characterized in that The checkpoint data includes memory data; The steps of capturing the memory data include: Extracting corresponding memory data blocks from the runtime memory according to the address range and data block size of each type of memory data stored in the runtime memory; Construct each memory data block into a corresponding ELF file section.

3. The method according to claim 2, characterized in that The runtime memory includes a firmware memory area; The types of the memory data include static memory data and dynamic memory data; Extracting corresponding memory data blocks from the runtime memory according to the address range and data block size of each type of memory data stored in the runtime memory further includes: extracting a first memory data block from the firmware memory area according to an address range and a data block size of the static memory data stored in the firmware memory area; Obtain operating parameters of dynamic memory data from the simulator, calculate an address range and a data block size of the dynamic memory data stored in the firmware memory area based on the operating parameters, and extract a second memory data block from the firmware memory area based on the calculated address range and data block size.

4. The method according to claim 2, characterized in that The runtime memory includes a Payload memory area; The type of the memory data includes one or more data areas in the Payload memory area, where the data areas are obtained by performing a byte scan on the Payload memory area; Extracting corresponding memory data blocks from the runtime memory according to the address range and data block size of each type of memory data stored in the runtime memory further includes: One or more third memory data blocks are extracted from the Payload memory area according to the address range and data block size of the data area.

5. The method according to claim 2, characterized in that Merging the checkpoint data into the original program file to obtain the program file to be tested further comprises: Judge whether there is the original ELF file section corresponding to the ELF file section in the original program file; If so, the ELF file section is covered by the corresponding original ELF file section in the original program file; If not, add the ELF file section to the original program file.

6. The method according to claim 5, characterized in that Restoring the running state of the target program segment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested further includes: Parsing the ELF file section in the program file to be tested in the test environment to obtain the memory data block; The memory data block is loaded into the memory of the test environment.

7. The method according to claim 1, characterized in that The checkpoint data includes register data; Merging the checkpoint data into the original program file to obtain the program file to be tested further comprises: The register data is stored in a workspace corresponding to the hardware thread of the original program file.

8. The method according to claim 7, characterized in that Restoring the running state of the target program segment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested further includes: Extracting register data in a workspace corresponding to a hardware thread of the original program file; The register data is loaded into the hardware register of the test environment.

9. A simulation analysis device for program fragments, characterized in that: The device comprises: An original program file construction unit, used for constructing an original program file of a target program; A checkpoint data generating unit, configured to run the target program fragment in the original program file through a simulator, capture the corresponding running state, and generate checkpoint data; a program file to be tested generating unit, configured to merge the checkpoint data into the original program file to obtain the program file to be tested; The test deployment unit is used to restore the running state of the target program fragment in the program file to be tested in the test environment according to the checkpoint data in the program file to be tested, and run the target program in the test environment to obtain performance data of the target program fragment.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images