Method and system for executing an add instruction

Abstract

The present application provides a method and system for executing a new instruction in a processor. The method comprises receiving an instruction. When the received instruction is an unknown instruction, a conversion program is executed by an operating system. The conversion program determines whether the received instruction is a new instruction, converts the received instruction into at least one old instruction when the received instruction is a new instruction, and executes the at least one old instruction. Thus, the new instruction can be executed without changing the hardware architecture of a previous generation of processing core.

Description

Technical Field

[0001] This invention relates to the field of microelectronics, and more particularly to a method and system for executing new instructions. Background Technology

[0002] Processor technology has advanced rapidly in recent years. As processor capabilities increase, later generations often add new instructions to their predecessors. Because older processors cannot execute these new instructions, when they encounter them, an Unknown Instruction Exception (#UD) is generated, causing the operating system to terminate the process containing the new instructions. Consequently, applications or operating systems containing these new instructions cannot run on older processors.

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

[0004] The following disclosure is exemplary only and is not intended to limit in any way. In addition to the illustrative aspects, implementations, and features described, other aspects, implementations, and features will also become apparent from the accompanying drawings and the detailed description below. That is, the following disclosure is provided to introduce concepts, key points, benefits, and novel and non-obvious technical advantages described herein. Selected, and not all, embodiments will be further described in detail below. Therefore, the following disclosure is not intended to represent all essential features of the claimed subject matter, nor is it intended to determine the scope of use of the claimed subject matter.

[0005] Therefore, the main objective of this invention is to provide a method and system for executing new instructions, so as to achieve the goal of executing new instructions without changing the hardware architecture of the previous generation processing core.

[0006] This invention proposes a method for executing a newly added instruction, comprising: receiving an instruction; when the received instruction is an unknown instruction, executing a conversion program through an operating system, wherein the conversion program: determines whether the received instruction is a newly added instruction; when the received instruction is a newly added instruction, converts the received instruction into at least one old instruction; and executes the at least one old instruction.

[0007] This invention proposes a system for executing newly added instructions, comprising: an instruction decoding unit, which receives an instruction and determines whether the received instruction is an unknown instruction. When the received instruction is an unknown instruction, the system for executing the newly added instruction executes a conversion program through the operating system. The conversion program: determines whether the received instruction is a newly added instruction; and when the received instruction is a newly added instruction, converts the received instruction into at least one old instruction. The system for executing the newly added instruction then executes the at least one old instruction.

[0008] The method and system for executing new instructions provided by this invention enable the execution of new instructions on previous generation processors without modifying the hardware architecture of the processing core. Attached Figure Description

[0009] Figure 1 This is a schematic diagram showing a system for executing new instructions according to a first embodiment of the present invention.

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

[0011] Figure 3 This is a flowchart illustrating the execution of a newly added instruction according to the first embodiment of the present invention.

[0012] Figure 4 This is a flowchart illustrating the processing of received instructions according to the first embodiment of the present invention.

[0013] Figure 5 This is a flowchart showing the entry into system management mode according to the first embodiment of the present invention.

[0014] Figure 6 This is a flowchart showing the processing of the simulator according to the first embodiment of the present invention.

[0015] Figure 7 This is a flowchart showing the conversion procedure according to the first embodiment of the present invention.

[0016] Figure 8 This is an example illustrating the processing of unknown instructions in system management mode according to the first embodiment of the present invention.

[0017] Figures 9A-9B This is a flowchart illustrating the exit system management mode according to the first embodiment of the present invention.

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

[0019] Figure 11This is a structural diagram of the processor according to the second embodiment of the present invention.

[0020] Figure 12 This is a flowchart illustrating the execution of a newly added instruction according to a second embodiment of the present invention.

[0021] Figure 13 This is a flowchart illustrating the processing of receiving instructions according to the second embodiment of the present invention.

[0022] Figure 14 This is a flowchart illustrating the processing of received instructions in microcode for handling unknown instruction exceptions according to a second embodiment of the present invention.

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

[0024] Figure 16 This is a flowchart of the process of receiving instructions according to the third embodiment of the present invention.

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

[0026] Figure 18 This is a flowchart illustrating the execution of a new instruction according to an embodiment of the present invention.

[0027] Figure 19 This is a flowchart illustrating the execution of a new instruction according to an embodiment of the present invention.

[0028] Figure 20 This is a flowchart of a conversion and addition instruction according to an embodiment of the present invention.

[0029] Figure 21 This shows an exemplary operating environment for implementing embodiments of the present invention.

[0030] The symbols in the attached diagram are briefly explained as follows:

[0031] 100: System executing new instructions; 110: Processor; 112: Interrupt preprocessing unit; 114: System management mode entry / exit; 1142: System management mode entry; 1144: System management mode exit; 120: Operating system; 130: Application program; 118: Instruction; 132: Unknown instruction; 142: Emulator; 145: Translator; 200: Processor; 201: Instruction bypass translation buffer; 202: Instruction cache; 203: Branch predictor; 230: Instruction decoding unit; 204: Renaming unit; 205: Reserved station; 206: Execution unit; 207: Memory access unit; 220: Microarchitecture registers; 240 : Reorder buffer; 245: Instruction commit unit; 250: System management mode; 260: Architecture register; S305, S310, S315, S320, S325: Step; S405, S410, S415, S420, S425, S430, S435: Step; S505, S510, S515, S520, S525, S530: Step; S605, S610, S615, S620, S625, S630, S635, S640, S645: Step; S705, S710, S712, S715, S720, S725: Step; S901, S904, S9 03, S905, S907, S909, S911, S913, S915, S917, S919, S921, S923, S925, S927, S929, S933: Steps; 1000: System executing the new instruction; 1100: Processor; 1110: Transformer; S1205, S1210, S1215, S1220, S1225: Steps; S1305, S1310, S1315, S1320, S1325: Steps; S1405, S1410, S1415, S1420, S1425: Steps; 1500: System executing the new instruction; 150: Kernel driver 1600: Flowchart; S1605, S1610, S1620, S1625: Steps; 1700: System executing new instructions; 190: Dedicated processing core; S1805, S1810, S1815, S1820, S1825: Steps; S1905, S1910, S1915, S1920, S1925: Steps; S2005, S2010, S2015: Steps; 2100: Computing device; 2110: Bus; 2112: Memory; 2114: Processor; 2116: Display element; 2118: I / O port; 2120: I / O element; 2122: Power supply. Detailed Implementation

[0032] The various aspects of the invention will be described more fully below with reference to the accompanying drawings. However, the invention can be embodied in many different forms and should not be construed as being limited to any particular structure or function presented throughout the invention. Rather, these aspects are provided to make the invention comprehensive and complete, and to provide those skilled in the art with a full understanding of its scope. Based on the teachings herein, those skilled in the art will recognize that the scope of the invention is intended to cover any aspect disclosed herein, whether implemented alone or in combination with any other aspect of the invention. For example, it can be implemented using any number of the means or methods presented herein. Furthermore, in addition to the various aspects of the invention presented herein, the scope of the invention is more intended to cover means or methods implemented using other structures, functions, or structures and functions. It should be understood that any aspect disclosed herein can be embodied by one or more elements of the claims.

[0033] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect of the invention or a design described herein as “exemplary” is not necessarily to be construed as preferred or superior to other aspects of the invention or design. Furthermore, the same numerals indicate the same elements in all the figures, and unless otherwise specified in the description, the articles “a” and “above” include multiple references.

[0034] It is understood that when an element is described as being “connected” or “coupled” to another element, the element may be directly connected to or coupled to the other element, or there may be intermediate elements. Conversely, when an element is described as being “directly connected” or “directly coupled” to another element, there are no intermediate elements. Other terms used to describe the relationship between elements should be interpreted in a similar manner (e.g., “between” vs. “directly between”, “adjacent” vs. “directly adjacent”, etc.).

[0035] To better describe the embodiments of the present invention, the specific terms used in the present invention will be defined below.

[0036] Old instructions: Instructions that were natively supported by previous generation processors are called native instructions, also known as existing instructions or old instructions.

[0037] Unknown instructions: Instructions not natively supported by previous generation processors.

[0038] New instructions: Instructions added to the support of the new generation of processors compared to their predecessors. These new instructions are not recognized by the previous generation of processors and are therefore unknown to them.

[0039] New architecture registers: These are the new architecture registers supported by the later generation of processors compared to their predecessors. These new architecture registers did not exist in the previous generation of processors; therefore, when simulating the execution of new instructions using these new architecture registers on a previous generation processor, it is necessary to simulate the new architecture registers.

[0040] Unrecognized instructions: These are the remaining instructions after excluding newly added instructions. In other words, unrecognized instructions are those not natively supported by later processors.

[0041] Model-specific registers: A type of register in a processor that can be used to perform specific functions.

[0042] Traps: Traps are generally caused by software interrupt instructions (such as the INT instruction). When an instruction causes a trap exception, it does not mean that the instruction itself has an error. Therefore, after an instruction encounters a trap exception, the processor will continue executing the next instruction. For example, when software developers debug software code, they can set breakpoints in the code. When the code with breakpoints is executed on the processor, a trap will be generated when the breakpoint is reached, causing the code to pause execution at the breakpoint. Software developers can use the microcode handler for traps to view the values ​​of various architecture registers or variables in the code when the code reaches the breakpoint. Based on these values, they can determine whether the code executed correctly when the breakpoint was reached.

[0043] The processor described in this invention can be a processor capable of Reduced Instruction Set Computing (RISC, such as ARM / MIPS / RISC-V instruction sets), Complex Instruction Set Computing (CISC, such as x86 instruction set), or other instruction set types; or a processor capable of simultaneously supporting multiple different instruction set architectures (e.g., a processor that simultaneously supports x86 and ARM instruction sets). This invention does not specifically limit the instruction set types supported by the processor, but for ease of explanation, the embodiments described herein use processors supporting the x86 instruction set. Furthermore, as those skilled in the art will know, x86 processors interpret macro instructions into at least one microinstruction or microinstruction sequence according to the original program order, but the microinstructions are executed out of order to improve execution efficiency; however, the retire process after the microinstruction execution is completed still follows the original program order.

[0044] This invention has multiple implementations, and the following four embodiments describe four main implementations of the invention. The first embodiment is an implementation of simulating the execution of a new instruction in system management mode. The second embodiment is an implementation of simulating the execution of a new instruction in the same execution mode as the new instruction. The third and fourth embodiments are implementations of simulating the execution of a new instruction through an operating system, wherein the fourth embodiment uses a dedicated processing core to complete the conversion operation of the new instruction. The first embodiment will be described first.

[0045] [First Embodiment]

[0046] Figure 1 This is a schematic diagram showing a system for executing newly added instructions according to the first embodiment of the invention. (See diagram below.) Figure 1 As shown, the system 100 executing the new instructions includes a processor 110, an operating system 120, an application program 130, and an emulator 142. The operating system 120 runs on the processor 110 and manages it. The application program 130 runs on the operating system 120 and can use various functions provided by the processor 110 and other hardware (not shown, such as hard drives, network cards, etc.) through the operating system 120. The emulator 142 runs on the processor 110 in System Management Mode (SMM). Neither the operating system 120 nor the application program 130 is aware of the execution process of the emulator 142. That is, all operations performed by the emulator 142 are transparent to the operating system 120 or the application program 130.

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

[0048] like Figure 1As shown, the processor 110 includes an interrupt preprocessing unit 112 and a system management mode entry / exit 114. The system management mode entry / exit 114 includes a system management mode entry 1142 and a system management mode exit 1144. Figure 1 Solid arrows with numerical designations indicate the direction of instruction information transmission, while dashed arrows with numerical designations indicate the direction of instruction simulation execution results transmission. The following describes the entire process of processor 110 processing the unknown instruction 132.

[0049] First, processor 110 receives instruction 118 from application program 130 to perform a specified function (as shown by solid arrow 1). After receiving instruction 118, processor 110 determines whether instruction 118 is an unknown instruction 132. If instruction 118 is an unknown instruction 132, processor 110 issues an unknown instruction exception (#UD). In response to the unknown instruction exception, interrupt preprocessing unit 112 executes the microcode handler for the unknown instruction exception. In the microcode handler for the unknown instruction exception, interrupt preprocessing unit 112 sets an Emulation Flag (EF) and issues a system management interrupt (#SMI), while simultaneously sending the instruction information of the unknown instruction 132 to system management mode entry / exit 114 (as shown by solid arrow 2). How to issue the unknown instruction exception and system management interrupt is common knowledge to those skilled in the art and will not be described in detail here. In one embodiment, processor 110 is a processor supporting the x86 instruction set, and interrupt preprocessing unit 112 is a microcode control unit. In practice, those skilled in the art can modify the microcode handling program for unknown instruction exceptions stored in the interrupt preprocessing unit 112 to add functions such as setting a simulation flag, obtaining instruction information for unknown instructions, and issuing system management interrupts. Since these microcodes vary depending on the processor version, those skilled in the art can write corresponding microcodes according to the actual situation.

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

[0051] Figure 2 This is a structural diagram showing the processor according to the first embodiment of the present invention. Figure 2 As shown, processor 200, located to the left of the dashed line, is... Figure 1 The schematic diagram of processor 110 shown shows that simulator 142 and conversion program 145, located to the right of the dashed line, run on processor 200 in system management mode. In one embodiment, the function performed by conversion program 145 is implemented in a conversion module; alternatively, conversion program 145 can be considered as a conversion module in system 100 that executes new instructions. The following is in conjunction with... Figure 1 right Figure 2 Please provide an explanation.

[0052] like Figure 2 As shown, processor 200 includes an Instruction Translation Lookaside Buffer (ITLB) 201, an Instruction Cache 202, and a branch predictor 203. When processor 200 executes an instruction from application program 130 or operating system 120, the ITLB 201 receives the instruction. The branch predictor 203 predicts conditional branches and passes the branch prediction result to the instruction cache 202. The instruction cache 202 retrieves the received instruction from the ITLB 201 based on the branch prediction result, and then processor 200 performs further processing on the received instruction.

[0053] like Figure 2As shown, the processor 200 further includes an instruction decoding unit 230. The instruction decoding unit 230 determines whether the received instruction is an unknown instruction, and then generates at least one microinstruction, wherein the microinstruction includes an unknown instruction identifier to indicate whether the received instruction is an unknown instruction. When the unknown instruction identifier is a first value, it indicates that the received instruction is an unknown instruction. When the unknown instruction identifier is a second value, it indicates that the received instruction is an old instruction. In one embodiment, the first value is 1, and the second value is 0.

[0054] The processor 200 also includes a renaming unit 204, a reservation station 205, an execution unit 206, a memory access unit 207, a rearrangement buffer 240, an interrupt preprocessing unit 112, and an architecture register 260. The renaming unit 204 receives microinstructions from the instruction decoding unit 230 and renames them, wherein the microinstructions contain an unknown instruction identifier (UD). Then, the renaming unit 204 sends the renamed microinstructions to the reservation station 205 and the rearrangement buffer 240. The reservation station 205, depending on the type of the microinstruction, sends it to the execution unit 206 or the memory access unit 207 for further processing. The rearrangement buffer 240 receives the microinstructions and stores them in an instruction entry. The rearrangement buffer 240 contains multiple instruction entries, each containing an unknown instruction identifier field to store the unknown instruction identifier in the microinstruction.

[0055] The rearrangement buffer 240 contains an instruction submission unit 245. When the aforementioned microinstruction meets the retirement condition, the instruction submission unit 245 submits the microinstruction. When submitting the microinstruction, if no exception occurs during execution, the instruction submission unit 245 updates the architecture register 260 based on the execution result. If an exception occurs during execution, the instruction submission unit 245 reports the exception. In response to the exception, the processor 200 executes the exception's microcode handler.

[0056] When the instruction submission unit 245 submits the aforementioned microinstruction, if the unknown instruction identifier of the microinstruction is a first value, the instruction submission unit 245 will issue an unknown instruction exception (#UD). In response to the unknown instruction exception, the processor 200 executes the microcode handler for the unknown instruction exception. In the microcode handler for the unknown instruction exception, the processor 200 stores an analog identifier with a value of the first value into the microarchitecture register 220 and issues a system management interrupt (#SMI). In response to the system management interrupt, the processor 200 will, as follows: Figure 1The system management mode entry 1142 shown enters the system management mode based on the simulation identifier stored in the microarchitecture register 220. In system management mode, the processor 200 processes the received instruction via the simulator 142. First, the simulator 142 determines whether the received instruction is a new instruction. If the received instruction is a new instruction, the simulator 142 will simulate the execution of the received instruction. During the simulated execution of the received instruction, the simulator 142 can store intermediate calculation results into the system management memory (SMRAM). It should be noted that when the simulation identifier is the first value, it indicates that the simulator 142 needs to process the received instruction; when the simulation identifier is the second value, it indicates that the simulator 142 does not need to process the received instruction.

[0057] After the simulator 142 processes the above-mentioned receive instruction, the processor 200 executes the following... Figure 1 The system management mode exit 1144 exits system management mode. System management mode exit 1144 sets the emulation flag stored in microarchitecture register 220 to the second value, and then exits system management mode. When processor 200 executes another instruction, and that instruction is unknown, processor 200, while executing the microcode handler for the unknown instruction exception, will again set the emulation flag stored in microarchitecture register 220 to the first value. Then, processor 200 processes the other instruction according to the aforementioned processing procedure.

[0058] Figure 3 This is a flowchart illustrating the execution of a newly added instruction according to the first embodiment of the present invention. Please also refer to... Figure 2 and Figure 3 ,like Figure 3 As shown, the instruction decoding unit 230 receives an instruction (S305). When the received instruction is an unknown instruction, the instruction submission unit 245 issues an unknown instruction exception (S310). 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 program (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). A detailed explanation follows: The instruction decoding unit 230 first executes step S305.

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

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

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

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

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

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

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

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

[0067] When the received instruction is an old instruction ("No" in step S410), step S435 is executed. In step S435, the processor 200 processes the received instruction normally. How the received instruction is processed normally, such as converting the old instruction into its corresponding microinstruction and executing the corresponding microinstruction, is common knowledge to those skilled in the art and will not be elaborated here. When the received instruction is an unknown instruction ("Yes" in step S410), step S415 is executed.

[0068] In step S415, the processor 200 writes an emulation identifier into a microarchitecture register 220. Specifically, when the received instruction is an unknown instruction, the instruction decoding unit 230 generates a microinstruction whose unknown instruction identifier is a first value. In one embodiment, the microinstruction is a no-operation microinstruction (NOP). The instruction decoding unit 230 sends the microinstruction to the renaming unit 204. The renaming unit 204 renames the microinstruction. Then, the renaming unit 204 sends the microinstruction to the rearrangement buffer 240. The rearrangement buffer 240 stores the microinstruction in its instruction entry. When the microinstruction is submitted, since the unknown instruction identifier of the microinstruction is the first value, the instruction submission unit 245 issues an unknown instruction exception. In response to the unknown instruction exception, the processor 200 executes the microcode handler for the unknown instruction exception. In the microcode handler for the unknown instruction exception, the processor 200 writes an emulation identifier into the microarchitecture register 220. In addition, the processor 200 stores the information of the received instruction and the runtime environment information of the received instruction in the microarchitecture register 220. Then, in the microcode handler for the unknown instruction exception, the processor 200 issues a system management interrupt (#SMI). In one embodiment, the information of the received instruction includes the instruction pointer of the received instruction. In another embodiment, the information of the received instruction includes the instruction pointer of the received instruction and the machine code of the received instruction. The runtime environment information includes the runtime mode of the received instruction (i.e., the runtime mode of the processor 200 when the processor 200 executes the received instruction). For example, the runtime mode includes read mode, protected mode, v8086 mode, compatibility mode, and long mode, etc. Then, the processor 200 executes step S420.

[0069] In step S420, the processor 200 enters system management mode. Specifically, in response to the aforementioned system management interrupt, the processor 200 executes, as follows: Figure 1The system management mode entry point 1142 shown indicates entry into system management mode. Details regarding processor 200 entering system management mode will be discussed later. Figure 5 The details are then provided. Next, processor 200 executes step S425.

[0070] In step S425, the processor 200 processes the aforementioned receive instruction. How the processor 200 processes the aforementioned receive instruction will be explained later in conjunction with... Figures 6-8 A detailed description is then provided. Next, the processor 200 executes step S430.

[0071] In step S430, the processor 200 exits the system management mode and ends the process. Specifically, the processor 200 executes the following... Figure 1 The system management mode exit 1144 shown indicates exiting system management mode. How processor 200 exits system management mode will be discussed later. Figures 9A-9B Provide a detailed description.

[0072] Figure 5 This is a flowchart showing the entry into system management mode according to the first embodiment of the present invention. Figure 5 To and Figure 1 The processing flow of the microcode processing program corresponding to system management mode entry 1142 is shown below. Please refer to... Figure 2 and Figure 5 ,like Figure 5 As shown, processor 200 disables interrupts (S505) and determines whether the simulation flag is the first value (S510). If the result of step S510 is "yes", then it enters system management mode. Detailed explanation follows: Processor 200 first executes step S505.

[0073] In step S505, processor 200 disables interrupts. As is known to those skilled in the art, interrupts are disabled in system management mode; therefore, this invention continues this architectural requirement by disabling interrupts. As for 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, processor 200 executes step S510.

[0074] Next, in step S510, the processor 200 determines whether the aforementioned analog identifier is the first value. Specifically, the processor 200 determines whether the analog identifier stored in the microarchitecture register 220 is the first value. If the determination result is "no", step S530 is executed to perform the normal processing flow for entering system management mode. Those skilled in the art will understand the normal processing flow of system management mode, and it will not be described in detail here. If the determination result is "yes", the processor 200 executes step S515.

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

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

[0077] Table 1

[0078]

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

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

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

[0082] Figure 6 This is a flowchart illustrating the processing of the simulator according to the first embodiment of the present invention. As previously described, the processor 200 processes the received instructions via the simulator 142 in system management mode. Please refer to... Figure 2 and Figure 6 ,like Figure 6 As shown, in system management mode, simulator 142 establishes a simulation running environment (S605), and then determines whether the simulation identifier is the first value (S610). If the determination result of step S610 is "yes", simulator 142 converts the above received instruction through a conversion program and generates a conversion result (S615). Then, simulator 142 processes the above conversion result. A detailed explanation is as follows: First, simulator 142 executes step S605.

[0083] In step S605, simulator 142 establishes a simulated runtime environment. Specifically, simulator 142 reads the simulation identifier, receive instruction information, receive instruction runtime environment information, and architecture register information from system management memory. In subsequent steps, the information read above will be used to simulate the execution of the receive instruction. Then, simulator 142 executes step S610.

[0084] In step S610, simulator 142 determines whether the simulation identifier is the first value. Specifically, simulator 142 determines whether the simulation identifier read in step S605 is the first value. If the determination result is "no", simulator 142 executes step S645. In step S645, simulator 142 executes the normal processing flow of system management mode. The normal processing flow of system management mode is common knowledge to those skilled in the art and will not be described in detail here. If the determination result of step S610 is "yes", simulator 142 executes step S615.

[0085] In step S615, the simulator 142 converts the received instruction using the conversion program 145 and generates a conversion result. The structure of the conversion result is shown in Table 2 below, containing two fields: result and content. When the result field is the first value, it indicates successful conversion. In this case, the content field contains at least one old instruction converted from the received instruction and the length of the received instruction. When the result field is the second value, it indicates conversion failure. In this case, the content field contains an error number. How the received instruction is converted using the conversion program 145 will be discussed later. Figure 7 Detailed explanation.

[0086] Table 2

[0087] result content … …

[0088] In step S620, the simulator 142 determines whether the above conversion program has been successfully converted. Specifically, the simulator 142 determines whether the above conversion program has been successfully converted based on the 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 executes step S625; when the result field of the conversion result is the second value, the determination result is "no", and the simulator 142 generates a simulation execution result based on the conversion result, and then executes step S630. The structure of the simulation execution result is shown in Table 3 below, containing two fields: result and details. When the result field of the simulation execution result is the first value, it indicates that the simulation execution was successful, and the details field stores the calculation result obtained after the simulation execution; when the result field of the simulation execution result is the second value, it indicates that the simulation execution failed, and the details field stores the exception number. When the result field of the simulation execution result is the second value, the simulation execution result generated based on the conversion result is shown in Table 3-1 below. The exception number in the details field of Table 3-1 is the exception number in the content field of the conversion result.

[0089] Table 3

[0090] result Details … …

[0091] Table 3-1

[0092] result Details Second value Error number

[0093] Furthermore, when the judgment result of step S620 is that the conversion is successful (i.e., the judgment result of step S620 is "yes"), the simulator 142 executes step S625. In step S625, the simulator 142 obtains at least one old instruction from the above conversion result and executes the at least one old instruction. Specifically, the simulator 142 obtains the at least one old instruction and the length of the received instruction from the content field of the above conversion result. Then, the simulator 142 causes the processor 200 to execute the at least one old instruction through a call instruction or a jump instruction. The processor 200 decodes the at least one old instruction into at least one microinstruction and executes the at least one microinstruction, generating a simulated execution result. If a runtime exception occurs during the execution of the at least one microinstruction by the processor 200, the content field of the simulated execution result is shown in Table 3-2 below. In Table 3-2, the result field of the simulated execution result is the second value, indicating that the simulated execution failed; the details field of the simulated execution result is the exception number, i.e., the runtime exception number. If the processor 200 successfully executes the at least one microinstruction, the content field of the simulated execution result is shown in Table 3-3 below. In Table 3-3, the first value in the simulation execution result indicates that the simulation was successful; the details field of the simulation execution result is the calculation result.

[0094] Table 3-2

[0095] result Details Second value Error number

[0096] Table 3-3

[0097] result Details First value Calculation result

[0098] In one embodiment, when the operand of the received instruction includes a new architecture register, the new architecture register is simulated using system management memory. For example, when a descendant processor of processor 200 includes a new architecture register with a bit width of 1024 bits, simulator 142 can use a contiguous 1024-bit storage space in system management memory to simulate the new architecture register. That is, when the received instruction accesses the new architecture register, simulator 142 actually accesses the contiguous 1024-bit storage space in system management memory.

[0099] When the newly added architecture register is the destination operand of the received instruction, after executing at least one of the old instructions, the processor 200 stores the result of the received instruction in the system-managed memory. Thus, when the processor 200 executes another instruction, which is also a new instruction, and the newly added architecture register is the source operand of that other instruction, the processor 200 directly uses the result stored in the system-managed memory when simulating the execution of that other instruction. It should be noted that the received instruction and the other instruction can be consecutive (i.e., adjacent) or not consecutive; this invention does not impose any limitations on this.

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

[0101] The first step is for simulator 142 to translate the virtual addresses of the aforementioned memory operands into physical addresses. Specifically, simulator 142 uses the physical memory direct access interface to access the page table and translate the virtual addresses of the memory operands into physical addresses. The steps for translating virtual addresses into physical addresses are as follows: 1. Read the page table base address stored in the architecture register CR3 from the system management memory; 2. Perform a page table lookup based on the page table base address and the virtual address, simulating the page table lookup process to obtain the physical address.

[0102] The second step involves emulator 142 reading the value of the memory operand from the physical address via the direct physical memory access interface (DMI). This physical address is not located in system-managed memory. Specifically, emulator 142 uses a Model Specific Register (MSR) via the DMI to read the value of the memory operand from the physical address. The specific steps are as follows:

[0103] Step 1: Simulator 142 writes the address of the above-mentioned model special register into a first register (ECX) and writes the above-mentioned physical address into a second register (EDX:EAX).

[0104] Step 2: The simulator 142 executes a Write Model Special Register (WRMSR) instruction to store the value of the aforementioned memory operand into the aforementioned model special register. Specifically, after the simulator 142 executes the Write Model Special Register instruction, the aforementioned physical address is written into the aforementioned model special register. Then, the processor 1100 uses the aforementioned physical address stored in the aforementioned model special register to load the value of the aforementioned memory operand from system memory into the aforementioned model special register by executing a Load from Physical Address microinstruction (ld_phys).

[0105] Step 3: The simulator 142 executes the Read Model Special Register (RDMSR) instruction to read the value of the memory operand from the aforementioned model special register and stores the read value of the memory operand into the aforementioned second register.

[0106] In one embodiment, the next instruction after the aforementioned receive instruction is the aforementioned other instruction. The last instruction in the aforementioned at least one prior instruction is a jump instruction or a call instruction, and the processor 1100 jumps to the aforementioned other instruction via the aforementioned jump instruction or the aforementioned call instruction. The instruction pointer of the aforementioned other instruction is: EIP + Length, where EIP is the instruction pointer of the aforementioned receive instruction, and Length is the length of the aforementioned receive instruction.

[0107] Then, simulator 142 executes step S630. In step S630, simulator 142 writes the simulation execution result to system management memory. Specifically, simulator 142 writes the simulation execution result generated in step S625 or step S620 to system management memory. As mentioned above, there are two possible simulation execution results: successful simulation and failed simulation. System management memory contains an exception vector table, the structure of which is shown in Table 4 below. The exception vector table contains two fields: exception identifier and exception number. When storing the simulation execution result into system management memory, the exception vector table in system management memory needs to be filled. The process of simulator 142 storing the simulation execution results of these two cases into system management memory is described below.

[0108] Table 4

[0109] Anomaly indicator Error number … …

[0110] When the simulation executes successfully, the simulator 142 sets the exception identifier field of the exception vector table in the system management memory to the first value (as shown in Table 4-1 below), and stores the calculation result stored in the details field of the simulation execution result into the system management memory. For example, if the above calculation result is that the value of the architecture register ECX changes to 10H (i.e., the hexadecimal number 10, the same below), then the simulator 142 needs to write 10H into the storage space corresponding to the architecture register ECX in the system management memory. If the calculation result is that the value of the newly added architecture register changes to 20H, then the simulator 142 needs to write 20H into the storage space used to simulate the newly added architecture register in the system management memory. The simulator 142 also updates the value of the instruction pointer of the above received instruction stored in the system management memory to: EIP + Length, so that the instruction pointer of the processor 200 points to the next instruction to be executed, where EIP is the value of the instruction pointer before the update, and Length is the length of the above received instruction. The instruction pointer of the above received instruction in the system management memory is the storage space corresponding to the architecture register EIP. When exiting system management mode, the value in the storage space corresponding to the architecture register in system management memory will be written into the corresponding architecture register 260 to send the simulated execution result of the newly added instruction to the application 130 or the operating system 120, which will be described in detail later.

[0111] Table 4-1

[0112] Anomaly indicator Error number First value …

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

[0114] Table 4-2

[0115] Anomaly indicator Error number Second value Error number

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

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

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

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

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

[0121] The third scenario: When the information of the above-mentioned receiving instruction contains the instruction pointer of the above-mentioned receiving instruction and the machine code of the above-mentioned receiving instruction, the conversion program 145 directly decodes the machine code in the information of the above-mentioned receiving instruction.

[0122] The following describes the execution of conversion program 145 in the first scenario. Figure 7 The processing flow is as follows. The conversion program 145 first executes step S705.

[0123] In step S705, the conversion program 145 obtains the opcode of the aforementioned receiving instruction. Specifically, the conversion program 145 obtains the opcode of the aforementioned receiving instruction based on the information of the aforementioned receiving instruction. As described above ( Figure 6 In step S605, the information of the received instruction is read from the system management memory by the emulator 142. The received instruction information only contains the instruction pointer of the received instruction, and the conversion program 145 obtains the opcode of the received instruction based on the instruction pointer. Specifically, the conversion program 145 first reads the first byte of the machine code of the received instruction from memory (i.e., system memory) based on the instruction pointer, and then determines the opcode of the received instruction based on the read byte (i.e., the first byte). If the opcode of the received instruction cannot be determined based on the first byte of the machine code, the second byte of the machine code is read, and the opcode of the received instruction is determined based on the read byte (i.e., the first two bytes). This process continues until the opcode of the received instruction is determined. It is worth noting that if the received instruction contains a prefix and / or escape code, the conversion program 145 will first obtain the prefix and / or escape code of the received instruction, and then obtain its opcode. In one embodiment, the conversion program 145 reads machine code from memory according to the instruction pointer of the received instruction via the physical memory direct access interface as described above. After obtaining the opcode of the received instruction, the conversion program 145 executes step S710.

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

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

[0126] Table 2-1

[0127] result content Second value #UD

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

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

[0130] When the conversion program 145 determines that there is a decoding error in the received instruction (the judgment result of step S712 is "yes"), step S725 is executed to generate the conversion result shown in Table 2-2 below. As shown in Table 2-2 below, the result field value of the conversion result is the second value, indicating that the conversion failed; the content field of the conversion result is the error number #UD (value 6) of the unknown instruction error.

[0131] Table 2-2

[0132] result content Second value #UD

[0133] When the conversion program 145 determines that there is no decoding error in the received instruction (the determination result of step S712 is "No"), step S715 is executed. In step S715, the conversion program 145 obtains other decoding information of the received instruction. Specifically, the conversion program 145 continues to read the machine code of the received instruction byte by byte from memory, decoding as it reads, until the other decoding information of the received instruction is decoded, and calculates the length of the received instruction. The other decoding information includes the operand mode (ModR / M), source operand, and destination operand, etc. As those skilled in the art know, the length of the received instruction can only be calculated after the decoding of the received instruction is completed. Then, the conversion program 145 executes step S720.

[0134] In step S720, the conversion program 145 converts the received instruction into at least one old instruction. Specifically, the conversion program 145 can convert the received instruction into at least one old instruction by looking up a table. For example, at least one old instruction corresponding to the received instruction can be stored in a lookup table first. Then, the conversion program 145 retrieves the at least one old instruction from the lookup table according to the opcode 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 opcode of the received instruction. In another embodiment, the conversion program 145 retrieves the at least one old instruction from the lookup table according to the escape code, opcode, and operand pattern of the received instruction.

[0135] It is worth noting that since the at least one old instruction obtained from the lookup table does not contain other decoding information such as the source operands and / or destination operands of the received instruction, it is necessary to write other decoding information into the at least one old instruction so that it can simulate the execution of the received instruction. For example, the conversion program 145 writes the specific values ​​of the source operands and / or destination operands of the received instruction into the corresponding positions in the at least one old instruction. Then, the processor 200 can simulate the execution of the new instruction by executing the at least one old instruction. In one embodiment, the conversion program 145 writes other decoding information into the at least one old instruction based on the prefix of the received instruction.

[0136] In one embodiment, the lookup table is stored in the Basic Input / Output System (BIOS). As those skilled in the art will know, the BIOS is executed when the system 100, which executes new instructions, boots up. The BIOS contains code that initializes the system management mode. When the system 100 executes the code that initializes the system management mode, it loads the lookup table into system management memory. Then, the conversion program 145 can retrieve 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 read-only memory. Therefore, in both embodiments, the conversion program 145 converts the received instruction into at least one old instruction using a hardware-supported lookup table.

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

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

[0139] Table 2-3

[0140] result content First value Receive instruction length and at least one old instruction

[0141] The following describes the execution of conversion program 145 in the second scenario. Figure 7The processing flow is as follows. In the second scenario, the conversion program 145 executes steps S710, S712, S720, and S725 in the same manner as in the first scenario, and will not be repeated here. Steps S705 and S715 are described below.

[0142] Unlike the first scenario, in the second scenario, in step S705, the conversion program 145 first reads the complete machine code of the received instruction from memory according to the instruction pointer of the received instruction, and then decodes the read machine code to obtain the opcode of the received instruction. Furthermore, in step S715, the conversion program 145 also decodes the machine code read in step S705 to obtain other decoded information of the received instruction. The other processes in the second scenario are the same as in the first scenario, and will not be described in detail here.

[0143] It is worth noting that when the conversion program 145 reads the machine code based on the instruction pointer of the received instruction, since the length of the received instruction is not yet known, it needs to read a sufficiently long amount of the machine code. For example, if the longest new instruction that the processor 200 can process is 15 bytes, then in step S705, it is necessary to read at least 15 bytes of the machine code.

[0144] The following describes the execution of conversion program 145 in the third scenario. Figure 7 The processing flow is as follows. In the third case, the conversion program 145 executes steps S710, S712, S715, S720, and S725 in the same way as in the second case, and will not be described again here. Step S705 is described below.

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

[0146] Figure 8 This is an example illustrating the processing of unknown instructions in system management mode according to the first embodiment of the present invention. Figure 8 It demonstrates how to implement something using pseudocode. Figure 6 and Figure 7 The processing flow for handling unknown instructions shown is a specific implementation of the simulator.

[0147] like Figure 8As shown, lines 1-25 contain the code for the simulator's main function, `simulator_start`. Lines 27-36 contain the code for the decoding function, `check_decode_excep`. Lines 38-47 contain the code for the simulation function, `Unsupport_X_handle`, which implements the addition of new instructions, including at least one old instruction corresponding to the received instruction mentioned earlier. The main function, `simulator_start`, will be described first.

[0148] In the main function `simulator_start`, line 3 of the code is executed first. Line 3 completes. Figure 6 Step S605 functions to establish a simulated runtime environment for the processor 200. In line 3, the processor 200 uses the function `setup_simulator_env` to establish the simulated runtime environment. After executing line 3, the processor 200 saves the simulation flag, instruction receiving information, instruction receiving runtime environment information, and architecture register information read from system management memory into the variable `env`. For example, in line 4, the value of the simulation flag is accessed through `env.emulation_flag`. Line 4 completes... Figure 6 Step S610's function is for the processor 200 to determine whether the analog identifier is the first value. If the result of the determination in line 4 is that the analog identifier is not the first value, then line 5 is executed. Line 5 completes. Figure 6 Step S645 functions as follows: the processor 200 executes the normal processing flow of system management mode. In line 5, the processor 200 executes the normal processing flow to enter system management mode through the function `exit_to_normal_SMM`. If the judgment result of line 4 is that the simulation identifier is the first value, then line 8 is executed, defining the variable `inst_emu` as the output parameter of the decoding function `check_decode_excep` in line 9 (described later). Then line 9 is executed.

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

[0150] Line 16 of code completed. Figure 6Step S625 involves processor 200 executing at least one legacy instruction. When executing the routine, processor 200 actually executes the simulated function `Unsupport_X_handle` (described in detail later). After executing the routine, it returns a value `runtime_excep`. Then, the code in lines 18-19 is executed. Lines 18-19 are then complete. Figure 6 The function of step S630 is for processor 200 to determine if a runtime exception exists. If a runtime exception exists, processor 200 writes the simulated execution result of the runtime exception to system management memory. In line 18, processor 200 determines if a runtime exception exists based on the return value of runtime_exception. If a runtime exception exists, it executes line 19. In line 19, processor 200 uses the function set_exception to store the simulated execution result of the runtime exception into system management memory. Then, processor 200 executes line 20, jumping to line 23 using the goto instruction. As mentioned earlier, processor 200 will then execute line 24. The function of line 24 has been described previously and will not be repeated here.

[0151] The following describes the decoding function check_decode_excep.

[0152] In the decoding function check_decode_excep, lines 29-30 are executed first to obtain the opcode of the aforementioned receive instruction. Figure 7 Step S705). In line 29, processor 200 reads the machine code `machine_code` of the aforementioned receive instruction using the function `read_instruction`. Here, the machine code `machine_code` of length `code_len` bytes is read from memory based on the instruction pointer `ip` of the aforementioned receive instruction (i.e., the one explained earlier). Figure 7 In the second scenario mentioned earlier, the value of code_len can be 15. In line 30, processor 200 decodes the machine code machine_code using the function decode_opcode to obtain the opcode of the received instruction. In line 31, processor 200 uses the function is_emulate_op to determine whether the received instruction is a new instruction based on the opcode. Figure 7Step S710). If the above receive instruction is not a new instruction, the processor 200 executes the code on line 32, returning decoding exception information to the main function simulator_start via a return instruction. If the above receive instruction is a new instruction, the processor 200 first executes the code on line 33, storing the above opcode into the output parameter inst_emu; then executes the code on line 34 to obtain other decoding information of the above receive instruction (…). Figure 7 In step S715, the processor 200 executes the code on line 35 and stores the obtained decoding information into the output parameter inst_emu. Finally, the processor 200 executes the code on line 35 and returns the decoding success information to the main function simulator_start via the return instruction. The main function simulator_start can obtain the opcode of the above received instruction and other decoding information operands through the output parameter inst_emu.

[0153] The following describes the simulation function Unsupport_X_handle.

[0154] In the simulated function `Unsupport_X_handle`, lines 40-41 are executed first. Lines 40-41 read the operand's value, storing it in the array `op`. In line 41, the processor uses the function `read_op` to read the operand. Specifically, `read_op` retrieves the operand's value from the previously mentioned `env` variable. Line 42 then completes... Figure 6The function of step S625 is that processor 200 executes at least one old instruction, that is, processor 200 simulates the execution of the aforementioned receive instruction. In line 42, op represents the operand of the aforementioned receive instruction, and operate with op means that the value of the operand of the aforementioned receive instruction is written to the aforementioned at least one old instruction, and the aforementioned at least one old instruction is executed. Then, line 43 is executed. Line 43 completes the function of step S630 in Figure 6, whereby processor 200 writes the simulated execution result (including the simulated execution result that generated a runtime exception and the simulated execution result that did not generate a runtime exception) into system management memory. More specifically, in line 43, processor 200 stores the simulated execution result into system management memory through the function write_result_to_SMRAM. Line 44 determines whether a runtime exception occurred when line 42 was executed. If a runtime exception occurred, line 45 is executed, and the exception information is sent to the main function; otherwise, line 46 is executed, and the execution success information is sent to the main function. In lines 45 and 46, processor 200 sends exception information or correct execution information to the main function simulator_start via the return instruction.

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

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

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

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

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

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

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

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

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

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

[0165] Table 4-2

[0166] Anomaly indicator Error number First value 3

[0167] Table 4-3

[0168] Anomaly indicator Error number First value 0

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

[0170] In step S923, the processor 200 executes the microcode handling program for the exception. Specifically, the processor 200 determines whether an exception has occurred based on the exception identifier in the exception vector table stored in the system management memory. If an exception has occurred, the processor 200 executes the microcode handling program for the exception based on the exception number stored in the exception vector table. That is, it executes the microcode handling program for the exception corresponding to the exception number. For example, when the exception identifier in the exception vector table stored in the system management memory is the 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, it indicates that the exception is a division error, and the processor 200 will execute the microcode handling program for the division error.

[0171] In step S915, when the judgment result is "yes", that is, when the exception type of the simulated execution result is a trap, the processor 200 executes... Figure 9B The steps S925, S927, S929, and S933 are shown. Steps S925, S927, and S929 are the same as steps S907, S909, and S911, respectively, and will not be repeated here. Step S933 is described below.

[0172] In step S933, the processor 200 executes the microcode handler for the exception. For example, when an exception occurs in the simulation execution result, and the exception is an overflow exception, the processor 200 executes the microcode handler for the overflow exception. Figure 9A , 9B In the actual operation of exiting system management mode via system management interrupt exit 1144, those skilled in the art can add some microcode to the microcode corresponding to exiting system management mode after calling the instruction to resume from system management mode (RSM). This microcode stores the simulation execution results from system management memory into architecture registers, so as to pass the simulation execution results to application program 130 or operating system 120. Since these microcodes will vary depending on the processor version, those skilled in the art can write the corresponding microcode according to the actual situation.

[0173] It is worth noting that in the first embodiment, the microarchitecture register 220 is a register that already exists in the processor 200. Therefore, in the first embodiment of the present invention, new instructions can be executed on a previous generation processor without modifying the processor's hardware structure. Thus, in the first embodiment of the present invention, the ability to execute new instructions can be acquired by upgrading the microcode in an already manufactured processor.

[0174] [Second Embodiment]

[0175] Figure 10 This is a schematic diagram showing a system 1000 for executing new instructions according to a second embodiment of the present invention. Figure 1 The difference from the first embodiment shown is that, Figure 10 The conversion program 145 in the system 1000 shown for executing the new instruction runs directly on the processor in the same execution mode as the new instruction. Furthermore, since the conversion program 145 in the second embodiment runs in the same execution mode as the new instruction, the processor does not need to switch execution modes when executing the conversion program 145. The differences between the second embodiment and the first embodiment will be detailed below.

[0176] like Figure 10 As shown, when instruction 118 is an unknown instruction 132, processor 110 executes the microcode handler for handling unknown instruction exceptions. In the microcode handler for handling unknown instruction exceptions, the conversion program 145 is directly called (e.g., ...). Figure 10 (As shown by solid arrow 2 in the diagram). The conversion program 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 will convert it into at least one old instruction and send the at least one old instruction to the microcode processing program that handles unknown instruction exceptions (e.g., ...). Figure 10 (as shown by solid arrow 6 in the diagram). The microcode handler for handling unknown instruction exceptions receives at least one of the aforementioned legacy instructions and causes the processor 110 to execute the aforementioned legacy instruction via a call instruction or a jump instruction.

[0177] Figure 11 This is a structural diagram of the processor according to the second embodiment of the present invention. Figure 11 neutralization Figure 2 Components with the same name have the same function, so we will not repeat them here.

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

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

[0180] In step S1215, in response to the aforementioned unknown instruction exception, the processor 1100 determines whether the received instruction is a new instruction through a conversion program. Specifically, after the instruction submission unit 245 issues an unknown instruction exception, the processor 1100 executes a microcode processing program for handling the unknown instruction exception. In the microcode processing program for handling the unknown instruction exception, the processor 1100 sends the information of the received instruction and the runtime environment information to the conversion program 145. The conversion program 145 determines whether the received instruction is a new instruction based on the information of the received instruction. How the conversion program 145 determines whether the received instruction is a new instruction has been described in detail in the first embodiment and will not be repeated here.

[0181] Figure 13 This is a flowchart illustrating the processing of receiving instructions according to the second embodiment of the present invention. Figure 13 Steps S1305, S1310, and S1325 Figure 4 Steps S405, S410, and S435 are the same and will not be repeated here. Step S1320 is described below.

[0182] In step S1320, Figure 11 The processor 1100 processes the aforementioned received instruction. Specifically, when the received instruction is an unknown instruction (the determination result of step S1310 is "yes"), the processor 1100 executes a microcode processing program for handling unknown instruction exceptions. In the microcode processing program for handling unknown instruction exceptions, the processor 1100 processes the aforementioned unknown instruction through a conversion program 145 (which will be discussed in conjunction with the following text). Figure 14 (Detailed explanation).

[0183] Figure 14 This is a flowchart illustrating the processing of received instructions in a microcode processing procedure for handling unknown instruction exceptions according to a second embodiment of the present invention. Figure 14 As shown, Figure 11 The processor 1100 acquires information about the received instruction (S1405), converts the received instruction through the conversion program 145, and generates a conversion result (S1410). If the conversion is successful (the judgment result of step S1415 is "yes"), the processor 1100 obtains at least one old instruction from the conversion result and executes the at least one old instruction (S1420). The detailed explanation is as follows: The processor 1100 first executes step S1405.

[0184] In step S1405, information about the received instruction is obtained in the microcode handler for the unknown instruction exception. This information includes the instruction pointer of the received instruction. It is worth noting that since the received instruction has not yet been decoded, this information does not include decoding information such as prefixes, escape codes, and opcodes. When the microcode handler for the unknown instruction exception is executed, the operating environment of the processor 1100 remains unchanged because no mode switching is required. Therefore, the operating environment information of the processor 1100 can be directly obtained in the microcode handler for the unknown instruction exception; this operating environment information is the operating environment information of the received instruction. Then, step S1410 is executed.

[0185] In step S1410, the processor 1100 converts the received instruction through conversion program 145 and generates a conversion result. The process of converting the received instruction through conversion program 145 is the same as in the first embodiment and will not be described again here. Steps S1415 and... Figure 6 Step S620 is the same, so it will not be repeated here. Steps S1420 and S1425 are described below.

[0186] When the conversion process 145 successfully completes the conversion ("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. Furthermore, the processor 1100 can also obtain the length of the received instruction from the conversion result. In one embodiment, the next instruction after the received instruction is another instruction. The last instruction among the at least one old instruction is a jump instruction or a call instruction, and the processor 1100 jumps to the other instruction via the jump instruction or the call instruction. The instruction pointer of the other instruction is: EIP + Length, where EIP is the instruction pointer of the received instruction, and Length is the length of the received instruction.

[0187] When conversion program 145 fails (No in step S1415), processor 1100 executes step S1425. In step S1425, processor 1100 handles an exception. Specifically, any exception encountered when conversion program 145 converts the aforementioned received instruction will cause conversion failure. In the microcode handler for handling unknown instruction exceptions in interrupt preprocessing unit 112, an exception number can be obtained from the content field of the conversion result. Then, the microcode handler for handling unknown instruction exceptions issues an exception corresponding to the aforementioned exception number. In response to the exception corresponding to the aforementioned exception number, processor 1100 executes the corresponding microcode handler to handle the aforementioned exception.

[0188] The processing flow of the conversion procedure in the second embodiment is the same as that in the first embodiment. Figure 7 The processing flow of the conversion program is the same, so it will not be described again here.

[0189] In summary, unlike the first embodiment, in this embodiment, when the processor 1100 executes an unknown instruction, the processor 1100 directly executes the conversion program 145 in the same execution mode as the unknown instruction. The conversion program 145 determines whether the unknown instruction is a new instruction. If the unknown instruction is a new instruction, the conversion program 145 converts the new instruction into at least one old instruction. Then, the processor 1100 executes the at least one old instruction in the same execution mode as the unknown instruction. Compared with the first embodiment, in this embodiment, the processor does not need to switch execution modes, thus the efficiency of simulating the execution of new instructions is higher.

[0190] [Third Embodiment]

[0191] Figures 15A-15B This is a schematic diagram showing a system 1500 for executing new instructions according to a third embodiment of the present invention. Figure 1 The first embodiment shown and Figure 10 Unlike the second embodiment shown, in the third embodiment, the conversion program 145 in the system 1500 that executes the new instructions is run by the kernel driver 150 in the operating system 120. The conversion program 145 may be located inside the kernel driver 150 (e.g., Figure 15A (as shown) or external (such as) Figure 15B (As shown). Please refer to... Figure 11 and Figures 15A-15B When processor 1100 determines that instruction 118 is an unknown instruction 132, it will issue an unknown instruction exception. In response to this unknown instruction exception, processor 1100 executes the microcode handler for the unknown instruction exception. In the microcode handler for the unknown instruction exception, processor 1100 calls kernel driver 150 and simultaneously sends information about the unknown instruction 132 and runtime environment information to kernel driver 150. Kernel driver 150 processes the received instruction through translation program 145.

[0192] In one embodiment, in the microcode handler for an unknown instruction exception, the processor 1100 calls the kernel driver 150 through a custom interrupt service routine (the developer of the interrupt service routine can call the custom interrupt handler through a custom interrupt vector #NE (Non-support instruction Emulator), where the custom interrupt vector #NE is a reserved number in the interrupt vector table). It is worth noting that when the interrupt service routine calls the kernel driver 150, it must either pass information about the unknown instruction 132 (including the instruction pointer, etc.) and runtime environment information to the kernel driver 150, or notify the kernel driver 150 of the storage address of the unknown instruction 132 information and runtime environment information. Furthermore, the interrupt service routine used by the kernel driver 150 (the interrupt service routine corresponding to the custom interrupt vector #NE) can be microcode stored in the interrupt preprocessing unit 112 and called by the interrupt preprocessing unit 112 (the interrupt preprocessing unit 112 can be constructed using a state machine or combinational logic circuits). In one embodiment, the kernel driver 150 can be invoked by the operating system 120 to execute the kernel driver 150 via a system call, by processing the unknown instruction 132 through the translation program 145. For example, the kernel driver 150 can be used as a callback function, and the information of the unknown instruction 132 and the runtime environment information can be passed to the kernel driver 150 as parameters. If the unknown instruction 132 is a new instruction, the kernel driver 150 will return at least one old instruction to the processor 1100 after processing the unknown instruction 132 through the translation program 145. Alternatively, the kernel driver 150 can be invoked through an internal interrupt or a trap. For example, the designer of the processor 1100 can define an interrupt vector #NE to enter the kernel of the operating system and invoke the kernel driver 150. Those skilled in the art will know the technical details of this part, so they will not be described in detail here. In one embodiment, the process of sending the information of the unknown instruction 132 and the runtime environment information in the microcode handler of the unknown instruction exception is as follows: the information of the unknown instruction 132 and the runtime environment information are pushed onto the stack, and then the kernel driver 150 retrieves the information of the unknown instruction 132 and the runtime environment information from the stack.

[0193] In another embodiment, the interrupt service routine for handling unknown instruction exceptions in the operating system can be modified to directly call the kernel driver 150 to process the unknown instruction 132. In the modified interrupt service routine, information about the unknown instruction 132 and its runtime environment can be read first, and then transmitted to the kernel driver 150. In this embodiment, no modifications to the processor hardware and / or microcode are required; only the interrupt service routine for handling unknown instruction exceptions in the operating system needs to be modified to achieve the processing of unknown instructions as described above, making it quite convenient to implement. In practice, those skilled in the art can modify the interrupt service routine for handling unknown instruction exceptions to add the functions of reading information about the unknown instruction 132 and its runtime environment, as well as calling the kernel driver 150. Since the interrupt service routine for handling unknown instruction exceptions varies depending on the operating system and / or processor version, those skilled in the art can write corresponding code according to the actual situation.

[0194] Figure 16 This is a flowchart of the process of receiving instructions according to the third embodiment of the present invention. Figure 16 Steps S1605, S1610, and S1625 are the same as those in the second embodiment. Figure 13 Steps S1305, S1310, and S1325 are the same and will not be repeated here. Step S1620 is described below.

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

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

[0197] In summary, unlike the second embodiment, in this embodiment (the third embodiment), when the processor 1100 executes an unknown instruction, the microcode handler for handling unknown instruction exceptions executes the kernel driver 150 of the operating system 120 to continue processing the convertible new instruction. Compared to the second embodiment, in this embodiment, the operating system's kernel driver is used to convert the new instruction through a conversion program. Compared to updating the processor's hardware and / or the microcode in the processor, updating the kernel driver and the conversion program is more convenient and faster, thereby improving development efficiency.

[0198] [Fourth Embodiment]

[0199] Figure 17 This is a schematic diagram showing a system 1700 for executing new instructions according to a fourth embodiment of the present invention. Similar to the third embodiment, in this embodiment (fourth embodiment), the conversion program 145 in the system 1700 for executing new instructions is also run by the kernel driver 150 in the operating system 120. The difference is that in this embodiment, the conversion program 145 runs on a dedicated processing core 190. The kernel driver 150 sends information about the unknown instruction 132 and runtime environment information to the conversion program 145 via a polling or doorbell mechanism. The conversion program 145 also needs to send the conversion result to the kernel driver 150 via a polling or doorbell mechanism. The specific methods for transmitting data between the kernel driver 150 and the conversion program 145 via polling or doorbell mechanisms will be described below.

[0200] The polling mechanism will be described below. Please refer to... Figure 11 and Figure 17 In one embodiment, the designer of processor 1100 may set a transfer register (not shown) in the uncore of processor 1100 to store information about the unknown instruction 132, runtime environment information, a transfer information identifier, and a transfer result identifier (all not shown). Figure 17In the above-mentioned transfer register, the default values ​​for both the transfer information identifier and the transfer result identifier are the second value. The kernel driver 150 stores the information of the unknown instruction 132 and the runtime environment information into the aforementioned transfer register, and stores the transfer information identifier with the first value into the aforementioned transfer register. Then, the kernel driver 150 reads the transfer result identifier in the transfer register at fixed intervals (e.g., every 100 milliseconds) to wait for the conversion result. If the transfer result identifier is read as the first value, it indicates that the conversion program 145 has generated the conversion result, and the kernel driver 150 reads the conversion result from the transfer register. Additionally, the conversion program 145 running on the dedicated processing core 190 is configured to check whether the transfer information identifier in the transfer register is the first value at fixed intervals (e.g., every 100 milliseconds) when idle. If the transfer information identifier in the transfer register is the first value, the conversion program 145 reads the information of the unknown instruction 132 and the runtime environment information from the aforementioned transfer register, and then sets the transfer information identifier in the transfer register to the second value. Then, the conversion program 145 performs the conversion processing on the unknown instruction 132 as described above, generating the conversion result. Then, the conversion program 145 stores the conversion result into the transfer register and stores the transfer result identifier with a first value into the transfer register. As mentioned earlier, since the transfer result identifier is the first value, the kernel driver 150 reads the conversion result from the transfer register and sets the transfer result identifier in the transfer register to the second value. At this point, a data transfer is completed between the kernel driver 150 and the conversion program 145. In another embodiment, under a multi-core processor architecture, it is also necessary to store the processing core number into the transfer register or allocate dedicated storage space for each processing core in the transfer register, so that the kernel driver 150 running on each processing core can perform data transfer with the conversion program 145.

[0201] The doorbell mechanism is described below. Refer to [reference needed]. Figure 11 and Figure 17 In one embodiment, the designer of processor 1100 may set a transfer register (not shown) in a non-core part of processor 1100 to store information about the unknown instruction 132 and runtime environment information (both not shown). Figure 17(In the middle). After the kernel driver 150 stores the information of the unknown instruction 132 and the runtime environment information into the aforementioned transfer register, it notifies the conversion program 145 running on the dedicated processor 190 via an interrupt. In response to the interrupt, the conversion program 145 reads the information of the unknown instruction 132 and the runtime environment information from the aforementioned transfer register and generates a conversion result. Then, the conversion program 145 stores the conversion result into the transfer register and notifies the kernel driver 150 via an interrupt. In response to the interrupt, the kernel driver 150 reads the conversion result from the transfer register. At this point, a data transfer is completed between the kernel driver 150 and the conversion program 145. As for how to set the interrupt, such as defining interrupt service routines and corresponding interrupt vector numbers for the kernel driver 150 and the conversion program 145 respectively, it has been described above and will not be repeated here. In another embodiment, a hardware interrupt signal line (PIN) can also be added separately to the processor 1100 and / or the dedicated processor 190. The kernel driver 150 and / or the conversion program 145 can trigger an interrupt through the aforementioned hardware interrupt signal line to complete the data transfer.

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

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

[0204] As can be seen from the above, similar to the third embodiment, the conversion of new instructions is also implemented through the kernel driver 150 of the operating system 120 in this embodiment. Unlike the third embodiment, in this embodiment, the conversion program 145 runs on the dedicated processing core 190. In this embodiment, because the conversion program 145 runs on the dedicated processing core 190, the execution speed is faster; furthermore, since it is not necessary to run a conversion program 145 in each processing core, the workload of the other processing cores of the processor is reduced.

[0205] Figure 18 This is a flowchart illustrating the execution of a newly added instruction according to an embodiment of the present invention. Please also refer to... Figure 11 , 1718. As described above in the third embodiment and this embodiment, the processor 1100 receives an instruction (S1805). When the received instruction is an unknown instruction, the processor 1100 executes a conversion program through the operating system 120 (S1810). In the conversion program, it is determined whether the received instruction is a new instruction (S1815), and when the received instruction is a new instruction, it is converted into at least one old instruction (S1820). Finally, the processor 1100 executes the at least one old instruction (S1825). Figure 18 Steps S1805, S1815, S1820, and S1825 have been described in detail in the first embodiment and will not be repeated here. Step S1810 is described below.

[0206] In step S1810, when the received instruction is an unknown instruction, the processor 1100 executes a conversion program through the operating system. Specifically, as described above in the third embodiment and this embodiment, when the received instruction is an unknown instruction, the instruction submission unit 245 issues an unknown instruction exception. In response to the unknown instruction exception, the processor 1100 executes the microcode handling program for the unknown instruction exception. In the microcode handling program for the unknown instruction exception, the kernel driver 150 of the operating system is called. The kernel driver 150 of the operating system then calls the conversion program 145.

[0207] Figure 19 This is a flowchart illustrating the execution of a newly added instruction according to an embodiment of the present invention. Please also refer to... Figure 11 , 17 19. As described above in the first embodiment, second embodiment, third embodiment, and this embodiment, the processor 1100 receives an instruction (S1905). When the received instruction is an unknown instruction, the processor 1100 initiates a conversion procedure (S1910). In the conversion procedure, it is determined whether the received instruction is a new instruction (S1915), and when the received instruction is a new instruction, it is converted into at least one old instruction (S1920). Finally, the processor 1100 simulates the execution of the received instruction by executing the at least one old instruction (S1925). Figure 19 Steps S1905, S1915, S1920, and S1925 have been described in detail in the first embodiment and will not be repeated here. Step S1910 is described below.

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

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

[0210] Figure 20 This is a flowchart illustrating a conversion and addition instruction according to an embodiment of the present invention. Please also refer to... Figure 11 , 17 20. As described above in the first embodiment, second embodiment, third embodiment, and this embodiment, the conversion program 145 receives an instruction, wherein the instruction is an unknown instruction (S2005), and determines whether the received instruction is a new instruction (S2010). When the received instruction is a new instruction, the conversion program 145 converts the received instruction into at least one old instruction (S2015). In the preceding text, it has already been stated that... Figure 20 Steps S2005, S2010, and S2015 have been described in detail, so they will not be repeated here.

[0211] For the embodiments of the present invention already described, the following describes exemplary operating environments in which embodiments of the present invention can be implemented. See details. Figure 21 , Figure 21 This illustrates an exemplary operating environment for implementing embodiments of the present invention, and can generally be considered as computing device 2100. Computing device 2100 is merely an example of a suitable computing environment and is not intended to imply any limitation on the use or scope of the invention. Computing device 2100 should also not be construed as having any dependency or requirement associated with any or all combinations of the elements shown.

[0212] This invention can be executed using instructions on a computer or machine. These instructions can be computer-executable instructions for a program module, which is executed by a computer or other machine, such as a personal digital assistant or other portable device. Generally, a program module includes routines, programs, objects, components, data structures, etc., and refers to program code that performs a specific task or implements a specific abstract data type. This invention can be implemented in various system configurations, including portable devices, consumer electronics, general-purpose computers, and more specialized computing devices. This invention can also be implemented in distributed computing environments, processing devices connected by communication networks.

[0213] Please refer to Figure 21 The computing device 2100 includes a bus 2110, 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, which are directly or indirectly coupled to the following devices. The bus 2110 may be an element of one or more buses (e.g., an address bus, a data bus, or a combination thereof). Although Figure 21 For simplicity, the various blocks are shown as lines. In reality, the boundaries between the various elements are not specific. For example, the presentation elements of the display device can be regarded as I / O elements; the processor may have memory.

[0214] Computing device 2100 generally includes various computer-readable media. Computer-readable media can be any available medium accessible to computing device 2100, including both volatile and non-volatile media, and removable and non-removable media. For example, but not limited to, computer-readable media can include computer storage media and communication media. Computer-readable media also includes volatile and non-volatile media, and removable and non-removable media implemented in any method or technology for storing 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical disc storage devices, magnetic disks, magnetic disks, magnetic storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to computing device 2100. Computer storage media itself does not contain signals.

[0215] Communication media generally include computer-readable instructions, data structures, program modules, or other data in the form of modular data signals, such as carrier waves or other transmission mechanisms, and include any information transmission medium. The term "modular data signal" refers to a signal having one or more sets of characteristics or modified in a manner that encodes information in the signal. For example, but not limited to, communication media include wired media such as wired networks or direct wired connections, and wireless media such as audio, radio frequency, infrared, and other wireless media. Combinations of the above media are included within the scope of computer-readable media.

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

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

[0218] I / O port 2118 allows computing device 2100 to be logically connected to other devices including I / O element 2120, some of which are built-in. Exemplary elements include microphones, joysticks, game consoles, disc satellite receivers, scanners, printers, wireless devices, etc. I / O element 2120 provides a Natural User Interface (NUI) for processing user-generated gestures, voice, or other physiological input. In some examples, this input may be transmitted to a suitable network element for further processing. The NUI can implement any combination of speech recognition, touch and stylus recognition, facial recognition, biometrics, gesture recognition on and near the screen, air gestures, head and eye tracking, and touch recognition associated with the display on computing device 2100. 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 thereof, to detect and recognize gestures. Additionally, computing device 2100 may be equipped with an accelerometer or gyroscope to detect motion. The output of the accelerometer or gyroscope can be provided to the computing device 2100 for display to present an immersive augmented reality or virtual reality.

[0219] In addition, the processor 2114 in the computing device 2100 can also execute programs and instructions in the memory 2112 to perform the actions and steps described in the above embodiments, or other content described in the specification.

[0220] Any specific order or hierarchical arrangement of steps in the procedures disclosed herein is merely illustrative. It should be understood, based on design preferences, that any specific order or hierarchical arrangement of steps in the procedures can be rearranged within the scope of this document. The accompanying method claims present the elements of various steps in an exemplary order and should therefore not be limited to any particular order or hierarchy shown herein.

[0221] The use of ordinal numbers such as "first," "second," and "third" to modify elements in the claims does not imply any priority, order of precedence, sequence of elements, or order of steps performed by the method, but is merely used as an identifier to distinguish different elements with the same name (but different ordinal numbers).

[0222] The method and system for executing new instructions provided by this invention enable the execution of new instructions on previous generation processors without modifying the hardware architecture of the processing core.

[0223] The above description is only a preferred embodiment of the present invention, but it is not intended to limit the scope of the present invention. Any person skilled in the art can make further improvements and changes on this basis without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be determined by the scope defined in the claims of this application.

Claims

1. A method for executing a newly added instruction, characterized in that, Include: Instructions are received by the processor; When the received instruction is an unknown instruction not natively supported by the processor, a conversion program is executed by the operating system running on the processor. The conversion program is as follows: Determine whether the above-mentioned receive instruction is a new instruction that is newly supported by a descendant processor of the above-mentioned processor and cannot be recognized by the above-mentioned processor; When the above-mentioned receive instruction is a new instruction, the above-mentioned receive instruction is converted into at least one old instruction natively supported by the above-mentioned processor. And, the processor executes at least one of the aforementioned legacy instructions.

2. The method for executing a new instruction as described in claim 1, further comprising: The aforementioned operating system executes the conversion program through a kernel driver.

3. The method for executing a new instruction as described in claim 1, wherein, The aforementioned receiving instruction is an instruction set architecture instruction, and the aforementioned at least one old instruction is an instruction set architecture instruction.

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

5. The method for executing a new instruction as described in claim 1, further comprising: The processor described above decodes at least one of the aforementioned legacy instructions into at least one microinstruction; as well as The processor described above executes at least one of the microinstructions.

6. The method for executing a new instruction as described in claim 1, further comprising: Using the above operating system: Based on the instruction pointer of the aforementioned receiving instruction, obtain the machine code of the aforementioned receiving instruction; Obtain the runtime environment information for receiving the above-mentioned instructions; and The instruction pointer, the machine code, and the runtime environment information mentioned above are sent to the conversion program.

7. The method for executing a new instruction as described in claim 6, further comprising: The above conversion program determines whether the above received instruction is a new instruction based on the above machine code.

8. The method for executing a new instruction as described in claim 6, wherein when the received instruction is not a new instruction, the method further comprises: An unknown instruction exception was generated; The above conversion program sends the aforementioned unknown instruction exception to the kernel driver; as well as The aforementioned kernel driver abnormally sends the aforementioned unknown instruction to the aforementioned operating system.

9. The method for executing a new instruction as described in claim 6, wherein when the received instruction is a new instruction, the method further comprises: If the aforementioned received instruction cannot be executed in operating mode, the aforementioned conversion program generates a decoding exception, wherein the aforementioned operating environment information includes the aforementioned operating mode; and The above conversion program sends the above decoding error to the above operating system.

10. The method for executing a new instruction as described in claim 1, wherein when the received instruction is a new instruction, the method further comprises: The aforementioned conversion procedure sends at least one of the aforementioned old instructions to the aforementioned processor; and The processor executes at least one of the aforementioned legacy instructions received.

11. The method for executing a new instruction as described in claim 1, wherein, The conversion program mentioned above is a driver or application for the aforementioned operating system.

12. The method for executing a new instruction as described in claim 1, wherein, The above conversion process is executed in a dedicated processing core.

13. The method for executing a new instruction as described in claim 12, further comprising: The aforementioned operating system sends the instruction pointer of the received instruction, the machine code of the received instruction, and the runtime environment information of the received instruction to the aforementioned conversion program through the polling mechanism or doorbell mechanism of the aforementioned dedicated processing core.

14. The method for executing a new instruction as described in claim 12, further comprising: The aforementioned operating system obtains at least one of the old instructions generated by the aforementioned conversion program through the polling mechanism or doorbell mechanism of the aforementioned dedicated processing core.

15. The method for executing a new instruction as described in claim 1, wherein, The aforementioned conversion program is included in the aforementioned operating system.

16. The method for executing a new instruction as described in claim 1, further comprising: When the received instruction is an unknown instruction, an error occurs when issuing an unknown instruction. as well as In response to the aforementioned unknown instruction exception, the kernel driver of the aforementioned operating system is executed, and the aforementioned conversion program is performed through the aforementioned kernel driver.

17. A system for executing newly added instructions, characterized in that, include: The processor includes an instruction decoding unit that receives an instruction and determines whether the received instruction is an unknown instruction not natively supported by the processor. When the received instruction is an unknown instruction, the system executing the new instruction executes a conversion program through the operating system running on the processor. The conversion program is as follows: Determine whether the above-mentioned receive instruction is a new instruction that is newly supported by a descendant processor of the above-mentioned processor and cannot be recognized by the above-mentioned processor; When the above-mentioned receive instruction is a new instruction, the above-mentioned receive instruction is converted into at least one old instruction natively supported by the above-mentioned processor. In this system, the processor executes at least one of the old instructions.

18. The system for executing new instructions as described in claim 17, wherein, The aforementioned operating system executes the conversion program through a kernel driver.

19. The system for executing new instructions as claimed in claim 17, wherein, The aforementioned receiving instruction is an instruction set architecture instruction, and the aforementioned at least one old instruction is an instruction set architecture instruction.

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

21. The system for executing new instructions as claimed in claim 17, wherein, The processor of the system executing the new instruction decodes the at least one old instruction into at least one microinstruction; and the processor of the system executing the new instruction executes the at least one microinstruction.

22. The system for executing new instructions as described in claim 17, wherein, The system that executes the new instructions described above uses the aforementioned operating system: Based on the instruction pointer of the aforementioned receiving instruction, obtain the machine code of the aforementioned receiving instruction; Obtain the runtime environment information for receiving the above-mentioned instructions; and The instruction pointer, the machine code, and the runtime environment information mentioned above are sent to the conversion program.

23. The system for executing new instructions as described in claim 22, wherein, The above conversion program determines whether the above received instruction is a new instruction based on the above machine code.

24. The system for executing new instructions as described in claim 22, wherein, When the received instruction is not a new instruction, the system executing the new instruction generates an unknown instruction exception; the conversion program sends the unknown instruction exception to the kernel driver; and the kernel driver sends the unknown instruction exception to the operating system.

25. The system for executing new instructions as described in claim 22, wherein, When the above-mentioned received instruction is a new instruction, if the above-mentioned received instruction cannot be executed in the running mode, the above-mentioned conversion program generates a decoding exception, wherein the above-mentioned running environment information includes the above-mentioned running mode; and the above-mentioned conversion program sends the above-mentioned decoding exception to the above-mentioned operating system.

26. The system for executing new instructions as described in claim 17, wherein, When the received instruction is a new instruction, the conversion program sends at least one old instruction to the processor; and the processor executes the received at least one old instruction.

27. The system for executing new instructions as claimed in claim 17, wherein, The conversion program mentioned above is a driver or application for the aforementioned operating system.

28. The system for executing new instructions as described in claim 17, wherein, The above conversion process is executed in a dedicated processing core.

29. The system for executing new instructions as described in claim 28, wherein, The aforementioned operating system sends the instruction pointer of the received instruction, the machine code of the received instruction, and the runtime environment information of the received instruction to the aforementioned conversion program through the polling mechanism or doorbell mechanism of the aforementioned dedicated processing core.

30. The system for executing new instructions as described in claim 28, wherein, The aforementioned operating system obtains at least one of the old instructions generated by the aforementioned conversion program through the polling mechanism or doorbell mechanism of the aforementioned dedicated processing core.

31. The system for executing new instructions as described in claim 17, wherein, The aforementioned conversion program is included in the aforementioned operating system.

32. The system for executing new instructions as described in claim 17, further comprising: When the received instruction is an unknown instruction, the instruction submission unit issues an unknown instruction exception; in response to the unknown instruction exception, the system executing the new instruction executes the kernel driver of the operating system, and executes the conversion program through the kernel driver.

Images