Apparatus, method and computer program product for executing processor instructions in an extended set on a multi-core processor

Abstract

The present invention discloses an apparatus, method, and computer program for executing processor instructions in an extension set on a multi-core processor. At least some of the disclosed embodiments can utilize the processor's memory management device to map virtual memory addresses used by application code to physical memory addresses used by the computer system's hardware memory bus by mapping different executable code blocks to different running cores. Thus, for cores that support a given extension, a code block is provided that uses the supported extension in a simple and direct manner with very little overhead, while for cores that do not support a given extension, an alternative code block is provided that emulates the unsupported extension using more basic and / or fundamental instructions.

Description

Technical Field

[0001] The present invention relates to the field of computer hardware, and more particularly, to executing processor instructions in an extended set on a multi-core processor, as well as related devices, methods, and computer program products. Background Art

[0002] Today, computer systems often have processors that include multiple processor cores (e.g., logical cores). For example, a computer system can have any number of physical processors, including any number of logical processor cores that independently execute machine code. A processor core can retrieve processor instructions from memory for execution.

[0003] Generally, all processor cores support a common basic instruction set. However, in addition to the basic instructions, the processor instruction set may also include one or more extension sets, which may not be supported by all processor cores.

[0004] For example, on a symmetric multiprocessor system, a given execution stream (or thread) of a given running application can run on different processor cores at different times. Therefore, unless the application code is written to a common subset of extensions supported by all processor cores, a thread might run application code that requires an extension even if the processor core it is running on does not support that extension. This can result in undefined instruction exceptions or other undesirable behavior.

[0005] However, extensions supported by only a subset of processor cores can provide useful runtime services to applications, such as security enhancements or performance optimizations. Therefore, it is desirable to be able to execute code that depends on the extension on a multi-core processor even if only some cores support the instruction set extension.

[0006] One existing approach is to "pin" the execution flow to a core or set of cores known to support the extension. However, this reduces the flexibility of the operating system's scheduler component in selecting which execution flow to run on a given core at a given time. This also introduces security and / or safety limitations, as typical users or third-party applications do not have the necessary permissions to "pin" their own execution flow.

[0007] A variant of the pinning described above involves first pinning the execution flow to the current core, then checking the core capabilities and only using the extension if it is supported. Otherwise, a different extension is used. This has the same limitations and can be significantly slower when the runtime doesn't support the extension.

[0008] Another existing approach involves blindly using the extension even if the core doesn't support it. This is also known as "trap-and-emulate." This isn't generally applicable, but in certain specific circumstances, it will trigger an "undefined instruction" exception, which the operating system (OS) can catch. When the OS catches this exception, it can determine the failing instruction in the extension and emulate it using a different implementation. This is quite slow because it involves exception handling, which disrupts the optimal execution flow along the core's execution pipeline. Summary of the Invention

[0009] This summary is provided to introduce a selection of concepts in a simplified form that will be further described in the detailed description below. The purpose of this summary is to identify key features or essential features of the subject matter protected by the claims and is not intended to limit the scope of the subject matter protected by the claims.

[0010] An object of the present invention is to enable execution of an extended set of processor instructions on a multi-core processor. These and other objects are achieved by the features of the independent claims. Further implementations will be apparent from the dependent claims, the description, and the accompanying drawings.

[0011] According to a first aspect of the present invention, a memory management device for a processor is provided. The processor includes a first processor core capable of executing processor instructions in a first extension set and a second processor core incapable of executing the processor instructions in the first extension set. The memory management device is configured to obtain a processor instruction to be executed. The memory management device is further configured to access a translation table for a memory mapping of the processor instruction to be executed. The memory management device is further configured to apply a memory mapping to the processor instruction according to the translation table. The memory management device is configured to apply the memory mapping according to the translation table by branching a first processor instruction to a first code block in a first physical memory address set for execution, the first processor instruction being intended for the first processor core and included in the first extension set. The memory management device is further configured to apply the memory mapping according to the translation table by branching a second processor instruction to a second code block in a second physical memory address set for emulation, the second processor instruction being intended for the second processor core and included in the first extension set. The memory management device according to the first aspect of the present invention facilitates executing extension-dependent code on a multi-core processor, even when only some cores support the instruction set extension. The memory management device according to the first aspect of the present invention can dynamically and semi-transparently determine whether a running core supports a given extension. If the running core supports the extension, the extension can be used. If the running core does not support the extension, an alternative simulation code can be used. The memory management device according to the first aspect of the present invention generates very little overhead on the processor core that supports the extension, resulting in very good performance in this case. Even if the processor core does not support the extension, the memory management device according to the first aspect of the present invention still generates less overhead than methods such as capture and simulation. Unlike the capture and simulation method, the memory management device according to the first aspect of the present invention does not require the prerequisite that the extension instruction must trigger an undefined instruction exception. The memory management device according to the first aspect of the present invention also helps to avoid the safety, security and flexibility limitations associated with fixed methods.

[0012] In one implementation of the first aspect, the translation table includes the first set of physical memory addresses, including a first code block for executing processor instructions of the first processor core. The translation table also includes a second set of physical memory addresses, including a second code block for emulating processor instructions of the second processor core. The translation table also includes a third set of physical memory addresses, each of which includes a first branch instruction to a first virtual memory address in the first set of virtual memory addresses. The translation table also includes a fourth set of physical memory addresses, each of which includes a second branch instruction to a second virtual memory address in the second set of virtual memory addresses. This implementation can utilize the memory management device to map virtual memory addresses used by application code to physical memory addresses used by a hardware memory bus of the computer system by mapping different executable code blocks to different running cores. This allows cores that support a given extension to be provided with code blocks that use the supported extension in a simple manner (thus with very little overhead), while cores that do not support the given extension are provided with replacement code blocks that emulate the unsupported extension using more basic and / or fundamental instructions.

