Compiling building method and device, electronic equipment and storage medium

Abstract

The embodiment of the present disclosure discloses a compilation construction method and device, electronic equipment and storage medium, wherein the method comprises: determining compilation task parameter information, the compilation task parameter information comprising at least one processor core corresponding compilation task parameter; based on the compilation task parameter information, generating a processor core corresponding compilation task rule file; based on the processor core corresponding compilation class object, running the compilation task rule file to generate a processor core corresponding intermediate file; and based on the processor core corresponding intermediate file, generating a processor core corresponding target file. The embodiment of the present disclosure can automatically generate a compilation task rule file corresponding to each processor core for controlling compilation for homogeneous multi-core or heterogeneous multi-core, thereby realizing the compilation work of multiple processor cores, without the need for relevant personnel to develop a corresponding makefile script for each processor core, greatly reducing the relevant workload and effectively improving the compilation efficiency.

Description

Technical Field

[0001] This disclosure relates to compilation techniques, and in particular to a compilation and build method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of processor technology, multi-core processors have become the mainstream technology. Multi-core processors typically have multiple cores, and can be categorized as homogeneous multi-core or heterogeneous multi-core. In simulating and verifying multi-core systems, especially heterogeneous multi-core systems, verification engineers often need to develop corresponding Makefile scripts for different core architectures to handle the compilation process. Makefile scripts define a series of rules specifying which files should be compiled first, which should be compiled later, and which should be recompiled, leading to low compilation efficiency and consequently, low verification efficiency. Summary of the Invention

[0003] To address the aforementioned technical problems such as low compilation efficiency in multi-core systems, this disclosure is proposed. Embodiments of this disclosure provide a compilation and build method, apparatus, electronic device, and storage medium.

[0004] According to one aspect of the present disclosure, a compilation and construction method is provided, comprising: determining compilation task parameter information, the compilation task parameter information including compilation task parameters corresponding to at least one processor core; generating a compilation task rule file corresponding to the processor core based on the compilation task parameter information; running the compilation task rule file based on a compilation class object corresponding to the processor core to generate an intermediate file corresponding to the processor core; and generating a target file corresponding to the processor core based on the intermediate file corresponding to the processor core.

[0005] According to another aspect of the present disclosure, a compilation and build apparatus is provided, comprising: a first determining module, configured to determine compilation task parameter information, the compilation task parameter information including compilation task parameters corresponding to at least one processor core; a first processing module, configured to generate a compilation task rule file corresponding to the processor core based on the compilation task parameter information; a second processing module, configured to run the compilation task rule file based on a compilation class object corresponding to the processor core to generate an intermediate file corresponding to the processor core; and a third processing module, configured to generate a target file corresponding to the processor core based on the intermediate file corresponding to the processor core.

[0006] According to another aspect of the present disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program for executing the compilation and construction method described in any of the above embodiments of the present disclosure.

[0007] According to another aspect of the present disclosure, an electronic device is provided, the electronic device comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the compilation and construction method described in any of the above embodiments of the present disclosure.

[0008] Based on the compilation and building method, apparatus, electronic device and storage medium provided in the above embodiments of this disclosure, a compilation task rule file for controlling compilation can be automatically generated for each processor core for homogeneous multi-core or heterogeneous multi-core, thereby realizing the compilation work for multiple processor cores without the need for relevant personnel to develop corresponding makefile scripts for each processor core, greatly reducing the workload and effectively improving compilation efficiency.

[0009] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0010] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0011] Figure 1 This is an exemplary application scenario of the compilation and building method provided in this disclosure;

[0012] Figure 2 This is a flowchart illustrating a compilation and construction method provided in an exemplary embodiment of this disclosure;

[0013] Figure 3 This is a flowchart illustrating step 202 provided in an exemplary embodiment of this disclosure;

[0014] Figure 4 This is a flowchart illustrating step 2021 provided in an exemplary embodiment of this disclosure;

[0015] Figure 5 This is a flowchart illustrating step 2021 provided in another exemplary embodiment of this disclosure;

[0016] Figure 6 This is a flowchart illustrating step 203 provided in an exemplary embodiment of this disclosure;

[0017] Figure 7 This is a flowchart illustrating step 2022 provided in an exemplary embodiment of this disclosure;

[0018] Figure 8 This is a flowchart illustrating step 2024 provided in an exemplary embodiment of this disclosure;

[0019] Figure 9 This is a flowchart illustrating a compilation and construction method provided in another exemplary embodiment of this disclosure;

[0020] Figure 10 This is a flowchart illustrating a compilation and construction method provided in yet another exemplary embodiment of this disclosure;

[0021] Figure 11 This is a schematic diagram of the structure of a compilation and build apparatus provided in an exemplary embodiment of this disclosure;

[0022] Figure 12 This is a schematic diagram of the structure of the first processing module 502 provided in an exemplary embodiment of this disclosure;

[0023] Figure 13 This is a schematic diagram of the structure of the first determining unit 5021 provided in an exemplary embodiment of this disclosure;

[0024] Figure 14 This is a schematic diagram of the structure of the first determining unit 5021 provided in another exemplary embodiment of this disclosure;

[0025] Figure 15 This is a schematic diagram of the structure of the second processing module 503 provided in an exemplary embodiment of this disclosure;

[0026] Figure 16 This is a schematic diagram of the structure of the second determining unit 5022 provided in an exemplary embodiment of this disclosure;

[0027] Figure 17 This is a schematic diagram of the structure of the first generation unit 5024 provided in an exemplary embodiment of this disclosure;

[0028] Figure 18 This is a schematic diagram of the structure of the third processing module 504 provided in an exemplary embodiment of this disclosure;

[0029] Figure 19 This is a schematic diagram of the structure of a compilation and build apparatus provided in another exemplary embodiment of this disclosure;

[0030] Figure 20 This is a schematic diagram of the structure of the first determining module 501 provided in an exemplary embodiment of this disclosure;

[0031] Figure 21 This is a schematic diagram of the structure of a compilation and build apparatus provided in yet another exemplary embodiment;

[0032] Figure 22This is a schematic diagram of the structure of one application embodiment of the electronic device disclosed herein. Detailed Implementation

[0033] Hereinafter, exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. It is obvious that the described embodiments are merely some embodiments of the present disclosure, and not all embodiments of the present disclosure, and it should be understood that the present disclosure is not limited to the exemplary embodiments described herein.

[0034] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0035] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0036] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0037] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0038] Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this disclosure generally indicates that the preceding and following related objects have an "or" relationship.

[0039] It should also be understood that the description of the various embodiments in this disclosure emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0040] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0041] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0042] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0043] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0044] The embodiments disclosed herein can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate together with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, and servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems, etc.

[0045] Electronic devices such as terminal devices, computer systems, and servers can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in distributed cloud computing environments, where tasks are executed by remote processing devices linked through communication networks. In distributed cloud computing environments, program modules can reside on local or remote computing system storage media, including storage devices.

[0046] This disclosure outlines

