Hardware and software cooperative extension method of virtual linear memory and electronic equipment

Abstract

The application provides a hardware and software cooperative extension method of virtual linear memory and an electronic device. The hardware and software cooperative extension method of virtual linear memory provided by the application comprises a hardware unit of virtual linear memory, hardware for realizing address conversion and mapping, and a set of instructions related to memory operation adaptation to the hardware unit. Specifically, during advance compilation, instructions in a program are converted into instructions of virtual linear memory, such as reading, writing, memory size, memory increase and the like. During running, memory is directly accessed through the instructions provided by the application, and boundary checking is directly completed based on the hardware, so that the computing cost of the electronic device is greatly reduced.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and in particular to hardware and software collaborative expansion methods and electronic devices for virtual linear memory. Background Technology

[0002] Embedded microcontroller units (MCUs) are widely used in terminal devices in the Internet of Things (IoT) field due to their advantages such as low power consumption, low cost, and small size. For example, smart wearable devices, smart home devices, and other smart devices are all equipped with embedded MCUs. However, due to the cost limitations of MCUs, low-end electronic devices often lack a memory management unit (MMU) and a memory protection unit (MPU), allowing third-party applications to access all physical addresses with the same permissions as the operating system.

[0003] When an electronic device lacks an MMU and MPU, all third-party applications have the same permissions as the operating system, allowing them to access and execute system-level instructions. Clearly, the malicious execution of system-level instructions by a third-party application, or memory access errors occurring during access by a third-party program, can all affect the normal operation of the electronic device.

[0004] To ensure secure isolation between the operating system and third-party applications on electronic devices, preventing third-party applications from arbitrarily accessing and executing system-level instructions, the open-source WebAssembly (WASM) provides a method for achieving secure isolation between third-party applications and the operating system. WebAssembly provides a linear memory for third-party applications, specifying that the logical addresses accessible to the third-party application are limited to a contiguous range. When the third-party application performs memory-related operations, the operating system performs boundary checks, ensuring that the third-party application can only access and execute instructions within the corresponding linear memory. Correspondingly, if an error occurs during memory access operations, it will only be confined to the application itself and will not propagate to the external environment.

[0005] While WebAssembly's linear memory enables secure isolation between third-party applications and the operating system, firstly, third-party applications need to access linear memory indirectly through pointers, increasing the system's computational overhead and register load; secondly, to prevent third-party applications from overflowing linear memory, boundary checks are required when accessing the contents of linear memory, which leads to a sharp increase in code size, increasing the storage space occupied by third-party applications, and the boundary checks themselves also increase the device's computational overhead. Summary of the Invention

[0006] This application provides a hardware and software collaborative method for expanding linear memory, as well as an electronic device. The method includes: during pre-compilation, converting program instructions into virtual linear memory instructions, such as read, write, memory size, and memory increment instructions. At runtime, memory is directly accessed using the instructions provided in this application, and boundary checks are directly performed based on the hardware, significantly reducing the computational overhead of the electronic device. Furthermore, this method also supports features such as Multiple Per-Module Memory in WebAssembly.

[0007] In a first aspect, a hardware and software collaborative expansion method for virtual linear memory is provided. The processor of an electronic device includes a virtual linear memory unit, which is used to manage part or all of the physical memory on the electronic device. The method includes: the electronic device acquiring a first file, which includes a WASM bytecode file of a first application; when the electronic device compiles the first file in advance, the electronic device converts a first instruction in the first file into a corresponding second instruction; the first instruction is a normal memory access instruction, and the second instruction is an instruction for accessing the memory managed by the virtual linear memory unit through the virtual linear memory unit.

[0008] In the above embodiments, when the electronic device compiles the application in advance, it translates read / write instructions into read / write instructions based on virtual linear memory units, thereby enabling direct access to linear virtual memory based on virtual linear memory units. This method initially achieves secure isolation between the application and the operating system.

[0009] In conjunction with some embodiments of the first aspect, in some embodiments, when the electronic device compiles the first program in advance, the electronic device converts the third instruction into a corresponding fourth instruction; the third instruction includes a memory increase instruction and a memory size instruction, and the fourth instruction is used to call the interface provided by the runtime so that when the electronic device runs the first file, the electronic device can increase memory or determine memory size based on the fourth instruction calling the interface provided by the runtime.

[0010] In the above embodiments, the electronic device translates memory increase and memory size instructions into calls to a runtime interface, enabling the electronic device to determine the memory size allocated to an application and to change the application's memory size. Furthermore, when changing the application's memory size, the application's base address remains unchanged, avoiding the overhead caused by memory fragmentation resulting in the entire application being swapped in and out of memory.

[0011] In conjunction with some embodiments of the first aspect, in some embodiments, when the electronic device executes the second instruction, it performs boundary checks based on virtual linear memory units.

[0012] In the above embodiments, since the electronic device converts the first instruction into the second instruction, the electronic device does not need to generate boundary check code for the first instruction during pre-compilation; secondly, the boundary check is performed by the virtual linear memory unit hardware during the execution of the second instruction, which reduces the size of the file after pre-compilation.

[0013] In conjunction with some embodiments of the first aspect, in some embodiments, the electronic device compiles the first file in advance to obtain a first executable file; when the electronic device runs the first executable file, the electronic device allocates virtual linear memory for the first executable file based on the virtual linear memory unit; the virtual linear memory is contiguous in physical memory, or the virtual linear memory is discontinuous in physical memory.

[0014] In the above embodiments, when the electronic device runs a pre-compiled application, it allocates virtual linear virtual memory for the application based on linear memory units.

[0015] In conjunction with some embodiments of the first aspect, in some embodiments, when the electronic device switches the first executable file to the background, the electronic device saves the configuration information corresponding to the first executable file.

[0016] In the above embodiments, when an electronic device switches tasks, it needs to save the configuration information of the virtual linear memory unit of the application being switched to the background.

[0017] In conjunction with some embodiments of the first aspect, in some embodiments, when the electronic device switches the first executable file to the foreground, the electronic device restores the configuration information corresponding to the first executable file.

[0018] In the above embodiments, when the electronic device switches tasks, it needs to restore the configuration information of the virtual linear memory unit of the application that was switched to the foreground so that the application can run normally.

[0019] In conjunction with some embodiments of the first aspect, in some embodiments, the one or more virtual linear memory blocks are configured with independent base addresses, read / write permissions, and sizes.

[0020] In the above embodiments, when the electronic device switches tasks, it needs to restore the configuration information of the virtual linear memory unit of the application that was switched to the foreground so that the application can run normally.

[0021] In conjunction with some embodiments of the first aspect, in some embodiments, the electronic device acquires a second file, the second file including a WASM bytecode file of a second application; when the electronic device compiles the second file in advance, the electronic device converts the first instruction in the second file into the corresponding second instruction; the read / write permissions of the first program on the first memory are different from the read / write permissions of the second program on the first memory, the first memory corresponding to a continuous physical address in the physical memory of the electronic device.

[0022] In the above embodiments, different programs running on the electronic device have different access permissions to the same physical address, ensuring secure isolation between different applications.

[0023] In conjunction with some embodiments of the first aspect, in some embodiments, the first program and the second program have the same execution level / privilege level.

[0024] In the above embodiments, the first application and the second application are not configured with privileged states or have the same privileged states, thereby avoiding the overhead caused by privileged state switching.

[0025] Secondly, this application provides an electronic device comprising: one or more processors and a memory; the memory is coupled to the one or more processors, the one or more processors including a virtual linear memory unit for managing part or all of the physical memory on the electronic device, the memory storing computer program code including computer instructions, the one or more processors calling the computer instructions to cause the electronic device to execute: acquiring a first file, the first file including a WASM bytecode file of a first application; when compiling the first file in advance, converting a first instruction in the first file into a corresponding second instruction; the first instruction being a normal memory access instruction, and the second instruction being an instruction for accessing the memory managed by the virtual linear memory unit through the virtual linear memory unit.

