Lightweight Wasm runtime engine design method based on embedded operating system

Abstract

The invention relates to a lightweight Wasm runtime engine design method based on an embedded operating system, and belongs to the technical field of embedded operating systems. The runtime engine comprises a starting module, an analysis module, an AOT module and a runtime module. The process starts from command line input, firstly, command line parameters are analyzed, the AOT compiling is shunted to different processing paths according to whether the AOT compiling is triggered or not, if the parameters are appointed to be AOT compiling, AOT compiling branches are executed, and if the parameters are not appointed to be AOT compiling, the runtime execution process is entered. According to the method provided by the invention, the problem of supporting the engine when the Wasm is run by a domestic embedded operating system in an embedded system resource limited environment is solved, and the light weight of the engine when the Wasm is run in the embedded system resource environment is realized.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of embedded operating systems, and particularly relates to a lightweight Wasm runtime engine design method based on an embedded operating system. BACKGROUND

[0002] The Chinese patent "Method for optimizing wasm bytecode, execution method, computer device and storage medium" reads wasm bytecode and parses to obtain a wasm module queue; linear memory is created according to the parsed wasm module object and the linear memory is filled; a start function in the wasm module object is executed, and the linear memory is modified according to the execution result of the start function; the data in the modified linear memory is used to replace the corresponding data segment in the wasm module object; and the wasm module after the data segment is replaced is encoded and saved as wasm bytecode.

[0003] The Chinese patent "Method for optimizing wasm bytecode, execution method, computer device and storage medium" mainly provides a method for optimizing wasm bytecode in a non-web environment, and the main application field focuses on the Internet of Things and the blockchain field. Currently, no patent provides a Wasm runtime engine design and optimization method for a domestic embedded operating system in a resource-constrained environment of an embedded system.

[0004] There are diversified hardware architectures (such as ARM, RISC-V, x86) and heterogeneous operating system environments (including Linux, RTOS and various customized OSs) in the current embedded device ecosystem, which leads to repeated adaptation development of application programs for different platforms. The traditional development mode requires developers to deeply couple the bottom layer hardware characteristics, which leads to low code reuse rate, high maintenance cost and difficulty in realizing "one development, multi-platform deployment". Moreover, the embedded development environment is usually complex, and multiple cross-compilations and debugging are required, which brings great inconvenience to developers. The existing development tools and processes are complicated, inefficient and difficult to meet the needs of rapid development and deployment. Such an inefficient development process not only increases the development cost, but also prolongs the technical implementation cycle and reduces the development efficiency. Therefore, it is necessary to introduce a Wasm runtime engine in an embedded real-time operating system environment to solve the application cross-platform support problem in a resource-constrained environment of an embedded system. SUMMARY

[0005] (I) Technical problems to be solved The technical problem to be solved by the present application 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 a resource-constrained environment of an embedded system.

[0006] (II) Technical solutions In order to solve the above technical problems, the application provides a lightweight Wasm runtime engine design method based on an embedded operating system, which comprises a starting module, an analysis module, an AOT module and a runtime module. The starting module is responsible for the initialization of the Wasm runtime engine, constructs a command line tool and analyzes command line parameters, and decides whether to hand over the control to the AOT module or the runtime module according to the command options. The AOT module is responsible for calling the analysis module to parse the Wasm program into an AST, then performing intermediate code optimization, and compiling the optimized Wasm program into machine code that can be directly executed in the host environment. The runtime module is responsible for calling the analysis module to parse the Wasm program into an AST, performing preparation work before the Wasm program runs, and instantiating the Wasm runtime. The analysis module is responsible for importing the Wasm program to be executed according to the file path and configuration information of the command line parameters, and disassembling the program segment.

[0007] (III) Advantages The application provides a lightweight Wasm runtime engine design method based on an embedded operating system, and the advantages of the application are as follows: (1) The method provided by the application solves the problem of supporting Wasm runtime engine for domestic embedded operating system in a resource-limited embedded system environment.

[0008] (2) The scheme provided by the application realizes the lightweight of the Wasm runtime engine in the resource-limited embedded system environment. DETAILED DESCRIPTION

[0009] Figure 1 is a structure diagram of the runtime module of the application; Figure 2 is a runtime engine running flowchart of the application. DETAILED DESCRIPTION

[0010] In order to make the purpose, content and advantages of the application clearer, the specific embodiments of the application are described in detail below in combination with the drawings and examples.

[0011] In order to solve the problem of supporting Wasm runtime engine in a resource-limited embedded system environment, the application provides a lightweight Wasm runtime engine supporting domestic embedded real-time operating system.

[0012] The runtime engine of the application has the following functional modules, including a starting module, an analysis module, an AOT module and a runtime module. (1) Start module The start module will be responsible for the initialization of the Wasm runtime engine, mainly for the construction of the command line tool and the parsing of the command line parameters. The application adopts the Configure-Option-based command line tool programming paradigm to construct the command line parameter parser and generate Configure.

[0013] The start module will parse the information of the command line parameters, map the parameter values to the corresponding options, and verify the legality of the parameters.

[0014] After completing the initialization work, the start module will decide whether to hand over the control to the AOT module or the runtime module according to the command options.

