A lightweight Wasm runtime engine design method based on an embedded operating system

Abstract

The present application relates to a kind of based on the design method of lightweight Wasm runtime engine of embedded operating system, belong to embedded operating system technical field.The runtime engine of the present application includes: starting module, analysis module, AOT module and runtime module.The flow of the present application starts from command line input, first to command line parameter is parsed, according to whether trigger AOT compilation is shunted to different processing path, if parameter is specified to carry out AOT compilation, execute AOT compilation branch, if parameter is not specified to carry out AOT compilation, enter runtime execution flow.The method presented in the present application solves the problem that domestic embedded operating system supports Wasm runtime engine under the limited resource environment of embedded system, realizes the lightweight of Wasm runtime engine under the resource environment of embedded system.

Description

Technical Field

[0001] This invention belongs to the field of embedded operating system technology, specifically relating to a design method for a lightweight Wasm runtime engine based on an embedded operating system. Background Technology

[0002] Chinese patent "A method for optimizing Wasm bytecode, an execution method, a computer device, and a storage medium." The method involves reading and parsing the Wasm bytecode to obtain the Wasm module array; creating and filling linear memory based on the parsed Wasm module objects; executing the `start` function in the Wasm module objects and modifying the linear memory based on the execution result of the `start` function; replacing the corresponding data segments in the Wasm module objects with data from the modified linear memory; encoding the Wasm module after the data segment replacement and saving it as Wasm bytecode.

[0003] The Chinese patent "A method for optimizing Wasm bytecode, execution method, computer device, and storage medium" primarily addresses non-Web environments by providing a method for optimizing Wasm bytecode, with its main application areas focusing on the Internet of Things (IoT) and blockchain fields. Currently, no patent proposes a design and optimization method for the Wasm runtime engine for domestically developed embedded operating systems, specifically for resource-constrained embedded system environments.

[0004] The current embedded device ecosystem features diverse hardware architectures (such as ARM, RISC-V, and x86) and heterogeneous operating system environments (including Linux, RTOS, and various custom OSes), necessitating repeated adaptation development for different platforms. Traditional development models require developers to be deeply coupled with underlying hardware characteristics, resulting in low code reusability, high maintenance costs, and difficulty in achieving "develop once, deploy on multiple platforms." Furthermore, embedded development environments are typically complex, requiring multiple cross-compilations and debugging, causing significant inconvenience for developers. Existing development tools and processes are cumbersome and inefficient, failing to meet the demands of rapid development and deployment. This inefficient development process not only increases development costs but also extends the technology implementation cycle and reduces development efficiency. Therefore, it is necessary to introduce the Wasm runtime engine into the embedded real-time operating system environment to solve the cross-platform support problem for applications in resource-constrained embedded system environments. Summary of the Invention

[0005] (a) Technical problems to be solved The technical problem to be solved by this invention is how to provide a lightweight Wasm runtime engine design method based on an embedded operating system to solve the Wasm runtime engine support problem in resource-constrained embedded system environments.

[0006] (II) Technical Solution To address the aforementioned technical problems, this invention proposes a lightweight Wasm runtime engine design method based on an embedded operating system. The runtime engine includes: a startup module, a parsing module, an AOT module, and a runtime module. The startup module is responsible for initializing the Wasm runtime engine, building command-line tools and parsing command-line parameters, and deciding whether to hand over control to the AOT module or the runtime module based on command options. The AOT module is responsible for calling the parsing module to parse the Wasm program into an AST, then optimizing the intermediate code, and compiling the optimized Wasm program into machine code that can be executed directly in the host environment. The runtime module is responsible for calling the parsing module to parse the Wasm program into an AST, performing the preparatory work before running the Wasm program, and instantiating the Wasm runtime. The parsing module is responsible for importing the Wasm program to be executed based on the file path and configuration information in the command line parameters, and disassembling its program segments.

[0007] (III) Beneficial Effects This invention proposes a design method for a lightweight Wasm runtime engine based on an embedded operating system. The beneficial effects of this invention are as follows: (1) The method proposed in this invention solves the problem of domestic embedded operating systems supporting the Wasm runtime engine under resource-constrained embedded system environments.