[0026] In the above embodiments, when the electronic device compiles the application in advance, it translates read / write instructions into read / write instructions based on virtual linear memory units, thereby enabling direct access to linear virtual memory based on virtual linear memory units. This method initially achieves secure isolation between the application and the operating system.

[0027] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: when compiling the first program in advance, converting the third instructions into corresponding fourth instructions; the third instructions include memory increment instructions and memory size instructions, and the fourth instructions are configured to invoke a runtime-provided interface so that when the electronic device runs the first file, it can invoke the runtime-provided interface based on the fourth instructions to increase memory or determine memory size.

[0028] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to perform: when executing the second instruction, a boundary check is performed based on a virtual linear memory unit.

[0029] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to perform: compiling the first file in advance to obtain a first executable file; when running the first executable file, allocating virtual linear memory for the first executable file based on the virtual linear memory unit; the virtual linear memory is contiguous in physical memory, or the virtual linear memory is discontinuous in physical memory.

[0030] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to perform: when switching the first executable file to the background, saving the configuration information corresponding to the first executable file.

[0031] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to perform: when switching the first executable file to the foreground, restore the configuration information corresponding to the first executable file.

[0032] In conjunction with some embodiments of the second aspect, in some embodiments, the virtual linear memory unit provides one or more virtual linear memory blocks for the first executable file.

[0033] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more virtual linear memory blocks are configured with independent base addresses, read / write permissions, and sizes.

[0034] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: acquiring a second file, the second file including a WASM bytecode file of a second application; when compiling the second file in advance, converting the first instruction in the second file into the corresponding second instruction; the read / write permissions of the first program on the first memory are different from the read / write permissions of the second program on the first memory, the first memory corresponding to a contiguous physical address in the physical memory of the electronic device.

[0035] In conjunction with some embodiments of the second aspect, in some embodiments, the first program and the second program have the same execution level / privilege level.

[0036] Thirdly, embodiments of this application provide a chip system applied to an electronic device. The chip system includes one or more processors, which are used to invoke computer instructions to cause the electronic device to perform the methods described in the first aspect, the second aspect, and any possible implementation of the first aspect.

[0037] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an electronic device, cause the electronic device to perform the method described in the first aspect and any possible implementation thereof.

[0038] Fifthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect and any possible implementation thereof.

[0039] It is understood that the electronic device provided in the second aspect, the chip system provided in the third aspect, the computer program product provided in the fourth aspect, and the computer storage medium provided in the fifth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0040] Figure 1 This is an exemplary schematic diagram illustrating the relationship between physical and virtual addresses involved in this application.

[0041] Figure 2A , Figure 2B This is an exemplary schematic diagram of the MMU function involved in this application.

[0042] Figure 3 This is an exemplary schematic diagram of the linear memory function involved in this application.

[0043] Figure 4 This is an exemplary schematic diagram illustrating the working principle of the compiler involved in this application.

[0044] Figure 5 This is an exemplary schematic diagram of the MPU function involved in this application.

[0045] Figure 6 This is an exemplary schematic diagram of the virtual linear memory unit interaction process provided in the embodiments of this application.

[0046] Figure 7 This is an exemplary schematic diagram illustrating the principle of the virtual linear memory unit provided in the embodiments of this application.

[0047] Figure 8 This is an exemplary schematic diagram of the unified address mapping mode provided in the embodiments of this application.

[0048] Figure 9 This is an exemplary schematic diagram of a method for adapting relevant instructions during the advance compilation process provided in this application embodiment.

[0049] Figure 10 An exemplary schematic diagram illustrating the adaptation processing for memory size (memory.size) and memory growth (memory.grow) provided in the embodiments of this application.

[0050] Figure 11A , Figure 11B This is an exemplary schematic diagram illustrating the implementation of the memory increment method provided in the embodiments of this application.

[0051] Figure 12 This is an exemplary schematic diagram illustrating the method for loading, starting, and executing target files provided in the embodiments of this application.

[0052] Figure 13 This is an exemplary schematic diagram of a target program for obtaining WASM bytecode format provided in an embodiment of this application.

[0053] Figure 14 This is an exemplary schematic diagram illustrating the saving and restoration of virtual linear memory configuration information in a multi-target program scenario provided in this application embodiment.

[0054] Figure 15 This is an exemplary schematic diagram of the hardware structure of the electronic device 100 provided in the embodiments of this application.

[0055] Figure 16 This is an exemplary schematic diagram of the software structure of the electronic device 100 provided in the embodiments of this application. Detailed Implementation

[0056] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0057] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0058] First, for ease of understanding, the relevant terms and concepts involved in the embodiments of this application will be introduced below. The terminology used in the embodiments section of this invention is only used to explain specific embodiments of the invention and is not intended to limit the invention.

[0059] (1) Physical address, virtual address

[0060] A physical address is an address that can be recognized and accessed by specific physical hardware. A virtual address is an address that can be recognized and accessed by applications within the operating system.

[0061] When a target program is compiled, assembled, and linked to generate executable binary machine code, it is mapped into the virtual address space. For operating systems that use virtual memory, the addresses given in the instructions are virtual addresses. When the CPU executes instructions, it must first translate the virtual addresses into physical addresses before it can access main memory to fetch instructions and data. Address translation is performed by the memory management unit (MMU) within the CPU.

[0062] Figure 1 This is an exemplary schematic diagram illustrating the relationship between physical and virtual addresses involved in this application.

[0063] like Figure 1As shown, when the electronic device runs target program 1 and target program 2 respectively, it executes the same "call virtual address" instruction. However, for different target programs, the same virtual address is translated into different physical addresses by the MMU. For example, when the CPU executes the "call virtual address" instruction of target program 1, it actually accesses physical address 1; when the CPU executes the "call virtual address" instruction of target program 2, it actually accesses physical address 2.

[0064] Figure 2A , Figure 2B This is an exemplary schematic diagram of the MMU function involved in this application.

[0065] like Figure 2A As shown, when a device does not have an MMU, regardless of whether it is an operating system or a target program, the CPU accesses the actual physical address during execution. In other words, the memory address issued by the CPU is directly transmitted to the memory chip via the bus.

[0066] In this situation, malicious target programs or bugs can access and modify data at any physical address, thereby affecting the normal operation of electronic devices.

[0067] like Figure 2B As shown, when a device has a memory management system (MMU), regardless of whether it's an operating system or a target program, the address accessed by the CPU during execution is received by the MMU; this address is a virtual address. After receiving it, the MMU translates the address into an actual physical address and sends it to memory. In other words, the memory address issued by the CPU is first received by the MMU, which then translates it into another memory address (the actual physical address) before sending it to the memory chip via the bus.

[0068] It is understandable that when an electronic device is equipped with an MMU, the MMU can achieve secure isolation between different applications, as well as secure isolation between applications and the operating system.

[0069] It is worth noting that the hardware module that implements the address translation mapping function can also be implemented by other hardware units, and is not limited to the MMU.

[0070] (2) Linear memory (LM)

[0071] In the Wasm standard, linear memory is an abstract random access memory (RAM). Linear memory supports addressing at the byte level and can dynamically grow in pages within a limited range.

[0072] When instantiating a WASM module, a linear memory object, such as an ArrayBuffer, needs to be created for that module. A module is a distributable, loadable, and executable unit of code in WASM. Similar to an array, the index can be viewed as a memory address, which is the address or pointer visible to the program.

[0073] Figure 3 This is an exemplary schematic diagram of the linear memory function involved in this application.

[0074] First, different target programs have independent linear memory, and the target programs can directly read and write the contents of the linear memory. Second, before the target program operates on the instructions and data in the linear memory through indexes, the WASM engine will perform boundary checks to ensure that the target program will not access the contents outside the authorized space, that is, it will not access the contents outside the linear memory of the target program.

