Function execution method, device and equipment and readable storage medium

Abstract

The embodiment of the invention provides a function execution method and device, electronic equipment and a readable storage medium, and belongs to the technical field of computers. The method comprises the following steps: in response to a calling instruction for a heterogeneous function in a target program, starting to execute the heterogeneous function through a translator; the heterogeneous function is compiled and generated by a first framework, and the first framework is different from a second framework for operating the target program; calling a target function of the second architecture through a target interface function based on the heterogeneous function, obtaining a first target parameter of the heterogeneous function through the target interface function, converting the first target parameter of the heterogeneous function into a second target parameter of the second architecture, and transmitting the second target parameter to the target function; and controlling the target function to execute based on the second target parameter, obtaining an execution result, and returning the execution result to the heterogeneous function, thereby completing calling of the target function by the heterogeneous function. Through the embodiment of the invention, the target functions of different architectures can be smoothly called by the heterogeneous function.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and in particular relates to a function execution method, device, electronic device and readable storage medium. Background Art

[0002] In a Java program, there are some functions written in non-Java languages. These functions are called native functions. The Java virtual machine interacts with these native functions through the JNI (Java native Interface) function. When a Java program calls a native function, the native function calls methods in the Java virtual machine through the JNI function to complete certain tasks.

[0003] When a Java program is ported to another CPU architecture, a dynamic translator is built on the new CPU architecture to translate the program so that the native function can execute normally under the new CPU architecture. However, some JNI functions include variable parameters, and the number of variable parameters is not specified when they are defined. The definition method of variable parameters also varies under different CPU architectures. As a result, the call result obtained by the native function from the Java virtual machine may be different from the expected call result, thus affecting the Java program's call to the native function. Summary of the Invention

[0004] The present invention aims to provide a function execution method, device, electronic device and readable storage medium, which at least solve the problems in the prior art.

[0005] In order to solve the above-mentioned technical problems, the present invention is achieved as follows:

[0006] In a first aspect, an embodiment of the present invention provides a function execution method, the method comprising:

[0007] In response to a call instruction to a heterogeneous function in a target program, executing the heterogeneous function through a translator; the heterogeneous function is compiled and generated by a first architecture, the first architecture being different from a second architecture on which the target program is executed;

[0008] calling a target function of the second architecture through a target interface function based on the heterogeneous function, obtaining a first target parameter of the heterogeneous function through the target interface function, converting the first target parameter of the heterogeneous function into a second target parameter of the second architecture, and passing the second target parameter to the target function;

[0009] The target function is controlled to be executed based on the second target parameter, and an execution result is obtained and returned to the heterogeneous function, thereby completing the call of the heterogeneous function to the target function.

[0010] In a second aspect, an embodiment of the present invention further provides a function execution device, the device comprising:

[0011] A main calling module: in response to a call instruction to a heterogeneous function in a target program, starting to execute the heterogeneous function through a translator; the heterogeneous function is compiled and generated by a first architecture, the first architecture being different from a second architecture running the target program;

[0012] A translation module is configured to call a target function of the second architecture through a target interface function based on the heterogeneous function, obtain a first target parameter of the heterogeneous function through the target interface function, convert the first target parameter of the heterogeneous function into a second target parameter of the second architecture, and pass the second target parameter to the target function;

[0013] Execution module: used to execute the target function based on the second target parameter to obtain the execution result and return it to the heterogeneous function, thereby completing the call of the heterogeneous function to the target function.

[0014] In a third aspect, an embodiment of the present invention further provides an electronic device comprising a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements the steps of the function execution method described in the first aspect.

[0015] In a fourth aspect, an embodiment of the present invention further provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the function execution method described in the first aspect are implemented.

[0016] In an embodiment of the present invention, a target program runs in a virtual machine based on a second architecture, and in the process of the target program calling a heterogeneous function compiled and generated by the first architecture; when the heterogeneous function needs to call a target function in the virtual machine, and the first target parameter based on the first architecture is used in the heterogeneous function, the first target parameter is converted into a second target parameter that matches the second architecture through a translator, and then the execution of the target function is completed based on the second target parameter, and the execution result of the target function is returned to the heterogeneous function to complete the call of the heterogeneous function to the target function. In an embodiment of the present invention, the heterogeneous function is executed by a translator, ensuring that all types of data including the first target parameter in the heterogeneous function can be smoothly converted by the translator to adapt to the target function based on the second architecture; by obtaining the first target parameter corresponding to the heterogeneous function and converting the first target parameter into the second target parameter that matches the first architecture, it is ensured that the target function can be executed normally after receiving the second target parameter and return the correct execution result to the heterogeneous function, so that the execution process of the heterogeneous function proceeds smoothly, further ensuring the smooth operation of the target program; through the solution provided by the embodiment of the present invention, correct cross-structure calls are realized during the function execution process. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flowchart of a function execution method provided by an embodiment of the present invention;

[0018] Figure 2 This is a schematic diagram of an architecture provided by an embodiment of the present invention;

[0019] Figure 3 is a flowchart of another function execution method provided by an embodiment of the present invention;

[0020] Figure 4 This is a schematic diagram of a heterogeneous function calling process provided by an embodiment of the present invention;

[0021] Figure 5 This is another architectural diagram provided by an embodiment of the present invention;

[0022] Figure 6 This is a flowchart of another method for executing a function provided by an embodiment of the present invention;

[0023] Figure 7 is a block diagram of a function execution device provided by an embodiment of the present invention;

[0024] Figure 8 This is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0025] The technical solutions in the embodiments of the present invention will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present invention.

[0026] Figure 1 This is a flow chart of the steps of a function execution method provided by an embodiment of the present invention. Figure 1 As shown, the method may include:

[0027] Step 101: In response to a call instruction to a heterogeneous function in a target program, start executing the heterogeneous function through a translator; the heterogeneous function is compiled and generated by a first architecture, and the first architecture is different from a second architecture running the target program.

[0028] In an embodiment of the present invention, the target program is written in Java and can run normally on a platform of a first architecture. It is an application program that currently needs to be ported to a platform of a second architecture to run. The first architecture and the second architecture can be one of the architectures such as x86, ARM, RISC-V, etc., and the two are different.

[0029] During the execution of the target program, in order to achieve code reuse, various functions will be called to perform different tasks. Since the Java Virtual Machine (JVM) that runs Java programs has a lower operating efficiency than directly compiled C or C++ files, and the JVM lacks the ability to directly operate hardware resources, some functions need to be implemented using non-Java languages such as C or C++. These functions are called native functions. After the target program is executed on a platform with a first architecture, the native functions will be compiled into binary files to improve execution efficiency. When the target program is ported to a platform with a second architecture for execution, the compatibility of these binary files needs to be considered: native functions are compiled into binary files to store data. The form of binary encoding in the binary file depends on the CPU architecture of the target program when the native function is compiled. If the target program is ported to a platform device with another architecture for execution, these native functions that have not been rewritten and compiled will be called heterogeneous functions.

[0030] Translators can be used to ensure native function compatibility across different architectures. A translator is a tool that converts program code from a source format or instruction set to a target format or instruction set. The system or architecture platform where the translator resides is called the host, and the host format is the target format. The system or architecture platform for the program code executed or translated by the translator is called the guest, and the guest format is the source format. The translator's task is to translate the guest's instruction set or program code into a form that the host can understand and execute. For example, if a tool for emulating an x86 program is running on an ARM architecture platform device, the ARM architecture is the host platform and the x86 architecture is the guest platform. This tool is called a translator.

