A dynamic compatibility method and system, an electronic device, and a storage medium are provided

Abstract

The application discloses a dynamic compatibility method and system, an electronic device and a storage medium. The method comprises the following steps: an instruction compilation layer compiles a source architecture instruction set of a target application, and submits an instruction compilation acceleration subtask generated in the compilation process to a hardware acceleration layer; a policy selector in an API virtualization layer processes a call of a source system API of the target application according to an API type of the target application by using a corresponding API processing strategy, and submits an API conversion acceleration subtask generated in the processing process to the hardware acceleration layer; and the hardware acceleration layer executes the instruction compilation acceleration subtask and the API conversion acceleration subtask. The method realizes the compatibility of the target application on different architectures, and processes the API call according to different types of API in the API virtualization layer, so that various types of long-tail API can be adapted.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an application dynamic compatibility method, system, electronic device, and storage medium. Background Technology

[0002] Some processor systems, when running Wintel ecosystem applications, have encountered obstacles in migrating critical business applications due to differences in x86 instruction sets, missing Windows APIs, and incompatible graphics rendering architectures.

[0003] Existing compatibility solutions mainly rely on manually predefined API rules, which cannot adapt to the massive number of long-tail APIs. Long-tail APIs refer to unpublished interfaces that are called very infrequently but are critical to the business, such as dedicated interfaces for industrial control software and outdated business APIs. Users are forced to downgrade to using incomplete versions, such as stripped-down versions of business systems. Summary of the Invention

[0004] This invention provides an application dynamic compatibility method, system, electronic device, and storage medium to solve the problem that existing compatibility solutions cannot adapt to various types of APIs.

[0005] In a first aspect, embodiments of the present invention provide an application dynamic compatibility method for use in a dynamic compatibility system, the dynamic compatibility system comprising: an instruction compilation layer, an application programming interface (API) virtualization layer, and a hardware acceleration layer;

[0006] The instruction compilation layer compiles the source architecture instruction set of the target application and submits the instruction compilation acceleration subtasks generated during the compilation process to the hardware acceleration layer.

[0007] The API virtualization layer uses a policy selector to process the source system API calls of the target application according to the API type and adopts the corresponding API processing strategy, and submits the API conversion acceleration subtasks generated during the processing to the hardware acceleration layer.

[0008] The hardware acceleration layer executes the instruction compilation acceleration subtask and the API conversion acceleration subtask.

[0009] Secondly, embodiments of the present invention provide an application dynamic compatibility system, including: an instruction compilation layer, an application programming interface (API) virtualization layer, and a hardware acceleration layer;

[0010] The instruction compilation layer compiles the source architecture instruction set of the target application and submits the instruction compilation acceleration subtasks generated during the compilation process to the hardware acceleration layer.

[0011] The API virtualization layer processes the calls to the source system API of the target application by adopting the corresponding API processing strategy according to the API type through a policy selector, and submits the API conversion acceleration subtask generated during the processing to the hardware acceleration layer.

[0012] The hardware acceleration layer executes the instruction compilation acceleration subtask and the API conversion acceleration subtask.

[0013] Thirdly, embodiments of the present invention provide an electronic device, the electronic device comprising:

[0014] At least one processor;

[0015] and a memory communicatively connected to the at least one processor;

[0016] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the application dynamic compatibility method described in any embodiment of the present invention.

[0017] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the application dynamic compatibility method described in any embodiment of the present invention.

[0018] The technical solution of this invention compiles the source architecture instruction set of the target application through an instruction compilation layer, and submits the instruction compilation acceleration subtasks generated during the compilation process to a hardware acceleration layer. The policy selector in the API virtualization layer processes the calls to the source system APIs of the target application using corresponding API processing strategies based on the API type of the target application, and submits the API conversion acceleration subtasks generated during the processing to the hardware acceleration layer. The hardware acceleration layer executes the instruction compilation acceleration subtasks and the API conversion acceleration subtasks. To address the compatibility issues of the target application, the source application architecture of the target application is divided into an instruction translation layer and an API virtualization layer, simultaneously resolving issues at two different levels: instruction set differences and operating system API differences, thus achieving cross-architecture compatibility for the target application. Furthermore, the API virtualization layer processes API calls for different types of APIs, enabling adaptation to various types of long-tail APIs.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart of an application dynamic compatibility method provided in Embodiment 1 of the present invention;

[0022] Figure 2 This is a flowchart of an application dynamic compatibility method provided in Embodiment 2 of the present invention;

[0023] Figure 3 This is a schematic diagram illustrating the principle of the instruction compilation process;

[0024] Figure 4 A schematic diagram illustrating the principle of applying the dynamic compatibility method;

[0025] Figure 5 This is a schematic diagram of the structure of an application dynamic compatibility system provided in Embodiment 3 of the present invention;

[0026] Figure 6 A schematic diagram of the structure of an electronic device for implementing the application dynamic compatibility method of this invention. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] Example 1

[0030] Figure 1 This is a flowchart illustrating an application dynamic compatibility method provided in Embodiment 1 of the present invention. This embodiment is applicable to dynamic compatibility situations of APIs between different processor systems. The method can be executed by an application dynamic compatibility system, which can be implemented in hardware and / or software and configured in an electronic device. The application dynamic compatibility system can be integrated into an application system, or it can be set up independently as a plugin or application, etc.