[0013] In one implementation of the first aspect, the translation table further includes a first set of virtual memory addresses, each virtual memory address being mapped to a first code block in the first code blocks for executing processor instructions in the first set of physical memory addresses. The translation table further includes a second set of virtual memory addresses, each virtual memory address being mapped to a second code block in the second code blocks for emulating processor instructions in the second set of physical memory addresses. The translation table further includes a third set of virtual memory addresses, each virtual memory address being mapped to a physical memory address in the third set of physical memory addresses of the first processor core and a physical memory address in the fourth set of physical memory addresses of the second processor core. This implementation can utilize the memory management device to map virtual memory addresses used by application code to physical memory addresses used by the computer system's hardware memory bus by mapping different executable code blocks to different running cores. This allows cores that support a given extension to be provided with code blocks that use the supported extension in a simple manner (thus with very little overhead), while cores that do not support the given extension are provided with alternative code blocks that emulate the unsupported extension using more basic and / or fundamental instructions.

[0014] In an implementation of the first aspect, the memory management device is further configured to branch the first processor instruction to a virtual memory address in the third virtual memory address set, thereby mapping the virtual memory address in the third virtual memory address set to a physical memory address in the third physical memory address set. The memory management device is further configured to branch the first processor instruction to a virtual memory address in the first virtual memory address set, thereby mapping the virtual memory address in the first virtual memory address set to a first code block in a physical memory address in the first physical memory address set for execution. The implementation helps to map different codes from different physical addresses to the same virtual address of different types of processors, thereby using the memory management device as a determiner between capable processors and incapable processors. Since the functionality of the memory management device has been heavily optimized, the execution time overhead of the determiner is very low.

[0015] In one implementation of the first aspect, the memory management device is further configured to branch the second processor instruction to a virtual memory address in the third virtual memory address set, thereby mapping the virtual memory address in the third virtual memory address set to a physical memory address in the fourth physical memory address set. The memory management device is further configured to branch the second processor instruction to a virtual memory address in the second virtual memory address set, thereby mapping the virtual memory address in the second virtual memory address set to a second code block in a physical memory address in the second physical memory address set for execution. The implementation helps to map different codes from different physical addresses to the same virtual address on different types of processors, thereby using the memory management device as a determiner between capable processors and incapable processors. Since the functionality of the memory management device has been heavily optimized, the execution time overhead of the determiner is very low.

[0016] In an implementation of the first aspect, a total size of the third set of physical memory addresses is equal to a total size of the fourth set of physical memory addresses. This implementation facilitates efficient execution of extension-dependent code on a multi-core processor even when only some cores support the instruction set extension.

[0017] In an implementation of the first aspect, the total size of the first virtual memory address set is equal to the total size of the first physical memory address set. This implementation helps to efficiently execute code that relies on the instruction set extension on a multi-core processor even if only some cores support the extension.

[0018] In an implementation of the first aspect, the total size of the second virtual memory address set is equal to the total size of the second virtual memory address set. This implementation helps to efficiently execute code that depends on the extension on a multi-core processor even if only some cores support the instruction set extension.

[0019] In an implementation of the first aspect, the second processor core disables the first virtual memory address set. This implementation helps to efficiently execute extension-dependent code on a multi-core processor even if only some cores support the instruction set extension.

[0020] According to a second aspect of the present invention, a processor is provided. The processor includes a first processor core capable of executing processor instructions in a first extension set. The processor also includes a second processor core that is not capable of executing the processor instructions in the first extension set. The processor also includes a memory management device according to the first aspect. The memory management device included in the processor according to the second aspect of the present invention facilitates execution of extension-dependent code on a multi-core processor, even when only some cores support the instruction set extension. The memory management device included in the processor according to the second aspect of the present invention can dynamically and semi-transparently determine whether a running core supports a given extension. If the running core supports the extension, the extension can be used. If the running core does not support the extension, alternative emulation code can be used. The memory management device included in the processor according to the second aspect of the present invention incurs very little overhead on processor cores that support the extension, thereby providing excellent performance in such situations. Even if the processor core does not support the extension, the memory management device according to the second aspect of the present invention still incurs less overhead than methods such as trap and emulation. Unlike trap and emulation methods, the memory management device included in the processor according to the second aspect of the present invention does not require that an extension instruction trigger an undefined instruction exception. The memory management device included in the processor according to the second aspect of the present invention also helps to avoid the safety, security and flexibility limitations associated with fixed methods.

[0021] According to a third aspect of the present invention, a memory management method for a processor is provided. The processor includes a first processor core capable of executing processor instructions in a first extension set and a second processor core incapable of executing the processor instructions in the first extension set. The method includes: a memory management device obtaining a processor instruction to be executed. The method also includes: the memory management device accessing a translation table for a memory mapping of the processor instruction to be executed. The method also includes: the memory management device applying a memory mapping to the processor instruction according to the translation table. Applying the memory mapping according to the translation table includes: branching the first processor instruction to a first code block in a first physical memory address set for execution, the first processor instruction being intended for the first processor core and included in the first extension set. Applying the memory mapping according to the translation table also includes: branching the second processor instruction to a second code block in a second physical memory address set for emulation, the second processor instruction being intended for the second processor core and included in the first extension set. The method according to the third aspect of the present invention facilitates executing extension-dependent code on a multi-core processor, even when only some cores support the instruction set extension. The method according to the third aspect of the present invention can dynamically and semi-transparently determine whether a running core supports a given extension. If the running core supports the extension, the extension can be used. If the running core does not support extensions, an alternative simulation code can be used. The method according to the third aspect of the present invention generates very little overhead on processor cores that support extensions, resulting in very good performance in this case. Even if the processor core does not support extensions, the method according to the third aspect of the present invention still generates less overhead than methods such as capture and simulation. Unlike the capture and simulation method, the method according to the third aspect of the present invention does not require the prerequisite that the extension instruction must trigger an undefined instruction exception. The method according to the third aspect of the present invention also helps to avoid the safety, security and flexibility limitations associated with fixed methods.