[0015] (2) Parsing module The parsing module is responsible for importing the Wasm program to be executed according to the file path and configuration information of the command line parameters, and disassembling the program segment.

[0016] If it is a regular Wasm program (i.e. does not contain AOT compiled machine code), the parsing module will convert it into the internal data structure AST (Abstract Syntax Tree), and each node in the abstract syntax tree represents a syntax structure in the Wasm program, so as to facilitate subsequent execution.

[0017] Otherwise, it means that the Wasm program already contains AOT compiled machine code, and the parsing module will modify the related 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 AST, then perform intermediate code optimization, and compile the optimized Wasm program into machine code that can be directly executed in the host environment.

[0019] The AOT module will first add the options of AOT, such as optimization level, etc. on the basis of the existing Configure. Then the AOT module will call the parsing module to parse the Wasm program into AST according to Configure.

[0020] Then AOT will perform intermediate code optimization and compile the optimized intermediate code into machine code that can be directly executed in the host environment. The details are not expanded here, and please refer to the technical approach for details.

[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 segment of the target Wasm program according to the Wasm Spec specification, ensuring that the Wasm runtime engine can correctly identify 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 AST, performing the preparation work before running the Wasm program, and instantiating the Wasm runtime.

[0023] Similar to the AOT module, the runtime module will add runtime options based on the existing Configure, such as resource limits, WASI interface function registration, etc. Then, the runtime module will call the parsing module to parse the Wasm program according to Configure and generate the AST of the internal data structure.

[0024] Then, the runtime module will define the Wasm runtime object and load the Wasm program parsed into AST into the sandbox, and then call the verifier of the Wasm runtime object to perform static checking before running, mainly verifying whether the module structure is complete, whether the import, export and segment definitions conform to the Wasm Spec specification, and whether the control flow structure is correct, whether there are illegal control jumps, etc.

[0025] After the check is completed, the runtime module will instantiate the Wasm runtime object and transfer the control to the entry function of the Wasm program in the sandbox. Then the Wasm program will perform specific instruction execution through the executor of the Wasm runtime.

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

[0027] The functional execution flow of the present application takes the command line driver as the entrance, and expands around the two core branches of AOT compilation and runtime execution. The specific process is as follows: S1, entrance and parameter parsing The process starts with command line input. First, the command line parameters are parsed, and according to whether AOT compilation is triggered, the flow is divided into different processing paths. If the parameter is specified for AOT compilation, the AOT compilation branch is executed, and if the parameter is not specified for AOT compilation, the runtime execution process is entered.

[0028] S2, AOT compilation branch When the parameter is specified for "AOT compilation", the following steps are performed: S21, AOT option addition: load AOT compilation exclusive configuration (such as optimization level, target architecture, etc.).

[0029] S22, bytecode parsing: read the input bytecode file and convert it into an internal processable intermediate representation.

[0030] S23, intermediate code optimization: compile-time optimization of intermediate code (such as constant folding, 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 the parameter is not specified for AOT compilation, enter the runtime execution process, the steps are as follows: S31, run-time option addition: load the runtime environment configuration (such as memory limit, sandbox policy, etc.).

[0033] S32, bytecode parsing: same as the AOT branch, parse the input bytecode.

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

[0035] S34, pre-execution verification: perform security verification (such as permission check, type legality verification) on the AST or execution environment to avoid illegal execution.

[0036] S35, create sandbox: build an isolated execution environment to limit code access to the host system and ensure security.

[0037] S36, execution mode selection: determine the execution mode based on runtime parameters and target file form: S37, interpretive execution: interpret the bytecode line by line; S38, AOT execution: call the pre-compiled AOT code segment.

[0038] Through this step, the running process of the Wasm runtime engine is completed.

[0039] Key points of the present application: The present application designs a Wasm runtime engine for domestic embedded operating system environment, ensuring cross-platform support for resource-constrained embedded computing environment applications, and the main features include: (1) Efficient execution mechanism The Wasm runtime engine can ensure that resource-constrained embedded system applications can still be quickly loaded and executed under limited hardware resources.

[0040] (2) Scalability In view of the diversity of device types and application requirements in embedded environments, the developer is allowed to extend the runtime engine functions to enhance the applicability and functionality.

[0041] (3) AI inference task support The runtime environment that can efficiently execute these complex computing tasks on embedded devices provides strong runtime support for intelligent computing in embedded environments.

[0042] Effects of the present application: The present application provides a Wasm runtime engine implementation method for embedded operating systems, which has the following advantages compared with the prior art: (1) The method proposed in the present application solves the problem of supporting Wasm runtime engine for domestic embedded operating systems in resource-constrained environments of embedded systems.

[0043] (2) The scheme provided in the present application realizes the lightweight of Wasm runtime engine in the resource environment of embedded systems.

[0044] The above is only the preferred embodiment of the present application, it should be pointed out that, for the ordinary skilled in the art, without departing from the technical principles of the present application, a number of improvements and modifications can be made, these improvements and modifications should also be considered as the protection scope of the present application.

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 AOT compilation is specified as a parameter, the runtime execution flow is entered, and the steps are as follows: S31. Added the option to 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 to 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