[0008] (2) The solution provided by the present invention achieves lightweighting of the Wasm runtime engine for embedded system resource environments. Attached Figure Description

[0009] Figure 1 This is a diagram of the runtime module structure of the present invention; Figure 2 This is a flowchart of the runtime engine operation of the present invention. Detailed Implementation

[0010] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0011] To address the issue of Wasm runtime engine support in resource-constrained embedded system environments, this invention proposes a lightweight Wasm runtime engine that supports domestically developed embedded real-time operating systems.

[0012] The runtime engine of this invention has the following functional modules, including: a startup module, a parsing module, an AOT module, and a runtime module; (1) Startup module The startup module is responsible for initializing the Wasm runtime engine, primarily building command-line tools and parsing command-line arguments. This invention adopts a command-line tool programming paradigm based on Configure-Option to build a command-line argument parser and generate Configure.

[0013] The startup module parses the command-line arguments, maps the argument values ​​to the corresponding options, and verifies the validity of the arguments.

[0014] After completing the initialization process, the startup module will decide whether to hand over control to the AOT module or the runtime module based on the command options.

[0015] (2) Parsing module The parsing module is responsible for importing the Wasm program to be executed based on the file path and configuration information in the command line parameters, and disassembling its program segments.

[0016] If it is a regular Wasm program (i.e., it does not contain machine code compiled by AOT), the parsing module will convert it into an internally used data structure AST (Abstract Syntax Tree). Each node in the abstract syntax tree represents a syntax structure in the Wasm program for subsequent execution.

[0017] Otherwise, it means that the Wasm program already contains machine code compiled by AOT, and the parsing module will modify the relevant options of Configure to simplify the generation of AST.

[0018] (3) AOT module The AOT module will call the parsing module to parse the Wasm program into an AST, then perform intermediate code optimization, and compile the optimized Wasm program into machine code that can be executed directly in the host environment.

[0019] The AOT module first adds AOT options, such as optimization level, to the existing Configure. Then, the AOT module calls the parsing module to parse the Wasm program into an AST based on the Configure.

[0020] AOT will then perform intermediate code optimization and compile the optimized intermediate code directly into machine code that can be executed directly in the host environment. Details will not be elaborated here; please refer to the technical roadmap for more information.

[0021] Finally, the AOT module will copy the Wasm program content to the output file address according to the configuration options, and place the generated machine code into the Custom Section of the target Wasm program according to the Wasm Spec, ensuring that the Wasm runtime engine can correctly recognize and load the AOT-compiled program.

[0022] (4) Runtime module The runtime module is mainly responsible for calling the parsing module to parse the Wasm program into an AST, performing preparatory work before running the Wasm program, and instantiating the Wasm runtime.

[0023] Similar to the AOT module, the runtime module adds runtime options to the existing Configure, such as resource limits and registration of WASI interface functions. Afterward, the runtime module calls the parsing module to parse the Wasm program based on the Configure, generating the Abstract Syntax Tree (AST) of its internal data structures.

[0024] Afterwards, the runtime module defines a Wasm runtime object and loads the Wasm program, which has been parsed into an AST, into the sandbox. Then, it calls the Wasm runtime object's verifier to perform static checks before runtime, mainly verifying: whether the module structure is complete, whether the definitions of imports, exports, and segments conform to the Wasm Spec, whether the control flow structure is correct, and whether there are any illegal control jumps, etc.

[0025] After the check is complete, the runtime module will instantiate a Wasm runtime object and transfer control to the entry function of the Wasm program within the sandbox. The Wasm program will then execute specific instructions through the Wasm runtime's executor.

[0026] These core modules are highly decoupled and work together to ensure that the Wasm program can run correctly and compliantly.

[0027] The functional execution flow of this invention takes command-line driving as the entry point and revolves around two core branches: AOT compilation and runtime execution. The specific flow is as follows: S1, Input and Parameter Analysis The process begins with command-line input. First, the command-line parameters are parsed, and then the process is routed to different processing paths depending on whether AOT compilation is triggered. If the parameter specifies AOT compilation, the AOT compilation branch is executed. If the parameter does not specify AOT compilation, the runtime execution process is entered.