[0022] In one implementation of the third aspect, the translation table includes the first set of physical memory addresses, including a first code block for executing processor instructions of the first processor core. The translation table also includes a second set of physical memory addresses, including a second code block for emulating processor instructions of the second processor core. The translation table also includes a third set of physical memory addresses, each of which includes a first branch instruction to a first virtual memory address in the first set of virtual memory addresses. The translation table also includes a fourth set of physical memory addresses, each of which includes a second branch instruction to a second virtual memory address in the second set of virtual memory addresses. This implementation can utilize the memory management device to map virtual memory addresses used by application code to physical memory addresses used by the computer system's hardware memory bus by mapping different executable code blocks to different running cores. This allows cores that support a given extension to be provided with code blocks that use the supported extension in a simple manner (thus with very little overhead), while cores that do not support the given extension are provided with alternative code blocks that emulate the unsupported extension using more basic and / or fundamental instructions.

[0023] In one implementation of the third aspect, the translation table further includes a first set of virtual memory addresses, each virtual memory address being mapped to a first code block in the first code blocks for executing processor instructions in the first set of physical memory addresses. The translation table further includes a second set of virtual memory addresses, each virtual memory address being mapped to a second code block in the second code blocks for emulating processor instructions in the second set of physical memory addresses. The translation table further includes a third set of virtual memory addresses, each virtual memory address being mapped to a physical memory address in the third set of physical memory addresses of the first processor core and a physical memory address in the fourth set of physical memory addresses of the second processor core. This implementation can utilize the memory management device to map virtual memory addresses used by application code to physical memory addresses used by the computer system's hardware memory bus by mapping different executable code blocks to different running cores. This allows cores that support a given extension to be provided with code blocks that use the supported extension in a simple manner (thus with very little overhead), while cores that do not support the given extension are provided with alternative code blocks that emulate the unsupported extension using more basic and / or fundamental instructions.

[0024] In an implementation of the third aspect, the method further comprises: branching the first processor instruction to a virtual memory address in the third virtual memory address set, thereby mapping the virtual memory address in the third virtual memory address set to a physical memory address in the third physical memory address set. The method further comprises: branching the first processor instruction to a virtual memory address in the first virtual memory address set, thereby mapping the virtual memory address in the first virtual memory address set to a first code block in a physical memory address in the first physical memory address set for execution. The implementation helps to map different codes from different physical addresses to the same virtual address of different types of processors, thereby using a memory management device as a determiner between capable processors and incapable processors. Since the functionality of the memory management device has been heavily optimized, the execution time overhead of the determiner is very low.

[0025] In an implementation of the third aspect, the method further comprises: branching the second processor instruction to a virtual memory address in the third virtual memory address set, thereby mapping the virtual memory address in the third virtual memory address set to a physical memory address in the fourth physical memory address set. The method further comprises: branching the second processor instruction to a virtual memory address in the second virtual memory address set, thereby mapping the virtual memory address in the second virtual memory address set to a first code block in a physical memory address in the second physical memory address set for simulation. The implementation helps to map different codes from different physical addresses on the same virtual address of different types of processors, thereby using the memory management device as a determiner between capable processors and incapable processors. Since the functionality of the memory management device has been heavily optimized, the execution time overhead of the determiner is very low.

[0026] In an implementation of the third aspect, a total size of the third set of physical memory addresses is equal to a total size of the fourth set of physical memory addresses. This implementation facilitates efficient execution of extension-dependent code on a multi-core processor even when only some cores support the instruction set extension.

[0027] In an implementation of the third aspect, the total size of the first virtual memory address set is equal to the total size of the first physical memory address set. This implementation helps to efficiently execute code that relies on the instruction set extension on a multi-core processor even if only some cores support the extension.

[0028] In an implementation of the third aspect, the total size of the second virtual memory address set is equal to the total size of the second virtual memory address set. This implementation helps to efficiently execute code that depends on the extension on a multi-core processor even if only some cores support the instruction set extension.

[0029] In an implementation of the third aspect, the second processor core disables the first virtual memory address set. This implementation helps to efficiently execute extension-dependent code on a multi-core processor even if only some cores support the instruction set extension.

[0030] According to a fourth aspect of the present invention, a computer program is provided. The computer program includes program code that, when executed on a computer, is configured to perform the method according to the third aspect. The computer program according to the fourth aspect of the present invention facilitates execution of extension-dependent code on a multi-core processor, even when only some cores support the instruction set extension. The computer program according to the fourth aspect of the present invention can dynamically and semi-transparently determine whether a running core supports a given extension. If the running core supports the extension, the extension can be used. If the running core does not support the extension, alternative emulation code can be used. The computer program according to the fourth aspect of the present invention incurs very little overhead on processor cores that support the extension, resulting in superior performance in such situations. Even if the processor core does not support the extension, the computer program according to the fourth aspect of the present invention still incurs less overhead than methods such as trap and emulate. Unlike trap and emulate methods, the computer program according to the fourth aspect of the present invention does not require the prerequisite that the extension instruction must trigger an undefined instruction exception. The computer program according to the fourth aspect of the present invention also helps avoid the safety, security, and flexibility limitations associated with fixed methods.