[0031] The application dynamic compatibility system includes: an instruction compilation layer, an application programming interface (API) virtualization layer, and a hardware acceleration layer.

[0032] like Figure 1 As shown, the method includes:

[0033] S110, the instruction compilation layer, compiles the source architecture instruction set of the target application and submits the instruction compilation acceleration subtasks generated during the compilation process to the hardware acceleration layer.

[0034] The instruction compilation layer can be understood as the processing architecture layer that compiles instructions. The target application can be understood as the application object that needs dynamic compatibility. The instruction compilation acceleration subtask can be considered as a specific computational task or instruction pattern that is identified during the instruction compilation process and is suitable for offloading to the hardware acceleration layer for execution. Its essence is to transform computational segments with specific patterns in the instruction sequence processed by the traditional CPU into independent task units that can be efficiently executed by the hardware accelerator through hardware-software collaboration.

[0035] Specifically, the instruction compilation layer can use a JIT compiler and / or a lightweight interpreter to compile the source architecture instruction set of the target application into a target architecture instruction set adapted to the target architecture. For example, if the target application is a Wintel application and the source architecture instruction set is the x86 instruction set, the instruction compilation layer compiles the target application's x86 instruction set into ARM instructions / LoongArch instructions. During the instruction compilation process, instruction compilation acceleration subtasks that require hardware acceleration are generated and submitted to the hardware acceleration layer.

[0036] S120, the API virtualization layer uses a policy selector to process the source system API calls of the target application according to the API type and adopts the corresponding API processing strategy, and submits the API conversion acceleration subtasks generated during the processing to the hardware acceleration layer.

[0037] The API virtualization layer can be understood as a processing architecture layer that transforms API calls into executable operations. It includes a policy selector, which selects the appropriate API processing strategy based on the API type. The API conversion acceleration subtask can be considered as transforming identified high-performance, hardware-accelerated API call fragments into independent task units executable by a dedicated accelerator during the API call conversion process. Its core objective is to replace traditional software simulation conversion with hardware acceleration, significantly reducing API conversion overhead and improving interoperability between heterogeneous systems.

[0038] API types can include basic APIs, graph APIs, and encryption-related APIs; they can also be unknown types (or non-predefined) APIs. For unknown types of APIs, the API type can be predicted using artificial intelligence models.

[0039] Specifically, the API virtualization layer uses a policy selector to select a matching API processing policy based on the API type of the source system API to process the source system API calls, converting the source system API into operations that can be executed on the target system. During the API call processing, API conversion acceleration subtasks that require hardware acceleration are generated and submitted to the hardware acceleration layer.

[0040] S130, the hardware acceleration layer executes instruction compilation acceleration subtasks and API conversion acceleration subtasks.

[0041] The hardware acceleration layer can be considered as the collective term for physical hardware modules and their supporting software stacks in a computer system that are specifically designed to efficiently perform specific computing tasks. It breaks through the performance bottleneck of general-purpose processors through customized hardware design.

[0042] Specifically, the hardware acceleration layer is used to accelerate the execution of instruction compilation acceleration subtasks that require hardware acceleration generated during the execution of the instruction translation layer, and API conversion acceleration subtasks that require hardware acceleration generated during the execution of the API virtualization layer.

[0043] The technical solution of this invention compiles the source architecture instruction set of the target application through an instruction compilation layer, and submits the instruction compilation acceleration subtasks generated during the compilation process to a hardware acceleration layer. The policy selector in the API virtualization layer processes the calls to the source system APIs of the target application using corresponding API processing strategies based on the API type of the target application, and submits the API conversion acceleration subtasks generated during the processing to the hardware acceleration layer. The hardware acceleration layer executes the instruction compilation acceleration subtasks and the API conversion acceleration subtasks. To address the compatibility issues of the target application, the source application architecture of the target application is divided into an instruction translation layer and an API virtualization layer, simultaneously resolving issues at two different levels: instruction set differences and operating system API differences, thus achieving cross-architecture compatibility for the target application. Furthermore, the API virtualization layer processes API calls for different types of APIs, enabling adaptation to various types of long-tail APIs.

[0044] Example 2

[0045] Figure 2 This is a flowchart of an application dynamic compatibility method provided in Embodiment 2 of the present invention. Based on the above embodiments, this embodiment further refines the functionality of the API virtualization layer. Specifically, the API types of the target application include: basic APIs, graphics APIs, encryption-related APIs, and non-predefined APIs. The API virtualization layer processes the calls to the source system APIs of the target application using a policy selector based on the API type and employing corresponding API processing strategies. This includes: when the API type of the source system API of the target application is a basic API, the policy selector selects a static mapping channel to process the calls to the source system API; when the API type of the source system API of the target application is a graphics API... The strategy selector selects a graphics translation channel to process the calls to the source system API. When the API type of the target application's source system API is an encryption-related API, the strategy selector selects a national cryptographic algorithm hardware offloading channel to process the calls to the source system API. When the API type of the target application's source system API is a non-predefined API, during the first processing, the strategy selector predicts the API processing strategy for the non-predefined API based on the API prediction channel, and processes the calls to the source system API based on the API processing strategy within the sandbox environment. For subsequent processing, the strategy selector matches a suitable API processing strategy for the non-predefined API based on historical execution data to process the calls to the source system API.

