System and method for performing binary translation

Abstract

Systems and methods for performing binary translation include a system capable of translating binary files written for use in a source execution environment into binary files compatible with a target execution environment. According to some embodiments, the binary translation system includes a system service and a runtime code module that exists in the application memory address space. The binary translation system translates object-level binary files corresponding to executable programs, linkers, libraries, etc., and stores the translation in a translation cache that is cryptographically protected to ensure that only systems with a particular key can access the translation. If the application or application binary file has been modified since the translation was performed, the system service will ensure that the translation is removed from the cache, a new translation is performed, and all threads that access the translation are updated to the new translation.

Description

Background Technology Technical Field

[0001] The implementation scheme described herein relates to binary translation. Specifically, the implementation scheme described herein involves caching translated binary files in a translation cache for rapid retrieval by system services that manage cached translations.

[0002] Related technical descriptions

[0003] The standard way developers enable applications written for a first execution environment to run in a second execution environment is to port the application to the second execution environment. This involves rebuilding and recompiling the application for the second execution environment. Porting can be time-consuming and labor-intensive for large applications and may involve good working knowledge of the second execution environment and calibration tools for recompiling for that environment. To bridge the gap as the application is rebuilt and recompiled, developers often use emulators (e.g., interpreters and / or translators) to run code in different execution environments. An interpreter typically iteratively reads application instructions in a first or source execution environment and executes the operations in the source execution environment that run in the software environment within the second or target execution environment. Other emulators operate in a similar manner but will leverage portions of the underlying hardware of the second environment to optimize the interpretation. For example, an emulator may use the underlying memory as well as the underlying processor and system, allowing the application to behave as if it were running natively in the second environment, where the application runs at a speed determined by the capabilities of the underlying hardware and the performance of the interpreter. A binary translator translates the various instructions and code of the application from the first execution environment to the second execution environment.

[0004] Binary translators can typically be static or dynamic. A static binary translator attempts to translate all application code from a first execution environment to a second execution environment without actually executing the code beforehand. A dynamic binary translator translates discrete blocks of code during execution and caches the translated blocks for use during the execution of the application containing that code. The Rosetta dynamic translation layer, used to translate PowerPC applications to x86, is an example of a dynamic binary translator. While a dynamic binary translator may be more accurate because it takes into account all the code that needs to be translated, it typically incurs significant hardware overhead during application execution due to the dynamic translation, which can cause the application to execute slowly with a noticeable lag. Furthermore, if the application being translated includes just-in-time (JIT) compilation that requires translation, this will further introduce user-perceptible latency into the application as it undergoes dynamic binary translation. Summary of the Invention

[0005] In one embodiment, the system may include memory storing an operating system and one or more application binaries. The one or more application binaries may be written for execution in a first execution environment. The system may also include one or more processors configured to execute the application binaries in a second execution environment different from the first execution environment. The system may also include a binary translator comprising system services executable in an address space separate from the application binaries, and a runtime code module executable in the address space containing the application binaries. The system services may be configured to manage translations of the application binaries, and the runtime code module may be configured to manage just-in-time (JIT) translations of the system services for application binaries for which they lack corresponding translations. In one embodiment, the system services may also manage library binaries (e.g., libraries provided by the operating system and / or user-provided libraries). The system may also include a persistent translation cache stored within the memory. The persistent translation cache may store one or more translations, wherein a given translation corresponds to at least a portion of the one or more application binaries. The one or more translations can be used to execute in the second execution environment, wherein: the translation of the one or more application binaries may include object-level translations of the one or more application binaries generated prior to the execution of the one or more applications represented by the one or more application binaries; and the one or more processors may be configured to execute the cached translations of the one or more application binaries within the runtime code module when the operating system invokes the execution of the one or more application binaries.

[0006] In one embodiment, the first execution environment may include a source instruction set, and the second execution environment may include a target instruction set different from the source instruction set. In one embodiment, code signatures may be generated for each page that includes at least a portion of the translation of the one or more application binaries. A data structure storing the code signatures may be encrypted with a key unique to the system (e.g., a secure enclave processor coupled to one or more processors and memory may be configured to generate the unique key). In one embodiment, the object-level translation may include the translation of libraries used by the one or more application binaries during execution. In one embodiment, the object-level translation may include the translation of plugins used by the one or more application binaries during execution.

[0007] In one implementation, the system service can be configured to generate a hash value based on information associated with one or more application binaries. The system service can store the generated hash value in an associative array in the memory. The generated hash value can be used to determine whether the one or more application binaries are available in the persistent translation cache and to determine whether the one or more application binaries have been modified. When the one or more application binaries have been modified, the system can be configured to: remove the translation of the one or more application binaries from the persistent translation cache; and generate a new translation.

[0008] In one implementation, the runtime code module may be configured to determine whether the one or more application binaries corresponding to the translation being executed have become writable. When the one or more application binaries have become writable, the system may be further configured to: remove the target address associated with the one or more application binaries from the global indirection table; unlink the translations stored in the runtime translation cache that directly jump to the removed translation; advance the global counter; suspend the execution of the thread associated with the one or more application binaries; force the thread associated with the one or more application binaries to perform just-in-time (JIT) translations of the one or more application binaries executed by the runtime code module; and resume the execution of the thread.

[0009] In one implementation, if the one or more application binaries include self-modifying code, the system may be configured to: write-protect pages in the memory where the one or more application binaries are stored; capture writes to the protected pages in an exception handler; remove the target address associated with the one or more application binaries from the global indirection table; unlink translations that store direct jumps to the removed translation in the runtime translation cache; advance the global counter; request the thread associated with the self-modifying code to handle the invalidation; execute the JIT translation of the self-modifying code; record the global counter value in the metadata associated with the translation; update the execution thread with the new version of the global indirection table; remove the removed translation from the return stack associated with the execution thread; insert the target address of the branch into the translation via a lookup in the global indirection table; and release the translation when all threads have reached the global counter value.

[0010] In one embodiment, a system may include one or more processors configured to execute instructions defined in a first instruction set architecture; and a non-transitory computer-accessible storage medium coupled to the one or more processors. The non-transitory computer-accessible storage medium may store: one or more application binaries having instructions defined in a second instruction set architecture different from the first instruction set architecture; a permanent translation cache storing one or more translated code sequences corresponding to one or more portions of the one or more application binaries, wherein the one or more translated code sequences, when executed, perform substantially the same operations as those performed by the one or more portions of the one or more application binaries; and a binary translator including system services that execute in an address space separate from the application binary, and runtime code modules that can execute in the address space having the application binary. The system services may be configured to manage the permanent translation cache, and the runtime code modules may be configured to manage just-in-time (JIT) translation for application binaries for which translated code sequences are not present in the permanent translation cache.