[0031] Many features will become more apparent and thus better understood with reference to the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Exemplary embodiments will be described in detail below with reference to the following drawings, in which:

[0033] Figure 1 block diagrams for processors and memory management devices;

[0034] Figure 2 A flowchart of a method provided in accordance with an embodiment of the present invention;

[0035] Figure 3 A diagram of a memory map provided for an exemplary embodiment.

[0036] In the following, identical reference signs refer to identical or at least functionally equivalent features. DETAILED DESCRIPTION

[0037] In the following description, reference is made to the accompanying drawings, which form a part of the present invention and show, by way of illustration, specific aspects to which the present invention may be applied. It will be understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present invention. Therefore, the following detailed description should not be construed in a restrictive sense, as the scope of the present invention is defined by the appended claims.

[0038] It will be understood that the disclosures relating to the described methods also apply to the corresponding devices or systems for performing the methods, and vice versa. For example, if specific method steps are described, the corresponding devices may include units for performing the described method steps, even if such units are not explicitly described or shown in the accompanying drawings. On the other hand, for example, if a specific device or apparatus is described based on functional units, the corresponding method may include steps for performing the described functions, even if such steps are not explicitly described or shown in the accompanying drawings. In addition, it will be understood that, unless otherwise expressly stated, the features of the various exemplary aspects described herein may be combined with each other.

[0039] In the following, a general description of a memory management unit (MMU) is provided.

[0040] For example, today's application processors are designed to support virtual memory systems. Software executing on the processor only sees virtual addresses, which the processor translates into physical addresses. These physical addresses are presented to the memory system and point to actual physical locations in memory.

[0041] Virtual addresses are translated into physical addresses through a mapping. The mapping between virtual and physical addresses can be stored, for example, in a translation table (also called a page table). The translation table can be stored in memory and managed by appropriate software such as an OS kernel or a hypervisor.

[0042] The memory management unit can perform the translation. For example, the MMU can include a table walk unit that includes logic to read the translation table from memory. The MMU can also include one or more translation lookaside buffers (TLBs) that cache recently used translations.

[0043] Memory addresses issued by software are typically virtual. These memory addresses are passed to the MMU, which may check for recently used cached translations in the TLB. If the MMU cannot find a recently cached translation, the table walk unit can read the appropriate table entry or entries from memory. Before a memory access occurs, the virtual address is translated into a physical address because it is necessary to know the physical memory location being accessed.

[0044] As will be discussed in more detail below, aspects of the present invention provide a mechanism for executing processor instructions at minimal performance cost when a computer system has multiple processor cores and some, but not all, of the cores are capable of executing the instructions. This is accomplished by utilizing a memory management facility to dynamically and semi-transparently determine whether a running core supports a given extension. If the running core supports the extension, the extension can be used. If the running core does not support the extension, an alternative emulation code can be used.

[0045] In other words, at least some of the disclosed embodiments may utilize the memory management device to map the virtual memory addresses used by the application code to the physical memory addresses used by the hardware memory bus of the computer system by mapping different executable code blocks to different running cores, so that for cores that support a given extension, a code block that uses the supported extension in a simple manner (and therefore has very little overhead) is provided, and for cores that do not support the given extension, a replacement code block that uses more basic and / or fundamental instructions to emulate the unsupported extension is provided.

[0046] Next, combine Figure 1 Exemplary embodiments of the processor 100 and the memory management device 130 of the processor 100 are described. Some of the features of the described devices are optional features that provide other advantages.

[0047] Figure 1 is a block diagram of the processor 100 and the memory management device 130. In addition, Figure 1 A memory 150 and a bus 150 connecting the processor 100 and the memory 150 are shown.

[0048] Processor 100 includes a first processor core 110 capable of executing processor instructions in a first extended set. Processor 100 also includes a second processor core 120 that cannot execute processor instructions in the first extended set. For example, first processor core 110 and / or second processor core 120 may be logical processor cores.

[0049] In other words, the processor instruction set includes a common base instruction set supported by all processor cores. In addition to the base instruction set, the processor instruction set also includes at least one extension set, which is not supported by all processor cores.

[0050] Processor instructions may include, for example, one or more of the following: data processing and memory operations (e.g., setting a register to a fixed constant value, copying data from a memory location to a register or from a register to a memory location, reading and writing data from a hardware device), arithmetic and logical operations (e.g., adding, subtracting, multiplying, or dividing the values ​​of two registers, performing bitwise operations (e.g., taking the conjunction or disjunction of corresponding bits in a pair of registers), comparing two values ​​in registers, floating-point instructions for floating-point arithmetic), control flow operations (e.g., branching to another location in the program and executing instructions there, conditionally branching to another location if a condition holds, indirectly branching to another location, calling another block of code while saving the location of the next instruction as a point to return to), coprocessor instructions (e.g., loading / storing data in a coprocessor, performing coprocessor operations), transferring multiple registers between memories at once, moving large blocks of memory, complex integer and floating-point arithmetic (e.g., square root or transcendental functions such as logarithms, sine, cosine, etc.), single instruction multiple data (SIMD). data, SIMD) instructions (a single instruction that operates on many homogeneous values ​​in parallel), atomic test-and-set instructions or other read-modify-write atomic instructions, and / or performing arithmetic logic unit (ALU) operations using operands from memory rather than registers.

[0051] It should be understood that although Figure 1 In the example disclosed in , two processor cores and an extended set of processor instructions are disclosed, but the number of processor cores and / or extended sets can be greater.