[0046] like Figure 2 As shown, the method includes:

[0047] S210, the instruction compilation layer, compiles the source architecture instruction set of the target application and submits the instruction compilation acceleration subtasks generated during the compilation process to the hardware acceleration layer.

[0048] In an optional embodiment, the instruction compilation layer compiles the source architecture instruction set of the target application, including:

[0049] A1. The instruction compilation layer identifies and marks the instruction type of the source architecture instruction in the source architecture instruction set of the target application based on hot path identification. The instruction type includes: high-frequency instructions and low-frequency instructions.

[0050] A2. Dynamically compile the high-frequency instructions and store them in a memory cache;

[0051] A3. For the low-frequency instructions, a cold path rollback strategy is adopted, and compilation is performed based on a lightweight interpreter.

[0052] The source architecture instruction set includes high-frequency and low-frequency instructions. High-frequency instructions are those whose call frequency is higher than a first threshold, while low-frequency instructions are those whose call frequency is lower than or equal to a second threshold. The first and second thresholds may be equal or unequal. Hot path identification refers to identifying the most frequently used code paths (including instruction sequences, function calls, or basic blocks) during program execution in a computer system through static or dynamic analysis methods.

[0053] Specifically, the instructions for the source and target architectures are completely different machine languages, requiring real-time compilation. However, the workload of compiling every single instruction in real time is enormous. Therefore, this embodiment employs a combination of hot-path dynamic compilation and cold-path rollback interpretation execution to compile the instruction set.

[0054] Figure 3 This is a schematic diagram illustrating the principle of the instruction compilation process. (For example...) Figure 3 As shown, a hot path identification method is used to mark high-frequency and low-frequency instructions. For high-frequency instructions, dynamic compilation (JIT, also known as just-in-time compilation) is used to compile them, and the compiled high-frequency instructions are stored in an in-memory cache. For example, for high-frequency x86 instructions, an optimized ARM / LoongArch binary cache is generated based on dynamic compilation. For low-frequency instructions, a cold path rollback strategy is used to separate them from the main execution path, and they are executed by a lightweight interpreter using an on-demand loading execution method, rather than being resident in memory, thus reducing memory consumption. During the compilation of high-frequency and low-frequency instructions, instruction compilation acceleration subtasks are generated and submitted to the hardware acceleration layer.

[0055] S220. When the API type of the source system API of the target application is a basic API, the strategy selector selects a static mapping channel to process the call to the source system API.

[0056] In this context, a basic API refers to the set of most fundamental or core programming interfaces provided by a software system or service, such as general interfaces for files / networks (e.g., CreateFileW). A strategy selector can be understood as a functional module that matches an API to the corresponding processing channel. A statically mapped channel can be considered a directly mapped processing channel. Its core principle is to establish a predefined API mapping rule base and parameter adaptation logic; its essence is function-level semantic transformation.

[0057] At the API level, different operating systems provide different service interfaces, which may involve multiple aspects such as file operations, graphics rendering, and encryption. Some application systems do not have these interfaces and need to be simulated or converted. In particular, there are a large number of undocumented APIs, and traditional static mapping may fail, requiring the introduction of other API processing methods.

[0058] Specifically, when the API type of the source system API of the target application is a basic API, the static mapping channel is preferred to be matched based on the strategy selector, and the call to the source system API is processed using the static mapping channel.

[0059] For example, for basic APIs in the Windows-Linux scenario, the implementation process of processing calls to source system APIs based on static mapping channels can be as follows: (1) Intercepting Windows API calls, such as the application calling CreateFileW(L"test.txt",GENERIC_WRITE,...);

[0060] (2) Rule base matching: Search the mapping library for the Linux native interface and conversion rules corresponding to CreateFileW; an example of a mapping rule is as follows:

[0061]

[0062]

[0063] (3) Dynamic parameter adaptation. The parameter conversion function handles API parameter differences. The pseudocode for the parameter conversion function can be represented as:

[0064]

[0065] (4) Execute native calls. Call Linux system functions, such as int fd = open(path, flags, mode);

[0066] (5) Return value conversion: wrap the Linux file descriptor fd into a Windows handle format (e.g., 0x1003F).

[0067] For example, in a Windows-Linux scenario: Mapping Windows API-CreateFileW to Linux API-Open involves the following parameter mapping adaptation logic: wide character to UTF-8 conversion; mapping GENERIC_READ to O_RDONLY; mapping the security descriptor to mode_t. Mapping Windows API-ReadFile to Linux API-read involves the following parameter mapping adaptation logic: mapping the Windows handle to the Linux fd; offset processing (requires synchronous calls to lseek). Mapping Windows API-WSASend to Linux API-sendmsg involves the following parameter mapping adaptation logic: socket handle conversion; mapping the WSABUF structure to iovec; and flag mapping. Mapping Windows API-RegOpenKeyExW to Linux API-regedit involves the following parameter mapping adaptation logic: converting the registry path to / etc / registry / virtual file; and calling the Tongxin Registry service via inter-process communication (IPC).

