Method and system for executing an add instruction

Abstract

The present application provides a method and system for executing a new instruction. The method is used in a processor and includes receiving an instruction. When the received instruction is an unknown instruction, an unknown instruction exception is issued. In response to the unknown instruction exception, a conversion program is used to determine whether the received instruction is a new instruction, convert the received instruction into at least one old instruction when the received instruction is a new instruction, and execute the at least one old instruction in the same execution mode as the received instruction. Thus, the new instruction can be executed without changing the hardware architecture of the previous generation of processing cores.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of microelectronics, and in particular, to a method and system for executing new instructions. BACKGROUND

[0002] Processor technology has been rapidly developed in recent years. With the enhancement of processor functions, the next generation of processors often add new instructions on the basis of the previous generation of processors. Since the previous generation of processors cannot execute the new instructions supported by the next generation of processors, when the current generation of processors execute the new instructions, an unknown instruction exception (#UD) is generated, which causes the process containing the new instructions to be terminated by the operating system. Thus, the application program or operating system containing the new instructions cannot be executed on the previous generation of processors.

[0003] Therefore, a method and system for executing new instructions are needed to achieve the purpose of executing new instructions on the previous generation of processors. SUMMARY

[0004] The following disclosure is merely exemplary in nature and is not intended to limit the disclosure in any way. Furthermore, there is no intention to limit the application to the illustrative embodiments described and illustrated herein. Additionally, this Summary is intended to provide an overview of the disclosure and is not intended to provide an exclusive or exhaustive list of features, embodiments, or aspects of the disclosure. Accordingly, it will be apparent to one of ordinary skill in the art that other aspects, embodiments, and features can be added to the disclosure without departing from the spirit and scope of the disclosure. That is, it will be understood that various aspects, embodiments, and features of the disclosure can be combined with each other in any way. Thus, the following disclosure is intended to be illustrative, but not limiting, of the scope of the disclosure, which is set forth with particularity in the claims that follow.

[0005] Therefore, the main purpose of the present application is to provide a method and system for executing new instructions, so as to achieve the purpose of executing new instructions without changing the hardware architecture of the previous generation of processing cores.

[0006] The present application provides a method for executing new instructions, comprising: receiving an instruction, and issuing an unknown instruction exception when the received instruction is an unknown instruction. In response to the unknown instruction exception, through a conversion program: determining whether the received instruction is a new instruction; when the received instruction is a new instruction, converting the received instruction into at least one old instruction; and executing the at least one old instruction in the same execution mode as the received instruction.

[0007] The present application provides a system for executing a new instruction, comprising: a command decoder unit (decoder) receiving a command and determining whether the received command is an unknown command; a command submission unit issuing an unknown command exception when the received command is an unknown command; and a conversion program for converting the received command into at least one old command when the received command is a new instruction in response to the unknown command exception, wherein the system for executing a new instruction executes the at least one old command in the same execution mode as the received command.

[0008] The method and system for executing a new instruction provided by the present application can execute a new instruction on a previous generation processor without modifying the hardware architecture of the processing core. BRIEF DESCRIPTION OF DRAWINGS

[0009] Figure 1 FIG. 1 is a schematic diagram showing a system for executing a new instruction according to a first embodiment of the present application.

[0010] Figure 2 FIG. 2 is a structural diagram of a processor according to the first embodiment of the present application.

[0011] Figure 3 FIG. 3 is a flowchart showing a process for executing a new instruction according to the first embodiment of the present application.

[0012] Figure 4 FIG. 4 is a flowchart showing a process for processing a received command according to the first embodiment of the present application.

[0013] Figure 5 FIG. 5 is a flowchart showing a process for entering a system management mode according to the first embodiment of the present application.

[0014] Figure 6 FIG. 6 is a flowchart showing a process for an emulator according to the first embodiment of the present application.

[0015] Figure 7 FIG. 7 is a flowchart showing a process for a conversion program according to the first embodiment of the present application.

[0016] Figure 8 FIG. 8 is an example showing a process for processing an unknown command in a system management mode according to the first embodiment of the present application.

[0017] Figures 9A-9B FIG. 9 is a flowchart showing a process for exiting a system management mode according to the first embodiment of the present application.

[0018] Figure 10is a schematic diagram showing a system for executing a new instruction according to a second embodiment of the present application.

[0019] Figure 11 is a block diagram of a processor according to the second embodiment of the present application.

[0020] Figure 12 is a flowchart showing a process for executing a new instruction according to the second embodiment of the present application.

[0021] Figure 13 is a flowchart showing a process for handling a received instruction according to the second embodiment of the present application.

[0022] Figure 14 is a flowchart showing a process for handling a received instruction in a microcode for handling an unknown instruction exception according to the second embodiment of the present application.

[0023] Figures 15A-15B is a schematic diagram showing a system for executing a new instruction according to a third embodiment of the present application.

[0024] Figure 16 is a flowchart showing a process for handling a received instruction according to the third embodiment of the present application.

[0025] Figure 17 is a schematic diagram showing a system for executing a new instruction according to a fourth embodiment of the present application.

[0026] Figure 18 is a flowchart showing a process for executing a new instruction according to an embodiment of the present application.

[0027] Figure 19 is a flowchart showing a process for executing a new instruction according to an embodiment of the present application.

[0028] Figure 20 is a flowchart showing a process for converting a new instruction according to an embodiment of the present application.

[0029] Figure 21 is a schematic diagram showing an exemplary operating environment for implementing embodiments of the present application.

[0030] Brief descriptions of the symbols in the drawings are as follows:

[0031] 100: system for executing new instructions; 110: processor; 112: interrupt pre-processing unit; 114: system management mode exit / entry; 1142: system management mode entry; 1144: system management mode exit; 120: operating system; 130: application program; 118: instruction; 132: unknown instruction; 142: emulator; 145: translation program; 200: processor; 201: instruction bypass translation buffer; 202: instruction cache; 203: branch predictor; 230: instruction decode unit; 204: rename unit; 205: reservation station; 206: execution unit; 207: memory access unit; 220: micro-architecture register; 240: reorder buffer; 245: instruction issue unit; 250: system management mode; 260: architected register; S305, S310, S315, S320, S325: steps; S405, S410, S415, S420, S425, S430, S435: steps; S505, S510, S515, S520, S525, S530: steps; S605, S610, S615, S620, S625, S630, S635, S640, S645: steps; S705, S710, S712, S715, S720, S725: steps; S901, S904, S903, S905, S907, S909, S911, S913, S915, S917, S919, S921, S923, S925, S927, S929, S933: steps; 1000: system for executing new instructions; 1100: processor; 1110: translation program; S1205, S1210, S1215, S1220, S1225: steps; S1305, S1310, S1315, S1320, S1325: steps; S1405, S1410, S1415, S1420, S1425: steps; 1500: system for executing new instructions; 150: kernel driver; 1600: flowchart; S1605, S1610, S1620, S1625: steps; 1700: system for executing new instructions; 190: special processing core; S1805, S1810, S1815, S1820, S1825: steps; S1905, S1910, S1915, S1920, S1925: steps; S2005, S2010, S2015: steps; 2100: computing device; 2110: bus; 2112: memory; 2114: processor; 2116: display element; 2118: I / O port; 2120: I / O element; 2122: power supply. DETAILED DESCRIPTION

[0032] Aspects of the application are described more fully below with reference to the drawings. This application may, however, be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the application to those skilled in the art. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein can be implemented independently of any other aspects and that two or more of the aspects can be combined in any suitable manner. For example, an apparatus can be implemented or a method can be practiced using any number of the aspects set forth herein. In addition, such an apparatus can be implemented or such a method can be practiced using other structure, functionality, or structure and functionality in addition to or other than the structure, functionality and structure and functionality explicitly described herein. One skilled in the art should appreciate that any aspect disclosed herein can be embodied by one or more elements. For example, an apparatus can be implemented or a method can be practiced using any number of the described embodiments.

[0033] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Furthermore, examples of the present application are described herein as including certain features, structures, or characteristics, but it should be appreciated that not all of these features, structures, or characteristics need necessarily be present in every example of the application. In addition, it should be understood that examples can include features, structures, or characteristics of some previous examples, without having to include every such feature, structure, or characteristic. It should also be understood that descriptions of well known structures, functions, or characteristics do not limit the application, and that the functions, structures, or characteristics can be implemented by any number of means.

[0034] It is to be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Pronouns in the masculine form include the feminine form, and vice versa, and the singular form also includes the plural form, unless the context clearly dictates otherwise.

[0035] In order to better describe the embodiments of the present application, the following first defines the special terms used in the present application.

[0036] Old instruction: the instruction originally supported by the previous generation processor is called native instruction, also known as existing instruction or old instruction.

[0037] Unknown instruction: the instruction not originally supported by the previous generation processor.

[0038] New instruction: the instruction newly supported by the next generation processor compared with the previous generation processor. The new instruction cannot be recognized by the previous generation processor, and thus is unknown instruction to the previous generation processor.

[0039] New architecture register: an architecture register newly supported by the successor processor compared with the predecessor processor. The new architecture register does not exist in the predecessor processor, and therefore needs to be emulated when emulating the execution of the new instruction using the new architecture register on the predecessor processor.

[0040] Unrecognizable instruction: the part of the instruction in the unknown instruction except the new instruction. That is, the unrecognizable instruction is the instruction not natively supported by the successor processor.

[0041] Model special register: a type of register in the processor, which can be used to complete some specific functions.

[0042] Trap: a trap is generally caused by a software interrupt instruction (such as the INT instruction). When an instruction causes a trap exception, it does not mean that the execution of the instruction itself is incorrect. Therefore, when an instruction causes a trap exception, the processor will continue to execute the next instruction of the instruction. For example, when a software developer debugs a software program code, he can set a breakpoint in the program code. When the program code with the set breakpoint is executed on the processor, a trap will be generated when the breakpoint is executed, so that the program code is paused at the breakpoint. The software developer can view the values of the architecture registers in the processor or the values of the variables in the program code when the program code is executed to the breakpoint by processing the microcode processing program of the trap. And according to the values of the architecture registers or the values of the variables in the program code, it is determined whether the program code is executed normally when the program code is executed to the breakpoint.

[0043] The processor described in the present application can be a processor with a reduced instruction set computing (RISC, such as ARM / MIPS / RISC-V instruction set), a complex instruction set computing (CISC, such as x86 instruction set), or other instruction set types; or a processor that can support multiple different instruction set architectures at the same time (such as a processor that supports both x86 instruction set and ARM instruction set). The present application does not make special limitations on the instruction set type supported by the processor, but for the convenience of description, the embodiments of the present application are described with respect to a processor supporting X86 instruction set. In addition, as known by those skilled in the art, the x86 processor will interpret the macro instruction (Macroinstruction) into at least one micro instruction (Microinstruction) or micro instruction sequence according to the original program order (In-order), but the execution of the micro instruction is performed in an out-of-order (Out-of-order) manner to improve the execution efficiency, only the submission (Retire) process after the execution of the micro instruction is still in the original program order.

[0044] The present application has various embodiments, and four main embodiments of the present application will be described below using four examples. The first embodiment is an embodiment of emulating execution of new instructions in system management mode. The second embodiment is an embodiment of emulating execution of new instructions in the same execution mode as the new instructions. The third and fourth embodiments are embodiments of emulating execution of new instructions by an operating system, wherein the fourth embodiment uses a special processing core to perform conversion of the new instructions. The first embodiment will be described first.

[0045] [First Embodiment]

[0046] Figure 1 is a schematic diagram showing a system for executing new instructions according to the first embodiment of the present application. As shown in Figure 1 , the system 100 for executing new instructions includes a processor 110, an operating system 120, an application 130, and an emulator 142. The operating system 120 runs on the processor 110 and is used to manage the processor 110. The application 130 runs on the operating system 120 and can use various functions provided by the processor 110 and other hardware (not shown, such as hard disks, network cards, etc.) through the operating system 120. The emulator 142 runs on the processor 110 in system management mode (SMM). The operating system 120 or the application 130 cannot perceive the execution process of the emulator 142. That is, all operations performed by the emulator 142 are transparent to the operating system 120 or the application 130.

[0047] When the processor 110 executes an unknown instruction from the application 130 or the operating system 120, the processor 110 enters system management mode and sends the unknown instruction to the emulator 142 for processing. If the unknown instruction is a new instruction, the emulator 142 will emulate execution of the new instruction. It is worth noting that the source code of the application 130 or the operating system 120 is generally written in a high-level language (such as C, C++, etc.) and / or a low-level language (such as assembly language, etc.). After the source code is compiled using a compiler, executable code that can be executed by the processor is generated. The executable code is composed of instructions that can be executed by the processor. In the present application, the application 130 or the operating system 120 refers to the executable code generated by compiling the source code of the application 130 or the operating system 120 using the compiler. The process of the system 100 for executing new instructions will be described briefly below using the processor 110 processing the unknown instruction 132 in Figure 1 .

[0048] As shown in Figure 1As shown, the processor 110 includes an interrupt pre-processing unit 112 and a system management mode exit / entry 114. The system management mode exit / entry 114 includes a system management mode entry 1142 and a system management mode exit 1144. Figure 1 The solid arrows with numbers indicate the direction of the transmission of the instruction information, and the dashed arrows with numbers indicate the direction of the transmission of the results of the instruction emulation. The entire process of the processor 110 handling the unknown instruction 132 is described below.

[0049] First, the processor 110 receives the instruction 118 in the application program 130 that completes a specified function (as shown by the solid arrow 1). After receiving the instruction 118, the processor 110 determines whether the instruction 118 is an unknown instruction 132. If the instruction 118 is an unknown instruction 132, the processor 110 issues an unknown instruction exception (#UD). In response to the unknown instruction exception, the interrupt pre-processing unit 112 executes a microcode handling program of the unknown instruction exception. In the microcode handling program of the unknown instruction exception, the interrupt pre-processing unit 112 sets an emulation flag (EF) and issues a system management interrupt (#SMI), and sends the instruction information of the unknown instruction 132 to the system management mode exit / entry 114 (as shown by the solid arrow 2). How to issue the unknown instruction exception and the system management interrupt is common knowledge to those skilled in the art, and thus is not described here. In an embodiment, the processor 110 is a processor supporting the x86 instruction set, and the interrupt pre-processing unit 112 is a microcode control unit. In actual operation, those skilled in the art can modify the microcode handling program of the unknown instruction exception stored in the interrupt pre-processing unit 112 to add the functions of setting the emulation flag, obtaining the instruction information of the unknown instruction, and issuing the system management interrupt. Since these microcodes are different depending on the version of the processor, those skilled in the art can write the corresponding microcodes according to the actual situation.

[0050] Then, the processor 110 enters the system management mode by executing the system management mode entry 1142, and sends the instruction information of the unknown instruction 132 to the emulator 142 (as shown by the solid arrow 3). In the system management mode, the emulator 142 judges whether the unknown instruction 132 is a new instruction. If the unknown instruction 132 is a new instruction, the emulator 142 emulates the execution of the new instruction. After emulating the execution of the new instruction, the emulator 142 sends the emulation execution result to the system management mode entry / exit 114 (as shown by the dashed arrow 4). Then, the processor 110 sends the emulation execution result to the application 130 through the system management mode exit 1144 (as shown by the dashed arrow 5), and exits the system management mode. At this point, the processor 110 has finished processing the unknown instruction 132. In an embodiment, during the emulation execution of the new instruction by the emulator 142, the intermediate operation results generated during the emulation execution can be stored in the system management memory (SMRAM).

[0051] Figure 2 is a structural diagram of a processor according to the first embodiment of the present application. As shown in Figure 2 , the processor 200 on the left side of the dashed line is the structural diagram of the processor 110 shown in Figure 1 , and the emulator 142 and the conversion program 145 on the right side of the dashed line run on the processor 200 in the system management mode. In an embodiment, the functions completed by the conversion program 145 are implemented in a conversion module, or the conversion program 145 can also be regarded as a conversion module in the system 100 that executes the new instruction. The following will be described in combination with Figure 1 . Figure 2

[0052] As shown in Figure 2 , the processor 200 includes an instruction translation lookaside buffer (ITLB) 201, an instruction cache 202, and a branch predictor 203. When the processor 200 executes an instruction of the application 130 or the operating system 120, the instruction translation lookaside buffer 201 of the processor 200 receives the instruction. The branch predictor 203 is used to predict conditional branches, and transmits the branch prediction result to the instruction cache 202. The instruction cache 202 acquires the received instruction from the instruction translation lookaside buffer 201 according to the branch prediction result, and then the processor 200 further processes the received instruction.

[0053] As shown in Figure 2 ​As shown, the processor 200 also includes an instruction decode unit 230. The instruction decode unit 230 determines whether the received instruction is an unknown instruction and generates at least one microinstruction including an unknown instruction identification indicating whether the received instruction is an unknown instruction. When the unknown instruction identification is a first value, the received instruction is an unknown instruction. When the unknown instruction identification is a second value, the received instruction is an old instruction. In one embodiment, the first value is 1 and the second value is 0.

[0054] The processor 200 also includes a rename unit 204, a reservation station 205, an execution unit 206, a memory access unit 207, a reorder buffer 240, an interrupt pre-processing unit 112, and an architectural register 260. The rename unit 204 receives the microinstruction including the unknown instruction identification (UD) from the instruction decode unit 230 and renames the microinstruction. The rename unit 204 then sends the renamed microinstruction to the reservation station 205 and the reorder buffer 240. The reservation station 205 sends the microinstruction to the execution unit 206 or the memory access unit 207 for further processing based on the type of the microinstruction. The reorder buffer 240 receives the microinstruction and stores the microinstruction in an instruction entry. The reorder buffer 240 includes a plurality of instruction entries, each of which includes an unknown instruction identification field for storing the unknown instruction identification in the microinstruction.

[0055] The reorder buffer 240 includes an instruction retirement unit 245. The instruction retirement unit 245 retires the microinstruction when the microinstruction satisfies a retirement condition. When the microinstruction is retired, the instruction retirement unit 245 updates the architectural register 260 based on the execution result of the microinstruction if no exception is generated when the microinstruction is executed. If an exception is generated when the microinstruction is executed, the instruction retirement unit 245 reports the exception. In response to the exception, the processor 200 executes a microcode handler for the exception.

[0056] When the instruction retirement unit 245 retires the microinstruction, the instruction retirement unit 245 issues an unknown instruction exception (#UD) if the unknown instruction identification of the microinstruction is the first value. In response to the unknown instruction exception, the processor 200 executes a microcode handler for the unknown instruction exception. In the microcode handler for the unknown instruction exception, the processor 200 stores a dummy identification having the first value in the micro-architectural register 220 and issues a system management interrupt (#SMI). In response to the system management interrupt, the processor 200 executes a microcode handler for the system management interrupt. Figure 1The system management mode entry 1142 is shown to enter the system management mode based on the simulation flag stored in the micro-architecture register 220. In the system management mode, the processor 200 processes the received instruction through the emulator 142. First, the emulator 142 determines whether the received instruction is a new instruction. If the received instruction is a new instruction, the emulator 142 emulates execution of the received instruction. In the process of emulating execution of the received instruction, the emulator 142 can store intermediate results in a system management memory (SMRAM). It is noted that when the simulation flag is the first value, it indicates that the emulator 142 is needed to process the received instruction; when the simulation flag is the second value, it indicates that the emulator 142 is not needed to process the received instruction.

[0057] After the emulator 142 finishes processing the received instruction, the processor 200 exits the system management mode through execution of a system management mode exit 1144. The system management mode exit 1144 sets the simulation flag stored in the micro-architecture register 220 to the second value, and then exits the system management mode. When the processor 200 executes another instruction, and the other instruction is an unknown instruction, the processor 200 sets the simulation flag stored in the micro-architecture register 220 to the first value in the process of executing the microcode handler for the unknown instruction exception. Then, the processor 200 processes the other instruction according to the foregoing process. Figure 1

[0058] Figure 3 is a flowchart showing execution of a new instruction according to the first embodiment of the present application. Please refer to Figure 2 and Figure 3 As shown in Figure 3 , the instruction decode unit 230 receives an instruction (S305), and the instruction issue unit 245 issues an unknown instruction exception (S310) when the received instruction is an unknown instruction. In response to the unknown instruction exception, the processor 200 enters a system management mode (S315), and determines whether the received instruction is a new instruction through a translation program (S320). When the received instruction is a new instruction, the processor 200 emulates execution of the received instruction through execution of at least one old instruction (S325). Details are as follows: the instruction decode unit 230 first executes step S305.

[0059] In step S305, the instruction decode unit 230 receives an instruction. Specifically, the instruction decode unit 230 receives the instruction from the instruction cache 202. Then, the processor 200 executes step S310.

[0060] ​In step S310, when the received instruction is an unknown instruction, the instruction submission unit 245 issues an unknown instruction exception. Specifically, as described above, after the instruction decoding unit 230 determines that the received instruction is an unknown instruction, it generates a microinstruction, wherein the microinstruction contains an unknown instruction identifier with a value of a first value. Then, the instruction decoding unit 230 sends the microinstruction to the renaming unit 204. The renaming unit 204 renames the microinstruction and then sends it to the rearrangement buffer 240. The rearrangement buffer 240 stores the microinstruction in an instruction entry. When the microinstruction meets the retiring condition, the instruction submission unit 245 reads the microinstruction from the instruction entry and performs a retiring process on the microinstruction. Since the unknown instruction identifier of the microinstruction is the first value, the instruction submission unit 245 issues an unknown instruction exception. Then, the processor 200 executes step S315.

[0061] In step S315, in response to the aforementioned unknown instruction exception, processor 200 enters a System Management mode (SMM). Specifically, in response to the unknown instruction exception, processor 200 executes the microcode handler for the unknown instruction exception. In the microcode handler for the unknown instruction exception, processor 200 writes an Emulation Flag (EF) with a first value into microarchitecture register 220 and issues a System Management Interrupt (#SMI). In response to the System Management Interrupt, processor 200 will, as follows: Figure 1 The system management mode entry 1142 is shown. Enter the system management mode according to the above simulation identifier. Then execute step S320.

[0062] In step S320, under the aforementioned system management mode, the processor 200 determines whether the received instruction is a new instruction through a conversion program. How the conversion program determines whether the received instruction is a new instruction will be explained later in conjunction with... Figure 7 A detailed description is provided. In one embodiment, the conversion program can be pre-stored in a Basic Input / Output System (BIOS). As those skilled in the art will know, the BIOS is executed when the system 100 executing the new instruction boots up. The BIOS contains code for initializing the system management mode. When the system 100 executing the new instruction reaches the code for initializing the system management mode, the conversion program is loaded into the System Management Memory (SMRAM). Then, the processor 200 can directly execute the conversion program stored in the SMRAM after entering the system management mode. Then, the processor 200 executes step S325.

[0063] In step S325, when the received instruction is a new instruction, the processor 200 simulates the execution of the received instruction by executing at least one old instruction. Specifically, when the received instruction is a new instruction, the processor 200 first converts the received instruction into at least one old instruction using the aforementioned conversion procedure. Then, the processor 200 executes the at least one old instruction. For a more detailed explanation, please refer to the following section... Figure 6 The steps S615, S620, S625 and S630 are described.

[0064] In one embodiment, the received instruction is an instruction set architecture (ISA) instruction, and the at least one legacy instruction is an ISA instruction. In another embodiment, the received instruction is an x86 instruction, an ARM instruction, a RISC-V instruction, or a MIPS instruction, and the at least one legacy instruction is an x86 instruction, an ARM instruction, a RISC-V instruction, or a MIPS instruction.

[0065] Figure 4 This is a flowchart illustrating the processing of received instructions according to the first embodiment of the present invention. Please also refer to... Figure 2 and Figure 4 ,like Figure 4 As shown, the instruction decoding unit 230 receives an instruction (S405) and determines whether the received instruction is an unknown instruction (S410). When the received instruction is an unknown instruction, the system management mode is entered to process the received instruction. Since step S405 and... Figure 3 Step S305 is the same, so it will not be repeated here. Step S410 is described below.

[0066] In step S410, the instruction decoding unit 230 determines whether the received instruction is an unknown instruction. Specifically, the instruction decoding unit 230 decodes the received instruction to obtain its decoding information. In one embodiment, the decoding information includes a prefix, escape code, opcode, operand mode (ModR / M), and other decoding information, etc. Then, the instruction decoding unit 230 determines whether the received instruction is an unknown instruction based on the decoding information. For example, the opcodes of older instructions natively supported by the processor 200 can be stored in a lookup table. The instruction decoding unit 230 can check whether the opcode of the received instruction is stored in the lookup table. If it is, the received instruction is an older instruction; otherwise, the received instruction is an unknown instruction. In one embodiment, the lookup table is stored in the instruction decoding unit 230.

[0067] When the received instruction is an old instruction (NO in step S410), step S435 is performed. In step S435, the processor 200 normally processes the received instruction. As to how to normally process the received instruction, for example, converting the old instruction into a micro instruction corresponding thereto, and executing the corresponding micro instruction, it is the common knowledge of those skilled in the art, and thus will not be described here. When the received instruction is an unknown instruction (YES in step S410), step S415 is performed.

[0068] In step S415, the processor 200 writes an emulation flag into a micro- architectural register 220. Specifically, when the received instruction is an unknown instruction, the instruction decode unit 230 generates a micro instruction, and the unknown instruction flag of the micro instruction is a first value. In an embodiment, the micro instruction is a no-operation (NOP) micro instruction. The instruction decode unit 230 sends the micro instruction to the rename unit 204. The rename unit 204 performs rename processing on the micro instruction. Then, the rename unit 204 sends the micro instruction to the reorder buffer 240. The reorder buffer 240 stores the micro instruction in its own instruction entry. When the micro instruction is committed, because the unknown instruction flag of the micro instruction is the first value, the instruction commit unit 245 issues an unknown instruction exception. In response to the unknown instruction exception, the processor 200 executes a microcode processing program of the unknown instruction exception. In the microcode processing program of the unknown instruction exception, the processor 200 writes an emulation flag into the micro- architectural register 220. In addition, the processor 200 also stores information of the received instruction and running environment information of the received instruction into the micro- architectural register 220. Then, in the microcode processing program of the unknown instruction exception, the processor 200 issues a system management interrupt (#SMI). In an embodiment, the information of the received instruction includes an instruction pointer of the received instruction. In another embodiment, the information of the received instruction includes an instruction pointer of the received instruction and machine code of the received instruction. The running environment information includes a running mode of the received instruction (i.e., a running mode of the processor 200 when the processor 200 executes the received instruction). For example, the running mode includes a real mode, a protected mode, a virtual 8086 mode (v8086 mode), a compatibility mode, and a long mode, etc. Then, the processor 200 performs step S420.

[0069] In step S420, the processor 200 enters a system management mode. Specifically, in response to the system management interrupt, the processor 200 executes a system management mode entry routine, and enters the system management mode. Then, the processor 200 performs step S425. Figure 1The system management mode entry 1142 is shown to enter the system management mode. Details of how the processor 200 enters the system management mode will be described later in conjunction with Figure 5 The processor 200 then performs step S425.

[0070] In step S425, the processor 200 processes the above-mentioned received instruction. Details of how the processor 200 processes the above-mentioned received instruction will be described later in conjunction with Figures 6-8 The processor 200 then performs step S430.

[0071] In step S430, the processor 200 exits the system management mode and ends this flow. Specifically, the processor 200 exits the system management mode by performing the system management mode exit 1144 as shown in Figure 1 Details of how the processor 200 exits the system management mode will be described later in conjunction with Figures 9A-9B

[0072] Figure 5 is a flowchart showing the flow of entering the system management mode according to the first embodiment of the present application. Figure 5 is a flowchart showing the flow of the microcode handler corresponding to the system management mode entry 1142 shown in Figure 1 Please refer to Figure 2 and Figure 5 As shown in Figure 5 , the processor 200 disables the interrupt (S505) and judges whether the simulation flag is the first value (S510). If the result of step S510 is "Yes", the system management mode is entered. Details are as follows: the processor 200 first performs step S505.

[0073] In step S505, the processor 200 disables the interrupt. As is known to those skilled in the art, the interrupt is disabled in the system management mode, and therefore the interrupt is disabled in the present application in accordance with the architecture requirement. As an example, the processor 200 clears the IF flag to disable the maskable interrupt, clears the TF flag to disable the single-step interrupt, and clears the DR7 to disable the breakpoint interrupt. The processor 200 then performs step S510.

[0074] Next, in step S510, the processor 200 judges whether the above-mentioned simulation flag is the first value. Specifically, the processor 200 judges whether the simulation flag saved in the micro-architecture register 220 is the first value. If the result is "No", step S530 is performed to execute the normal flow of entering the system management mode. As is known to those skilled in the art, the normal flow of entering the system management mode is not described here. If the result is "Yes", the processor 200 performs step S515. ​

[0075] In step S515, the processor 200 sends an entry into system management mode notification (Assert#smmact) to notify the chipset processor 200 that it has entered system management mode. How to send the entry into system management mode notification is common knowledge to those skilled in the art and will not be described in detail here. Then, the processor 200 executes step S520.

[0076] In step S520, the processor 200 stores the emulation identifier, received instruction information, and runtime environment information into the system management memory. Specifically, the processor 200 reads the emulation identifier, received instruction information, and runtime environment information from the microarchitecture register 220 and stores the read emulation identifier, received instruction information, and runtime environment information into the system management memory. Simultaneously, the contents of the architecture register 260 (i.e., the current state of the processor 200) are also stored in the system management memory. The information stored in the system management memory is shown in Table 1 below.

[0077] Table 1

[0078]

[0079] Then, in step S525, the processor 200 establishes a system management mode execution environment and enters system management mode. How to establish the system management mode execution environment and how to enter system management mode are common knowledge to those skilled in the art, and will not be elaborated here.

[0080] It is worth noting that, in Figure 5 The passage shown Figure 1 In the actual operation of entering system management mode via entry point 1142, those skilled in the art can add microcode to the microcode corresponding to entering system management mode after issuing a system management interrupt (#SMI). This microcode executes the process of saving the simulation identifier, the aforementioned received instruction information, and the runtime environment information to the system management memory (SMRAM), ensuring that this data / information is not overwritten when the processor 200 switches to system management mode. Furthermore, since the processor 200 in system management mode accesses the system management memory (SMRAM) in known technologies, those skilled in the art can modify this part of the microcode to achieve the purpose of accessing this data / information. Because these microcodes vary depending on the processor version, those skilled in the art can write the corresponding microcode according to the actual situation.

[0081] Then, the processor 200 processes the aforementioned receive instructions (such as...) in system management mode. Figure 4 Step S425 (as shown). The following is in conjunction with... Figures 6-8The processor 200 processes the received instruction in the system management mode is described in detail.

[0082] Figure 6 is a flowchart showing the processing of the emulator according to the first embodiment of the present application. As described above, the processor 200 processes the received instruction in the system management mode through the emulator 142. Please refer to Figure 2 and Figure 6 As shown in Figure 6 , in the system management mode, the emulator 142 establishes a simulation running environment (S605), and then judges whether the simulation identifier is the first value (S610). If the result of step S610 is "Yes", the emulator 142 converts the received instruction through the conversion program, and generates a conversion result (S615). Then, the emulator 142 processes the conversion result. The details are as follows: First, the emulator 142 executes step S605.

[0083] In step S605, the emulator 142 establishes a simulation running environment. Specifically, the emulator 142 reads the simulation identifier, the information of the received instruction, the running environment information of the received instruction, and the information of the architecture register from the system management memory. In the subsequent steps, the received information is used to simulate the execution of the received instruction. Then, the emulator 142 executes step S610.

[0084] In step S610, the emulator 142 judges whether the simulation identifier is the first value. Specifically, the emulator 142 judges whether the simulation identifier read in step S605 is the first value. If the result is "No", the emulator 142 executes step S645. In step S645, the emulator 142 executes the normal processing flow of the system management mode. For the normal processing flow of the system management mode, it is the common knowledge of those skilled in the art, and will not be described here. If the result of step S610 is "Yes", the emulator 142 executes step S615.

[0085] In step S615, the emulator 142 converts the received instruction through the conversion program 145, and generates a conversion result. The structure of the conversion result is shown in Table 2 below, which includes two fields: result and content. When the result field is the first value, it means that the conversion is successful, and the content field contains at least one old instruction converted from the received instruction and the length of the received instruction; when the result field is the second value, it means that the conversion fails, and the content field contains an exception number. As for how to convert the received instruction through the conversion program 145, it will be described in detail later. Figure 7

[0086] Table 2

[0087] Results Content … … ​

[0088] In step S620, the simulator 142 judges whether the conversion program is converted successfully. Specifically, the simulator 142 judges whether the conversion program is converted successfully according to the result field in the conversion result. When the result field in the conversion result is the first value, the judgment result is "Yes", and the simulator 142 executes step S625. When the result field in the conversion result is the second value, the judgment result is "No", and the simulator 142 generates a simulation execution result according to the conversion result, and then executes step S630. The structure of the simulation execution result is shown in Table 3 below, and includes two fields of result and details. When the result field in the simulation execution result is the first value, it indicates that the simulation execution is successful, and the operation result obtained after the simulation execution is saved in the details field. When the result field in the simulation execution result is the second value, it indicates that the simulation execution fails, and the exception number is saved in the details field. When the result field in the simulation execution result is the second value, the simulation execution result generated according to the conversion result is shown in Table 3-1 below. The exception number in the details field in Table 3-1 is the exception number in the content field in the conversion result.

[0089] Table 3

[0090] Results Details … …

[0091] Table 3-1

[0092] Results Details Second value Exception number

[0093] Further, when the result of the step S620 is a success (i.e., the result of the step S620 is "Yes"), the emulator 142 performs a step S625. In the step S625, the emulator 142 obtains at least one old instruction from the conversion result and executes the at least one old instruction. Specifically, the emulator 142 obtains the at least one old instruction and the length of the received instruction from the content field of the conversion result. Then, the emulator 142 causes the processor 200 to execute the at least one old instruction by calling or jumping to the at least one old instruction. The processor 200 decodes the at least one old instruction into at least one micro instruction and executes the at least one micro instruction to generate an emulation execution result. If a runtime exception occurs during the execution of the at least one micro instruction by the processor 200, the content field of the emulation execution result is shown in Table 3-2. In Table 3-2, the result field of the emulation execution result is a second value, indicating that the emulation execution fails; and the detail field of the emulation execution result is an exception number, i.e., the number of the runtime exception. If the execution of the at least one micro instruction by the processor 200 is successful, the content field of the emulation execution result is shown in Table 3-3. In Table 3-3, the result field of the emulation execution result is a first value, indicating that the emulation execution succeeds; and the detail field of the emulation execution result is a result of the operation.

[0094] Table 3-2

[0095] Results Details Second value Exception number

[0096] Table 3-3

[0097] Results Details First value Operation result

[0098] In an embodiment, when the operand of the received instruction includes a new architecture register, the new architecture register is emulated by using the system management memory. For example, when a descendant processor of the processor 200 includes a new architecture register with a bit width of 1024 bits, the emulator 142 can emulate the new architecture register by using a continuous 1024-bit storage space in the system management memory. That is, when the received instruction accesses the new architecture register, the emulator 142 actually accesses the continuous 1024-bit storage space in the system management memory.

[0099] When the new architectural register is a destination operand of the received instruction, the processor 200 stores the result of the received instruction in the system management memory after executing the at least one old instruction. In this way, when the processor 200 executes another instruction, and the another instruction is also a new instruction, and the new architectural register is a source operand of the another instruction, the processor 200 directly uses the result stored in the system management memory when emulating the another instruction. It should be noted that the received instruction and the another instruction can be consecutive (i.e., adjacent), or can not be consecutive, and the present application does not limit this.

[0100] In the system management mode, the emulator 142 can only access the system management memory, and cannot access the memory (i.e., system memory, hereinafter the same) in a normal manner. In an embodiment of the present application, a physical memory direct access interface is provided to enable the operation of accessing the memory in the system management mode. When the received instruction includes a memory operand, the memory operand can be accessed through the physical memory direct access interface. The steps of accessing the memory operand through the physical memory direct access interface are as follows:

[0101] First, the emulator 142 converts the virtual address of the memory operand to a physical address. Specifically, the emulator 142 converts the virtual address of the memory operand to a physical address by accessing the page table through the physical memory direct access interface. The steps of converting the virtual address to the physical address are as follows: 1. read the page table base address saved in the architectural register CR3 from the system management memory; 2. perform a page table query according to the page table base address and the virtual address, and obtain the physical address after emulating the page table query process.

[0102] Second, the emulator 142 reads the value of the memory operand according to the physical address through the physical memory direct access interface, wherein the physical address is not in the system management memory. Specifically, the emulator 142 reads the value of the memory operand according to the physical address by using a model specific register (MSR) through the physical memory direct access interface. The specific steps are as follows:

[0103] Step 1, the emulator 142 writes the address of the model specific register into a first register (ECX), and writes the physical address into a second register (EDX:EAX).

[0104] In step 2, the emulator 142 executes a write model-specific register instruction (WRMSR) to store the value of the memory operand in the model-specific register. Specifically, after the emulator 142 executes the write model-specific register instruction, the physical address is written into the model-specific register. Then, the processor 1100 uses the physical address stored in the model-specific register to load the value of the memory operand from the system memory into the model-specific register by executing a load from physical address microinstruction (ld_phys).

[0105] In step 3, the emulator 142 executes a read model-specific register instruction (RDMSR) to read the value of the memory operand from the model-specific register and store the value of the memory operand in the second register.

[0106] In one embodiment, the next instruction of the received instruction is the another instruction. The last instruction of the at least one old instruction is a jump instruction (jump) or a call instruction (call), and the processor 1100 jumps to the another instruction through the jump instruction or the call instruction. The instruction pointer of the another instruction is EIP+Length, where EIP is the instruction pointer of the received instruction, and Length is the length of the received instruction.

[0107] Then, the emulator 142 performs step S630. In step S630, the emulator 142 writes the simulation execution result into the system management memory. Specifically, the emulator 142 writes the simulation execution result generated in step S625 or step S620 into the system management memory. As described above, there are two cases of the simulation execution result: one is that the simulation execution is successful, and the other is that the simulation execution fails. The system management memory includes an exception vector table, which has the structure shown in Table 4. The exception vector table includes two fields: an exception identification and an exception number. When storing the simulation execution result into the system management memory, the exception vector table in the system management memory needs to be filled in. The processes of the emulator 142 storing the simulation execution result of the two cases into the system management memory are described below.

[0108] Table 4

[0109] Exception identification Exception number … …

[0110] When the simulation execution is successful, the emulator 142 sets the exception identification field of the exception vector table in the system management memory to a first value (as shown in Table 4-1 below), and stores the operation result stored in the details field of the simulation execution result into the system management memory. For example, if the operation result is that the value of the architectural register ECX becomes 10H (i.e., the hexadecimal number 10, the same below), the emulator 142 needs to write 10H into the storage space corresponding to the architectural register ECX in the system management memory. If the operation result is that the value of the newly added architectural register becomes 20H, the emulator 142 needs to write 20H into the storage space used for simulating the newly added architectural register in the system management memory. The emulator 142 also updates the value of the instruction pointer of the received instruction stored in the system management memory to EIP+Length, so that the instruction pointer of the processor 200 points to the next instruction to be executed, where EIP is the value of the instruction pointer before the update, and Length is the length of the received instruction. The instruction pointer of the received instruction in the system management memory is the storage space corresponding to the architectural register EIP. When exiting the system management mode, the values in the storage spaces corresponding to the architectural registers in the system management memory are written into the corresponding architectural registers 260, so as to send the simulation execution result of the newly added instruction to the application program 130 or the operating system 120, which will be described in detail below.

[0111] Table 4-1

[0112] Exception identification Exception number First value …

[0113] When the simulation execution fails, it indicates that an exception occurs during the simulation execution. The emulator 142 sets the exception identification field of the exception vector table in the system management memory to a second value (as shown in Table 4-2 below), and writes the exception number stored in the details field of the simulation execution result into the exception number field of the exception vector table. According to the exception number, it can be determined whether the exception is a trap. When the exception is a trap, the emulator 142 updates the value of the instruction pointer of the received instruction stored in the system management memory to EIP+Length, so that the instruction pointer of the processor 200 points to the next instruction set architecture instruction to be executed, where EIP is the value of the instruction pointer of the received instruction before the update, and Length is the length of the received instruction stored in the system management memory.

[0114] Table 4-2

[0115] Exception identification Exception number Second value Exception number

[0116] Then, emulator 142 executes step S635. In step S635, emulator 142 executes the Resume from System Management mode (RSM) instruction. After executing the Resume from System Management mode instruction, processor 200 will execute as follows: Figure 1 The microcode processing program for system management mode exit 1144 shown below will be combined with... Figures 9A-9B It will be explained in detail.

[0117] Figure 7 This is a flowchart showing the conversion procedure according to the first embodiment of the present invention. Figure 7 For example Figure 1 The flowchart of conversion procedure 145 is shown below. Please refer to it. Figure 2 and Figure 7 ,like Figure 7 As shown, the conversion program 145 obtains the opcode of the aforementioned receiving instruction (S705). Then, the conversion program 145 determines whether the aforementioned receiving instruction is a new instruction based on the aforementioned opcode (S710). When the aforementioned receiving instruction is a new instruction, the conversion program 145 converts the aforementioned receiving instruction into at least one old instruction (S720) and generates a conversion result (S725). A detailed explanation follows: The conversion program 145 first executes step S705.

[0118] In step S705, the conversion program 145 obtains the opcode of the received instruction based on the information of the received instruction. It should be noted that since the received instruction has not yet been decoded at this point, the information of the received instruction does not include decoding information such as prefixes, escape codes, and opcodes. Based on the preceding text... Figure 4 As described in step S415, in one embodiment, the information of the received instruction only includes the instruction pointer of the received instruction; in another embodiment, the information of the received instruction includes both the instruction pointer of the received instruction and the machine code of the received instruction. The conversion program 145 is executed. Figure 7 The processing flow shown can be divided into the following three scenarios:

[0119] In the first scenario: when the information of the above-mentioned receiving instruction only contains the instruction pointer of the above-mentioned receiving instruction, when the conversion program 145 decodes the above-mentioned receiving instruction, it reads and processes 1 byte of machine code each time according to the instruction pointer of the above-mentioned receiving instruction until the decoding is completed.

[0120] The second scenario: When the information of the above received instruction only contains the instruction pointer of the above received instruction, the conversion program 145 first reads the machine code of the above received instruction according to the instruction pointer of the above received instruction, and then decodes the read machine code.

[0121] The third case: when the information of the received instruction contains the instruction pointer of the received instruction and the machine code of the received instruction, the conversion program 145 directly decodes the machine code in the information of the received instruction;

[0122] The following first describes the process of the conversion program 145 executing the processing flow of Figure 7 in the first case. The conversion program 145 first executes step S705.

[0123] In step S705, the conversion program 145 obtains the opcode of the received instruction. Specifically, the conversion program 145 obtains the opcode of the received instruction according to the information of the received instruction. As previously described Figure 6 (step S605) of the emulator 142. The information of the received instruction only contains the instruction pointer of the received instruction, and the conversion program 145 obtains the opcode of the received instruction according to the instruction pointer of the received instruction. In detail, the conversion program 145 first reads the first byte of the machine code of the received instruction from the memory (i.e., the system memory) according to the instruction pointer of the received instruction, and then determines the opcode of the received instruction according to the read byte (i.e., the first byte). If the opcode of the received instruction cannot be determined according to the first byte of the machine code, the conversion program 145 reads the second byte of the machine code, and then determines the opcode of the received instruction according to the read byte (i.e., the first two bytes). In this way, the opcode of the received instruction is determined. It is worth noting that if the received instruction contains a prefix and / or an escape code, the conversion program 145 first obtains the prefix and / or the escape code of the received instruction, and then obtains the opcode thereof. In an embodiment, the conversion program 145 reads the machine code from the memory according to the instruction pointer of the received instruction through the physical memory direct access interface as previously described. After obtaining the opcode of the received instruction, the conversion program 145 executes step S710.

[0124] Next, in step S710, the conversion program 145 determines whether the received instruction is a new instruction. Specifically, the conversion program 145 determines whether the received instruction is a new instruction based on the opcode of the received instruction. For example, the opcodes of new instructions supported by the processor 200 can be stored in a lookup table. The conversion program 145 can check whether the opcode is stored in the lookup table. If it is stored in the lookup table, it indicates that the received instruction is a new instruction, and the determination result is "yes"; otherwise, the determination result is "no". In one embodiment, the lookup table is stored in system management memory. In one embodiment, the conversion program 145 determines whether the received instruction is a new instruction based on both the escape code and the opcode of the received instruction.

[0125] When the received instruction is not a new instruction (the result of step S710 is "No"), it indicates that the received instruction is an unrecognizable instruction. The conversion program 145 executes step S725 and generates the conversion results shown in Table 2-1 below. As shown in Table 2-1 below, the result field value of the conversion result is the second value, indicating that the conversion failed; the content field of the conversion result is the exception number #UD (value 6) of the unknown instruction exception.

[0126] Table 2-1

[0127] Results Content Second value #UD

[0128] When the received instruction is a new instruction (the judgment result of step S710 is "yes"), the conversion program 145 executes step S712. In step S712, the conversion program 145 determines whether there is a decoding error. Specifically, as described above ( Figure 6 In step S605, the simulation program 142 reads the operating environment information of the processor 200 at the time of executing the aforementioned receive instruction from the system management memory. This operating environment information includes the operating mode of the processor 200. The conversion program 145 determines whether the aforementioned receive instruction can be executed in the aforementioned operating environment. For example, when the operating mode is real mode, if the aforementioned receive instruction cannot be executed in real mode, the determination result of step S712 is "yes"; if the aforementioned receive instruction can be executed in real mode, the determination result of step S712 is "no".

[0129] In one embodiment, the opcode of the newly added instruction and its supported runtime environments are stored in a lookup table. The conversion program 145 can use the opcode of the received instruction to look up the runtime environments in the lookup table. In another embodiment, the lookup table is stored in system management memory.

[0130] When the conversion program 145 determines that the received instruction has a decode exception (YES in step S712), step S725 is performed, and a conversion result shown in Table 2-2 below is generated. As shown in Table 2-2 below, the result field value of the conversion result is the second numerical value, indicating that the conversion has failed; and the content field of the conversion result is the exception number #UD (value 6) of the unknown instruction exception.

[0131] Table 2-2

[0132] Results Content Second value #UD

[0133] When the conversion program 145 determines that the received instruction has no decode exception (NO in step S712), step S715 is performed. In step S715, the conversion program 145 obtains other decode information of the received instruction. Specifically, the conversion program 145 continues to read the machine code of the received instruction from the memory one byte at a time, decodes the machine code while reading, until the other decode information of the received instruction is decoded, and the length of the received instruction is calculated, wherein the other decode information includes the operand mode (ModR / M), the source operand, and the destination operand, etc. Those skilled in the art know that the length of the received instruction can be calculated only after the decoding of the received instruction is completed. Then, the conversion program 145 performs step S720.

[0134] In step S720, the conversion program 145 converts the received instruction into at least one old instruction. Specifically, the conversion program 145 can convert the received instruction into at least one old instruction by means of a lookup table. For example, the at least one old instruction corresponding to the received instruction can be stored in a lookup table in advance. Then, the conversion program 145 obtains the at least one old instruction from the lookup table according to the opcode of the received instruction. In an embodiment, when the received instruction includes an escape code, the conversion program 145 obtains the at least one old instruction from the lookup table according to the escape code and the opcode of the received instruction. In another embodiment, the conversion program 145 obtains the at least one old instruction from the lookup table according to the escape code, the opcode, and the operand mode of the received instruction.

[0135] It is noted that since the at least one old instruction obtained from the lookup table does not contain other decode information such as the source operand and / or the destination operand of the received instruction, the other decode information needs to be written into the at least one old instruction so that the at least one old instruction can simulate the execution of the received instruction. For example, the conversion program 145 writes the specific values of the source operand and / or the destination operand of the received instruction into the corresponding locations in the at least one old instruction. Then, the processor 200 can simulate the execution of the new instruction by executing the at least one old instruction. In one embodiment, the conversion program 145 writes the other decode information into the at least one old instruction according to the prefix of the received instruction.

[0136] In one embodiment, the lookup table is stored in a basic input / output system (BIOS). As known to those skilled in the art, the system 100 executing the new instruction performs the BIOS when it is powered on. The BIOS contains code for initializing the system management mode, and when the system 100 executes the code for initializing the system management mode, the lookup table is loaded into the system management memory. Then, the conversion program 145 can obtain the at least one old instruction from the lookup table according to the opcode of the received instruction. In another embodiment, the lookup table is stored in a private read-only memory. Therefore, in these two embodiments, the conversion program 145 converts the received instruction into the at least one old instruction by using the hardware-supported lookup table.

[0137] In another embodiment, the conversion program 145 stores the at least one old instruction in a memory or a cache. When the processor 200 executes another instruction, if the another instruction is a new instruction, the conversion program 145 determines whether the received instruction and the another instruction are the same instruction. If the received instruction and the another instruction are the same instruction, the conversion program 145 directly obtains the at least one old instruction from the memory or the cache.

[0138] Then, the conversion program 145 performs step S725 to generate the conversion result shown in Table 2-3 below. As shown in Table 2-3 below, the result field of the conversion result has the first value, indicating that the conversion is successful, and the content field of the conversion result is the length of the received instruction and the at least one old instruction.

[0139] Table 2-3

[0140] Results Content First value Length of the received instruction and at least one old instruction

[0141] The following describes the execution of the conversion program 145 in the second case. Figure 7the process of the flowchart of Fig. 7. In the second case, the conversion program 145 performs the processes of steps S710, S712, S720 and S725 in the same way as in the first case, and thus will not be described here. The processes of steps S705 and S715 will be described below.

[0142] In the second case, the conversion program 145 first reads the machine code of the received instruction from the memory according to the instruction pointer of the received instruction in step S705, and then decodes the read machine code to obtain the operation code of the received instruction. In step S715, the conversion program 145 also decodes the machine code read in step S705 to obtain other decoding information of the received instruction. The other processes in the second case are the same as in the first case, and thus will not be described here.

[0143] It is worth noting that when the conversion program 145 reads the machine code according to the instruction pointer of the received instruction, the length of the received instruction is not known yet, so the machine code needs to be read long enough. For example, if the longest new instruction that the processor 200 can handle is 15 bytes long, at least 15 bytes of machine code need to be read in step S705.

[0144] The processes of the conversion program 145 in the third case will be described below. Figure 7 In the third case, the conversion program 145 performs the processes of steps S710, S712, S715, S720 and S725 in the same way as in the second case, and thus will not be described here. The process of step S705 will be described below.

[0145] In the third case, the conversion program 145 directly decodes the machine code in the information of the received instruction to obtain the operation code of the received instruction in step S705. The other processes in the third case are the same as in the second case, and thus will not be described here.

[0146] Figure 8 Fig. 7 is an example of processing an unknown instruction in the system management mode according to the first embodiment of the present application. Figure 8 Fig. 8 shows how to implement the processing flow of processing an unknown instruction as shown in Figs. 6 and 7 in the form of pseudo code. Figure 6 and Figure 7 Fig. 9 is a specific implementation of the emulator.

[0147] Fig. 10 shows the processes of the conversion program 145 in the fourth case. Figure 8The code included in the main function simulator_start for implementing the simulator is shown in lines 1-25. The code included in the decoding function check_decode_excep is shown in lines 27-36. The code included in the simulation function Unsupport_X_handle for implementing the function of the new instruction is shown in lines 38-47, which includes at least one old instruction corresponding to the received instruction as described above. The main function simulator_start is described first.

[0148] In the main function simulator_start, the code in line 3 is executed first. The code in line 3 completes the function of step S605 of Figure 6 , and the processor 200 establishes the simulation running environment. In the code in line 3, the processor 200 establishes the simulation running environment by calling the function setup_simulator_env. After the code in line 3 is executed, the processor 200 has saved the simulation identifier, the information of the received instruction, the running environment information of the received instruction, and the information of the architectural register read from the system management memory into the variable env. For example, in the code in line 4, the value of the simulation identifier is accessed by env.emulation_flag. The code in line 4 completes the function of step S610 of Figure 6 , and the processor 200 determines whether the simulation identifier is the first value. If the result of the determination in the code in line 4 is that the simulation identifier is not the first value, the code in line 5 is executed. The code in line 5 completes the function of step S645 of Figure 6 , and the processor 200 executes the normal processing flow of the system management mode. In the code in line 5, the processor 200 executes the normal processing flow of entering the system management mode by calling the function exit_to_normal_SMM. If the result of the determination in the code in line 4 is that the simulation identifier is the first value, the variable inst_emu is defined as the outgoing parameter of the decoding function check_decode_excep in line 9 (to be described later) in line 8, and then the code in line 9 is executed.

[0149] The code in lines 9-15 completes the function of step S615 of Figure 6The function of step S615 is that the processor 200 converts the aforementioned received instruction through a conversion program and generates a decoding result. Specifically, the processor 200 first executes line 9 of the code, obtaining the opcode and other decoding information of the aforementioned received instruction through the decoding function check_decode_excep, wherein the aforementioned decoding information is stored in the output parameter inst_emu. Then, the processor 200 executes line 10 of the code to determine whether the decoding was successful. In line 10 of the code, the processor 200 determines whether the decoding was successful based on the decoding result decode_excep. If the decoding fails, it indicates that the conversion has failed, and the processor 200 executes line 11 of the code. Line 11 of the code is then completed. Figure 6 In step S630, the processor 200 writes the simulation execution result of the conversion failure to the system management memory. In line 11, the processor 200 uses the function `set_exception` to write the simulation execution result of the conversion failure to the system management memory. After executing line 11, it executes line 12, then jumps to line 23. In line 12, the processor 200 uses the `goto` instruction to jump to the location of label `out` (i.e., line 23). Then it continues execution from line 23. Since line 23 only has label `out` and no code to execute, the processor 200 executes line 24. Line 24 completes. Figure 6 In step S635, the processor 200 executes an instruction to exit system management mode. In line 24, the processor 200 executes the instruction to exit system management mode through the function `execute_rsm`. Subsequently, the processor 200 will execute... Figure 1 The microcode for system management mode exit 1144 is shown. If the code in line 10 determines that decoding was successful, then the code in line 15 is executed. Line 15 completes. Figure 7 The function of step S720 is that the processor 200 converts the received instruction into at least one old instruction based on the information of the received instruction. For example... Figure 8 As shown, in line 15, the at least one legacy instruction is retrieved from the `op_mapping` table using the opcode for receiving the instruction. A pointer `routine` represents this legacy instruction, and its value is the address of the `Unsupport_X_handle` function. Then, line 16 is executed.

[0150] Line 16 of code completed. Figure 6The processor 200 executes the at least one old instruction in response to the function of step S625. When executing the routine, the processor 200 actually executes a simulation function Unsupport_X_handle (to be described later). After executing the routine, a value runtime_excep is returned. Then, the code of lines 18-19 is executed. The code of lines 18-19 performs the function of step S630. The processor 200 determines whether a runtime exception exists. If a runtime exception exists, the processor 200 writes the simulation execution result of the runtime exception into the system management memory. In line 18, the processor 200 determines whether a runtime exception exists according to the value of the returned value runtime_excep. If a runtime exception exists, the code of line 19 is executed. In line 19, the processor 200 stores the simulation execution result of the runtime exception into the system management memory by using the function set_exception. Then, the processor 200 executes the code of line 20 and jumps to line 23 by using the goto instruction. As mentioned above, the processor 200 will execute the code of line 24 next. The function of the code of line 24 has been described above and will not be described again here. Figure 6

[0151] The decoding function check_decode_excep will be described below.

[0152] In the decoding function check_decode_excep, the code of lines 29-30 is executed first to obtain the operation code opcode of the received instruction (step S705). In line 29, the processor 200 reads the machine code machine_code of the received instruction by using the function read_instruction. Here, the machine code machine_code of a length of code_len bytes is read from the memory according to the instruction pointer ip of the received instruction (i.e., the second case mentioned above). The value of code_len can be 15. In line 30, the processor 200 decodes the machine code machine_code to obtain the operation code opcode of the received instruction by using the function decode_opcode. In line 31, the processor 200 determines whether the received instruction is a new instruction by using the function is_emulate_op according to the operation code opcode. Figure 7 Figure 7 Figure 7 ​​​the step S710). If the received instruction is not the new instruction, the processor 200 executes the code in the line 32 to return the decoding exception information to the main function simulator_start through the return instruction. If the received instruction is the new instruction, the processor 200 first executes the code in the line 33 to store the operation code opcode in the outgoing parameter inst_emu; then executes the code in the line 34 to obtain other decoding information of the received instruction (operands) Figure 7 the step S715), and stores the obtained other decoding information in the outgoing parameter inst_emu. Finally, the processor 200 executes the code in the line 35 to return the decoding success information to the main function simulator_start through the return instruction. The main function simulator_start can obtain the operation code opcode and the other decoding information operands of the received instruction through the outgoing parameter inst_emu.

[0153] The simulation function Unsupport_X_handle is described as follows.

[0154] In the simulation function Unsupport_X_handle, the codes in the lines 40-41 are executed first. The codes in the lines 40-41 complete the operation of reading the values of the operands, and the read values of the operands are stored in the array op. In the line 41, the processor completes the operation of reading the operands through the function read_op. Specifically, the read_op function obtains the values of the operands from the aforementioned env variable. The code in the line 42 completes the operation of reading the values of the operands, and the read values of the operands are stored in the array op. In the line 42, the processor completes the operation of reading the operands through the function read_op. Specifically, the read_op function obtains the values of the operands from the aforementioned env variable. Figure 6The function of step S625 is that processor 200 executes at least one old instruction, that is, processor 200 simulates the execution of the aforementioned receive instruction. In line 42, op represents the operand of the aforementioned receive instruction, and operate withop means writing the value of the operand of the aforementioned receive instruction into the aforementioned at least one old instruction and executing the aforementioned at least one old instruction. Then, line 43 is executed. Line 43 completes the function of step S630 in Figure 6, whereby processor 200 writes the simulated execution result (including the simulated execution result that generated a runtime exception and the simulated execution result that did not generate a runtime exception) into system management memory. More specifically, in line 43, processor 200 stores the simulated execution result into system management memory through the function write_result_to_SMRAM. Line 44 determines whether a runtime exception occurred when executing line 42. If a runtime exception occurred, line 45 is executed, sending the exception information to the main function; otherwise, line 46 is executed, sending the execution success information to the main function. In lines 45 and 46, processor 200 sends exception information or correct execution information to the main function simulator_start via the return instruction.

[0155] Figures 9A-9B This is a flowchart illustrating the exit system management mode according to the first embodiment of the present invention. Figures 9A-9B To and Figure 1 The processing flow of the microcode processing program corresponding to system management mode exit 1144 is shown below. Please refer to... Figure 2 As shown in Figure 9, Figures 9A-9B As shown, when exiting system management mode, processor 200 determines whether the simulation flag is the first value (S901). If the determination result is "yes", processor 200 resets the simulation flag (S904) and determines whether there is an exception in the simulation execution result (S905). Processor 200 performs the operation of exiting system management mode according to whether there is an exception in the simulation execution result and the type of exception. The detailed explanation is as follows: Processor 200 first executes step S901.

[0156] In step S901, the processor 200 determines whether the simulated identifier is the first value. Specifically, the processor 200 reads the simulated identifier from the system management memory (as described above). Figure 5As described in step S520, the simulated identifier is stored in the system management memory, and then it is determined whether the read simulated identifier is the first value. If the simulated identifier is not the first value, the processor 200 executes step S903. In step S903, the processor 200 executes the normal process for exiting the system management mode. The normal process for exiting the system management mode is common knowledge to those skilled in the art and will not be described in detail here. If the simulated identifier is the first value, the processor 200 executes step S904.

[0157] In step S904, processor 200 resets the emulation flag. Specifically, processor 200 sets the emulation flag in microarchitecture register 220 and system management memory to a second value. After resetting the emulation flag, processor 200 will execute the normal processing flow of system management mode when a normal system management interrupt occurs during subsequent execution. Then, processor 200 executes step S905.

[0158] In step S905, the processor 200 determines whether there is an anomaly in the simulation execution result. Specifically, the processor 200 reads the anomaly vector table shown in Table 4 above from the system management memory. If the value of the anomaly identifier field in the anomaly vector table is the first value, it indicates that there is an anomaly in the simulation execution result, and the judgment result is "yes"; if the value of the anomaly identifier field in the anomaly vector table is the second value, it indicates that there is no anomaly in the simulation execution result, and the judgment result is "no". If the judgment result is "no", the processor 200 executes step S907.

[0159] like Figure 9B As shown, in step S907, the processor 200 stores the simulated execution results stored in the system management memory into the architecture register. As mentioned earlier, in Figure 6 In step S630, the processor 200 has already written the simulated execution result of the aforementioned receive instruction into the area corresponding to the architecture register in the system management memory. In this step, the processor 200 stores the value in the area corresponding to the architecture register in the system management memory into the architecture register 260. This is equivalent to the processor 200 having completed executing the aforementioned receive instruction.

[0160] If the destination operand of the aforementioned received instruction is a new architecture register, since the processor 200's architecture register 260 does not contain a new architecture register, the processor 200 will not store the value of the region simulating the new architecture register in system management memory into architecture register 260. As mentioned earlier, when the processor 200 is simulating the execution of another new instruction, and the operand of the other new instruction is also the aforementioned new architecture register, the processor 200 can directly use the value stored in the region simulating the aforementioned new architecture register in system management memory to simulate the execution of the other new instruction.

[0161] Then, processor 200 executes step S909. In step S909, processor 200 enables interrupts. For example, processor 200 sets the IF flag to enable maskable interrupts, sets the TF flag to enable single-step interrupts, and sets DR7 to enable breakpoint interrupts. Then, processor 200 executes step S911.

[0162] In step S911, the processor 200 sends an exit from system management mode notification (Deassert#smmact) to notify the chipset processor 200 that it has exited system management mode. Then, the processor 200 executes step S913 to exit system management mode.

[0163] like Figure 9A As shown, when the processor 200 determines that there is an abnormality in the simulation execution result in step S905, step S915 is executed.

[0164] In step S915, the processor 200 determines whether the exception type is a trap. Specifically, the processor 200 determines whether the exception in the simulated execution result is a trap based on the exception identifier and exception number in the exception vector table read from the system management memory in step S905. For example, when the exception identifier is the first value and the exception number is 3 (as shown in Table 4-2 below), it indicates an overflow exception. The overflow exception is a trap, so the judgment result is "yes". When the exception identifier is the first value and the exception number is 0 (as shown in Table 4-3 below), it indicates a division error exception. The division error exception is a fault, not a trap, so the judgment result is "no".

[0165] Table 4-2

[0166] Exception identification Exception number First value 3

[0167] Table 4-3

[0168] Exception identification Exception number First value 0

[0169] When the result of the determination in step S915 is "No", the processor 200 executes steps S917, S919, S921 and S723. Among them, steps S917, S919 and S921 are the same as steps S909, S911 and S913 respectively, and will not be described here. Step S923 will be described below.

[0170] In step S923, the processor 200 executes the microcode processing program of the exception. Specifically, the processor 200 determines whether an exception has occurred according to the exception identifier in the exception vector table stored in the system management memory. If an exception has occurred, the processor 200 executes the microcode processing program of the exception according to the exception number stored in the exception vector table. That is, the microcode processing program of the exception corresponding to the exception number is executed. For example, when the exception identifier in the exception vector table stored in the system management memory is the first value, it indicates that the simulation execution result has an exception. If the exception number in the exception vector table at this time is 0, it indicates that the exception is a division error, and the processor 200 will execute the microcode processing program of the division error.

[0171] In step S915, when the result of the determination is "Yes", that is, the type of the simulation execution result exception is a trap, the processor 200 executes steps S925, S927, S929 and S933 as shown in FIG. 9. Figure 9B Among them, steps S925, S927, S929 are the same as steps S907, S909, S911 respectively, and will not be described here. Step S933 will be described below.

[0172] In step S933, the processor 200 executes the microcode processing program of the exception. For example, when the simulation execution result has an exception, and the exception is an overflow exception, the processor 200 executes the microcode processing program of the overflow exception. In the actual operation of exiting the system management mode through the system management interrupt exit 1144 as shown in FIG. 10, those skilled in the art can add some microcodes to the microcode corresponding to the exit of the system management mode after calling the instruction of resuming from the system management mode (RSM) to store the simulation execution result from the system management memory to the architectural register, so as to pass the simulation execution result to the application 130 or the operating system 120. Since these microcodes will be different depending on the processor version, those skilled in the art can write the corresponding microcode according to the actual situation. Figure 9A 、 9B In the actual operation of exiting the system management mode through the system management interrupt exit 1144 as shown in FIG. 10, those skilled in the art can add some microcodes to the microcode corresponding to the exit of the system management mode after calling the instruction of resuming from the system management mode (RSM) to store the simulation execution result from the system management memory to the architectural register, so as to pass the simulation execution result to the application 130 or the operating system 120. Since these microcodes will be different depending on the processor version, those skilled in the art can write the corresponding microcode according to the actual situation.

[0173] Note that in the first embodiment, the micro-architecture register 220 is a register that originally exists in the processor 200. Therefore, in the first embodiment of the present application, the new instruction can be executed on a previous generation processor without modifying the hardware structure of the processor. Thus, in the first embodiment of the present application, the already manufactured processor can be upgraded by microcode to execute the new instruction.

[0174] [Second Embodiment]

[0175] Figure 10 is a schematic diagram showing a system 1000 that executes a new instruction according to the second embodiment of the present application. As in the first embodiment shown in Figure 1 , the system 1000 includes a processor 1100 and a memory 1200. However, unlike the first embodiment shown in Figure 10 , the translation program 145 in the system 1000 that executes a new instruction shown in runs directly on the processor in the same execution mode as the new instruction. In addition, since the translation program 145 in the second embodiment runs in the same execution mode as the new instruction, the processor does not need to switch execution modes when executing the translation program 145. The differences between the second embodiment and the first embodiment are described in detail below.

[0176] Figure 10 As shown in Figure 10 , when the instruction 118 is an unknown instruction 132, the processor 1100 executes a microcode processing program that handles an unknown instruction exception. In the microcode processing program that handles an unknown instruction exception, the translation program 145 is called directly (as shown by the solid arrow 2 in Figure 10 ). The translation program 145 determines whether the unknown instruction 132 is a new instruction. If the unknown instruction 132 is a new instruction, the translation program 145 converts it into at least one old instruction and sends the at least one old instruction to the microcode processing program that handles an unknown instruction exception (as shown by the solid arrow 6 in ).

[0177] Figure 11 is a block diagram of a processor according to the second embodiment of the present application. Figure 11 The functions of the elements with the same names in Figure 2 are the same, and thus are not described again.

[0178] Note that, as shown in Figure 11 , the processor 1100 on the left side of the dotted line is Figure 10The schematic diagram of processor 110 shows that the transition program 145, located to the right of the dashed line, runs on processor 1100 in the same execution mode as the newly added instruction (i.e., the processor does not need to switch execution modes). The transition program 145 can be stored in the interrupt preprocessing unit 112 within the processing core of processor 1100. In another embodiment, the transition program 145 can be stored in an uncore of processor 1100. Therefore, all processing cores of processor 1100 can share the transition program 145.

[0179] Figure 12 This is a flowchart illustrating the execution of a newly added instruction according to a second embodiment of the present invention. Figure 12 The processing flow shown can be generated by Figure 11 The processor 1100 executes. For example... Figure 12 As shown, processor 1100 receives an instruction (S1205). When the received instruction is an unknown instruction, an unknown instruction exception is issued (S1210). In response to the unknown instruction exception, a conversion program determines whether the received instruction is a new instruction (S1215). When the received instruction is a new instruction, the conversion program converts the received instruction into at least one old instruction (S1220). Finally, processor 1100 executes the at least one old instruction in the same execution mode as the received instruction (S1225). Figure 12 Steps S1205, S1210 and Figure 3 Steps S305 and S310 are the same, so they will not be repeated here. Figure 3 Steps S320 and S325 with Figure 12 The difference between steps S1220 and S1225 is that... Figure 3 Steps S320 and S325 run in system management mode, while Figure 12 Steps S1220 and S1225 are executed in the same execution mode as the above-mentioned receiving instruction. Figure 3 Steps S320 and S325 with Figure 12 Steps S1220 and S1225 perform the same function, so they will not be described again here. Only step S1215 will be described below.

[0180] In step S1215, in response to the unknown instruction exception, the processor 1100 judges whether the received instruction is a new instruction through a conversion program. Specifically, after the instruction submission unit 245 issues the unknown instruction exception, the processor 1100 executes a microcode processing program for handling the unknown instruction exception. In the microcode processing program for handling the unknown instruction exception, the processor 1100 sends the information of the received instruction and the running environment information to the conversion program 145. The conversion program 145 judges whether the received instruction is a new instruction according to the information of the received instruction. As to how the conversion program 145 judges whether the received instruction is a new instruction, it has been described in detail in the first embodiment, and thus will not be described here.

[0181] Figure 13 is a flowchart showing the process of handling the received instruction according to the second embodiment of the present application. Figure 13 Steps S1305, S1310, S1325 of Figure 4 are the same as steps S405, S410, S435 of, and thus will not be described here. Step S1320 will be described below.

[0182] In step S1320, Figure 11 the processor 1100 handles the received instruction. Specifically, when the received instruction is an unknown instruction (the result of the judgment in step S1310 is "Yes"), the processor 1100 executes the microcode processing program for handling the unknown instruction exception. In the microcode processing program for handling the unknown instruction exception, the processor 1100 handles the unknown instruction through the conversion program 145 (which will be described in detail below). Figure 14

[0183] Figure 14 is a flowchart showing the process of handling the received instruction in the microcode processing program for handling the unknown instruction exception according to the second embodiment of the present application. As Figure 14 shown, Figure 11 the processor 1100 of acquires the information of the received instruction (S1405), converts the received instruction through the conversion program 145, and generates a conversion result (S1410). If the conversion is successful (the result of the judgment in step S1415 is "Yes"), the processor 1100 acquires at least one old instruction from the conversion result, and executes the at least one old instruction (S1420). The processor 1100 first executes step S1405.

[0184] In step S1405, the information of the received instruction is obtained in the microcode processing program of the unknown instruction exception. The information of the received instruction includes the instruction pointer of the received instruction. It is worth noting that since the received instruction has not been decoded at this time, the information of the received instruction does not include the decoded information such as the prefix, the escape code and the operation code. When the microcode processing program of the unknown instruction exception is executed, the running environment of the processor 1100 does not change since no mode switching is needed. Therefore, in the microcode processing program of the unknown instruction exception, the running environment information of the processor 1100, which is the running environment information of the received instruction, can be obtained directly. Then, step S1410 is executed.

[0185] In step S1410, the processor 1100 converts the received instruction by the conversion program 145 and generates a conversion result. As to how the conversion program 145 converts the received instruction, the process is the same as that in the first embodiment, and thus will not be described here. Steps S1415 and S1420 are the same as steps S620 and S625 of the first embodiment, and thus will not be described here. Steps S1425 and S1430 will be described below. Figure 6

[0186] When the conversion by the conversion program 145 is successful (YES in step S1415), the processor 1100 executes step S1420. In step S1420, the processor 1100 obtains at least one old instruction from the conversion result and executes the at least one old instruction. In addition, the processor 1100 can also obtain the length of the received instruction from the conversion result. In an embodiment, the next instruction of the received instruction is another instruction. The last instruction of the at least one old instruction is a jump instruction or a call instruction, and the processor 1100 jumps to the another instruction by the jump instruction or the call instruction. The instruction pointer of the another instruction is EIP+Length, where EIP is the instruction pointer of the received instruction and Length is the length of the received instruction.

[0187] When the conversion by the conversion program 145 fails (NO in step S1415), the processor 1100 executes step S1425. In step S1425, the processor 1100 handles the exception. Specifically, any exception that occurs when the conversion program 145 converts the received instruction will result in a conversion failure. In the microcode processing program of the unknown instruction exception that handles the exception of the interrupt pre-processing unit 112, an exception number can be obtained from the content field of the conversion result. Then, the microcode processing program of the unknown instruction exception raises an exception corresponding to the exception number. In response to the exception corresponding to the exception number, the processor 1100 executes a corresponding microcode processing program to handle the exception. ​

[0188] The processing flow of the conversion program of the second embodiment is the same as that of the first embodiment, and thus is not described here. Figure 7 The processing flow of the conversion program is the same as that of the first embodiment, and thus is not described here.

[0189] In summary, the difference between the first embodiment and the second embodiment is that, in the second embodiment, when the processor 1100 executes an unknown instruction, the processor 1100 directly executes the conversion program 145 in the same execution mode as the unknown instruction. The conversion program 145 determines whether the unknown instruction is a new instruction. When the unknown instruction is a new instruction, the conversion program 145 converts the new instruction into at least one old instruction. Then, the processor 1100 executes the at least one old instruction in the same execution mode as the unknown instruction. Compared with the first embodiment, in the second embodiment, the processor does not need to switch the execution mode, and thus the efficiency of emulating the new instruction is higher.

[0190] [Third Embodiment]

[0191] Figures 15A-15B is a schematic diagram showing a system 1500 for executing a new instruction according to the third embodiment of the present application. The difference between the system 1500 shown in Figure 1 and the system 100 shown in Figure 10 is that, in the third embodiment, the conversion program 145 in the system 1500 for executing a new instruction is run by a kernel driver 150 in the operating system 120. The conversion program 145 can be located inside (as shown in Figure 15A ) or outside (as shown in Figure 15B ) the kernel driver 150. Please refer to Figure 11 and Figures 15A-15B When the processor 1100 determines that the instruction 118 is an unknown instruction 132, the processor 1100 will issue an unknown instruction exception. In response to the unknown instruction exception, the processor 1100 executes a microcode processing program of the unknown instruction exception. In the microcode processing program of the unknown instruction exception, the processor 1100 will call the kernel driver 150, and send the information of the unknown instruction 132 and the running environment information to the kernel driver 150. The kernel driver 150 processes the received instruction through the conversion program 145.

[0192] In one embodiment, in the microcode handler of the unknown instruction exception, the processor 1100 invokes the kernel driver 150 through a self-defined interrupt service routine (the developer of the interrupt service routine can invoke the self-defined interrupt handler through a self-defined interrupt vector #NE (Non-support instruction Emulator) in the reserved number of the interrupt vector table). It is worth noting that the interrupt service routine must pass the information of the unknown instruction 132 (including the instruction pointer, etc.) and the running environment information to the kernel driver 150, or inform the kernel driver 150 of the storage address of the information of the unknown instruction 132 and the running environment information. Furthermore, the interrupt service routine (the interrupt service routine corresponding to the self-defined interrupt vector #NE) used by the kernel driver 150 can be the microcode stored in the interrupt pre-processing unit 112 and invoked by the interrupt pre-processing unit 112 (the interrupt pre-processing unit 112 can be constructed by a state machine or a combination logic circuit). In one embodiment, the kernel driver 150 can call the operating system 120 to execute the kernel driver 150 through the system call (System call) in the manner of the processor 1100 processing the unknown instruction 132 through the conversion program 145, for example, the kernel driver 150 is taken as a callback function, and the information of the unknown instruction 132 and the running environment information are taken as parameters passed to the kernel driver 150. If the unknown instruction 132 is a new instruction, the kernel driver 150 returns at least one old instruction to the processor 1100 after processing the unknown instruction 132 through the conversion program 145. In addition, the kernel driver 150 can be invoked through an internal interrupt or a trap, for example, the designer of the processor 1100 defines an interrupt vector #NE, and enters the core of the operating system to call the kernel driver 150 through the interrupt vector #NE, and the skilled in the art should know the technical details of this part and thus will not be described herein. In one embodiment, in the microcode handler of the unknown instruction exception, the process of sending the information of the unknown instruction 132 and the running environment information is as follows: the information of the unknown instruction 132 and the running environment information are pushed into the stack, and then the kernel driver 150 obtains the information of the unknown instruction 132 and the running environment information from the stack.

[0193] In another embodiment, the interrupt service routine in the operating system for handling unknown instruction exception can be modified to directly call the kernel driver 150 to implement the processing of the unknown instruction 132. In the modified interrupt service routine for handling unknown instruction exception, the information of the unknown instruction 132 and the running environment information can be read first, and then transmitted to the kernel driver 150. In this embodiment, the hardware and / or microcode of the processor do not need to be modified, and the processing of the unknown instruction as described above can be implemented by modifying the interrupt service routine for handling unknown instruction exception in the operating system, which is quite convenient to implement. In actual operation, the interrupt service routine for handling unknown instruction exception can be modified by those skilled in the art to add the functions of reading the information of the unknown instruction 132 and the running environment information, and calling the kernel driver 150. Since the interrupt service routine for handling unknown instruction exception varies with the operating system and / or the version of the processor, the corresponding code can be written by those skilled in the art according to the actual situation.

[0194] Figure 16 is a flowchart of processing a received instruction according to the third embodiment of the present application. Figure 16 Steps S1605, S1610 and S1625 of Figure 13 Steps S1305, S1310 and S1325 of Step S1620 is described below.

[0195] Please refer to the processing flow shown in Figure 11 , Figures 15A-15B and Figure 16 , Figure 16 which can be executed by the processor 1100 of Figure 11 In step S1620, the processor 1100 processes the received instruction. Specifically, when the received instruction is an unknown instruction, in the microcode processing program for handling unknown instruction exception, the processor 1100 calls the conversion program 145 to process the received instruction through the kernel driver 150 of the operating system 120. It should be noted that, compared with the second embodiment, in step S1320 of Figure 13 when the received instruction is an unknown instruction, in the microcode processing program for handling unknown instruction exception, the processor 1100 directly processes the received instruction through the conversion program 145.

[0196] In an embodiment, the conversion program 145 is a driver or an application program of the operating system 120. The other processing flows in the third embodiment are the same as those in the second embodiment, which will not be described here.

[0197] In the third embodiment, the microcode handler for handling unknown instruction exception executes the kernel driver 150 of the operating system 120 to continue processing the convertible new instruction when the processor 1100 executes an unknown instruction. In the third embodiment, the kernel driver of the operating system is used to convert the new instruction by the conversion program. Updating the kernel driver and the conversion program is more convenient and faster than updating the hardware of the processor and / or the microcode in the processor, thereby improving the development efficiency.

[0198] [Fourth Embodiment]

[0199] Figure 17 is a schematic diagram showing a system 1700 for executing a new instruction according to the fourth embodiment of the present application. In the fourth embodiment, the conversion program 145 in the system 1700 for executing a new instruction is also run by the kernel driver 150 in the operating system 120, as in the third embodiment. The difference is that, in the fourth embodiment, the conversion program 145 is run on a dedicated processing core 190. The kernel driver 150 sends the information of the unknown instruction 132 and the running environment information to the conversion program 145 by polling or doorbell mechanism. The conversion program 145 also needs to send the conversion result to the kernel driver 150 by polling or doorbell mechanism. The specific data transmission between the kernel driver 150 and the conversion program 145 by polling or doorbell mechanism will be described below.

[0200] First, the polling mechanism will be described. Please refer to Figure 11 and Figure 17 In an embodiment, the designer of the processor 1100 can set a transmission register (not shown) in the uncore of the processor 1100 to store the information of the unknown instruction 132, the running environment information, a transmission information identifier and a transmission result identifier (all not shown in the figure). Figure 17The kernel driver 150 stores the information of the unknown instruction 132 and the running environment information into the above-mentioned transfer register, and stores the transfer information identifier with the first value into the above-mentioned transfer register. Then, the kernel driver 150 reads the transfer result identifier in the transfer register every fixed time (for example, every 100 milliseconds) to wait for receiving the conversion result. If the transfer result identifier is read as the first value, it indicates that the conversion program 145 has generated the conversion result, and the kernel driver 150 reads the conversion result from the transfer register. In addition, the conversion program 145 running on the special processing core 190 is set to check whether the transfer information identifier in the transfer register is the first value every fixed time (for example, every 100 milliseconds) when it is idle. If the transfer information identifier in the transfer register is the first value, the conversion program 145 reads the information of the unknown instruction 132 and the running environment information from the above-mentioned transfer register, and then sets the transfer information identifier in the transfer register as the second value. Then, the conversion program 145 performs the conversion processing on the unknown instruction 132 according to the method described above to generate the conversion result. Then, the conversion program 145 stores the above-mentioned conversion result into the transfer register, and stores the transfer result identifier with the first value into the transfer register. As described above, since the transfer result identifier is the first value, the kernel driver 150 reads the conversion result from the transfer register, and sets the transfer result identifier in the transfer register as the second value. Thus, the data transmission between the kernel driver 150 and the conversion program 145 is completed. In another embodiment, under the multi-core processor architecture, the number of the processing core also needs to be stored in the transfer register or a special storage space for each processing core is allocated in the transfer register, so that the kernel driver 150 running on each processing core can perform the data transmission with the conversion program 145.

[0201] The doorbell mechanism is described below. Reference is also made to Figure 11 With Figure 17 In an embodiment, the designer of the processor 1100 can set a transfer register (not shown) in the non-core of the processor 1100 to store the information of the unknown instruction 132 and the running environment information (both not shown in the figure). The transfer register is used to store the information of the unknown instruction 132 and the running environment information, and the transfer information identifier with the first value. The transfer register is also used to store the transfer result identifier with the first value. The transfer register is also used to store the number of the processing core. Figure 17The kernel driver 150 stores the information of the unknown instruction 132 and the running environment information into the transfer register, and then notifies the conversion program 145 running on the special processor 190 through an interrupt. In response to the interrupt, the conversion program 145 reads the information of the unknown instruction 132 and the running environment information from the transfer register, and generates a conversion result. Then, the conversion program 145 stores the conversion result into the transfer register, and notifies the kernel driver 150 through an interrupt. In response to the interrupt, the kernel driver 150 reads the conversion result from the transfer register. Thus, the data transmission between the kernel driver 150 and the conversion program 145 is completed. As to how to set the interrupt, for example, the kernel driver 150 and the conversion program 145 can define their own interrupt service programs and their own corresponding interrupt vector numbers, which have been described above, and thus will not be described here. In another embodiment, a hardware interrupt signal line (PIN) can be added to the processor 1100 and / or the special processor 190, and the kernel driver 150 and / or the conversion program 145 can trigger the interrupt through the hardware interrupt signal line to complete the data transmission.

[0202] The other processing flows in this embodiment are the same as those in the third embodiment, and thus will not be described here.

[0203] In another embodiment, the functions of the conversion program 145 described in the first embodiment, the second embodiment and the fourth embodiment can be implemented in a hardware circuit.

[0204] As can be seen from the above, in this embodiment, the kernel driver 150 of the operating system 120 also implements the conversion of the new instruction, which is the same as the third embodiment. However, in this embodiment, the conversion program 145 runs on the special processing core 190, which is different from the third embodiment. In this embodiment, the conversion program 145 runs on the special processing core 190, and thus the execution speed is faster. In addition, since a conversion program 145 does not need to run on each processing core, the work burden of other processing cores of the processor is reduced.

[0205] Figure 18 is a flowchart of executing a new instruction according to an embodiment of the present application. Please refer to Figure 11 、 17, 18. As described above with respect to the third embodiment and the present embodiment, the processor 1100 receives an instruction (S1805). When the received instruction is an unknown instruction, the processor 1100 executes a conversion program (S1810) via the operating system 120. In the conversion program, it is determined whether the received instruction is a new instruction (S1815), and when the received instruction is a new instruction, the received instruction is converted into at least one old instruction (S1820). Finally, the processor 1100 executes the at least one old instruction (S1825). Figure 18 The steps S1805, S1815, S1820, and S1825 have been described in detail with respect to the first embodiment, and thus will not be described again. The step S1810 will be described below.

[0206] In the step S1810, when the received instruction is an unknown instruction, the processor 1100 executes a conversion program via the operating system. Specifically, as described above with respect to the third embodiment and the present embodiment, when the received instruction is an unknown instruction, the instruction submission unit 245 issues an unknown instruction exception. In response to the unknown instruction exception, the processor 1100 executes a microcode handling program of the unknown instruction exception. In the microcode handling program of the unknown instruction exception, the kernel driver 150 of the operating system is invoked. The kernel driver 150 of the operating system invokes the conversion program 145.

[0207] Figure 19 is a flowchart showing a procedure of executing a new instruction according to an embodiment of the present application. Please refer to Figure 11 , 17 , 19. As described above with respect to the first embodiment, the second embodiment, the third embodiment, and the present embodiment, the processor 1100 receives an instruction (S1905). When the received instruction is an unknown instruction, the processor 1100 starts a conversion program (S1910). In the conversion program, it is determined whether the received instruction is a new instruction (S1915), and when the received instruction is a new instruction, the received instruction is converted into at least one old instruction (S1920). Finally, the processor 1100 simulates execution of the received instruction by executing the at least one old instruction (S1925). Figure 19 The steps S1905, S1915, S1920, and S1925 have been described in detail with respect to the first embodiment, and thus will not be described again. The step S1910 will be described below.

[0208] In step S1910, when the received instruction is an unknown instruction, the processor 1100 initiates a conversion program. Specifically, as described above with respect to the first embodiment, the second embodiment, the third embodiment, and the present embodiment, when the received instruction is an unknown instruction, the instruction submission unit 245 issues an unknown instruction exception. In response to the unknown instruction exception, the processor 1100 executes a microcode handling program for the unknown instruction exception.

[0209] Specifically, in the first embodiment, the microcode handling program for the unknown instruction exception issues a system management interrupt (#SMI). In response to the system management interrupt, the processor 1100 enters a system management mode. In the system management mode, the emulator 142 is initiated, and the conversion program 145 is initiated by the emulator 142. In the second embodiment, the microcode handling program for the unknown instruction exception directly initiates the conversion program 145. In the third embodiment and the present embodiment, the microcode handling program for the unknown instruction exception calls the kernel driver 150 of the operating system 120. The kernel driver 150 of the operating system 120 then calls the conversion program 145.

[0210] Figure 20 is a flowchart showing a process of converting a new instruction according to an embodiment of the present application. Please refer to Figure 11 , 17 , 20, as described above with respect to the first embodiment, the second embodiment, the third embodiment, and the present embodiment, the conversion program 145 receives an instruction, wherein the instruction is an unknown instruction (S2005), and determines whether the received instruction is a new instruction (S2010). When the received instruction is a new instruction, the conversion program 145 converts the received instruction into at least one old instruction (S2015). In the foregoing, steps S2005, S2010, and S2015 have been described in detail, and thus will not be described here. Figure 20

[0211] With respect to the embodiments of the present application that have been described, an exemplary operating environment for implementing embodiments of the present application is described below. Specifically refer to Figure 21 , Figure 21 is a flowchart showing a process of converting a new instruction according to an embodiment of the present application. Please refer to

[0212] ​The application can be implemented in a computing or processing device using instructions that can be computer-executable. The instructions can be program modules trained by or for the computer or other machine, such as a personal digital assistant or other portable device. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application can be practiced in a variety of system configurations, including hand-held devices, consumer electronics, general- purpose computers, more specialty computing devices, etc. The application can also be practiced in distributed computing environments where tasks are performed by remote-processing devices that are linked through a communications network.

[0213] See Figure 21 The computing device 2100 includes a bus 2110, a memory 2112, one or more processors 2114, one or more display elements 2116, input / output (I / O) ports 2118, input / output (I / O) elements 2120, and a power supply 2122 coupled with the bus 2110. The bus 2110 can be one or more busses of various types (e.g., address bus, data bus, or a combination thereof). While Figure 21 Although various items are illustrated as being stored in memory or on the computer, these items or portions of them can be transferred between computer and / or computer-readable media devices by one or more various types of transport, such as optical, electrical, magnetic, or other technologies.

[0214] The computing device 2100 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computing device 2100 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media can comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computing device 2100. Computer storage media does not, however, include signals per se.

[0215] Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared and other wireless media. Combinations of the above are also included within the scope of computer-readable media.

[0216] Memory 2112 includes computer-storage media in the form of volatile and / or nonvolatile memory. The memory can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, etc. The system management memory in the first embodiment is located in memory 2112.

[0217] Computing device 2100 includes one or more processors 2114 that read data from various entities such as memory 2112 or I / O elements 2120. Display element 2116 presents data indications to a user or other devices. Exemplary display elements include a display device, speaker, printing element, vibrating element, etc.

[0218] I / O ports 2118 allow computing device 2100 to be logically coupled to other devices including I / O elements 2120, some of which can be built in. Exemplary elements include a microphone, joystick, game pad, disk controller, satellite dish, scanner, printer, wireless device, etc. The I / O elements 2120 can provide a natural user interface (NUI) that processes audio, speech, or other physiological inputs generated by a user. Such inputs can be transferred to a suitable network element for further processing in some examples. The natural user interface can implement any combination of speech recognition, touch and stylus recognition, facial recognition, biometric recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, and touch recognition associated with displays 2116. The computing device 2100 can be equipped with depth cameras, such as stereoscopic camera systems, infrared camera systems, RGB camera systems, and combinations of these, for example, to perform gesture detections and recognitions. Additionally, the computing device 2100 can be equipped with accelerometers or gyroscopes that enable detection of motion. The output of the accelerometers or gyroscopes can be provided to the computing device 2100 to render immersive augmented reality or virtual reality.

[0219] Furthermore, the processors 2114 of the computing device 2100 can execute instructions and / or data stored in the memory 2112 to implement aspects of the embodiments described above, or to otherwise perform the methods described in the specification.

[0220] Any particular order or hierarchy of steps in the processes disclosed herein is purely illustrative. It is to be understood that the disclosure can be practiced with the order or hierarchy of any particular steps rearranged, so it is recognized that any particular order or hierarchy of steps that is disclosed herein is simply an example. The accompanying method claims present elements of the various steps in a sample order, and as such should not be taken as a limitation on the order in which such elements are presented in the various claims.

[0221] The use of "first", "second", "third", etc. adjectives in the claims to modify elements is not intended to connote any priority, precedence, order of use or occurrence, or temporal sequence, but merely to distinguish different elements having the same name (with different adjectives).

[0222] The method for executing the new instruction and the system for executing the new instruction provided by the present application can execute the new instruction on the previous generation processor without modifying the hardware architecture of the processing core.

[0223] The above description is merely illustrative of the application and is not intended to limit the scope of the application. Any variations and modifications of the application that are apparent to those skilled in the art are intended to be within the scope of the application. Accordingly, the scope of the application is to be limited only by the scope of the claims appended hereto.

Claims

1. A method for executing newly added instructions in a processor, characterized in that, include: Receive instructions; When the above received instruction is an unknown instruction, an unknown instruction is issued abnormally. The above unknown instruction is an instruction that is not natively supported by the above processor. In response to the aforementioned unknown instruction exception, the following conversion procedure is used: Determine whether the above received instruction is a new instruction. The above new instruction is an instruction that is added and supported by the successor processor of the above processor and cannot be recognized by the above processor. When the above-mentioned receive instruction is a new instruction, the above-mentioned receive instruction is converted into at least one old instruction, which is an instruction natively supported by the processor. Furthermore, in the same execution mode as the aforementioned received instruction, at least one of the aforementioned old instructions is executed without switching execution modes.

2. The method for executing a new instruction as described in claim 1, wherein, The aforementioned receive instruction is an instruction set architecture instruction, and at least one of the aforementioned legacy instructions is an instruction set architecture instruction.

3. The method for executing a new instruction as described in claim 1, wherein, The aforementioned receiving instructions are x86 instructions, ARM instructions, RISC-V instructions, or MIPS instructions, and at least one of the aforementioned legacy instructions is an x86 instruction, ARM instruction, RISC-V instruction, or MIPS instruction.

4. The method for executing a new instruction as described in claim 1, wherein, The aforementioned conversion program is stored in the processing core of the aforementioned processor or in the non-core of the aforementioned processor.

5. The method for executing a new instruction as described in claim 1, wherein, The above conversion procedure converts the received instruction into at least one of the above-mentioned old instructions using a hardware-supported lookup table.

6. The method for executing a new instruction as described in claim 1, further comprising: Store at least one of the aforementioned older instructions into memory or cache.

7. The method for executing a new instruction as described in claim 6, further comprising: Read at least one of the aforementioned legacy instructions from the aforementioned memory or cache; Decode at least one of the above-mentioned old instructions into at least one microinstruction; as well as Execute at least one of the above micro-instructions.

8. The method for executing a new instruction as described in claim 6, further comprising: Determine whether the other received instruction is an unknown instruction; When the other instruction mentioned above is an unknown instruction, issuing another unknown instruction is an exception; In response to the aforementioned unknown instruction exception, the above conversion procedure is followed: When the aforementioned other instruction is a newly added instruction, determine whether the aforementioned received instruction and the aforementioned other instruction are the same instruction; and When the above-mentioned receive instruction is the same as the above-mentioned other instruction, at least one of the above-mentioned old instructions shall be retrieved from the above-mentioned memory or the above-mentioned cache. And, execute at least one of the aforementioned old instructions.

9. The method for executing a new instruction as described in claim 1, wherein, At least one of the aforementioned legacy instructions is pre-stored in a private read-only memory or a basic input / output system.

10. The method for executing a new instruction as described in claim 1, further comprising: When the received instruction is not a new instruction, the above conversion procedure is followed: An error occurred while issuing an unknown command.

11. The method for executing a new instruction as described in claim 1, further comprising: After executing at least one of the above-mentioned old instructions, execute the next instruction following the above-mentioned receive instruction.

12. A system for executing newly added instructions, characterized in that, include: The instruction decoding unit receives instructions and determines whether the received instructions are unknown instructions, which are instructions that are not natively supported by the processor. When the received instruction is an unknown instruction, the instruction submission unit issues an unknown instruction exception. In response to the aforementioned unknown instruction exception, the system executing the new instruction converted the procedure as follows: Determine whether the received instruction is a new instruction, wherein the new instruction is an instruction added by a successor processor of the aforementioned processor and is not recognized by the aforementioned processor; and When the above-mentioned receive instruction is a new instruction, the above-mentioned receive instruction is converted into at least one old instruction, which is an instruction natively supported by the processor. The system that executes the new instruction executes at least one old instruction in the same execution mode as the system that receives the instruction, without switching the execution mode.

13. The system for executing new instructions as described in claim 12, wherein, The aforementioned receive instruction is an instruction set architecture instruction, and at least one of the aforementioned legacy instructions is an instruction set architecture instruction.

14. The system for executing new instructions as claimed in claim 12, wherein, The aforementioned receiving instructions are x86 instructions, ARM instructions, RISC-V instructions, or MIPS instructions, and at least one of the aforementioned legacy instructions is an x86 instruction, ARM instruction, RISC-V instruction, or MIPS instruction.

15. The system for executing new instructions as claimed in claim 12, wherein, The aforementioned conversion program is stored in the processor's processing core or in the processor's non-core.

16. The system for executing new instructions as claimed in claim 12, wherein, The above conversion procedure converts the received instruction into at least one of the above-mentioned old instructions using a hardware-supported lookup table.

17. The system for executing new instructions as claimed in claim 12, wherein, The system that executes the new instructions will store at least one of the old instructions in memory or cache.

18. The system for executing new instructions as described in claim 17, wherein, The system that executes the new instruction reads at least one old instruction from the memory or cache; decodes the read old instruction into at least one microinstruction; and executes the microinstruction.

19. The system for executing new instructions as claimed in claim 17, wherein, The aforementioned conversion procedure determines whether the received instruction is an unknown instruction; when the other instruction is an unknown instruction, the instruction submission unit issues an unknown instruction exception; in response to the unknown instruction exception, the system executing the new instruction proceeds through the aforementioned conversion procedure: When the aforementioned other instruction is a newly added instruction, determine whether the aforementioned received instruction and the aforementioned other instruction are the same instruction; and When the above-mentioned receive instruction is the same as the above-mentioned other instruction, at least one of the above-mentioned old instructions shall be retrieved from the above-mentioned memory or the above-mentioned cache. Furthermore, the system that executes the newly added instructions executes at least one of the old instructions.

20. The system for executing new instructions as claimed in claim 12, wherein, At least one of the aforementioned legacy instructions is pre-stored in a private read-only memory or a basic input / output system.

21. The system for executing new instructions as claimed in claim 12, wherein, When the received instruction is not a new instruction, the system that executes the new instruction issues an unknown instruction exception through the conversion program.

22. The system for executing new instructions as described in claim 12, wherein, After executing at least one of the old instructions, the system that executes the new instructions executes the next instruction after the received instruction.

Images