Code adaptation method, electronic device, storage medium and chip system

Abstract

The code adaptation method, the electronic device, the storage medium and the chip system provided by the embodiments of the present application relate to the technical field of terminals. The method comprises the following steps: the adaptation of the variadic function can be realized by sharing the linear memory array between the JS glue code and WASM. For example, when the variadic function of the DOM API is called, a plurality of parameters can be packaged into a unified array, and the index of the array is passed, so that the JS glue code can access the parameters when the DOM API is called. Then, the plurality of parameters can be expanded according to the requirements of the variadic function, so as to realize the adaptation and calling of the variadic function.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a code adaptation method, electronic device, storage medium and chip system. Background Technology

[0002] In software development, high-level languages ​​such as C, Rust, or JavaScript (JS) can be compiled into WebAssembly programming languages ​​(WASM) to facilitate code migration and improve runtime performance. Taking JS to WASM compilation as an example, the compiler needs to adapt the environment interaction between JS and WASM during the compilation process.

[0003] However, when JS is compiled into WASM, the code generated by WASM occupies a lot of memory space, cannot effectively handle function calls, increases the complexity of code development, and reduces the execution efficiency of the code. Summary of the Invention

[0004] This application provides a code adaptation method, electronic device, storage medium, and chip system that can achieve the adaptation of variadic functions through a linear memory array shared between glue code and bytecode, thereby supporting the adaptation of variadic function calls after the code is compiled into bytecode. This provides a simpler and more efficient mechanism for calling variadic functions.

[0005] In a first aspect, embodiments of this application provide a code adaptation method applied to electronic devices, the method comprising:

[0006] The first function in the source code is called; this first function is a variable-argument function. If the source code is compiled into bytecode, the indices of the first function's parameters in a second array are saved to the first array. The second array stores the parameters passed between the glue code and the bytecode, including the parameters of the first function. The second function in the glue code is called, which in turn calls the first function and passes a third function as a parameter to the first function. The third function retrieves the first array and uses the indices stored in the first array to retrieve the parameters of the first function. In this embodiment, the adaptation of variable-argument functions (including the first function) is achieved through a shared linear memory array (equivalent to the first array) between the glue code and the bytecode, thereby supporting the calling of variable-argument functions (including the first function) after the source code is compiled into bytecode. For example, when calling a variable-argument function of the Web platform DOM API, multiple parameters can be packaged into a unified array, and by passing the array indices, the glue code can access these parameters when calling the DOM API. These multiple parameters can then be expanded according to the requirements of the variable-argument function, achieving adaptation and calling of variable-argument functions in the DOM API. This optimizes the handling of dynamic parameters and provides a more concise and efficient mechanism for calling variadic functions. Developers no longer need to write functions with multiple fixed numbers of parameters for variadic functions, reducing code redundancy and size. Furthermore, variadic parameters can be uniformly passed through linear memory arrays, ensuring consistency between source code and bytecode function calls. This makes bytecode implementations for adapting variadic function calls more concise and reduces application development complexity.

[0007] In one possible implementation, the parameter of the third function is an index of a reference to the first array in the second array. The third function also includes a target operator, which instructs the third function to retrieve the parameter of the first function based on the index stored in the first array. The third function retrieves the first array and retrieves the parameter of the first function based on the index stored in the first array, including: the third function retrieves the first array based on the index of the reference to the first array in the second array; and retrieves the parameter of the first function from the second array based on the index stored in the first array according to the target operator. The code adaptation method of this application embodiment can adapt to variable parameter functions, allowing variable parameter functions to pass a variable number of parameters, making function calls more flexible. Callers can pass different numbers of parameters according to actual needs without generating multiple import functions and function signatures based on the number of parameters. Thus, adapting variable parameter functions in this application embodiment can reduce code duplication, improve code maintainability and reusability, thereby reducing code size and optimizing the memory space of electronic devices.

[0008] In one possible implementation, when the source code is compiled into bytecode, the method further includes saving a reference to the first array into the second array. This embodiment of the application uses a heap array (equivalent to the second array) and an array array (equivalent to the first array) to transform the passing of objects or variables into the passing of the index values ​​of the objects or variables in the heap array. This satisfies the requirement that source code (such as JS source code) and bytecode (such as WASM) do not directly pass objects, but rather pass numerical values, thereby achieving adaptation to variadic functions.

[0009] One possible implementation involves, before saving the index of the first function's parameter in the second array to the first array, retrieving the first function's parameter from the second array based on its data type. This allows for different adaptation processes based on the parameter's data type, placing the indices of different types of parameters from the heap array (equivalent to the second array) into the array array (equivalent to the first array), thus enabling the processing and adaptation of different parameter types.

[0010] In one possible implementation, the parameters of the first function are obtained from the second array based on their data types. This includes: if the parameter of the first function is an object type, obtaining the index of the parameter in the second array; wherein the second array stores references to the parameters of the first function; if the parameter of the first function is an integer type, using a first utility function to obtain the index of the parameter in the second array; wherein the second array stores the parameters of the first function; if the parameter of the first function is a string type, using a second utility function to obtain the index of the parameter in the second array; wherein the second array stores the parameters of the first function. In this embodiment, the implementation of the first function (such as the Document.append function) in the source code can be adapted in the bytecode. When an object in the source code calls the first function, the compiler's adaptation code can be called in the bytecode to execute the adaptation function for the first function (such as the jwst_Document_append function), thereby achieving processing and adaptation for different types of parameters.

[0011] In one possible implementation, the first utility function includes the `dom_registerPrimitive` function, and the second utility function includes the `dom_registerPrimitiveString` function. Thus, based on the first and second utility functions, the index of the parameter in the heap array (equivalent to the second array) can be stored in the array array (equivalent to the first array).

[0012] In one possible implementation, the source code includes JavaScript source code, the glue code includes JavaScript glue code, and the bytecode includes WebAssembly binary bytecode. Understandably, the JavaScript programming language can run on various platforms, giving it good cross-platform compatibility. JavaScript also boasts a vast ecosystem of libraries and frameworks, making the development of complex applications more efficient and convenient. JavaScript is a dynamically typed language, where the type of variables is determined at runtime. This allows variables to hold different values ​​at different times, and developers can change the structure of objects and functions at runtime, increasing code writing flexibility. JavaScript glue code can act as "glue," bridging different systems or languages, enabling different parts of bytecode (such as WASM) to work together. WebAssembly binary bytecode can execute in web browsers or other WebAssembly runtime systems for higher execution performance.