[0047] In the process of realizing this disclosure, the inventors discovered that in the simulation verification of multi-core systems, especially in the simulation verification of heterogeneous multi-core systems, relevant verification engineers usually need to develop corresponding makefile scripts for different architecture cores to handle the compilation work of heterogeneous multi-core systems. The makefile script is used to define a series of rules to specify the files that need to be compiled first, the files that need to be compiled later, and the files that need to be recompiled, etc. Moreover, the calling logic of multiple makefiles is very cumbersome, resulting in low compilation efficiency, which in turn leads to low verification efficiency.

[0048] Exemplary Overview

[0049] Figure 1 This is an exemplary application scenario of the compilation and build method provided in this publication.

[0050] In chip verification scenarios, for multi-core chip systems, using the compilation and build method provided in this disclosure, users can input a list of compilation task commands into the compilation and build device executing the method via a terminal or any other means. This list includes compilation task parameters corresponding to at least one processor core. The device can then determine the compilation task parameter information based on the list and generate a compilation task rule file corresponding to the processor core. Similar to a Makefile, the compilation task rule file defines a series of rules to specify files that need to be compiled first, files that need to be compiled later, and files that need to be recompiled. The compilation task rule file can be any implementable script file; for example, it can be a compilation task rule script file generated by any organization of compilation tool libraries and template tool libraries to control the compilation process. For instance, for some automated build tools, this disclosure can be used to replace `make` to implement complex Makefile-like functions, thereby generating compilation task rule files. After generating the compilation task rule file corresponding to the processor core, the compilation task rule file is run based on the compilation class object corresponding to the processor core to generate the intermediate file corresponding to the processor core. Then, based on the intermediate file, the target file corresponding to the processor core is generated. The target file is at least one of the following: executable file (.so), disassembled file (.as), binary code file (.bin), and hexadecimal code file (.hex), obtained by linking, decompiling, and analyzing the intermediate file. The target file can be used in chip verification. The figure shows an example of verifying a multi-core system, where each processor core cluster corresponds to a core architecture, and each processor core cluster can include multiple processor cores of that architecture. For multi-core systems, this disclosure implements independent processing and resource isolation of the compilation tasks of each processor core based on an object-oriented approach. For each processor core, the above process can be followed to generate the compilation task rule file, intermediate file, and target file corresponding to each processor core, thereby realizing the automated construction and compilation of multi-core system compilation tasks, effectively improving compilation efficiency, and thus improving verification efficiency. In practical applications, multi-core systems may also include other subsystems, such as vision subsystems, message networks, etc., which are not limited in this disclosure.

[0051] The compilation and building method provided in this disclosure is not only applicable to any chip verification scenario, but can also be used in any other scenario that requires compilation to automate the compilation task and then perform compilation. The specific application scenario can be set according to actual needs, and this disclosure does not limit it.

[0052] Exemplary methods

[0053] Figure 2This is a schematic flowchart of a compilation and build method provided in an exemplary embodiment of this disclosure. This embodiment can be applied to electronic devices, specifically servers and terminals, such as... Figure 2 As shown, it includes the following steps:

[0054] Step 201: Determine the compilation task parameter information, which includes compilation task parameters corresponding to at least one processor core.

