Function calling method, device and equipment and readable storage medium

Abstract

The embodiment of the invention provides a function calling method and device, electronic equipment and a computer storage medium, and belongs to the technical field of computers. The method comprises the steps that in the process of loading a target program operated by a first thread, if it is detected that a function library corresponding to the target program comprises a heterogeneous function compiled and generated by a first architecture, a translator is started; the first architecture is different from a second architecture for operating the target program; executing the heterogeneous function through a heterogeneous function processing program in the translator to obtain an execution result of the heterogeneous function; the heterogeneous function processing program is compiled and generated by the first architecture; and returning an execution result to the target program to complete calling of the heterogeneous function. Through the method provided by the embodiment of the invention, the heterogeneous function can be called, and the performance loss caused by directly operating the translator on the second architecture is avoided.

Description

Technical Field

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

[0002] With the development of computer technology, different CPU (Central Processing Unit) architectures have emerged. Therefore, programs need to consider the compatibility of function calls on different CPU architectures. Due to the different instruction sets of different CPU architectures, the structure of the binary files generated by compiling the same function source code may be different, resulting in heterogeneous functions. Heterogeneous functions cannot be directly run on incompatible CPU architectures.

[0003] In the related art, a dynamic translator is used to convert program code from the format corresponding to the original CPU architecture (guest) to the format corresponding to the target CPU architecture (host). However, the dynamic translator runs directly on the host machine, and all instruction data will be converted one by one by the dynamic translator and then passed to the CPU for execution. This will cause high time overhead and large performance loss, thereby reducing the efficiency of program operation. Summary of the Invention

[0004] The present invention aims to provide a function calling 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 calling method, the method comprising:

[0007] During the process of loading a target program executed by a first thread, if it is detected that a function library corresponding to the target program includes a heterogeneous function compiled and generated by a first architecture, then starting a translator; the first architecture is different from a second architecture on which the target program is executed;

[0008] Executing the heterogeneous function through a heterogeneous function processing program in the translator to obtain an execution result of the heterogeneous function; the heterogeneous function processing program is compiled and generated by the first architecture;

[0009] The execution result is returned to the target program to complete the call to the heterogeneous function.

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

[0011] a startup module configured to, during a process of loading a target program executed by a first thread, start a translator if it is detected that a function library corresponding to the target program includes a heterogeneous function compiled and generated by a first architecture; the first architecture being different from a second architecture on which the target program is executed;

[0012] A calling execution module is configured to execute the heterogeneous function through a heterogeneous function processing program in the translator to obtain an execution result of the heterogeneous function; the heterogeneous function processing program is compiled and generated by the first architecture;

[0013] The call return module is used to return the execution result to the target program to complete the call to the heterogeneous 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 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 method described in the first aspect are implemented.

[0016] In an embodiment of the present invention, a target program runs on a platform of a second architecture, and a heterogeneous function compiled into a file of a first architecture exists in the target program; in the process of loading the target program, if a heterogeneous function is detected, a translator is started to enable the translator to immediately respond to translation requests that may exist in the function call process of the target program; when the target program calls the heterogeneous function, the heterogeneous function is executed by a heterogeneous function handler in the translator. Since the heterogeneous function handler is pre-compiled into a first architecture consistent with the heterogeneous function, after the heterogeneous function handler runs, it is equivalent to constructing an operating environment of the first architecture in the translator, so that the heterogeneous function can be normally executed in the operating environment constructed by the heterogeneous function handler to obtain normal operating results; finally, the execution result is returned to the target program to complete the target program's call to the heterogeneous function.

[0017] Through the solution provided by the embodiment of the present invention, on the one hand, the translator constructs the operating environment of the heterogeneous function and executes the heterogeneous function, thereby achieving the effect of translating the heterogeneous function and improving the compatibility of the target program for function calls on different CPU architectures. On the other hand, by responding to the call instruction issued by the target program and then executing the heterogeneous function, the translator only processes the heterogeneous function that needs to be translated, avoiding the use of the translator to process the entire target program, narrowing the target range that the translator needs to process, thereby reducing performance loss and improving the efficiency of the target program operation. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0019] Figure 2 It is a schematic diagram of an operating architecture in related technologies;

[0020] Figure 3 It is another operating architecture diagram in the related art;

[0021] Figure 4 is a flowchart of another function calling method provided by an embodiment of the present invention;

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

[0023] Figure 6 This is a schematic diagram of a function call process provided by an embodiment of the present invention;

[0024] Figure 7 is a schematic diagram of another function call process provided by an embodiment of the present invention;

[0025] Figure 8a-8d 1 is a schematic diagram of four consecutive stages of another function call process provided by an embodiment of the present invention;

[0026] Figure 9 is a block diagram of a function calling device provided by an embodiment of the present invention;

[0027] Figure 10 The figure is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0028] 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.

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

[0030] Step 101: During the process of loading a target program to be run by a first thread, if it is detected that a function library corresponding to the target program includes heterogeneous functions compiled and generated by a first architecture, a translator is started; the first architecture is different from a second architecture running the target program.

[0031] 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.

[0032] During the execution of the target program, various functions are called to perform different tasks in order to achieve code reuse. 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 implemented in non-Java languages are called native functions.

[0033] After the target program is executed on a platform with a first architecture, native functions are compiled into binary files to improve execution efficiency. When the target program is ported to a platform with a second architecture, the compatibility of these binary files needs to be considered: native functions are compiled into binary files to store data. The binary encoding format in the binary files depends on the CPU architecture of the target program when the native functions are compiled. If the target program is ported to a platform device with a different architecture for execution, these native functions that have not been rewritten and compiled are called heterogeneous functions.