[0031] Dynamic translator can complete the above conversion in the process of program code running, and is a commonly used translator, and common dynamic translators include QEMU, Box64, LLVM, LATX, etc. In the process of calling heterogeneous functions, a dynamic translator can be used to create an operating environment for heterogeneous functions, thereby ensuring that the instructions in the heterogeneous functions can be normally executed. Translator (the translator in the embodiment of the present application is a dynamic translator) realizes the normal operation of the target program on the second architecture by translating the heterogeneous functions in the target program.

[0032] like Figure 2 As shown, Figure 2 This is a schematic diagram of an architecture provided by an embodiment of the present invention, wherein the mutual calling relationship among target program, heterogeneous functions and target function is as follows: Figure 2 As shown in the figure; the virtual machine (JVM) running the target program interacts with the heterogeneous function (native) through the Java native Interface (JNI); the target program will call the heterogeneous function during execution; and in the process of executing the heterogeneous function, the heterogeneous function will have the need to call some specific functions (i.e., target functions) in the JVM. At this time, the heterogeneous function needs to use the JNI function (target interface function) to implement the call of the heterogeneous function to the target function; after the execution of the target function is completed, the execution result of the target function is returned to the heterogeneous function to complete the call of the heterogeneous function to the target function, and then the heterogeneous function continues to be executed. After the execution of the heterogeneous function is completed, the execution result of the heterogeneous function is returned to the target program, thereby completing the call of the target program to the heterogeneous function.

[0033] Step 102: Call the target function of the second architecture through the target interface function based on the heterogeneous function, obtain the first target parameter of the heterogeneous function through the target interface function, convert the first target parameter of the heterogeneous function into the second target parameter of the second architecture, and pass the second target parameter to the target function.

[0034] During the process of a heterogeneous function calling a target function, the translator copies the data in the parameter registers and memory stack to the parameter registers and memory stack corresponding to the target function according to the parameter types of the heterogeneous function and the target function. That is, the translator only performs numerical transfer when processing the parameters of the heterogeneous function; however, when the heterogeneous function calls the target function, there will be variable parameters (the first target parameter); when declaring a function that uses variable parameters, the specific parameter type of the variable parameters (such as string, number, Boolean value, etc.) is not specified, nor is the number of variable parameters specified. For a variable parameter as a whole, the number, type, and order of each variable parameter (sub-parameter of the variable parameter) need to be determined during the function's execution; due to the different hardware characteristics in different computer architectures (such as the different number of registers, the different number of bits that registers can process data, etc.), different computer architectures define variable parameters differently, so it is impossible to directly parse the type, number, order, and specific parameter values of the variable parameters from the structure that defines the variable parameters. Therefore, the variable parameters passed in by the heterogeneous function of the first architecture often cannot be correctly parsed in the target function of the second architecture, resulting in the target function being unable to return the correct execution result to the heterogeneous function, which in turn leads to errors in the execution process of the heterogeneous function, thereby affecting the normal operation of the target program.

[0035] For example, printf is a function that uses variable parameters to print input content; when calling printf, the specific type of the input parameter needs to be specified through the format string "%d%f%s", that is, the specific type or number of printf's input parameters can only be confirmed when printf is executed.

[0036] The heterogeneous function calls the target function through the target interface function (JNI function). For example, the heterogeneous function creates a new Java object through the target interface function jni_NewObjectV. The field "jni_" indicates that the function is a target interface function (JNI function). In the function declaration, the target interface function jni_NewObjectV passes the parameters of the constructor (i.e., the target function) that creates this Java object in the Java code through the variable parameter va_list. That is, the heterogeneous function calls the target interface function jni_NewObjectV, which is equivalent to executing the constructor (target function) in the Java code.

[0037] Variable parameters are implemented differently in different architectures. Taking heterogeneous functions as C or C++ programs based on the first architecture and x86 architecture as an example, the structure "typedef struct{…}va_list[1]" that implements the variable parameter va_list is defined. The offset in the general register is represented by the code field "unsigned int gp_offset", the offset in the floating-point register is represented by the code field "unsigned int fp_offset", the starting address of the overflow parameter in the memory stack is represented by the code field "void*overflow_arg_area", and the area where the register saves the parameter is represented by the code field "void*reg_save_area". In the x86 definition of va_list, the first 6 integer parameters and the first 8 floating-point type parameters in the va_list as a whole are saved by registers, and the part of the va_list as a whole that exceeds the register limit is saved by the memory stack.

[0038] In the target architecture, in the structure typedef struct{…}va_list[1] that implements the variable parameter va_list, the code field "void*__stack" is used to represent the starting address of the overflow parameter in the memory stack, the code field "void*__gr_top" is used to represent the top data bit of the general parameter in the general register storage area, the code field "void*__vr_top" is used to represent the top data bit of the parameter in the floating-point register storage area, the code field "int__gr_offs" is used to represent the current offset of the general register, and the code field "int__vr_offs" is used to represent the current offset of the floating-point register. In the definition of va_list in the target architecture, the first 8 integer parameters and the first 4 floating-point type parameters in the va_list as a whole are saved through registers, and the part of the va_list as a whole that exceeds the register limit is saved by the memory stack.

[0039] In the related art, when executing a heterogeneous function, the translator does not record the number and type of parameters used by the heterogeneous function, but only copies the parameter value stored in the specified address to another specified address to complete the parameter transfer; therefore, when calling a target interface function such as jni_NewObjectV, the translator will directly move the entire va_list based on the first architecture without considering the format of each sub-parameter in the va_list. For example, the parameter value of the integer parameter originally stored in the general register under the first architecture is copied to the floating-point register that stores the floating-point type parameter under the second architecture. As a result, the device of the second architecture incorrectly recognizes the parameter type or number of the sub-parameters in the va_list, thereby causing the execution result of the target function based on the second architecture to be erroneous, which in turn affects the call of the target function by the heterogeneous function.

[0040] In order to solve the above problems, an embodiment of the present invention provides a method for executing a heterogeneous function; first, during the execution of a target program, the heterogeneous function is started by calling an instruction of the target program to the heterogeneous function. Since the first architecture compiled to generate the heterogeneous function is different from the second architecture for running the target program, the heterogeneous function is executed by a translator, and a running environment based on the first architecture is constructed for the heterogeneous function by the translator; during the execution of the heterogeneous function, if the heterogeneous function needs to call a target function of the second architecture, the first target parameter of the heterogeneous function is queried and obtained; since the first target parameter is defined under the first architecture, and the type, number and order of the first target parameter can only be determined during the execution of the corresponding function, the target function based on the second architecture cannot correctly parse the first target parameter, so it is necessary to first obtain the first target parameter and translate the first target parameter to match the second architecture to ensure that the target function based on the second architecture can be smoothly executed based on the processed first target parameter, thereby allowing the target program to run normally.

[0041] The target function includes a function executed by the JVM in the Java Runtime Environment (JRE), that is, the target function includes a functional function in the JVM; in some embodiments, the target function also includes a Java function written and implemented by a programmer.

[0042] The location where the first target parameter is stored can be determined by the variable parameter definition rule file under the first architecture, thereby extracting the parameter value of the first target parameter. The variable parameter definition rule file is a technical document (its storage form includes but is not limited to electronic documents, paper documents, etc., wherein the electronic document may include web documents, PDF files, etc.), which records the specifications for storing and transmitting variable parameters. By parsing the corresponding content in the technical document, the location where the variable parameter (first target parameter) is stored in the device of the first architecture can be determined; illustratively, the rules recorded in the definition rule file include the System-V Application Binary Interface (ABI), which is widely used in a variety of computer architectures, but for different computer architectures, different System-V ABIs will be formulated based on the characteristics of the hardware.