[0013] Secondly, embodiments of this application provide a code adaptation apparatus, which may be an electronic device, a chip or chip system within an electronic device. The apparatus may include a processing unit. The processing unit is used to implement any processing-related method executed by the electronic device in the first aspect or any possible implementation of the first aspect. When the apparatus is an electronic device, the processing unit may be a processor. The apparatus may further include a storage unit, which may be a memory. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to cause the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect. When the apparatus is a chip or chip system within an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to cause the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect. The storage unit may be a storage unit within the chip (e.g., a register, cache, etc.), or a storage unit located outside the chip within the electronic device (e.g., read-only memory, random access memory, etc.).

[0014] Thirdly, embodiments of this application provide an electronic device including one or more processors and a memory, the memory being coupled to one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, and one or more processors being used to invoke the computer instructions to perform the method described in the first aspect or any possible implementation of the first aspect.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0016] Fifthly, embodiments of this application provide a computer program product including a computer program, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0017] Sixthly, this application provides a chip or chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to perform the methods described in the first aspect or any possible implementation of the first aspect. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0018] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0019] It should be understood that the second to sixth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0020] Figure 1 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0021] Figure 2 A schematic diagram of the software structure of an electronic device provided in an embodiment of this application;

[0022] Figure 3 A schematic diagram illustrating the generation of adaptation code by an adaptation code generation tool provided in an embodiment of this application;

[0023] Figure 4 A schematic diagram illustrating the execution flow of a code adaptation method provided in an embodiment of this application;

[0024] Figure 5 A schematic diagram illustrating the correspondence between JS glue code and WASM parameter indexes provided in an embodiment of this application;

[0025] Figure 6 This is a schematic diagram illustrating a cyclic adaptation process for different types of parameters provided in an embodiment of this application.

[0026] Figure 7 A schematic diagram illustrating a code adaptation method provided in an embodiment of this application;

[0027] Figure 8 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0028] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0029] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0030] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0031] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0032] The electronic devices in this application embodiment can also be any form of terminal device. For example, electronic devices may include: mobile phones, tablet computers, handheld computers, laptops, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, electronic devices in 5G networks, or future evolved public land mobile communication networks. The embodiments of this application do not limit the scope of electronic devices in a network (PLMN).

[0033] Furthermore, in this embodiment of the application, the electronic device can also be an electronic device in the Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection.

[0034] The electronic devices in the embodiments of this application may also be referred to as: user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device, etc.

[0035] In this embodiment, the electronic device includes a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and main memory. The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software.

[0036] For example, Figure 1 A schematic diagram of the hardware structure of the electronic device is shown.

[0037] The electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0038] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may include hardware, software, or a combination of software and hardware.

[0039] Processor 110 may include one or more processing units. For example, processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0040] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can directly retrieve it from the aforementioned memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system. For example, in the embodiments of this application, the processor 110 can be used to compile JS into WASM, and can also be used to generate adaptation code for variadic functions, etc.

[0041] Internal memory 121 can be used to store executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, etc. The data storage area may store data created during the use of the electronic device, etc. Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of the electronic device by running instructions stored in internal memory 121 and / or instructions stored in memory disposed in the processor. For example, in this embodiment, internal memory 121 may be used to store the source code of an application program, and related code of compiled binary instructions, etc.

[0042] Figure 2 This is a schematic diagram of the software structure of an electronic device according to an embodiment of this application.

[0043] For ease of description, the software architecture of electronic devices will be illustrated below using the Harmony operating system as an example. It should be noted that the embodiments of this application can also be applied to other operating systems (such as Android). ® System, Windows ® System, iOS ® (Systems, etc.) As long as the functions implemented by each functional module are similar to those in the embodiments of this application, the solution of this application can also be implemented.

[0044] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, HarmonyOS may include an application layer, a framework layer, a system infrastructure service layer, and a kernel layer, etc.

[0045] The application layer can include system applications and third-party applications, such as camera, gallery, and video applications. In some scenarios, the application layer can also be called the application layer.

[0046] The framework layer provides HarmonyOS applications with user program frameworks and meta-capability frameworks in multiple languages ​​such as Java, C, C++, and JavaScript, as well as multi-language framework application programming interfaces for various software and hardware services. In some scenarios, the framework layer can also be referred to as the application framework layer.

[0047] The system foundation service layer is the core capability set of the HarmonyOS system, supporting HarmonyOS in providing application services through the framework layer in multi-device deployment scenarios. The system foundation service layer may include, but is not limited to, one or more of the following components: system basic capability subsystem set, basic software service subsystem set, enhanced software service subsystem set, hardware service subsystem set, proprietary hardware service subsystem set, HarmonyOS driver framework, and hardware abstraction adaptation layer.

[0048] Among them, the system basic capability subsystem set provides the basic capabilities for the operation and scheduling of distributed applications on multiple devices of the HarmonyOS system, and can be composed of distributed task scheduling, distributed storage and data management, distributed soft bus, Ark runtime, distributed security and privacy protection, etc.

[0049] For example, in this embodiment, the Ark Runtime can be a unified compilation runtime platform designed to support the joint compilation and execution of multiple programming languages ​​and multiple chip platforms. The Ark Runtime supports multiple programming languages, including dynamically typed and statically typed languages, such as JS and WASM.

[0050] The basic software service subsystem provides common and general software services for HarmonyOS, and may consist of subsystems such as graphics and image software services and distributed media software services. The enhanced software service subsystem provides differentiated capability-enhancing software services for different devices, and may consist of subsystems such as tablet business software services and smart screen business software services. The hardware service subsystem provides common and adaptable hardware services for HarmonyOS, and may include subsystems such as power services. The proprietary hardware service subsystem provides differentiated hardware services for different devices, and may include subsystems such as tablet-specific hardware services and wearable-specific hardware services.

[0051] It is understandable that the above service subsystems can be deployed in different device configurations, and each subsystem can be tailored to its functional granularity.

[0052] The HarmonyOS driver framework and hardware abstraction adaptation layer are the foundation for the open hardware ecosystem of the HarmonyOS system. They provide hardware capability abstraction to the hardware at the top and development framework and runtime environment for various peripheral drivers at the bottom.

[0053] HarmonyOS employs a multi-kernel design, which may include the Linux kernel, the Harmony microkernel, and LiteOS. This design allows electronic devices with different capabilities to choose the appropriate system kernel.