[0075] like Figure 3 As shown, the linear memory indices for target program 1 are 1 to 7, corresponding to physical addresses 4 to 10 on the device. When the target program accesses memory through index 7, it calculates the physical address of the linear memory base plus the index to obtain the physical address 10, and then accesses it. When the target program accesses linear memory at index 8, the engine triggers an exception during boundary checks, preventing target program 1 from accessing the out-of-bounds physical address 11, thus ensuring memory safety.

[0076] Understandably, firstly, the target program accessing memory via pointers is indirect access, which increases computational load and register pressure. Secondly, memory address accesses that are uncertain at compile time require boundary checking code to be inserted at compile time, leading to a significant increase in the size of the compiled output file.

[0077] (3) Compiler

[0078] A compiler is a functional module that translates one language into another. Most compilers translate the source code of a target program into machine code. The compiler is responsible for executing the compilation steps in the program processing.

[0079] To reduce the complexity of compiler implementation and improve its scalability, the compiler can be divided into a front-end, a middle-end, and a back-end, with each component implemented independently. The front-end is primarily responsible for preprocessing, lexical analysis, syntax analysis, and semantic analysis, generating an intermediate representation (IR) for subsequent processing. The middle-end performs analysis and various optimizations, such as constant folding and dead code elimination. The back-end generates target code (compiled code or machine code), which is platform-specific assembly code. If only one compiler exists during program processing, it will further translate the assembly code into machine code after generating the target code. If an assembler also exists during program processing, it will convert the assembly code into machine code.

[0080] The following is based on Figure 4 The content shown is used as an example to illustrate how a compiler works.

[0081] Figure 4 This is an exemplary schematic diagram illustrating the working principle of the compiler involved in this application.

[0082] like Figure 4 As shown, the compiler identifies the programming language used by the program based on the program source code, analyzes it according to the lexical, syntactic, and semantic definitions of the programming language, and then generates a machine-independent intermediate code (IR) sequence. The IR sequence is also a representation of the program, but it is compiler-oriented and needs to be understood and processed by the compiler. The platform-independent IR is then translated by the compiler backend into machine code that is specific to the hardware and platform.

[0083] The compiler for the WebAssembly (WASM) language involved in this application compiles the source program into binary format. There are two types of binary format: one is the WASM binary format, which is platform-independent and, when used with the WASM runtime, is equivalent to JAVA bytecode. The WASM binary format can be further translated into the target machine code binary format.

[0084] It's worth noting that, to help developers understand the WASM module, WASM also provides an easier-to-understand text format.

[0085] (4) Ahead-of-time compilation (AOT)

[0086] In operating systems, target programs typically have three compilation and execution methods: interpreted execution, ahead-of-time compilation, and just-in-time compilation.

[0087] Interpreted execution includes: the interpreter interprets and executes one or more bytecode lines.

[0088] Ahead-of-time compilation involves the compiler further translating bytecode into machine object code and storing it on storage media. It's worth noting that ahead-of-time compilation occurs before the application runs, such as during application installation.

[0089] Just-in-time (JIT) compilation involves compiling bytecode into machine object code for execution at the moment it is loaded or interpreted at runtime. The results of JIT compilation exist only in runtime memory and are not stored on storage media.

[0090] The machine code for different platforms can be different, and the code for different target programs on different platforms can be in different high-level languages ​​such as C, Java, Python, etc.

[0091] For example, when the source code of the target program is in C language, the machine code compiled in different ways can be assembly language; when the source code of the target program is in Java language, since the Java target program is executed in the virtual machine, the Java target program is first compiled into bytecode files and loaded into the Java Virtual Machine. At this time, the virtual machine can execute the bytecode into machine code through interpretation and just-in-time compilation.

[0092] Understandably, for electronic devices with limited memory and computing resources, the target program spends some time compiling during installation to generate machine target code, which can improve the startup speed of the target program.

[0093] Secondly, the following section introduces the method for achieving memory security in electronic devices involved in this application, as well as the difficulties in applying the ahead-of-time compilation technique in WebAssembly to the MCU platform.

[0094] In traditional computer and laptop operating systems, security isolation between target programs and between target programs and the operating system is mainly achieved through virtual memory mechanisms and privileged mode division.

[0095] The isolation between target programs includes: using hardware modules with address translation and mapping functions, such as MMU, to ensure that the virtual address spaces of different target programs are independent of each other and do not affect each other, and the target programs can only operate on data on the virtual address.

[0096] The isolation between the target program and the operating system includes: the system execution level can be divided into user mode and kernel mode, with the operating system kernel running in kernel mode and the target program running in user mode. User-mode programs cannot arbitrarily manipulate the kernel address space, thus achieving secure isolation between the operating system and the target program.

[0097] In kernel mode, the CPU can execute privileged instructions, such as instructions for accessing special registers and accessing input / output (I / O) mapped addresses, as well as non-privileged instructions. If the CPU is in user mode, it can only execute non-privileged instructions. Switching between user mode and kernel mode can be achieved through system calls, exceptions, and peripheral interrupts. Kernel mode can be referred to as privileged mode, privileged mode, or supervisor mode; correspondingly, user mode can be referred to as non-privileged mode, normal mode, or user mode, etc., without further elaboration here.

[0098] When a user-mode CPU accesses memory, it needs to send the memory address to the MMU in order to access the actual physical address; while when a kernel-mode CPU accesses memory, it can directly send the memory address to the memory chip and directly access the actual physical address.

[0099] It is worth noting that the CPU's execution state can be divided into more levels.

[0100] Understandably, considering that the CPU does not know whether the instructions it executes come from the target program or the operating system, in order to prevent the target program from arbitrarily executing privileged instructions and causing electronic devices to malfunction, the switching between kernel mode and user mode allows the target program to switch to kernel mode by jumping to the operating system's code, thus initially achieving secure isolation between the operating system and the target program. Secondly, in user mode, the target program's access to memory is restricted by hardware modules such as the address translation mapping function of the MMU, and it cannot access or modify the kernel address space, further ensuring secure isolation between the target program and the operating system.

[0101] However, it is obvious that this switching between privileged and non-privileged states inherently incurs overhead. Secondly, for electronic devices lacking hardware modules with address translation mapping capabilities such as an MMU, virtual memory mechanisms cannot achieve secure isolation between the target program and the operating system.

[0102] To ensure memory security in electronic devices that do not have an MMU, an MPU can be configured.

[0103] Methods to ensure memory security in electronic devices include configuring an MPU (Multi-Processor Unit). The MPU also introduces a similar privileged state separation strategy, and utilizes the MPU to partition physical memory into segments with defined permissions. This ensures that a specific memory region only provides authorized access to a particular execution level, while unauthorized access triggers a processor exception.

[0104] When executing functions, the MPU operates on a region-by-region basis. A region is a contiguous block of addresses that must also meet conditions such as boundary alignment. Different regions can be configured with different execution levels.

[0105] For example, many STM32 devices include an MPU (Memory Management Unit). The MPU can independently configure multiple memory regions, and each region can be further configured into multiple sub-regions. Different regions can be configured with different read, write, and other operation permissions. When the processor accesses a region in memory, the MPU compares the region's access permissions with the current processor mode. If the request meets the region's access criteria, the MPU allows the processor to access it; if the request does not meet the region's access criteria, the MPU generates an exception signal to prevent the processor from accessing it.

[0106] However, because the MPU cannot provide a mechanism similar to virtual memory, bugs or malicious programs can use common instructions such as Load and Store to address any physical address. This can, in turn, compromise the integrity of the program's control flow.

[0107] Figure 5 This is an exemplary schematic diagram of the MPU function involved in this application.

[0108] like Figure 5 As shown, the memory can be divided into different regions by the MPU, and different privileged states or permissions can be set for different regions. For example, target program 1 is in user mode or non-privileged state, and target program 2 is in administrator mode or privileged state. From the perspective of target program 1, region 1 has read and write permissions, region 2 has read-only permissions, region 3 has read-only permissions, and region 4 has no permissions; while from the perspective of target program 2, region 1 has read-only permissions, region 2 has read and write permissions, region 3 has no permissions, and region 4 has read-only permissions. Among them, regions 1 and 2 are located in the RAM of the electronic device; regions 3 and 4 are located in Flash memory / ROM.