[0043] After obtaining the first target parameter from the heterogeneous function based on the first architecture, the first target parameter needs to be converted to a second target parameter matching the second architecture.

[0044] Exemplarily, the conversion process may include: extracting the parameter value of each sub-parameter of the first target parameter, converting the parameter values of the sub-parameters of the first target parameter into parameter values matching the second architecture one by one according to the correspondence between the definition rule file of the variable parameters under the first architecture and the definition rule file of the variable parameters under the second architecture, and then saving the parameter values of these sub-parameters to a specified location, thereby realizing the conversion between the first target parameter and the second target parameter.

[0045] The specific parameter information of a heterogeneous function can be obtained through the function signature. A function signature is a string data structure used to describe the function's parameters, return value, and other information. By obtaining a function with a specific signature, the function signature can be obtained during the function execution process to determine the specific parameter information (including the number of parameters, parameter types, and parameter order) during the function execution process. For example, the function signature "int add(int a, int b)" indicates that the return value of the function add is int, and its parameters are a and b in order, and the parameter types of a and b are both int.

[0046] Since heterogeneous functions need to call the target function through the target interface function, the specific parameter information of the first target parameter can be obtained by obtaining the function signature of the target interface function. Through the specific parameter information, the parameter type, number of parameters and parameter order of each sub-parameter in the first target parameter can be determined, so that the parameter values of the sub-parameters of the first target parameter can be converted in sequence. For example, the function signature of the target interface function jni_NewObjectV is "jobjectNewObjectV(JNIEnv*env,jclass clazz,jmethodID methodID,va_list args)", which indicates that the return value of the function jni_NewObjectV is jobject, that is, a Java object, and its parameters are env, clazz, methodID, and args in order. The types of these parameters are JNIEnv*, that is, environment pointer, jclass, that is, Java class, jmethodID, that is, function ID, and va_list, that is, variable parameters (the first target parameter). Among them, by parsing va_list, it can be seen that it includes jstring name and jint age. The number of parameters of the first variable parameter is 2, and the order is name and age. The types are jstring and jint, that is, strings in Java and integers in Java, respectively.

[0047] Step 103: Control the objective function to execute based on the second objective parameter, obtain the execution result and return it to the heterogeneous function, thereby completing the call of the heterogeneous function to the objective function.

[0048] After obtaining the second target parameter, the second target parameter is passed to the target function to enable the target function to execute smoothly; when the target function is executed smoothly and the execution result is obtained, the execution result is returned to the heterogeneous function, and the heterogeneous function will use the execution result as the return value of calling the target function, complete the call to the target function, and continue to execute subsequent tasks.

[0049] It should be noted here that the JVM running the target program (Java program) can be implemented in C or C++ (i.e., the programming language corresponding to heterogeneous functions), so that the heterogeneous function can directly access the execution result of the target function, increasing the efficiency of the heterogeneous function calling the target function.

[0050] In summary, in an embodiment of the present invention, the target program runs in a virtual machine based on the second architecture, and in the process of the target program calling the heterogeneous function compiled and generated by the first architecture; when the heterogeneous function needs to call the target function in the virtual machine, and the first target parameter based on the first architecture is used in the heterogeneous function, the first target parameter is converted into a second target parameter matching the second architecture through the translator, and then the execution of the target function is completed based on the second target parameter, and the execution result of the target function will be returned to the heterogeneous function to complete the call of the target function by the heterogeneous function. In the related art, the first target parameter is defined differently under the first architecture and the second architecture, and the specific type and number of parameters of the first target parameter are not determined when defined. Directly using the first target parameter based on the first architecture will cause the actual execution result of the target function to deviate from the expectation, thereby causing an error in the execution process of the heterogeneous function. In an embodiment of the present invention, the heterogeneous function is executed by a translator to ensure that all types of data in the heterogeneous function, including the first target parameter, can be converted by the translator to adapt to the target function based on the second architecture. By obtaining the first target parameter and converting the first target parameter into a second target parameter that matches the first architecture, it is ensured that the target function can be executed normally after receiving the second target parameter and return the correct execution result to the heterogeneous function, thereby ensuring the smooth execution process of the heterogeneous function and further ensuring the smooth operation of the target program. The solution provided by the embodiment of the present invention can realize correct cross-structure calls during function execution.

[0051] Figure 3 This is a flowchart of another method for executing a function provided by an embodiment of the present invention. Figure 3 include:

[0052] Step 201: In response to a call instruction to a heterogeneous function in a target program, start executing the heterogeneous function through a translator; the heterogeneous function is compiled and generated by a first architecture, and the first architecture is different from a second architecture running the target program.

[0053] This step may be specifically referred to the above step 101 and will not be described in detail here.

[0054] Optionally, in some embodiments, step 201 may include:

[0055] Sub-step 2011: The source code of the translator is configured as a shared function file, and the shared function file is executed to establish a second thread running the translator; the first thread and the second thread are located in the process running the virtual machine; the target program is run by the first thread.

[0056] Since the solution provided by the embodiment of the present invention is based on the process of the target program calling the heterogeneous function (the process includes the execution process of the heterogeneous function), and the translator can solve the problem that the target program cannot call the heterogeneous function due to the inconsistency between the second architecture for running the target program and the first architecture for compiling and generating the heterogeneous function, the translator can be improved on this basis and shared in the form of a file so that the translator only processes data related to the heterogeneous function, thereby improving the efficiency of the target program calling the heterogeneous function.

[0057] Specifically, the translator's source code is configured as a shared function file (i.e., packaged as a library function). When the target program calls a heterogeneous function compiled and generated by the first architecture, the shared function file is executed. A dedicated thread (second thread) can be established to run the translator, while the thread running the target program of the second architecture is the first thread. Both threads are included in the process running the virtual machine (i.e., JVM). For example, the translator's main function (main function) can be packaged as a function named translator_launch, and additional parameters can be added to translator_launch to store data related to the target interface function, so that the translator can process the first target parameter of the first architecture obtained from the target interface function.

[0058] The improved target program's calling process for heterogeneous functions is as follows: Figure 4 As shown, the translator executes heterogeneous functions through heterogeneous function handlers. Figure 4 Step A1. Setting parameters in the above example is to set the parameters used when the target program calls the heterogeneous function. Figure 4 Step A3 in the above code is to get the return value, which means to get the result of executing the heterogeneous function. Figure 2 The execution result of the heterogeneous function in the embodiment of the present invention is mainly caused by the following steps: Figure 4 Between step A2 and step A3 in the improved architecture is as follows Figure 5 As shown, both the translator and the target program run in a virtual machine (JVM).

[0059] Since the first thread running the target program and the second thread running the translator are in the same virtual machine (JVM) process, that is, the target program and the translator are threads of the same level after the improvement, compared with Figure 2The translator and the virtual machine are processes of the same level. The translator can directly access the parent process, that is, the memory segment corresponding to the virtual machine process, and the target program also directly uses the memory segment corresponding to the virtual machine process. Therefore, the target program and the virtual machine can communicate through the memory segment corresponding to the virtual machine process shared to all threads in the virtual machine, thereby improving the communication efficiency between the target program and the translator, and further improving the efficiency of the translator in executing heterogeneous functions; in addition, by configuring the translator as a shared function file, the coupling between the translator and the JVM code can be reduced, which facilitates the debugging and maintenance of the translator.