[0054] The technical terms used in the embodiments of this application are described below.

[0055] 1. WebAssembly programming language: This is a programming language designed to improve the performance of web applications. It can also be understood as a cross-platform binary bytecode programming language that can execute in web browsers or other WebAssembly runtime systems to achieve higher performance. WebAssembly programming language can also be abbreviated as WASM.

[0056] 2. JS Glue Code: In the development process of compiling JavaScript into WASM, JS glue code can be understood as code that uses JavaScript to connect different components or modules together. It can also be understood as the main function of JS glue code acting as "glue," bridging different systems or languages ​​so that different parts of WASM can work together. JavaScript, also abbreviated as JS, is a programming language used for web application development.

[0057] 3. Linear memory: This is a contiguous memory space in WASM that can be accessed via memory indexes. The size of linear memory can be dynamically expanded at runtime, allowing WASM modules to efficiently manage memory during execution and interact with JavaScript.

[0058] 4. Variable-parameter function: A variable-parameter function is a function that can accept a variable number of arguments of different types. The number and type of arguments of a variable-parameter function are dynamically determined at the time of function call, allowing for flexible handling of different types and numbers of input arguments. In some scenarios, a variable-parameter function can also be called a variable-argument function.

[0059] In software development, high-level languages ​​such as C, Rust, or JavaScript can be compiled into WASM to achieve code migration and improved runtime performance. Taking JavaScript compilation into WASM as an example, the compiler needs to adapt the environment interaction between JavaScript and WASM during the compilation process.

[0060] In some implementations, binding code generation tools can use the Web Interface Definition Language (WebIDL) to generate binding code for the Document Object Model (DOM API). For example, binding code includes JS glue code and WASM runtime code, allowing developers to call the JS DOM API.

[0061] However, WASM's memory management and calling methods cannot directly adapt to the DOM API in JavaScript, especially DOM functions with variable arguments (which can also be understood as variadic functions). Therefore, when JavaScript is compiled into WASM, the compiler cannot directly support calls to variadic functions in the DOM API. In some implementations, the generated binding code can include multiple functions with a fixed number of parameters. For example, to adapt to the `console.log` function, the binding code can include multiple versions of the function, such as `console.log_0`, `console.log_1`, etc. Here, `console.log_0` represents the `console.log` function with 0 parameters, and `log_1` represents the `console.log` function with 1 parameter. This implementation not only makes the generated binding code consume more memory but also limits the dynamic nature of parameter changes. Consequently, WASM cannot effectively handle calls to variadic functions, increasing code development complexity and reducing execution efficiency.

[0062] In view of this, the code adaptation method provided in this application can adapt variable-argument functions (including the first function) by using a linear memory array (equivalent to the first array) shared between the JS glue code and WASM, thereby supporting the calling of variable-argument functions in the DOM API after JS is compiled into WASM. For example, when calling a variable-argument function of the Web platform DOM API, multiple parameters can be packaged into a unified array, and by passing the array index, the JS glue code can access these parameters when calling the DOM API. Then, these multiple parameters can be expanded according to the requirements of the variable-argument function, achieving adaptation and calling of variable-argument functions in the DOM API.

[0063] It is understood that the code adaptation method in this application optimizes the handling of dynamic parameters and provides a more concise and efficient mechanism for calling variable-parameter functions. When developing web applications using WASM, developers no longer need to write functions with multiple fixed numbers of parameters for variable-parameter functions, reducing code redundancy and size. Furthermore, variable parameters can be uniformly passed through linear memory arrays, achieving consistency between WASM and JS calling the DOM API, making WASM more concise in adapting variable-parameter function calls and reducing the complexity of web application development.

[0064] In summary Figure 1 and Figure 2 In one possible implementation of the described electronic device, the electronic device may include a compiler, such as a mobile terminal, tablet computer, or other electronic device with a built-in compiler. Optionally, the electronic device may obtain JS source code files or bytecode files from a server, and the compiler may adapt the functions (or methods) in the source code files or bytecode files.

[0065] In another possible implementation, the code adaptation method of this application embodiment can be applied to a compiler, which can be hosted in an integrated development environment (IDE) device. This compiler can be used to compile or optimize source code files or bytecode files, so that the compiled WASM code can adapt to calls to variable-parameter functions.

[0066] The compiler can also be called a JWST compiler or a JS-WASM compiler. Optionally, the compiler can be a modified version of the open-source QuickJS interpreter. For ease of description, the methods in the following embodiments of this application will be described using the JWST compiler as an example.

[0067] The code adaptation method of this application can serve as a logical guide for generating adaptation code for variable-parameter functions in the DOM API. It is understood that tools related to the JWST compiler may include adaptation code generation tools. After JS is compiled to WASM, this adaptation code generation tool can generate some adaptation code for the JWST compiler based on the input standard file (e.g., WebIDL), including the DOM API adaptation code generated by executing the code adaptation method of this application.

[0068] For example, Figure 3 The diagram illustrates how the adapter code generation tool generates adapter code.

[0069] like Figure 3 As shown, the adaptation code generation tool can generate JS glue code and runtime adaptation code based on the interface descriptions in WebIDL. The JS glue code can be understood as code used for adaptation on the JS side. It can be used to declare the data structures and functions required for adaptation, handle the loading and compilation instantiation of the WASM module, import functions into the WASM module, manage WASM linear memory, handle DOM API interactions, and provide a bridge for function calls between JS and WASM. The runtime code can be understood as code used for adaptation on the WASM side. It can be used to handle function calls on the WASM side, such as implementing variadic functions and parameter passing.

[0070] For the glue code on the JS side, the parameters passed between JS and WASM can be stored in a heap array within the required data structure for adaptation. These parameters can be objects or variables, and each parameter in the heap array can have a corresponding index value. Since objects cannot be directly passed between JS and WASM, but numerical values ​​can, in this embodiment, the index values ​​of objects or variables stored in the heap array can be stored in an array. This way, the passing of objects or variables can be transformed into the passing of their index values ​​within the heap array through the heap array and the array.

[0071] Here, the heap array can be understood as any possible array on the JS side, used to store parameters passed between JS and WASM. It's understood that using an array to store references to JS objects allows for random access. Naming it a heap array reflects its function; the array resembles an object heap, simulating WASM's heap management, but is applicable to JS objects. Optionally, the heap array can have other names, which are not limited in this embodiment.