[0011] In one implementation, the system service may be configured to: in response to launching a given application binary in one or more application binaries, check the persistent translation cache for a corresponding translated code sequence, and provide the corresponding translated code sequence to the runtime code module based on the detection of the corresponding translated code sequence in the persistent translation cache. Similarly, libraries used by the given application binary may have translated sequences, and the system service may check the persistent translation cache for translated libraries used by the launched application. The translated library may be provided for launching the application binary. Checking the persistent translation cache may be based on a hash value generated based on the given application / library binary. If the given application binary has been modified after the corresponding translated code sequence was generated, the hash value may differ from the previously generated hash value. In one implementation, a first translated code sequence from the one or more translated code sequences in the translation cache is generated when the corresponding application binary is installed in the system. In one implementation, a first translated code sequence from the one or more translated code sequences in the persistent translation cache is generated when the corresponding application binary is initially launched in the system. In one implementation, when the corresponding application binary is previously launched in the system, the first translated code sequence from the one or more translated code sequences in the runtime translation cache is generated as the JIT translation of the corresponding application binary.

[0012] In one embodiment, a method may include launching a first application binary for execution in a system. The first application binary may be written for a first execution environment, and one or more processors in the system may be configured to execute the application binary in a second execution environment different from the first execution environment. The method may further include determining whether a sequence of translated code generated by a binary translator is stored in a persistent translation cache in the system. The binary translator may include a runtime code module executable in the address space of the application binary and system services executable in different processes, and determines whether the sequence of translated code stored in the persistent translation cache is executable by the system service. The method may further include performing an on-the-fly translation of the first application binary by the runtime code module based on the sequence of translated code not cached in the translation cache. The method may further include executing the cached sequence of translated code within the runtime code module based on the sequence of translated code cached in the translation cache. Attached Figure Description

[0013] The following detailed description refers to the accompanying drawings, which will now be briefly described.

[0014] Figure 1 It is a system that includes a binary translator, consistent with some implementation schemes.

[0015] Figure 2 This demonstrates consistency with some implementation schemes. Figure 1 A diagram of the binary translation system within the system's disk storage.

[0016] Figure 3 This is a diagram of one implementation of a binary translation system in system memory during execution, consistent with some implementation schemes.

[0017] Figure 4 This is a flowchart illustrating a method for processing cached binary translations consistent with some implementations.

[0018] Figure 5 This is a flowchart illustrating a method consistent with some implementations for processing modifications to binary files associated with cached translations.

[0019] Figure 6 This is a flowchart illustrating a method for handling self-modifying code that is consistent with some implementation schemes.

[0020] Figure 7 This is a flowchart illustrating a method consistent with some implementations for processing modifications to the original binary file corresponding to the cached translation being performed.

[0021] Figure 8 This is a flowchart illustrating one implementation of a method for handling exceptions or other interruptions (code stoppage) in translated code.

[0022] While the embodiments described herein may be subject to various modifications and alternatives, specific embodiments thereof are shown by way of example in the accompanying drawings and will be described in detail herein. However, it should be understood that the drawings and specific embodiments thereof are not intended to limit the embodiments to the particular forms disclosed, but rather, the invention is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the appended claims. The headings used herein are for organizational purposes only and are not intended to limit the scope of the specification. Detailed Implementation

[0023] Figure 1 This is a system 100 that includes a binary translator, consistent with some implementation schemes. For example... Figure 1As shown, system 100 includes processor 102, main memory 104, input / output (I / O) circuitry 106, GPU 108, various peripheral devices 110, and disk storage 112. Processor 102, system memory 104, I / O 106, GPU 108, peripheral devices 110, and disk storage 112 are coupled to each other via bus 114, such that system components 102-112 act as proxies for bus 114.

[0024] Processor 102 may include one or more cores 116-1-116-N and processor cache 118. Processor 102 may represent a general-purpose processor that performs computational operations. For example, processor 102 may be a central processing unit (CPU), such as a microprocessor, microcontroller, application-specific integrated circuit (ASIC), or field-programmable gate array (FPGA). Processor 102 may be a standalone component or may be integrated onto an integrated circuit along with other components, such as other processors or other components in a system-on-a-chip (SoC). Processor 102 may be a component in a multi-chip module (MCM) with other components.

[0025] According to some implementations, processor 102 may be configured to execute instructions defined in an execution environment (such as an instruction set architecture (ISA)) implemented by processor 102 and processor core 116-1-116-N. The ISA may include the x86 ISA original developed by Intel and related x86-64 ISAs developed by AMD and Intel, ARM and AArch64 ISAs from ARM Holdings, PowerISA and PowerPC ISAs from IBM / Motorola, RISC-VISA, etc. Instructions are defined in the instruction set architecture, including their encoding in memory, their operation, and their effects on registers, memory locations, and / or other processor states. A given specific implementation of the ISA may execute each instruction directly, but its form may be changed through decoding and other manipulations in processor 102. Another implementation may decode at least some instructions into multiple instruction operations for execution by core 116-1-116-N. In some implementations, some instructions may be micro-encoded. Therefore, the term "instruction operation" in this document can be used to refer to an operation that core 116-1-116-N is configured to perform as a single entity. Instructions can have a one-to-one correspondence with instruction operations, and in some cases, an instruction operation can be an instruction. Instructions can also have a one-to-many (one-to-many) correspondence with instruction operations. Instruction operations can be more simply referred to as "operations" in this document.

[0026] Core 116-1-116-N may include various execution units, each configured to perform various types of operations (e.g., integer, floating-point, vector, multimedia, load / store, etc.). Core 116-1-116-N may include varying numbers of pipeline stages and various other performance enhancements such as branch prediction. Core 116-1-116-N may include one or more of the following: instruction decoding unit, scheduler or reservation station, reordering buffer, memory management unit, I / O interface, etc.

[0027] The processor cache 118 may be volatile or non-volatile memory. In some embodiments, the processor cache 118 may be static random access memory (SRAM). Additional processor caches may include instruction caches and data caches. The processor cache 118 may be organized into a hierarchy of one or more cache levels, such as level 1 (L1), L2, L3, etc.

[0028] In some implementations, processor 102 may also include a secure enclave processor (SEP) 119. The SEP may be a self-contained system-on-a-chip (SoC) within processor 102, including its own processor and one or more secure peripherals. SEP 119 may be isolated from the rest of processor 102, allowing for strict control over access to SEP 119. For example, processor 102 may only be able to communicate with SEP 119 via a mailbox mechanism, where processor 102 can write messages to a mailbox, and SEP 119 can read and respond to the message through the mailbox.

[0029] In one implementation, SEP 119 can manage the cryptographic keys of system 100. In one implementation, software executing on system 100 can request a key, and system 100 can generate a "wrapped" key for the requesting software. The wrapped key is encrypted using a wrapping key, which is transmitted in hardware to the cryptographic hardware in SEP 119. Using the wrapping key, the receiving cryptographic hardware in SEP can decrypt the wrapped key provided by the software to obtain the actual key to be used. Insecure software cannot access the actual key.