[0034] For example, a target program (Java program) is executed in a platform device of an x86 architecture (a first architecture), and the native functions therein are compiled for the x86 architecture. Now the target program needs to be ported to a platform device of a target architecture (a second architecture). Due to the existence of the JVM, the part of the target program written in Java code can be directly ported, but the native functions have been compiled into binary files in the binary encoding form corresponding to the x86 architecture. It can be understood that the binary encoding form corresponding to the x86 architecture is different from the binary encoding form corresponding to the target architecture. At this time, these native functions are called heterogeneous functions (i.e., functions compiled in the first architecture but need to be executed in the second architecture). The platform device of the target architecture cannot directly run these binary files (i.e., these heterogeneous functions cannot be called).

[0035] 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.

[0036] A dynamic translator can complete the above conversion while the program code is running. It is a commonly used translator. Common dynamic translators include QEMU, Box64, LLVM, LATX, etc. Figure 2 This is a schematic diagram of the operating architecture of a client program (i.e., target program) using a dynamic translator in related technologies. In related technologies, the dynamic translator directly translates and runs the client's binary code (client program) on the host architecture. This is equivalent to installing a virtual machine system that matches the client program on the host architecture, providing a matching operating environment for the client program and enabling normal execution of the client program within the virtual machine system. However, since the client program runs within the virtual machine system, all instructions generated by the client program will be converted by the translator before being sent to the CPU for processing. When only part of the running client program is binary code for the client architecture and the rest is binary code for the host architecture, unnecessary overhead will be incurred, affecting the client program's operating efficiency.

[0037] Figure 3 This is another schematic diagram of the operating architecture of a client program using a dynamic translator in the related art. Figure 3 Taking a Java program that needs to call an x86 C language library and runs on a target architecture as an example, the relationship between the client program and the dynamic translator in related technologies is described. Specifically, the JVM runs on the dynamic translator, and the Java program (client program) needs to be compiled into bytecode, which is then converted by the JVM into binary code (machine code) recognizable by the CPU. The execution of each JVM instruction is intercepted and processed by the dynamic translator. This processing involves steps such as instruction decoding, mapping, and optimization, thereby introducing high operating overhead and reducing the operating efficiency of the client program. In addition, running the JVM on the dynamic translator not only makes the overall architecture more cumbersome, increasing the difficulty of system debugging for development and maintenance, but also increases the JVM startup time and execution delay, which may lead to unpredictable performance fluctuations when processing some time-sensitive tasks. Figure 3The JNI in this section refers to the Java Native Interface (JNI), which is used to implement the interaction between the JVM and native functions.

[0038] In order to at least solve the various problems caused by running the client program on a dynamic translator as mentioned above, an embodiment of the present invention provides a method for function calling. First, in the process of loading the target program run by the first thread, the function library corresponding to the target program is detected. If the function library includes heterogeneous functions, the translator is started. Loading the target program here refers to loading the function library of the target program, including loading the dynamic link library files corresponding to the native functions in the Java program during the process of starting the Java program (target program). (These library files are generated after the native functions are compiled. For different operating systems, the naming and location of these library files are different, and the commands for loading these library files are also different. For example, in the Windows system, the naming suffix of the library file is ".dll", while in the Linux system, the naming prefix of the library file is "lib" and the suffix is ".so". In macOS, the naming prefix of the library file is "lib" and the suffix is "dylib"). When the presence of a heterogeneous function is detected, the translator is started. The translator will exist until the end of the life cycle of the target program. In this way, the translator can handle translation requests from the target program at any time.

[0039] The translator (in the embodiment of the present application, the translator is a dynamic translator) translates the target program to enable the target program to run normally on the second architecture. The translator is not started until the heterogeneous function is detected, so as to minimize the performance overhead required by the translator. After the translator is started, it remains in a running state, ensuring that the translator can promptly process the heterogeneous functions that need to be translated, thereby ensuring that the heterogeneous functions can be normally called by the target program. After the translator is started, it will continue to run until the target program ends. At the end of the target program, since the target program is in Java format, the JVM instance corresponding to the target program is recycled by the JVM.

[0040] Step 102: Execute the heterogeneous function through the heterogeneous function processing program in the translator to obtain the execution result of the heterogeneous function; the heterogeneous function processing program is compiled and generated by the first architecture.

[0041] During the operation of the target program, various functions will be called, and the heterogeneous functions among them will be identified through step 101. When the target program needs to call these heterogeneous functions, the corresponding calling instructions of the target program will include translation requests so that the translator can process these heterogeneous functions; the translator executes the heterogeneous functions through the heterogeneous function handler, which is a program that is pre-compiled into a binary file based on the first architecture; when the heterogeneous function handler runs in the virtual machine system built by the translator, an operating environment based on the first architecture can be built for the heterogeneous function so that the heterogeneous function can run normally; consistent with the translator, the heterogeneous function handler will always exist after running to wait for translation requests of heterogeneous functions from the target program (these translation requests can be issued based on calling instructions, that is, the calling instructions for the heterogeneous function will also issue translation requests for the heterogeneous function). After the JVM instance of the target program is recycled, the heterogeneous function handler will be closed together with the translator. In the called function, only the call instructions of the heterogeneous function that needs to be translated will be received and processed by the translator. The running heterogeneous function handler provides a running environment for the heterogeneous function, so that the heterogeneous function can be executed normally in the translator to obtain the execution results after the normal execution of the heterogeneous function.