[0072] An array can be understood as any possible array in linear memory, used to store the index values ​​of objects or variables in the heap array. An array can also be called a parameter array. Optionally, the array can have other names, which are not limited in this embodiment.

[0073] The required functions for adaptation include some utility functions. These utility functions can be used to retrieve parameters from the linear memory shared between JS and WASM, store them in a heap array, and return the indices of these parameters in the heap array. These utility functions need to be imported into the WASM side and used in the variadic function call implementation on the WASM side.

[0074] Imported functions can be imported when a WASM module is instantiated. Imported functions wrap calls to variadic functions in the DOM API. For example, taking the `Document.append` function in the DOM API as an example, `Document.append` is a variadic function, and imported functions can wrap it. Specific code examples of imported functions are shown in Table 1 below. Explanations of the imported function code can be found in the relevant descriptions in the corresponding embodiments of Table 1, and will not be repeated here.

[0075] For the runtime code on the WASM side, the code implementing the variadic function call can be used to construct an array, process the parameter types, and pass parameters according to different parameter types. For example, a partial code example of the JWST runtime for the Document.append function is shown in Table 2 below. Detailed code explanations can be found in the relevant descriptions in the corresponding embodiments of Table 2, and will not be repeated here.

[0076] Figure 4 A schematic diagram illustrating the execution flow of the code adaptation method according to an embodiment of this application is shown. The execution flow may include steps S401 to S405.

[0077] The S401 and JWST compilers allocate an array in linear memory on the WASM side.

[0078] As described above, an array can be understood as any possible array in linear memory. In a possible implementation, an array could be an array allocated on the WASM side to store parameter indices. Allocating an array can also be understood as creating an array and allocating memory space for it. This array can exist in linear memory shared between JS and WASM.

[0079] The S402 and JWST compilers store the index of the parameter in the heap array into the array array.

[0080] It is understandable that the heap array on the JS glue code side stores the actual parameters. In this embodiment, the JWST compiler can store the index values ​​of the actual parameters (objects or variables) stored in the heap array into the array. Through the heap array and the array, the passing of objects or variables is transformed into the passing of the index values ​​of objects or variables in the heap array.

[0081] For example, such as Figure 5 The diagram shows the correspondence between parameter indices passed between the JS glue code side and the WASM side.

[0082] The heap array in the JS glue code can include one or more parameters, such as object 2, object 3, ..., object n. Object 2 has an index of 1 in the heap array, object 3 has an index of 2, and so on, with object n having an index of n-1.

[0083] The JWST compiler can store the index values ​​of one or more parameters in the heap array into the array on the WASM side. For example, the index value 1 corresponding to object 2 can be stored in the first element of the array, the index value 2 corresponding to object 3 can be stored in the second element of the array, and so on, the index value n-1 corresponding to object n can be stored in the (n-1)th element of the array.

[0084] It is understood that the actual parameters stored in the heap array can be objects or variables. Objects can be DOM objects, function objects, etc. Variables can be strings or integers, or other basic data types; this embodiment does not impose such limitations. The JWST compiler can perform different adaptation processes based on the different data types of the parameters, thereby placing the indices of different types of parameters in the heap array into the array.

[0085] In a possible implementation, the JWST compiler can perform loop adaptation on multiple parameters of different types for a variadic function, and the loop flow can be as follows: Figure 6 As shown. In this context, multiple parameters of different types for a variadic function can also be understood as a set of parameters of different types.

[0086] When performing loop adaptation on the parameters of a variadic function, the JWST compiler can obtain the number of parameters in the variadic function. Therefore, the JWST compiler can determine whether all parameters have been processed based on the number of parameters.

[0087] If all parameters have been processed (which can also be interpreted as the loop not ending), the JWST compiler can determine the data type of the current i-th parameter. Here, i is an integer greater than or equal to 0 and less than the number of parameters. If the data type of the i-th parameter is an object type, such as a DOM object or a function object, then the runtime code on the WASM side already obtains the object's index in the heap array. Therefore, the JWST compiler can store the index of the i-th parameter in the heap array into the array.

[0088] If the data type of the i-th parameter is a basic type (such as string or integer), the JWST compiler can call different utility functions according to different basic types to store the index of the i-th parameter in the heap array into the array.

[0089] Understandably, since JS and WASM support numerical data transfer, if the parameter is a numeric type, the numeric type utility function can store the numeric parameter in a heap array and return the parameter's index in the heap array. If the parameter is a string type, the corresponding string type utility function can, on the JS glue code side, retrieve the string from linear memory based on its address and length in linear memory, store it in the heap array, and return the string's index in the heap array. Optionally, during the string retrieval process, it can also handle encoding and / or view-related processes.

[0090] Once all parameters have been processed, the JWST compiler can terminate the loop. This can also be understood as the JWST compiler having processed all parameters of the variadic function. Then, the wrapper function for the variadic function in the JS glue code can be executed, thus achieving code adaptation for the variadic function. For details, please refer to step S405 below for adapting the Document.append variadic function in the DOM API; it will not be elaborated upon here.

[0091] S403. Retrieve the array from linear memory and store it in the heap array.

[0092] Step S403 is similar to string passing; the JWST compiler can pass a reference to the array to the JS glue code side, store it in the heap array, and return the index of the array reference in the heap array. For example, using... Figure 5 For example, a reference to the array can be stored in the first element of the heap array, as object 1 in the heap array. That is, the index of the array in the heap array is 0.

[0093] It is understood that, in actual operation, the index value of the array in the heap array is not fixed at 0. The index of the array in the heap array needs to be determined according to the actual operation of the electronic device. This application does not limit this.

[0094] S404, Variable parameter function calls the index of the array in the heap array.

[0095] In a possible implementation, within the JavaScript glue code, a new wrapper function can be used to encapsulate calls to DOM variadic functions; in other words, it can be understood as wrapping the calls to variadic functions. This variadic function can include DOM variadic functions. It's understood that this wrapper function will be imported into the WASM module.

[0096] When a wrapper function of a variadic function is executed, the passed parameter is the index of the array within the heap array. This transforms parameter passing between JavaScript and WASM into passing indices between the two. The wrapper function can then access the array using its index within the heap array and retrieve or use one or more parameters based on their indices within the array.

[0097] S405. Extract each actual parameter and expand it.

[0098] Wrap functions can expand an array using the "..." operator, find the actual parameters by index, and then call the implementation of the native variadic function.