[0030] Disk storage 112 may include volatile and / or non-volatile memory and may be used as a long-term storage device for system 100. Disk storage 112 may store one or more application programs 120, which, when executed by processor 102, cause system 100 to perform one or more steps, operations, or functions, and may include software applications. Application program 120 may include one or more binary files. Application program 120 may be written for execution in a specific execution environment, such as a specific instruction set architecture. In some embodiments, the execution environment for which application program 120 is written is different from the execution environment for which processor 102 is designed to execute. In such embodiments, application program 120 is considered to be written for a source execution environment, while the processor is capable of executing it in a target execution environment. As discussed throughout, system 100 may be able to translate application binary files written for a first or source execution environment for use in a second or target execution environment. Figure 1 The disk storage 112 may include a permanent translation cache 122 and an operating system 124. The operating system 124 may include instructions and frameworks for any well-known operating system, such as MacOS X.

[0031] More generally, disk storage 112 and / or main memory 104 may be examples of computer-accessible storage media. Generally, computer-accessible storage media can include any storage medium that can be accessed by a computer during use to provide instructions and / or data to the computer. For example, computer-accessible storage media can include storage media such as magnetic or optical media, such as discs (fixed or removable), tapes, CD-ROMs, DVD-ROMs, CD-Rs, CD-RWs, DVD-Rs, DVD-RWs, or Blu-ray discs. Storage media may also include volatile or non-volatile memory media such as RAM (e.g., Synchronous Dynamic RAM (SDRAM), Rambus DRAM (RDRAM), Static RAM (SRAM), etc.), ROM, or flash memory. The storage medium may be physically included within a computer to which instructions / data are provided. Alternatively, the storage medium may be connected to a computer. For example, the storage medium may be connected to a computer via a network or wireless link such as a network-attached storage device. The storage medium may be connected via a peripheral interface such as a Universal Serial Bus (USB). Typically, computer-accessible storage media can store data in a non-transitory manner, where non-transitory in this context can mean not transmitting instructions / data via signals. For example, a non-transitory storage device can be volatile (and may lose stored instructions / data in response to a power outage) or non-volatile. Computer-accessible storage media can store... Figure 1Various components are shown, such as permanent translation cache 122, application 120, and / or operating system 124.

[0032] I / O circuitry 106 and / or peripheral devices 110 can be any set of additional hardware functions included in system 100. For example, peripheral devices 110 may include video peripherals, such as image signal processors configured to process image capture data from cameras or other image sensors, graphics processing units (GPUs), etc. Figure 1 The peripherals include a GPU 108, video encoders / decoders, scalers, rotators, mixers, video display controllers, displays (such as liquid crystal displays (LCDs)), light-emitting diode displays (LEDs) (such as organic LEDs (OLEDs)), plasma displays, etc., including displays integrated with touch sensing technology to act as input devices. Peripherals may include video peripherals such as microphones, speakers, microphone and speaker interfaces, audio processors, digital signal processors, mixers, etc. I / O circuitry 106 may include interface controllers for various interfaces external to the system, including interfaces such as Universal Serial Bus (USB), PCI including the Peripheral Component Interconnect Standard (PCIe), serial ports, and parallel ports, etc. Peripherals may include networking peripherals such as Media Access Controllers (MACs). Any set of hardware may be included as peripherals 110 and / or I / O circuitry 106. Peripherals may include other user interface devices such as keyboards, mice, or other pointing devices.

[0033] Bus 114 can be an example of a communication architecture. Typically, a communication architecture can be any communication interconnect and protocol used for communication between components of system 100. The communication architecture can be bus-based (e.g., bus 114), including shared bus configurations, crossbar configurations, and hierarchical buses with bridges. The communication architecture can also be packet-based and can be a hierarchical, crossbar, point-to-point, or other interconnect with bridges.

[0034] Main memory 104 may include a memory controller and one or more memory devices. The memory controller typically includes circuitry for receiving memory operations from other components of system 100 and for accessing memory devices to complete the memory operations. The memory controller may be configured to access any type of memory device. For example, the memory device may be static random access memory (SRAM), dynamic RAM (DRAM), or synchronous DRAM (SDRAM) including double data rate (DDR, DDR2, DDR3, DDR4, etc.) DRAM. Low-power / mobile versions of DDR DRAM (e.g., LPDDR, mDDR, etc.) may be supported. The memory controller may include a memory operation queue for ordering (and possibly reordering) these operations and presenting them to the memory devices. The memory controller may also include data buffers for storing write data awaiting to be written to the memory devices and read data awaiting return to the source of the memory operations. In some embodiments, the memory controller may include a memory cache for storing recently accessed memory data. In some cases, the memory cache may also be referred to as a system cache, which differs from a proprietary cache such as processor cache 118, which serves only certain components. Main memory 104 may store various types of code for execution, such as application 120, corresponding translations read from permanent translation cache 122, operating system 124, etc. In one embodiment, various runtime data structures may also be in main memory 104. For example, main memory 104 may store a global indirection table 117. The global indirection table 117 may be a data structure managed by a binary translator to map indirection target addresses from application 120 to indirection target addresses in the corresponding translated code sequence.

[0035] In some implementations, the persistent translation cache 122 may include translations of binaries developed or written for one execution environment to a second execution environment different from the first execution environment. The binaries may include executables, applications, linkers, libraries, etc. In some implementations, the binaries may include Mach-O objects. In some implementations, the translated binaries stored in the translation cache may be signed using a key unique to system 100 generated by SEP 119, such that the translation is unavailable to system 100 unless it is signed. Furthermore, the persistent translation cache 122 may reside in a read / write partition of disk storage 112 along with the operating system 124. More specifically, when executed by processor 102, a translation of a given binary file may cause system 100 to perform operations substantially identically in system 100 to operations performed in a first execution environment (e.g., an ISA) for which the binary file was written. Because the second execution environment differs from the first execution environment, some differences in operation may exist. For example, in some cases, multiple instructions in an ISA implemented by processor 120 can be used to perform the same operation as a single instruction in an ISA to which the binary file is written. Therefore, the amount of time elapsed during the execution of the binary file may differ compared to executing the original binary file in its original execution environment. However, the functionality of the original binary file can be maintained, for example, identically as in the translated binary file.

[0036] Figure 2 This is a diagram illustrating a binary translation system 200 within a disk storage 112 of a system 100 consistent with some implementation schemes. (See diagram for reference.) Figure 2As shown, the binary translation system (or simply "binary translator") 200 includes a system service 202 and a runtime code module 204. In some embodiments, the runtime code module 204 is a runtime service residing in the address space corresponding to the application 120 within disk storage 112, and is the location where the translated application 120 is executed in a second execution environment. The system service 202 may be responsible for managing access to translations stored in a persistent translation cache 122, and for ensuring the consistency of translations stored in the persistent translation cache 122 in the case of self-modified code or other dynamically modified code. The system service 202 may manage the scheduling of translations when cached translations are absent or invalid, and may execute translations. Specifically, the system service 202 may be responsible for handling calls to the persistent translation cache 122, determining hash values ​​associated with one or more binary files 206-1-206-N (hereinafter referred to as binary file 206) of the application 120, and writing lookups to and performing lookups from a global hash table 208. In some implementations, system service 202 may handle requests to binary translator 202 via inter-process communication (IPC) calls from operating system 124. Runtime code module 204 may be responsible for handling just-in-time (JIT) translation and may also be responsible for monitoring the status of registers updated by the application during execution (e.g., registers defined in the source ISA or the execution environment in which application 120 was initially written).