[0055] The compilation task parameter information can include project file information (such as project file identifier and location), the location of the compilation task (i.e., the directory, working directory), the location of the main compilation function, the processor core information (such as processor core architecture, number, type, etc.), and other relevant descriptive information. It can also include simulation code test case information (such as simulation code test case name), which can be set according to actual needs. The project file is a file describing the project information of the target architecture platform of the multi-core system or subsystem to be built. For example, it can be a file based on another markup language (YAML Ain't Markup Language, abbreviated as YAML), including macro information, static library information, header file information, startup assembly function information, etc. The project file needs to be prepared by the user according to their actual needs, and there are no specific limitations. The compilation task parameter information can include compilation task parameters corresponding to one or more processor cores. For cases involving compilation task parameters corresponding to multiple processor cores, these multiple processor cores can be homogeneous or heterogeneous, and there are no specific limitations.

[0056] The compilation task parameters can be prepared in advance by the user according to their actual needs and submitted to the compilation and build device disclosed herein through a certain method when compilation and build are required. The compilation and build device can then determine the compilation task parameters based on the content submitted by the user. The specific submission method by the user is not limited; for example, a list of compilation task commands can be passed to the compilation and build device.

[0057] Step 202: Based on the compilation task parameter information, generate the compilation task rule file corresponding to the processor core.

[0058] Similar to a Makefile, the compilation task rule file is a script that defines a series of rules to specify which files need to be compiled first, which files need to be compiled later, and which files need to be recompiled. The compilation task rule file can be any executable script file; for example, it can be a compilation task rule script file generated by an organization library and template library based on any language, used to control the compilation process. For instance, for some automated build tools, this disclosure is used to replace `make` in implementing complex Makefile-like implementations, thereby automatically generating compilation task rule files.

[0059] For example, based on the object-oriented factory pattern, classes can be pre-created to generate compilation task rule files corresponding to various types of processor cores. During the actual compilation and build process, objects corresponding to each processor core are instantiated according to the compilation task parameters corresponding to each processor core. Each processor core can instantiate its own corresponding object, and compilation task rule files corresponding to each processor core are generated independently based on the objects corresponding to each processor core, thereby enabling independent processing and resource isolation of the compilation tasks of each processor core.

[0060] Step 203: Based on the compilation class object corresponding to the processor core, run the compilation task rule file to generate the intermediate file corresponding to the processor core.

[0061] The compiler class object is an instantiation of a pre-created compiler class based on the compiler task parameters corresponding to each processor core. Each processor core's compilation task can correspond to an independent compiler class object, achieving independent processing and resource isolation among processor cores. Running the compiler task rule file based on the compiler class object can be done by accessing its member functions. For example, first, the automated build tool function is executed, then the compiler task rule file is run, generating the corresponding intermediate file. A processor core's compilation task corresponds to a project, which can include one or more source files. Source files refer to the source language program files to be compiled. After running the compiler task rule file, each source file can generate a corresponding intermediate file. For example, running the compiler task rule file generates an intermediate file, which is a binary code file (.o). The representation may differ under different build tools, and this disclosure does not limit this.

[0062] Step 204: Generate the target file corresponding to the processor core based on the intermediate file corresponding to the processor core.

[0063] The target file can be at least one of the following: an executable file (.so), a disassembled file (.as), a binary code file (.bin), or a hexadecimal code file (.hex). Since the intermediate files include the intermediate files corresponding to each source file, after the intermediate files are generated, linking, decompiling, and file analysis operations are required to obtain the corresponding executable file, disassembled file, binary code file, and hexadecimal code file. The specific compilation process will not be elaborated here.

[0064] The compilation and build method provided in this embodiment can automatically generate compilation task rule files for each processor core to control compilation, whether it is a homogeneous multi-core or heterogeneous multi-core processor. Then, based on the compilation task rule files corresponding to each processor core, intermediate files are generated respectively, and target files are generated based on the intermediate files. This enables the compilation of multiple processor cores without the need for relevant personnel to develop corresponding makefile scripts for each processor core, greatly reducing the workload and effectively improving compilation efficiency.

[0065] In one optional example, Figure 3 This is a flowchart illustrating step 202 provided in an exemplary embodiment of the present disclosure. In this example, step 202 may specifically include the following steps:

[0066] Step 2021: Based on the compilation task parameter information, determine the configuration factory class object corresponding to the processor core.

[0067] In this context, the configuration factory class object is an object instantiated from a pre-established configuration factory class based on compilation task parameter information. Each type of processor core can have at least one corresponding configuration factory class, which can be a derived subclass of the configuration base class (Configure Base class). This configuration factory class contains all members, including member functions and member variables, that handle the corresponding type of processor core configuration file, project file, and compilation task parameters. The configuration factory class performs deserialization on the compilation task parameters, configuration file, and project file. The constructor of the configuration base class instantiates member classes using a factory pattern based on the processor core type described by the compilation task parameters, generating the corresponding configuration factory class object. The processor core configuration file is a file used to describe the cross-toolchain information for that processor core, such as a YAML file. Cross-compilation is performed on machine A and runs on machine B. The two machines can have different machine instructions. The toolchain generally consists of a compiler, linker, interpreter, debugger, etc. For example, in embedded development, there is a distinction between the host machine and the target machine. The host machine is the computer that executes the compilation and linking of the embedded software, while the target machine is the hardware platform that runs the embedded software. Therefore, toolchain information includes the names of tools such as compilers, assemblers, linkers, disassemblers, and code conversion tools, as well as descriptions of related parameters (such as compilation parameters and linker scripts). A compiler is a program or tool that translates one language into another, such as translating a high-level language into a low-level language. A linker links one or more intermediate files generated by a compiler or assembler, along with libraries, into an executable file. Intermediate files are programs that include machine code and information available to the linker. A linker script is a reference file used during program linking; its main purpose is to describe how to map sections from input files to output files and control the storage layout of the output files. The specific functional principles of each tool in the cross-compilation toolchain will not be elaborated here.

[0068] The Factory pattern is a design pattern implemented in object-oriented languages. It belongs to the creational patterns and provides an optimal way to create objects. In the Factory pattern, the creation logic is not exposed to the client during object creation. Instead, a common interface is used to point to the newly created object. Typically, an interface for object creation is defined in the Factory pattern, allowing its subclasses to decide which factory class to instantiate. Based on this, different factory class objects can be instantiated for compilation and construction of different processor cores, thereby achieving independence and resource isolation between compilation tasks of different processor cores. The specific principles of the Factory pattern will not be elaborated here.

[0069] Step 2022: Based on the configuration factory class object, determine the parameter configuration class object corresponding to the processor core.

[0070] The parameter configuration class object is derived from the configuration factory class object, which calls its member functions to perform a parameter parsing process. This process obtains parameters such as toolchain information, project directory information, and source file information corresponding to the processor core. The obtained toolchain information, project directory information, and source file information are then encapsulated. In other words, a parameter configuration class object corresponding to a processor core encapsulates the toolchain information, project directory information, and source file information for that processor core, used in the subsequent compilation preparation stage to generate compilation task rule files. The toolchain information can be obtained by reading the processor core configuration file, and the project directory information and source file information can be obtained by reading the project files.

[0071] Step 2023: Based on the compilation task parameter information, determine the generation factory class object corresponding to the processor core.

[0072] The generator factory class object is an instantiated object based on the compilation task parameter information. Similar to the configuration factory class, each type of processor core can have a corresponding generator factory class. This generator factory class can be a derived subclass of the generator base class (Generator Base class). The generator factory class contains all member functions that generate the corresponding processor core project directory and the corresponding compilation task rule file (such as a script file under an automated build tool) according to the configuration parameters encapsulated in the parameter configuration class object. The member constructor of the generator base class instantiates its member classes using the factory pattern according to the type of processor core described in the corresponding compilation task parameters, resulting in the generator factory class object.

[0073] Steps 2022 and 2023 can be performed in any order.

[0074] Step 2024: Based on the generation factory class object and parameter configuration class object, generate the compilation task rule file corresponding to the processor core.

[0075] Since the generator factory class contains all member functions that generate the corresponding processor core project directory and the corresponding compilation task rule file (such as a script file under an automated build tool) based on the configuration parameters encapsulated in the parameter configuration class object, after determining the generator factory class object, its members can be accessed based on the generator factory class object to realize the creation of the project directory corresponding to the processor core and the generation of the corresponding compilation task rule file in the project directory.

[0076] For example, by accessing the member function of the generation factory class object to generate the project directory, the member function can create the project directory corresponding to the processor core based on the project directory information encapsulated in the parameter configuration class object. Then, based on the project directory information and source file information corresponding to the processor core, symbolic links to the corresponding source files are created in this project directory. Finally, based on the configuration parameters and template files encapsulated in the parameter configuration class object, the corresponding compilation task rule file is generated in this project directory. For instance, the template file is a template generation file based on any implementable template engine rule, achieving separation of execution content and rules. The template engine populates the template file with the configuration parameters encapsulated in the parameter configuration class object, generating the corresponding compilation task rule file.

[0077] This disclosure, based on the object-oriented factory pattern, automates the generation of compilation task rule files corresponding to the compilation tasks of processor cores. It also enables independent processing and resource isolation of compilation tasks for multiple processor cores, ensuring that compilation tasks of different processor cores do not interfere with each other. This effectively solves the problem of cumbersome multiple Makefile call logics in existing multi-core system compilation tasks, further improving compilation efficiency. Furthermore, the object-oriented factory pattern of this disclosure provides better scalability for compilation. When users want to compile and build new types of processor cores, they can easily derive factory classes corresponding to the new types of processor cores from various factory base classes to support compilation tasks for these new types of processor cores, greatly facilitating the work of relevant personnel and improving work efficiency.

[0078] In one optional example, Figure 4 This is a flowchart illustrating step 2021 provided in an exemplary embodiment of this disclosure. In this example, step 2021, determining the configuration factory class object corresponding to the processor core based on compilation task parameter information, includes:

[0079] Step 20211a: Determine the type of processor core based on the compilation task parameter information.

[0080] The processor core type refers to the processor core architecture type. In a multi-core system, if all processor cores have the same architecture, it is called homogeneous multi-core; if multiple processor cores have different architectures, it is called heterogeneous multi-core. The compilation task parameter information includes compilation task parameters corresponding to at least one processor core. The compilation task parameters corresponding to a processor core include the type and number of that processor core, as well as other relevant information. Therefore, the type corresponding to each processor core can be determined based on the compilation task parameter information, as well as the number and other relevant information corresponding to each processor core.

[0081] Step 20212a: Based on the type of the processor core, determine the configuration factory class object corresponding to the processor core.

[0082] For heterogeneous multi-core processors, since the processor core types differ, the corresponding factory class objects can be determined based on the processor core type. These include configuration factory class objects, generation factory class objects, and compilation factory class objects. Alternatively, the type and number can be combined to determine the corresponding configuration factory class object, generation factory class object, and compilation factory class object, depending on actual needs. For example, for compilation tasks of two processor cores belonging to type A and type B respectively, at least one set of factory classes A (configuration factory class A, generation factory class A, compilation factory class A, etc.) corresponding to type A is pre-created to support the compilation and construction of type A, and at least one set of factory classes B corresponding to type B is also created to support the compilation and construction of type B. When compilation and construction are required, for the compilation task of the processor core of type A, a factory class A can be selected by default from the at least one set of factory classes A based on its corresponding type A, or a factory class A can be determined by combining type A and a user-specified number to determine the corresponding factory class object. The same logic applies to type B and type A, and will not be elaborated further here.

[0083] In one optional example, Figure 5 This is a flowchart illustrating step 2021 provided in another exemplary embodiment of this disclosure. In this example, step 2021, determining the configuration factory class object corresponding to the processor core based on compilation task parameter information, includes:

[0084] Step 20211b: Based on the compilation task parameter information, determine the type and number of the processor core.

[0085] Step 20212b: Based on the type and number of the processor core, determine the configuration factory class object corresponding to the processor core.

[0086] For homogeneous multi-core processors, multiple factory classes can be identical. Therefore, the type and number can be combined to determine which factory class to instantiate and which factory class object to use. For example, eight configuration factory classes C supporting the same type of processor core (e.g., type C) and eight corresponding generation factory classes C and eight compilation factory classes C can be created. This means that each processor core's compilation task will have a set of factory classes (including configuration, generation, and compilation factory classes) to support its implementation. The eight factory classes C are distinguished by numbers (e.g., 1-8). When a user needs to compile and build, for a compilation task of a processor core of type C, the user can select which factory class C to instantiate based on the number. For example, the user can choose number 2. When there are multiple compilation tasks for processor cores of type C, a number can be assigned to each processor core. The specific settings can be configured according to actual needs.

[0087] In an optional example, the same set of factory classes can be further subdivided into different processing methods according to actual needs, to meet different compilation requirements of users for the same processor core. The specific subdivision can be set according to actual needs, and this disclosure does not limit it. For example, for the same set of factory classes, different compilation task rule files can be generated through different member functions, thereby generating different target files. By implementing a more granular processing method, the user experience can be effectively improved.

[0088] In one optional example, Figure 6 This is a flowchart illustrating step 203 provided in an exemplary embodiment of this disclosure. In this example, step 203, based on the compilation class object corresponding to the processor core, runs the compilation task rule file to generate intermediate files corresponding to the processor core, including:

[0089] Step 2031: Based on the type and number of the processor core, determine the compiler factory class object corresponding to the processor core.

[0090] Among them, the compiler factory class object is a compiler class object instantiated based on the factory pattern. Similar to the configuration factory class object, each type of processor core can create at least one corresponding compiler factory class. The compiler factory class can be a derived subclass of the compiler base class (Compiler Base class). The compiler factory class contains all member functions that describe the compilation and building behavior of the corresponding type of processor core. The member constructor of the compiler base class instantiates the member class in the factory pattern according to the processor core type and number described by the compilation task parameters, and determines the compiler factory class object corresponding to the processor core.

[0091] Step 2032: Based on the compilation factory class object corresponding to the processor core, run the compilation task rule file to generate the intermediate file corresponding to the processor core.

[0092] For example, based on the compiler factory class object corresponding to the processor core, the utility function is first executed to run the compilation task rule file and generate the corresponding intermediate files.

[0093] This disclosure uses a compiler factory class object instantiated based on the factory pattern to run the compilation task rule file and generate the corresponding intermediate file, thereby realizing the independent processing and resource isolation of the compilation tasks of each processor core during the compilation stage.

[0094] In one optional example, Figure 7 This is a flowchart illustrating step 2022 provided in an exemplary embodiment of this disclosure. In this example, step 2022, determining the parameter configuration class object corresponding to the processor core based on the configuration factory class object, includes:

[0095] Step 20221: Based on the configuration factory class object, obtain the toolchain information, project directory information, and source file information corresponding to the processor core.

[0096] The toolchain information corresponding to the processor core includes the names and parameter descriptions of tools such as compilers, assemblers, linkers, disassemblers, and code conversion tools, including descriptions of compilation parameters and linker scripts. Project directory information includes information about the project directory that needs to be created under the test case simulation target to execute the compilation task. Source file information refers to information about the source program files to be compiled, such as source file names and locations. The toolchain information can be obtained by reading the configuration file corresponding to the processor core through a configuration factory class object. The configuration file describes the cross-toolchain information for that processor core; for example, it can be a YAML configuration file. Configuration files are pre-prepared for different processor cores, with different configuration files corresponding to different types of processor cores. YAML is a recursive abbreviation for "YAML Ain't a Markup Language." When developing this language, YAML actually means "Yet Another Markup Language." YAML's syntax is similar to other high-level languages ​​and can easily express data formats such as lists, hash tables, and scalars. It features whitespace indentation and a strong reliance on appearance, making it particularly suitable for expressing or editing data structures, various configuration files, debugging content, and document outlines (e.g., many email header formats are very similar to YAML). YAML configuration files have the .yml extension, such as runoob.yml. Specific settings depend on actual needs. Project directory information and source file information can be obtained by reading the project file through a configuration factory class object. The project file describes the project information for the target architecture platform of the multi-core system or subsystem to be built; it can be a YAML project file. The project file includes macro information, static library information, header file information, startup assembly function information, etc. Users need to prepare the project file according to their actual compilation and build project requirements.

[0097] Step 20222: Encapsulate the toolchain information, project directory information, and source file information corresponding to the processor core to obtain the parameter configuration class object corresponding to the processor core.

[0098] Specifically, the toolchain information, project directory information, and source file information corresponding to the processor core are encapsulated into parameter configuration class objects, which facilitate subsequent process calls and are used to generate compilation task rule files.

[0099] In one optional example, Figure 8 This is a flowchart illustrating step 2024 provided in an exemplary embodiment of this disclosure. In this example, step 2024, based on the generation factory class object and the parameter configuration class object, generates the compilation task rule file corresponding to the processor core, including:

[0100] Step 20241: Based on the generator factory class object, create the project directory corresponding to the processor core.

[0101] Specifically, the generator factory object calls its member function for creating project directories, adding a separate project directory to the directory where the compilation task for that processor core is executed, based on the processor core type and number. For example, in a verification scenario, a separate project directory is added under the test case simulation directory.

[0102] For example, the code for creating the project directory is as follows:

[0103] [lisan@login03 HVBS]$cd RI5CY_0

[0104] BOOTFILES DIR3 obj SConscript.RI5CY_0tc.c

[0105] Step 20242: Based on the project directory information and source file information corresponding to the processor core, create symbolic links to the source files corresponding to the processor core in the project directory.

[0106] Symbolic links are a type of soft link, a special type of file that contains a reference to another file or directory, either in absolute or relative path form. Operations on symbolic links are transparent; programs reading and writing to symbolic link files behave as if they are directly operating on the target file (the source file in this disclosure). Some programs that require special handling of symbolic links (such as backup programs) may recognize and directly operate on them. A symbolic link file contains only a text string, which the operating system interprets as a path to another file (the target file) or directory. It is an independent file, and its existence does not depend on the target file. Deleting a symbolic link does not affect the target file it points to. If the target file is moved, renamed, or deleted, any symbolic links pointing to it will still exist, but they will point to a file that no longer exists. The specific principles of symbolic link creation are not elaborated upon here.

[0107] Step 20243: Based on the parameter configuration class object and the corresponding template file, generate the compilation task rule file corresponding to the processor core in the project directory.

[0108] The template file is a template generation file based on any implementable template engine rule, achieving separation of execution content and rules. In this disclosure, it is a template used to generate compilation task rule files. It automates the generation process of compilation task rule files for different processor cores by parameterizing the content that needs to change according to different processor cores. This allows for the automatic generation of compilation task rule files for different processor cores through the combination of parameters and templates. The parameters are provided through parameter configuration class objects. By filling the template file with parameters according to preset filling rules, the corresponding compilation task rule file can be generated. Specifically, the template engine can fill the template file with configuration parameters encapsulated in the parameter configuration class object. The template engine was created to separate the user interface from business data (content), and it can generate documents in a specific format.

[0109] For example, after creating symbolic links to source files in the project directory, the template engine is started, and the compilation task rule files corresponding to each source file are generated in the project directory according to the parameters encapsulated in the parameter configuration class object.

[0110] This disclosure combines parameter configuration class objects with template files to effectively automate the generation of compilation task rule files, greatly reducing the development workload of relevant personnel and further improving compilation efficiency.

[0111] Figure 9 This is a flowchart illustrating a compilation and construction method provided in another exemplary embodiment of this disclosure.

[0112] In an optional example, step 204, which generates the target file corresponding to the processor core based on the intermediate file corresponding to the processor core, includes:

[0113] Step 2041: Perform a linking operation on the intermediate files to obtain the executable file corresponding to the processor core.

[0114] Specifically, the intermediate files can be linked by calling the linker in the compilation toolchain through a compiler class object or a compiler factory class object to obtain the corresponding executable file. The specific principles of the linking operation will not be elaborated here.

[0115] Step 2042: Decompile the executable file to obtain the corresponding disassembled file.

[0116] Specifically, the executable file can be decompiled by calling the disassembler in the compiler toolchain through a compiler class object or a compiler factory class object, and the corresponding disassembled file can be obtained. The specific principle will not be elaborated here.

[0117] Step 2043: Perform file analysis on the executable file to obtain the corresponding binary code file and / or hexadecimal code file.

[0118] Specifically, the executable file can be analyzed by calling the file analysis tool in the compiler toolchain through the compiler class object or compiler factory class object to obtain the corresponding binary code file and / or hexadecimal code file. The specific principle will not be elaborated here.

[0119] Step 2044: Use at least one of the following as the target file: executable file, disassembled file, binary code file, and hexadecimal code file.

[0120] For example, executable files, disassembled files, binary code files, and hexadecimal code files can be used as target files, and the specific settings can be configured according to actual needs.

[0121] In an optional example, for the implementation of the compilation and build method of this disclosure, in a specific application scenario, before step 201, it is also necessary to create a symbolic link of the compilation task rule file of the compilation and build device of this disclosure in the directory where compilation is performed (such as the simulation tool directory) according to the requirements of the automated build tool, so as to perform asynchronous path compilation organization work and realize the independent processing and resource isolation between the compilation tasks of each processor core of the multi-core heterogeneous system. For different automated build tools, the generated compilation task rule file may include one-level or multi-level rule files, and there is no specific limitation.

[0122] In one optional example, the methods disclosed herein also include:

[0123] Step 301: Receive the user's factory class registration request. The factory class registration request includes information on the factory classes that the user wants to add to support the compilation and construction of new types of processor cores.

[0124] When users need to add support for compiling and building new types of processor cores, they can prepare the relevant files or data according to the requirements for that new type of processor core mentioned above. For example, this includes creating a set of factory classes (configuration factory class, generation factory class, and compilation factory class) for that new type. These factory classes can be derived from corresponding base classes, thus reducing the user's development workload. Other examples include preparing configuration files for that new type to describe the cross-compilation toolchain information, template files, etc., which can be customized according to actual needs. Once prepared, users can register the support for that new type through the terminal or other means to enable the compilation and build system to support the compilation tasks for that new type of processor core. The factory class registration request can include the content that the user needs to prepare as mentioned above, but is not limited to factory class information; the specific settings can be customized according to actual needs.

[0125] Step 302: In response to the factory class registration request, register the user's factory class information.

[0126] Upon receiving a user's factory class registration request, the system can respond to the user's request and register the information for each of the user's factory classes. For example, it can add the configuration factory class, generation factory class, and compilation factory class to their respective locations and store the configuration file in the corresponding location, enabling subsequent applications to implement the functionality described above. Specific registration operations can be configured according to actual needs, and this disclosure does not impose any limitations.

[0127] This disclosure improves the scalability of compilation and building by providing users with new type registration functionality, further facilitating the work of developers and improving their efficiency.

[0128] In one optional example, step 201, determining the compilation task parameter information, includes:

[0129] Step 2011: Obtain the list of compilation task parameters in string format.

[0130] Specifically, the list of compilation task parameters prepared by the user can be a dictionary data structure, constructed in dictionary form by processor core, such as the dictionary form of any automated build tool. The compilation task parameters for each specified processor core are encapsulated into an independent dictionary data structure, which is input to the compilation and build device as a command-line parameter through the automated build tool script. When input as a command-line parameter, the dictionary data structure is passed to the compilation and build device in string form. The dictionary data structures for multiple core compilation tasks are independent of each other, and the compilation and build device obtains the list of compilation task parameters in string form.

[0131] Optionally, after obtaining the list of compilation task parameters, the compilation and build device needs to create a symbolic link to the compilation task rule file in the simulation tool directory according to the requirements of the automated build tool so that asynchronous path compilation and build work can be performed subsequently.

[0132] Step 2012: Deserialize the compilation task parameter list to obtain a dictionary data structure corresponding to at least one processor core, which will serve as the compilation task parameter information.

[0133] Deserialization involves converting the list of compilation task parameters in string form back into a dictionary data structure.

[0134] For example, when the build unit receives a list of compilation task parameters in string form from an external source, it first initiates deserialization of the string information, converting the list of compilation task parameters back into a dictionary data structure. Multiple compilation tasks (one for each processor core) will exist as a list, with each list member being a dictionary data structure describing the compilation task parameters for each processor core. The build unit then sequentially extracts each dictionary from the list and proceeds to the next processing step. Each compilation task corresponds to an independent object, thus achieving resource isolation between the working environments of different compilation tasks.

[0135] Any of the embodiments or optional examples described above can be implemented individually or in combination in any manner without conflict, and this disclosure does not limit them.

[0136] In one optional example, Figure 10 This is a flowchart illustrating a compilation and build method provided in another exemplary embodiment of this disclosure. In this example, a simulation case of a verification scenario is used as an example. The compilation and build device executing the compilation and build method of this disclosure is abbreviated as HVBS (Horizon Verification Build System). The compilation and build method specifically includes:

[0137] 1. Prepare the HVBS compilation task parameter list.

[0138] 2. Create a symbolic link to the HVBS compilation task rule file in the simulation case directory.

[0139] 3. Pass a list of compilation task parameters in string format to HVBS.

[0140] 4. HVBS performs deserialization on the list of compilation task parameters in string form.

[0141] 5. Obtain processor core information from a set of compilation task parameters.

[0142] The processor core information can be set as a type, or a type and number, according to actual needs. A set of compilation task parameters refers to the parameters corresponding to a compilation task, that is, the parameters corresponding to a processor core.

[0143] 6. Determine the configuration factory class object based on the processor core information.

[0144] 7. Obtain compilation toolchain information by reading configuration files based on configuration factory class objects.

[0145] For example, configuration files are structured in YAML format. HVBS uses YAML-based config files to define compilation-related configurations for specific processor architectures, leveraging YAML's anchor points and aliases to achieve information inheritance. In the config file, tag nodes serve as the basic unit for organizing compilation parameter groups. Tag nodes can contain information such as toolchains, library directories, macro definitions, compilation parameters, linker scripts, and assembly startup files. The config file has a default BASE (no need to define) tag, allowing users to add new tag containers. Newly defined tags can inherit information from any level of node containers defined in the config table. Configuration files are semi-fixed configurations used to add new processor architectures or expand compilation information for existing architectures. All configuration files can be located in the HVBS / config directory, and the specific settings can be configured according to actual needs.

[0146] 8. Obtain project directory information and source file information by reading the project file based on the configuration factory class object.

[0147] For example, the project file is structured in YAML format. It's a user-defined YAML configuration table containing project information, such as source files, header function files, assembly startup functions, static libraries, and macro definitions. The project file can be passed to HVBS via command-line parameters. Similarly, users can utilize the anchor point feature in the YAML format to inherit certain configuration information within the project file.

[0148] 9. Based on the configuration factory class object, the obtained compilation toolchain information, project directory information and source file information are encapsulated into parameter configuration class objects.

[0149] 10. Are there any other compilation tasks? If yes, return to step 5 and continue processing the next compilation task until all compilation tasks in the compilation task parameter list are completed; otherwise, continue to step 11.

[0150] 11. Determine the factory class object to be generated based on the processor core information.

[0151] Specifically, for each compilation task, the corresponding generation factory class object is determined based on the processor core information of that compilation task.

[0152] 12. Create a project directory named "Processor Core Architecture_Number" based on the generator factory class object.

[0153] 13. Based on the generator factory class object, create symbolic links to the source files in the project directory according to the source file information and project directory information.

[0154] 14. Based on the configuration parameters encapsulated by the parameter configuration class object, the template engine is started in the project directory to generate compilation task rule files.

[0155] 15. Are there any other compilation tasks? If yes, return to step 11 to continue processing the next compilation task; otherwise, continue to step 16.

[0156] 16. Determine the compilation factory class object based on the processor core information.

[0157] This step also involves determining the compiler factory class object based on the processor core information for each compilation task.

[0158] 17. Based on the compiler factory class object, start the corresponding compilation task rule file in the corresponding project directory to generate the corresponding intermediate files.

[0159] 18. Perform linking operations based on the compiler factory class object to generate the corresponding executable file.

[0160] 19. Generate disassembled files by calling a disassembler based on a compiler factory class object.

[0161] 20. Generate the corresponding binary or hexadecimal file by calling the file analysis tool based on the compiler factory class object.

[0162] 21. Are there any other compilation tasks? If yes, return to step 16 to continue to the next compilation task; otherwise, continue to step 22.

[0163] 22. End HVBS.

[0164] For the specific operation of each step 1-22 above, please refer to the aforementioned content, and will not be repeated here.

[0165] Optionally, the workflow of the above steps can be summarized into three stages: parameter resolution, compilation preparation, and compilation operation. The parameter resolution stage may include the processing stages of steps 5-9 above, the compilation preparation stage may include the processing stages of steps 11-14 above, and the compilation operation stage may include the processing stages of steps 16-20. For multiple compilation tasks on a multi-core system, each stage needs to process all compilation tasks before proceeding to the next stage; the specific settings can be configured according to actual needs.

[0166] The HVBS disclosed herein supports joint compilation of multiple architectures and multiple cores during simulation. Each set of param parameter dictionary strings passed to HVBS represents a compilation task of a core (i.e., a processor core). The configuration factory class, generation factory class, and compilation factory class of each compilation task are independent objects, thereby achieving isolation of compilation task flow and resources. At the same time, since each compilation task can independently specify project files to compile and build different source files, and in terms of processing the compilation results, each core's compilation task is located in an independent project folder, HVBS can adapt to the needs of various compilation tasks such as heterogeneous multi-core, homogeneous multi-core, AMP (asymmetric multiprocessing), and SMP (symmetric multiprocessing).

[0167] This disclosed HVBS is based on object-oriented inheritance. The various classes used are constructed using the object-oriented factory pattern. Each class can derive different working subclasses based on different architectures, thus allowing for the definition of independent compilation processes for different architectures. Each class can define a base class. Taking the compiler class as an example, there is a base class `CompilerBase`. The class declares the static member `_pool`. In the class constructor, the prototype of the subclass (e.g., the compiler factory class) is stored in the static member list of the parent class (compiler base class) during the initial construction. The correct subclass object can be determined using information related to the processor core (architecture, type, number, etc.). If the subclass object cannot be determined using the processor core information, the parent class can be used by default to construct the object. The specific settings can be configured according to actual needs. Based on this, users can utilize the inheritance feature to register or add their own classes corresponding to their respective processor core types in each module and rewrite the corresponding constructors. Except for functions already called, the function names can be renamed and redefined. The initial instantiation of the new extended class can be automatically completed by HVBS during invocation. Users need to pay attention to the fact that the newly defined class should follow the naming conventions of the existing subclasses.

[0168] For example, the overall software solution of HVBS disclosed herein can be implemented based on any implementable language. For instance, it can be developed based on an automated build tool in any language and use any implementable template engine to automatically generate specific compilation task rule files. The configuration tables such as project files and configuration files adopt YAML tables. The HVBS build tool disclosed herein does not depend on a specific operating system and can be set according to actual needs. For example, it can be developed based on a Linux system or a Windows system, without any specific limitation.

[0169] Any of the compilation and build methods provided in this disclosure can be executed by any suitable device with data processing capabilities, including but not limited to: terminal devices and servers. Alternatively, any of the compilation and build methods provided in this disclosure can be executed by a processor, such as by a processor executing any of the compilation and build methods mentioned in this disclosure by calling corresponding instructions stored in memory. Further details will not be elaborated below.

[0170] Exemplary device

[0171] Figure 11 This is a schematic diagram of a compilation and build apparatus provided in an exemplary embodiment of this disclosure. The apparatus of this embodiment can be used to implement corresponding method embodiments of this disclosure, such as… Figure 11 The device shown includes: a first determining module 501, a first processing module 502, a second processing module 503, and a third processing module 504.

[0172] The first determining module 501 is used to determine compilation task parameter information, which includes compilation task parameters corresponding to at least one processor core; the first processing module 502 is used to generate a compilation task rule file corresponding to the processor core based on the compilation task parameter information determined by the first determining module 501; the second processing module 503 is used to run the compilation task rule file generated by the first processing module 502 based on the compilation class object corresponding to the processor core, and generate an intermediate file corresponding to the processor core; the third processing module 504 is used to generate an object file corresponding to the processor core based on the intermediate file corresponding to the processor core generated by the second processing module 503.

[0173] In one optional example, Figure 12 This is a schematic diagram of the structure of a first processing module 502 provided in an exemplary embodiment of the present disclosure. In this example, the first processing module 502 includes: a first determining unit 5021, a second determining unit 5022, a third determining unit 5023, and a first generating unit 5024.

[0174] The first determining unit 5021 is used to determine the configuration factory class object corresponding to the processor core based on the compilation task parameter information determined by the first determining module 501; the second determining unit 5022 is used to determine the parameter configuration class object corresponding to the processor core based on the configuration factory class object determined by the first determining unit 5021; the third determining unit 5023 is used to determine the generation factory class object corresponding to the processor core based on the compilation task parameter information determined by the first determining module 501; and the first generation unit 5024 is used to generate the compilation task rule file corresponding to the processor core based on the generation factory class object determined by the third determining unit 5023 and the parameter configuration class object determined by the second determining unit 5022.

[0175] In one optional example, Figure 13 This is a schematic diagram of the structure of a first determining unit 5021 provided in an exemplary embodiment of the present disclosure. In this example, the first determining unit 5021 includes: a first determining subunit 50211a and a second determining subunit 50212a.

[0176] The first determining subunit 50211a is used to determine the type of the processor core based on the compilation task parameter information; the second determining subunit 50212a is used to determine the configuration factory class object corresponding to the processor core based on the type of the processor core.

[0177] In one optional example, Figure 14 This is a schematic diagram of the structure of a first determining unit 5021 provided in another exemplary embodiment of the present disclosure. In this example, the first determining unit 5021 includes a third determining subunit 50211b and a fourth determining subunit 50212b.

[0178] The third determining subunit 50211b is used to determine the type and number of the processor core based on the compilation task parameter information; the fourth determining subunit 50212b is used to determine the configuration factory class object corresponding to the processor core based on the type and number of the processor core.

[0179] In one optional example, Figure 15 This is a schematic diagram of the structure of the second processing module 503 provided in an exemplary embodiment of the present disclosure. In this example, the second processing module 503 includes: a first processing unit 5031 and a second processing unit 5032.

[0180] The first processing unit 5031 is used to determine the compiler factory class object corresponding to the processor core based on the type and number of the processor core; the second processing unit 5032 is used to run the compilation task rule file based on the compiler factory class object corresponding to the processor core determined by the first processing unit 5031 to generate the intermediate file corresponding to the processor core.

[0181] In one optional example, Figure 16 This is a schematic diagram of the structure of the second determining unit 5022 provided in an exemplary embodiment of the present disclosure. In this example, the second determining unit 5022 includes: a first acquiring subunit 50221 and an encapsulation subunit 50222.

[0182] The first acquisition subunit 50221 is used to acquire the toolchain information, project directory information and source file information corresponding to the processor core based on the configuration factory class object; the encapsulation subunit 50222 is used to encapsulate the toolchain information, project directory information and source file information corresponding to the processor core acquired by the first acquisition subunit 50221 to obtain the parameter configuration class object corresponding to the processor core.

[0183] In one optional example, Figure 17 This is a schematic diagram of the structure of the first generation unit 5024 provided in an exemplary embodiment of the present disclosure. In this example, the first generation unit 5024 includes: a first creation subunit 50241, a second creation subunit 50242, and a generation subunit 50243.

[0184] The first creation subunit 50241 is used to create the project directory corresponding to the processor core based on the generation factory class object; the second creation subunit 50242 is used to create symbolic links to the source files corresponding to the processor core in the project directory based on the project directory information and source file information corresponding to the processor core; the generation subunit 50243 is used to generate the compilation task rule file corresponding to the processor core in the project directory according to the parameter configuration class object and the corresponding template file.

[0185] In one optional example, Figure 18 This is a schematic diagram of the structure of a third processing module 504 provided in an exemplary embodiment of this disclosure. In this example, the third processing module 504 includes: a linking unit 5041, a decompilation unit 5042, an analysis unit 5043, and a third processing unit 5044.

[0186] Linking unit 5041 is used to link intermediate files to obtain an executable file corresponding to the processor core; decompilation unit 5042 is used to decompile the executable file to obtain a corresponding disassembled file; analysis unit 5043 is used to perform file analysis on the executable file to obtain a corresponding binary code file and / or hexadecimal code file; third processing unit 5044 is used to use at least one of the executable file, disassembled file, binary code file and hexadecimal code file as a target file.

[0187] In one optional example, Figure 19This is a schematic diagram of the structure of a compilation and build apparatus provided in another exemplary embodiment of the present disclosure. In this example, the apparatus of the present disclosure further includes: a receiving module 505 and a fourth processing module 506.

[0188] The receiving module 505 is used to receive the user's factory class registration request, which includes information on the various factory classes to be added by the user to support the compilation and construction of new types of processor cores; the fourth processing module 506 is used to register the user's various factory class information in response to the factory class registration request.

[0189] In one optional example, Figure 20 This is a schematic diagram of the structure of a first determining module 501 provided in an exemplary embodiment of the present disclosure. In this example, the first determining module 501 includes: an acquisition unit 5011 and a fourth processing unit 5012.

[0190] The acquisition unit 5011 is used to acquire a list of compilation task parameters in string form; the fourth processing unit 5012 is used to deserialize the list of compilation task parameters to obtain a dictionary data structure corresponding to at least one processor core, which serves as the compilation task parameter information.

[0191] In one alternative example, the compilation and build apparatus of this disclosure can also be divided into functional modules in other ways. Figure 21 This is a schematic diagram of the structure of a compilation and build apparatus provided in another exemplary embodiment of this disclosure. In this example, the compilation and build apparatus of this disclosure may include a configuration module, a generation module, and a compilation module. The configuration module is used to execute the process of the parameter parsing phase and generate a parameter configuration class object; the generation module is used to execute the process of the compilation preparation phase and generate a compilation task rule file; and the compilation module is used to execute the process of the compilation operation phase and generate an object file. The specific operations of each module are described above and will not be repeated here.

[0192] In an optional example, taking a chip verification scenario as an example, the HVBS (Horizon VerificationBuild System) disclosed herein may functionally include a configuration module (composed of a series of classes such as the Configuration Base class and its derived subclasses), a generation module (composed of a series of Python classes such as the Generator Base class and its derived subclasses), a compilation module (composed of a series of Python classes such as the Compiler Base class and its derived subclasses), configuration files (Config YAML), project files (Project YAML), module library files (i.e., template files), and a shell program containing compilation task rule files. Each functional module is further developed using an automated build tool based on any implementable language, and a template engine is used to automatically generate specific compilation task rule files. The configuration tables such as project files and configuration files are in YAML format. The HVBS in this example also includes a shell program containing compilation task rule files. The shell program is the top-level file used to organize the compilation task workflow. According to the requirements of the automated build tool for performing off-site compilation of the project, symbolic links to the compilation task rule files need to be generated in the working directory of the simulation test cases. The compilation task rule file generated by the automated build tool is used to generate corresponding intermediate files. Then, the target files (.bin, .hex, .as, .so) are obtained through linking, disassembly, and file analysis. The target files are used for verification of the chip system or subsystem.

[0193] Exemplary electronic devices

[0194] This disclosure also provides an electronic device, including: a memory for storing computer programs;

[0195] A processor is configured to execute a computer program stored in the memory, wherein, when the computer program is executed, it implements the method described in any of the above embodiments of the present disclosure.

[0196] Figure 22 This is a schematic diagram of an application embodiment of the electronic device disclosed herein. In this embodiment, the electronic device 10 includes one or more processors 11 and a memory 12.

[0197] The processor 11 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 10 to perform desired functions.

[0198] The memory 12 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 11 may execute the program instructions to implement the methods of the various embodiments of this disclosure described above and / or other desired functions. Various contents such as input signals, signal components, and noise components may also be stored in the computer-readable storage medium.

[0199] In one example, the electronic device 10 may also include an input device 13 and an output device 14, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0200] For example, the input device 13 may be the microphone or microphone array described above, used to capture the input signal of the sound source.