[0028] S2 and AOT compilation branches When the parameter is specified as "AOT compilation", perform the following steps: S21, AOT option added: Load AOT compilation-specific configurations (such as optimization level, target architecture, etc.).

[0029] S22. Bytecode parsing: Read the input bytecode file and convert it into an internally processable intermediate representation.

[0030] S23. Intermediate code optimization: Perform compile-time optimization on intermediate code (such as constant folding and dead code elimination) to improve the performance of the final machine code.

[0031] S24. Machine code generation: Convert the optimized intermediate code into machine code for the target platform (output as a .wasm file).

[0032] S3, Runtime Execution Branch When no parameters are specified for AOT compilation, the runtime execution flow is entered, and the steps are as follows: S31. Added to the run options: Load runtime environment configuration (such as memory limits, sandbox policies, etc.).

[0033] S32, Bytecode parsing: Same as the AOT branch, parses the input bytecode.

[0034] S33, AOT code segment check: Determines whether the bytecode contains a pre-compiled AOT code segment. Yes: Supplement the runtime configuration of the AOT code segment to directly generate an abstract syntax tree (AST); No: Generate AST from bytecode.

[0035] S34. Pre-run verification: Perform security verification on the AST or execution environment (such as permission check and type validity verification) to prevent illegal execution.

[0036] S35. Create a sandbox: Build an isolated execution environment, restrict code access to the host system, and ensure security.

[0037] S36. Execution mode selection: The execution mode is determined based on runtime parameters and the target file format. S37. Interpreted execution: Interpreting bytecode line by line; S38, AOT Execution: Invokes the pre-compiled AOT code segment.

[0038] This step completes the operation flow of the Wasm runtime engine.

[0039] Key points of this invention: This invention designs a Wasm runtime engine for domestic embedded operating system environments, ensuring cross-platform support for resource-constrained embedded computing environments. Its main features include: (1) Highly efficient execution mechanism The Wasm runtime engine ensures that applications on resource-constrained embedded systems can still load and execute quickly even with limited hardware resources.

[0040] (2) It has scalability For embedded environments with diverse device types and application requirements, it allows developers to extend runtime engine functionality, enhancing applicability and functionality.

[0041] (3) AI inference task support The runtime environment that enables the efficient execution of these complex computational tasks on embedded devices provides powerful runtime support for intelligent computing in embedded environments.

[0042] Effects of the invention: This invention provides a method for implementing the Wasm runtime engine for embedded operating systems. Compared with existing technologies, the advantages of this invention are as follows: (1) The method proposed in this invention solves the problem of domestic embedded operating systems supporting the Wasm runtime engine under resource-constrained embedded system environments.

[0043] (2) The solution provided by the present invention achieves lightweighting of the Wasm runtime engine for embedded system resource environments.

[0044] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A design method for a lightweight Wasm runtime engine based on an embedded operating system, characterized in that, The runtime engine includes: a startup module, a parsing module, an AOT module, and a runtime module; The startup module is responsible for initializing the Wasm runtime engine, building command-line tools and parsing command-line parameters, and deciding whether to hand over control to the AOT module or the runtime module based on command options. The AOT module is responsible for calling the parsing module to parse the Wasm program into an AST, then optimizing the intermediate code, and compiling the optimized Wasm program into machine code that can be executed directly in the host environment. The runtime module is responsible for calling the parsing module to parse the Wasm program into an AST, performing the preparatory work before running the Wasm program, and instantiating the Wasm runtime. The parsing module is responsible for importing the Wasm program to be executed based on the file path and configuration information in the command line parameters, and disassembling its program segments.

2. The lightweight Wasm runtime engine design method based on an embedded operating system as described in claim 1, characterized in that, The startup module adopts a command-line tool programming paradigm based on Configure-Option to build a command-line parameter parser and generate Configure. The startup module parses the information of the command-line parameters, maps the parameter values ​​to the corresponding options, and verifies the validity of the parameters. After completing the initialization work, the startup module will decide whether to hand over control to the AOT module or the runtime module according to the command options.