[0037] like Figure 2 As further illustrated, application 120 includes application binary 206. As previously discussed, binary 206 may include executable files, applications, linkers, libraries, etc. In some embodiments, binary 206 may include Mach-O objects. In some embodiments, the disk storage may also include shared libraries and / or a shared cache 210, which may store libraries and caches that can be utilized by various applications, services, and / or the operating system 124 itself.

[0038] In some implementations, binary files 206 may be translated when they are installed onto system 100 via a standard or trusted installation process associated with operating system 124. The translation process may be performed as part of the installation (e.g., the installation may not be completed until the translation is finished) or as a background process during and / or after installation. For other installations, such as sideloading or via removable disk media, binary translator 200 may translate binary files 206 upon the first launch of application 120 or the first use of any binary file 206. If binary file 206 cannot be translated due to errors or mispredictions, runtime code module 204 includes a just-in-time (JIT) translation process that translates the smaller set of instructions associated with binary file 206 when system 100 attempts to execute application 120. When operating system 124 is updated, system service 202 may delete all cached translations in permanent translation cache 122 and initiate a background process to re-translate all previously cached binary files 206. Furthermore, when binary translator 200 is added to system 100, binary translator 100 can translate shared libraries and shared cache 210 associated with operating system 124.

[0039] To perform the translation of a binary file written for execution in a first execution environment for use in a second execution environment, system service 202 may identify one or more entry points into binary file 206 to determine potential portions of the binary file that may be code and require translation. In some embodiments, the first execution environment may include support for variable-size instructions, while the second execution environment may only include support for fixed-size instructions. In these embodiments, system service 202 may find potentially valid instructions for translation at multiple steps along the way, as it may not know instruction boundaries based on instruction size. System service 202 may use information provided by the static linker to the dynamic linker to identify entry points into binary file 206. Specifically, in some embodiments, operating system 124 may include a dynamic linker that links applications to shared libraries 210 and places specific code at address points in disk storage 112, which the application 120 encodes at link time. This allows the application 120 to use machine-specific calls or jump instructions to one of those address points when it needs to utilize the dynamic linker rather than interacting with it directly. System service 202 can utilize these specific address points as entry points for identifying code that needs to be translated. Once the entry points have been identified and the code that needs to be translated has been identified, system service 202 can translate the identified code written for the first execution environment into code that can be executed in the second execution environment. System service 202 can store the translation in a persistent translation cache 122 in disk storage 112 and update the associated array 208 by executing the hash of the application binary 206 and storing the hash in array 208.

[0040] Figure 3 This is a block diagram illustrating one embodiment of main memory 104 during operation. Various portions of the address space may be mapped by operating system 124 into system service space 320 and user (or unprivileged) space 322. For example, operating system 124 may define pages of memory as either privileged space or user space 322 in a virtual-to-physical address translation mechanism, as one of the page attributes in the translation. Privileged space may be the address space in which operating system 124 itself executes, or, in a kernel-based embodiment, at least the kernel portion of operating system 124. User space 322 may be the space in which application 120 executes. System service space 320 may also be user space, but may be separate from the address space in which the translated application runs (e.g., system services may be processes different from the translated application, while runtime code module 204 may execute in the address space of the translated application). Generally, code executing in user space 322 may not be permitted to execute certain instructions reserved by operating system 124 for itself to control critical processor states.

[0041] As previously described, system service 202 can execute in system service space 320 and can maintain a persistent translation cache 122. The persistent translation cache 122 can reside in user space so that translated code can be executed by processor 102, but access to the persistent translation cache 122 can be controlled by system service 202 (e.g., generating hashes and checking them for translation when a given application 120 is invoked for execution). Alternatively, translations from the persistent translation cache 122 can be mapped into memory when the corresponding application is launched or when an entry point corresponding to a cached translation is invoked. Translations can be loaded into memory and pointers to the translations can be provided to runtime code module 204. Translations can be loaded into the address space of the application in user space 322. If multiple threads are executing the same translation, the translation can be mapped into the address space of each thread. Alternatively, threads can share a common copy of the translation. Other points in time may exist where translations are loaded from the persistent translation cache 122. For example, a dynamic linker can link various dynamic link libraries to the application. If a dynamic link library is written for a first execution environment, the dynamic linker may request the runtime code module 204 to determine whether the translation exists in the persistent translation cache 122. The runtime code module 204 may query system services to determine whether the translation exists and may determine the size of the translation. Alternatively, the dynamic linker may query system services and provide the size to the runtime code module to allocate memory for the translated library. The dynamic linker may load the original library code and may request the runtime code module 204 to load the corresponding translation and provide a pointer to that translation.

[0042] As described above, runtime code module 204 executes in user space 322 (and more specifically, in the address space of application 120 when application 120 is written to an ISA different from that of processor 102). When a corresponding translation or a portion thereof for application 120 is not found in permanent translation cache 122, runtime code module 204 may maintain runtime translation cache 122 for JIT translations generated by runtime code module 204.

[0043] In one implementation, the JIT translation generated by runtime code module 204 may also be installed as a translation in persistent translation cache 122. While JIT translations typically cover a small portion of the application dynamically generated when application 120 is executed, if the JIT translations begin to cover a sufficiently large portion of the entire application (e.g., a threshold amount), the JIT translations may be installed in persistent translation cache 122 by system service 202 and held for later execution. In other implementations, JIT translations may not be installed in persistent translation cache 122 and may therefore be generated by runtime code module 204 each time the corresponding application is invoked. In yet another implementation, the generation of JIT translations may serve as a hint to binary translator 200 to consider translations to be installed in persistent translation cache 122. If binary translator 200 determines that a translation should be performed, binary translator 200 may perform a translation separate from the JIT translation and may install the separately generated translation in persistent translation cache 122. Various factors can determine whether JIT translation results in translation for the permanent translation cache 122 (e.g., the frequency with which JIT translation is generated over time during different executions of the application; whether JIT translation is due to self-modifying code, which may not be installed in the permanent translation cache 122; etc.).

[0044] The shared library / cache 210 may also be in user space 322, or in privileged space or a combination of spaces (e.g., library 210 may be in privileged space or user space 322 on a per-library basis).