[0042] For example, in the target program, there is an Example class. In the library file of the target program, there is a library file named "nativeLib", which implements the native function "Java_Example_nativeMethod()" (C code naming). Then the target program can use the Java code segment "example.nativeMethod()" to call the "Java_Example_nativeMethod() function" (the corresponding function name of the native function in the Java code is nativeMethod(), where example is an instance of the Example class in the target program). In addition, before calling nativeMethod(), the Example class also needs the Java code segment "static{System.loadLibrary("nativeLib");}" to determine that nativeMethod() is a function belonging to the library file "nativeLib".

[0043] By confirming in advance that the existing functions are heterogeneous functions, starting the translator, and processing these heterogeneous functions through the translator and its heterogeneous function handler when the heterogeneous functions are called, the translator can accurately capture and process the heterogeneous binary codes (heterogeneous functions) that need to be translated, thereby minimizing the performance loss caused by the translator.

[0044] Step 103: Return the execution result to the target program to complete the call to the heterogeneous function.

[0045] When the heterogeneous function handler successfully executes the heterogeneous function and obtains the execution result of the heterogeneous function, it will return the execution result to the target program. The target program will use the execution result as the return value of calling the heterogeneous function, complete the call to the heterogeneous function, and continue to execute subsequent tasks.

[0046] It should be noted that for the target program in the first thread, calling the heterogeneous function is a synchronous process by default, that is, after calling the heterogeneous function, the first thread will be blocked because the target program needs to wait for the execution result corresponding to the heterogeneous function, and will not execute subsequent target program code. The first thread can continue to run the target program only after waiting for the heterogeneous function to be executed and returning the execution result to the target program; however, if the heterogeneous function itself performs an operation to achieve an asynchronous effect (such as starting a new thread, using an asynchronous IO mechanism), then the target program's calling process of the heterogeneous function is an asynchronous process. At this time, after the target program calls the heterogeneous function, the first thread will continue to run without blocking subsequent target program code. After the heterogeneous function is executed, the execution result of the heterogeneous function will be returned to the target program for the target program to use, thereby completing the call to the heterogeneous function.

[0047] It should be noted that the JVM running the target program (Java program) can be implemented in C or C++ (i.e., the writing language of the corresponding native function), so that the JVM instance of the target program can directly use the execution results of the heterogeneous function, increasing the efficiency of the target program calling the heterogeneous function.

[0048] In summary, in an embodiment of the present invention, the target program runs on a platform of the second architecture, and there are heterogeneous functions compiled into files of the first architecture in the target program; in the process of loading the target program, if a heterogeneous function is detected, the translator is started to enable the translator to immediately respond to translation requests that may exist in the function call process of the target program; when the target program calls the heterogeneous function, the heterogeneous function is executed by the heterogeneous function handler in the translator. Since the heterogeneous function handler is pre-compiled into the first architecture consistent with the heterogeneous function, after the heterogeneous function handler runs, it is equivalent to building an operating environment of the first architecture in the translator, so that the heterogeneous function can be normally executed in the operating environment constructed by the heterogeneous function handler to obtain normal operating results; finally, the execution result is returned to the target program to complete the target program's call to the heterogeneous function.

[0049] Through the solution provided by the embodiment of the present invention, on the one hand, the translator constructs the operating environment of the heterogeneous function and executes the heterogeneous function, thereby achieving the effect of translating the heterogeneous function and improving the compatibility of the target program for function calls on different CPU architectures. On the other hand, by responding to the call instruction issued by the target program and then executing the heterogeneous function, the translator only processes the heterogeneous function that needs to be translated, avoiding the use of the translator to process the entire target program, narrowing the target range that the translator needs to process, thereby reducing performance loss and improving the efficiency of the target program operation.

[0050] Figure 4 This is a flowchart of another function calling method provided by an embodiment of the present invention. Figure 4 include:

[0051] Step 201, according to the established naming rule file, traverse the function name of each function in the function library, and obtain the naming recognition result corresponding to each function respectively; when the naming recognition result of the function is passed, confirm that the function is the heterogeneous function.

[0052] Since heterogeneous functions are native functions, it is possible to determine whether there are heterogeneous functions by filtering out native functions; native functions are declared by the native keyword. For example, by traversing the code, it can be seen that the code segment {publicnative void nativeMethod();} declares a native function named "nativeMethod()". According to the function name of the native function in the Java Native Interface (JNI), the name of the library file where the native function is located can be determined. Then, according to the name of the library file, the properties of the library file can be queried to determine the architecture corresponding to the library file, thereby determining whether the library file is a binary file compiled and generated under the first architecture (that is, a binary file that is heterogeneous relative to the second architecture). If the library file is a heterogeneous binary file, then the native function in the library file is a heterogeneous function.

[0053] Exemplarily, JNI names native functions using the rule of "Java_package name_class name_method name"; for example, in the Android system (a system built on Java), for a Java function start(), JNI names it "Java_android_media_MediaRecorder_start", and the location of the function is in frameworks / … / java / android / media / MediaRecorder.cpp. By reading the properties of the library file corresponding to MediaRecorder.cpp (i.e., .dll, .so, .dylib file), determining the architecture for compiling the library file, and comparing it with the architecture corresponding to running the Android system (equivalent to the second architecture), it is possible to confirm whether the library file is a heterogeneous file, and then confirm whether the function start() is a heterogeneous function. If the library file is a ".dll" file, then there is a property called "machine" in its PE header (Portable ExecutableHeader), which is used to save the information of the architecture used to compile the library file. By reading this property, you can confirm the architecture of the library file. For example, the property uses the character "0x14C" to represent the x86 architecture. When the "machine" property value of the library file is "0x14C", it can be confirmed that the architecture used to compile the library file is x86. For the Android system, you can obtain the corresponding architecture of the Android system by reading the CPU_ABI property in the Build class of the Android system or the ro.product.cpu.abi property in the SystemProperties class. For example, by reading ro.product.cpu.abi, the corresponding architecture of the Android system is arm64-v8a. Obviously, arm64-v8a and x86 are different structures. Therefore, it can be determined that the start() function in the above example is a heterogeneous function.