[0060] Step 202: When the heterogeneous function calls the target function of the second architecture, obtain the first target parameter of the heterogeneous function through the target interface function; the heterogeneous function calls the target function in the virtual machine through the target interface function.

[0061] Since the target function needs to be executed in the virtual machine, and the heterogeneous function interacts with the virtual machine through the target interface function, the first target parameter of the heterogeneous function can be directly obtained from the target interface function.

[0062] There are many types of JNI functions (interface functions), including, for example, class operation functions, such as FindClass, which are used to find and return a reference to a specified class; object operation functions, such as NewObjectV, which are used to create Java objects based on variable parameters (first target parameters); field access, such as GetObjectField, which is used to obtain the value of an instance field of a Java object; method call functions, such as CallVoidMethod, which are used to call an instance method of a Java object; and exception handling functions, such as ThrowNew, which are used to create and throw Java exceptions. Among them, the target interface function will use variable parameters, such as NewObjectV, CallVoidMethod, CallNonvirtual, VoidMethod, etc. For these target interface functions, variable parameters can be extracted, and the variable function (first target parameter) of the first architecture can be converted to the second target parameter of the second architecture for execution by the target function, thereby adapting to the conversion of the second architecture.

[0063] Optionally, the heterogeneous function is divided into multiple basic blocks during execution, and step 202 may include:

[0064] Sub-step 2021: When the basic block meets a preset condition, confirm that the target interface function is running in the basic block, and the target interface function includes a first target parameter.

[0065] Sub-step 2022: Obtain the first target parameter in the target interface function corresponding to the basic block respectively

[0066] Sub-steps 2021-2022 represent how to confirm that the target interface function used by the heterogeneous function includes the first target parameter. When executing a heterogeneous function, the translator divides the running heterogeneous function into multiple basic blocks. Each basic block represents a continuous and uninterrupted instruction sequence with a unique entry and exit, and no instruction jumps are performed within the basic block. The translator divides the heterogeneous function into basic blocks, which is conducive to the analysis and debugging of the heterogeneous function, such as analyzing the control flow and data flow of the heterogeneous function, and the register allocation during the function execution process.

[0067] Each basic block represents a part of a heterogeneous function. The translator will translate and execute the heterogeneous functions in sequence based on the basic blocks, thereby completing the execution of the entire heterogeneous function. For each basic block, it is necessary to determine whether the instruction sequence represented by the basic block is an interface function through preset conditions. When the basic block includes an interface function, it is further confirmed that the interface function is the target interface function, that is, a JNI function with variable parameters.

[0068] For example, the heterogeneous function calls jni_NewObjectV to create a student object. The process can be divided into the following basic blocks: initialization, parameter preparation, object creation, and resource cleanup; the initialization basic block executes the sub-function FindClass in the heterogeneous function through the code segment "jclassstudentClass=env->FindClass("com / example / Student");" to reference the student class to which the student object belongs; the parameter preparation basic block constructs the parameter array of the student object through the code segment "jvalue args[2]", and generates va_list through the code segments "va_list va" and "*(jvalue**)&va=args"; the object creation basic block creates the object through the code segment "jobject student=env->jni_NewObjectV(studentClass,constructor,va);", which is the basic block that executes the target interface function; the resource cleanup basic block cleans up the reference to the student class through the code segment "env->DeleteLocalRef(studentClass)". By analyzing the above basic blocks, we can confirm that the object creation basic block executes the target interface function jni_NewObjectV.

[0069] Optionally, entry addresses of all interface functions are stored in the translator when the translator is created; the preset condition is that the recorded value of the program counter of the basic block matches the entry address of the target interface function, and the parameter type of the interface function is a preset parameter type. Sub-step 2021 may include:

[0070] Sub-step 20211: Check the program counter of the basic block. If the recorded value of the program counter of the basic block matches the entry address of the target interface function, confirm that the target interface function is running in the basic block.

[0071] Sub-step 20212: acquiring a target variable for storing the target interface function according to the entry address;

[0072] Sub-step 20213: Check the target attribute of the target variable to determine the parameter type of the target interface function;

[0073] Sub-step 20214: When the parameter type is a preset parameter type, confirm that the target interface function includes the first target parameter.

[0074] Sub-steps 20211-20214 explain sub-step 2021; the program counter (PC) records the entry address of the basic block (in some embodiments, the program counter is also called the Instruction Pointer, IP). After the current basic block is executed, the PC will point to the entry address of the next basic block. By reading the value stored in the PC (that is, the pointed address), the entry address of the current basic block can be obtained, thereby determining whether the basic block corresponds to a JNI function.

[0075] The target interface function JNI includes a JNIEnv structure. The JNIEnv structure records all JNI functions through a function table (JNIEnv is a pointer to this function table), including the storage addresses of these JNI functions in memory. When the translator is started, JNIEnv will be sent to the translator so that the translator can smoothly execute heterogeneous functions. Therefore, after reading the value stored in PC, it can be compared with the storage address in the function table pointed to by JNIEnv. When the entry address of the basic block matches the storage address of the JNI function, it can be confirmed that the current basic block is running the target interface function.

[0076] For example, in JNIEnv, the storage address of the target interface function jni_NewObjectV is 0x08048000. Through the GetProgramCounter method, the entry address of the basic block currently recorded by PC can be read, and the entry address of the currently executed basic block is also 0x08048000. The entry address is consistent with the storage address of the target interface function, indicating that the function being executed by the current basic block is the target interface function jni_NewObjectV.

[0077] After obtaining the interface function, it is also necessary to determine whether the target interface function corresponding to the current basic block is using variable parameters (first target parameters); specifically, it is necessary to locate the target variable according to the entry address in the PC, that is, to locate the variable that stores the specified target interface function. In this target variable representing the target interface function, there is a target attribute that represents the function parameters. By checking the value of the target attribute, it is possible to determine what types of parameters are in the target interface function. By comparing with the preset parameter type, it can be determined whether the target interface function includes variable parameters. When the value of the target attribute represents that the target interface function includes the preset parameter type, it can be confirmed that the target interface function includes the first target parameter.

[0078] For example, in the x86 architecture, the program counter includes the EIP register. After the target interface function is loaded into the memory, the instruction mov eax,0x08048000 can be used to load the entry address (0x08048000) into the middle EAX register, and then the instruction mov[EIP],eax can be used to load the entry address saved in the EAX register into the program counter. Through 0x08048000, the variable "a" storing the target interface function can be located. By reading the subvariable "a1" in the variable "a", the target attribute of the recorded parameter type can be obtained. The subvariable "a1" includes a "va_list" string, which is consistent with the preset "va_list" string. Therefore, it can be indicated that the parameters being used by the target interface function include the variable parameter va_list, that is, the target interface function includes the first target parameter. When it is determined that the target interface function in the basic block includes the first target parameter, the conversion of the first target parameter can be started.

[0079] Step 203: During the execution of the target interface function, obtain the function signature of the target interface function; the function signature is used to represent parameter information of the target interface function during the execution process.

[0080] The characteristics of variable parameters include that the number, type, and order of the parameters of the variable parameters can only be determined when the function using the variable parameters is executed; and through the function signature of the target interface function, detailed information about the parameters of the target interface function, including the number of parameters, specific parameter types, and parameter order, can be obtained.