[0109] For example, RAM space used as a communication buffer, designated as region 5, can be configured as non-executable to prevent malicious code injection during communication. As another example, some programs may need to copy code into SRAM for execution, or copy vector tables into SRAM to improve access speed. After copying the code or vector tables, the memory space can be designated as a region, and this region can be defined as read-only to prevent accidental modification of the memory space.

[0110] It is understandable that by configuring permissions in different privilege states or modes through the MPU, memory safety between target programs and between target programs and the operating system can be achieved.

[0111] However, there are still many limitations in the implementation of MPU hardware functions. For example, overly strict boundary requirements can greatly increase the memory overhead of electronic devices. On processors such as Cortext-M4 / M7, the boundaries of MPU Regions must be aligned to their own size. If a 1MB Region is defined, its boundaries must be aligned to the starting position of an integer MB.

[0112] However, achieving secure isolation between target programs on an MPU requires leaving I / O functionality within the system kernel. This necessitates switching to kernel mode when the target program performs I / O operations. Clearly, switching execution levels between kernel and user mode increases the computational and memory overhead of the electronic device. Furthermore, as the number of I / O operations increases, the computational and memory overhead rises dramatically, impacting the smooth operation of the target program.

[0113] To reduce the computational overhead caused by privileged state switching from additional hardware such as MPUs and MMUs, WebAssembly technology can be used to ensure secure isolation between programs and between programs and the operating system at the software level. Furthermore, the ahead-of-time compilation technique within WebAssembly can be used to compile the target program in advance, thereby improving program startup speed and reducing memory consumption.

[0114] However, the ahead-of-time compilation technique in WebAssembly, when directly applied to the MCU platform, still faces some unresolved issues, including:

[0115] First, during the early compilation of the target program, because the target program contains external symbols with uncertain addresses, such as external library functions, boundary checking code needs to be inserted at compile time for these uncertain memory accesses. Memory accesses can be performed using read / write instructions, and most instruction sets require the inclusion of read / write instructions.

[0116] It is worth noting that, in order to distinguish them from the read / write instructions provided in the embodiments of this application, the original read / write instructions are referred to as ordinary memory access instructions. These ordinary memory access instructions are related to the architecture and platform of the electronic device.

[0117] Understandably, the insertion of boundary check code causes a dramatic increase in the size of the target file output after the target program is pre-compiled, thereby increasing the memory overhead of electronic devices. Furthermore, the insertion of boundary check code alters the program control flow of the target program, affecting subsequent program optimization and preventing the target program from running smoothly.

[0118] Secondly, the memory access model of WebAssembly differs from that of the MCU. WebAssembly uses linear memory access, and when the MCU performs memory access operations, it needs to translate the index in WebAssembly into an indirect memory access operation consisting of the physical base address of linear memory and the index. For the terminology explanation, please refer to the textual description of linear memory (LM) in (2), which will not be repeated here.

[0119] It is worth noting that on 32-bit MCUs, memory access operations are translated into indirect memory access operations using linear physical base addresses and indices, which may cause integer overflows, making it very difficult to eliminate boundary check code through static analysis.

[0120] Finally, the WebAssembly standard defines the `memory.grow` instruction for dynamically increasing linear memory space to meet the dynamic memory access needs of programs. However, MCUs on electronic devices use a unified physical address space, and expanding linear memory may not maintain the base address of the linear memory. Furthermore, updating the base address of linear memory involves modifying the target program's stack and registers. The base address of linear memory can reside in a general-purpose register.

[0121] It is worth noting that it is impossible to combine WebAssembly technology with an additional hardware MPU to simultaneously achieve memory safety and improve the performance of the target program.

[0122] Secondly, the hardware and software collaborative expansion method for virtual linear memory provided in the embodiments of this application will be described below by way of example.

[0123] Firstly, this application provides a processor hardware functional module for providing virtual linear memory (vlm): a virtual linear memory unit (vlmn). This virtual linear memory unit can provide one or more virtual linear memory blocks (vlmb) for the target program.

[0124] Each virtual linear memory block can be independently configured with parameters including: physical address base, read / write permissions, and enable bits. This configuration can be achieved through corresponding I / O mapping registers. Reading / writing these configuration parameters can be accomplished using peripheral operation instructions from the Target Instruction Set Architecture (ISA).

[0125] The virtual linear memory unit provided in this application embodiment can provide one or more virtual linear memory units for the target program, and the target program can operate on the virtual linear memory unit, such as reading, writing, adding memory, determining memory size, memory expansion, memory migration, etc. Furthermore, when executing memory access instructions, boundary checks are performed by hardware rather than by code generated at compile time.

[0126] The virtual linear memory unit provided in this application embodiment can realize the conversion between physical address and virtual address through hardware.

[0127] Secondly, the embodiments of this application further provide read and write access instructions based on virtual linear memory.

[0128] When the CPU executes read or write access instructions, it can access the virtual linear memory provided by the virtual linear memory unit.

[0129] The format of read instructions is similar to that of read instructions for the target platform's memory. The source operand can be mem (a memory unit in assembly), and the destination operand can be a general purpose register (GPR). If multiple VLMBs are allocated for the virtual linear memory unit, an immediate value is added to indicate the number of the VLMB accessed by the read instruction, such as vlmid.

[0130] When implementing the virtual linear memory-based read instruction provided in this application embodiment, the read instruction can be invoked using a method such as `vlm.load.sz GPR,mem[,vlmid]`. Here, `mem` is the memory access format supported by the target ISA, such as offset (GPR) form, or immediate form, etc., which is not limited here. `.sz` represents the number of bits loaded, which can be 8, 16, 32, etc. For a 64-bit target ISA, `.sz` can also be 64. If the mapping `vlm.load.sz GPR,mem[,vlmid]` does not exist, a processor exception is triggered; or a bit in the processor status register is rewritten to notify the application to process the instruction.

[0131] Among them, the write instructions based on virtual linear memory include:

[0132] The format of the write instruction is similar to that of the memory write instruction on the target platform. The source operand can be a general-purpose register, and the destination operand can be mem. When implementing the read instruction based on virtual linear memory provided in the embodiments of this application, the read instruction can be invoked in a manner such as vlm.store.sz mem[,vlmid],GPR.

[0133] It is worth noting that the memory read / write instructions of the target platform can be converted into the read / write instructions provided in the embodiments of this application; that is, ordinary memory access instructions are converted into the read / write instructions provided in the embodiments of this application. In the following description, the terms "load instruction" and "store instruction" will be used to refer to ordinary memory access instructions.

[0134] Third, embodiments of this application also provide instructions for implementing virtual address to physical address translation.

[0135] When the CPU executes the physical address to virtual address translation instruction, the input is the physical address and the output is the virtual address corresponding to the physical address; when the CPU executes the virtual address to physical address translation instruction, the input is the virtual address and the output is the physical address.

[0136] This instruction can be used to quickly translate virtual addresses into physical addresses, resulting in a physical address, which is then stored in the GPR. Failure may trigger a processor exception or modify control bits.

[0137] For example, the format of this instruction is cvt.vlm.phy GPR,mem[,vlmid]. This instruction takes a virtual address in a virtual linear memory unit as input and outputs the physical address corresponding to that virtual address. The hardware logic for implementing this instruction is consistent with the hardware logic for finding the physical address through the VLM address when implementing the read instruction vlm.load and the write instruction vlm.store.

[0138] Alternatively, the `cvt.vlm.phy GPR,mem[,vlmid]` instruction can be implemented in software without hardware, using VLMU configuration information to map virtual addresses to physical addresses. For example, in Multi-VLMB Mode, the instruction `cvt.vlm.phy Rd,Rs,32,0` can be equivalent to the following code implementation:

[0139]

[0140]

[0141] Here, Rd can be considered as the physical address that needs to be determined; Rs is the known virtual address.