[0054] Step 202 , during the process of loading the target program to be run by the first thread, if it is detected that the function library corresponding to the target program includes heterogeneous functions compiled and generated by a first architecture, then starting a translator; the first architecture is different from the second architecture running the target program.

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

[0056] Optionally, in one implementation, the source code of the translator is configured as a shared function file in the function library; the target program is executed by the first thread; and the step of starting the translator in step 202 may specifically include:

[0057] Sub-step 2021: execute the shared function file to establish a second thread for running the translator; the first thread and the second thread are located in the virtual machine process corresponding to the target program.

[0058] The translator can be executed in the form of a library function call: the source code of the translator is packaged and compiled into a shared function file. In this embodiment, the main function of the translator is packaged as a translator_launch function and shared. By calling and executing the translator_launch function, the main function of the translator can be enabled to run the translator; by packaging 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.

[0059] like Figure 5 As shown, Figure 5 A schematic diagram of an architecture provided by an embodiment of the present invention is provided. Figure 5 This diagram represents the architecture after placing the thread running the translator in the JVM. Since the translator is run by calling a library function after the target program is run, the second thread running the translator and the first thread running the target program are both located in the JVM process. When the thread running the translator is configured to run in the JVM, the first thread and the second thread become two threads of the same level in the same process.

[0060] If a target program needs to run in the JVM and also needs to be processed by a translator, then the JVM and the translator need to share the memory address of the target program; however, running a virtual machine involves virtual-to-real conversion of memory addresses. The JVM and the translator are essentially virtual machines. If the JVM and the translator run in two different processes respectively, then for the same memory segment, the virtual-to-real conversion of the memory addresses of the two processes will be different, making it difficult for the target program running in the JVM and the translator to interact directly; by packaging the translator's main function as a translator_launch function for sharing, and calling the translator_launch function through the first thread, a second thread dedicated to running the translator can be established in the JVM, so that the first thread running the target program and the second thread running the virtual machine are both located in the JVM process. By inserting the second thread running the translator into the JVM process in this way, the thread running the target program and the thread running the translator can share the memory address space of the JVM process, that is, the translator can directly access the memory address of the target program, thereby reducing resource consumption in the communication process between the translator and the target program and improving the execution efficiency of the target program.

[0061] Step 203: During the execution of the target program, in response to a call instruction of the target program to the heterogeneous function, a third thread for calling the heterogeneous function is established; the third thread is a child thread of the first thread and corresponds one-to-one to each of the heterogeneous functions.

[0062] During the execution of the target program, each function call instruction will generate a matching sub-thread, which is used to call the heterogeneous function and obtain the return value of the call; when the target program needs to call the heterogeneous function (that is, when issuing a call instruction for the heterogeneous function), a third thread corresponding to the heterogeneous function will be established accordingly; since the target program may call multiple heterogeneous functions, there are also multiple one-to-one corresponding third threads, which need to be created separately when calling.

[0063] Step 204: Construct a communication structure through the third thread so that the translator can return the execution result to the target program.

[0064] In order to realize the communication between the target program and the translator, a communication structure message_t can be constructed through typedefstruct{……}message_t. The data structure of the communication structure mainly includes two parts: variables passed from the target program to the translator and variables passed back to the target program by the translator; among them, the variables passed from the target program to the translator for heterogeneous function calls can include char*dll_path (used to represent the location path of the heterogeneous function), char*symbol (used to represent the signature of the name, parameters and return value of the heterogeneous function), arg_t*args (used to represent the parameters of the heterogeneous function); the variables passed back to the target program by the translator for execution result return can include boolfinished (used to indicate whether the translation execution is completed) and long ret (used to indicate the execution result after the translation execution is completed); the above variables are temporarily stored in the communication structure in the form of key-value pairs, so that the target program or translator can write or read data to or from the communication structure.

[0065] It should be noted that after the communication structure is declared, for each third thread, a communication structure instance matching the third thread needs to be created to realize the communication connection between the target program and the translator; for example, if the target program has three third threads T1, T2, and T3 that call different heterogeneous functions, then corresponding communication structure instances message_t_1, message_t_2, and message_t_3 need to be created for T1, T2, and T3 respectively. It can be understood that T1 communicates with the translator through message_t_1, T2 communicates with the translator through message_t_2, and T3 communicates with the translator through message_t_3.

[0066] For example, a heterogeneous function has two parameters int a and float b. When the heterogeneous function is called, the input actual parameters are 2 and 3.0 respectively. Then, the args variable used to represent the parameters can be written in sequence as "int2, float: 3.0".

[0067] Step 205: Control the third thread to generate a translation request, and write the translation request into the communication structure; the translation request includes the parameters and entry address of the heterogeneous function.

[0068] When the thread that calls the heterogeneous function (the third thread) is established, a translation request will be generated based on the calling instruction. The translation request may include the content required to execute the heterogeneous function, including the parameters (actual parameters) of the heterogeneous function and the entry address of the heterogeneous function (the address of the first instruction of the function in the memory); after sending the translation request, the third thread will start waiting for the execution result returned by the translator.