[0099] For example, the `Document.append` function in the DOM API is used to illustrate the code adaptation method of this application embodiment. The `Document.append` function is a variadic function in the DOM API used to add one or more nodes to a document. The `Document.append` function is part of a `Document` object and can be used to add element nodes, text nodes, or other types of nodes to a specified parent node. The `Document.append` function can accept variable arguments, which may include a single node, multiple nodes, text strings, or other DOM objects.

[0100] In JavaScript glue code, a new wrapper function can be used to wrap calls to the Document.append function. This wrapper function will be imported into the WASM module. The wrapper function can be shown in Table 1 below.

[0101] It should be noted that the code involved in the embodiments of this application is exemplary code, and the code in the actual implementation may differ from the exemplary code in the embodiments of this application. For example, the relevant code in Table 1 of this application embodiment is used to show partial code examples of the wrapper function of the append function on the JS glue code side. The relevant code in Table 2 is used to show partial code examples of the append function adapted by the JWST runtime. The code in the actual implementation may differ from the code in Table 1 or Table 2, and this application embodiment does not limit it.

[0102] Understandably, the key to this wrapper function lies in the parameter arg1 and ...getObjectArray(arg1). Here, arg1 is used to indicate the index of the array in the heap array, and ...getObjectArray is used to retrieve the array from the heap array and expand it to pass the parameters.

[0103] As can be seen from the code in Table 1, the code adaptation method of this application embodiment can adapt to variable-parameter functions, allowing variable-parameter functions to pass a variable number of parameters, making function calls more flexible. Callers can pass different numbers of parameters according to actual needs, without needing to generate multiple import functions and function signatures based on the number of parameters. Thus, adapting variable-parameter functions in this application embodiment can reduce code duplication, improve code maintainability and reusability, thereby reducing code size and optimizing the memory space of electronic devices.

[0104] Table 1

[0105]

[0106] In a possible implementation, the implementation of the `Document.append` function can be adapted within the JWST runtime code. When an object in the JS source code calls the `Document.append` function, it triggers the JWST runtime on the WASM side to call the JWST compiler's adaptation code, executing the adaptation function for `Document.append`, namely the `jwst_Document_append` function. The `jwst_Document_append` function can handle and adapt parameters of different types.

[0107] For example, the example code in Table 2 below is an adapted implementation of the `jwst_Document_append` function from the DOM API, which is an adaptation of the `Document.append` function. The `jwst_Document_append` function can adapt to DOM variable parameter functions by converting the parameters called by JS into a format suitable for languages ​​such as C.

[0108] In the first line of code, the `jwst_Document_append` function can include parameters, parameter types, and a return type. The parameter `ctx` can be a pointer to a `JSContext` structure, representing the execution context of the current code. The parameter `this_val` is used to reference the current object within the function; it can also be understood as the object that calls the `dom_Document_append` function. The parameter `argc` indicates the number of arguments passed to the function. The parameter `argv` is a pointer to an array of type `JSValueConst`, which can contain the values ​​of the arguments passed to the `jwst_Document_append` function.

[0109] The return type of the jwst_Document_append function can be a JSValue data type, such as numbers, strings, objects, etc. Optionally, the jwst_Document_append function may not have a return value; the specific implementation can be determined according to the actual situation, and this application embodiment does not limit it.

[0110] In line 2, the JS_GetRawOpaqueUInt function is used to get the index of the shadow object in the JS-side heap array, which is an unsigned 32-bit integer (uint32_t) and assigned to the variable this_raw.

[0111] In this context, the shadow object can be understood as a mapping of the actual object in the JavaScript glue code to the JWSt runtime. Specifically, references to the actual object are stored in the heap array on the JavaScript glue code side, while the WASM side stores the object relationships between the references to the actual objects and their indices in the heap array. There is a one-to-one correspondence between the shadow object and the actual object. The shadow object does not actually contain the property content or method implementations; these are implemented in the actual object within the JavaScript glue code.

[0112] In line 3, the `malloc` function dynamically allocates memory, with the allocated memory size being `argc` signed 64-bit integers (`int64_t`). Line 3 indicates that a block of heap memory capable of storing `argc` `int64_t` integers has been allocated, and its starting address has been assigned to the pointer `args`. The pointer array `args` can be understood as the `array` mentioned above.

[0113] The size of the pointer array args is not fixed and can be related to the number of arguments argc. For example, the pointer array args can be argc signed 64-bit integers.

[0114] Understandably, the way these parameters are represented in memory varies depending on their type. For example, for basic type parameters, they are first stored in the heap using the JS-imported interface, and their corresponding indices are obtained. Then, these indices are added to the array. For DOM object type parameters, their indices in the heap are used to add them to the array. Therefore, lines 4 through 24 require a loop to process parameters of different types.

[0115] Line 5 is the conditional branch that checks if the parameter type is an object. Object types can include DOM objects and function objects; DOM objects can be understood as objects related to the Document Object Model. The `JS_VALUE_GET_TAG(argv[i])` function retrieves the type tag of `argv[i]`, which can be object, number, string, etc. `JS_TAG_OBJECT` indicates that the type tag is an object type.

[0116] The JS_VALUE_GET_PTR function in line 6 is used to extract the pointer to the i-th element from the array argv[i], convert it to a JSObject pointer type, and assign it to the pointer variable my_obj.

[0117] Line 7 of the code indicates the branch used to determine if the parameter type is a function object. Here, JS_CLASS_BYTECODE_FUNCTION represents the type identifier of the bytecode function, and this line of code indicates that it determines whether it is a bytecode function based on the class_id attribute. The specific process for processing the function object can be determined according to the actual situation, and this embodiment does not limit it.

[0118] Line 10 is the branch that determines if the parameter type is a DOM object. In line 10, the `JS_GetRawOpaqueUInt` function retrieves the index of a signed 64-bit integer from the array `argv[i]` and assigns it to the pointer array `args`. This can also be understood as retrieving the index of the shadow object in the heap and assigning that index to the pointer array `args`.

[0119] Line 12 is used to indicate the conditional branch that checks if the parameter type is a string.

[0120] The `JS_ToCString` function in line 13 converts a JavaScript value into a C-style string, specifically a `const char*` type. The `JS_ToCString` function takes two arguments: `ctx`, which indicates the current JavaScript execution context, and the `i`th element of the array `argv[i]`. Line 13 then converts the string corresponding to the `i`th element of `argv[i]` into a C-style string and assigns it to a pointer `str_ptr` that points to a constant character (`char`).