[0142] Specifically, if `VLMB.EN||Rs+32>=VLMB[0].Size` checks if the virtual linear memory block is enabled and not out of bounds (VLMB.EN=1, then the virtual linear memory block is enabled; VLMB.EN=0, then the virtual linear memory block is not enabled; || represents OR; VLMB[0].Size represents the size of the first virtual linear memory block), the physical address Rd is calculated as: virtual linear memory block + virtual address (VLMB[0].Base represents the base address of the first virtual linear memory block), where the virtual address is equivalent to an offset, index, or pointer. If the virtual linear memory block is not enabled, or if an out-of-bounds error occurs, `trap` will trigger a processor exception or modify the control bits.

[0143] Correspondingly, this instruction can also be used to achieve a fast conversion from physical address to virtual address, i.e., the result is a virtual address, and the converted physical address is stored in GPR; failure may cause a processor exception or modify control bits.

[0144] The format of this command can be cvt.phy.vlmmem[,vlmid],GPR

[0145] Similar to the rapid change from virtual address to physical address, the rapid change from physical address to virtual address can be implemented in hardware or software. If we consider the rapid change from virtual address to physical address as a forward mapping, then the rapid change from physical address to virtual address can be considered the inverse or reverse mapping of this forward mapping.

[0146] It is worth noting that the hardware circuit that implements the fast translation from virtual address to physical address can be different from the hardware circuit that implements the translation from physical address to virtual address. That is, in an electronic device, there are two different hardware circuits used to implement the fast translation from virtual address to physical address and the fast translation from physical address to virtual address, respectively.

[0147] It's worth noting that during the rapid conversion between physical and virtual addresses in Multi-VLMB mode, the conversion may cross virtual linear memory block boundaries, resulting in potentially discontinuous physical addresses. In such cases, several methods can be employed. For example, leveraging the fixed size of Multi-VLMB, the boundary-crossing portion can be segmented; alternatively, virtual linear memory space data can be directly read using `vlm.store` / `vlm.load` within runtime functions; or block data transfer can be performed using Direct Memory Access (DMA), etc. These methods are not limited here.

[0148] Fourth, the embodiments of this application provide multiple access modes for virtual linear memory.

[0149] Users can configure the control registers of virtual linear memory units to enable or disable any mode, allowing them to disable corresponding functions when virtual linear memory is not needed, thereby reducing power consumption. Different modes, such as Unified VLMB Mode and multiple virtual address modes, can also be selected by configuring the control registers.

[0150] The unified address mapping mode is primarily used to implement dynamic linear memory expansion on processors that do not support an MMU, and to resolve the problem of contiguous address space allocation failures caused by memory fragmentation. In implementation, if the unified address mode is enabled, virtual linear memory blocks are organized into a contiguous virtual address space according to their numbers (vlmid), and the physical base addresses of virtual linear memory blocks with different numbers can be contiguous or non-contiguous.

[0151] The multiple virtual address mode is primarily used to support the multiple per-module memory feature of WebAssembly. In implementation, if multiple virtual address mode is enabled, each virtual linear memory block has an independent virtual address space, physical base address, and offset mapping; each virtual linear memory block can be configured with different access permissions, such as read-write permissions or read-only permissions.

[0152] It is worth noting that, in any mode, corresponding DMA instructions can be designed to realize data transfer operations between virtual linear memory space data blocks and physical address space.

[0153] After introducing the virtual linear memory, virtual linear memory unit, and virtual linear memory block provided in the embodiments of this application, the working process and working principle of the virtual linear memory unit are described below by way of example.

[0154] Figure 6 This is an exemplary schematic diagram of the virtual linear memory unit interaction process provided in the embodiments of this application.

[0155] like Figure 6As shown, when the CPU does not have a virtual linear memory unit configured, read / write operations can be performed directly on data at physical addresses using the `load` instruction and the `store` instruction. When the CPU has a virtual linear memory unit configured, it can support memory access operations performed directly using the `load` and `store` instructions, and it can also support memory access operations performed by the CPU through the virtual linear memory unit. Specifically, when the CPU performs memory access operations through the virtual linear memory unit, the read instruction executed by the CPU is `vlm.load`, and the write instruction executed by the CPU is `vlm.store`. The virtual linear memory unit can translate the virtual address into a physical address before performing the corresponding memory access operation.

[0156] Figure 7 This is an exemplary schematic diagram illustrating the principle of the virtual linear memory unit provided in the embodiments of this application.

[0157] like Figure 7 As shown, a virtual linear memory unit can be configured with multiple virtual linear memory blocks through a control register. The physical address range corresponding to the virtual linear memory block numbered 0 is from 0x2000_8000 to 0x2000_8FFF.

[0158] Understandably, virtual linear memory units are responsible for mapping / conversion between physical addresses and virtual addresses.

[0159] The configuration information for the virtual linear memory unit is shown in Table 1 below.

[0160] Table 1

[0161]

[0162] Table 1 shows an exemplary schematic diagram of the configuration information of the virtual linear memory unit provided in the embodiments of this application.

[0163] As shown in Table 1 above, virtual linear memory units can be configured by configuring the contents shown in Table 2 in the control register. The parameters that need to be configured include the number vlmid, permission PERMISSION, base address, and size. Unconfigured parameters use default values.

[0164] Understandable Figure 6 and Figure 7 The virtual address in the corresponding text description can be understood as an index / pointer in WebAssembly, and then the memory access operation of linear memory in WebAssembly is realized through virtual linear memory units.

[0165] The following is a combination of Table 2 and... Figure 8 An example is provided to illustrate the configuration of the same virtual address mode.

[0166] Table 2

[0167]

[0168]

[0169] Table 2 is an exemplary schematic table of unified address mapping mode configuration information provided in the embodiments of this application.

[0170] Figure 8 This is an exemplary schematic diagram of the unified address mapping mode provided in the embodiments of this application.

[0171] like Figure 8 As shown in Table 2 above, virtual linear memory units can be configured to achieve a unified address mapping mode. Clearly, a virtual linear memory unit operating in unified address mapping mode can be configured with multiple virtual memory unit blocks of the same or different sizes.

[0172] From the perspective of the target program, the virtual addresses or indices / pointers corresponding to multiple virtual memory blocks of the same or different sizes are contiguous; however, from the perspective of the electronic device, the physical addresses corresponding to multiple virtual memory blocks of the same or different sizes may be non-contiguous.

[0173] Understandably, virtual linear memory units can reduce the probability of contiguous address space allocation failures caused by memory fragmentation by allocating multiple virtual memory unit blocks of the same or different sizes, thereby improving memory utilization efficiency.

[0174] Understandably, the virtual linear memory provided in this application does not require the processor's general-purpose registers to store the linear memory base address, thereby reducing register pressure and facilitating the generation of more efficient backend code. Furthermore, changes to the base address are transparent to the target program, reducing the impact of runtime pointer / index updates on the program.

[0175] After introducing the concepts of virtual linear memory, virtual linear memory unit, and virtual linear memory block provided in the embodiments of this application, the hardware and software collaborative expansion method based on virtual linear memory and other hardware provided in the embodiments of this application are described by way of example. The software collaborative expansion method mainly includes two aspects: first, the adaptation processing when the compiler executes memory access instructions; and second, the adaptation processing between the runtime and the operating system.

[0176] First, in the existing WebAssembly early compilation process, the original memory access instructions are adapted to support the memory access instructions provided in this application's embodiments. Second, adaptation processing for memory size (memory.size) and memory growth (memory.grow) instructions needs to be added, and bulk-memory expansion operations of WebAssembly need to be supported.

[0177] Secondly, it requires corresponding support from the operating system and runtime, such as initializing virtual linear memory units and implementing related callback functions. It can also save the configuration information of one or more virtual linear memory units to save and restore the relevant states during multi-target program switching.

[0178] First, the adaptation processing for memory access instructions is introduced. The adaptation processing for memory access instructions mainly includes: obtaining information such as offset and identifier ID from the instruction encoding of the original read / write instructions, and converting the original read / write instructions into the virtual linear memory-based read / write instructions provided in the embodiments of this application based on this information.