[0069] Figure 6 is a schematic diagram of a function calling process provided by an embodiment of the present invention, Figure 6 Describes the flow chart of heterogeneous function calls; Figure 6 In the example, the translator only needs to process a third thread. The translator and the target program communicate through the communication structure message_t. The parameters and function address required by the target program to call the heterogeneous function are sent to the translator as parameters of the communication structure through the first thread, and the corresponding execution result in the translator is sent to the target program as a parameter of the communication structure in the form of a return value through the second thread.

[0070] Optionally, in one implementation, there are at least two third threads. After step 205, the following steps may be further included:

[0071] Step 206: In multiple allocation cycles, establish a fourth thread corresponding to the third thread one by one; the fourth thread is used to execute the heterogeneous function processing program and communicate with the third thread through the communication structure.

[0072] Since there may be multiple heterogeneous functions that need to be called, and these heterogeneous functions themselves may have dependencies, and only one thread is used to run the translator and heterogeneous function handler, only one translation request of a heterogeneous function can be translated at a time, so multiple third threads calling heterogeneous functions may cause deadlock.

[0073] Figure 7 FIG. 1 is a schematic diagram of another function calling process according to an embodiment of the present invention. Figure 7The figure shows the process of deadlock. If heterogeneous function 1 depends on the execution result of heterogeneous function 2, the thread calling heterogeneous function 1 first obtains the opportunity to be processed by the second thread running the translator through message_t. The corresponding translation request will be sent to the second thread to execute heterogeneous function 1. However, heterogeneous function 1 needs to wait for the execution result of heterogeneous function 2, so the second thread will wait after the step of "2. Jump to the heterogeneous function entry". If heterogeneous function 2 wants to execute, it needs to rely on its corresponding message_t to pass the translation request. However, at this time, the second thread is processing heterogeneous function 1 and has not exited yet, and cannot execute other heterogeneous functions, thus causing deadlock.

[0074] In order to avoid this problem, the translator is configured in a server-like mode to implement translation. Specifically, whenever the thread running the translator (the second thread) receives a translation request from a thread that calls a heterogeneous function (the third thread, the third thread is a child thread of the first thread, that is, the third thread is triggered by the first thread), a child thread dedicated to the translation request (the fourth thread, the fourth thread is a child thread of the second thread, that is, the fourth thread is triggered by the second thread) is established to handle the translation request, instead of using the second thread running the translator to perform the translation work itself. It can be understood that in this case, the third thread and the fourth thread will be connected for communication through the communication structure dedicated to the third thread.

[0075] In the scheme of establishing the fourth thread, the main task of the thread running the translator (the second thread) will be modified to allocate the fourth thread so that the fourth thread corresponds one-to-one with the third thread; the specific implementation of this scheme will be described in sub-steps 2061-2064 below.

[0076] Optionally, step 206 may specifically include:

[0077] Sub-step 2061: In each allocation cycle, the target third thread is controlled to check the value of the reserved memory address space; the reserved memory address space is used to store the memory address of the communication structure; the target third thread is any third thread that has not yet established a corresponding fourth thread.

[0078] In order to achieve allocation, the translator and the target program can agree on a shared reserved memory address space. This address space is used to represent the memory address of the communication structure currently transmitted between the target program and the thread running the translator (the second thread); at the beginning of each allocation cycle, any third thread is controlled to check the value of the reserved memory address space. The third thread performing the checking operation is called the target third thread.

[0079] Combined with reference Figures 8a to 8d , Figures 8a to 8dThe schematic diagrams are respectively four consecutive stages of another heterogeneous function calling process provided by the embodiments of the present application; wherein message_addr is used to represent the reserved memory address space; the second thread has completed the processing of the translation request issued by the third thread calling the heterogeneous function x, and the third thread calling the heterogeneous function x has obtained the exclusive translation thread x (i.e., the exclusive fourth thread) to process its translation request. The fourth thread calls the third thread of the heterogeneous function x to communicate with the exclusive translation thread x through its own corresponding communication structure message_tx, and the exclusive translation thread x has written the finished field indicating that the translation is completed into message_tx; there are still three concurrent third threads, which call heterogeneous function 1, heterogeneous function 2, and heterogeneous function 3 respectively. The translation requests of these three third threads have not yet been processed. The three third threads each create and write the corresponding communication structures for the translation requests, namely message_t1, message_t2, and message_t3.

[0080] Figure 8a It represents the process stage corresponding to sub-step 2061, wherein the three third threads respectively check the value of the reserved memory address space message_addr to write the memory address of their own communication structure into the reserved memory address space message_addr.

[0081] Sub-step 2062: When the value of the reserved memory address space is empty, write the memory address of the communication structure corresponding to the target third thread into the reserved memory address space.

[0082] Each third thread strives to write the memory address of its own communication structure into the reserved memory space address. When the target third thread detects that the value of the reserved memory space address is null, it will write the memory address of its own communication structure into the reserved memory address space; thus, the target third thread establishes a communication connection with the second thread running the translator.

[0083] In step 205 , the translation request of each third thread is written into the corresponding communication structure, so the second thread can read the translation request corresponding to the target third thread through the communication structure.

[0084] Figure 8b Indicates the process stage corresponding to sub-step 2062, message_addr is a null value (null), the target third thread that calls heterogeneous function 1 writes the memory address of its own message_t1 into message_addr, and blocks other third threads from operating on message_addr.