[0045] Figure 4 This is a flowchart illustrating a method 400 for processing cached binary translations, consistent with some implementation schemes. (Example) Figure 4As shown, when application 120 is invoked (step 402), a check can be performed to determine whether application 120 is written for a first execution environment (step 404). In some embodiments, an application such as application 120 may include one or more binaries 206 written for execution in a first execution environment (such as x86 or x86-64), which requires a processor capable of executing those instructions. If application 120 is not written for the first execution environment and instead can run locally in a second execution environment (which may be, for example, ARM or AArch64), then application 120 can run locally (step 406). If application 120 is written for the first execution environment, it can be passed to system service 202 of binary translation system 200 (step 408). In some embodiments, the code used to pass the application to system service 202 may be part of runtime code module 204. System service 202 may compute a hash value based on metadata associated with one or more binaries 206 of the application and / or the binary 206 itself, and compare the generated hash with one or more hash values ​​in the associated array 208 to determine whether a cached translation exists in the permanent translation cache 122, or whether a desired cached translation is unavailable (step 410). If a match is found in array 208, the cached translation can be used by granting access to the cached translation (access to runtime module 204 by system service 202). The cached translation can be mapped into memory using standard operating system calls (e.g., in a...). Figure 3 (Step 412). Then, the translated application binary can be executed in the user address space 322 of the application shown. Then, the translated application binary can be executed in the second execution environment within the runtime code module 204 (step 414). When the hash does not match, the application 120 may not have been translated previously. In this case, the system service 202 can start a background process to translate the application binary 206 (step 416) and install the resulting translation in the persistent translation cache 122. In parallel, the runtime code module 204 can generate a JIT translation for the currently executing code. Then, the JIT translation can be executed in the second execution environment within the runtime code module 204 (step 414).

[0046] Figure 5 This is a flowchart illustrating a method 500 for processing modifications to binary files associated with cached translations, consistent with some implementation schemes. (Example) Figure 5 As shown, when application 120 is invoked (step 502), a check can be performed to determine whether the application is written for a first execution environment (step 504) (e.g., similar to...). Figure 4 (Implementation scheme). In some implementations, an application such as application 120 may include one or more binary files 206 written for execution in a first execution environment (such as x86 or x86-64), which requires a processor capable of executing those instructions. If application 120 is not written for the first execution environment and instead can run natively in a second execution environment (which may be, for example, ARM or AArch64), the application may run natively (step 506). If the application is written for the first execution environment, it may be passed to system service 202 of binary translation system 200 by runtime code module 204 (step 508). System service 202 may compute a hash value based on metadata associated with one or more binary files 206 of the application or the binary file 206 itself, and compare the hash value with one or more values ​​in associated array 208 to determine whether a cached translation exists in permanent translation cache 122 or whether the application has been modified (step 510). If a match is found in array 208, the cached translation can be used by granting access to it, and the cached translation can then be mapped onto memory using standard operating system calls (step 512). The translation can be executed in the second execution environment via runtime code module 204 (step 520). When the hash does not match, application 120 may have been modified and a new translation is required. In this case, system service 202 may remove the cached translation (step 514) and generate a new translation (step 516), and then send the generated new translation to runtime code module 204 (step 518) for execution within the second execution environment in runtime code module 204 (step 520).

[0047] Consistent with some implementations, the binary translation system 200 can also manage multithreaded resources. In some implementations, the runtime code module 204 may use specific time-based processing to manage its resources, referred to as period-based reclamation. In period-based reclamation, each executing thread on system 100 may be associated with a current period, which indicates when the thread last exited the runtime code module 204 and discarded any pointers to shared state. Threads may asynchronously request other threads to advance their periods, or they may perform one of a few tasks. Shared resources can be deallocated when all threads have advanced to a sufficiently close period.

[0048] Figure 6This is a flowchart illustrating a method 600 for handling self-modifying code, consistent with some embodiments. Some execution environments (e.g., x86 and x86-64) allow applications to employ self-modifying code, and the binary translation system 200 is also capable of handling self-modifying code. In some embodiments, a first execution environment may actively maintain coherence between data and instruction caches and an instruction pipeline, which may invoke the self-modifying code at build time. To handle such self-modifying code, the binary translation system 200 may initially write-protect any code pages in memory of a binary file 206 written for the first execution environment, which has been translated into code written for a second execution environment (step 602). Then, if a write occurs (which could be a store instruction or an attempt to modify the page in memory via a system call, etc.), system service 202 may catch the write in an exception handler in runtime code module 204 (step 604). Then, the exception handler in runtime code module 204 can remove any branch targets for that page from the global indirection branch table 117 (step 606) and unlink any translations that jump directly to the affected translation (step 608). The exception handler can then advance the global epoch counter (step 610), asynchronously request all other threads to process the invalidation of the code (step 612), and log the advanced global epoch counter value in the metadata of each affected translation (step 614). While processing the asynchronous request, other threads update to the latest version of the indirection branch table 117, clear any removed translations from its return stack cache (or simply clear the entire cache) (step 616), and enter the translated code by performing a new lookup from the indirection branch table 117 (step 618). Execution of the original thread can then continue with the capture write. When all other threads reach the newly updated epoch, the affected translation can be released from the lock and execution can continue (step 620). It should be noted that in one implementation, method 600 can be processed by runtime code module 204 within the application's address space.

[0049] Figure 7 This is a flowchart illustrating a method 700 for processing modifications to the original binary file corresponding to the cached translation being performed, consistent with some implementation schemes. (See flowchart for example.) Figure 6As shown, when a cached translation is being executed within runtime code module 204 (step 702), runtime code module 204 can determine that the original binary file corresponding to the currently executing cached translation is already writable (step 704). In some cases, application 120 corresponding to a cached translation can modify binary file 206 during execution by making it writable, thereby indicating that it may be modified, which can invalidate previously cached translations of binary file 206. Then, the exception handler in runtime code module 204 can remove any branch targets for that page from the global indirection table 117 (step 706) and unlink any translations that jump directly to the affected translation (step 708). In one embodiment, binary translator 200 can maintain a mapping from the address of the original (untranslated) code that serves as the translation entry point to the corresponding translation itself. The mapping allows binary translator 200 to efficiently perform ordered queries. When the affected translation is invalid for writing to code in a given page, the mapping to any address at that time can be invalidated. An exception handler may advance the global epoch counter (step 710). Then, runtime code module 204 may send a message to operating system 124 to suspend all execution threads (step 712). Runtime code module 204 may then check if any threads are running cached translations, and if so, forcibly redirect them to JIT translations generated by runtime code module 204 (step 714). For example, each thread's thread-specific context may include variables indicating the last global epoch change observed by the thread. Variables may be written atomically by one thread and read atomically by another thread. The runtime code module may resume execution of all threads within a second execution environment within runtime code module 204 (step 716). In some implementations, the JIT translation is not cached in disk storage 112, but is only temporarily stored in the writable address space of runtime code module 204.

[0050] In some implementations, the binary translation system 200 may also be able to handle indirect branches. Specifically, indirect branch lookups can be performed using a global indirect branch table 117, where multiple threads can read the table without synchronization, but the writer takes a lock to modify it. As the size of table 117 increases, only the thread that updates its local table pointer to point to the latest version gets the new version, which occurs when a thread returns from runtime code module 204 to translated code (if necessary). In some implementations, period-based reclamation is used to handle the reclamation of older versions of table 117 (after the table grows). Deletions can be handled in situ because table 117 is linearly probed. Race conditions exist where one thread might be reading while another is deleting, resulting in an incorrectly detected cache miss. This can be handled by having the code path that missed a permanent translation cache 122 use the same lock being used by the writer. Function returns are a specific type of indirect branch, which can be handled using a software version of the return stack branch predictor. A pair of program counters from the first execution environment and translated program counters for the second execution environment are stored on the stack. Upon return, the return address is checked to see if it matches the stored address associated with the program counter used for the first execution environment. If a match is found, the saved translated program counter is returned. Otherwise, indirect branching is handled as normal.