[0068] Optionally, the call processing method for basic APIs can be dynamically adjusted based on hardware resource status. For example, if historical execution efficiency data shows that the API is inefficient to process through statically mapped channels under certain hardware or loads (e.g., high latency due to frequent context switching), and a better lightweight virtualization solution exists, the policy selector can switch paths.

[0069] S230. When the API type of the source system API of the target application is a graphics API, the strategy selector selects the graphics translation channel to process the call to the source system API of the target application.

[0070] Graphics APIs can be understood as a series of programming interfaces used to process, analyze, generate, and manipulate images. Examples include rendering APIs like DirectX / OpenGL (such as DrawInstanced). Graphics APIs simplify complex image processing tasks, enabling developers to easily integrate image functionality into applications. The Graphics Translation Pipeline refers to the process of converting graphics data from one form to another, involving conversions between different graphics APIs, rendering technologies, or hardware architectures. A heterogeneous acceleration architecture compatible across graphics APIs is achieved through instruction semantic translation and physical resource pass-through. Its core goal is to translate non-native graphics instructions (such as DirectX / OpenGL) into Vulkan instructions supported by the target GPU and directly submit them to hardware for execution without modifying the source GPU driver.

[0071] Specifically, when the API type of the source system API of the target application is a graphics API, the graphics translation channel is preferred for the graphics API based on the strategy selector, and the call to the source system API of the target application is processed using the graphics translation channel.

[0072] For example, the graphics API calls rendering commands from any non-Vulkan graphics interface. Using rendering resources such as vertex / texture data, shader bytecode, and state machine configuration parameters, the rendering semantics of the input API are converted into equivalent Vulkan instructions. By sharing native memory / video memory resources, resource passthrough is achieved, avoiding data copying. The system outputs correct rendering results and ensures that the graphics rendering results are completely equivalent to the framebuffer output of the native environment. In terms of performance metrics, it approaches the rendering latency and throughput of native hardware.

[0073] Optionally, the handling of graphics API calls can be dynamically adjusted based on hardware resource status and / or historical execution efficiency data. For example, if GPU utilization exceeds 80% or GPU temperature is too high, the policy selector may perform dynamic degradation. For instance, a) some non-critical image effects may use lower-precision translations (e.g., translating some DirectX 12 features to Direct 11 / Vulkan equivalents); b) for computationally intensive but non-real-time graphics tasks, switching to CPU software rendering, sacrificing performance for stability. If the embedded neural network process unit (NPU) is idle and the graphics API involves shader logic that can be computed in parallel, the policy selector may offload some computation to the NPU. The policy selector can also preload optimal translation rules or shader caches for specific graphics APIs based on historical execution efficiency.

[0074] S240. When the API type of the source system API of the target application is an encryption-related API, the policy selector selects the national cryptographic algorithm hardware offloading channel to process the call to the source system API.

[0075] Among them, encryption-related APIs can be understood as a collection of programming interfaces used to implement security functions such as data encryption, decryption, digital signatures, and key management. They are widely used in fields such as data protection, secure communication, and authentication, such as cryptographic service interfaces (e.g., BCryptEncrypt). The core of the Chinese national cryptographic algorithm hardware offloading channel is to transfer execution from the main processor CPU to a dedicated Chinese national cryptographic hardware chip. The key is to prevent data from leaving the secure area.

[0076] Specifically, when the API type of the source system API of the target application is an encryption-related API, the national cryptographic algorithm hardware offloading channel is preferred for encryption-related APIs based on the policy selector, and the call to the source system API is processed using the national cryptographic algorithm hardware offloading channel.

[0077] For example, the execution process of the national cryptographic algorithm hardware offloading channel is as follows: receiving the encrypted API redirection request, parsing the key handle and plaintext data in it; transmitting the plaintext data directly to the national cryptographic hardware accelerator through the security bus; triggering the national cryptographic chip to independently perform cryptographic operations, during which the main CPU does not participate in the calculation process; asynchronously sending back the ciphertext result to the API virtual layer.

[0078] Optionally, the handling of encryption-related API calls can be dynamically adjusted based on hardware resource status and / or historical execution efficiency data. For example, if the national cryptographic chip is unavailable, busy, or malfunctioning, the strategy selector can downgrade the processing: a) use the lower-performance national cryptographic algorithm based on software implementation; b) for non-critical or low-strength encryption, attempt to map it to the system software encryption library. Alternatively, the throughput and latency of different encryption APIs under different hardware offload paths can be recorded to optimize task scheduling strategies (such as batch processing of small requests).

[0079] S250. When the API type of the source system API of the target application is a non-predefined API, the strategy selector predicts the API processing strategy of the non-predefined API based on the API prediction channel during the first processing, and processes the call to the source system API based on the API processing strategy in the sandbox environment; during subsequent processing, the strategy selector matches an appropriate API processing strategy for the non-predefined API based on historical execution data and processes the call to the source system API.