[0085] Exemplarily, the above-mentioned detection and writing of the reserved memory address space can be executed through the CAS (CompareAnd Swap) instruction of the CPU, which allows the CPU to first compare whether two values are equal, and then update the value of a specific location without interruption; CAS contains three parameters: a specific memory location (V, equivalent to the reserved memory address space), an expected value (A, null in the above process) and a new value (B, the latest value to be updated, equivalent to the memory address of the communication structure corresponding to the target third thread). CAS will read the value in V. If the value is also null, that is, the value is equal to the expected value A, the new value B is used to replace the value in V, otherwise no operation is performed. The replacement of the value in V with the new value B is atomic, that is, it cannot be interrupted, and it is either completely successful or does not occur at all.

[0086] For example, Figure 8a and Figure 8b For example, the initial value of message_addr is null, and the CAS instruction input parameters include message_addr, null, and message_t1 in sequence. CAS first reads the value of the first parameter, message_addr, which is the initial value null. This matches the second parameter of CAS, null, and then writes the value of the third parameter, message_t1, to message_addr. This completes the initial detection and writing of the reserved memory address space by the structure message_t1. When the value in message_addr is changed to the value of message_t1, the input parameters of CAS become message_addr, null, message_t2 or message_addr, null, message_t3. CAS first reads the value of the first parameter, message_addr, as message_t1. This differs from the second parameter, null, so CAS does not process the third parameter (message_t2 or message_t3). This means the CAS instruction aborts execution, temporarily preventing the second thread from allocating a fourth thread to the third thread. In the above example, even if heterogeneous functions 1 and 2 have a dependency, this does not block the second thread from executing the translation.

[0087] Sub-step 2063: establishing a fourth thread corresponding to the target third thread according to the memory address in the reserved memory address space, and establishing a communication connection between the target third thread and the fourth thread through the communication structure corresponding to the target third thread.

[0088] After receiving the translation request from the target third thread's translator, the translator can then establish a fourth thread dedicated to the target third thread, thereby concurrently processing translation requests from the target program. Other third threads are temporarily blocked in sub-steps 2062 and 2063 until reaching sub-step 2064.

[0089] Sub-step 2064: After the fourth thread is established, the reserved memory address space is cleared to start the next allocation cycle.

[0090] After the fourth thread corresponding to the current target third thread is established, the reserved memory address space is set to null, so that the next target third thread can perform detection and write operations on the reserved memory address space.

[0091] Figure 8c and Figure 8d Indicates the process stage corresponding to sub-step 2063 and sub-step 2064. After obtaining the memory address of message_t1, the translator creates a fourth thread (exclusive translation thread 1) corresponding to the third thread that calls heterogeneous function 1 according to message_t1, and uses message_t1 to realize the communication between the third thread that calls heterogeneous function 1 and the exclusive translation thread 1; at the same time, message_addr is set to a null value (null) to allow the remaining third thread that calls heterogeneous function 2 and the third thread that calls heterogeneous function 3 to continue to compete for the qualification of being allocated the fourth thread.

[0092] For example, after the second thread allocates an exclusive fourth thread (i.e., exclusive translation thread 1) to the third thread that calls heterogeneous function 1, the second thread will first set the value of message_addr to null, and then execute the CAS instruction. The input parameters of the CAS instruction include message_addr, null, and message_t2 in sequence (assuming that the third thread that calls heterogeneous function 2 is the new target third thread); CAS will first read the value of the first parameter message_addr as the initial value null, which is consistent with the second parameter null of CAS, and then write the value of the third parameter message_t2 into message_addr; at this point, the second detection and writing of the reserved memory address space is completed. When the value in message_addr is modified to the value of message_t2, the input parameters of CAS become message_addr, null, and message_t3; CAS first reads the value of the first parameter message_addr, which is the value of message_t2, which is different from the second parameter null of CAS. At this time, CAS will not process the third parameter, that is, the CAS instruction terminates execution, thereby temporarily preventing the second thread from allocating the fourth thread to the third thread that calls heterogeneous function 3.

[0093] In the above process, each thread that calls a heterogeneous function (the third thread) will be mapped to a dedicated translator sub-thread (the fourth thread) for execution. The third thread and the fourth thread communicate through the agreed communication structure, and the third thread no longer directly contacts the thread running the translator (the second thread). In this way, even if these heterogeneous functions have dependencies, it will not affect the second thread running the translator, thereby realizing the concurrent processing of the translator's translation requests for heterogeneous functions and avoiding the deadlock problem of multiple threads calling heterogeneous functions.

[0094] Step 207: Control the translator to parse the translation request from the communication structure, and control the heterogeneous function processing program to store the parameters into a predetermined parameter register, and then execute the heterogeneous function according to the entry address.

[0095] The translator first reads the translation request in the communication structure, which is stored in the variable passed to the translator by the target program in step 204; if there is no concurrency in the third thread, the second thread running the translator will perform the read operation (at this time, refer to Figure 6 , the second thread mainly runs the heterogeneous function processing program), for the case of multiple third threads concurrently, the fourth thread corresponding to each of the third threads performs the read operation (at this time, refer to Figures 8a to 8d, the second thread mainly runs a heterogeneous function allocation handler that allocates a fourth thread to the third thread, and the heterogeneous function handler is a subroutine of the heterogeneous function allocation handler).

[0096] After reading the translation request, the second thread or the fourth thread first stores the actual parameters in the predetermined parameter registers and the thread stack in a preset order so that the heterogeneous function can be used at any time during execution. Subsequently, the heterogeneous function handler will jump to the entry address of the heterogeneous function according to the translation request to execute the heterogeneous function.