[0081] For example, jni_NewObjectV includes a variable parameter va_list, but the function declaration of jni_NewObjectV does not restrict va_list. Only when jni_NewObjectV is called, for example, by using the code segment "jobjectstudent = env->jni_NewObjectV(studentClass,constructor,va_list);" to generate a Java object named student, can specific means be used to parse the va_list to determine the specific number of parameters, their types, and their order. For example, by obtaining the function signature of jni_NewObjectV (jString name, I score)v, it can be confirmed that it includes a parameter named name of type string (jString corresponds to string) and a parameter named score of type int (I corresponds to int).

[0082] Optionally, step 203 may include:

[0083] Sub-step 2031: Control the translator to read the third target parameter of the target interface function to obtain the identity of the target interface function.

[0084] Sub-step 2032: Based on the identity identifier of the target interface function, obtain the execution result of the signature acquisition function in the virtual machine to obtain the function signature of the target interface function.

[0085] Sub-steps 2031 and 2032 describe the steps of how to obtain the function signature of the target interface; the description of the function signature can be referred to step 103 above and will not be repeated here; the above steps specifically include obtaining the third target parameter of the target interface function, the third target parameter is used to represent the function identity of the target interface function, and each target interface function has a third target parameter; the function identity of the target interface function can be obtained by extracting the third target parameter through the translator, and in the virtual machine, a signature acquisition function is included, which can return the function signature of the specified function by inputting the function identity of the specified function; therefore, the function signature of the target interface function can be obtained by extracting the third target parameter of the target interface function through the translator, and using the third target parameter as the input parameter of the signature acquisition function.

[0086] For example, in the target interface function f(a, b), a represents the first target parameter of the target interface function f (such as va_list), and b represents the third target parameter of the target interface function f (such as method_id). In the JVM, the signature acquisition function includes resolve_jmethod_id. By copying method_id to the storage location of the parameters of resolve_jmethod_id (parameter registers and memory stack), then jumping to the entry address of resolve_jmethod_id to execute resolve_jmethod_id, the function signature of the target interface function f can be obtained.

[0087] Step 204: Based on the function signature of the target interface function, convert the first target parameter into a second target parameter corresponding to the second architecture.

[0088] This step can refer to the above step 103 and will not be described again here.

[0089] Optionally, the parameter information in the function signature includes the number of parameters and the order of parameters. Step 204 may include

[0090] Sub-step 2041: extracting the parameter value of the first target parameter from a first preset storage location in the memory according to the parameter information in the function signature and the variable parameter definition rule file of the first architecture.

[0091] Sub-step 2042: According to the parameter information in the function signature and the correspondence between the variable parameter definition rule file of the first architecture and the variable parameter definition rule file of the second architecture, determine the parameter value of the second target parameter corresponding to the parameter value of the first target parameter in sequence.

[0092] Sub-steps 2041 to 2042 describe how to convert the parameter value of the first target parameter based on the function signature, so as to obtain the corresponding parameter value of the second target parameter. Specifically, it includes reading the value in the first preset storage location according to the function signature of the target interface function and the variable parameter definition rule file of the first architecture, that is, the positioning rule file in step 102 above, and using it as the parameter value of the first target parameter. After obtaining the parameters of the first target parameter, according to the parameter information in the function signature, the corresponding relationship between the variable parameter definition rule file of the first architecture and the variable parameter definition rule file of the second architecture (including the corresponding relationship between the different storage formats of the same type of parameters under the two definition rule files), the parameter value of the first target parameter is converted into the parameter value of the second target parameter that matches the second architecture.

[0093] Optionally, the parameter value of the first target parameter includes parameter values of sub-parameters of the first target parameter, and sub-step 2041 may include:

[0094] Sub-step 20411: Determine, based on the function signature, a first storage format, a number of parameters, and a parameter order of sub-parameters in the first target parameter; the first storage format represents a storage specification of the sub-parameters in the variable parameter definition rule file of the first architecture;

[0095] Sub-step 20412: divide a target area from the memory according to the first storage format, the number of parameters, and the order of parameters, and use the target area as the first preset storage location.

[0096] Sub-step 20413: extract the parameter value corresponding to each of the sub-parameters from the first preset storage location.

[0097] Sub-steps 20411-20413 describe in detail the execution process of the above sub-step 2041, that is, how to extract the parameter value of the first target parameter. Specifically, it includes, according to the function signature, obtaining the parameter type (for va_list, its essence is an array of indefinite length, and the sub-parameter represents each element in the array) of the first target parameter (for example, integer, floating-point type, etc.), according to the parameter type, confirming how the parameter type is stored in the variable parameter definition rule file of the first architecture, and confirming the storage specification of the parameter type under the first architecture. Through the storage specification, the starting position of the first target parameter in the memory can be calibrated, and according to the number of parameters and the order of parameters in the function signature, the length of the space occupied by the first target parameter in the memory segment can be determined; according to the starting position and the length of the space, a memory segment for storing the parameter value of the first target parameter, that is, the first preset storage location, can be divided from the memory; by reading the values in the first preset storage location in sequence, the parameter value of the first target parameter can be extracted.

[0098] Exemplarily, taking x86 as the first architecture, under the x86 architecture, through the variable parameter definition rule file, the sub-parameters of va_list are stored in the specified first preset storage location in the x86 architecture device, including two areas marked as reg_save_area and arg_area in the memory stack. According to the function signature, the first target parameter has a total of n+m sub-parameters, so starting from the starting address segment of reg_save_area, data in n address segments can be obtained, and starting from the starting address segment of arg_area, data in m address segments can be obtained; the value of the above n+m data is the parameter value of the first target parameter.

[0099] Optionally, sub-step 2042 may include:

[0100] Sub-step 20421: determining a second storage format for each sub-parameter in the first target parameter; the second storage format represents a storage specification for the sub-parameter in the variable parameter definition rule file of the second architecture;

[0101] Sub-step 20422: According to the parameter order and the number of parameters, the parameter values of the sub-parameters in the first architecture are converted in sequence according to the second storage format to obtain parameter values of the second target parameters that correspond one-to-one to the parameter values of the first target parameters.

[0102] Sub-steps 20421 to 20422 describe in detail the execution process of the above sub-step 2042, that is, how to convert the parameter value of the first target parameter into the parameter value of the second target parameter. Specifically, it includes obtaining the specific type of the parameter in the first target parameter through the function signature, and confirming the storage format of various specific types under the second architecture according to the specific type and the variable parameter definition rule file of the second architecture. For example, in the first architecture, an int type (integer) parameter requires 16 data bits for storage, while in the second architecture, an int type parameter requires 32 data bits for storage; after obtaining the second storage format of each type of parameter, according to the number of parameters and parameter order of the sub-parameters of the first target parameter in the function signature, the parameter values of the sub-parameters of the first target parameter are converted in sequence, thereby obtaining the corresponding parameter values of the sub-parameters of the second target parameter. These sub-parameters constitute the whole of the second target parameter, and determining the parameter values of these sub-parameters is, that is, determining the parameter value of the second target parameter.

[0103] For example, in the example of the above sub-step 2041, the sub-parameters obtained through the function signature are 1.int, 2.char, 3.float, 4.double, 5.int...m+n.char, in sub-step 2042. After the sub-parameters are converted based on the target architecture, the parameter type, number of parameters, and parameter order are also 1.int, 2.char, 3.float, 4.double, 5.int...m+n.char. However, the specific values of each parameter type are adjusted according to the storage specifications under the target architecture. For example, the integer value 0 was originally represented by 000...00 (a total of 16 bits), but under the target architecture, the integer value 0 is represented by 000...00 (a total of 32 bits).