[0179] Figure 9 This is an exemplary schematic diagram of a method for adapting relevant instructions during the advance compilation process provided in this application embodiment.

[0180] like Figure 9 As shown, during pre-compilation, memory access instructions need to be adapted, specifically including three types of instructions: read / write instructions, memory size / increment instructions, and memory-bulk instructions.

[0181] The adaptation handling for read / write instructions includes:

[0182] Information is obtained from the instruction encoding of ordinary memory access instructions, and read / write instructions provided in this application embodiment are generated based on that information.

[0183] Specifically, information such as `align`, `offset`, and `id` can be obtained from the instruction encoding of the existing read instruction `store` and write instruction `load`, and then the base address `base` can be obtained from the operand stack. Next, after obtaining the `align`, `offset`, `id`, and `base` information, the corresponding inline function calls are generated. In the compiler backend, these intrinsic functions are directly translated into the corresponding `vlm.load` and `vlm.store` instructions.

[0184] For example, information such as align, offset, and id can be obtained using the following code.

[0185] align = read_leb_unit32();

[0186] offset = read_leb_unit32();

[0187] id = read_leb_unit32();

[0188] base = POP();

[0189] ptr = base + offset;

[0190] After obtaining information such as align, offset, id, and base, the read operation is completed using the corresponding vlm.load directive. For example, a read operation can be implemented using the following code.

[0191] res=emit_vlm_load(ptr,align,id);

[0192] emit_excep_handle_code();

[0193] PUSH(res);

[0194] In the code above, `res` is the value to be read, `emit_vlm_load` is the corresponding `vlm.load` instruction, `emit_excep_handle_code()` is the exception code used to return the code of the corresponding error, and `PUSH(res)` can push the data to be read off the stack.

[0195] Similarly, after obtaining information such as align, offset, id, and base, the write operation is completed using the corresponding vlm.store directive. For example, a write operation can be implemented using the following code.

[0196] value = POP();

[0197] res=emit_vlm_store(ptr,align,id,value);

[0198] In the code above, emit_vlm_store is the corresponding vlm.store directive, and value is the value to be written.

[0199] It is worth noting that in some cases, if sign bit extension or zero padding is required, the corresponding instructions of the target platform's ISA will be invoked for processing.

[0200] It is worth noting that in some cases, vlmid can be ignored if multiple virtual address modes are not supported or not required; however, if multiple virtual address modes are enabled, memidx (immediate value) needs to be translated into vlmid (immediate value).

[0201] Understandably, when implementing the `vlm.load` and `vlm.store` instructions, the corresponding read and write operations are performed through `emit_vlm_load` and `emit_vlm_store`. Since the virtual linear memory unit can determine the range of physical addresses corresponding to any target program based on the configuration information, if `ptr` is within that range, the corresponding operation is performed directly; if `ptr` is not within that range, the virtual linear memory will not allow the program to access content within the physical address range, thus completing the boundary check. Therefore, it is not necessary to generate boundary check code at compile time.

[0202] Understandably, using memory access instructions supported by virtual linear memory to replace ordinary memory access instructions, while using hardware mechanisms to implement boundary checks, simplifies the code and control flow, which is beneficial for compiler backend optimization and reduces the size of object files. It also eliminates the need for dedicated or general-purpose registers to store the program's base address in memory.

[0203] The adaptation handling for memory size (memory.size) and memory growth (memory.grow) includes:

[0204] The compiler calls runtime APIs ahead of time. In other words, WebAssembly needs to call APIs in the WebAssembly micro-runtime (WAMR) to achieve adaptive handling of memory size (memory.size) and memory growth (memory.grow).

[0205] Figure 10 An exemplary schematic diagram illustrating the adaptation processing for memory size (memory.size) and memory growth (memory.grow) provided in the embodiments of this application.

[0206] like Figure 10 As shown, the memory size instruction and its implementation can be achieved in the following way.

[0207] For example, the size of memory can be determined using the following code.

[0208] func="wasm_runtime_memory_size";

[0209] ret = build_call(func);

[0210] PUSH(ret);

[0211] wasm_runtime_memory_size is an API provided by WAMR for determining memory size, and ret is the return value of this API. By calling wasm_runtime_memory_size, the size of the memory can be determined.

[0212] Similarly, memory can be increased, for example, by using the following code.

[0213] delta = POP();

[0214] func="wasm_runtime_enlarge_memory";

[0215] ret = build_call(func);

[0216] PUSH(ret);

[0217] wasm_runtime_enlarge_memory is an API provided by WAMR for increasing memory allocation. ret is the return value of this API. By calling wasm_runtime_memory_size, you can increase the memory allocation.

[0218] The adaptation handling for bulk-memory extensions includes:

[0219] The data transfer can be accomplished using DMA instructions, such as the `emit_vlm_dma_intrinsic` function. The compiler backend can translate `emit_vlm_dma_intrinsic` into corresponding library calls or custom instruction sequences. DMA instructions can implement various modes, such as COPY mode and FILL mode, which are not limited here.

[0220] COPY mode includes copying between virtual linear memory and physical addresses, and copying between virtual linear memory locations; FILL mode includes assigning scalar values ​​to virtual linear memory. For example, OP_FILL refers to FILL mode, OP_COPY_V2V refers to copying between virtual linear memory locations in COPY mode, OP_COPY_V2P refers to copying virtual linear memory to a physical address in COPY mode, and OP_COPY_P2V refers to copying a physical address to virtual linear memory in COPY mode.

[0221] When implementing the COPY mode, it can be done in the following code format:

[0222] len = POP();

[0223] val = POP();

[0224] dst = POP();

[0225] emit_vlm_dma_intrinsic(OP_FILL,dst,len,val);

[0226] When implementing the FILL pattern, it can be done in the following code format:

[0227] en = POP();

[0228] val = POP();

[0229] dst = POP();

[0230] emit_vlm_dma_intrinsic(OP_COPY_V2V,dst,len,val);

[0231] Clearly, some instructions, such as memory size instructions and memory increment instructions, require APIs provided by the runtime and operating system to implement their corresponding functions. The following provides an example of how the operating system and runtime provide these APIs.

[0232] The following is based on Figure 10 The content shown is an example to illustrate how to implement the memory size instruction (memory.size) and the memory increase instruction (memory.grow).

[0233] Figure 10 This is an exemplary schematic diagram illustrating the method for implementing the memory size instruction (memory.size) and memory increase instruction (memory.grow) provided in the embodiments of this application.

[0234] like Figure 10 As shown, when performing pre-compilation and encountering a memory increase instruction, memory increase (memory.grow) can be achieved through steps S1001, S1002, S1003, S1004, and S1005.

[0235] S1001: Target file is running.

[0236] After the target program is compiled in advance, it generates a machine code object file. When the object file is started, i.e., during runtime, the electronic device will execute the code in the object file according to its logic.

[0237] S1002: Memory increment instruction.

[0238] When the electronic device executes the instructions in the object file and encounters a memory increment instruction, it executes step 1003.

[0239] S1003: Obtain the base address of the linear memory and the size to be allocated.

[0240] Obtain the base address of the linear memory for the target file and the size to be allocated. The base address can be obtained through the configuration information of the virtual linear memory unit; the size to be allocated comes from the input parameters in the memory increment instruction. Execute step S1004.

[0241] S1004: Call the interface provided by the operating system to allocate memory space.

[0242] After determining the base address of the linear memory and the size to be allocated, memory can be allocated by calling the interface provided by the operating system, so that the size of the newly allocated memory is equal to the size to be allocated. Execute step S1005.

[0243] S1005: Modify the configuration information of virtual linear memory.

[0244] After successful memory allocation, the configuration information in the corresponding virtual linear memory / virtual linear memory unit of the target file is modified.

[0245] S1006: Memory size instruction.

[0246] When the electronic device executes the instructions in the object file and encounters a memory increment instruction, it executes step 1007.