[0097] Step 208: Return the execution result to the target program to complete the call to the heterogeneous function.

[0098] Optionally, in one implementation, step 208 may specifically include:

[0099] Sub-step 2081: controlling the third thread to read the execution result written by the translator from the communication structure;

[0100] Sub-step 2082: Use the running result as the return value of the target program calling the heterogeneous function to complete the call to the heterogeneous function.

[0101] After the heterogeneous function handler is executed, the execution result will be stored in the return value register. The translator thread will write the execution result into the communication structure through the return value register, and the translator will pass it back to the variable of the target program, and set the variable (finished) indicating the translation execution status to "finished"; after detecting that the variable indicating the translation execution status indicates completion, the third thread will read the execution result from the communication structure and return the execution result as the return value of calling the heterogeneous function to the thread running the target program, thereby completing the target program's call to the heterogeneous function.

[0102] Taking the variable in step 204 as an example, if the heterogeneous function has only one execution result r, and the execution result is the value 10.40, the translator will write "r: 10.40" into the ret variable in the communication structure, and at the same time, set the finished variable to 1. After the third thread detects that the finished variable is set to 1, it will read the ret variable from the communication structure, extract 10.40 as the call result and hand it over to the first thread running the target program, thereby completing the target program's call to the heterogeneous function.

[0103] In an embodiment of the present invention, a target program runs on a platform of a second architecture, and a heterogeneous function compiled into a file of a first architecture exists in the target program; in the process of loading the target program, if a heterogeneous function is detected, a translator is started to enable the translator to immediately respond to translation requests that may exist in the function call process of the target program; when the target program calls the heterogeneous function, the heterogeneous function is executed by a heterogeneous function handler in the translator. Since the heterogeneous function handler is pre-compiled into a first architecture consistent with the heterogeneous function, after the heterogeneous function handler runs, it is equivalent to constructing an operating environment of the first architecture in the translator, so that the heterogeneous function can be normally executed in the operating environment constructed by the heterogeneous function handler to obtain normal operating results; finally, the execution result is returned to the target program to complete the target program's call to the heterogeneous function.

[0104] Through the solution provided by the embodiment of the present invention, on the one hand, the translator constructs the operating environment of the heterogeneous function and executes the heterogeneous function, thereby achieving the effect of translating the heterogeneous function and improving the compatibility of the target program for function calls on different CPU architectures. On the other hand, by responding to the call instruction issued by the target program and then executing the heterogeneous function, the translator only processes the heterogeneous function that needs to be translated, avoiding the use of the translator to process the entire target program, narrowing the target range that the translator needs to process, thereby reducing performance loss and improving the efficiency of the target program operation.

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

[0106] The startup module 301 is configured to start a translator during a process of loading a target program to be run by a first thread if it is detected that a function library corresponding to the target program includes a heterogeneous function compiled and generated by a first architecture, wherein the first architecture is different from a second architecture on which the target program is run.

[0107] The calling execution module 302 is configured to execute the heterogeneous function through a heterogeneous function processing program in the translator to obtain an execution result of the heterogeneous function; the heterogeneous function processing program is compiled and generated by the first architecture;

[0108] The call return module 303 is used to return the execution result to the target program to complete the call to the heterogeneous function.

[0109] Optionally, the source code of the translator is configured as a shared function file in the function library, and the startup module 301 may include:

[0110] A same-process module: configured to execute the shared function file to establish a second thread for running the translator; the first thread and the second thread are located in a virtual machine process corresponding to the target program;

[0111] Optionally, the device 30 may further include:

[0112] a third thread module configured to establish, during the execution of the target program, a third thread for calling the heterogeneous function in response to a call instruction from the target program to the heterogeneous function; the third thread being a child thread of the first thread and corresponding one-to-one to each heterogeneous function;

[0113] Communication structure module: used for constructing a communication structure through the third thread; so that the translator can return the execution result to the target program.

[0114] Optionally, calling the execution module 302 may further include:

[0115] The first translation request submodule is used to control the third thread to generate a translation request and write the translation request into the communication structure; the translation request includes the parameters and entry address of the heterogeneous function;

[0116] The second submodule of the translation request is used to control the translator to parse the translation request from the communication structure, and control the heterogeneous function processing program to store the parameters into the predetermined parameter register, and then execute the heterogeneous function according to the entry address.

[0117] Optionally, calling the return module 303 may include:

[0118] The first return processing submodule is used to control the third thread to read the execution result written by the translator from the communication structure.

[0119] The second return processing submodule is used to use the running result as the return value of the target program calling the heterogeneous function to complete the call to the heterogeneous function.

[0120] Optionally, there are at least two third threads, and the apparatus 30 may further include:

[0121] The fourth thread module is used to establish a fourth thread corresponding to the third thread in multiple allocation cycles; the fourth thread is used to execute the heterogeneous function processing program and communicate with the third thread through the communication structure.

[0122] Optionally, the fourth thread module may include:

[0123] A detection and writing unit is configured to write the memory address of the communication structure corresponding to the target third thread into the reserved memory address space when the value of the reserved memory address space is empty; the reserved memory address space is used to store the memory address of the communication structure;

[0124] A dedicated thread establishment unit is configured to establish a fourth thread corresponding to the target third thread according to the reserved memory address space, and to establish a communication connection between the target third thread and the fourth thread through the communication structure.

[0125] Optionally, the device 30 further includes:

[0126] Function name recognition module: according to the established naming rule file, traverse the function name of each function in the function library and obtain the corresponding naming recognition result of each function;