[0201] In addition, the input device 13 may also include, for example, a keyboard, a mouse, etc.

[0202] The output device 14 can output various information to the outside, including determined distance information, direction information, etc. The output device 14 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0203] Of course, for the sake of simplicity, Figure 22 Only some of the components of the electronic device 10 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 10 may include any other suitable components depending on the specific application.

[0204] Exemplary computer program products and computer-readable storage media

[0205] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps of the methods according to various embodiments of this disclosure as described in the "Exemplary Methods" section of this specification.

[0206] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0207] Furthermore, embodiments of this disclosure may also be computer-readable storage media having computer program instructions stored thereon, which, when executed by a processor, cause the processor to perform the steps in the methods according to various embodiments of this disclosure described in the "Exemplary Methods" section above.

[0208] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable 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.

[0209] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0210] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0211] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0212] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0213] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0214] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0215] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A compilation and build method, comprising: Determine compilation task parameter information, which includes compilation task parameters corresponding to at least one processor core; Using automated build tools, a compilation task rule file corresponding to the processor core is generated based on the compilation task parameter information; Based on the compilation class object corresponding to the processor core, the compilation task rule file is run to generate the intermediate file corresponding to the processor core. The compilation class object is an object that instantiates a pre-created compilation class according to the compilation task parameters. Based on the intermediate file corresponding to the processor core, the target file corresponding to the processor core is generated.