[0121] Line 14 is used to calculate the length of the string pointed to by the pointer str_ptr and assign it to the unsigned 32-bit integer variable str_len.

[0122] The `dom_registerPrimitiveString` function in line 15 is a utility function. This utility function takes a parameter `str_ptr` representing a pointer to the string and a parameter `str_len` representing the string's length. This utility function is used in the JavaScript glue code to store the string in memory indicated by the parameters into a heap array and returns its index.

[0123] Optionally, the process of retrieving a string from memory may also require handling encoding and view-related processes.

[0124] Line 16 indicates that the memory pointed to by the pointer str_ptr is being released. This memory was understandably allocated in line 13 when the JS_ToCString function converted a JSValue value to a C string.

[0125] Line 18 indicates a conditional branch that checks if the parameter type is other than an integer. The `JS_VALUE_GET_INT` function extracts the integer value of the i-th element from the array `argv[i]`. The `dom_registerPrimitive` function is a utility function whose parameter is the integer value returned by `JS_VALUE_GET_INT`. This utility function converts the parameter to a signed 64-bit integer and assigns it to the i-th element of the pointer array `args`. Alternatively, it can be understood as the utility function storing the integer value in the heap array and assigning the returned heap array index to `args[i]`.

[0126] In line 21, the `dom_addHeapArrayFromJwst64` function can be used to manipulate the heap array, such as storing or retrieving data from it. The JavaScript side obtains a pointer array `args` using the parameters `args` and `argc`. This pointer array `args` stores `argc` index values. These index values ​​are indices within the heap array, and each index corresponds to a JavaScript object.

[0127] The `dom_addHeapArrayFromJwst64` function can also store a pointer array `args` into a heap array and return the index of `args` within the heap array. In other words, it returns the index of the `array` within the heap array, represented by `idx`. If the above... Figure 5 For example, the index of the array in the heap array is 0.

[0128] Line 22 of the code calls the `dom_Document_append` function, enabling the JavaScript glue code to execute the `dom_Document_append` wrapper function listed in Table 1. This allows the `dom_Document_append` wrapper function to expand and pass parameters based on the index values ​​in the array, thus enabling the calling of variadic functions.

[0129] For example, as described above Figure 5 For example, in the `dom_Document_append` function, you can retrieve parameters from the heap array based on the index value in the array. For instance, you can retrieve object 2 from the heap array using index 0 in the array; you can retrieve object 3 from the heap array using index 1 in the array; and so on, you can retrieve object n from the heap array using index n-1 in the array.

[0130] Afterwards, the jwst_Document_append function can also release the allocated memory and return the result.

[0131] Table 2

[0132]

[0133] Optionally, this application embodiment can also be applied to any variadic function, such as the addEventListener function, querySelectorAll function, etc., and this application embodiment is not limited thereto. The addEventListener function can be used to add an event listener to a specified DOM element. When the specified event is triggered on the DOM element, the corresponding callback function will be executed. The querySelectorAll function can be used to return a list of elements in the document that match a specified cascading style sheets (CSS) selector group, i.e., a NodeList. This NodeList is an array-like object, and elements can be accessed by index.

[0134] Figure 7 This application illustrates a code adaptation method according to an embodiment of the present application. Applied to electronic devices, the method includes:

[0135] S701, Call the first function of the source code. The first function is a function with variable parameters.

[0136] In this embodiment, the source code can be written in any possible programming language. For example, the source code may include the JS source code (or JS source code) mentioned above. Taking JS source code as an example, JS source code can be understood as project code, that is, the code of a web application. The JS source code may include calls to the DOM API. The first function can be a function in the DOM API, for example, the first function may include the Document.append function mentioned above.

[0137] S702. When the source code is compiled into bytecode, the index of the parameter of the first function in the second array is saved to the first array; the second array is used to store the parameters passed between the glue code and the bytecode, and the second array includes the parameters of the first function.

[0138] Bytecode can be understood as binary bytecode, which can be used to execute in an execution environment such as a virtual machine or interpreter. For example, bytecode can include the WASM binary bytecode (or WASM code) mentioned above. Taking JS source code as an example again, JS source code can be compiled into WASM code by a JWST compiler or a JS-WASM compiler.

[0139] In this embodiment, glue code can be understood as code generated to adapt to the DOM API. Glue code can include various functions and data structures such as wrapper functions, helper functions, and heap arrays. For example, glue code can include the JS glue code mentioned above, which is code generated on the JS side to adapt to the DOM API.

[0140] The parameters of the first function can be understood as all the parameters of the first function. The number of parameters of the first function can vary depending on the calling scenario; that is, the first function may include one or more parameters. This application does not limit the number of parameters of the first function.

[0141] The first array can be understood as the "array" mentioned above, and the second array can be understood as the "heap" array mentioned above. For details on array and heap arrays, please refer to [link / reference needed]. Figure 3 Corresponding embodiments or Figure 4 The relevant descriptions in the corresponding embodiments will not be repeated. S703: Call the second function of the glue code, call the first function in the second function, and pass the third function as a parameter to the first function. The third function is used to obtain the first array and obtain the parameter of the first function based on the index stored in the first array.

[0142] In this embodiment, the second function can be understood as the wrapper function mentioned above, such as the dom_Document_append function. A wrapper function can be understood as one function encapsulating another function to add extra functionality when called from the source code. For example, a wrapper function can be understood as the second function encapsulating the first function, thereby achieving adaptation to the variable parameter function (equivalent to the first function).

[0143] The third function can be understood as the function mentioned above used to obtain the array and expand the parameters, such as the getObjectArray(arg1) function.

[0144] It is understandable that after the glue code is adapted to the DOM API, the Document.append function call in the source code will execute the jwst_Document_append function mentioned above at runtime, which will then further call the wrapper function, namely the dom_Document_append function.

[0145] In this embodiment, the adaptation of variadic functions (including the first function) can be achieved through a linear memory array (equivalent to a first array) shared between the glue code and the bytecode, thereby supporting the calling of variadic functions (including the first function) in the DOM API after the source code is compiled into bytecode. For example, when calling a variadic function of the Web platform DOM API, multiple parameters can be packaged into a unified array, and by passing the array index, the glue code can access these parameters when calling the DOM API. These multiple parameters can then be expanded according to the requirements of the variadic function, achieving adaptation and calling of variadic functions in the DOM API.