[0104] Step 205: Determine a second preset storage location for storing the second target parameter according to the variable parameter definition rule file of the second architecture.

[0105] After completing the conversion of the parameter values, it is necessary to confirm the location where these parameter values are stored; this includes confirming the storage location of various types of sub-parameters according to the variable parameter definition rule file of the second architecture.

[0106] Exemplarily, based on the example of the above sub-step 2041, the target architecture is the second architecture. Under the target architecture, the second target parameter corresponding to the first target parameter also has m+n sub-parameters. According to the variable parameter definition rule file of the target architecture, the sub-parameters of va_list are stored in the second preset storage location specified by the target architecture device, including the gr_top area and the vr_top area in the register. Since the size of the gr_top area is inconsistent with the size of the reg_save_area area in the above-mentioned first preset storage location, and the size of the vr_top area may be inconsistent with the size of the arg_area area in the above-mentioned first preset storage location, only j sub-parameters of the m+n sub-parameters can be stored in the gr_top area, that is, from, k sub-parameters can be stored in the vr_top area, that is, m+n=j+k, and j, k are respectively different from m, n. The quantitative relationship between them needs to be determined by the storage method in the variable parameter definition rule file of the first architecture and the variable parameter definition rule file of the second architecture according to the parameter type of each sub-parameter in the first target parameter; for example, the variable parameter definition rule file of the first architecture stipulates that the first 32 integer parameters are stored in reg_save_area, and the remaining integer parameters are stored in arg_area. Now the first target parameter has a total of 64 integer sub-parameters that need to be stored. In the process of converting to the second target parameter, the number of sub-parameters remains unchanged and is always 64. The variable parameter definition rule file of the second architecture stipulates that the first 8 integers are stored in gr_top and the remaining integer parameters are stored in vr_top. According to the above relationship, m=32, n=64-32=32, then in the second architecture, j=8, k=64-8=56.

[0107] Step 206: Store the parameter value of the second target parameter into the second preset storage location to obtain the second target parameter.

[0108] After determining the second preset storage location for storing the parameter value of the second target parameter, the parameter values of the sub-parameters of the first target parameter can be written into the second preset storage location in sequence according to the parameter order of the sub-parameters of the first target parameter provided in the function signature, thereby obtaining the complete second target parameter; thereafter, the translator will translate and execute the basic block of the heterogeneous function based on the second target parameter.

[0109] Step 207: Copy the parameter value of the second target parameter stored in the second preset storage location to a third preset storage location corresponding to the target function, so that the parameter value of the second target parameter is passed to the target function in the virtual machine.

[0110] After obtaining the second target parameter, the translator copies the data stored in the second preset storage location, that is, the parameter value of the second target parameter, to the third preset storage location storing the parameters of the target function, so as to complete the transfer of the second target parameter from the translator to the target function in the virtual machine; the third preset storage location includes registers and memory stacks. According to the function name of the target function, the virtual machine can divide a designated area from the registers and memory stack for the specified target function to use. Among them, according to the parameter type of the target function, the position of the parameter of the target function in the designated area, that is, the third preset storage location, can be further determined. For example, for basic data types such as int, it is stored in the local variable table of the memory stack frame. For reference data types, its reference is stored in the local variable table of the memory stack frame, and its parameter value is stored in the memory heap; since the target function and the second target parameter are both based on the second architecture, directly copying the data will not cause parsing errors of the target function, thereby ensuring that the target function can be executed normally and return the expected correct results.

[0111] Step 208: Based on the second target parameter, execute the target function to obtain an execution result and return it to the heterogeneous function, completing the call of the heterogeneous function to the target function.

[0112] The target function is executed through the second target parameter, ensuring that the heterogeneous function can call the target function smoothly. For target functions with return values, the target function's execution result, i.e., the target function's return value, is passed to the heterogeneous function to complete the call.

[0113] For example, if the target function is a function whose return value is int 20 (that is, the return value is an integer with a value of 20), then after the JVM executes the target function, 20 will be written to the return value register corresponding to the target function. After the translator reads the value "20" from the return value register corresponding to the target function, it copies the "20" in the return value register to the corresponding variable representing the return value of the heterogeneous function, and the call of the heterogeneous function to the target function is completed.

[0114] It should be noted that not all target functions have return values, that is, not all target functions can return the execution results to the heterogeneous function in the form of data. To this end, a mark can be set for the target function. After the target function is executed, the mark is set to inform the target function to start execution or complete execution, thereby determining that the heterogeneous function completes the call to the target function.

[0115] For example, if the target function is a function with a void return value (i.e., no return value), then after the JVM executes the target function, a global variable of type Boolean will be set. The translator monitors the changes of the global variable by setting a hook function. After detecting that the Boolean value of the global variable is set, it confirms that the heterogeneous function completes the call to the target function.

[0116] like Figure 6 As shown, Figure 6 Based on the basic blocks, the function execution method provided by the embodiment of the present application is described; the method includes:

[0117] Step S1: Enter the basic block.

[0118] Step S2: Determine whether the recorded value of PC is the entry address of the target interface function.

[0119] Step S2 is equivalent to sub-step 20211 above.

[0120] If not, execute step S3: translate the next instruction.

[0121] If so, execute step S8: determine the entry address of the specific target interface function to jump to based on the recorded value of PC.

[0122] Step S8 is equivalent to sub-step 20212 above.

[0123] After step S3, step S4 is executed: determining whether it is the end of the basic block.

[0124] If yes, execute step S5: store the translated code into the code cache.

[0125] If not, return to step S3.

[0126] After step S5, step S6 is executed: executing the basic block.

[0127] Step S7: Determine whether the next basic block has been translated and is in the code cache.

[0128] If yes, go to step S6; if no, go to step S1.

[0129] After step S8, step S9 is executed: obtaining the parameter type according to the name of the target interface function.

[0130] Step S9 is equivalent to the above sub-step 20214.

[0131] Step S10: Determine whether there is a first target parameter (ie, a variable parameter) in the parameter type.

[0132] If yes, execute step S11: obtain the dynamic function signature of the target interface function through the signature acquisition function in the JVM.

[0133] Step S11 is equivalent to the above step 203, and the signature acquisition function includes the resolve_jmethod_id function.

[0134] If not, execute step S13.

[0135] After step S11, step S12 is executed: converting the first target parameter into a second target parameter according to the function signature.

[0136] Step S13 is equivalent to the above steps 204, 205 and 206.

[0137] Step S13: copying the second target parameter to a third preset storage location corresponding to the target function.

[0138] Step S13 is equivalent to step 207 above, wherein the translation state indicates that the parameter register and the variables on the stack are equivalent to the second target parameter stored in the second preset storage location, and the parameter register and stack of the host are equivalent to the third preset storage location.

[0139] Step S14: Jump to the target function address entry for execution

[0140] Step S15: Record the return value of the target function into the variable representing the return value register in the translation state.

[0141] Steps S14 to S15 are equivalent to the above step 208.

[0142] The above steps are located in Figure 4 The calling process of the heterogeneous function shown is between step A2 and step A3.

