CN114691203A

CN114691203A - Method and system for executing newly added instruction

Info

Publication number: CN114691203A
Application number: CN202011591545.6A
Authority: CN
Inventors: 王惟林; 管应炳; 杨梦晨
Original assignee: VIA Alliance Semiconductor Co Ltd
Current assignee: Shanghai Zhaoxin Semiconductor Co Ltd
Priority date: 2020-12-29
Filing date: 2020-12-29
Publication date: 2022-07-01

Abstract

The invention provides a method and a system for executing a newly added instruction, wherein the method is used in a processor and comprises the following steps: an instruction is received. And when the received instruction is an unknown instruction, an unknown instruction exception is sent out. And responding to the exception of the unknown instruction, and entering a system management mode. In the system management mode, through a conversion program: judging whether the received instruction is a new instruction or not; when the received instruction is a new instruction, the execution of the received instruction is simulated by executing at least one old instruction. Therefore, the newly added instruction can be executed without changing the hardware architecture of the previous generation processing core.

Description

Method and system for executing newly added instruction

Technical Field

The present invention relates to the field of microelectronics, and more particularly to a method and system for executing a new instruction.

Background

Processor technology has evolved rapidly over the years. With the enhancement of processor functions, the descendant processors tend to add new instructions on the basis of the predecessor processors. Because the former generation processor can not execute the new instruction supported by the latter generation processor, when the former generation processor executes the new instruction, an unknown instruction exception (# UD) is generated, and further, the process containing the new instruction is stopped by the operating system. Resulting in the inability of the application or operating system containing the newly added instruction to execute on the previous generation processor.

Therefore, a method and system for executing a newly added instruction is needed to execute the newly added instruction on a previous generation processor.

Disclosure of Invention

The following disclosure is illustrative only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features, other aspects, embodiments, and features will be apparent by reference to the drawings and the following detailed description. That is, the following disclosure is provided to introduce concepts, points, benefits and novel and non-obvious technical advantages described herein. Selected, but not all, embodiments are described in further detail below. Accordingly, the following disclosure is not intended to identify essential features of the claimed subject matter, nor is it intended to be used in determining the scope of the claimed subject matter.

Therefore, the present invention is directed to a method and system for executing a newly added instruction, so as to execute the newly added instruction without changing the hardware architecture of the previous generation processing core.

The invention provides a method for executing a newly added instruction, which comprises the following steps: receiving an instruction; when the received instruction is an unknown instruction, an unknown instruction exception is sent out; responding to the unknown instruction exception, entering a System Management Mode (SMM); and under the system management mode, through a conversion program: judging whether the received instruction is a new instruction or not; and simulating the execution of the received instruction by executing at least one old instruction when the received instruction is a new instruction.

The invention provides a system for executing a newly added instruction, which comprises: a command decoding unit (decoder) for receiving a command and determining whether the received command is an unknown command; and an instruction submitting unit, when the received instruction is an unknown instruction, the instruction submitting unit sends an unknown instruction exception; in response to the unknown instruction exception, the system executing the new instruction enters a system management mode, and in the system management mode, the system executing the new instruction passes through a conversion program: judging whether the received instruction is a new instruction or not; and simulating the execution of the received instruction by executing at least one old instruction when the received instruction is a new instruction.

By the method for executing the newly added instruction and the system for executing the newly added instruction, provided by the invention, the newly added instruction can be executed on the prior generation processor without modifying a hardware architecture of a processing core.

Drawings

Fig. 1 is a diagram illustrating a system for executing a new instruction according to a first embodiment of the invention.

Fig. 2 is a block diagram of a processor according to a first embodiment of the invention.

Fig. 3 is a flowchart illustrating the execution of a new instruction according to a first embodiment of the present invention.

Fig. 4 is a flowchart illustrating a process of receiving an instruction according to a first embodiment of the present invention.

Fig. 5 is a flowchart illustrating entering a system management mode according to a first embodiment of the present invention.

Fig. 6 is a flowchart showing a process of the simulator according to the first embodiment of the present invention.

Fig. 7 is a flowchart showing a process of the conversion routine according to the first embodiment of the present invention.

Fig. 8 is a diagram showing an example of processing an unknown instruction in the system management mode according to the first embodiment of the present invention.

Fig. 9A to 9B are flowcharts illustrating the exit from the system management mode according to the first embodiment of the present invention.

FIG. 10 is a diagram illustrating a system for executing a new instruction according to a second embodiment of the invention.

Fig. 11 is a block diagram of a processor according to a second embodiment of the invention.

Fig. 12 is a flowchart illustrating the execution of a new instruction according to a second embodiment of the invention.

Fig. 13 is a flowchart showing a process of receiving an instruction according to the second embodiment of the present invention.

FIG. 14 is a flowchart illustrating processing of a received instruction in microcode handling an unknown instruction exception according to a second embodiment of the present invention.

FIGS. 15A-15B are diagrams illustrating a system for executing a new instruction according to a third embodiment of the invention.

FIG. 16 is a flowchart illustrating a process for receiving instructions according to a third embodiment of the present invention.

FIG. 17 is a diagram illustrating a system for executing a new instruction according to a fourth embodiment of the invention.

FIG. 18 is a flowchart illustrating the execution of a new instruction according to an embodiment of the invention.

FIG. 19 is a flowchart illustrating the execution of a new instruction according to an embodiment of the invention.

FIG. 20 is a flowchart illustrating converting a new instruction according to an embodiment of the invention.

FIG. 21 is a flowchart illustrating an exemplary operating environment for implementing embodiments of the present invention.

Wherein the symbols in the drawings are briefly described as follows:

100: a system for executing the newly added instruction; 110: a processor; 112: an interrupt preprocessing unit; 114: system management mode egress/ingress; 1142: a system management mode entry; 1144: a system management mode exit; 120: an operating system; 130: an application program; 118: instructions; 132: an unknown instruction; 142: a simulator; 145: converting the program; 200: a processor; 201: an instruction bypass translation buffer; 202: caching an instruction; 203: a branch predictor; 230: an instruction decoding unit; 204: a renaming unit; 205: a reservation station; 206: an execution unit; 207: a memory access unit; 220: a micro-architecture register; 240: a rearrangement buffer area; 245: an instruction commit unit; 250: a system management mode; 260: an architecture register; s305, S310, S315, S320, S325: a step of; s405, S410, S415, S420, S425, S430, S435: a step of; s505, S510, S515, S520, S525, S530: a step of; s605, S610, S615, S620, S625, S630, S635, S640, S645: a step of; s705, S710, S712, S715, S720, S725: a step of; s901, S904, S903, S905, S907, S909, S911, S913, S915, S917, S919, S921, S923, S925, S927, S929, S933: a step of; 1000: a system for executing the newly added instruction; 1100: a processor; 1110: converting the program; s1205, S1210, S1215, S1220, S1225: a step of; s1305, S1310, S1315, S1320, S1325: a step of; s1405, S1410, S1415, S1420, S1425: a step of; 1500: a system for executing the newly added instruction; 150: a kernel driver; 1600: a flow chart; s1605, S1610, S1620, S1625: a step of; 1700: a system for executing the new instruction; 190: a dedicated processing core; s1805, S1810, S1815, S1820, S1825: a step of; s1905, S1910, S1915, S1920, S1925: a step of; s2005, S2010, S2015: a step of; 2100: a computing device; 2110: a bus; 2112: a memory; 2114: a processor; 2116: a display element; 2118: an I/O port; 2120: an I/O element; 2122: a power supply.

Detailed Description

Aspects of the present invention will be described more fully hereinafter with reference to the accompanying drawings. This invention 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 invention to those skilled in the art. Based on the teachings herein one skilled in the art should appreciate that the scope of the present invention is intended to cover any aspect disclosed herein, whether alone or in combination with any other aspect of the invention to achieve any aspect disclosed herein. For example, it may be implemented using any number of the apparatus or performing methods set forth herein. In addition, the scope of the present invention is intended to cover apparatuses or methods implemented with other structure, functionality, or structure and functionality in addition to the various aspects of the invention set forth herein. It is to be understood that any aspect disclosed herein may be embodied by one or more elements of a claim.

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any aspect of the present invention or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects of the invention or design. Moreover, like numerals refer to like elements throughout the several views, and the articles "a" and "an" include multiple references unless otherwise specified in the description.

It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected" or "directly coupled" to another element, there are no intervening elements present. Other words used to describe the relationship between elements should be interpreted in a similar manner (e.g., "between …" versus "directly between …," "adjacent" versus "directly adjacent," etc.).

In order to better describe the embodiments of the present invention, the terms used in the present invention are defined below.

The old instruction: instructions that are natively supported by predecessor processors are referred to as native instructions (native instructions), also known as existing instructions or old instructions.

Unknown instruction: instructions not natively supported by the predecessor processors.

Adding an instruction: the later generation processor is populated with supported instructions compared to the earlier generation processor. The newly added instruction is not recognized by the predecessor, and thus is an unknown instruction to the predecessor.

Newly adding an architecture register: the next generation processor has newly added architectural registers to support as compared to the previous generation processor. The new architectural register is not present in the previous generation processor, and therefore the new architectural register needs to be emulated when a new instruction using the new architectural register is emulated on the previous generation processor.

The instruction cannot be identified: and removing the part of the unknown instruction which is left after the new instruction. That is, an unrecognizable instruction refers to an instruction that is not natively supported by the descendant processor.

Model specific registers: a type of register in the processor may be used to perform some specific functions.

A trap: traps are typically caused by soft interrupt instructions, such as INT instructions. When an instruction causes a trap exception, it does not indicate that the instruction itself is executing in error. Thus, when a trap exception occurs for an instruction, the processor will continue to execute the instruction next to the instruction. For example, a software developer may set a breakpoint in software code when debugging the code. When the program code with the breakpoint set is executed on the processor, a trap is generated when the program code is executed to the breakpoint, so that the program code is suspended from being executed at the breakpoint. Software developers can view the values of all the architectural registers in the processor or the values of all the variables in the program code when the program code is executed to a breakpoint through a microcode processing program for processing traps. And judging whether the program code is normally executed when the breakpoint is executed according to the value of each architecture register or the value of each variable in the program code.

The processor of the present invention may be a processor having Reduced Instruction Set Computing (RISC, such as the ARM/MIPS/RISC-V Instruction Set), Complex Instruction Set Computing (CISC, such as the x86 Instruction Set), or other Instruction Set types; or a processor capable of supporting multiple different instruction set architectures (e.g., a processor supporting both the x86 instruction set and the ARM instruction set). The invention is not particularly limited in the type of instruction set supported by the processor, but for convenience of description, the embodiments of the present description are described in terms of a processor supporting the X86 instruction set. In addition, as is known In the art, the x86 processor decodes macro instructions (microinstructions) 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 instructions is performed In an Out-of-order (Out-of-order) manner to improve the execution efficiency, except that the micro instructions are still executed In the original program order during the commit (reire) process after the execution of the micro instructions is completed.

The invention has a plurality of embodiments, 4 main embodiments of the invention are described below with 4 examples. The first embodiment is an implementation mode for simulating the execution of a newly added instruction in the system management mode. The second embodiment is an implementation in which execution of the newly added instruction is simulated in the same execution mode as the newly added instruction. The third embodiment and the fourth embodiment are implemented by simulating the execution of the newly added instruction through an operating system, wherein the fourth embodiment uses a special processing core to complete the conversion operation of the newly added instruction. The first embodiment is described below.

[ first embodiment ]

Fig. 1 is a diagram illustrating a system for executing a new instruction according to a first embodiment of the invention. As shown in FIG. 1, the system 100 for executing the new instruction includes a processor 110, an operating system 120, an application 130, and a simulator 142. An operating system 120 runs on top of the processor 110 and is used to manage the processor 110. The application programs 130 run on the operating system 120 and may use various functions provided by the processor 110 and other hardware (not shown), such as a hard disk, network card, etc., through the operating system 120. Simulator 142 runs on processor 110 in System Management Mode (SMM). The operating system 120 or the application 130 is unaware of the execution of the simulator 142. That is, all operations performed by simulator 142 are transparent to operating system 120 or application 130.

When the processor 110 executes an unknown instruction to the application 130 or the operating system 120, the processor 110 enters the system management mode and sends the unknown instruction to the simulator 142 for processing. If the unknown instruction is a new instruction, the simulator 142 simulates the new instruction. Notably, the source code for the application programs 130 or the operating system 120 is typically written in a high-level language (e.g., C language, C + + language, etc.) and/or a low-level language (e.g., assembly language, etc.). After the source code is compiled using a compiler, executable code is generated that can be executed by the processor. The executable code is comprised of instructions that can be executed by a processor. In the present invention, the application 130 or the operating system 120 refers to an executable code generated by compiling a source code of the application 130 or the operating system 120 by a compiler. The processing of the system 100 for executing the newly added instruction will be briefly described below by taking the processing of the unknown instruction 132 by the processor 110 in fig. 1 as an example.

As shown in FIG. 1, processor 110 includes an interrupt pre-processing unit 112 and a SMM egress/ingress 114. The SMM egress/ingress 114 includes a SMM ingress 1142 and a SMM egress 1144. Solid arrows with numerical numbers in fig. 1 indicate the direction of transmission of instruction information, and dashed arrows with numerical numbers indicate the direction of transmission of the instruction simulation execution result. The overall process of the processor 110 processing the unknown instruction 132 is described below.

First, the processor 110 receives an instruction 118 (shown as a solid arrow 1) in the application 130 to perform a specified function. After receiving instruction 118, processor 110 determines whether instruction 118 is unknown instruction 132. If instruction 118 is unknown instruction 132, processor 110 issues an unknown instruction exception (# UD). In response to the unknown instruction exception, the interrupt pre-processing unit 112 executes the microcode handler for the unknown instruction exception. In the microcode handler for 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 egress/ingress 114 (as indicated by the solid arrow 2). How to issue the unknown instruction exception and the system management interrupt is the general knowledge of those skilled in the art, and will not be described herein. In one embodiment, processor 110 is a processor supporting the x86 instruction set and interrupt pre-processing unit 112 is a microcode control unit. In practice, a person skilled in the art may modify the microcode handler for the unknown instruction exception stored in the interrupt preprocessing unit 112 to add the functions of setting the simulation flag, obtaining the instruction information of the unknown instruction, and issuing the system management interrupt. Since these microcode will vary depending on the processor version, one skilled in the art can write the corresponding microcode according to the actual situation.

The processor 110 then enters the SMM mode through the SMM entry 1142 and sends the instruction information of the unknown instruction 132 to the simulator 142 (as indicated by the solid arrow 3). In the system management mode, the simulator 142 determines whether the unknown command 132 is a new command. If the unknown instruction 132 is a new instruction, the simulator 142 simulates the new instruction. After the simulation has executed the new instruction, the simulator 142 sends the simulation execution result to the SMM I/O114 (as indicated by the dashed arrow 4). The processor 110 then sends the simulation execution result to the application 130 through the SMM exit 1144 (as indicated by the dashed arrow 5), and exits SMM. At this point, the processor 110 has finished processing the unknown instruction 132. In one embodiment, during the simulation of the simulator 142 executing the new instruction, the intermediate operation result generated during the simulation may be stored in a system management memory (SMRAM).

Fig. 2 is a block diagram showing a processor according to a first embodiment of the present invention. As shown in FIG. 2, processor 200 to the left of the dashed line is a block diagram of processor 110 shown in FIG. 1, and simulator 142 and translator 145 to the right of the dashed line run on processor 200 in the system management mode. In one embodiment, the functions performed by the transformation program 145 are implemented in a transformation module, or the transformation program 145 may be considered as a transformation module in the system 100 executing the newly added instruction. Fig. 2 will be described with reference to fig. 1.

As shown in FIG. 2, the processor 200 includes an Instruction bypass Translation Buffer (ITLB) 201, an Instruction Cache (Instruction Cache)202, and a branch predictor (Branch predictor) 203. When the processor 200 executes an instruction to the application 130 or the operating system 120, the instruction bypass translation buffer 201 of the processor 200 receives the instruction. The branch predictor 203 is used to predict conditional branches and to pass the branch prediction results to the instruction cache 202. The instruction cache 202 fetches the received instruction from the instruction bypass translation buffer 201 based on the branch prediction result, and the processor 200 further processes the received instruction.

As shown in FIG. 2, the processor 200 also includes an instruction decode unit 230. The instruction decoding unit 230 determines whether the received instruction is an unknown instruction, and then generates at least one micro instruction, wherein the micro instruction includes an unknown instruction tag for indicating whether the received instruction is an unknown instruction. When the unknown instruction mark is a first value, the received instruction is represented as an unknown instruction. When the unknown instruction mark is the second value, the received instruction is an old instruction. In one embodiment, the first value is 1 and the second value is 0.

Processor 200 also includes rename unit 204, reservation station 205, execution unit 206, memory access unit 207, reorder buffer 240, interrupt pre-processing unit 112, and architectural registers 260. The rename unit 204 receives the micro instructions, which include an unknown instruction identification (UD), from the instruction decode unit 230 and renames the micro instructions. Rename unit 204 then sends the renamed microinstructions to reservation station 205 and reorder buffer 240. The reservation station 205 sends the microinstructions to the execution unit 206 or the memory access unit 207 for further processing according to the types of the microinstructions. The reorder buffer 240 receives the micro instructions and stores them into instruction entries. The reorder buffer 240 contains a plurality of instruction entries, each instruction entry containing an unknown instruction identification field for storing an unknown instruction identification in the microinstruction.

Reorder buffer 240 includes instruction issue unit 245. When the micro instruction satisfies a commit (retire) condition, the instruction issue unit 245 issues the micro instruction. When the micro instruction is committed, if no exception is generated when the micro instruction is executed, the instruction issue unit 245 updates the architectural register 260 according to the execution result of the micro instruction. If an exception is raised when the microinstruction is executed, the instruction issue unit 245 reports (report) the exception. In response to the exception, the processor 200 executes the microcode handler for the exception.

When the instruction issue unit 245 issues the micro instruction, if the unknown instruction of the micro instruction is identified as the first value, the instruction issue unit 245 issues an unknown instruction exception (# UD). In response to the unknown instruction exception, processor 200 executes a microcode handler for the unknown instruction exception. In the microcode handler for the unknown instruction exception, processor 200 stores an emulation flag with a first value in microarchitectural register 220 and issues a system management interrupt (# SMI). In response to the SMI, the processor 200 will enter SMI according to the emulation identifier stored in the micro-architectural register 220 via SMI entry 1142 shown in FIG. 1. In the system management mode, the processor 200 processes the received instruction through the simulator 142. First, the simulator 142 determines whether the received command is a new command. If the received command is a new command, the simulator 142 simulates the received command. In simulating execution of the received instruction, simulator 142 may store the intermediate operation result in a system management memory (SMRAM). It should be noted that, when the simulation flag is the first value, it indicates that the simulator 142 is required to process the received instruction; when the simulation flag is the second value, it indicates that simulator 142 is not required to process the received instruction.

After the simulator 142 processes the received command, the processor 200 exits the SMM mode by executing the SMM exit 1144 shown in FIG. 1. The SMM exit 1144 sets the simulation flag stored in the micro-architectural register 220 to a second value and then exits SMM. When the processor 200 executes another instruction, and the other instruction is an unknown instruction, the processor 200 sets the emulation flag stored in the micro-architectural register 220 to the first value when executing a microcode handler for which the unknown instruction is abnormal. The processor 200 then processes the other instruction in accordance with the processing procedure described above.

Fig. 3 is a flowchart illustrating the execution of a new instruction according to a first embodiment of the present invention. Referring to both FIG. 2 and FIG. 3, as shown in FIG. 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 conversion process (S320). 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 (S325). The detailed description is as follows: the instruction decoding unit 230 first executes step S305.

In step S305, the instruction decoding unit 230 receives an instruction. Specifically, the instruction decode unit 230 receives the instructions from the instruction cache 202. Then, the processor 200 performs step S310.

In step S310, when the received instruction is an unknown instruction, the instruction issue unit 245 issues an unknown instruction exception. Specifically, as mentioned above, when the instruction decoding unit 230 determines that the received instruction is an unknown instruction, a micro instruction is generated, wherein the micro instruction includes an unknown instruction tag having a first value. The instruction decode unit 230 then sends the micro instructions to the rename unit 204. The rename unit 204 renames the microinstructions and sends the microinstructions to the reorder buffer 240. The reorder buffer 240 stores the microinstructions into an instruction entry. When the micro instruction satisfies a commit (retire) condition, the instruction issue unit 245 reads the micro instruction from the instruction entry and issues the micro instruction. Since the unknown instruction of the microinstruction is identified as the first value, the instruction commit unit 245 issues an unknown instruction exception. Then, the processor 200 executes step S315.

In step S315, in response to the unknown instruction exception, the processor 200 enters a System Management Mode (SMM). In particular, in response to the unknown instruction exception described above, processor 200 executes a microcode handler for the unknown instruction exception. In the microcode handler for unknown instruction exceptions, the processor 200 writes an Emulation Flag (EF) with a first value into the microarchitectural register 220 and issues a system management interrupt (# SMI). In response to the SMI, the processor 200 will enter SMI according to the simulation flag via the SMI entry 1142 shown in FIG. 1. Then, step S320 is performed.

In step S320, in the system management mode, the processor 200 determines whether the received command is a new command through a conversion procedure. How the conversion process determines whether the received command is a new command will be described in detail later with reference to fig. 7. In one embodiment, the conversion program may be pre-stored in a Basic Input Output System (BIOS). It is well known in the art that the bios is executed when the system 100 executing the new command is powered on. The bios includes a code for initializing a system management mode. When the system 100 executing the new instruction executes the code for initializing the system management mode, the conversion program is loaded into a system management memory (SMRAM). Then, the processor 200 can directly execute the above-mentioned conversion program stored in the system management memory after entering the system management mode. Then, the processor 200 performs step S325.

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 converts the received instruction into at least one old instruction through the conversion procedure. The processor 200 then executes the at least one old instruction. For a more detailed explanation, refer to the following description of steps S615, S620, S625, and S630 of fig. 6.

In one embodiment, the received instruction is an instruction set architecture instruction and the at least one old instruction is an instruction set architecture 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 old instruction is an x86 instruction, an ARM instruction, a RISC-V instruction, or a MIPS instruction.

Fig. 4 is a flowchart illustrating a process of receiving an instruction according to a first embodiment of the present invention. Referring to fig. 2 and 4, as shown in fig. 4, the instruction decoding unit 230 receives an instruction (S405), and determines whether the received instruction is an unknown instruction (S410). And when the received command is an unknown command, entering a system management mode to process the received command. Since step S405 is the same as step S305 of fig. 3, it is not described here in detail. Step S410 is described below.

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 decoding information of the received instruction. In one embodiment, the decoding information includes a prefix (prefix), an escape code (escape code), an operation code (opcode), an operand mode (ModR/M), and other decoding information. Then, the instruction decoding unit 230 determines whether the received instruction is an unknown instruction according to the decoding information. For example, the operation code of the old instruction natively supported by the processor 200 may be stored in a Lookup Table (Lookup Table). The instruction decoding unit 230 may check whether the operation code of the received instruction is stored in the lookup table, and if so, the received instruction is an old instruction; otherwise, the received instruction is an unknown instruction. In one embodiment, the lookup table is stored in the instruction decode unit 230.

When the above-described reception instruction is an old instruction (no in step S410), step S435 is executed. In step S435, the processor 200 normally processes the above reception instruction. How to normally process the received instruction, for example, converting the old instruction into a corresponding microinstruction and executing the corresponding microinstruction, is common knowledge of those skilled in the art and will not be described herein again. When the above-described reception instruction is an unknown instruction (yes in step S410), step S415 is executed.

In step S415, the processor 200 writes an analog 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 whose unknown instruction tag is a first value. In one embodiment, the micro instruction is a no-operation micro instruction (NOP). The instruction decode unit 230 sends the micro instructions to the rename unit 204. The rename unit 204 renames the microinstructions. Rename unit 204 then sends the micro instructions to reorder buffer 240. The reorder buffer 240 stores the microinstructions in its instruction entry. When the micro instruction is committed, instruction commit unit 245 issues an unknown instruction exception since the unknown instruction tag of the micro instruction is the first value. In response to the unknown instruction exception, processor 200 executes a microcode handler for the unknown instruction exception. In the microcode handler for unknown instruction exceptions described above, the processor 200 writes an emulation flag into the microarchitectural register 220. In addition, the processor 200 stores the information of the received instruction and the execution environment information of the received instruction into the micro-architecture register 220. Then, in the microcode handler for 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 a machine code of the received instruction. The operating environment information includes the operating mode of the received instruction (i.e., the operating mode of the processor 200 when the processor 200 executes the received instruction). For example, the operation modes include a real mode (read mode), a protected mode (protected mode), a virtual 8086 mode (v8086 mode), a compatibility mode (compatibility mode), and a long mode (long mode), and the like. Then, the processor 200 executes step S420.

In step S420, the processor 200 enters a system management mode. Specifically, in response to the above-mentioned system management interrupt, the processor 200 enters the system management mode by executing the system management mode entry 1142 shown in fig. 1. Details of the entry of the processor 200 into the system management mode will be described later in conjunction with fig. 5. Then, the processor 200 performs step S425.

In step S425, the processor 200 processes the above reception instruction. How the processor 200 processes the received instruction will be described in detail with reference to fig. 6 to 8. Then, the processor 200 performs step S430.

In step S430, the processor 200 exits the system management mode, and ends the flow. Specifically, the processor 200 exits the SMM mode by executing the SMM exit 1144 shown in FIG. 1. As to how the processor 200 exits the system management mode, it will be described in detail later in conjunction with fig. 9A to 9B.

Fig. 5 is a flowchart illustrating entering a system management mode according to a first embodiment of the present invention. Fig. 5 is a flowchart of a microcode handler corresponding to the system management mode entry 1142 shown in fig. 1. Referring to fig. 2 and 5, as shown in fig. 5, the processor 200 disables the interrupt (S505), and determines whether the simulation flag is the first value (S510). If the judgment result of the step S510 is YES, a system management mode is entered. The detailed description is as follows: the processor 200 first executes step S505.

In step S505, the processor 200 disables the interrupt. As is known to those skilled in the art, interrupts are disabled in the SMM mode, and thus the present invention also extends this architectural requirement to disable interrupts. As to how interrupts are disabled, for example, processor 200 clears the IF flag to disable maskable interrupts, clears the TF flag to disable single step interrupts, and clears DR7 to disable breakpoint interrupts. Then, the processor 200 performs step S510.

Next, in step S510, the processor 200 determines whether the simulation flag is the first value. In particular, processor 200 determines whether the simulation flag stored in micro-architectural register 220 is a first value. If the determination result is "no", step S530 is performed to execute a normal process flow of entering the system management mode. Those skilled in the art will understand the normal processing flow of the system management mode, and will not be described herein. If the determination is yes, the processor 200 performs step S515.

In step S515, the processor 200 issues an enter system management mode notification (Assert # smmact) to notify the chipset that the processor 200 has entered system management mode. How to issue the notification of entering into the system management mode is the general knowledge of those skilled in the art, and is not described herein in detail. Then, the processor 200 executes step S520.

In step S520, the processor 200 stores the simulation flag, the information of the received instruction, and the operating environment information into the system management memory. Specifically, the processor 200 reads the simulation flag, the information of the received instruction, and the execution environment information from the micro-architecture register 220, and stores the read simulation flag, the information of the received instruction, and the execution environment information in the system management memory. At the same time, the contents of architectural registers 260 (i.e., the current state of processor 200) are also stored in system management memory. The information stored in the system management memory is shown in table 1 below.

TABLE 1

Then, the processor 200 executes step S525, establishes a system management mode execution environment, and enters a system management mode. How to establish the execution environment of the SMM and how to enter the SMM are the common knowledge of those skilled in the art, and are not described herein in detail.

It should be noted that in the actual operation of entering the system management mode through the system management mode entry 1142 of fig. 1 shown in fig. 5, after issuing the system management interrupt (# SMI), a person skilled in the art may add some microcode for executing the save emulation flag, the information of the received instruction, and the operating environment information to the system management memory (SMRAM) to the microcode corresponding to entering the system management mode, and ensure that these data/information are not overwritten (overwritten) due to the switching of the processor 200 to the system management mode. Furthermore, because the processor 200 in the SMM mode accesses the SMRAM (system management memory) in the prior art, those skilled in the art can modify the portion of microcode to access the data/information. Since the microcode will vary depending on the processor version, one skilled in the art can write the corresponding microcode according to the actual situation.

Then, the processor 200 processes the above-mentioned reception instruction in the system management mode (step S425 shown in fig. 4). How the processor 200 processes the received instruction in the system management mode is described in detail below with reference to fig. 6-8.

Fig. 6 is a flowchart showing a process of the simulator according to the first embodiment of the present invention. As described above, the processor 200 processes the received instruction through the simulator 142 in the system management mode. Referring to fig. 2 and 6, as shown in fig. 6, in the system management mode, the simulator 142 establishes a simulation running environment (S605), and then determines whether the simulation flag is the first value (S610). If the determination result of step S610 is yes, the simulator 142 converts the above received instruction by the conversion program and generates a conversion result (S615). The simulator 142 then processes the conversion results. The detailed description is as follows: first, the simulator 142 performs step S605.

In step S605, the simulator 142 establishes a simulation execution environment. Specifically, the emulator 142 reads the emulation flag, the information of the received instruction, the execution environment information of the received instruction, and the information of the architectural register from the system management memory. In the subsequent step, the read information is used for simulating and executing the receiving instruction. Then, the simulator 142 performs step S610.

In step S610, the simulator 142 determines whether the simulation flag is the first value. Specifically, the simulator 142 determines whether the simulation flag read in step S605 is the first numerical value. If the determination result is "no", the simulator 142 performs step S645. In step S645, the simulator 142 executes the normal processing flow of the system management mode. The normal processing flow of the system management mode is the common knowledge of those skilled in the art, and will not be described herein. If the determination result of step S610 is YES, the simulator 142 performs step S615.

In step S615, the simulator 142 converts the above-described reception instruction by the conversion program 145 and generates a conversion result. The structure of the conversion result is shown in table 2 below, and includes two fields, a result and a content. When the result field is a first value, the conversion is successful, and at this time, the content field comprises at least one old instruction obtained by converting the received instruction and the length of the received instruction; when the result field is the second value, it indicates that the conversion has failed, and the content field includes an exception number. How to convert the received command by the conversion program 145 will be described in detail later in conjunction with fig. 7.

TABLE 2

Results	Content providing method and apparatus
		…	…

In step S620, the simulator 142 determines whether the conversion process is successful. Specifically, the simulator 142 determines whether the conversion process is successful or not according to a result field in the conversion result. When the result field of the conversion result is the first value, the determination result is yes, and the simulator 142 performs step S625; when the result field of the conversion result is the second value, the determination result is no, the simulator 142 generates a simulation execution result according to the conversion result, and then performs step S630. The structure of the simulation execution result is shown in table 3 below, and includes two fields, a result and details. When the result field of the simulation execution result is a first numerical value, the simulation execution is successful, and the operation result obtained after the simulation execution is stored in the detail field; and when the result field of the simulation execution result is a second numerical value, the simulation execution is failed, and the exception number is stored in the detail field. When the result field of the simulation execution result is the second value, the simulation execution result generated according to the conversion result is as shown in the following table 3-1. The exception number in the detail field in Table 3-1 is the exception number in the content field of the conversion result.

TABLE 3

As a result, the	Details of
		…	…

TABLE 3-1

As a result, the	Details of
		Second numerical value	Exception number

Further, when the determination result of step S620 is that the conversion is successful (i.e., the determination result of step S620 is yes), the simulator 142 performs step S625. In step S625, the simulator 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 length of the at least one old instruction and the received instruction from the content field of the conversion result. The simulator 142 then causes the processor 200 to execute the at least one old instruction by a call instruction or a jump 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 a simulated execution result. If a runtime exception (runtime exception) occurs during the execution of the at least one microinstruction by the processor 200, the contents field of the simulation execution result is as shown in Table 3-2 below. The result field of the simulation execution result in table 3-2 is a second value indicating that the simulation execution failed; the details field of the simulation execution result is the exception number, i.e., the number of the runtime exception. If the processor 200 successfully executes the at least one microinstruction, the contents of the simulated execution result are shown in tables 3-3 below. The result of the simulation execution result in table 3-3 is a first numerical value indicating that the simulation execution was successful; the detail field of the simulation execution result is an operation result.

TABLE 3-2

Results	Details of
		Second numerical value	Exception numbering

Tables 3 to 3

Results	Details of
		First value	Operation result

In one embodiment, the additional architectural registers are emulated using system management memory when operands of the received instruction include additional architectural registers. For example, when a descendant processor of processor 200 includes a 1024-bit wide added architectural register, simulator 142 may utilize a continuous 1024-bit storage space in the system management memory to simulate the added architectural register. That is, when the received instruction accesses the newly added architectural register, the simulator 142 actually accesses the 1024-bit contiguous memory space in the system management memory.

When the new architectural register is the Destination operand (Destination operand) of the received instruction, the processor 200 stores the operation result of the received instruction into the system management memory after the execution of the at least one old instruction. Thus, when the processor 200 executes another instruction, and the other instruction is also a new instruction, and the new architectural register is a Source operand (Source operand) of the other instruction, the processor 200 directly uses the operation result stored in the system management memory when simulating the execution of the other instruction. It should be noted that the receiving instruction and the another instruction may be consecutive (i.e. adjacent) or may not be consecutive, and the present invention is not limited thereto.

In the system management mode, the emulator 142 can only access the system management memory, but cannot access the memory in a normal manner (i.e., system memory, the same applies below). In an embodiment of the present invention, a physical memory direct access interface is provided to implement an operation of accessing a memory in a system management mode. When the received instruction includes a memory operand, the memory operand may 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:

in the first step, the emulator 142 converts the virtual address of the memory operand into a physical address. Specifically, the simulator 142 converts the virtual address of the memory operand into a physical address by accessing the page table through the physical memory direct access interface. The step of converting the virtual address into the physical address comprises the following steps: firstly, reading a page table base address stored in an architecture register CR3 from a system management memory; and secondly, performing page table query according to the page table base address and the virtual address, and acquiring the physical address after simulating the page table query process.

In the second step, the simulator 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 simulator 142 reads the value of the memory operand according to the physical address through the physical memory direct access interface using a Model Specific Register (MSR). The method comprises the following specific steps:

in step 1, simulator 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).

In step 2, simulator 142 executes a write model specific register instruction (WRMSR) to store the values of the memory operands in the model specific registers. Specifically, after the simulator 142 executes the write model specific register instruction, the physical address is written into the model specific register. The processor 1100 then loads the values of the memory operands from system memory into the model specific registers by executing a load from physical micro instruction (ld _ phys) using the physical addresses stored in the model specific registers.

In step 3, the simulator 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 read value of the memory operand in the second register.

In an embodiment, the next instruction of the received instructions is the another instruction. The last instruction in the at least one old instruction is a jump instruction (jump) or a call instruction (call), through which processor 1100 jumps to the other instruction. The instruction pointer of the another instruction is: EIP + Length, wherein EIP is an instruction pointer of the received instruction, and Length is the Length of the received instruction.

Then, the simulator 142 performs step S630. In step S630, the simulator 142 writes the simulation execution result into the system management memory. Specifically, the simulator 142 writes the simulation execution result generated in step S625 or step S620 into the system management memory. As can be seen from the foregoing, there are two cases of simulation execution results: one is that the simulation execution succeeds, and one is that the simulation execution fails. The system management memory includes an exception vector table, which is structured as shown in table 4 below. The exception vector table contains 2 fields for exception identification and exception number. When the simulation execution result is stored in the system management memory, the abnormal vector table in the system management memory needs to be filled in. The following describes the procedure of storing the simulation execution results of the two cases into the system management memory by the simulator 142.

TABLE 4

Anomaly identification	Exception numbering
		…	…

When the simulation execution is successful, the simulator 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 detail field of the simulation execution result in the system management memory. For example, if the result of the above operation is that the value of the architecture register ECX becomes 10H (i.e. 10 hexadecimal digits, the same applies hereinafter), the simulator 142 needs to write 10H into the storage space corresponding to the architecture register ECX in the system management memory. If the operation result is that the value of the new architectural register becomes 20H, the emulator 142 needs to write 20H into the memory space of the system management memory for emulating the new architectural register. The simulator 142 further updates the value of the instruction pointer of the received instruction stored in the system management memory to: EIP + Length, such 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 updating, and Length is the Length of the received instruction. The instruction pointer of the received instruction in the system management memory is a storage space corresponding to the EIP. When exiting the SMM mode, the values in the memory space corresponding to the architectural registers in the SMM are written into the corresponding architectural registers 260, so as to send the simulated execution result of the newly added instruction to the application 130 or the operating system 120, as will be described in detail later.

TABLE 4-1

Anomaly identification	Exception numbering
		First value	…

When the simulation execution fails, it indicates that an exception has occurred in 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 detail field of the emulation execution result in the exception number field of the exception vector table. The simulator 142 may determine whether the exception is a trap (trap) based on the exception number, and when the exception is a trap, update the value of the instruction pointer of the received instruction stored in the system management memory to: EIP + Length, where EIP is a value before the instruction pointer of the received instruction is updated, and Length is a Length of the received instruction stored in the system management memory, and the EIP + Length is used to point the instruction pointer of the processor 200 to the next instruction set architecture instruction to be executed.

TABLE 4-2

Anomaly identification	Exception numbering
		Second numerical value	Exception numbering

Then, the simulator 142 performs step S635. In step S635, the emulator 142 executes an exit System Management mode (RSM) instruction. After executing the SMM exit instruction, the processor 200 executes the microcode handler of the SMM exit 1144 shown in FIG. 1, which will be described in detail with reference to FIGS. 9A-9B.

Fig. 7 is a flowchart showing a process of the conversion routine according to the first embodiment of the present invention. Fig. 7 is a flowchart of the processing of the conversion program 145 shown in fig. 1. Referring to fig. 2 and 7, as shown in fig. 7, the conversion program 145 obtains the operation code of the received instruction (S705). Then, the conversion program 145 determines whether the received command is a new command according to the operation code (S710). When the received command is a new command, the conversion program 145 converts the received command into at least one old command (S720) and generates a conversion result (S725). The detailed description is as follows: the conversion program 145 first executes step S705.

In step S705, the conversion program 145 obtains the operation code of the received command according to the information of the received command. Note that, since the received instruction is not decoded at this time, the information of the received instruction does not include decoding information such as a prefix, an escape code, and an opcode. As can be seen from the foregoing description of step S415 in fig. 4, in an embodiment, the information of the received instruction only 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 a machine code of the received instruction. When the conversion program 145 executes the processing flow shown in fig. 7, the following three cases can be divided:

the first case: when the information of the received instruction only includes the instruction pointer of the received instruction, and the conversion program 145 decodes the received instruction, the machine code of 1 byte is read and processed each time according to the instruction pointer of the received instruction until the decoding is completed;

the second case: when the information of the received instruction only includes the instruction pointer of the received instruction, the conversion program 145 reads the machine code of the received instruction according to the instruction pointer of the received instruction, and then decodes the read machine code;

the third situation: when the information of the received command includes the command pointer of the received command and the machine code of the received command, the conversion program 145 directly decodes the machine code in the information of the received command;

the process by which the conversion program 145 executes the processing flow of fig. 7 in the first case will be described first. The conversion program 145 first executes step S705.

In step S705, the conversion program 145 obtains an operation code (opcode) of the above-described received instruction. Specifically, the conversion program 145 obtains the operation code of the received instruction according to the information of the received instruction. As described above (step S605 in fig. 6), the information of the received command is read from the system management memory by the simulator 142. The information of the received instruction only includes an instruction pointer of the received instruction, and the conversion program 145 obtains the operation code of the received instruction according to the instruction pointer of the received instruction. Specifically, the conversion program 145 reads the 1 st byte of the machine code of the received instruction from a memory (i.e., a system memory) according to the instruction pointer of the received instruction, and then determines the operation code of the received instruction according to the read byte (i.e., the first 1 byte). If the operation code of the received instruction cannot be judged according to the 1 st byte of the machine code, the 2 nd byte of the machine code is read again, and then the operation code of the received instruction is judged according to the read byte (namely the first 2 bytes). And so on until the operation code of the receiving instruction is judged. It is noted that if the received instruction contains a prefix (prefix) and/or escape code (escape), the translator 145 retrieves the prefix and/or escape code of the received instruction and then retrieves the opcode thereof. In one embodiment, the translation program 145 reads the machine code from memory based on the instruction pointer of the received instruction via the physical memory direct access interface as described above. After obtaining the operation code of the received command, the conversion program 145 executes step S710.

Next, in step S710, the conversion program 145 determines whether the received command is a new command. Specifically, the conversion program 145 determines whether the received command is a new command according to the operation code of the received command. For example, the operation code of the newly added instruction supported by the processor 200 may be stored in a Lookup Table (Lookup Table). The conversion program 145 may check whether the operation code is stored in the lookup table, and if the operation code is stored in the lookup table, the received instruction is a new instruction, and the determination result is yes; otherwise, the judgment result is no. In an embodiment, the lookup table is stored in a system management memory. In one embodiment, the conversion program 145 determines whether the received command is a new command according to the escape code and the operation code of the received command.

When the received command is not the new command (no in step S710), indicating that the received command is the unrecognizable command, the conversion program 145 performs step S725 to generate the conversion result shown in the following table 2-1. As shown in the following table 2-1, the value of the result field of the conversion result is a second value, indicating that the conversion failed; the content field of the conversion result is an exception number # UD (value 6) of the unknown instruction exception.

TABLE 2-1

Results	Content providing method and apparatus
		Second numerical value	#UD

When the above-described received instruction is the addition instruction (yes in step S710), the conversion program 145 executes step S712. In step S712, the conversion program 145 determines whether there is a decoding abnormality. Specifically, as described above (step S605 in fig. 6), the simulation program 142 reads the operating environment information of the processor 200 when executing the received instruction, from the system management memory, where the operating environment information includes the operating mode of the processor 200. The conversion program 145 determines whether the received command can be executed under the execution environment. For example, when the operation mode is the real mode, if the received instruction cannot be operated in the real mode, the determination result in step S712 is yes; if the received command can be operated in the real mode, the determination result of step S712 is no.

In one embodiment, the operation code of the newly added instruction and its supported execution environment are stored in a look-up table. The conversion program 145 can find out, through the lookup table, which execution environments the received instruction can be executed under according to the operation code of the received instruction. In another embodiment, the lookup table is stored in a system management memory.

When the conversion program 145 determines that there is a decoding abnormality in the received instruction (yes in step S712), step S725 is executed to generate a conversion result as shown in table 2-2 below. As shown in table 2-2 below, the value of the result field of the conversion result is a second value, indicating that the conversion failed; the content field of the conversion result is an exception number # UD (value 6) of the unknown instruction exception.

Tables 2 to 2

Results	Content providing method and apparatus
		Second numerical value	#UD

When the conversion program 145 determines that there is no decoding abnormality in the received instruction (no in step S712), step S715 is executed. In step S715, the conversion program 145 obtains other decoded information of the received instruction. Specifically, the translation program 145 continues reading the machine code of the received instruction from the memory byte by byte, decoding the machine code while reading the machine code until other decoded information of the received instruction is decoded, and calculating the length of the received instruction, wherein the other decoded information includes the operand mode (ModR/M), the source operand, the destination operand, and the like. It is known to those skilled in the art that the length of the received instruction can be calculated only after the received instruction is decoded. Then, the conversion program 145 performs step S720.

In step S720, the conversion program 145 converts the received instruction into at least one old instruction. Specifically, the conversion program 145 may convert the received instruction into at least one old instruction by means of a table lookup. For example, at least one old instruction corresponding to the received instruction may be stored in a look-up table. Then, the conversion program 145 obtains the at least one old instruction from the lookup table according to the operation code of the received instruction. In one embodiment, when the received instruction contains an escape code, the conversion program 145 retrieves 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 translation program 145 retrieves the at least one old instruction from the lookup table based on the escape code, the opcode, and the operand pattern of the received instruction.

It is to be noted that, since the at least one old instruction obtained from the lookup table does not include other decoding information such as the source operand and/or the destination operand of the received instruction, the at least one old instruction needs to be written with the other decoding information so as to simulate the execution of the received instruction. For example, the conversion program 145 writes the specific value of the source operand and/or the destination operand of the received instruction into the corresponding location in the at least one old instruction. Processor 200 may then simulate the execution of the newly added instruction by executing the at least one old instruction. In one embodiment, the translation program 145 writes other decode information into the at least one old instruction according to the prefix of the received instruction.

In one embodiment, the lookup table is stored in a Basic Input Output System (BIOS). It is well known in the art that the bios is executed when the system 100 executing the new command is powered on. The bios includes 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. The conversion program 145 can then retrieve the at least one old instruction from the lookup table based on the opcode of the received instruction. In another embodiment, the lookup table is stored in a private rom. Therefore, in these 2 embodiments, the conversion program 145 converts the received instruction into at least one old instruction via a look-up table with hardware support.

In another embodiment, the translation program 145 stores the at least one old instruction into a memory or cache (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 is the same instruction as the other instruction, the translation program 145 retrieves the at least one old instruction directly from the memory or cache.

The conversion program 145 then executes step S725 to generate the conversion results as shown in tables 2-3 below. As shown in tables 2-3 below, the value of the result field of the conversion result is a first value, indicating that the conversion is successful; the content field of the conversion result is the length of the received instruction and the at least one old instruction.

Tables 2 to 3

Results	Content providing method and apparatus
		First value	Receiving the length of an instruction and at least one old instruction

The following describes the procedure by which the conversion program 145 executes the processing flow of fig. 7 in the second case. In the second case, the process of the conversion program 145 performing steps S710, S712, S720 and S725 is the same as in the first case, and is not repeated here. Steps S705 and S715 are described below.

In the second case, different from the first case, in step S705, the conversion program 145 reads the complete machine code of the received instruction from the memory according to the instruction pointer of the received instruction, and then decodes the read machine code to obtain the operation code of the received instruction. In step S715, the conversion program 145 decodes the machine code read in step S705 to obtain other decoded information of the received command. The other processing in the second case is the same as in the first case and will not be described in detail here.

It should be noted 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, so that the machine code needs to be read long enough. For example, if the longest new instruction in the new instructions that can be processed by the processor 200 has a length of 15 bytes, in step S705, the machine code having a length of at least 15 bytes needs to be read.

The following describes the procedure by which the conversion program 145 executes the processing flow of fig. 7 in the third case. In the third case, the process of the conversion program 145 performing steps S710, S712, S715, S720 and S725 is the same as that in the second case, and thus is not repeated herein. Step S705 is described below.

In the third case, different from the second case, in step S705, 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. The other processing in the third case is the same as that in the second case and is not described here.

Fig. 8 is a diagram showing an example of processing an unknown instruction in the system management mode according to the first embodiment of the present invention. Fig. 8 is a specific implementation of a simulator in the form of pseudo code (pseudo code) showing how to implement the process flow of processing unknown instructions as shown in fig. 6 and 7.

As shown in FIG. 8, behaviors 1-25 implement the code that the simulator's main function simulator _ start contains. Behaviors 27-36 implement the code contained in the decoding function check code excep. Behaviors 38-47 include code that includes the emulation function Unresupport _ X _ handle that implements the function of the newly added instruction, including at least one of the old instructions described above that correspond to the received instruction. The main function scalar _ start is described first below.

In the main function simulator _ start, the 3 rd line code is executed first. Line 3 code performs the functions of step S605 of fig. 6, and the processor 200 establishes a simulated execution environment. In line 3 code, the processor 200 builds a simulated execution environment through the function setup _ simulator _ env. After executing the 3 rd line of code, the processor 200 stores the simulation flag, the information of the received instruction, the information of the operating environment of the received instruction, and the information of the architectural register, which are read from the system management memory, into the variable env. For example, in line 4 code, accessed by env. The code of line 4 completes the function of step S610 of fig. 6, and the processor 200 determines whether the simulation flag is the first value. And if the judgment result of the 4 th line of codes is that the simulation identification is not the first numerical value, executing the 5 th line of codes. The code of line 5 completes the function of step S645 of fig. 6, and the processor 200 executes the normal processing flow of the system management mode. In line 5 code, processor 200 performs the normal process flow of entering system management mode through the function exit _ to _ normal _ SMM. If the judgment result of the code in line 4 is that the simulation identifier is the first value, the code in line 8 is executed, and a variable inst _ emu is defined to be an outgoing parameter of a decoding function check _ decode _ excep in the code in line 9 (which will be described later). Line 9 code is then executed.

The codes of lines 9-15 complete the function of step S615 in fig. 6, and the processor 200 converts the received instruction by the conversion program and generates a decoding result. Specifically, the processor 200 executes the code of line 9 first, and obtains decoding information such as an operation code of the received instruction through a decoding function check _ decode _ excep, where the decoding information is stored in an outgoing parameter inst _ emu. Then, the processor 200 executes the code of line 10 to determine whether the decoding is successful. In the code of line 10, the processor 200 determines whether decoding is successful according to the decoding result decode _ excep. If the decode fails, indicating that the conversion failed, the processor 200 executes the code of line 11. The code of line 11 completes the function of step S630 of fig. 6, and the processor 200 writes the simulation execution result of the conversion failure into the system management memory. In line 11, the processor 200 writes the simulation execution result of the conversion failure into the system management memory through the function set _ exception. After the code of the 11 th line is executed, the code of the 12 th line is executed, and the code of the 23 rd line is jumped to. In line 12 code, the processor 200 jumps by the instruction goto to the position of the reference number out (i.e. line 23). Execution then begins to continue from line 23. Since line 23 has only one label out, there is no code to execute and the processor 200 executes the code of line 24. The code on line 24 performs the function of step S635 of fig. 6, and the processor 200 executes the exit system management mode instruction. In line 24 code, processor 200 executes an instruction to exit system management mode via the function execute _ rsm. The processor 200 will then execute the microcode of the SMM egress 1144 shown in FIG. 1. And if the judgment result of the code in the line 10 is that the decoding is successful, executing the code in the line 15. The code of line 15 completes the function of step S720 of fig. 7, and the processor 200 converts the received instruction into at least one old instruction according to the information of the received instruction. As shown in fig. 8, in the line 15 code, the at least one old instruction is located from the table op _ mapping by using the opcode of the received instruction. And representing the at least one old instruction by using a pointer, wherein the value of the route is the address of the UnUpport _ X _ handle function. Then, the code of line 16 is executed.

The code of line 16 performs the function of step S625 of fig. 6, and the processor 200 executes at least one of the old instructions. When executing route, the processor 200 actually executes the simulation function Unsupport _ X _ handle (described in detail later). After execution of the route, a value runtime _ excep is returned. Then, the code of lines 18-19 is executed. The codes on lines 18 to 19 complete the function of step S630 in fig. 6, and the processor 200 determines whether there is an runtime exception. If a runtime exception exists, processor 200 writes the simulation execution result in which the runtime exception occurred into the system management memory. In line 18 of code, processor 200 determines whether a runtime exception exists based on the value of the return value runtime _ exception. If there is a runtime exception, the code of line 19 is executed. In the 19 th line of code, the processor 200 stores the simulation execution result of the runtime exception into the system management memory through the function set _ exception. The processor 200 then executes the code of line 20 and jumps to line 23 via the goto instruction. As previously described, processor 200 may next execute the code of line 24. The function of the code in line 24 has been described above and will not be described in detail here.

The decoding function check _ decode _ excep is described below.

In the decoding function check _ decode _ excep, the codes in the 29 th to 30 th lines are executed first to obtain the operation code of the received instruction (step S705 in fig. 7). On line 29, the processor 200 reads the machine code machine _ code of the received instruction via the function read _ instruction. Here, the machine code machine _ code of the code _ len byte length is read from the memory according to the instruction pointer ip of the received instruction (i.e. the second case described above in explaining fig. 7), and the value of code _ len may be 15. In line 30, the processor 200 decodes the machine code machine _ code by a function decode _ opcode to obtain an operation code opcode of the received instruction. On the 31 st line, the processor 200 determines whether the received instruction is a new instruction according to the operation code opcode through the is _ emulate _ op function (step S710 in fig. 7). If the received instruction is not a new instruction, the processor 200 executes the code of line 32 and returns decode exception information to the main function simulator _ start via the return instruction. If the received instruction is a new instruction, the processor 200 first executes the 33 rd line code and stores the opcode into the outgoing parameter inst _ emu; then, the code in line 34 is executed to obtain other decoded information of the received instruction (step S715 in fig. 7), and the obtained other decoded information is stored in the outgoing parameter inst _ emu. Finally, the processor 200 executes the code of line 35, and returns the decode success information to the main function scalar _ start through the return instruction. The main function simulator _ start may obtain the opcode and other decoding information operands of the received instruction via the outgoing parameter inst _ emu.

The simulation function Unsupport _ X _ handle is described below.

In the simulation function Untupport _ X _ handle, lines 40-41 code is executed first. The 40-41 lines of code complete the operation of reading the operand values, which are stored in the array op. In line 41, the processor completes the operation of reading the operand via the function read _ op. Specifically, the read _ op function takes the operand values from the env variable described above. The line 42 code performs the function of step S625 of fig. 6, and the processor 200 executes at least one old instruction, i.e. the processor 200 simulates executing the above-mentioned received instruction. On line 42, op represents the operand of the received instruction, and operation with op represents writing the value of the operand of the received instruction to the at least one old instruction and executing the at least one old instruction. Line 43 code is then executed. The code on line 43 completes the function of step S630 in fig. 6, and the processor 200 writes the simulation execution results (including the simulation execution result that generates the runtime exception and the simulation execution result that does not generate the runtime exception) into the system management memory. In more detail, in line 43 code, the processor 200 stores the simulation execution results into the system management memory via the function write _ result _ to _ SMRAM. The 44 th line code judges whether the 42 th line is executed to generate a runtime exception, if the 42 th line is executed to generate the runtime exception, the 45 th line code is executed to send exception information to the main function; otherwise, the 46 th line of code is executed, and the correct execution information is sent to the main function. In

lines

45, 46 code, the processor 200 sends exception information or information that execution is correct to the main function simulator _ start via the return instruction.

Fig. 9A to 9B are flowcharts illustrating the exit from the system management mode according to the first embodiment of the present invention. FIGS. 9A-9B illustrate the flow of microcode routines corresponding to the SMM egress 1144 of FIG. 1. Referring to fig. 2 and 9, as shown in fig. 9A to 9B, when exiting the system management mode, the processor 200 determines whether the simulation flag is the first value (S901). If the determination result is "yes", the processor 200 resets the simulation flag (S904), and determines whether there is an abnormality in the simulation execution result (S905). The processor 200 executes an operation of exiting the system management mode according to whether or not there is an exception and the type of the exception in the simulation execution result. The detailed description is as follows: the processor 200 first executes step S901.

In step S901, the processor 200 determines whether the simulation flag is the first value. Specifically, the processor 200 reads the simulation flag from the system management memory (as can be seen from the foregoing description of step S520 in fig. 5, the simulation flag is stored in the system management memory), and then determines whether the read simulation flag is the first value. If the simulation flag is not the first value, the processor 200 executes step S903. In step S903, the processor 200 executes a normal processing flow of exiting the system management mode. For the normal process flow of exiting the system management mode, it is the common knowledge of those skilled in the art, and will not be described herein. If the simulation flag is the first value, the processor 200 executes step S904.

In step S904, the processor 200 resets the simulation flag. In particular, processor 200 sets micro-architectural register 220 and the emulation flag in system management memory to a second value. After resetting the emulation flag, the processor 200 executes the normal processing flow of the system management mode when a normal system management interrupt occurs during the subsequent execution process. Then, the processor 200 executes step S905.

In step S905, the processor 200 determines whether there is an abnormality in the simulation execution result. Specifically, the processor 200 reads the exception vector table as shown in table 4 above from the system management memory. If the value of the abnormal identification field of the abnormal vector table is a first numerical value, the abnormal execution result is represented, and the judgment result is yes; and if the value of the abnormal identification field of the abnormal vector table is a second numerical value, the simulation execution result is not abnormal, and the judgment result is 'no'. If the determination result is "no", the processor 200 performs step S907.

As shown in fig. 9B, in step S907, the processor 200 stores the simulation execution result stored in the system management memory into the architectural register. As described above, in step S630 of fig. 6, the processor 200 has written the simulation execution result of the received instruction into the corresponding area of the architectural register in the system management memory. In this step, processor 200 stores the value in the region corresponding to the architectural register in system management memory into architectural register 260. Thus, it is equivalent to the processor 200 having executed the received instruction.

If the destination operand of the received instruction is a new architectural register, the processor 200 will not store the value in the area of the system management memory emulating the new architectural register into the architectural register 260 because the architectural register 260 of the processor 200 does not include the new architectural register. As described above, when the processor 200 is simulating the execution of another newly added instruction, and the operand of the another newly added instruction is the new architectural register, the processor 200 can directly use the value stored in the region of the system management memory simulating the new architectural register to simulate the execution of the another newly added instruction.

Then, the processor 200 executes step S909. In step S909, the processor 200 enables the interrupt. 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, the processor 200 executes step S911.

In step S911, the processor 200 issues an exit system management mode notification (Deassert # smmact) to notify the chipset that the processor 200 exits the system management mode. Then, the processor 200 executes step S913 and exits the system management mode.

As shown in fig. 9A, when the processor 200 determines in step S905 that there is an abnormality in the simulation execution result, step S915 is performed.

In step S915, the processor 200 determines whether the exception type is Trap (Trap). Specifically, the processor 200 determines whether the exception in the simulation execution result is a trap or not, based on the exception identifier and the exception number in the exception vector table read from the system management memory in step S905. For example, when the exception is identified as a first value and the exception number is 3 (Table 4 is shown below in Table 4-2), an Overflow exception is indicated. The type of overflow exception is trap, so the determination result is yes. When the exception flag is a first value and the exception number is 0 (table 4 is shown below in tables 4-3), it indicates a division error exception. The division error exception is an error (Fault) and is not a trap, so the determination result is no.

TABLE 4-2

Anomaly identification	Exception numbering
		First value	3

Tables 4 to 3

Anomaly identification	Exception numbering
		First value	0

When the determination result of step S915 is no, the processor 200 performs steps S917, S919, S921, and S723. Step S917, step S919, and step S921 are the same as step S909, step S911, and step S913, respectively, and are not repeated here. Step S923 is described below.

In step S923, the processor 200 executes an exception microcode handler. Specifically, the processor 200 determines whether an abnormality has occurred based on an abnormality flag in an abnormality vector table stored in the system management memory. If an exception is generated, the processor 200 executes the microcode handler for the exception according to the exception number stored in the exception vector table. Namely, a microcode handler for executing an exception corresponding to the exception number. For example, when the exception flag in the exception vector table stored in the system management memory is a first value, it indicates that there is an exception in the simulation execution result. If the exception number in the exception vector table is 0 at this time, indicating that the exception is a division error, the processor 200 executes a microcode handler for the division error.

In step S915, when the determination result is yes, that is, the abnormality type of the simulation execution result is trap, the processor 200 executes steps S925, S927, S929, and S933 shown in fig. 9B. Wherein, steps S925, S927, and S929 are the same as steps S907, S909, and S911, respectively, and are not repeated here. Step S933 is described below.

In step S933, the processor 200 executes an exception microcode handler. For example, when the simulation execution result has an exception, and the exception is an overflow exception, the processor 200 executes the microcode handler of the overflow exception. In the actual operation of exiting the SMM through the SMI egress 1144 shown in FIGS. 9A and 9B, after calling an instruction (RSM) to exit the SMM, a person skilled in the art may add some microcode for storing the simulation execution result from the SMM into the architectural register to transmit the simulation execution result to the application 130 or the OS 120. Since the microcode will vary depending on the processor version, one skilled in the art can write the corresponding microcode according to the actual situation.

Notably, in the first embodiment, micro-architectural registers 220 are registers that are inherently present in processor 200. Thus, in the first embodiment of the present invention, the newly added instruction can be executed on the previous generation processor without modifying the hardware structure of the processor. Therefore, in the first embodiment of the present invention, the processor that has been produced can be made to obtain the function of executing the newly added instruction by upgrading the microcode.

[ second embodiment ]

Fig. 10 is a diagram illustrating a system 1000 for executing a new instruction according to a second embodiment of the invention. Unlike the first embodiment shown in FIG. 1, the translation program 145 in the system 1000 for executing the newly added instruction shown in FIG. 10 runs directly on the processor in the same execution mode as the newly added instruction. In addition, since the conversion program 145 in the second embodiment is operated in the same execution mode as the newly added instruction, the processor does not need to switch the operation mode when executing the conversion program 145. Differences of the second embodiment from the first embodiment are described in detail below.

As shown in FIG. 10, when instruction 118 is unknown instruction 132, processor 110 executes a microcode handler that handles the exception of the unknown instruction. In a microcode handler that handles an unknown instruction exception, the translator 145 is called directly (as shown by the solid arrow 2 in FIG. 10). The conversion routine 145 will determine whether the unknown instruction 132 is a new instruction. If the unknown instruction 132 is a new instruction, the conversion program 145 converts it to at least one old instruction and sends the at least one old instruction to the microcode handler that handles the exception of the unknown instruction (shown by solid arrow 6 in FIG. 10). A microcode handler that handles exceptions to unknown instructions receives the at least one old instruction and causes the processor 110 to execute the at least one old instruction via a call instruction (call) or a jump instruction (jump).

Fig. 11 is a block diagram of a processor according to a second embodiment of the invention. The functions of the elements with the same names in fig. 11 and fig. 2 are the same, and are not described again.

It is noted that, as shown in FIG. 11, the processor 1100 to the left of the dashed line is the block diagram of the processor 110 shown in FIG. 10, and the conversion program 145 to the right of the dashed line runs on the processor 1100 in the same execution mode as the newly added instruction (i.e., the processor does not need to switch execution modes). The translation program 145 may be stored in the interrupt pre-processing unit 112 within the processing core of the processor 1100. In another embodiment, the translation program 145 may be stored in a non-core (Uncore) of the processor 1100. Thus, all processing cores of processor 1100 may share translation program 145.

Fig. 12 is a flowchart illustrating the execution of a new instruction according to a second embodiment of the invention. The process flow shown in FIG. 12 may be performed by processor 1100 of FIG. 11. As shown in fig. 12, the processor 1100 receives an instruction (S1205), and when the received instruction is an unknown instruction, an unknown instruction exception is issued (S1210). In response to the unknown instruction exception, a conversion procedure is performed to determine whether the received instruction is a new instruction (S1215). When the received command is a new command, the received command is converted into at least one old command by the conversion program (S1220). Finally, the processor 1100 executes the at least one old instruction in the same execution mode as the received instruction (S1225). Steps S1205 and S1210 of fig. 12 are the same as steps S305 and S310 of fig. 3, and are not repeated here. Steps S320 and S325 of fig. 3 are different from steps S1220 and S1225 of fig. 12 in that steps S320 and S325 of fig. 3 operate in a system management mode, and steps S1220 and S1225 of fig. 12 operate in the same execution mode as the above-described received instruction. The functions performed in steps S320 and S325 of fig. 3 and steps S1220 and S1225 of fig. 12 are the same, and are not described herein. Only step S1215 is described below.

In step S1215, in response to the unknown instruction being abnormal, the processor 1100 determines whether the received instruction is a new instruction through a conversion routine. In particular, after an unknown instruction exception is issued by instruction commit unit 245, processor 1100 executes a microcode handler that handles the unknown instruction exception. In a microcode handler that handles an unknown instruction exception, the processor 1100 sends the received instruction information and operating environment information to the translator 145. The conversion program 145 determines whether the received command is a new command according to the information of the received command. How the conversion program 145 determines whether the received instruction is a new instruction has been described in detail in the first embodiment, and is not described herein again.

Fig. 13 is a flowchart showing a process of receiving an instruction according to the second embodiment of the present invention. Steps S1305, S1310, S1325 of fig. 13 are the same as steps S405, S410, S435 of fig. 4, and are not repeated here. Step S1320 is described below.

In step S1320, the processor 1100 of fig. 11 processes the above reception instruction. Specifically, when the received instruction is an unknown instruction (yes in step S1310), the processor 1100 executes a microcode handler for handling an exception of the unknown instruction. In a microcode handler that handles exceptions to unknown instructions, the processor 1100 processes the unknown instructions through the translator 145 (described in more detail below in conjunction with FIG. 14).

FIG. 14 is a flowchart illustrating processing of a received instruction in a microcode handler to handle an unknown instruction exception according to a second embodiment of the invention. As shown in fig. 14, the processor 1100 of fig. 11 acquires information of a reception instruction (S1405), converts the reception instruction by the conversion program 145, and generates a conversion result (S1410). If the conversion is successful (yes in step S1415), the processor 1100 obtains at least one old instruction from the conversion result and executes the at least one old instruction (S1420). The detailed description is as follows: the processor 1100 first executes step S1405.

In step S1405, information of the received instruction is obtained in the microcode handler with unknown instruction exception. The information of the received command includes a command pointer of the received command. Note that, since the received command is not decoded at this time, the information of the received command does not include decoding information such as a prefix, an escape code, and an opcode. When executing a microcode handler with an unknown instruction exception, the operating environment of the processor 1100 will not change because mode conversion is not required. Therefore, in the microcode handler with unknown instruction exception, the running environment information of the processor 1100 can be directly obtained, and the running environment information is the running environment information of the received instruction. Then, step S1410 is performed.

In step S1410, the processor 1100 converts the above-described reception instruction by the conversion program 145, and generates a conversion result. How to convert the received instruction by the conversion program 145 is the same as the processing procedure in the first embodiment, and is not described herein again. Step S1415 is the same as step S620 of fig. 6, and is not repeated here. Steps S1420 and S1425 are described below.

When the conversion program 145 is converted successfully (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. Further, the processor 1100 may obtain the length of the received instruction from the conversion result. In an embodiment, the next instruction of the received instructions is another instruction. The last instruction in the at least one old instruction is a jump instruction (jump) or a call instruction (call), through which the processor 1100 jumps to the other instruction. The instruction pointer of the another instruction is: EIP + Length, wherein EIP is an instruction pointer of the received instruction, and Length is the Length of the received instruction.

When the conversion program 145 fails in the conversion (no in step S1415), the processor 1100 executes step S1425. In step S1425, the processor 1100 processes the exception. Specifically, any exception that occurs when the translation program 145 translates the received instruction will cause the translation to fail. In a microcode handler of the interrupt pre-processing unit 112 that handles an unknown instruction exception, an exception number may be obtained from the content field of the translation result. Then, the microcode handler that handles the unknown instruction exception issues an exception corresponding to the exception number. In response to the exception corresponding to the exception number, processor 1100 executes a corresponding microcode handler to handle the exception.

The processing flow of the conversion procedure of the second embodiment is the same as the processing flow of the conversion procedure of fig. 7 in the first embodiment, and is not repeated here.

In summary, unlike the first embodiment, in the present embodiment, when the processor 1100 executes an unknown instruction, the processor 1100 executes the conversion program 145 in the same execution mode as the unknown instruction. The conversion program 145 determines whether the unknown command is a new command. When the unknown instruction is a new instruction, the conversion program 145 converts the new instruction into at least one old instruction. Processor 1100 then executes the at least one old instruction in the same execution mode as the unknown instruction. Compared with the first embodiment, in the embodiment, the processor does not need to switch the execution mode, so that the simulation execution of the newly added instruction is more efficient.

[ third embodiment ]

FIGS. 15A-15B are diagrams illustrating a system 1500 for executing a new instruction according to a third embodiment of the invention. Unlike the first embodiment shown in fig. 1 and the second embodiment shown in fig. 10, in the third embodiment, the conversion program 145 in the system 1500 that executes the newly added instruction is executed by the kernel driver 150 in the operating system 120. The conversion program 145 may be located inside (as shown in FIG. 15A) or outside (as shown in FIG. 15B) the kernel driver 150. Referring to FIG. 11 and FIGS. 15A-15B, when processor 1100 determines that instruction 118 is unknown instruction 132, it issues an unknown instruction exception. In response to the unknown instruction exception, processor 1100 executes a microcode handler for the unknown instruction exception. In a microcode handler with an exception to an unknown instruction, the processor 1100 may call the kernel driver 150 and send the information of the unknown instruction 132 and the operating environment information to the kernel driver 150. The kernel driver 150 processes the above-described reception instruction through the conversion program 145.

In one embodiment, in a microcode handler for unknown instruction exceptions, processor 1100 calls kernel driver 150 through a self-defined interrupt service routine (the developer of the interrupt service routine may call the self-defined interrupt handler via a self-defined interrupt vector # NE (Non-support interrupt indicator), where the self-defined interrupt vector # NE is in a reserved number of the interrupt vector table). It should be noted that when the interrupt service program calls the kernel driver 150, the information (including the instruction pointer, etc.) and the runtime environment information of the unknown instruction 132 must be transmitted to the kernel driver 150, or the kernel driver 150 must be notified of the storage address of the information and the runtime environment information of the unknown instruction 132. The interrupt service routine (interrupt service routine corresponding to the self-defined interrupt vector # NE) used by the kernel driver 150 may be microcode stored in the interrupt preprocessing unit 112 and called by the interrupt preprocessing unit 112 (the interrupt preprocessing unit 112 may be configured by a state machine or a combinational logic circuit). In one embodiment, the kernel driver 150 can call the operating System 120 to execute the kernel driver 150 via a System call (System call) by the way the translation program 145 processes the unknown instruction 132, for example, the kernel driver 150 is used as a callback function (callback function), and the information of the unknown instruction 132 and the runtime environment information are used as parameters to be 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 the conversion program 145 processes the unknown instruction 132. Alternatively, the Kernel driver 150 may be invoked by an internal interrupt (internal interrupt) or Trap (Trap), for example, a designer of the processor 1100 may define an interrupt vector # NE and enter the Kernel (Kernel) of the operating system to call the Kernel driver 150, which will not be described in detail herein. In one embodiment, the process of sending the information of the unknown instruction 132 and the running environment information in the microcode handler of the unknown instruction exception is: the information of the unknown instruction 132 and the execution environment information are pushed into a (push) stack (stack), and then the kernel driver 150 acquires the information of the unknown instruction 132 and the execution environment information from the stack.

In another embodiment, an interrupt service routine in the operating system that handles the exception of the unknown instruction may be modified to call the kernel driver 150 directly to enable processing of the unknown instruction 132. In the modified interrupt service routine for handling the exception of the unknown instruction, the information of the unknown instruction 132 and the operating environment information may be read first, and the read information of the unknown instruction 132 and the operating environment information may be transmitted to the kernel driver 150. In this embodiment, the processing of the unknown instruction as described above can be implemented by modifying the interrupt service routine for handling the exception of the unknown instruction in the operating system without modifying hardware and/or microcode of the processor, which is quite convenient to implement. In practice, one skilled in the art may modify the interrupt service routine that handles the exception of the unknown instruction to add information to read the unknown instruction 132 and run environment information, and to invoke the functionality of the kernel driver 150. Since the interrupt service routine for handling the unknown instruction exception may vary depending on the operating system and/or processor version, one skilled in the art may write the corresponding code as is practical.

FIG. 16 is a flowchart illustrating a process for receiving instructions according to a third embodiment of the present invention. Steps S1605, S1610, S1625 of fig. 16 are the same as steps S1305, S1310, S1325 of fig. 13 of the second embodiment, and are not repeated here. Step S1620 is described below.

Referring to fig. 11, 15A-15B, and 16, the process flow shown in fig. 16 may be executed by the processor 1100 of fig. 11. In step S1620, the processor 1100 processes the reception instruction. Specifically, when the received instruction is an unknown instruction, the processor 1100 calls the conversion program 145 to process the received instruction in the microcode handler for handling the exception of the unknown instruction, through the kernel driver 150 of the operating system 120. It should be noted that, compared to the present embodiment, in the step S1320 in fig. 13 of the second embodiment, when the received instruction is an unknown instruction, in the microcode handler for handling the exception of the unknown instruction, the processor 1100 directly processes the received instruction through the translation program 145.

In one embodiment, the transformation program 145 is a driver or application of the operating system 120. The other processing flows in the third embodiment are the same as those in the second embodiment, and are not described herein again.

In summary, different from the second embodiment, in this embodiment (third embodiment), when the processor 1100 executes an unknown instruction, the microcode handler for handling the exception of the unknown instruction executes the kernel driver 150 of the os 120 to subsequently process the convertible new instruction. Compared with the second embodiment, in the embodiment, the kernel driver of the operating system is used for converting the new instruction through the conversion program, and compared with the updating of hardware of the processor and/or microcode in the processor, the updating of the kernel driver and the conversion program is more convenient and quicker, so that the development efficiency is improved.

[ fourth embodiment ]

Fig. 17 is a diagram illustrating a system 1700 for executing a new instruction according to a fourth embodiment of the invention. As in the third embodiment, in the present embodiment (fourth embodiment), the conversion program 145 in the system 1700 that executes the newly added instruction is also run by the kernel driver 150 in the operating system 120. The difference is that in the present embodiment, the conversion program 145 runs on a dedicated processing core 190. The kernel driver 150 sends the information of the unknown instruction 132 and the execution environment information to the conversion program 145 through a Polling (Polling) or Doorbell (Doorbell) mechanism. The translation program 145 also needs to send the translation results to the kernel driver 150 through a polling or doorbell mechanism. The following describes how data is transferred between the kernel driver 150 and the translation program 145, in particular by a polling or doorbell mechanism, respectively.

The polling mechanism is described first below. Referring to fig. 11 and 17, in an embodiment, a designer of the processor 1100 may set a transfer register (not shown) in a noncore (noncore) of the processor 1100 for storing information of the unknown instruction 132, the execution environment information, a transfer information flag and a transfer result flag (all not shown in fig. 17), wherein the default values of the transfer information flag and the transfer result flag are the second values. The kernel driver 150 stores the information of the unknown instruction 132 and the execution environment information into the transfer register, and stores the transfer information flag having the first value into the transfer register. Then, the kernel driver 150 reads the transmission result id in the transmission register at regular intervals (for example, every 100 msec) to wait for receiving the conversion result. If the transfer result flag is read as the first value, indicating that the conversion program 145 has generated the conversion result, the kernel driver 150 will read the conversion result from the transfer register. In addition, the translation program 145 running on the special purpose processing core 190 is configured to check, when idle, whether the transfer information flag in the transfer register is the first value at regular intervals (e.g., every 100 milliseconds). If the transfer information flag in the transfer register is a first value, the translation program 145 reads the information of the unknown instruction 132 and the execution environment information from the transfer register, and then sets the transfer information flag in the transfer register to a second value. The conversion program 145 then performs the conversion process on the unknown instruction 132 as described above to generate a conversion result. The conversion program 145 then stores the conversion result in the transfer register, and stores the transfer result flag with the first value in the transfer register. As described above, since the transfer result flag is the first value, kernel driver 150 reads the translation result from the transfer register and sets the transfer result flag in the transfer register to the second value. At this point, a data transfer is completed between kernel driver 150 and translator 145. In another embodiment, in a multi-core processor architecture, it is also necessary to store the numbers of the processing cores in the transfer registers or allocate a dedicated memory space for each processing core in the transfer registers, so that the kernel driver 150 running on each processing core can perform data transfer with the translator 145.

The doorbell mechanism is described below. Referring also to FIGS. 11 and 17, in one embodiment, a designer of the processor 1100 may set a transfer register (not shown) in the uncore of the processor 1100 for storing information about the unknown instruction 132 and execution environment information (neither shown in FIG. 17). After the kernel driver 150 stores the information of the unknown instruction 132 and the execution environment information in the transfer register, the conversion program 145 running on the special purpose processor 190 is notified by means of an interrupt. In response to the interrupt, the conversion program 145 reads the information of the unknown instruction 132 and the execution environment information from the transfer register and generates a conversion result. The translation program 145 then stores the translation result in a transfer register and notifies the kernel driver 150 by means of an interrupt. In response to the above-described interrupt, the kernel driver 150 reads the conversion result from the transfer register. Thus, a data transfer between the kernel driver 150 and the translator 145 is completed. How to set the interrupt, for example, defining the interrupt service routine for the kernel driver 150 and the conversion routine 145 and defining the corresponding interrupt vector number for each of them, has already been described above, and is not described herein again. In another embodiment, a hardware interrupt signal line (PIN) may be added separately to processor 1100 and/or dedicated processor 190, through which kernel driver 150 and/or translator 145 may trigger interrupts to complete data transfers.

Other processing flows in this embodiment are the same as those in the third embodiment, and are not described herein again.

In another embodiment, the functions of the conversion program 145 described in the first, second and fourth embodiments may be implemented in a hardware circuit.

As can be seen from the above, in the present embodiment, the conversion of the new instruction is also realized by the kernel driver 150 of the operating system 120, as in the third embodiment. Unlike the third embodiment, in the present embodiment, the conversion program 145 runs on the dedicated processing core 190. In the embodiment, since the conversion program 145 runs on the dedicated processing core 190, the execution speed is fast; in addition, the workload of the other processing cores of the processor is reduced since there is no need to run a translator 145 in each processing core.

Fig. 18 is a flowchart illustrating the execution of the new instruction according to an embodiment of the invention. Referring to fig. 11, 17 and 18, as can be seen from the above description of the third embodiment and the present embodiment, the processor 1100 receives an instruction (S1805), and when the received instruction is an unknown instruction, the processor 1100 executes a conversion program through the operating system 120 (S1810). In the conversion process, 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). Steps S1805, S1815, S1820, and S1825 in fig. 18 have already been described in detail in the first embodiment, and are not described herein again. Step S1810 is described below.

In step S1810, when the received instruction is an unknown instruction, the processor 1100 executes a conversion program through the operating system. Specifically, as can be seen from the foregoing description of the third embodiment and the present embodiment, when the received instruction is an unknown instruction, the instruction issue unit 245 issues an unknown instruction exception. In response to the unknown instruction exception, processor 1100 executes a microcode handler for the unknown instruction exception. In microcode handlers for unknown instruction exceptions, kernel drivers 150 for the operating system are invoked. The kernel driver 150 of the operating system recalls the translator 145.

FIG. 19 is a flowchart illustrating the execution of a new instruction according to an embodiment of the invention. Referring to fig. 11, 17 and 19, as can be seen from the above description of the first, second, third and present embodiments, the processor 1100 receives an instruction (S1905), and when the received instruction is an unknown instruction, the processor 1100 starts a conversion procedure (S1910). In the conversion process, it is determined whether the received command is a new command (S1915), and when the received command is a new command, the received command is converted into at least one old command (S1920). Finally, processor 1100 simulates execution of the received instruction by executing the at least one old instruction (S1925). Steps S1905, S1915, S1920 and S1925 in fig. 19 have already been described in detail in the first embodiment, and are not repeated here. Step S1910 is described below.

In step S1910, when the received instruction is an unknown instruction, the processor 1100 starts a conversion routine. Specifically, as can be seen from the foregoing description of the first, second, third and present embodiments, when the received instruction is an unknown instruction, the instruction issue unit 245 issues an unknown instruction exception. In response to the unknown instruction exception, processor 1100 executes a microcode handler for the unknown instruction exception.

Specifically, in the first embodiment, a microcode handler with unknown instruction exceptions issues a system management interrupt (# SMI). In response to the above-described system management interrupt, processor 1100 enters system management mode. In system management mode, simulator 142 is started and converter 145 is started by simulator 142. In the second embodiment, a microcode handler with an unknown instruction exception directly initiates the translator 145. In the third embodiment and the present embodiment, the microcode handler for unknown instruction exceptions calls the kernel driver 150 of the operating system 120. Kernel driver 150 of operating system 120 then recalls translator 145.

FIG. 20 is a flowchart illustrating converting a new instruction according to an embodiment of the invention. Referring to fig. 11, 17 and 20, as can be seen from the above description of the first, second, third and present embodiments, 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 of fig. 20 have been described in detail, and are not described again here.

With respect to the described embodiments of the present invention, an exemplary operating environment in which embodiments of the present invention may be implemented is described below. With specific reference to FIG. 21, FIG. 21 illustrates an exemplary operating environment for implementing embodiments of the present invention that can be generally considered a computing device 2100. The computing device 2100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing device 2100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

The present invention may be implemented in a computer or machine using instructions that are computer-executable instructions of program modules that are executed by a 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., which refer to program code that performs particular tasks or implements particular abstract data types. The present invention may be implemented in a variety of system configurations, including portable devices, consumer electronics, general purpose computers, more specialty computing devices, and the like. The present invention may also be implemented in a distributed computing environment, processing devices linked by a communications network.

Please refer to fig. 21. The computing device 2100 includes a bus 2110 that directly or indirectly couples the following devices, 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. The bus 2110 may be a component of one or more buses, such as an address bus, a data bus, or a combination thereof. Although the blocks of FIG. 21 are illustrated with lines for simplicity, in practice, the boundaries of the various elements are not specific, e.g., the presentation elements of the display device may be considered to be I/O elements; the processor may have a memory.

Computing device 2100 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by 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 may comprise computer storage media and communication media. Computer-readable media include both 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, Random Access Memory (RAM), Read-Only Memory (ROM), Electrically-Erasable-Programmable-Read-Only Memory (EEPROM), flash Memory or other Memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic disks, 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 computing device 2100. Computer storage media itself does not include signals.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modular data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modular data signal" means a signal that has one or more sets of characteristics or is modified 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, RF, infrared and other wireless media. Combinations of the above are included within the scope of computer-readable media.

Memory 2112 includes computer storage media in the form of volatile and nonvolatile memory. The memory may be removable, non-removable, or a combination of the two. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. The system management memory in the first embodiment is located in the memory 2112.

The computing device 2100 includes one or more processors 2114 that read data from entities such as memory 2112 or I/O elements 2120. The display component 2116 displays data indications to a user or other device. Exemplary display elements include a display device, a speaker, a printing element, a vibrating element, and the like.

The I/O ports 2118 allow the computing device 2100 to be logically connected to other devices including I/O elements 2120, some of which are built-in devices. Exemplary elements include a microphone, joystick, game pad, satellite dish receiver, scanner, printer, wireless device, etc. The I/O element 2120 may provide a Natural User Interface (NUI) for processing User-generated gestures, sounds, or other physiological inputs. In some examples, these inputs may be transmitted to a suitable network element for further processing. The natural user interface may enable any combination of language recognition, touch and stylus recognition, facial recognition, biometric recognition, gesture recognition on and near the screen, air gestures, head and eye tracking, and touch recognition associated with display by the computing device 2100. The computing device 2100 may be equipped with a depth camera, such as a stereo camera system, an infrared camera system, an RGB camera system, and combinations of these systems, to detect and recognize gestures. Additionally, the computing device 2100 may be equipped with an accelerometer or gyroscope to detect motion. The output of the accelerometer or gyroscope may be provided to the computing device 2100 for display to present an immersive augmented reality or virtual reality.

In addition, the processor 2114 in the computing device 2100 may also execute the programs and instructions in the memory 2112 to present the actions and steps described in the above embodiments, or other items described in the specification.

Any particular order or hierarchy of steps for processes disclosed herein is by way of example only. Based upon design preferences, it should be understood that any specific order or hierarchy of steps in the processes may be rearranged within the scope of the disclosures made in this document. The accompanying method claims present elements of the various steps in a sample order, and are therefore not to be limited to the specific order or hierarchy presented.

The use of ordinal terms such as "first," "second," "third," etc., in the claims to modify an element does not by itself connote any priority, precedence, order of various elements, or order of steps performed by the method, but are used merely as labels to distinguish one element from another element having a same name (but for use of a different ordinal term).

The above description is only for the preferred embodiment of the present invention, and it is not intended to limit the scope of the present invention, and any person skilled in the art can make further modifications and variations without departing from the spirit and scope of the present invention, therefore, the scope of the present invention should be determined by the claims of the present application.

Claims

1. A method for executing a newly added instruction in a processor, comprising:

receiving an instruction;

when the received instruction is an unknown instruction, sending an unknown instruction exception;

responding to the abnormality of the unknown instruction, and entering a system management mode; and

in the system management mode, through a conversion program:

judging whether the received instruction is a new instruction or not; and

and when the received instruction is a new instruction, simulating the execution of the received instruction by executing at least one old instruction.

2. A method as claimed in claim 1, wherein the received instruction is an instruction set architecture instruction and the at least one old instruction is an instruction set architecture instruction.

3. The method of executing a add-on instruction of claim 1, further comprising:

decoding the at least one old instruction into at least one microinstruction; and

and executing the at least one microinstruction.

4. The method of executing a add-on instruction of claim 1, further comprising:

when the received instruction is an unknown instruction, writing the simulation identification into a micro-architecture register; and

and sending out the system management interrupt.

5. A method as claimed in claim 4, wherein the emulation flag is a first value indicating that the received instruction is to be emulated.

6. The method of executing a add-on instruction of claim 1, further comprising:

obtaining an analog identification, an instruction pointer of the received instruction, a machine code of the received instruction and operation environment information of the received instruction from a micro-architecture register;

storing the simulation mark, the instruction pointer of the received instruction, the machine code and the operating environment information into a system management memory; and

and entering the system management mode.

7. A method of executing a add-on instruction as in claim 6, further comprising, in the system management mode:

acquiring the simulation identification from the system management memory; and

and when the simulation mark is a first value, judging whether the received instruction is a new instruction according to the machine code, wherein the first value represents that the received instruction is a to-be-simulated instruction.

8. The method of claim 6, wherein in the system management mode, when the received command is a new command, the method further comprises:

if the received instruction cannot be executed in the operating environment, generating a decoding exception; and

and storing the decoding exception into the system management memory, and setting an exception identifier in the system management memory.

9. The method of executing a add-on instruction of claim 6, further comprising:

when the received instruction is an unknown instruction, the simulation flag, the instruction pointer of the received instruction, the machine code, and the execution environment information are written into the micro-architecture register.

10. A method as claimed in claim 1, further comprising, in the system management mode:

acquiring the machine code of the receiving instruction from a system management memory;

decoding the machine code to obtain an operation code of the received instruction; and

and judging whether the received instruction is a new instruction or not according to the operation code.

11. The method of claim 10, wherein in the system management mode, when the received command is a new command, the method further comprises:

generating the at least one old instruction according to the operation code; and

executing the at least one old instruction.

12. A method for performing a add-on instruction as in claim 10, further comprising:

decoding the machine code to obtain other decoding information of the received instruction, wherein the other decoding information comprises a source operand and a destination operand; and

executing the at least one old instruction according to the other decoded information.

13. The method of claim 10, wherein in the system management mode, when the received command is not a new command, the method further comprises:

generating an exception number of the unknown instruction exception; and

and storing the abnormal number into the system management memory, and setting an abnormal identifier in the system management memory.

14. A method of executing a add-on instruction as in claim 1, wherein in the system management mode, the method further comprises:

reading the instruction pointer of the received instruction from a system management memory;

reading the machine code of the received instruction from a system memory according to the instruction pointer; and

and judging whether the received instruction is a new instruction or not according to the machine code.

15. A method of performing a new add instruction as recited in claim 1, wherein when said received instruction is a new add instruction, said method further comprises:

and storing a simulation execution result into a system management memory in the system management mode, wherein the simulation execution result is obtained by executing the at least one old instruction.

16. A method of performing a new add instruction as recited in claim 15, wherein when said received instruction is a new add instruction, said method further comprises:

and writing the simulation execution result stored in the system management memory into an architecture register when the system management mode is exited.

17. A method of performing a new add instruction as recited in claim 1, wherein when said received instruction is a new add instruction, said method further comprises:

calculating the length of the received command; and

if no exception is generated during the execution of the at least one old instruction, updating the value of the instruction pointer of the received instruction stored in the system management memory to: EIP + Length, wherein EIP is a value before the instruction pointer of the received instruction is updated, and Length is the Length.

18. A method of performing a new add instruction as recited in claim 1, wherein when said received instruction is a new add instruction, said method further comprises:

calculating the length of the received command; and

if an exception occurs during execution of the at least one old instruction and the exception is a trap, updating a value of an instruction pointer of the received instruction stored in the system management memory to: EIP + Length, where EIP is a value of the received instruction before the instruction pointer is updated, and Length is a Length of the received instruction.

19. A method of executing a new add instruction as in claim 1, wherein the conversion program is pre-stored in the bios.

20. The method of executing a add-on instruction of claim 19, further comprising:

executing the basic input and output system; and

and loading the conversion program into a system management memory.

21. The method of executing a add-on instruction of claim 1, further comprising:

in the above system management mode:

acquiring a simulation identifier from a system management memory; and

when the simulation flag is a first value, the conversion program is executed, wherein the first value indicates that the received instruction is a to-be-simulated instruction.

22. A method of performing a new add instruction as recited in claim 1, wherein when said received instruction is a new add instruction, said method further comprises:

judging whether an exception is generated in the process of executing the at least one old instruction; and

if the abnormality occurs, the abnormality is stored in a system management memory, and an abnormality identifier is set in the system management memory.

23. A method as claimed in claim 22, wherein the exceptions include decode exceptions and run-time exceptions.

24. A method of performing a new add instruction as in claim 22, when the received instruction is a new add instruction, the method further comprising:

judging whether the abnormality is generated according to the abnormality identifier stored in the system management memory; and

if the judgment result is that the exception is generated, after the system management mode is exited, the microcode processing program of the exception stored in the system management memory is executed.

25. A method of performing a new add instruction as in claim 22, when the received instruction is a new add instruction, the method further comprising:

when the exception is a trap, the value stored in the architectural register is restored using the information stored in the system management memory when the system management mode is exited.

26. The method of claim 1, wherein when the received instruction is a new instruction and the operand of the received instruction is an architected register, the architected register is emulated using system management memory in the system management mode.

27. A method as claimed in claim 26, wherein when the added architectural register is a destination operand of the received instruction, the method further comprises:

and after simulating the execution of the received instruction, storing the operation result of the received instruction into the system management memory.

28. A method as claimed in claim 27, wherein when the added architectural register is a destination operand of the received instruction, the method further comprises:

when the system management mode is exited, the operation result stored in the system management memory is not stored in the configuration register.

29. The method of executing a add-on instruction of claim 27, further comprising:

when the received another instruction is a new instruction and the new architectural register is a source operand of the another instruction, the operation result stored in the system management memory is directly used to simulate the execution of the another instruction.

30. The method of claim 1, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the method further comprises:

converting the virtual address of the memory operand into a physical address; and

and reading the numerical value of the memory operand according to the physical address, wherein the physical address is not in a system management memory.

31. The method of claim 30, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the method further comprises:

and converting the virtual address of the memory operand into a physical address by accessing the page table through a physical memory direct access interface.

32. The method of claim 30, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the method further comprises:

and reading the numerical value of the memory operand according to the physical address through a model special register.

33. The method of claim 32, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the method further comprises:

writing the address of the model-specific register into a first register;

writing the physical address into a second register; and

a write model specific register instruction is executed to store the value of the memory operand in the model specific register.

34. The method of claim 33, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the method further comprises:

and executing a read model specific register instruction to read the numerical value of the memory operand from the model specific register and store the read numerical value of the memory operand into the second register.

35. The method of claim 33, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the method further comprises:

after the write model specific register instruction is executed, the micro instruction is loaded from the physical address, and the numerical value of the memory operand is loaded into the model specific register from the system memory.

36. A system for executing a newly added instruction, comprising:

an instruction decoding unit for receiving an instruction and judging whether the received instruction is an unknown instruction; and

the instruction submitting unit is used for sending an unknown instruction exception when the received instruction is an unknown instruction;

responding to the abnormity of the unknown instruction, the system for executing the newly added instruction enters a system management mode, and in the system management mode, the system for executing the newly added instruction converts a program:

judging whether the received instruction is a new instruction or not; and

37. A system as recited in claim 36, wherein the received instruction is an instruction set architecture instruction and the at least one old instruction is an instruction set architecture instruction.

38. A system for performing a new instruction as recited in claim 36, wherein the system for performing a new instruction decodes the at least one old instruction into at least one microinstruction; and the system for executing the new added instruction executes the at least one microinstruction.

39. The system of claim 36, wherein the system for executing the new instruction writes an emulation flag into a microarchitectural register when the received instruction is an unknown instruction; and the system executing the new instruction sends the system management interrupt.

40. A system for performing a add-on instruction as recited in claim 39, wherein the emulation indicator is a first value indicating that the received instruction is an instruction to be emulated.

41. A system for performing a add-on instruction as recited in claim 36, wherein in response to the system management interrupt, the system for performing the add-on instruction obtains an emulation flag, an instruction pointer of the received instruction, a machine code of the received instruction, and runtime environment information of the received instruction from a micro-architectural register, wherein the emulation flag is a first value indicating that the received instruction is to be emulated; storing the simulation mark, the instruction pointer of the received instruction, the machine code and the operating environment information into a system management memory; and entering the system management mode.

42. A system for performing a new add instruction as recited in claim 41, wherein in the system management mode, the system for performing a new add instruction obtains the simulation flag from the system management memory; and when the simulation mark is a first value, judging whether the received instruction is a new instruction according to the machine code, wherein the first value represents that the received instruction is a to-be-simulated instruction.

43. The system of claim 41, wherein in the system management mode, when the received command is a new command, if the received command cannot be executed in the operating environment, the system executing the new command generates a decoding exception; and storing the decoding exception into the system management memory, and setting an exception identifier in the system management memory.

44. The system of claim 41, wherein the system for executing the new instruction writes the emulation flag, the instruction pointer of the received instruction, the machine code, and the runtime information into the micro-architectural register when the received instruction is an unknown instruction.

45. A system for performing a add-on as in claim 36, wherein in the system management mode, the system for performing the add-on obtains the machine code of the received instruction from a system management memory; decoding the machine code to obtain an operation code of the received instruction; and judging whether the received instruction is a new instruction or not according to the operation code.

46. A system as claimed in claim 45, wherein in the system management mode, when the received command is a new command, the system for executing the new command generates the at least one old command according to the operation code; and executing the at least one old instruction.

47. A system for performing a new add instruction as in claim 45, wherein the system for performing a new add instruction decodes the machine code to obtain other decoded information for the received instruction, wherein the other decoded information comprises a source operand and a destination operand; and executing the at least one old instruction according to the other decoded information.

48. The system of claim 45, wherein in the system management mode, when the received command is not a new command, the system of executing the new command generates an exception number of an unknown command exception; and storing the abnormal number into the system management memory, and setting an abnormal identifier in the system management memory.

49. The system of claim 36, wherein in the system management mode, the system of executing the new instruction reads the instruction pointer of the received instruction from a system management memory; reading the machine code of the received instruction from a system memory according to the instruction pointer of the received instruction; and judging whether the received instruction is a new instruction or not according to the machine code.

50. The system of claim 36, wherein when the received instruction is a new instruction, the system executing the new instruction temporarily stores a simulated execution result obtained by executing the at least one old instruction into a system management memory in the system management mode.

51. The system of claim 50, wherein when the received instruction is a new instruction, the system executing the new instruction writes the simulated execution results stored in the system management memory into an architectural register upon exiting the system management mode.

52. A system for performing a new add instruction as in claim 36, wherein when the received instruction is a new add instruction, the system for performing a new add instruction calculates a length of the received instruction; and if no exception is generated during the execution of the at least one old instruction, updating a value of an instruction pointer of the received instruction stored in the system management memory to: EIP + Length, wherein EIP is a value before the instruction pointer of the received instruction is updated, and Length is the Length.

53. A system for performing a new add instruction as recited in claim 36, wherein when the received instruction is a new add instruction, the system for performing a new add instruction calculates a length of the received instruction; and if an exception is generated during execution of the at least one old instruction and the exception is a trap, updating a value of an instruction pointer of the received instruction stored in the system management memory to: EIP + Length, where EIP is a value of the received instruction before the instruction pointer is updated, and Length is a Length of the received instruction.

54. A system for performing a add on command as in claim 36, wherein the transformation program is pre-stored in the bios.

55. The system of claim 54, wherein the system that executes the new instruction executes the BIOS; and loading the conversion program into a system management memory.

56. The system of claim 36, wherein in the system management mode, the system of executing the new instruction obtains the simulation flag from a system management memory; and executing the conversion program when the simulation mark is a first numerical value, wherein the first numerical value represents that the received instruction is an instruction to be simulated.

57. A system for performing a new add instruction as in claim 36, wherein when the received instruction is a new add instruction, the system for performing a new add instruction determines whether an exception was made during execution of the at least one old instruction; and if the abnormality is generated, storing the abnormality into a system management memory, and setting an abnormality identifier in the system management memory.

58. A system for performing a add-on instruction as recited in claim 57, wherein said exceptions include decode exceptions and run-time exceptions.

59. The system of claim 57, wherein when the received command is a new command, the system of executing the new command determines whether the exception is generated based on the exception flag stored in the system management memory; and if the judgment result is that the exception is generated, executing the microcode processing program of the exception stored in the system management memory after exiting the system management mode.

60. The system of claim 57, wherein when the received instruction is a new instruction and the exception is a trap, upon exiting the system management mode, the system of executing the new instruction restores the value stored in the architectural register using information stored in the system management memory.

61. The system of claim 36, wherein the architected register is emulated using system management memory in the system management mode when the received instruction is a new instruction and the operand of the received instruction is an architected register.

62. The system of claim 61, wherein the system for executing the newly added instruction stores the operation result of the received instruction into the system management memory when the new architectural register is the destination operand of the received instruction and after completion of the received instruction is simulated.

63. The system of claim 62, wherein the system for executing the new instruction does not store the result of the operation stored in the SMM into an architectural register when the SMM exits the SMM mode when the new architectural register is a destination operand of the received instruction.

64. The system of claim 62, wherein when the received one of the additional instructions is the additional instruction and the additional architectural register is a source operand of the additional instruction, the system for executing the additional instruction directly uses the operation result stored in the system management memory to simulate execution of the additional instruction.

65. The system of claim 36, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the system of executing the new instruction converts a virtual address of the memory operand to a physical address; and reading the value of the memory operand according to the physical address, wherein the physical address is not in a system management memory.

66. The system as claimed in claim 65, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the system for executing the new instruction converts the virtual address of the memory operand to a physical address by accessing a page table through a physical memory direct access interface.

67. A system as claimed in claim 65, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the system for executing the new instruction reads the value of the memory operand from the physical address via a model specific register.

68. The system of claim 67, wherein the system for executing the new instruction writes the address of the model-specific register to a first register when the received instruction is the new instruction and the received instruction includes a memory operand; writing the physical address into a second register; and executing a write model specific register instruction to store the value of the memory operand in the model specific register.

69. The system of claim 68, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the system executes a read model specific register instruction to read the value of the memory operand from the model specific register and store the read value of the memory operand in the second register.

70. The system of claim 68, wherein when the received instruction is a new instruction and the received instruction includes a memory operand, the system executing the new instruction loads the value of the memory operand from system memory into the model-specific register by executing a load micro instruction from a physical address after executing the write model-specific register instruction.