[0146] This optimizes the handling of dynamic parameters and provides a more concise and efficient mechanism for calling variadic functions. Developers no longer need to write functions with a fixed number of parameters for variadic functions when developing web applications, reducing code redundancy and size. Furthermore, variadic parameters can be uniformly passed through linear memory arrays, ensuring consistency between source code and bytecode calls to the DOM API. This makes bytecode implementations for adapting variadic function calls more concise, reducing the complexity of web application development.

[0147] Optional, in Figure 7 Based on the corresponding embodiment, the parameter of the third function is the index of the reference of the first array in the second array. The third function also includes a target operator, which is used to instruct the third function to obtain the parameter of the first function based on the index stored in the first array. The third function is used to obtain the first array and obtain the parameter of the first function based on the index stored in the first array. This may include: the third function obtaining the first array based on the index of the reference of the first array in the second array; and obtaining the parameter of the first function from the second array based on the index stored in the first array according to the target operator.

[0148] In this embodiment, the third function can be understood as the ...getObjectArray(arg1) function mentioned above. The parameter arg1 of the third function can be the index of the array reference within the heap array. For example... Figure 5 For example, the index of the array reference in the heap array can be 0. In some scenarios, the index of the array reference in the heap array can also be simply referred to as the index of the array in the heap array.

[0149] The target operator can be understood as the "..." operator. In the second function (i.e., the wrapper function), the "..." operator expands the array, finds the actual parameters based on the index, and thus calls the implementation of the native variadic function. The third function can retrieve the array based on the index of the array reference in the heap array; and based on the target operator and the index stored in the array, retrieve the parameters of the first function from the heap array.

[0150] The code adaptation method in this application can adapt to variable-parameter functions, allowing these functions to pass a variable number of parameters, making function calls more flexible. Callers can pass different numbers of parameters according to actual needs, without needing to generate multiple import functions and function signatures based on the number of parameters. Thus, adapting to variable-parameter functions in this application reduces code duplication, improves code maintainability and reusability, thereby reducing code size and optimizing the memory space of electronic devices.

[0151] Optional, in Figure 7 Based on the corresponding embodiment, when the source code is compiled into bytecode, the method may further include: saving a reference to the first array into the second array.

[0152] In this embodiment of the application, saving the reference of the first array to the second array can be understood as saving the reference of the array array to the heap array. For example, as described above... Figure 5 Taking a corresponding embodiment as an example, a reference to the array can be stored in the first element of the heap array, as object 1 in the heap array. That is, the index value of the array in the heap array is 0. In some scenarios, saving a reference to the array into the heap array can also be simply referred to as saving the array into the heap array.

[0153] It is understood that, in actual operation, the index value of the array in the heap array is not fixed at 0. The index of the array in the heap array needs to be determined according to the actual operation of the electronic device. This application does not limit this.

[0154] It is understood that, through the heap array and array array, the passing of objects or variables can be transformed into the passing of the index values ​​of objects or variables in the heap array. This satisfies the requirement that source code (such as JS source code) and bytecode (such as WASM) do not directly pass objects, but rather pass numerical values, thereby achieving adaptation to variable parameter functions.

[0155] Optional, in Figure 7 Based on the corresponding embodiment, before saving the index of the parameter of the first function in the second array to the first array, it may further include: obtaining the parameter of the first function from the second array based on the data type of the parameter of the first function.

[0156] In this embodiment, the data type of the parameter can be an object or a variable. The object can be a DOM object, a function object, etc. The variable can also be a string or an integer, or other basic data type; this embodiment does not impose any limitations.

[0157] Specifically, the process of retrieving the parameters of the first function from the second array based on the data type of the first function's parameters can be referred to the implementation of the jwst_Document_append function in the corresponding embodiment in Table 2. This application embodiment can perform different adaptation processes based on the different data types of the parameters, placing the indices of different types of parameters in the heap array into the array array, thereby processing and adapting different types of parameters based on the jwst_Document_append function.

[0158] Optional, in Figure 7 Based on the corresponding embodiments, retrieving the parameters of the first function from the second array based on the data type of the parameters of the first function may include: if the parameters of the first function are of object type, retrieving the index of the parameters of the first function in the second array; wherein the second array stores references to the parameters of the first function; if the parameters of the first function are of integer type, retrieving the index of the parameters of the first function in the second array using a first utility function; wherein the second array stores the parameters of the first function; if the parameters of the first function are of string type, retrieving the index of the parameters of the first function in the second array using a second utility function; wherein the second array stores the parameters of the first function.

[0159] In this embodiment, the object type includes Document Object Model (DOM) objects and function objects, etc. For details regarding the determination of the object type parameter, please refer to the implementation of lines 5 to 11 in the corresponding embodiment in Table 2, as well as the related descriptions of lines 5 to 11, which will not be repeated here.

[0160] The first utility function can be understood as the `dom_registerPrimitive` function in the corresponding embodiment in Table 2. This utility function converts the parameter into a signed 64-bit integer and assigns it to the `array` array. Alternatively, it can be understood as storing the integer value in the `heap` array and assigning the returned index of the `heap` array to the `array` array. For details regarding the determination of the integer parameter, please refer to the implementation of lines 17 to 19 in the corresponding embodiment in Table 2, as well as the related descriptions of lines 17 to 19, which will not be repeated here.

[0161] The second utility function can be understood as the `dom_registerPrimitiveString` function in the corresponding embodiment of Table 2. This function stores the string in memory indicated by the parameter into a heap array on the JS glue code side and returns its index. Alternatively, it can be understood that the second utility function can retrieve the string from linear memory based on its address and length in linear memory, store it in a heap array, and return the string's index in the heap array. For details regarding the determination of the string type parameter, please refer to the implementation of lines 12 to 16 in the corresponding embodiment of Table 2, as well as the related descriptions of lines 12 to 16, which will not be repeated here.

[0162] In this embodiment, the implementation of the first function (such as the Document.append function) in the source code can be adapted within the bytecode. When an object in the source code calls the first function, the compiler's adaptation code can be called in the bytecode to execute the adaptation function for the first function, such as the jwst_Document_append function, thereby enabling the processing and adaptation of different types of parameters.

[0163] Optional, in Figure 7 Based on the corresponding implementation, the first utility function includes the dom_registerPrimitive function, and the second utility function includes the dom_registerPrimitiveString function.

[0164] In this embodiment, the first utility function and the second utility function can be described in the above optional steps, and will not be repeated here. Based on the first utility function and the second utility function, the index of the parameter in the heap array can be stored in the array.