[0080] Among these, non-predefined APIs can be unknown APIs (encountered for the first time) or known but not predefined APIs. A sandbox can be considered a safety fallback mechanism; its core logic is to predict strategies by testing them in an isolated environment, preventing system crashes caused by misfits.

[0081] Specifically, when processing a non-predefined API for the first time, the policy selector predicts the API processing strategy based on the API prediction channel. For example, within the API prediction channel, the prediction model outputs the API processing strategy based on the parameters of the non-predefined API, such as name, parameter hash, and call stack. The API processing strategy can include redirection, parameter transformation, and hardware offloading. Then, within the sandbox environment (isolated environment), calls to the source system API are processed based on the API processing strategy, and memory / instruction status is monitored. A security execution report of the API processing strategy is output to ensure system security. The security execution report can include the strategy type (redirection / parameter transformation / hardware offloading); peak resource consumption (CPU / memory); execution status code (success / partial success / failure); and error details (such as illegal memory access).

[0082] When successfully processing calls to non-predefined APIs, the corresponding API processing strategies are recorded and cached locally. Subsequent encounters with the same or highly similar APIs can directly apply the cached strategies, skipping the prediction phase and significantly improving efficiency. When processing non-predefined APIs for the first time, the strategy selector chooses historical API processing strategies for the same or highly similar APIs and selects the optimal API processing strategy based on historical execution data. This optimal strategy is then used to match the appropriate API processing strategy for the non-predefined API call to the source system API.

[0083] In an optional embodiment, during the initial processing, the policy selector predicts the API processing strategy for the non-predefined API based on the API prediction channel, and processes the calls to the source system API within the sandbox environment based on the API processing strategy. This includes: during the initial processing, the policy selector selects an appropriate API prediction model to predict the API processing strategy for the non-predefined API based on the resource status of the central processing unit (CPU); and processes the calls to the source system API of the target application within the sandbox environment with appropriate resource quotas.

[0084] Specifically, when processing a non-predefined API for the first time, the strategy selector selects an appropriate API prediction model based on the CPU resource status within the API prediction channel. For example, if the CPU load is extremely high or memory is scarce, the strategy selector can choose an AI model with a lower load. The API processing strategy for the non-predefined API is then predicted based on the API prediction model. Furthermore, resource quotas (such as memory and CPU time slices) allocated to the sandbox can be limited according to the CPU resource status. Within the sandbox environment with appropriately allocated resource quotas, calls to the source system APIs of the target application are processed based on the API processing strategy, prioritizing system response.

[0085] For example, API prediction models can adopt cloud-edge collaborative AI models, using knowledge distillation technology to compress large AI models to below 10MB, adapting to the NPU computing power of the CPU. For instance, an API prediction model using the TinyBERT architecture has only 4.2M parameters, and with GPU quantization acceleration, improves model inference throughput. Furthermore, non-predefined APIs can be categorized into low-complexity and high-complexity APIs based on their complexity. Low-complexity APIs can be inferred locally using lightweight models, while high-complexity APIs can be processed in the cloud using high-performance models.

[0086] In a specific example, a terminal running an old Windows application calls an undocumented API. The API prediction model is input with the API name, parameter hash, and call stack context. The model performs feature extraction, vector embedding, behavioral graph lookup, and policy priority ranking, outputting an API processing policy. The behavioral graph database contains over 100,000 Windows API call records; the matching mechanism triggers policy generation when the cosine similarity is greater than 85%. The output executable compatibility policy can be: a redirection strategy for functionally equivalent APIs; a parameter transformation strategy for APIs with different data structures; and a hardware offloading strategy for non-predefined APIs designed for encryption / image computation.

[0087] In another alternative embodiment, during non-first-time processing, the historical execution data includes one or more of the following: historical prediction model, prediction success rate, sandbox execution time, and resource consumption value of sandbox execution.

[0088] The historical prediction model can be considered the API prediction model used for the first prediction of API processing strategies for non-predefined APIs. The prediction success rate can be considered the success rate of processing API calls based on the predicted API processing strategy. The sandbox execution time can be considered the time spent processing API calls based on the API processing strategy within the sandbox environment. The resource consumption value of sandbox execution can be considered the resource consumption value of processing API calls based on the API processing strategy within the sandbox environment.

[0089] Specifically, when processing non-predefined APIs for the first time, appropriate API processing strategies can be matched to process the calls to the source system APIs based on one or more of the historical execution data, including historical prediction models, prediction success rates, sandbox execution time, and sandbox execution resource consumption values.

[0090] S260. Submit the API conversion acceleration subtask generated during the processing to the hardware acceleration layer.

[0091] S270, hardware acceleration layer execution instruction compilation acceleration subtask and API conversion acceleration subtask.

[0092] In one optional embodiment, the hardware acceleration layer includes a resource monitoring module and an adaptive offloading controller; the resource monitoring module monitors the quality of service data during the compilation of the source architecture instruction set of the target application by the instruction compilation layer, and the resource usage information during the processing of the source system API calls of the target application by the API virtualization layer; the adaptive offloading controller optimizes the resource allocation strategy in the instruction compilation acceleration subtask based on the quality of service data; and optimizes the resource allocation strategy in the API conversion acceleration subtask based on the resource usage information.

