Program import method and device, electronic equipment and storage medium
By generating a WASM interface encapsulation library and preset function callbacks, the problem of importing external program interfaces into the WASM runtime environment is solved, achieving efficient and low-memory interface import, which is suitable for various electronic devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-11
- Publication Date
- 2026-03-13
AI Technical Summary
Importing a large number of external program interfaces into the WASM runtime environment is difficult. Existing technical solutions would result in an increased WASM package size or excessive workload, and are not suitable for electronic devices with limited memory.
By obtaining the header files and compilation configuration information of the native program, an import program is generated, the interfaces in the native program are encapsulated into WASM interfaces, a WASM interface encapsulation library is generated, and the native program is imported into the WASM runtime environment. Preset functions are used to realize function callbacks and memory area sharing.
It enables the efficient import of a large number of external program interfaces in the WASM runtime environment, reducing workload, avoiding program errors, and is suitable for electronic devices with small memory.
Smart Images
Figure CN121658103A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and in particular to a program import method, apparatus, electronic device, and storage medium. Background Technology
[0002] WebAssembly (WASM) technology is a virtual machine technology. The WASM virtual machine runtime format is characterized by high security and a compact structure. WASM programs require specific software to run, and this software creates an isolated runtime environment for the WASM program. Within this environment, the WASM program cannot directly access any external program interfaces. Access to external program interfaces is only possible by importing them into the specific software, thus ensuring the WASM program's security. However, if a WASM program needs to access a large number of external program interfaces, importing a large number of these interfaces into the specific software becomes very difficult. Summary of the Invention
[0003] To overcome the problems existing in the related technologies, this disclosure provides a program import method, apparatus, electronic device and storage medium.
[0004] According to a first aspect of the present disclosure, a program import method is provided, the method comprising:
[0005] Obtain the header files and compilation configuration information of the native program;
[0006] Based on the header file and the compilation configuration information, an import program is generated;
[0007] The import procedure encapsulates the interfaces in the native program into WASM interfaces, generating a WASM interface encapsulation library.
[0008] Based on the WASM interface encapsulation library, import the native program into the WASM runtime environment.
[0009] In an exemplary embodiment, if the native program includes a first function that calls a second function, wherein the second function is a WASM function, the method for generating the importer based on the header file and the compilation configuration information further includes:
[0010] Create the first preset function;
[0011] The second function is called back to the WASM runtime environment through the first preset function.
[0012] In one exemplary embodiment, the method further includes:
[0013] The first information and the second information are stored in a preset storage area through the first preset function. The first information includes the execution context information and WASM function information of the WASM program. The second information is the second preset function information, which is used to call the preset WASM interface.
[0014] In an exemplary embodiment, the step of calling back the second function to the WASM runtime environment through the first preset function includes:
[0015] According to the preset instructions, jump to the third preset function;
[0016] The first information is converted into a parameter of a preset type through the third preset function;
[0017] Jump from the third preset function to the second preset function;
[0018] The second function is called back to the WASM runtime environment through the second preset function.
[0019] In an exemplary embodiment, when jumping to a third preset function according to a preset instruction, the method further includes:
[0020] The first address and the second address are sent to the third preset function through the first preset function; wherein, the first address is the memory address of the first preset function, and the second address is the offset address of the first information and the second information.
[0021] In an exemplary embodiment, before converting the first information into a parameter of a preset type via the third preset function, the method further includes:
[0022] Based on the first address and the second address, determine the target address of the first information and the second information;
[0023] Based on the target address, the first information and the second information are obtained through the third preset function.
[0024] In one exemplary embodiment, the method further includes:
[0025] The native program uses a preset memory allocator to determine a preset memory region in the WASM runtime environment. The preset memory region is a memory region that the native program can access through pointers.
[0026] According to a second aspect of the present disclosure, a program import apparatus is provided, the apparatus comprising:
[0027] The module is configured to retrieve the header files and compilation configuration information of native programs.
[0028] The generation module is configured to generate an importer based on the header file and the compilation configuration information;
[0029] The encapsulation module is configured to encapsulate the interfaces in the Native program into WASM interfaces through the importing program, and generate a WASM interface encapsulation library.
[0030] The import module is configured to import the native program into the WASM runtime environment based on the WASM interface encapsulation library.
[0031] According to a third aspect of the present disclosure, an electronic device is provided, comprising:
[0032] processor;
[0033] Memory used to store processor-executable instructions;
[0034] The processor is configured to perform the method described in the first aspect of the embodiments of this disclosure.
[0035] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided, wherein when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method described in the first aspect of the present disclosure.
[0036] The method described above has the following advantages: Based on the header file and compilation configuration information of the native program, an importer is automatically generated. The importer encapsulates the interfaces in the native program into WASM interfaces, generating a WASM interface encapsulation library. Based on the WASM interface encapsulation library, the native program is imported into the WASM runtime environment, which can achieve the technical effect of importing a large number of external program interfaces into the WASM runtime environment.
[0037] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description
[0038] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0039] Figure 1 This is a flowchart illustrating a program import method according to an exemplary embodiment;
[0040] Figure 2 This is a function callback flowchart illustrated according to an exemplary embodiment;
[0041] Figure 3 This is a schematic diagram of a function callback according to an exemplary embodiment;
[0042] Figure 4 This is a block diagram illustrating a program import device according to an exemplary embodiment;
[0043] Figure 5 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation
[0044] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.
[0045] In related technologies, if a WASM program needs to access a large number of external program interfaces, the following two methods are typically used: First, package all the external programs that the WASM program needs to access together and run them within the WASM program; second, compile each external program that the WASM program needs to access into a native program and add a wrapper layer for the WASM program to use. However, the first method increases the size of the WASM program package, and the memory required by the WASM program also increases accordingly, making it unsuitable for electronic devices with limited memory, such as embedded devices. Furthermore, if multiple WASM programs need to access the same external program interface, the external program needs to be packaged multiple times and loaded into each WASM program separately, resulting in the problem of repeated packaging and loading. The second method requires a very large amount of work and is not applicable to practical situations. Moreover, compiling some special external programs into native programs is quite difficult.
[0046] In the exemplary embodiments of this disclosure, to overcome the difficulty of importing a large number of external program interfaces into the WASM runtime environment in related technologies, a program import method is provided, including: obtaining the header file and compilation configuration information of a native program; generating an import program based on the header file and compilation configuration information; encapsulating the interfaces in the native program into WASM interfaces using the import program to generate a WASM interface encapsulation library; and importing the native program into the WASM runtime environment based on the WASM interface encapsulation library. This method can automatically generate an import program, achieving the technical effect of importing a large number of external program interfaces into the WASM runtime environment.
[0047] In an exemplary embodiment of this disclosure, a program import method is used. Figure 1 This is a flowchart illustrating a program import method according to an exemplary embodiment, such as... Figure 1 As shown, it includes the following steps:
[0048] Step S101: Obtain the header files and compilation configuration information of the native program;
[0049] Step S102: Generate the import program based on the header file and compilation configuration information;
[0050] Step S103: By importing the program, the interface in the native program is encapsulated into a WASM interface, and a WASM interface encapsulation library is generated.
[0051] Step S104: Based on the WASM interface encapsulation library, import the native program into the WASM runtime environment.
[0052] The program import method in this disclosure is applied to electronic devices, including smartphones, tablets, personal computers, and other electronic devices with compilation capabilities.
[0053] In step S101, the Native program is a program located outside the WASM runtime environment that the WASM program needs to access. In one example, the first program is a C or C++ program in the Native runtime environment. The header file of the Native program contains the function declarations and macro definitions used in the Native program. In some possible implementations, the header file is referenced in the C program code using the #include command. The header file is a code file with the .h extension. The compilation configuration information is entered by the user and set according to the user's personal needs. The compilation configuration information is used to compile the header file, including the file path of the include, macro definitions, etc.
[0054] In step S102, the header file of the native program is parsed using an Abstract Syntax Tree (AST) parser. This parses the header file's source code into an AST, which describes the various components of the header file's source code in a structured way and stores them as syntax tree information. For example, for a function in the header file, the parser will parse out the function's name, return value, parameters, and other components, storing each component as syntax tree information. The code generator reads the syntax tree information, thus obtaining all the information from the header file's source code. Based on all the information from the header file's source code and the characteristics of the WASM program's runtime code, the code generator generates the source code for the imported program. Both the AST parser and the code generator can be any tool with the corresponding functionality.
[0055] In step S103, the source code of the importing program and the source code of the header file of the native program are compiled. The importing program encapsulates each interface in the native program into a WASM interface. The interfaces in the native program include the calling interfaces of various functions that can be invoked. Since the WASM runtime environment cannot recognize the interfaces in the native program, the WASM program cannot directly call the interfaces in the native program. By encapsulating each interface in the native program into an interface that the WASM runtime environment can recognize, i.e., a WASM interface, through the importing program, it can be called by the WASM program. After encapsulating each interface in the native program into a WASM interface, the importing program then encapsulates the WASM interfaces corresponding to all interfaces to generate a WASM interface encapsulation library.
[0056] In step S104, the WASM interface wrapper library is imported into the WASM runtime environment, allowing the interface in the native program to be called from the source code of the WASM program. If multiple WASM programs need to call the native program, only the WASM interface wrapper library corresponding to the native program needs to be imported into the WASM runtime environment, allowing the interface in the native program to be called from the code of multiple WASM programs, without having to repeatedly wrap the interface in each WASM program.
[0057] In the exemplary embodiments of this disclosure, an importer is automatically generated based on the header files and compilation configuration information of the native program. This reduces workload and avoids program errors that are prone to occur when writing code by hand. The importer encapsulates the interfaces in the native program into WASM interfaces, generating a WASM interface encapsulation library. Based on the WASM interface encapsulation library, the native program is imported into the WASM runtime environment. This achieves the technical effect of importing a large number of external program interfaces into the WASM runtime environment. Furthermore, this method does not increase the memory required by the WASM program and is suitable for electronic devices with limited memory.
[0058] In some embodiments, if the native program includes a first function that calls a second function, where the second function is a WASM function, the above embodiments further include the following steps:
[0059] Create the first preset function;
[0060] The second function is called back to the WASM runtime environment through the first preset function.
[0061] When generating the importer based on the header file and compilation configuration information, the process iterates through each function information contained in the Native program's header file. If the Native program contains a first function that calls the second function, then the first function is a function implemented by the Native runtime environment, and the second function is a WASM function, i.e., a function within the WASM runtime environment. Since the Native program calls the second function, and this embodiment requires importing the Native program into the WASM runtime environment, the second function represents the WASM function that is being called back. The first preset function is automatically generated by the code generator. When the code generator detects that the Native program contains a first function that calls the WASM function, it dynamically generates the first preset function. When the Native program calls the first preset function, it calls back the second function to the WASM runtime environment. The name of the first preset function can be set according to actual needs, for example, the first preset function could be the `create_Native_cb` function.
[0062] In the WASM runtime environment, the address of each function is stored in the WASM table. When an external program calls a WASM function, it uses the index in the WASM table to invoke the function. When the first function needs to be imported into the WASM runtime environment, it cannot directly call the callback function index of the WASM function. Therefore, the second function is called back to the WASM runtime environment through the first preset function.
[0063] In some embodiments, when the second function is called back to the WASM runtime environment via the first preset function, Figure 2 This is a function callback flowchart illustrated according to an exemplary embodiment, such as... Figure 2 As shown, the process includes the following steps S201-S208:
[0064] Step S201: Store the first information and the second information into a preset storage area using a first preset function.
[0065] The first information includes the execution context information and WASM function information of the WASM program. The execution context information is a necessary structural element for every WASM program. The WASM function information represents the second function information, including the function name, return value, and parameters. The second information is the second preset function information. The second preset function is used to call the preset WASM interface, which is an interface provided by the WASM runtime environment for calling internal functions. In one example, the second preset function is the bridge function. In one example, the first information includes the env parameter and the func_idx parameter. A preset storage area is allocated through the first preset function, and the first and second information are saved to this preset storage area. The preset storage area is located in system memory, and its size is determined based on the sizes of the first and second information.
[0066] Step S202: According to the preset instruction, jump to the third preset function.
[0067] The preset instruction can be any instruction capable of jump, such as the `jmp` instruction. Executing the preset instruction jumps to the third preset function, which is the trampoline function. In some implementations, the preset instruction can also be called the entry instruction. In some implementations, the third preset function is written in assembly language.
[0068] Step S203: Send the first address and the second address to the third preset function through the first preset function.
[0069] Here, the first address is the memory address of the first preset function, i.e., the starting address, and the second address is the offset address of the first and second information. Simultaneously with the jump to the third preset function according to the preset instruction, the first preset function will send the first and second addresses to the third preset function.
[0070] Step S204: Determine the target address of the first information and the second information based on the first address and the second address.
[0071] Add the starting address and offset address of the first information to obtain the target address of the first information. Add the starting address and offset address of the second information to obtain the target address of the second information.
[0072] Step S205: Based on the target address, obtain the first information and the second information through the third preset function.
[0073] The third preset function retrieves the first information and the second information from the preset storage area based on the target address.
[0074] Step S206: Convert the first information into a parameter of a preset type using a third preset function.
[0075] The preset type of parameter indicates the parameters that the second preset function can accept. After the third preset function obtains the first information from the preset storage area, it converts the parameters in the first information into parameters that the second preset function can accept. For example, the third preset function integrates the env parameter, the func_idx parameter, and the first function parameter to form a list of parameters that the bridge function can accept.
[0076] Step S207: Jump from the third preset function to the second preset function.
[0077] After the third preset function retrieves the second information from the preset storage area, it jumps to the second preset function.
[0078] Step S208: Call back the second function to the WASM runtime environment through the second preset function.
[0079] The second preset function calls the preset WASM interface to return the second function to the WASM runtime environment.
[0080] In one example, the first function is the `Native_call` function, the first preset function is the `cb` function, the preset instruction is the `jmp` instruction, the first information includes the `env` parameter and the `func_idx` parameter, the second information is the `bridge_func` information, the second preset function is the `bridge_func` function, and the third preset function is the `trampoline` function. Figure 3 This is a schematic diagram of a function callback according to an exemplary embodiment, such as... Figure 3 As shown, the process of a native function calling back a WASM function includes the following steps:
[0081] S1, when the Native_call function calls cb, the first instruction is the jmp instruction, which jumps to the pre-defined trampoline function;
[0082] S2, the trampoline function retrieves the env parameter, func_idx parameter, and bridge_func information stored in cb;
[0083] In one example, the trampoline function is written in assembly language. The trampoline function reads the jump address of the register through assembly instructions to obtain the first and second information.
[0084] S3, the trampoline function integrates the env parameter, the func_idx parameter, and the Native_call function parameter to form a list of parameters that the bridge_func function can accept;
[0085] S4, jump to the bridge_func function;
[0086] S5, the bridge_func function calls the API provided by WASM and calls back to the WASM runtime environment.
[0087] Since calling the preset WASM interface requires providing first information, and the first function cannot directly obtain this first information when importing the WASM runtime environment, it cannot directly call the preset WASM interface. Therefore, the first information needs to be packaged into a function pointer that the first function can recognize. In this embodiment, the first information is converted into a parameter type acceptable to the second preset function through a third preset function, and then the preset WASM interface is called through the third preset function to implement the callback from the first function to the second function, thus solving the problem that the first function cannot directly call the preset WASM interface.
[0088] In some embodiments, steps S202 and S206-S208 in the above embodiments can be implemented as a separate embodiment, and other steps can be replaced or omitted.
[0089] In some embodiments, the above two embodiments further include the following steps:
[0090] Native programs use a default memory allocator to determine a default memory region in the WASM runtime environment. The default memory region is a memory region that native programs can access through pointers.
[0091] The default memory allocator refers to the same memory allocator shared by native programs and the WASM runtime environment. By using the default memory allocator to allocate memory allocated by native programs in the WASM memory space, WASM programs can directly access the default memory area, and native programs can directly access the default memory area through native pointers.
[0092] Because the WASM runtime environment uses a closed memory management mechanism, when a native program allocates data or structures for the WASM program to use, the WASM code cannot use the memory allocated by the native program. Therefore, by using a preset memory allocator to allocate a preset memory region in the WASM runtime environment for access by both the native and WASM programs, mutual memory access between the native and WASM programs can be achieved.
[0093] In an exemplary embodiment of this disclosure, a program import device is provided. Figure 4 This is a block diagram illustrating a program import device according to an exemplary embodiment, such as... Figure 4 As shown, the program import device includes:
[0094] Module 401 is configured to retrieve the header files and compilation configuration information of native programs.
[0095] Module 402 is configured to generate an importer based on the header file and compilation configuration information;
[0096] The encapsulation module 403 is configured to encapsulate the interfaces in the native program into WASM interfaces by importing the program, and generate a WASM interface encapsulation library.
[0097] Import module 404, configured as a WASM interface wrapper library, imports native programs into the WASM runtime environment.
[0098] In an exemplary embodiment, if the native program includes a first function that calls a second function, where the second function is a WASM function, then when generating the importer based on the header file and compilation configuration information, the generation module 402 is further configured as follows:
[0099] Create the first preset function;
[0100] The second function is called back to the WASM runtime environment through the first preset function.
[0101] In one exemplary embodiment, the generation module 402 is further configured to:
[0102] The first information and the second information are stored in a preset storage area through a first preset function. The first information includes the execution context information and WASM function information of the WASM program, and the second information is the second preset function information. The second preset function is used to call the preset WASM interface.
[0103] In one exemplary embodiment, the generation module 402 is further configured to:
[0104] According to the preset instructions, jump to the third preset function;
[0105] The first information is converted into a parameter of a preset type through the third preset function;
[0106] Jump from the third preset function to the second preset function;
[0107] The second function is called back to the WASM runtime environment via the second preset function.
[0108] In one exemplary embodiment, the generation module 402 is further configured to:
[0109] The first address and the second address are sent to the third preset function through the first preset function; wherein, the first address is the memory address of the first preset function, and the second address is the offset address of the first information and the second information.
[0110] In one exemplary embodiment, the generation module 402 is further configured to:
[0111] Based on the first address and the second address, determine the target addresses of the first information and the second information;
[0112] Based on the target address, the first and second information are obtained through a third preset function.
[0113] In one exemplary embodiment, the import module 404 is further configured to:
[0114] Native programs use a default memory allocator to determine a default memory region in the WASM runtime environment. The default memory region is a memory region that native programs can access through pointers.
[0115] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0116] Figure 5 This is a block diagram illustrating an electronic device 500 according to an exemplary embodiment.
[0117] Reference Figure 5 The electronic device 500 may include one or more of the following components: processing component 502, memory 504, power supply component 506, multimedia component 508, audio component 510, input / output (I / O) interface 512, sensor component 514, and communication component 516.
[0118] Processing component 502 typically controls the overall operation of electronic device 500, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 502 may include one or more processors 520 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 502 may include one or more modules to facilitate interaction between processing component 502 and other components. For example, processing component 502 may include a multimedia module to facilitate interaction between multimedia component 508 and processing component 502.
[0119] Memory 504 is configured to store various types of data to support the operation of electronic device 500. Examples of such data include instructions for any application or method operating on electronic device 500, contact data, phonebook data, messages, pictures, videos, etc. Memory 504 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.
[0120] Power supply component 506 provides power to various components of electronic device 500. Power supply component 506 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 500.
[0121] Multimedia component 508 includes a screen that provides an output interface between the electronic device 500 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 508 includes a front-facing camera and / or a rear-facing camera. When the electronic device 500 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.
[0122] Audio component 510 is configured to output and / or input audio signals. For example, audio component 510 includes a microphone (MIC) configured to receive external audio signals when electronic device 500 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 504 or transmitted via communication component 516. In some embodiments, audio component 510 also includes a speaker for outputting audio signals.
[0123] I / O interface 512 provides an interface between processing component 502 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.
[0124] Sensor assembly 514 includes one or more sensors for providing state assessments of various aspects of electronic device 500. For example, sensor assembly 514 may detect the on / off state of electronic device 500, the relative positioning of components such as the display and keypad of electronic device 500, changes in position of electronic device 500 or a component of electronic device 500, the presence or absence of user contact with electronic device 500, orientation or acceleration / deceleration of electronic device 500, and temperature changes of electronic device 500. Sensor assembly 514 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 514 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 514 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.
[0125] Communication component 516 is configured to facilitate wired or wireless communication between electronic device 500 and other devices. Electronic device 500 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 516 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 516 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.
[0126] In an exemplary embodiment, the electronic device 500 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.
[0127] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 504 including instructions, which can be executed by a processor 520 of an electronic device 500 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.
[0128] A non-transitory computer-readable storage medium, wherein when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform a program import method, including any of the methods described above.
[0129] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.
[0130] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.
Claims
1. A method for importing a program, characterized in that, The method includes: Obtain the header files and compilation configuration information of the native program; Based on the header file and the compilation configuration information, an import program is generated; The import program encapsulates the interfaces in the native program into WASM interfaces, generating a WASM interface encapsulation library. Based on the WASM interface encapsulation library, import the native program into the WASM runtime environment.
2. The program import method according to claim 1, characterized in that, If the native program includes a first function that calls a second function, where the second function is a WASM function, then when generating the import program based on the header file and the compilation configuration information, the method further includes: Create the first preset function; The second function is called back to the WASM runtime environment through the first preset function.
3. The program import method according to claim 2, characterized in that, The method further includes: The first information and the second information are stored in a preset storage area through the first preset function. The first information includes the execution context information and WASM function information of the WASM program. The second information is the second preset function information, which is used to call the preset WASM interface.
4. The program import method according to claim 3, characterized in that, The step of calling back the second function to the WASM runtime environment through the first preset function includes: According to the preset instructions, jump to the third preset function; The first information is converted into a parameter of a preset type by the third preset function; Jump from the third preset function to the second preset function; The second function is called back to the WASM runtime environment through the second preset function.
5. The program import method according to claim 4, characterized in that, When jumping to a third preset function according to a preset instruction, the method further includes: The first address and the second address are sent to the third preset function through the first preset function; wherein, the first address is the memory address of the first preset function, and the second address is the offset address of the first information and the second information.
6. The program import method according to claim 5, characterized in that, Before converting the first information into a parameter of a preset type via the third preset function, the method further includes: Based on the first address and the second address, determine the target address of the first information and the second information; Based on the target address, the first information and the second information are obtained through the third preset function.
7. The program import method according to claim 1, characterized in that, The method further includes: The native program uses a preset memory allocator to determine a preset memory region in the WASM runtime environment. The preset memory region is a memory region that the native program can access through pointers.
8. A program import device, characterized in that, The device includes: The module is configured to retrieve the header files and compilation configuration information of native programs; The generation module is configured to generate an importer based on the header file and the compilation configuration information; The encapsulation module is configured to encapsulate the interfaces in the Native program into WASM interfaces through the importing program, and generate a WASM interface encapsulation library. The import module is configured to import the native program into the WASM runtime environment based on the WASM interface encapsulation library.
9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to perform the method as described in any one of claims 1-7.
10. A non-transitory computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1-7.