[0051] In some implementations, while system 100 is executing the translated application 120, runtime code module 204 may monitor the execution of translated instructions to improve translation accuracy by ensuring that exceptions, traps, and other interruptions in instruction execution occur at instructions in the target execution environment that correspond to the beginning or end (“instruction boundaries”) of instructions in the source execution environment. That is, a given instruction in the source ISA can be translated into multiple instructions in the target ISA. If the execution of instructions in the translated instruction sequence is interrupted at one of the instructions that does not represent a boundary of the source instructions, the register state and / or other architectural state of processor 102 may reflect partial execution of the source ISA instructions, which is not possible on a processor that natively executes the source ISA. For example, operating system 124 may include various mechanisms to query registers after execution of the translated instruction sequence has stopped (e.g., for debugging purposes). Runtime code module 204 may monitor the execution of translated instructions to ensure that at each execution point in the second execution environment, the runtime code module may fast-forward or rewind a small number of instructions to produce an accurate register state according to the first execution environment, as if the binary is actually being executed precisely relative to the instruction boundaries observed in the first execution environment. In some implementations, the process may allow the execution of translated instructions to behave as if they were being executed atomically, as if they were being executed in a first execution environment rather than using instructions designed for a second execution environment.

[0052] Figure 8 This is a flowchart illustrating one embodiment of a method 800 for handling exceptions or other interruptions (code halting) in translated code. Exceptions can be synchronous halting of code due to a condition detected relative to the execution of instructions. In some cases, interrupts can be asynchronous with instruction execution (e.g., external interrupts originating from the device, or interrupts issued by another thread). An interrupt is taken when an instruction completes execution, but the interrupt may be independent of the instruction's execution. When exceptions and interrupts occur during the execution of translated code, they occur between translated instructions, but may not occur at the instruction boundaries of the corresponding source instructions, as there may be more than one translated instruction used to emulate the source instructions.

[0053] Therefore, translation is being performed (step 802). If no code stop is detected (decision step 804, "No" branch), translation execution can continue (step 802). On the other hand, if a code stop is detected (decision step 804, "Yes" branch), the runtime code module 204 can examine the code sequence to determine whether the code stop occurred at a source instruction boundary (step 806). For example, in one embodiment, the binary translator 200 may generate a translation following a set of rules, and therefore the examination of the code sequence (decomposing instructions near the stop) allows the binary translator 200 to determine where the boundary of a given source instruction is and what the progress of the source instruction was at the time of the stop. If the stop occurs at an instruction boundary (decision step 808, "Yes" branch), the stop can be handled at the instruction boundary (step 816). If no (decision step 808, "No" branch), the runtime code module 204 can determine whether any architectural state of the source execution environment has been modified (and whether such modification can be reversed to restore the state at the beginning of the source instruction) (decision step 810). If no structured state has been modified, or if the structured state has been modified and reversal is possible and expected rather than rollback (decision step 810, "No" branch), then runtime code module 204 can roll back the state to the beginning of the source instruction (step 820) and can process the stop (step 816). If the structured state has been irreversibly modified, or if rollback is not expected (decision step 810, "Yes" branch), then runtime code module 204 can determine whether a rollback is possible by simulating the remainder of the source instruction execution and modifying the structured state using the result of the instruction (decision step 812). If a rollback is possible (decision step 812, "Yes" branch), then runtime code module 204 can roll forward to the next instruction boundary (box 814) and can process the stop at that instruction boundary (step 816). If a rollback is not possible (decision step 812, "No" branch), then the execution of the translated code sequence can be terminated (step 818).

[0054] ***

[0055] This disclosure includes references to “implementation” or groups of “implementation” (e.g., “some implementations” or “various implementations”). An implementation is a different specific implementation or instance of the disclosed concepts. References to “implementation,” “an implementation,” “a particular implementation,” etc., do not necessarily refer to the same implementation. A large number of possible implementations are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the substance or scope of this disclosure.

[0056] This disclosure may discuss potential advantages that may arise from the disclosed embodiments. Not all specific implementations of all these embodiments will necessarily exhibit any or all of the potential advantages. Whether a particular embodiment achieves an advantage depends on many factors, some of which are outside the scope of this disclosure. In fact, there are many reasons why an embodiment falling within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular embodiment may include other circuitry outside the scope of this disclosure, in conjunction with an embodiment of the disclosed embodiments, which negates or diminishes one or more of the disclosed advantages. Furthermore, suboptimal design execution of a particular embodiment (e.g., the implementing technique or tool) may also negate or diminish the disclosed advantages. Even assuming an implementation of the technique, the realization of advantages may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the inputs provided to a particular embodiment may prevent one or more problems addressed in this disclosure from occurring in a particular context, and as a result, the benefits of its solution may not be realized. Given the existence of possible factors outside this disclosure, any potential advantages described herein should not be construed as a claim limitation that must be satisfied in order to prove infringement. Rather, the identification of such potential advantages is intended to show one or more types of improvements available to a designer who benefits from this disclosure. Describing such advantages permanently (e.g., stating that a particular advantage "may occur") is not intended to convey a question about whether such advantages can actually be realized, but rather to recognize that the realization of such advantages often depends on the technological reality of additional factors.

[0057] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims drafted based on this disclosure, even where only a single example is described with respect to a particular feature. The embodiments disclosed in this invention are intended to be exemplary and not restrictive, without requiring any statement to the contrary in this invention. Therefore, this application is intended to allow for the coverage of the claims of the disclosed embodiments, as well as such alternatives, modifications, and equivalents, which will be apparent to those skilled in the art who are aware of the effective effects of this disclosure.

[0058] For example, the features in the present application may be combined in any suitable manner. Thus, during the prosecution of the present patent application (or a patent application claiming priority therefrom), new claims may be made for any such combination of features. Specifically, referring to the appended claims, the features of dependent claims may, where appropriate, be combined with the features of other dependent claims, including claims that depend from other independent claims. Similarly, where appropriate, features from corresponding independent claims may be combined.

[0059] Thus, although the appended dependent claims may be drafted such that each dependent claim depends from a single other claim, additional dependencies are also contemplated. Any combination of dependent features consistent with the present disclosure is contemplated, and such combinations may be claimed in the present patent application or another patent application. In short, the combinations are not limited to those specifically recited in the appended claims.

[0060] Where appropriate, it is also contemplated that claims drafted in one format or statutory type (e.g., apparatus) are intended to support corresponding claims in another format or statutory type (e.g., method).

[0061] ***

[0062] Because the present disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. Notice is hereby given that the following paragraphs, as well as the definitions provided throughout the present disclosure, will be used to determine how claims drafted based on the present disclosure are to be interpreted.

[0063] References to items in the singular form (i.e., a noun or noun phrase preceded by "a," "an," or "the") are intended to mean "one or more" unless the context clearly dictates otherwise. Thus, without accompanying context, a reference to an "item" in a claim does not exclude additional instances of that item. A "plurality" of items means a collection of two or more items.