[0052] The processor 100 may include, for example, one or more of various processing devices, such as an application processor, a coprocessor, a microprocessor, a controller, a digital signal processor (DSP), a processing circuit with or without a DSP, or various other processing devices including integrated circuits, such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microcontroller unit (MCU), a hardware accelerator, a dedicated computer chip, etc. The processor 100 may be included in a symmetric multi-processing system and / or a single instruction, multiple data (SIMD) system.

[0053] In one example, the processor 100 may include an Advanced RISC Machine (ARM) processor. In this example, the base instruction set may include an instruction set such as ARMv8 64-bit (AArch64), and the extensions may include ARMv8.3-PAuth (Pointer Authentication), ARMv8.5-BTI (Branch Target Indicator), and / or ARMv8-5-MTE (Memory Tagging) extensions.

[0054] Memory 140 can be used to store computer programs, etc. Memory 140 can include one or more volatile memory devices, one or more non-volatile memory devices, and / or a combination of one or more volatile and non-volatile memory devices. For example, memory 140 can be implemented as a semiconductor memory (e.g., mask ROM, programmable ROM (PROM), erasable PROM (EPROM), flash ROM, random access memory (RAM), etc.).

[0055] The processor 100 also includes a memory management device 130, such as a memory management unit (MMU). The memory management device 130 may be controlled or operated by a software component, such as an operating system (OS) kernel or a hypervisor. Here, the operating system may include Linux, etc.

[0056] The memory management device 130 is configured to obtain a processor instruction to be executed. The processor instruction to be executed may include, for example, one of the examples discussed above. The memory management device 130 is also configured to access a translation table for a memory mapping of the processor instruction to be executed. The translation table may be stored in a memory such as the memory 140. The memory management device 130 is also configured to apply the memory mapping to the processor instruction based on the translation table. In other words, the translation table is configured to store a mapping of virtual addresses to physical addresses.

[0057] The memory management device 130 is configured to apply memory mapping according to the translation table by branching a first processor instruction to a first code block (or code sequence) in a first physical memory address set for execution. The first processor instruction is for the first processor core 110 and is included in a first extension set.

[0058] Figure 3A diagram 300 of a memory map is provided for an exemplary embodiment. Diagram 300 shows virtual memory 301 with extensions, physical memory 302, and virtual memory 303 without extensions. Diagram 300 shows four sets of physical memory addresses to be allocated by the system software component responsible for the MMU 130. In practice, this could be, for example, an operating system (e.g., Linux) kernel using the first stage of MMU address translation. Alternatively, it could be, for example, a hypervisor using the second stage of MMU address translation. In diagram 300, the four sets of physical memory addresses include set PC1, which includes code block C1 for a core with extensions. That is, in Figure 3 In the example of , the set PC1 represents the first physical memory address set, and the code block C1 represents the first code block for execution.

[0059] The memory management device 130 is further configured to apply memory mapping according to the translation table by branching the second processor instruction to a second code block (or code sequence) in the second physical memory address set for simulation. The second processor instruction is for the second processor core 120 and is included in the first extension set. Continuing with the above example, in Figure 300, the four physical memory address sets also include set PC2, which includes code block C2 for a core without extensions. That is, in Figure 3 In the example, set PC2 represents a second physical memory address set, and code block C2 represents a second code block for simulation.

[0060] The branching of the first processor instruction and the branching of the second processor instruction are described in more detail below according to exemplary embodiments.

[0061] As discussed above, the translation table may include a first set of physical memory addresses including a first code block for executing processor instructions for the first processor core 110. The translation table may also include a second set of physical memory addresses including a second code block for emulating processor instructions for the second processor core 120.

[0062] The translation table may also include a third set of physical memory addresses, each of which includes a first branch instruction to a first virtual memory address in the first set of virtual memory addresses. Continuing with the above example, in diagram 300, the four sets of physical memory addresses also include a set PD1, which includes dispatch (branch) instructions, each of which branches to a virtual address of a given code block in a set VC1 (described below). That is, in Figure 3 In the example, set PD1 represents the third physical memory address set.

[0063] The translation table may also include a fourth set of physical memory addresses, each of which includes a second branch instruction to a second virtual memory address in the second set of virtual memory addresses. Continuing with the above example, in diagram 300, the four sets of physical memory addresses also include a set PD2, which includes dispatch instructions, each of which branches to a virtual address of a given code block in a set VC2 (described below). That is, in Figure 3 In the example of FIG300 , set PD2 represents the fourth set of physical memory addresses. In one embodiment, the total size of the third set of physical memory addresses is equal to the total size of the fourth set of physical memory addresses. In FIG300 , the total size of set PD2 is the same as the total size of set PD1.

[0064] The translation table may also include a first set of virtual memory addresses, each virtual memory address being mapped to a first code block in a first code block for executing processor instructions in a first set of physical memory addresses. In one embodiment, the total size of the first set of virtual memory addresses is equal to the total size of the first set of physical memory addresses. In one embodiment, the first set of virtual memory addresses is disabled for the second processor core 120 (e.g., unmapped, invalid, or without memory access rights). In other words, in this embodiment, the first set of virtual memory addresses is enabled only for the first processor core 110. Continuing with the above example, in Figure 300, three sets of virtual memory addresses (VAs) are provided to map memory allocations. The memory management device 130 may be used to map the set VC1 to PC1 memory. That is, in Figure 3 In the example shown in FIG, set VC1 represents the first virtual memory address set. Set VC1 has the same total size as set PC1. Set VC1 is mapped only on cores with the extension. On other cores, the VA range corresponding to set VC1 is not mapped / invalid or has no memory access rights.