[0165] Optional, in Figure 7 Based on the corresponding implementation, the source code includes JS source code, the glue code includes JS glue code, and the bytecode includes WebAssembly binary bytecode.

[0166] In this embodiment, JavaScript (JS) is a programming language used for web application development. JS source code can be understood as code written using the JS programming language. For details, please refer to the description of JS source code in step S701, which will not be repeated here. It is understood that the JS programming language can run on various platforms, including browsers, servers, and mobile electronic devices, giving it good cross-platform compatibility. JS also boasts a vast ecosystem of libraries and frameworks, making the development of complex applications more efficient and convenient. JS is a dynamically typed language, where the type of variables is determined at runtime. This allows variables to hold different values ​​at different times, and developers can change the structure of objects and functions at runtime, improving the flexibility of code writing.

[0167] The specific JavaScript glue code can be found in the description of the JavaScript glue code in the above examples, and will not be repeated here. The JavaScript glue code can be used as "glue" to bridge different systems or languages, enabling different parts of bytecode (such as WASM) to work together.

[0168] The specific WebAssembly binary bytecode can be found in the description of the WebAssembly programming language in the examples above, and will not be repeated here. The WebAssembly binary bytecode can be executed in a web browser or other WebAssembly runtime systems to achieve higher execution performance.

[0169] The above detailed embodiments have provided a comprehensive description of the purpose, technical solutions, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific implementation methods of the embodiments of this application and are not intended to limit the scope of protection of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of the embodiments of this application should be included within the scope of protection of the embodiments of this application.

[0170] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0171] The foregoing mainly describes the technical solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that the method steps described in conjunction with the embodiments of this application can be implemented in hardware or a combination of hardware and software. Whether a function is executed in a hardware-driven or software-driven manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0172] This application provides an electronic device that may include one or more processors and a memory. The memory is coupled to one or more processors. The memory may be used to store computer program code, which includes computer instructions. The one or more processors may invoke the computer instructions to cause the electronic device to execute the technical solutions described above.

[0173] This application provides a chip system. This chip system is applied to an electronic device and may include one or more processors. The one or more processors can be used to invoke instructions to cause the electronic device to execute the technical solutions described above.

[0174] Figure 8 This is a schematic diagram of a chip system provided in an embodiment of this application. The chip system 800 includes one or more processors 801, communication lines 802, communication interfaces 803, and memory 804.

[0175] In some implementations, memory 804 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof.

[0176] The methods described in the embodiments of this application can be applied to, or implemented by, processor 801. Processor 801 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 801 or by instructions in software form. Processor 801 may be a general-purpose processor (e.g., a microprocessor or conventional processor), DSP, application-specific integrated circuit, off-the-shelf programmable gate array (FPGA), or other programmable logic device, discrete gate, transistor logic device, or discrete hardware component. Processor 801 can implement or execute the processing-related methods, steps, and logic block diagrams in the embodiments of this application.

[0177] The method described in this application can be implemented using a hardware decoding processor, or by a combination of hardware and software modules within the decoding processor. The software modules can be located in the memory 804, and the processor 801 can read information from the memory 804 and, in conjunction with its hardware, complete the steps of the method described above. The processor 801, the memory 804, and the communication interface 803 can communicate via the communication line 802.

[0178] This application also provides a readable storage medium (also referred to as a computer-readable storage medium). The readable storage medium includes computer instructions. When these computer instructions are executed on an electronic device, they cause the electronic device to perform the technical solutions described in the above embodiments.

[0179] The methods described in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored or transmitted on a readable medium as one or more instructions or programs. The readable medium can include storage media and communication media, and can also include any medium that can transfer a program from one place to another. The storage medium can be any accessible target medium.

[0180] In possible implementations, the readable medium may include random access memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, optical disc read-only memory, or other optical disc storage. The readable medium may also include disk storage or other disk storage devices, or be directed to any other medium or store the required program in the form of instructions or data structures, and be accessible.

[0181] This application also provides a program product (also referred to as a computer program product). The program product includes computer program code. When the computer program code runs on an electronic device, it causes the electronic device to execute the technical solutions described in the above embodiments.

[0182] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between the various embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0183] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A code adaptation method, characterized in that, Applied to electronic devices, the method includes: Call the first function in the source code; the first function is a function with variable arguments. When the source code is compiled into bytecode, the index of the parameter of the first function in the second array is saved to the first array; the second array is used to store the parameters passed between the glue code and the bytecode, and the second array includes the parameters of the first function; The second function of the glue code is called, and the first function is called in the second function. The third function is passed as a parameter to the first function. The third function is used to obtain the first array and obtain the parameter of the first function based on the index stored in the first array.

2. The method as described in claim 1, characterized in that, The parameter of the third function is the index of the reference to the first array in the second array. The third function also includes a target operator, which instructs the third function to retrieve the parameter of the first function based on the index stored in the first array. The third function is used to obtain the first array and, based on the index stored in the first array, obtain the parameters of the first function, including: The third function retrieves the first array based on the index of the reference to the first array in the second array; Based on the target operator and the index stored in the first array, the parameters of the first function are obtained from the second array.

3. The method as described in claim 1 or 2, characterized in that, When the source code is compiled into bytecode, the method further includes: Save the reference of the first array into the second array.

4. The method according to any one of claims 1-3, characterized in that, Before saving the index of the parameter of the first function in the second array to the first array, the method further includes: Based on the data type of the parameters of the first function, the parameters of the first function are obtained from the second array.

5. The method as described in claim 4, characterized in that, The step of obtaining the parameters of the first function from the second array based on the data type of the parameters of the first function includes: If the parameter of the first function is an object type, obtain the index of the parameter of the first function in the second array; wherein, the second array stores references to the parameters of the first function; If the parameter of the first function is an integer, the first utility function is used to obtain the index of the parameter of the first function in the second array; wherein, the second array stores the parameter of the first function; If the parameter of the first function is a string, the second utility function is used to obtain the index of the parameter of the first function in the second array; wherein the second array stores the parameter of the first function.

6. The method as described in claim 5, characterized in that, The first utility function includes the dom_registerPrimitive function, and the second utility function includes the dom_registerPrimitiveString function.

7. The method according to any one of claims 1-6, characterized in that, The source code includes JS source code, the glue code includes JS glue code, and the bytecode includes WebAssembly binary bytecode.

8. An electronic device, characterized in that, The electronic device includes: one or more processors and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-7.

9. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product includes computer program code that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1-7.

Images