[0064] The word "may" is used herein in the permissive sense (i.e., having the potential to, being able to), rather than in the mandatory sense (i.e., must).

[0065] The terms "comprising" and "including" and their forms are open-ended and mean "including but not limited to."

[0066] When the term “or” is used in this disclosure in relation to a list of options, it will generally be understood to be used in an inclusive sense unless the context otherwise provides. Thus, the expression “x or y” is equivalent to “x or y, or both,” and therefore covers 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, phrases such as “either x or y, but not both” make it clear that “or” is used in an exclusive sense.

[0067] The expressions “w, x, y, or z, or any combination thereof” or “...at least one of w, x, y, and z” are intended to cover all possibilities involving a single element up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element in the set (e.g., w but not x, y, or z), any two elements (e.g., w and x, but not y or z), any three elements (e.g., w, x, and y, but not z), and all four elements. The phrase “...at least one of w, x, y, and z” therefore refers to at least one element in the set [w, x, y, z], thus covering all possible combinations of that list of elements. This phrase should not be interpreted as requiring the existence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0068] In this disclosure, various “labels” may precede nouns or noun phrases. Unless the context otherwise provides, different labels used for features (e.g., “first circuit,” “second circuit,” “specific circuit,” “given circuit,” etc.) refer to different instances of the feature. Furthermore, unless otherwise stated, the labels “first,” “second,” and “third” do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0069] The phrase "based on" is used to describe one or more factors that influence the determination. This term does not exclude the possibility that additional factors may influence the determination. That is, the determination may be based solely on the specified factors or on the specified factors and other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude the possibility that the determination of A may also be based on another factor such as C. This phrase is also intended to cover implementations where A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "at least partially based on."

[0070] The phrases “responding to” and “responding” describe one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, whether used in conjunction with or independently of the specified factor. That is, the effect may respond solely to these factors, or it may respond to the specified factor along with other unspecified factors. Consider the phrase “responding to B to execute A.” This phrase specifies that B is a factor that triggers the execution of A or a specific result of A. This phrase does not exclude that the execution of A may also respond to certain other factors, such as C. This phrase also does not exclude that the execution of A may be performed jointly in response to B and C. This phrase is also intended to cover implementations where A is executed solely in response to B. As used herein, the phrase “responding” is synonymous with the phrase “at least partially responding to.” Similarly, the phrase “responding to” is synonymous with the phrase “at least partially responding to.”

[0071] ***

[0072] Within this disclosure, different entities (which may be referred to differently as “units,” “circuits,” other components, etc.) may be described or claimed to be “configured” to perform one or more tasks or operations. This expression—an [entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a physical thing). More specifically, this expression is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be said to be “configured” to perform a task even if the structure is not currently being operated. Therefore, an entity described or stated as “configured” to perform a task refers to a physical thing used to perform that task, such as a device, circuit, system with processor units, and memory storing executable program instructions. This phrase is not used herein to refer to intangible things.

[0073] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured" to perform those tasks / operations, even if not specifically stated.

[0074] The term "configured as" is not intended to mean "configurable as". For example, an unprogrammed FPGA is not considered "configured as" to perform a specific function. However, the unprogrammed FPGA may be "configurable as" to perform that function. After proper programming, the FPGA can then be considered "configured as" to perform a specific function.

[0075] For the purposes of this U.S. patent application based on this disclosure, the statement in the claims that the structure is “configured” to perform one or more tasks is expressly intended not to invoke 35 U.SC § 112(f) for that claim element. If an applicant wishes to invoke part 112(f) in the course of filing a U.S. patent application based on this disclosure, it will use the structure “means for [performing a function]” to state the elements of the claims.