[0093] The resource monitoring module can be considered as a functional module that monitors the data of the instruction compilation layer during the compilation process and the data of the API virtualization layer during API call processing. The adaptive offload controller can be considered as an intelligent resource management system that dynamically allocates computing tasks to the most suitable processing unit (CPU, GPU, FPGA, or dedicated accelerator) to achieve the optimal performance-to-power ratio.

[0094] Specifically, during the compilation of the source architecture instruction set of the target application at the instruction compilation layer, the resource monitoring module monitors the service quality data of the instruction compilation layer, which may include resource utilization and temperature. The adaptive offloading controller optimizes the resource allocation strategy in the instruction compilation acceleration subtasks generated during the compilation process based on the service quality data collected by the resource monitoring module.

[0095] During the API virtualization layer's processing of the source system API calls of the target application, the resource monitoring module monitors the resource usage information of the API virtualization layer, and the adaptive unloading controller optimizes the resource allocation strategy in the API conversion acceleration subtask based on the resource usage information.

[0096] Optionally, the adaptive unloading controller optimizes the resource allocation strategy in the instruction compilation acceleration subtask based on the quality of service data, including:

[0097] The adaptive unloading controller matches hardware resources for the compilation acceleration subtasks corresponding to high-frequency instructions based on service quality data, and establishes a hardware acceleration channel to execute the compilation acceleration subtasks.

[0098] For example, when the NPU utilization is lower than a utilization threshold, the instruction compilation layer is triggered to optimize the dynamic compilation of the high-frequency instruction segment; when the temperature is higher than a temperature threshold, the instruction compilation layer is triggered to reduce the dynamic compilation to interpreted execution.

[0099] Based on the resource usage information, optimize the resource allocation strategy in the API conversion acceleration subtask, including: offloading the API prediction subtask in the API conversion acceleration subtask to the NPU for execution based on the sandbox logs of the API virtualization layer and the resource status of the embedded neural network processor (NPU).

[0100] Figure 4 A schematic diagram illustrating the principle of applying the dynamic compatibility method, such as... Figure 4 As shown, the source architecture instruction set of the target application is compiled through the instruction compilation layer, and the instruction compilation acceleration subtasks generated during the compilation process are submitted to the hardware acceleration layer. The API virtualization layer processes the API calls of the source system of the target application according to the API type of the target application. For APIs of predefined types, it requests the hardware acceleration layer to process the API calls. For APIs of non-predefined types, it calls the API prediction engine and executes the API processing strategy prediction task of the API prediction engine on the hardware acceleration layer. The hardware acceleration layer allocates hardware resources on the hardware platform to execute the acceleration task.

[0101] In a specific example, for an office terminal that needs to use a Windows version of a target application, involving SSE3 instruction set calls (high-frequency hot path), GdiPlus.dll image rendering API, and a dedicated plugin calling the undefined API WPS_FormulaEdit, the application dynamic compatibility process is as follows: When the target application executes code segments containing SSE3 instructions, the instruction compilation layer identifies them as high-frequency instructions (execution frequency greater than 1000 / minute) based on the hot path. It then requests the hardware acceleration layer to accelerate the SSE3 to ARMv8 conversion process. The hardware acceleration layer allocates matrix calculation units to the hardware platform and generates optimized instruction blocks, returning them to the instruction translation layer. The instruction translation layer returns the calculation results to the target application. The target application requests the API virtualization layer to call the graphics API. The API virtualization layer allocates a graphics translation channel to the graphics API based on a policy selector, implements API call processing based on instruction semantic translation and physical resource passthrough (Vulkan translation + GPU channel), and requests accelerated rendering from the hardware acceleration layer. The hardware acceleration layer allocates a GPU to perform rendering and returns the rendering data to the API virtualization layer. The target application requests a non-predefined API from the API virtualization layer. The API virtualization layer selects an API prediction channel based on the policy selector and submits the prediction task to the hardware acceleration layer. The hardware acceleration layer executes the prediction task on the NPU and obtains the prediction policy as redirection to the formula editor. The prediction policy is then sent to the API virtualization layer. The API virtualization layer performs policy verification based on the sandbox and returns the editing result to the target application after verification.

[0102] The technical solution of this invention, through a hybrid approach of dynamic compilation based on hot paths and interpreted execution based on cold paths, can reduce resource consumption and improve compilation efficiency. It selects the corresponding API processing strategy to handle API calls according to the API type, and combines processing channel prediction and sandbox execution for non-predefined APIs. This automatically adapts to tens of thousands of unpublished APIs, solving the problem of exhaustive manual adaptation for long-tail APIs and the version fragmentation problem where different versions of the same application may call different APIs. This improves the compatibility of long-tail APIs, including compatibility coverage and migration rate for professional software. Simultaneously, it utilizes a hardware acceleration layer to execute accelerated subtasks during the compilation and API processing processes, effectively reducing adaptation cycles and cross-architecture performance losses.

[0103] Example 3