[0247] S1007: Query the configuration information of the virtual linear memory unit and return the corresponding virtual linear memory block size.

[0248] By querying the configuration information of the virtual linear memory units corresponding to the target file, the size of one or more virtual linear memory blocks corresponding to the target AOT can be obtained. The configuration information of the virtual linear memory units can be found in the corresponding text descriptions in Tables 1 and 2 above, and will not be repeated here.

[0249] In the above text, implementing adaptive handling of memory size (memory.size) and memory growth (memory.grow) requires WAMR to provide "wasm_runtime_memory_size" and "wasm_runtime_enlarge_memory". Below, we will take "wasm_runtime_enlarge_memory" as an example, combined with... Figure 11A , Figure 11B The content shown exemplifies how to build the WAMR API.

[0250] Clearly, the corresponding methods for setting the memory size (memory.size) and increasing the memory (memory.grow) can be implemented by reading and modifying the control register of the virtual linear memory.

[0251] Figure 11A , Figure 11B This is an exemplary schematic diagram illustrating the implementation of the memory increment method provided in the embodiments of this application.

[0252] When implementing the `memory.grow` method, the first step is to obtain the physical address base of the current linear memory. Then, the operating system's API is used to allocate a new, larger memory space. This API is operating system-dependent; for example, it could be the `realloc()` method from the C standard library. The `realloc()` method is declared as `void* realloc(void* ptr, size_t size)`, where `ptr` is a pointer to the memory block to be reallocated, and `size` is the new size of the memory block.

[0253] like Figure 11A As shown, linear memory 1 is 4KB in size, the physical base address of the old linear memory is 0x2000_8000, and the physical addresses corresponding to linear memory 1 are from 0x2000_8000 to 0x2000_8FFF. After calling the memory increase (memory.grow) method, linear memory 2 is 8KB in size. The base address of linear memory 2 remains unchanged at 0x2000_8000, and the physical addresses corresponding to linear memory 2 are contiguous, from 0x2000_8000 to 0x2000_9FFF.

[0254] The `realloc()` method may fail due to memory fragmentation, where the physical heap memory of the electronic device does not contain a sufficiently large contiguous physical address space. In this case, only the newly added memory needs to be allocated.

[0255] like Figure 11B As shown, the heap memory of the electronic device contains a large number of memory fragments. In this case, using the virtual linear memory and virtual linear memory block provided in this application embodiment, a new virtual linear memory block is allocated from 0x00FF_F000 to 0x00FF_FFFF. In this case, linear memory 1 is the same as linear memory 3, and the physical address corresponding to linear memory 4 is from 0x00FF_F000 to 0x00FF_FFFF.

[0256] It is worth noting that from the perspective of the target program, linear memory 3 and linear memory 4 are contiguous, and memory access operations related to linear memory 3 and linear memory 4 can still be completed through indexes / pointers.

[0257] It is understood that the memory access instructions provided in the embodiments of this application implement linear memory read and write operations and conversions, avoiding the register pressure caused by introducing an additional indirect memory access layer and saving a lot of computational overhead.

[0258] The above mainly introduced the adaptation handling of memory access instructions during the advance compilation process. The following section will combine... Figure 12 This example illustrates how the operating system loads, starts, and executes the target file after it has been pre-compiled into an object file.

[0259] Figure 12 This is an exemplary schematic diagram illustrating the method for loading, starting, and executing target files provided in the embodiments of this application.

[0260] like Figure 12 As shown, the method for loading, starting, and executing target files provided in this application embodiment includes:

[0261] S1201: Compile the target program into an object file in advance, and complete the adaptation processing of memory access instructions during the compilation process.

[0262] Specifically, electronic devices can obtain target programs in WASM bytecode format in various ways, such as by downloading them from an app store or from the internet, etc., which are not limited here.

[0263] After obtaining the target program, it is pre-compiled into an object file, which is in machine code format. During pre-compilation, the memory access instructions of the target program are adapted, such as read instructions, write instructions, memory size, and memory increment instructions. For details, please refer to the above text. Figure 9 , Figure 10 , Figure 11A , Figure 11B The corresponding textual descriptions will not be repeated here.

[0264] The following is combined Figure 13 The content shown illustrates, for example, the process of obtaining a target program in WASM bytecode format.

[0265] Figure 13 This is an exemplary schematic diagram of a target program for obtaining WASM bytecode format provided in an embodiment of this application.

[0266] like Figure 13 As shown, electronic devices such as watches, wristbands, VR / AR glasses, and home appliances can download target programs, such as applications or drivers, through various means, including app stores or the internet. The target program can be in WASM bytecode format.

[0267] S1202: Load the target file and complete the non-linear memory class loading and linear memory loading.

[0268] When loading the target file, non-linear memory classes are loaded according to the operating system's default logic, linear memory is loaded, and physical memory allocation is completed during the loading process. Execute step S1202.

[0269] S1203: Enable virtual linear memory unit, configure virtual linear memory block.

[0270] Since the operating system has already loaded linear memory in step S1202, the virtual linear memory unit of the target file can be enabled, and the virtual linear memory block can be configured. The method for configuring the virtual linear memory block can be found in the textual descriptions in Tables 1 and 2 above, and will not be repeated here.

[0271] S1204: Start and execute the target file.

[0272] After the operating system starts the target file, it executes the target file and uses the memory access instructions provided in this application embodiment to perform read and write operations on the virtual linear memory. Other instructions can be executed according to the original logic.

[0273] S1205: Close the target file, release physical memory, and remove virtual linear memory units.

[0274] When closing a target file, the operating system needs to release the physical memory occupied by the target file during runtime and free the virtual linear memory unit corresponding to the target file.

[0275] Combination Figure 9 , Figure 10 , Figure 12 As can be understood from the content shown, the hardware and software collaborative expansion method for virtual linear memory provided in the application embodiments firstly provides a set of extended instructions to implement read and write operations on linear memory, and avoids register pressure and corresponding computational overhead caused by introducing an additional indirect memory access layer through instruction conversion. Secondly, this application implements boundary checks for linear memory through the provided virtual linear memory hardware unit, avoiding the insertion of checking code during the compilation conversion stage and reducing the size of the target file generated after the target program is compiled.

[0276] Obviously, similar to electronic devices with MPUs, the hardware and software collaborative expansion method for virtual linear memory provided in this application embodiment also implements different permission settings on different physical addresses through virtual linear memory.

[0277] However, unlike other methods, the hardware and software collaborative expansion method for virtual linear memory provided in this application does not divide privileges / modes, thus avoiding the overhead caused by privilege / mode switching. It achieves different permission settings on different physical addresses through software collaboration within the same privilege / mode, thereby ensuring security. Furthermore, the hardware and software collaborative expansion method for virtual linear memory provided in this application also provides virtual addresses and corresponding memory access instructions.

[0278] Obviously, similar to electronic devices with an MMU, the hardware and software co-extension method for virtual linear memory provided in this application embodiment also implements virtual addresses through virtual linear memory, and the mapping relationship between virtual addresses and physical addresses can be configured.

[0279] However, unlike other applications, this application does not divide privileges / modes, thus avoiding the overhead caused by switching privileges / modes. By using software collaboration within the same privilege / mode to achieve different permission settings on different physical addresses, security is ensured.

[0280] When the operating system runs multiple target programs simultaneously, in response to user operations, when switching target programs, it needs to save the configuration information of the virtual linear memory unit of the target program being swapped out and restore the configuration information of the virtual linear memory unit of the target program being swapped in.

[0281] The following is based on Figure 14 Using the example shown, this document exemplifies the saving and restoration of configuration information when switching between target programs in a multi-target program scenario. For ease of description, when a target program is switched in, it is said to be switched to the foreground; when a target program is switched out, it is said to be switched to the background.

[0282] Figure 14This is an exemplary schematic diagram illustrating the saving and restoration of virtual linear memory configuration information in a multi-target program scenario provided in this application embodiment.