2. The method according to claim 1, wherein, The step of generating a compilation task rule file corresponding to the processor core based on the compilation task parameter information includes: Based on the compilation task parameter information, determine the configuration factory class object corresponding to the processor core; Based on the configuration factory class object, determine the parameter configuration class object corresponding to the processor core; Based on the compilation task parameter information, determine the generation factory class object corresponding to the processor core; Based on the generator factory class object and the parameter configuration class object, the compilation task rule file corresponding to the processor core is generated.

3. The method according to claim 2, wherein, The step of determining the configuration factory class object corresponding to the processor core based on the compilation task parameter information includes: Based on the compilation task parameter information, the type corresponding to the processor core is determined; Based on the type of the processor core, determine the configuration factory class object corresponding to the processor core.

4. The method according to claim 2, wherein, The step of determining the configuration factory class object corresponding to the processor core based on the compilation task parameter information includes: Based on the compilation task parameter information, the type and number corresponding to the processor core are determined; Based on the type and number corresponding to the processor core, determine the configuration factory class object corresponding to the processor core.

5. The method according to claim 4, wherein, The process of running the compilation task rule file based on the compilation class object corresponding to the processor core to generate intermediate files corresponding to the processor core includes: Based on the type and number corresponding to the processor core, the compiler factory class object corresponding to the processor core is determined. The compiler factory class object is a compiler class object instantiated based on the factory pattern. Based on the compiler factory class object corresponding to the processor core, the compiler task rule file is run to generate the intermediate file corresponding to the processor core.