[0127] Heterogeneous function confirmation module: used to confirm that the function is the heterogeneous function when the naming recognition result is passed.

[0128] In summary, in an embodiment of the present invention, the target program runs on a platform of the second architecture, and there are heterogeneous functions compiled into files of the first architecture in the target program; in the process of loading the target program, if a heterogeneous function is detected, the translator is started to enable the translator to immediately respond to translation requests that may exist in the function call process of the target program; when the target program calls the heterogeneous function, the heterogeneous function is executed by the heterogeneous function handler in the translator. Since the heterogeneous function handler is pre-compiled into the first architecture consistent with the heterogeneous function, after the heterogeneous function handler runs, it is equivalent to building an operating environment of the first architecture in the translator, so that the heterogeneous function can be normally executed in the operating environment constructed by the heterogeneous function handler to obtain normal operating results; finally, the execution result is returned to the target program to complete the target program's call to the heterogeneous function.

[0129] Through the solution provided by the embodiment of the present invention, on the one hand, the translator constructs the operating environment of the heterogeneous function and executes the heterogeneous function, thereby achieving the effect of translating the heterogeneous function and improving the compatibility of the target program for function calls on different CPU architectures. On the other hand, by responding to the call instruction issued by the target program and then executing the heterogeneous function, the translator only processes the heterogeneous function that needs to be translated, avoiding the use of the translator to process the entire target program, narrowing the target range that the translator needs to process, thereby reducing performance loss and improving the efficiency of the target program operation.

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

[0131] The function calling 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.

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

[0133] 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 call method embodiment are implemented and the same technical effect can be achieved. To avoid repetition, they will not be described here.

[0134] 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.

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

[0136] 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 .

[0137] 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 10 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.

[0138] 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.

[0139] Memory 1309 can be used to store software programs and various data. Memory 1309 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. 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.). Furthermore, memory 1309 may include volatile memory or non-volatile memory, or it may include both volatile and non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM) or static random access memory (SRAM). Memory 1309 in embodiments of the present invention includes, but is not limited to, these and any other suitable types of memory.

[0140] 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.

[0141] 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 call method embodiment are implemented and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0142] 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 calling method, characterized in that: The method comprises: During the process of loading a target program executed by a first thread, if it is detected that a function library corresponding to the target program includes a heterogeneous function compiled and generated by a first architecture, then starting a translator; the first architecture is different from a second architecture on which the target program is executed; Executing the heterogeneous function through a heterogeneous function processing program in the translator to obtain an execution result of the heterogeneous function; the heterogeneous function processing program is compiled and generated by the first architecture; The execution result is returned to the target program to complete the call to the heterogeneous function.

2. The method according to claim 1, characterized in that The source code of the translator is configured as a shared function file in the function library; then, starting the translator includes: The shared function file is executed to establish a second thread for running the translator; the first thread and the second thread are located in a virtual machine process corresponding to the target program.

3. The method according to claim 1, characterized in that The method further comprises: During the execution of the target program, in response to a call instruction of the target program to the heterogeneous function, a third thread for calling the heterogeneous function is established; the third thread is a child thread of the first thread and has a one-to-one correspondence with each of the heterogeneous functions; A communication structure is constructed through the third thread so that the translator can return the execution result to the target program.

4. The method according to claim 3, characterized in that The executing the heterogeneous function by the heterogeneous function processing program in the translator includes: Controlling the third thread to generate a translation request and writing the translation request into the communication structure; the translation request includes parameters and an entry address of the heterogeneous function; The translator is controlled to parse the translation request from the communication structure, and the heterogeneous function processing program is controlled to store the parameters into a predetermined parameter register, and then the heterogeneous function is executed according to the entry address.

5. The method according to claim 3, characterized in that The step of returning the execution result to the target program includes: controlling the third thread to read the execution result written by the translator from the communication structure; The running result is used as the return value of the heterogeneous function to complete the call to the heterogeneous function.

6. The method according to claim 3, characterized in that There are at least two third threads; the method further includes: In a plurality of allocation cycles, a fourth thread corresponding one-to-one to the third thread is respectively established; the fourth thread is used to execute the heterogeneous function processing program and to establish a communication connection with the third thread through the communication structure.

7. The method according to claim 6, characterized in that The establishing of fourth threads corresponding to the third threads one by one respectively includes: When the value of the reserved memory address space is empty, writing the memory address of the communication structure corresponding to the target third thread into the reserved memory address space; the reserved memory address space is used to store the memory address of the communication structure; A fourth thread corresponding to the target third thread is established according to the reserved memory address space, and a communication connection between the target third thread and the fourth thread is established through the communication structure.

8. The method according to claim 1, characterized in that The method further comprises: According to the established naming rule file, the function name of each function in the function library is traversed to obtain the corresponding naming recognition result of each function; If the name recognition result is passed, the function is confirmed to be the heterogeneous function.

9. A function calling device, characterized in that: The device comprises: a startup module configured to, during a process of loading a target program executed by a first thread, start a translator if it is detected that a function library corresponding to the target program includes a heterogeneous function compiled and generated by a first architecture; the first architecture being different from a second architecture on which the target program is executed; A calling execution module is configured to execute the heterogeneous function through a heterogeneous function processing program in the translator to obtain an execution result of the heterogeneous function; the heterogeneous function processing program is compiled and generated by the first architecture; Call return module: used to return the execution result to the target program to complete the call to the heterogeneous 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 calling method according to 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 calling method according to any one of claims 1 to 8 are implemented.

Images