[0283] like Figure 14 As shown, in a multi-target program scenario, the methods for saving and restoring target programs include:

[0284] S1401: The operating system switches target program 1 to the background and target program 2 to the foreground.

[0285] In response to user actions, or as determined by the operating system itself, target program 1 is switched to the foreground, and target program 2, which was previously in the foreground, is also moved to the foreground.

[0286] When switching a target program in response to a user's operation, the operating system can determine whether the target program is switched to the background or to the foreground based on whether the thread corresponding to the target program is switched.

[0287] Perform step S1301.

[0288] S1402: Save the configuration information of target program 1 and restore the configuration information of target program 2.

[0289] The operating system can store the configuration information of the virtual linear memory unit of target program 1 into the context structure of the thread of target program 1, and disable the virtual linear memory unit; correspondingly, the operating system can obtain the configuration information of the virtual linear memory unit from the context structure of the thread of target program 2, and configure the virtual linear memory unit according to the information.

[0290] It is worth noting that if the virtual linear memory unit of target program 1 is enabled before it is switched to the background, then the virtual linear memory unit of target program 1 will be disabled after it is switched to the background.

[0291] It is worth noting that when restoring the configuration information of target program 2, if the configuration information in the target program thread context is empty, the configuration information of target program 2 can be re-initialized.

[0292] It is worth noting that the hardware and software co-extension method for virtual linear memory provided in this application is not limited to WebAssembly pre-compilation and embedded real-time operating system scenarios. For example, using the hardware and software co-extension method for virtual linear memory provided in this application, machine-related (machine code) sandbox execution modules can be directly generated; furthermore, for electronic devices equipped with an MMU, combining the hardware and software co-extension method for virtual linear memory provided in this application with trusted intermediate representation code can provide a secure sandbox isolation mechanism for the kernel mode, enabling securely isolated kernel extensions, driver development interfaces, etc.

[0293] Finally, the electronic device provided in this application is described below.

[0294] In the embodiments of this application, the electronic device can be a mobile electronic device or a smart home device, etc., and is not limited thereto.

[0295] Figure 15 This is an exemplary schematic diagram of the hardware structure of the electronic device 100 provided in the embodiments of this application.

[0296] The following detailed description uses electronic device 100 as an example. It should be understood that electronic device 100 may have more or fewer components than shown in the figures, may combine two or more components, or may have different component configurations. The various components shown in the figures can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0297] Electronic device 100 may include: processor 110, bus and interface 120, random access memory (RAM) 130, non-volatile memory (NVM) 140, sensor module 150, communication module 160, display module 170, etc. The non-volatile memory 140 may include ROM and Flash memory.

[0298] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 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 be implemented in hardware, software, or a combination of software and hardware.

[0299] The processor 110 may include one or more processing units, such as a memory management unit (MMU), a memory protection unit (MPU), an arithmetic logic unit (ALU), a control unit, registers, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0300] Processor 110 may also include virtual linear memory (VLM) 180. Virtual linear memory provides a linearly addressable view of virtual memory and confines application memory access to the virtual memory space. By using virtual linear memory to implement memory address virtualization, the base physical address of the aforementioned virtual linear address can be dynamically updated, and linear memory space expansion and migration operations can be effectively implemented transparently to the application.

[0301] Virtual linear memory 180 can provide an application with one or more virtual linear memory units, and a virtual linear memory unit can provide an application with one or more virtual linear memory blocks. Each virtual linear memory block can be configured with independent permissions, thereby achieving memory safety.

[0302] Virtual linear memory 180 can perform boundary checks during the compilation process.

[0303] Processor 110 can directly access memory via instructions adapted to virtual linear memory 180.

[0304] Bus and interface 120 may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0305] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0306] Random access memory 130 may include static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM, such as fifth-generation DDR SDRAM, which is generally referred to as DDR5 SDRAM), etc.

[0307] The non-volatile memory 140 may include disk storage devices and flash memory. Flash memory can be classified according to its operating principle, such as NOR flash memory, NAND flash memory, and 3D NAND flash memory. It can also be classified according to the level of its storage cells, such as single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), and quad-level cell (QLC). Furthermore, it can be classified according to its storage specification, such as universal flash memory storage (UFS) and embedded multimedia card (eMMC).

[0308] Random access memory 130 can be directly read and written by processor 110. It can be used to store executable programs (such as machine instructions) of operating systems or other running programs, as well as user and application data.

[0309] The non-volatile memory 140 can also store executable programs and data of users and applications, and can be pre-loaded into random access memory for direct reading and writing by the processor 110.

[0310] The sensor module 150 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, ambient light sensors, fingerprint sensors, touch sensors, bone conduction sensors, etc.

[0311] The communication module 160 may include a mobile communication module and a wireless communication module.

[0312] Display module 170 may include a display screen.

[0313] Figure 16 This is an exemplary schematic diagram of the software structure of the electronic device 100 provided in the embodiments of this application.

[0314] The software system of the embedded electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture.

[0315] For example, the software architecture of an electronic device includes: application layer 200, real-time operating system 201, and driver layer 202.

[0316] Application layer 200 may include middleware, application packages, and driver packages. Application packages may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0317] The Real-Time Operating System (RTOS) 201, also known as the Instantaneous Operating System, runs and manages system resources in a sorted manner and provides a consistent foundation for application development.

[0318] Driver layer 202 may include hardware-related device drivers.

[0319] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0320] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0321] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A hardware and software collaborative expansion method for virtual linear memory, characterized in that, The processor of the electronic device includes a virtual linear memory unit for managing part or all of the physical memory on the electronic device, the method comprising: The electronic device acquires a first file, the first file including a WASM bytecode file of a first application; When the electronic device compiles the first file in advance, the electronic device converts the first instruction in the first file into the corresponding second instruction; The first instruction is a normal memory access instruction, and the second instruction is an instruction to access the memory managed by the virtual linear memory unit through the virtual linear memory unit. When the normal memory access instruction is executed, the device performs boundary checks on the linear memory in WASM based on the boundary check code generated when compiling the first file. When the electronic device executes the second instruction, it performs boundary checks on the linear memory in WASM based on the virtual linear memory unit.

2. The method according to claim 1, characterized in that, The method further includes: When the electronic device compiles the first file in advance, it converts the third instruction into the corresponding fourth instruction. The third instruction includes a memory increase instruction and a memory size instruction. The fourth instruction is used to call the runtime-provided interface so that when the electronic device runs the first file, the electronic device can increase memory or determine memory size based on the fourth instruction calling the runtime-provided interface.

3. The method according to claim 1, characterized in that, The method further includes: The electronic device compiles the first file in advance to obtain the first executable file; When the electronic device runs the first executable file, the electronic device allocates virtual linear memory for the first executable file based on the virtual linear memory unit; The virtual linear memory is either contiguous in physical memory or non-contiguous in physical memory.

4. The method according to claim 3, characterized in that, The method further includes: When the electronic device switches the first executable file to the background, the electronic device saves the configuration information corresponding to the first executable file.

5. The method according to claim 3, characterized in that, The method further includes: When the electronic device switches the first executable file to the foreground, the electronic device restores the configuration information corresponding to the first executable file.

6. The method according to claim 3, characterized in that, The virtual linear memory unit provides one or more virtual linear memory blocks for the first executable file.

7. The method according to claim 6, characterized in that, The one or more virtual linear memory blocks are configured with independent base addresses, read / write permissions, and sizes.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: The electronic device acquires a second file, the second file including the WASM bytecode file of the second application; When the electronic device compiles the second file in advance, the electronic device converts the first instruction in the second file into the corresponding second instruction; The read / write permissions of the first application on the first memory are different from those of the second application on the first memory, which corresponds to a continuous physical address in the physical memory of the electronic device.

9. The method according to claim 8, characterized in that, The first application and the second application have the same execution level / privilege level.

10. 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 to 9.

11. A chip system applied to an electronic device, the chip system comprising one or more processors, the processors being configured to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1 to 9.

Images