6. The method according to claim 2, wherein, The step of determining the parameter configuration class object corresponding to the processor core based on the configuration factory class object includes: Based on the configuration factory class object, obtain the toolchain information, project directory information and source file information corresponding to the processor core; The toolchain information, project directory information, and source file information corresponding to the processor core are encapsulated to obtain the parameter configuration class object corresponding to the processor core.

7. The method according to claim 6, wherein, The step of generating the compilation task rule file corresponding to the processor core based on the generation factory class object and the parameter configuration class object includes: Based on the aforementioned generator factory class object, create the project directory corresponding to the processor core; Based on the project directory information and source file information corresponding to the processor core, create symbolic links to the source files corresponding to the processor core in the project directory; Based on the parameter configuration class object and the corresponding template file, the compilation task rule file corresponding to the processor core is generated in the project directory.

8. The method according to claim 1, wherein, The step of generating the target file corresponding to the processor core based on the intermediate file corresponding to the processor core includes: The intermediate files are linked to obtain the executable file corresponding to the processor core. The executable file is decompiled to obtain the corresponding disassembled file; Perform file analysis on the executable file to obtain the corresponding binary code file and / or hexadecimal code file; The target file is at least one of the executable file, the disassembled file, the binary code file, and the hexadecimal code file.

9. The method according to claim 1, further comprising: Receive a user's factory class registration request, the factory class registration request including information on the factory classes to be added by the user for compiling and building to support new types of processor cores; In response to the factory class registration request, the user's factory class information is registered.

10. The method according to any one of claims 1-9, wherein, The determination of compilation task parameter information includes: Get the list of compilation task parameters in string format; The compilation task parameter list is deserialized to obtain a dictionary data structure corresponding to at least one of the processor cores, which serves as the compilation task parameter information.

11. A compilation and build apparatus, comprising: The first determining module is used to determine compilation task parameter information, which includes compilation task parameters corresponding to at least one processor core. The first processing module is used to generate a compilation task rule file corresponding to the processor core based on the compilation task parameter information. The second processing module is used to run the compilation task rule file based on the compilation class object corresponding to the processor core, and generate the intermediate file corresponding to the processor core. The compilation class object is an object that instantiates a pre-created compilation class according to the compilation task parameters. The third processing module is used to generate the target file corresponding to the processor core based on the intermediate file corresponding to the processor core.

12. A computer-readable storage medium storing a computer program for executing the compilation and construction method according to any one of claims 1-10.

13. An electronic device, the electronic device comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the compilation and construction method according to any one of claims 1-10.

Images