[0104] Figure 5 This is a schematic diagram of the structure of an application dynamic compatibility system provided in Embodiment 3 of the present invention. Figure 5 As shown, the system includes: an instruction compilation layer 310, an API virtualization layer 320, and a hardware acceleration layer 330; wherein:

[0105] The instruction compilation layer 310 compiles the source architecture instruction set of the target application and submits the instruction compilation acceleration subtasks generated during the compilation process to the hardware acceleration layer.

[0106] The API virtualization layer 320 processes the calls to the source system API of the target application by adopting the corresponding API processing strategy according to the API type through the policy selector, and submits the API conversion acceleration subtask generated during the processing to the hardware acceleration layer.

[0107] The hardware acceleration layer 330 executes the instruction compilation acceleration subtask and the API conversion acceleration subtask.

[0108] Optionally, the instruction compilation layer 310 is specifically used for:

[0109] Based on hot path identification, the instruction type of the source architecture instruction in the source architecture instruction set of the target application is marked, and the instruction type includes: high-frequency instructions and low-frequency instructions;

[0110] The high-frequency instructions are dynamically compiled and stored in a memory cache;

[0111] For the low-frequency instructions, a cold path fallback strategy is adopted, and compilation is performed based on a lightweight interpreter.

[0112] Optionally, the API types of the target application include: basic API, graphics API, encryption-related API, and non-predefined API;

[0113] The policy selector in the API virtualization layer 320 includes:

[0114] The basic API processing module is used to, when the API type of the source system API of the target application is a basic API, select a static mapping channel to process the call to the source system API.

[0115] A graphics API processing module is used to, when the API type of the source system API of the target application is a graphics API, select a graphics translation channel to process the call to the source system API.

[0116] An encryption-related API processing module is used to, when the API type of the source system API of the target application is an encryption-related API, select the national cryptographic algorithm hardware offloading channel to process the call to the source system API.

[0117] The non-predefined API processing module is configured to, during the first processing when the API type of the source system API of the target application is a non-predefined API, use the strategy selector to predict the API processing strategy for the non-predefined API based on the API prediction channel, and process the call to the source system API based on the API processing strategy in the sandbox environment; during subsequent processing, the strategy selector matches an appropriate API processing strategy for the non-predefined API based on historical execution data and processes the call to the source system API.

[0118] Optionally, the non-predefined API processing module is specifically used for:

[0119] During the initial processing, the strategy selector selects an appropriate API prediction model to predict the API processing strategy for the non-predefined API based on the resource status of the central processing unit (CPU).

[0120] Within a sandbox environment with appropriate resource quotas, the API calls of the target application's source system APIs are processed based on the API processing strategy.

[0121] Optionally, for non-first-time processing, the historical execution data includes one or more of the following: historical prediction model, prediction success rate, sandbox execution time, and sandbox execution resource consumption value.

[0122] Optionally, the hardware acceleration layer 330 includes a resource monitoring module and an adaptive offloading controller;

[0123] The resource monitoring module monitors the service quality data during the compilation process of the instruction compilation layer on the source architecture instruction set of the target application, as well as the resource usage information of the API virtualization layer during the process of handling the source system API calls of the target application.

[0124] The adaptive unloading controller optimizes the resource allocation strategy in the instruction compilation acceleration subtask based on the quality of service data, and optimizes the resource allocation strategy in the API conversion acceleration subtask based on the resource usage information.

[0125] Optionally, the adaptive unloading controller is specifically used for:

[0126] The adaptive offloading controller matches hardware resources for the compilation acceleration subtasks corresponding to high-frequency instructions based on service quality data, and establishes a hardware acceleration channel to execute the compilation acceleration subtasks.

[0127] Based on the sandbox logs of the API virtualization layer and the resource status of the embedded neural network processor (NPU), the API prediction subtask in the API conversion acceleration subtask is offloaded to the NPU for execution.

[0128] The application dynamic compatibility system provided in the embodiments of the present invention can execute the application dynamic compatibility method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0129] Example 4

[0130] Figure 6 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0131] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0132] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0133] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as applying dynamic compatibility methods.

[0134] In some embodiments, the application dynamic compatibility method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the application dynamic compatibility method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the application dynamic compatibility method by any other suitable means (e.g., by means of firmware).