[0065] The translation table may also include a second set of virtual memory addresses, each virtual memory address being mapped to a second code block in a second code block for emulating a processor instruction in a second set of physical memory addresses. In one embodiment, the total size of the second set of virtual memory addresses is equal to the total size of the second set of physical memory addresses. In one embodiment, the second set of virtual memory addresses is enabled for the second processor core 120 and is enabled or disabled for the first processor core 110. Continuing with the above example, in FIG300, the memory management device 130 may be configured to map the set VC2 to the PC2 memory. That is, in Figure 3 In the example, set VC2 represents the second set of virtual memory addresses. Set VC2 has the same total size as set PC2. Set VC2 is mapped on a core without extensions. Set VC2 may or may not be mapped on a core with extensions.

[0066] The translation table may further include a third set of virtual memory addresses, each virtual memory address being mapped to a physical memory address in a third physical memory address set of the first processor core 110 and a physical memory address in a fourth physical memory address set of the second processor core 120. In one embodiment, the total size of the third set of virtual memory addresses is equal to the total size of the third set of physical memory addresses (and is also equal to the total size of the fourth set of physical memory addresses). Continuing with the above example, in FIG300, the memory management device 130 may be used to map the set VD to the set PD1 and also to the set PD2. On a core with extensions, the memory management device 130 may be used to map the set VD to the set PD1. On a core without extensions, the memory management device 130 may be used to map the set VD to the set PD2. That is, on Figure 3 In the example of , set VD represents a third set of virtual memory addresses. Set VD has the same total size as set PD1 (and also has the same total size as set PD2).

[0067] The memory management device 130 may also be configured to branch the first processor instruction to a virtual memory address in a third set of virtual memory addresses, thereby mapping the virtual memory address in the third set of virtual memory addresses to a physical memory address in a third set of physical memory addresses. The memory management device 130 may also be configured to branch the first processor instruction from the physical memory address in the third set of physical memory addresses to a virtual memory address in the first set of virtual memory addresses, thereby mapping the virtual memory address in the first set of virtual memory addresses to a first code block in a physical memory address in the first set of physical memory addresses for execution.

[0068] In other words, continue Figure 3 For example, when native executable application code intends to call an instruction from an extension, it can execute a branch to a VA within the VD range instead of calling the inline instruction directly in the machine code. For each instruction in the extension (at least the instructions required for application use), there can be one branch instruction in set PD1 and one in set PD2.

[0069] The memory management device 130 may also be configured to branch the second processor instruction to a virtual memory address in a third virtual memory address set, thereby mapping the virtual memory address in the third virtual memory address set to a physical memory address in a fourth physical memory address set. The memory management device 130 may also be configured to branch the second processor instruction from the physical memory address in the fourth physical memory address set to a virtual memory address in the second virtual memory address set, thereby mapping the virtual memory address in the second virtual memory address set to a physical memory address in the second physical memory address set for simulation. Figure 3As shown in the example of , the branch instruction in the set PD2 can also branch to the code block in the set PC2 (mapped in the VC2 range), which can simulate the original instruction.

[0070] The replacement of the original instruction to the branch may be done manually, for example by an application developer (or, for example, a developer of a software library used by the application), or automatically, for example by a compiler of the programming language in which the application is written.

[0071] If an application's execution flow runs code on a core that supports the extension, it might, at some point in the execution flow, run on a VA in the VC1 range. If, at that exact moment, execution flow is migrated to another core that doesn't support the extension, the application might encounter a faulting instruction. This is because the VC1 range is invalid on the new core. In this case, the system software component responsible for the MMU (such as the OS kernel or hypervisor) can detect this situation based on the VA of the faulting instruction. Using this VA, it can infer which instruction was attempted to execute and fix the fault by moving execution flow to the corresponding VA in set VC2.

[0072] The following describes another example that includes an instruction set extension that adds an instruction for calculating the average of two unsigned integers: UADDH (Unsigned Add Half). In this example, the average of core registers r1 and r2 is calculated and the result is stored in core register r0.

[0073] On a processor core that supports UADDH, the code block C1 for “UADDH r0, r1, r2” might look like this:

[0074] VC1_UADDH_R0_R1_R2:

[0075] UADDH r0, r1, r2

[0076] RETURN

[0077] On a processor core that does not support UADDH, code block C2 can be:

[0078] VC2_UADDH_R0_R1_R2:

[0079] PUSH r3

[0080] PUSH r4

[0081] AND r0, r1, #1

[0082] AND r0, r0, r2

[0083] LOGICAL-SHIFT-RIGHT r3, r1, #1

[0084] LOGICAL-SHIFT-RIGHT r4, r2, #1

[0085] ADD r0, r0, r3

[0086] ADD r0, r0, r4

[0087] POP r4

[0088] POP r3

[0089] RETURN

[0090] The compiler can replace occurrences of UADDH r0, r1, r2 with function call instructions to the corresponding dispatch branches in VD / PD1 / PD2:

[0091] CALL [VD_UADDH_R0_R1_R2]

[0092] The address of the dispatch branch in VD, on processor cores that support the extension:

[0093] VD_UADDH_R0_R1_R2:

[0094] JUMP VC1_UADDH_R0_R1_R2

[0095] On processor cores that do not support the extension:

[0096] VD_UADDR_R0_R1_R2:

[0097] JUMP VC2_UADDH_R0_R1_R2