3. The lightweight Wasm runtime engine design method based on an embedded operating system as described in claim 2, characterized in that, In the parsing module If it is a regular Wasm program, that is, it does not contain machine code compiled by AOT, the parsing module will convert it into an abstract syntax tree (AST) for internal use. Each node in the abstract syntax tree represents a syntax structure in the Wasm program for subsequent execution. Otherwise, it means that the Wasm program already contains machine code compiled by AOT, and the parsing module will modify the relevant options of Configure to simplify the generation of AST.

4. The lightweight Wasm runtime engine design method based on an embedded operating system as described in claim 3, characterized in that, The AOT module first adds AOT options to the existing Configure, and then the AOT module calls the parsing module to parse the Wasm program into an AST based on the Configure. AOT will then perform intermediate code optimization and compile the optimized intermediate code directly into machine code that can be executed directly in the host environment; Finally, the AOT module will copy the Wasm program content to the output file address according to the configuration options, and place the generated machine code into the Custom Section of the target Wasm program according to the Wasm Spec, ensuring that the Wasm runtime engine can correctly recognize and load the AOT-compiled program.

5. The lightweight Wasm runtime engine design method based on an embedded operating system as described in claim 4, characterized in that, The AOT option is set to the optimization level.

6. The lightweight Wasm runtime engine design method based on an embedded operating system as described in claim 4, characterized in that, The runtime module adds run options to the existing Configure. Then, the runtime module calls the parsing module to parse the Wasm program according to the Configure and generate the AST of the internal data structure. After that, the runtime module defines the Wasm runtime object, loads the Wasm program after parsing into the AST into the sandbox, and then calls the validator of the Wasm runtime object to perform static checks before running. After the check is complete, the runtime module will instantiate the Wasm runtime object and transfer control to the entry function of the Wasm program in the sandbox; the Wasm program will then execute specific instructions through the Wasm runtime executor.

7. The lightweight Wasm runtime engine design method based on an embedded operating system as described in claim 6, characterized in that, Runtime options include: resource limits and registration of WASI interface functions.

8. The lightweight Wasm runtime engine design method based on an embedded operating system as described in claim 6, characterized in that, Static checks include: whether the module structure is complete, whether the definitions of imports, exports, and segments conform to the Wasm Spec, whether the control flow structure is correct, and whether there are any illegal control jumps.

9. The design method for a lightweight Wasm runtime engine based on an embedded operating system as described in any one of claims 1-8, characterized in that, The method specifically includes the following steps: S1, Input and Parameter Analysis The process begins with command-line input. First, the command-line parameters are parsed, and then the process is routed to different processing paths depending on whether AOT compilation is triggered. If the parameter specifies AOT compilation, the AOT compilation branch is executed. If the parameter does not specify AOT compilation, the runtime execution process is entered. S2 and AOT compilation branches When the parameter is specified as "AOT compilation", perform the following steps: S21, AOT option added: Load AOT compilation-specific configuration; S22. Bytecode parsing: Read the input bytecode file and convert it into an internally processable intermediate representation; S23. Intermediate code optimization: Optimize intermediate code at compile time to improve the performance of the final machine code; S24, Machine code generation: Convert the optimized intermediate code into machine code for the target platform; S3, Runtime Execution Branch When no parameters are specified for AOT compilation, the runtime execution flow is entered, and the steps are as follows: S31. Added the following option to the run: Load runtime environment configuration; S32, Bytecode parsing: Parsing the input bytecode; S33, AOT code segment check: Determines whether the bytecode contains a pre-compiled AOT code segment. Yes: Supplement the runtime configuration of the AOT code segment to directly generate the Abstract Syntax Tree (AST); No: Generate AST from bytecode; S34. Pre-run verification: Perform security verification on the AST or execution environment to prevent illegal execution; S35. Create a sandbox: Build an isolated execution environment, restrict code access to the host system, and ensure security; S36. Execution mode selection: The execution mode is determined based on runtime parameters and the target file format. S37. Interpreted execution: Interpreting bytecode line by line; S38, AOT Execution: Invokes the pre-compiled AOT code segment; This step completes the operation flow of the Wasm runtime engine.

10. The lightweight Wasm runtime engine design method based on an embedded operating system as described in claim 9, characterized in that, The compile-time optimizations include constant folding and dead code elimination.

Images