[0143] In an embodiment of the present invention, in an embodiment of the present invention, the target program runs in a virtual machine based on the second architecture, and in the process of the target program calling the heterogeneous function compiled and generated by the first architecture; when the heterogeneous function needs to call the target function in the virtual machine, and the first target parameter based on the first architecture is used in the heterogeneous function, the first target parameter is converted into a second target parameter matching the second architecture through the translator, and then the execution of the target function is completed based on the second target parameter, and the execution result of the target function will be returned to the heterogeneous function to complete the call of the target function by the heterogeneous function. In the related art, the first target parameter is defined differently under the first architecture and the second architecture, and the specific type and number of parameters of the first target parameter are not determined when defined. Directly using the first target parameter based on the first architecture will cause the actual execution result of the target function to deviate from the expectation, thereby causing an error in the execution process of the heterogeneous function. In an embodiment of the present invention, the heterogeneous function is executed by a translator to ensure that all types of data in the heterogeneous function, including the first target parameter, can be converted by the translator to adapt to the target function based on the second architecture. By obtaining the first target parameter and converting the first target parameter into a second target parameter that matches the first architecture, it is ensured that the target function can be executed normally after receiving the second target parameter and return the correct execution result to the heterogeneous function, thereby ensuring the smooth execution process of the heterogeneous function and further ensuring the smooth operation of the target program. The solution provided by the embodiment of the present invention can realize correct cross-structure calls during function execution.

[0144] Figure 7 is a block diagram of a function execution device provided by an embodiment of the present invention, such as Figure 7 As shown, the device includes:

[0145] The main calling module 301 is configured to start executing the heterogeneous function in the target program through the translator in response to a calling instruction of the heterogeneous function in the target program; the heterogeneous function is compiled and generated by a first architecture, and the first architecture is different from the second architecture for running the target program;

[0146] A translation module 302 is configured to call a target function of the second architecture through a target interface function based on the heterogeneous function, obtain a first target parameter of the heterogeneous function through the target interface function, convert the first target parameter of the heterogeneous function into a second target parameter of the second architecture, and pass the second target parameter to the target function;

[0147] The execution module 303 executes the target function based on the second target parameter to obtain an execution result and returns it to the heterogeneous function, thereby completing the call of the heterogeneous function to the target function.

[0148] Optionally, the heterogeneous function is divided into multiple basic blocks during execution; the apparatus 30 may further include:

[0149] a checking module, configured to confirm, when the basic block meets a preset condition, that a target interface function is running in the basic block, and that the target interface function includes a first target parameter;

[0150] The first target parameter module is used to respectively obtain the first target parameters in the target interface function corresponding to the basic block.

[0151] Optionally, the preset condition is: the recorded value of the program counter of the basic block matches the entry address of the target interface function, and the parameter type of the interface function is a preset parameter type; the first target parameter module may include:

[0152] a target interface function confirmation submodule, configured to confirm that a target interface function is running in the basic block when the record value matches an entry address of the target interface function;

[0153] A target variable submodule, configured to obtain a target variable for storing the target interface function according to the entry address;

[0154] A parameter type submodule, configured to determine the parameter type of the target interface function according to the target attribute of the target variable;

[0155] The first target parameter confirmation submodule is used to confirm that the target interface function includes the first target parameter when the parameter type is a preset parameter type.

[0156] Optionally, the translation module 302 may include:

[0157] A function signature submodule, used to obtain the function signature of the target interface function during the execution of the target interface function; the function signature is used to represent parameter information of the target interface function during the execution process;

[0158] The conversion submodule is used to convert the first target parameter into a second target parameter matching the second architecture based on the function signature of the target interface function.

[0159] Optional, function signature submodule, which can include:

[0160] An identity identification unit, configured to control the translator to read the third target parameter of the target interface function to obtain an identity identification of the target interface function;

[0161] The signature acquisition function unit obtains the execution result of the signature acquisition function in the virtual machine based on the identity identifier of the target interface function to obtain the function signature of the target interface function.

[0162] Optionally, the transformation submodule may include:

[0163] a parameter value extraction unit, configured to extract a parameter value of the first target parameter from a first preset storage location in a memory according to the parameter information in the function signature and the variable parameter definition rule file of the first architecture;

[0164] A parameter value conversion unit is used to determine, in sequence, the parameter value of the second target parameter corresponding to the parameter value of the first target parameter according to the parameter information in the function signature and the correspondence between the variable parameter definition rule file of the first architecture and the variable parameter definition rule file of the second architecture.

[0165] Optionally, the parameter value of the first target parameter includes parameter values of sub-parameters of the first target parameter; and the parameter value extraction unit may include:

[0166] a first extraction sub-unit, configured to determine, based on the function signature, a first storage format, a number of parameters, and a parameter order of sub-parameters in the first target parameter; the first storage format representing a storage specification of the sub-parameters in the variable parameter definition rule file of the first architecture;

[0167] a second extraction subunit, configured to divide a target area from the memory according to the first storage format, the number of parameters, and the order of the parameters, and use the target area as the first preset storage location;

[0168] The third extraction subunit is configured to extract the parameter value corresponding to each of the sub-parameters from the first preset storage location.

[0169] Optionally, the parameter value conversion unit may include:

[0170] a first conversion sub-unit, configured to respectively determine a second storage format of each sub-parameter in the first target parameter; the second storage format represents a storage specification of the sub-parameter in the variable parameter definition rule file of the second architecture;

[0171] A second conversion sub-unit is used to convert the parameter values of the sub-parameters under the first architecture in accordance with the parameter order and the number of parameters in accordance with the second storage format, so as to obtain the parameter values of the second target parameters that correspond one-to-one to the parameter values of the first target parameters.

[0172] In summary, in an embodiment of the present invention, the target program runs in a virtual machine based on the second architecture, and in the process of the target program calling the heterogeneous function compiled and generated by the first architecture; when the heterogeneous function needs to call the target function in the virtual machine, and the first target parameter based on the first architecture is used in the heterogeneous function, the first target parameter is converted into a second target parameter matching the second architecture through the translator, and then the execution of the target function is completed based on the second target parameter, and the execution result of the target function will be returned to the heterogeneous function to complete the call of the target function by the heterogeneous function. In the related art, the first target parameter is defined differently under the first architecture and the second architecture, and the specific type and number of parameters of the first target parameter are not determined when defined. Directly using the first target parameter based on the first architecture will cause the actual execution result of the target function to deviate from the expectation, thereby causing an error in the execution process of the heterogeneous function. In an embodiment of the present invention, the heterogeneous function is executed by a translator to ensure that all types of data in the heterogeneous function, including the first target parameter, can be converted by the translator to adapt to the target function based on the second architecture. By obtaining the first target parameter and converting the first target parameter into a second target parameter that matches the first architecture, it is ensured that the target function can be executed normally after receiving the second target parameter and return the correct execution result to the heterogeneous function, thereby ensuring the smooth execution process of the heterogeneous function and further ensuring the smooth operation of the target program. The solution provided by the embodiment of the present invention can realize correct cross-structure calls during function execution.

[0173] The function execution device in the embodiment of the present invention can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, the mobile electronic device can be a mobile phone, a tablet computer, a laptop computer, a PDA, an in-vehicle electronic device, a wearable device, an ultra-mobile personal computer (UMPC), a netbook, or a personal digital assistant (PDA), etc. The non-mobile electronic device can be a server, a network attached storage (NAS), a personal computer (PC), a television (TV), a teller machine, or a self-service machine, etc., which is not specifically limited in the embodiment of the present invention.

[0174] The function execution device in the embodiment of the present invention may be a device having an operating system. The operating system may be an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present invention.