[0135] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0136] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0137] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0138] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0139] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0140] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0141] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0142] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for application dynamic compatibility, characterized in that, Applied to a dynamic compatibility system, the dynamic compatibility system includes: an instruction compilation layer, an application programming interface (API) virtualization layer, and a hardware acceleration layer; The instruction compilation layer compiles the source architecture instruction set of the target application and submits the instruction compilation acceleration subtasks generated during the compilation process to the hardware acceleration layer. The API virtualization layer uses a policy selector to process the source system API calls of the target application according to the API type and adopts the corresponding API processing policy, and submits the API conversion acceleration subtasks generated during the processing to the hardware acceleration layer. The hardware acceleration layer executes the instruction compilation acceleration subtask and the API conversion acceleration subtask; The instruction compilation layer compiles the source architecture instruction set of the target application, including: The instruction compilation layer identifies and marks the instruction type of the source architecture instructions in the source architecture instruction set of the target application based on hot path identification. The instruction type includes: high-frequency instructions and low-frequency instructions. The high-frequency instructions are dynamically compiled and stored in a memory cache; For the low-frequency instructions, a cold path fallback strategy is adopted, and compilation is performed based on a lightweight interpreter; The target application's API types include: basic APIs, graphics APIs, encryption-related APIs, and non-predefined APIs. The API virtualization layer processes calls to the target application's source system APIs using a policy selector and corresponding API processing strategies based on the API type, including: When the API type of the source system API of the target application is a basic API, the strategy selector selects a static mapping channel to process the call to the source system API; When the API type of the source system API of the target application is a graphics API, the strategy selector selects the graphics translation channel to process the call to the source system API; When the API type of the source system API of the target application is an encryption-related API, the policy selector selects the national cryptographic algorithm hardware offloading channel to process the call to the source system API. When the API type of the source system API of the target application is a non-predefined API, the strategy selector predicts the API processing strategy of the non-predefined API based on the API prediction channel during the first processing, and processes the call to the source system API based on the API processing strategy in the sandbox environment; when processing is not the first time, the strategy selector matches an appropriate API processing strategy for the non-predefined API based on historical execution data and processes the call to the source system API.

2. The method according to claim 1, characterized in that, During the initial processing, the strategy selector predicts the API processing strategy for the non-predefined API based on the API prediction channel, and processes the calls to the source system API within the sandbox environment based on the API processing strategy, including: During the initial processing, the strategy selector selects an appropriate API prediction model to predict the API processing strategy for the non-predefined API based on the resource status of the central processing unit (CPU). Within a sandbox environment with appropriate resource quotas, the API calls of the target application's source system APIs are processed based on the API processing strategy.

3. The method according to claim 2, characterized in that, When not processing for the first time, the historical execution data includes one or more of the following: historical prediction model, prediction success rate, sandbox execution time, and sandbox execution resource consumption value.

4. The method according to claim 1, characterized in that, The hardware acceleration layer includes a resource monitoring module and an adaptive offloading controller; The resource monitoring module monitors the service quality data during the compilation process of the instruction compilation layer on the source architecture instruction set of the target application, as well as the resource usage information of the API virtualization layer during the process of handling the call of the source system API of the target application. The adaptive unloading controller optimizes the resource allocation strategy in the instruction compilation acceleration subtask based on the quality of service data, and optimizes the resource allocation strategy in the API conversion acceleration subtask based on the resource usage information.

5. The method according to claim 4, characterized in that, The adaptive unloading controller optimizes the resource allocation strategy in the instruction compilation acceleration subtask based on the service quality data, and optimizes the resource allocation strategy in the API conversion acceleration subtask based on the resource usage information, including: The adaptive offloading controller matches hardware resources for the compilation acceleration subtasks corresponding to high-frequency instructions based on service quality data, and establishes a hardware acceleration channel to execute the compilation acceleration subtasks. Based on the sandbox logs of the API virtualization layer and the resource status of the embedded neural network processor (NPU), the API prediction subtask in the API conversion acceleration subtask is offloaded to the NPU for execution.

6. An application-dynamic compatibility system, characterized in that, include: Instruction compilation layer, application programming interface (API) virtualization layer, and hardware acceleration layer; The instruction compilation layer compiles the source architecture instruction set of the target application and submits the instruction compilation acceleration subtasks generated during the compilation process to the hardware acceleration layer. The API virtualization layer processes the calls to the source system APIs of the target application using a policy selector based on the API type and the corresponding API processing policy, and submits the API conversion acceleration subtasks generated during the processing to the hardware acceleration layer. The hardware acceleration layer executes the instruction compilation acceleration subtask and the API conversion acceleration subtask. The instruction compilation layer is specifically used for: Based on hot path identification, the instruction type of the source architecture instruction in the source architecture instruction set of the target application is marked, and the instruction type includes: high-frequency instructions and low-frequency instructions; The high-frequency instructions are dynamically compiled and stored in a memory cache; For the low-frequency instructions, a cold path fallback strategy is adopted, and compilation is performed based on a lightweight interpreter; The target application's API types include: basic APIs, graphics APIs, encryption-related APIs, and non-predefined APIs; the policy selector in the API virtualization layer includes: The basic API processing module is used to, when the API type of the source system API of the target application is a basic API, select a static mapping channel to process the call to the source system API. A graphics API processing module is used to, when the API type of the source system API of the target application is a graphics API, select a graphics translation channel to process the call to the source system API. An encryption-related API processing module is used to, when the API type of the source system API of the target application is an encryption-related API, select the national cryptographic algorithm hardware offloading channel to process the call to the source system API. The non-predefined API processing module is configured to, during the first processing when the API type of the source system API of the target application is a non-predefined API, use the strategy selector to predict the API processing strategy for the non-predefined API based on the API prediction channel, and process the call to the source system API based on the API processing strategy in the sandbox environment; during subsequent processing, the strategy selector matches an appropriate API processing strategy for the non-predefined API based on historical execution data and processes the call to the source system API.

7. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the application dynamic compatibility method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the application dynamic compatibility method according to any one of claims 1-5.

Images