[0098] Thus, when the code runs and reaches a CALL instruction (instead of UADDH), execution flow can first transfer to [VD_UADDH_R0_R1_R2]. Therefore, if the execution core supports the extension, a JUMP instruction can further transfer execution flow to VC1_UADDH_R0_R1_R2, execute the UADDH instruction, and then return (RETURN) flow after the initial CALL. Conversely, if the execution core does not support the extension, a JUMP instruction can transfer execution flow to VC2_UADDH_R0_R1_R2, execute the UADDH replacement code, and then return (RETURN).

[0099] If the execution flow is interrupted and migrates from a supporting core to a non-supporting core while executing a UADDH or RETURN instruction from within C1, a fault may be triggered. The system can then detect that the fault is within a VC1_UADDH_R0_R1_R2 block, change the program counter to VC2_UADDH_R0_R1_R2, and resume execution, thus hiding the fault from the application.

[0100] Figure 2 1 is a block diagram of a method 200 for memory management of a processor 100 provided in an embodiment. As discussed in more detail above, the processor 100 includes a first processor core 110 capable of executing processor instructions in a first extension set and a second processor core 120 not capable of executing processor instructions in the first extension set.

[0101] In operation 202 , the memory management device 130 of the processor 100 obtains a processor instruction to be executed.

[0102] In operation 204 , the memory management device 130 accesses a translation table for a memory map of the processor instruction to be executed.

[0103] In operation 206, the memory management device 130 applies a memory map to the processor instruction according to the translation table. Applying the memory map according to the translation table includes branching a first processor instruction to a first code block in a first set of physical memory addresses for execution. The first processor instruction is for the first processor core 110 and is included in the first extension set. Applying the memory map according to the translation table also includes branching a second processor instruction to a second code block in a second set of physical memory addresses for emulation. The second processor instruction is for the second processor core 120 and is included in the first extension set.

[0104] The method 200 and its operations 202 to 206 may be performed by the memory management device 130. Other features of the method 200 result directly from the functions and parameters of the memory management device 130 and are therefore not repeated here. The method 200 may be performed by a computer program.

[0105] The functions described herein may be performed at least in part by one or more computer program product components (e.g., software components). Alternatively or in addition, the functions described herein may be performed at least in part by one or more hardware logic components. For example, but not limited to, illustrative types of usable hardware logic components include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SOCs), complex programmable logic devices (CPLDs), and graphics processors (and graphics processing units, GPUs).

[0106] Any range or device value given herein may be extended or modified without losing the desired effect. In addition, any embodiment may be combined with another embodiment unless expressly prohibited.

[0107] Although the subject matter has been described in language specific to structural features and / or acts, it should be understood that the subject matter defined in the claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as examples of implementing the claims, and other equivalent features and acts are intended to fall within the scope of the claims.

[0108] It should be understood that the benefits and advantages described above may relate to one embodiment or to several embodiments. The embodiments described are not limited to those that solve any or all of the stated problems or have any or all of the stated benefits and advantages. It should be further understood that reference to "an" item may refer to one or more of these items.

[0109] The steps of the methods described herein may be performed in any suitable order, or simultaneously where appropriate. In addition, individual blocks may be deleted from any method without departing from the spirit and scope of the subject matter described herein. Aspects of any of the above-described embodiments may be combined with aspects of any other embodiment described to form further embodiments without losing the desired effect.

[0110] As used herein, the term "comprising" means including the identified methods, blocks, or elements, but such blocks or elements do not comprise an exclusive list and the method or apparatus may include other blocks or elements.

[0111] It should be understood that the above description is given by way of example only and that various modifications may be made by those skilled in the art. The above description, examples, and data provide a complete description of the structure and use of the exemplary embodiments. Although various embodiments have been described above with a certain degree of particularity or with reference to one or more individual embodiments, those skilled in the art may make various changes to the disclosed embodiments without departing from the scope of this specification.

Claims

1. A memory management device (130) for a processor (100), characterized in that The processor (100) includes a first processor core (110) capable of executing processor instructions in a first extension set and a second processor core (120) incapable of executing the processor instructions in the first extension set, and the memory management device (130) is configured to: Get the processor instructions to be executed; accessing a memory-mapped translation table for the processor instruction to be executed; applying a memory map to the processor instruction according to the translation table, The memory management device (130) is used to apply the memory mapping according to the conversion table in the following manner: Branching a first processor instruction to a first code block in a first physical memory address set for execution, wherein the first processor instruction is for the first processor core (110) and is included in the first extension set, and the first code block is a code block of the core with the extension; Branching a second processor instruction to a second code block in a second physical memory address set for simulation, wherein the second processor instruction is for the second processor core (120) and is included in the first extension set, and the second code block is a code block of a core without extensions; The conversion table includes: a third set of physical memory addresses, each physical memory address comprising a first branch instruction to a first virtual memory address in the first set of virtual memory addresses; and said first set of virtual memory addresses, each virtual memory address mapping to a first code block in said first code blocks for executing processor instructions in said first set of physical memory addresses; a fourth set of physical memory addresses, each physical memory address comprising a second branch instruction to a second virtual memory address in the second set of virtual memory addresses; and a second set of second virtual memory addresses, each virtual memory address mapping to a second code block in the second code blocks for emulating processor instructions in the second set of physical memory addresses. A third virtual memory address set, each virtual memory address is mapped to a physical memory address in the third physical memory address set of the first processor core and a physical memory address in the fourth physical memory address set of the second processor core.

2. The memory management device (130) according to claim 1, characterized in that The conversion table includes: The first set of physical memory addresses includes a first code block for executing processor instructions of the first processor core (110); The second set of physical memory addresses includes a second code block for emulating processor instructions of the second processor core (120).