[0175] The function execution device provided in the embodiment of the present invention can implement each process of the function execution method in the method embodiment, and will not be described again here to avoid repetition.

[0176] Optionally, an embodiment of the present invention also provides an electronic device, including a processor, a memory, and a program or instruction stored in the memory and executable on the processor. When the program or instruction is executed by the processor, the various processes of the above-mentioned function execution method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, they will not be described here.

[0177] It should be noted that the electronic devices in the embodiments of the present invention include the mobile electronic devices and non-mobile electronic devices mentioned above.

[0178] Figure 8 The present invention is a hardware structure diagram of an electronic device.

[0179] The electronic device 1300 includes but is not limited to components such as a radio frequency unit 1301 , a network module 1302 , an audio output unit 1303 , an input unit 1304 , a sensor 1305 , a display unit 1306 , a user input unit 1307 , an interface unit 1308 , a memory 1309 , and a processor 1310 .

[0180] Those skilled in the art will understand that the electronic device 1300 may also include a power source (such as a battery) to power each component, and the power source may be logically connected to the processor 1310 through a power management system, thereby implementing functions such as charging, discharging, and power consumption management through the power management system. Figure 8 The electronic device structure shown in the figure does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently, which will not be repeated here.

[0181] It should be understood that in an embodiment of the present invention, the input unit 1304 may include a graphics processing unit (GPU) 13041 and a microphone 13042, and the graphics processor 13041 processes the image data of a static picture or video obtained by an image capture device (such as a camera) in a video capture mode or an image capture mode. The display unit 1306 may include a display panel 13061, and the display panel 13061 may be configured in the form of a liquid crystal display, an organic light emitting diode, etc. The user input unit 1307 includes a touch panel 13071 and at least one of the other input devices 13072. The touch panel 13071 is also called a touch screen. The touch panel 13071 may include two parts: a touch detection device and a touch controller. Other input devices 13072 may include, but are not limited to, a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which will not be repeated here.

[0182] The memory 1309 can be used to store software programs and various data. The memory 1309 may mainly include a first storage area for storing programs or instructions and a second storage area for storing data, wherein the first storage area may store an operating system, applications or instructions required for at least one function (such as a sound playback function, an image playback function, etc.). In addition, the memory 1309 may include a volatile memory or a non-volatile memory, or the memory 1309 may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM bus random access memory (DRRAM). The memory 1309 in the embodiment of the present invention includes, but is not limited to, these and any other suitable types of memory.

[0183] Processor 1310 may include one or more processing units. Optionally, processor 1310 integrates an application processor and a modem processor. The application processor primarily handles operations related to the operating system, user interface, and application programs, while the modem processor primarily processes wireless communication signals, such as a baseband processor. It is understood that the modem processor may not be integrated into processor 1310.

[0184] An embodiment of the present invention also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the various processes of the above-mentioned function execution method embodiment are implemented and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0185] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the present invention and the claims, all of which are protected by the present invention.

Claims

1. A function execution method, characterized in that: The method comprises: In response to a call instruction to a heterogeneous function in a target program, executing the heterogeneous function through a translator; the heterogeneous function is compiled and generated by a first architecture, the first architecture being different from a second architecture on which the target program is executed; Calling a target function of the second architecture through a target interface function based on the heterogeneous function, converting the obtained first target parameter of the heterogeneous function into a second target parameter of the second architecture, and passing the second target parameter to the target function; The target function is controlled to be executed based on the second target parameter, and an execution result is obtained and returned to the heterogeneous function, thereby completing the call of the heterogeneous function to the target function.

2. The method according to claim 1, characterized in that The heterogeneous function is divided into a plurality of basic blocks during execution; then, the method further comprises: In a case where the basic block meets a preset condition, confirming that the target interface function is running in the basic block, and the target interface function includes a first target parameter; The first target parameters in the target interface functions corresponding to the basic blocks are respectively obtained.

3. The method according to claim 2, characterized in that The preset condition is: the recorded value of the program counter of the basic block matches the entry address of the target interface function, and the parameter type of the interface function is a preset parameter type; Then, respectively obtaining the first target parameter in the target interface function corresponding to the basic block includes: In a case where the record value matches the entry address, confirming that the target interface function is running in the basic block; Acquire a target variable for storing the target interface function according to the entry address; Determining the parameter type of the target interface function according to the target attribute of the target variable; In a case where the parameter type is a preset parameter type, the first target parameter is confirmed.

4. The method according to claim 1, wherein The converting the first target parameter into a second target parameter corresponding to the second architecture includes: During the execution of the target interface function, obtaining a function signature of the target interface function; the function signature is used to represent parameter information of the target interface function during the execution process; Based on the function signature, the first target parameter is converted into a second target parameter that matches the second architecture.

5. The method according to claim 4, characterized in that The obtaining of the function signature of the target interface function comprises: Controlling the translator to read the third target parameter of the target interface function to obtain the identity of the target interface function; Based on the identity identifier of the target interface function, the execution result of the signature acquisition function in the virtual machine is obtained to obtain the function signature.

6. The method according to claim 4, characterized in that The parameter information in the function signature includes the number of parameters and the order of parameters; and converting the first target parameter into a second target parameter matching the second architecture includes: Extracting a parameter value of the first target parameter from a first preset storage location in a memory according to the parameter information in the function signature and the variable parameter definition rule file of the first architecture; According to the parameter information in the function signature and the correspondence between the variable parameter definition rule file of the first architecture and the variable parameter definition rule file of the second architecture, the parameter value of the second target parameter corresponding to the parameter value of the first target parameter is determined in sequence.

7. The method according to claim 6, characterized in that The parameter value of the first target parameter includes the parameter values of the sub-parameters of the first target parameter; The extracting the parameter value of the first target parameter from the first preset storage location in the memory includes: Determining, according to the function signature, a first storage format, a number of parameters, and a parameter order of sub-parameters in the first target parameter; Allocating the first preset storage location from the memory according to the first storage format, the number of parameters, and the order of the parameters; The parameter value corresponding to each of the sub-parameters is extracted from the first preset storage location.

8. The method according to claim 6 or 7, characterized in that The sequentially determining the parameter values of the second target parameters corresponding to the parameter values of the first target parameters includes: Determining a second storage format for each sub-parameter in the first target parameter; the second storage format represents a storage specification for the sub-parameter in the variable parameter definition rule file of the second architecture; According to the parameter order and the number of parameters, the parameter values of the sub-parameters under the first architecture are converted in sequence according to the second storage format to obtain parameter values of the second target parameters that correspond one-to-one to the parameter values of the first target parameters.

9. A function execution device, characterized in that: The device comprises: A main calling module: in response to a call instruction to a heterogeneous function in a target program, starting to execute the heterogeneous function through a translator; the heterogeneous function is compiled and generated by a first architecture, the first architecture being different from a second architecture running the target program; A translation module is configured to call a target function of the second architecture through a target interface function based on the heterogeneous function, obtain a first target parameter of the heterogeneous function through the target interface function, convert the first target parameter of the heterogeneous function into a second target parameter of the second architecture, and pass the second target parameter to the target function; Execution module: used to execute the target function based on the second target parameter to obtain the execution result and return it to the heterogeneous function, thereby completing the call of the heterogeneous function to the target function.

10. An electronic device, characterized in that: The method comprises a processor, a memory and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements the steps of the function execution method as claimed in any one of claims 1 to 8.

11. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by a processor, the steps of the function execution method according to any one of claims 1 to 8 are implemented.

Images