[0076] Different “circuits” may be described in this disclosure. These circuits or “circuits” constitute hardware that includes various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. Circuits may be custom-designed or taken from standard libraries. In various specific implementations, circuits may include digital components, analog components, or a combination of both, depending on the circumstances. Certain types of circuits may be commonly referred to as “cells” (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such cells also refer to circuits or circuitry.

[0077] Therefore, the circuits / units / components and other elements disclosed in the accompanying drawings and described herein include hardware elements, such as those described in the preceding paragraphs. In many cases, the internal arrangement of hardware elements in a particular circuit can be specified by describing the function of that circuit. For example, a particular “decoding unit” can be described as having the function of executing “the opcode of a processing instruction and routing that instruction to one or more of a plurality of functional units,” meaning that the decoding unit is “configured” to perform that function. To those skilled in the art of computers, this functional specification is sufficient to suggest a set of possible structures for the circuit.

[0078] In various implementations, as discussed in the preceding paragraphs, circuits, cells, and other elements configured thereto define the functions or operations to be performed. The arrangement of such circuits / cells / components relative to each other and the manner in which they interact form a microarchitecture definition of hardware, which is ultimately manufactured in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Thus, a microarchitecture definition is considered by those skilled in the art to be a structure from which many physical implementations are derived, all of which fall within the broader structure described by the microarchitecture definition. That is, those skilled in the art, with the microarchitecture definition provided according to this disclosure, can implement this structure without excessive experimentation and using the application of a person of ordinary skill in the art, by encoding the description of the circuits / cells / components in a hardware description language (HDL) such as Verilog or VHDL. The HDL description is often expressed in a way that can be revealed as functional. However, for those skilled in the art, the HDL description is a way of translating the structure of a circuit, cell, or component into the details of the next level of implementation. Such HDL descriptions can take the following forms: behavioral code (which is typically non-synthesizable), Register Transfer Language (RTL) code (which is typically synthesizable compared to behavioral code), or structural code (e.g., a netlist specifying logic gates and their connectivity). HDL descriptions can be sequentially synthesized against a library of cells designed for a given integrated circuit manufacturing technology and can be modified for timing, power, and other reasons to obtain the final design database that is transferred to the factory to generate masks and ultimately produce integrated circuits. Some hardware circuitry or portions thereof can also be custom-designed in a schematic editor and captured into the integrated circuit design along with the synthesized circuitry. The integrated circuit can include transistors and other circuit elements (e.g., passive components such as capacitors, resistors, inductors, etc.), as well as interconnects between transistors and circuit elements. Some implementations may implement multiple integrated circuits coupled together to implement the hardware circuitry, and / or discrete components may be used in some implementations. Alternatively, the HDL design can be synthesized into a programmable logic array such as a Field Programmable Gate Array (FPGA) and implemented in the FPGA. This decoupling between the design of a set of circuits and their subsequent low-level implementations often results in a situation where the circuit or logic designer never specifies a particular set of structures for the low-level implementation that goes beyond a description of what the circuit is configured to do, because that process is performed at different stages of the circuit implementation process.

[0079] The fact that a circuit of the same specifications can be implemented using many different low-level combinations of circuit elements results in a large number of equivalent circuit structures. As noted, these low-level circuit implementations can vary depending on the manufacturing technology, the foundry chosen to manufacture the integrated circuit, the cell library provided for a particular project, and so on. In many cases, the choice of different design tools or methods to produce these different implementations can be arbitrary.

[0080] Furthermore, for a given implementation, a single concrete implementation of the circuit's specific functional specifications typically involves a large number of devices (e.g., millions of transistors). Therefore, the shearing volume of this information makes it impractical to provide a complete description of the low-level structure used to implement a single implementation, let alone a large number of equivalent possible implementations. To this end, this disclosure describes the structure of a circuit using functional abbreviations commonly used in industry.

[0081] Once the above disclosure is fully understood, many variations and modifications will become apparent to those skilled in the art. This disclosure is intended to make the following claims interpretable as encompassing all such variations and modifications.

Claims

1. A system for performing binary translation, comprising: A memory that stores an operating system and one or more application binaries, which are written to be executed in a first execution environment; One or more processors, the one or more processors being configured to execute an application binary in a second execution environment different from the first execution environment; A binary translator comprising a cache management system service executable in a first address space of the application binary and a runtime code module executable in a second address space of the application binary, wherein the first address space is separate from the second address space, wherein the cache management system service is configured to manage the translation of the application binary in a translation cache, the management including handling calls to the translation cache, and wherein the runtime code module is configured to manage the just-in-time (JIT) translation of the application binary by the cache management system service for which a corresponding translation is lacking; and The translation cache stores one or more translations, wherein a given translation corresponds to at least a portion of the one or more application binaries, and wherein the one or more translations are used for execution in the second execution environment, wherein: The translation of the one or more application binaries includes an object-level translation of the one or more application binaries generated prior to the execution of the one or more applications represented by the one or more application binaries; and The one or more processors are configured to perform the cached translation of the one or more application binaries within the runtime code module when the operating system invokes the execution of the one or more application binaries.

2. The system of claim 1, wherein the first execution environment includes a source instruction set, and the second execution environment includes a target instruction set different from the source instruction set.

3. The system of claim 1, wherein the translation of the one or more application binaries is encrypted using a key unique to the system.

4. The system according to claim 3, further comprising: A secure enclave processor is coupled to the one or more processors and the memory, and the secure enclave processor is configured to generate the unique key.

5. The system of claim 1, wherein the object-level translation includes the translation of libraries used by the one or more application binaries during execution.

6. The system of claim 1, wherein the object-level translation includes the translation of plugins used by the one or more application binaries during execution.

7. The system of claim 1, wherein the cache management system service is configured to generate hash values ​​based on information associated with the one or more application binaries.

8. The system of claim 7, wherein the cache management system service stores the generated hash value in an associative array in the memory, and wherein the generated hash value is used to determine whether the one or more application binaries are available in the translation cache and to determine whether the one or more application binaries have been modified.

9. The system of claim 8, wherein when the one or more application binaries have been modified, the system is configured to: Remove the translation of the one or more application binaries from the translation cache; and Generate a new translation.

10. The system of claim 1, wherein the runtime code module is configured to determine whether the one or more application binaries corresponding to the execution translation have become writable, wherein when the one or more application binaries have become writable, the system is further configured to: Remove translations associated with the one or more application binaries from the global indirect branch table; Cancel the direct jump from the link stored in the translation cache to the translation that has been removed; This advances the global counter. Suspend the execution of the thread associated with the one or more application binaries; The thread associated with the one or more application binaries is forced to perform a just-in-time (JIT) translation of the one or more application binaries by the runtime code module; as well as Resume execution of the thread.

11. The system of claim 1, wherein if the one or more application binaries include self-modifying code, the system is configured to: Write-protect the pages in the memory where the one or more application binary files are stored; The write to the protected page is captured in the exception handler; Remove the translations associated with the one or more application binaries from the global indirection table in the processor; Cancel the direct jump from the link stored in the translation cache to the translation that has been removed; This advances the global counter. Request the thread associated with the self-modifying code to handle the invalid code; Perform JIT translation of the self-modifying code; The global counter value is recorded in the metadata associated with the translation; Update the executing thread to the new version of the global indirection branch table; Remove the removed translations from the return stack associated with the execution thread; The translation is inserted into the thread via a lookup of the global indirection branch table; as well as The translation is released when all threads reach the global counter value.

12. The system according to claim 1, wherein: The one or more processors are configured to execute instructions defined in a first instruction set architecture; and When the given translation is executed, it performs the same operations as the portions of the one or more application binaries.

13. The system of claim 12, wherein the cache management system service is configured as follows: In response to launching a given application binary from the one or more application binaries, the translation cache is checked for the corresponding translated code sequence, and Based on the detection of the corresponding translation in the translation cache, the corresponding translated code sequence is provided to the runtime code module.

14. The system of claim 12, wherein when the corresponding application binary is installed in the system, a first translation of the one or more translations in the translation cache is generated.

15. The system of claim 12, wherein when the corresponding application binary is initially launched in the system, a first translation of the one or more translations in the translation cache is generated.

16. A method for performing binary translation, comprising: A first application binary is launched for execution in the system, wherein the first application binary is written for a first execution environment, and one or more processors in the system are configured to execute the application binary in a second execution environment different from the first execution environment; Determining whether a sequence of translated code generated by a binary translator is stored in a translation cache in the system, wherein the binary translator includes a cache management system service that can execute in a first address space of the application binary and a runtime code module that can execute in a second address space of the application binary, wherein the first address space is a private address space and the second address space is a user address space, and wherein determining whether the sequence of translated code is stored in the translation cache is performed by the cache management system service; Based on the translated code sequence that is not cached in the translation cache, the runtime code module performs an on-the-fly translation of the first application binary file. as well as The translated code sequence in the translation cache is executed within the runtime code module based on the translated code sequence cached in the translation cache.

17. A system for performing binary translation, comprising: One or more processors, the one or more processors being configured to execute instructions defined in a first instruction set architecture; and A non-transitory computer-accessible storage medium coupled to the one or more processors, wherein the non-transitory computer-accessible storage medium stores: One or more application binaries having instructions defined in a second instruction set architecture that is different from the first instruction set architecture; A translation cache stores one or more translated code sequences corresponding to one or more portions of the one or more application binaries, wherein the one or more translated code sequences perform the same operations as the one or more portions of the one or more application binaries when executed; and A binary translator comprising a cache management system service executable in a first address space of the application binary and a runtime code module executable in a second address space of the application binary, wherein the first address space is separate from the second address space, wherein the cache management system service is configured to manage the translation cache, the management including handling calls to the translation cache, and wherein the runtime code module is configured to manage just-in-time (JIT) translation of the application binary for which there is no translated code sequence in the translation cache.

18. The system of claim 17, wherein the cache management system service is configured to: In response to launching a given application binary from the one or more application binaries, the translation cache is checked for the corresponding translated code sequence, and Based on the detection of the corresponding translated code sequence in the translation cache, the corresponding translated code sequence is provided to the runtime code module.

19. The system of claim 18, wherein the translation cache is checked based on a hash value generated based on the given application binary.

20. The system of claim 19, wherein if the given application binary has been modified after the corresponding translated code sequence was generated, the hash value is different from the previously generated hash value.

Images