3. The memory management device (130) according to claim 2, characterized in that The memory management device (130) is further configured to: branching the first processor instruction to a virtual memory address in the third set of virtual memory addresses, thereby mapping the virtual memory address in the third set of virtual memory addresses to a physical memory address in the third set of physical memory addresses; The first processor instruction is branched to a virtual memory address in the first set of virtual memory addresses, thereby mapping the virtual memory address in the first set of virtual memory addresses to a first code block in a physical memory address in the first set of physical memory addresses for execution.

4. The memory management device (130) according to claim 2, characterized in that The memory management device (130) is further configured to: branching the second processor instruction to a virtual memory address in the third set of virtual memory addresses, thereby mapping the virtual memory address in the third set of virtual memory addresses to a physical memory address in the fourth set of physical memory addresses; The second processor instruction branches to a virtual memory address in the second set of virtual memory addresses, thereby mapping the virtual memory address in the second set of virtual memory addresses to a first code block in a physical memory address in the second set of physical memory addresses for simulation.

5. The memory management device (130) according to claim 3, characterized in that The memory management device (130) is further configured to: branching the second processor instruction to a virtual memory address in the third set of virtual memory addresses, thereby mapping the virtual memory address in the third set of virtual memory addresses to a physical memory address in the fourth set of physical memory addresses; The second processor instruction branches to a virtual memory address in the second set of virtual memory addresses, thereby mapping the virtual memory address in the second set of virtual memory addresses to a first code block in a physical memory address in the second set of physical memory addresses for simulation.

6. The memory management device (130) according to any one of claims 2 to 5, characterized in that The total size of the third physical memory address set is equal to the total size of the fourth physical memory address set.

7. The memory management device (130) according to any one of claims 2 to 5, characterized in that: The total size of the first virtual memory address set is equal to the total size of the first physical memory address set.

8. The memory management device (130) according to any one of claims 2 to 5, characterized in that: The total size of the second virtual memory address set is equal to the total size of the second physical memory address set.

9. The memory management device (130) according to any one of claims 2 to 5, characterized in that: The first set of virtual memory addresses is disabled for the second processor core (120).

10. The memory management device (130) according to claim 6, characterized in that The total size of the first virtual memory address set is equal to the total size of the first physical memory address set.

11. The memory management device (130) according to claim 7, characterized in that The total size of the second virtual memory address set is equal to the total size of the second physical memory address set.

12. The memory management device (130) according to claim 8, characterized in that The first set of virtual memory addresses is disabled for the second processor core (120).

13. A processor (100), characterized in that include: A first processor core (110) capable of executing processor instructions in a first extended set; A second processor core (120) is unable to execute the processor instructions in the first extension set; A memory management device (130) according to any one of claims 1 to 12.

14. A method (200) for memory management of a processor, characterized in that The processor comprises a first processor core capable of executing processor instructions in a first extension set and a second processor core incapable of executing the processor instructions in the first extension set, and the method (200) comprises: The memory management device obtains (202) a processor instruction to be executed; The memory management device accesses (204) a translation table for a memory map of the processor instruction to be executed; The memory management device applies (206) a memory mapping to the processor instruction according to the translation table, Wherein, applying (206) the memory mapping according to the conversion table comprises: branching a first processor instruction to a first code block in a first physical memory address set for execution, wherein the first processor instruction is for the first processor core and is included in the first extension set, and the first code block is a code block of the core with the extension; Simulate a second processor instruction branch to a second code block in a second physical memory address set, wherein the second processor instruction is for the second processor core and is included in the first extension set, and the second code block is a code block of a core without extensions; The conversion table includes: a third set of physical memory addresses, each physical memory address comprising a first branch instruction to a first virtual memory address in the first set of virtual memory addresses; and said first set of virtual memory addresses, each virtual memory address mapping to a first code block in said first code blocks for executing processor instructions in said first set of physical memory addresses; a fourth set of physical memory addresses, each physical memory address comprising a second branch instruction to a second virtual memory address in the second set of virtual memory addresses; and a second set of second virtual memory addresses, each virtual memory address mapping to a second code block in the second code blocks for emulating processor instructions in the second set of physical memory addresses. A third virtual memory address set, each virtual memory address is mapped to a physical memory address in the third physical memory address set of the first processor core and a physical memory address in the fourth physical memory address set of the second processor core.

15. The method (200) according to claim 14, characterized in that The conversion table includes: The first set of physical memory addresses includes a first code block for executing processor instructions of the first processor core; The second physical memory address set includes a second code block for simulating processor instructions of the second processor core.

16. The method (200) according to claim 15, characterized in that Also includes: branching the first processor instruction to a virtual memory address in the third set of virtual memory addresses, thereby mapping the virtual memory address in the third set of virtual memory addresses to a physical memory address in the third set of physical memory addresses; The first processor instruction is branched to a virtual memory address in the first set of virtual memory addresses, thereby mapping the virtual memory address in the first set of virtual memory addresses to a first code block in a physical memory address in the first set of physical memory addresses for execution.

17. The method (200) according to claim 15 or 16, characterized in that Also includes: branching the second processor instruction to a virtual memory address in the third set of virtual memory addresses, thereby mapping the virtual memory address in the third set of virtual memory addresses to a physical memory address in the fourth set of physical memory addresses; The second processor instruction branches to a virtual memory address in the second set of virtual memory addresses, thereby mapping the virtual memory address in the second set of virtual memory addresses to a first code block in a physical memory address in the second set of physical memory addresses for simulation.

18. A computer program product, characterized in that The computer program product comprises a computer program or instructions which, when executed in a computer, perform the method according to any one of claims 14 to 17 .

Images