WO2016145498A1

WO2016145498A1 - Method and system for instruction emulation and legacy code execution

Info

Publication number: WO2016145498A1
Application number: PCT/BR2015/000181
Authority: WO
Inventors: Bruno Cardoso LOPES; Rafael AULER; Edson Borin; Rodolfo Jardim AZEVEDO
Original assignee: Universidade Estadual De Campinas - Unicamp
Priority date: 2015-03-13
Filing date: 2015-12-04
Publication date: 2016-09-22
Also published as: BR102015005838A2

Abstract

The present invention pertains to the field of information technology and more specifically to the execution of instructions in computer architectures and legacy code compatibility, and relates to a method and system for removal of instructions in computer architectures without disrupting compatibility with legacy code. The method and system may be used to guarantee compatibility of execution of old programs on new generations of a specific processor that does not necessarily include the subset of instructions necessary to execute the code thereof.

Description

METHOD AND SYSTEM FOR EMULATING INSTRUCTIONS AND IMPLEMENTATION

LEGACY CODE

FIELD OF INVENTION

[1] The present invention is in the field of information technology, more specifically the execution of instructions in computer architectures and the compatibility of legacy code, and relates to a method and system for removing instructions in computer architectures without break compatibility with legacy code.

[2] Has an application in ensuring compatibility of execution of old programs in new generations of a given processor, which does not necessarily include the subset of the instructions necessary to execute its code.

BACKGROUND OF THE INVENTION

[3] As a computer architecture evolves, successive generations of new instructions are added to it, which increases the complexity of the instruction set and makes the design of this processor increasingly difficult. More specifically, there is a limitation on the number of instructions a processor supports, which is related to the number of bytes required to encode the operation code. In the case of RISC processors, where instruction encoding is fixed in size, this increase in the number of instructions may even saturate the opcodes space, making it impossible to add new instructions in the future. [4] Currently, whenever an architecture has its instruction set overloaded with too many unused statements, a new version of the architecture or a new execution mode is created. If a new architecture is chosen, it will not be compatible with the previous one and all software will have to be recompiled. On the other hand, if you choose to create a new mode of execution, this new mode. execution will require operating system support to detect and know the correct mode for each program. In addition, processor complexity is increased by adding the new mode and maintaining the previous mode.

[5] Several other proposals have addressed this problem by trying to increase coding efficiency by using initiatives that support compact coding, allowing a processor to use fewer instructions to function. This ultimately gives more space so that new instruction sets can be added to it if necessary. Note that this does not solve the problem when the maximum number of supported statements is reached, but only causes it to be delayed for a longer time.

[6] Finally, a commonly used solution is simply to replace outdated instructions (rarely used by modern applications) with new ones, solving the space problem. However, this technique leads to the problem of code execution compatibility. legacy, that is, in programs compiled for a version of a particular processor, the processor may request instructions that are no longer present in the current version of the same, preventing its execution.

[7] It is. It is precisely on this latter technique that the present invention proposes an unprecedented method of recycling outdated instructions by proposing the emulation of these instructions removed from those still present in the current processor instruction set. Whenever a removed instruction is requested by the running program, a processor-established routine is able to interpret this request and establish an alternate sequence of existing statements with the same purpose (emulation). No document demonstrating emulation instruction recycling methods or any other similar alternative ensuring legacy code execution compatibility has been found in the prior art.

BRIEF DESCRIPTION OF THE INVENTION

[8] The present invention relates to a method and system for the removal of instructions in computer architectures, which ensures compatibility of execution of legacy code.

[9] More specifically, it comprises instructional recycling means in computer architectures, which enable the execution of a processor routine capable of establishing an alternate sequence of existing instructions (emulation) upon request by the program to execute a previously removed instruction. . In this In this situation, the program is not prevented from running and legacy code compatibility is guaranteed.

[10] The method may be described comprising the following steps:

(a) creation of a new instruction;

- (b) Removal of an old instruction;

(c) recycling of the corresponding unique instruction signature (UIS);

(d) Preparation for emulation of instruction removed in (b).

(dl) Determine a "UR" Revision Number for each UIS, and update it whenever its corresponding statement is recycled.

(d2) Establish the sequence of instructions that performs operation equivalent to the removed statement.

(d3) Determine the "RV" Review Vector for a PR.

(d4) Determine the "TM" interrupt masks for previous SRs in a PR.

(d5) Determine Effective Review Index "ERI".

(d ^' 6) Determine Active Review Vector "ARV".

(e) Emulation of the statement removed in (b).

(el) Verify that. a SRi computer program is running on a PRj processor, for i <j.

(e2) Look in the ERI for the entry corresponding to the difference between the indices je i. (e3) Identify in ARV the TM corresponding to the index calculated in (e2).

(e4) Verify that a given instruction executed by the SR is included in the selected TM.

(e5) Execute the alternate sequence of instructions equivalent to the instruction identified in ^' (e4).

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 - Shows the mechanism of outdating and recycling an instruction, and the problem of backwards compatibility.

Figure 2 - Shows the UIS Revision (UR), which records instructions that were associated with a specific UIS in previous versions of a processor.

Figure 3 - Shows an example of a TM (a, b) trap mask where an SRa program is running on a PRb processor.

Figure 4 - Shows an example of an Active Review Vector.

Figure 5 - Emulation of removed instruction.

Figure 6 - Indicates the length of the page table to indicate the revision of the software on each of the computer's memory pages.

Figure 7 - Indicates the software development flow and how the software review process is noted in each phase, including the intermediate files, libraries, and the final executable. The figure also indicates a possible disposition of this file. executable in memory with attention to the fact that Software and Library 1 can coexist on the same page because they can have the same SR, library 2 has to be on a separate page.

DETAILED DESCRIPTION OF THE INVENTION

[11] The present invention relates to a method and system for removing instructions in computer architectures, which ensures compatibility of execution of legacy code.

[12] More specifically, it comprises instructional recycling means in computer architectures, which enable the execution of a processor routine capable of establishing an alternative sequence of existing instructions (emulation) upon request by the program to execute a previously removed instruction. . In this situation, the program is not prevented from running and legacy code compatibility is guaranteed.

[13] The method may be described comprising the following steps:

(a) creation of a new instruction;

(b) Removal of an old instruction;

(c) recycling of the corresponding unique instruction signature (UIS);

(d) Preparation for emulation of instruction removed in (b).

(dl) Determine a "UR" Revision Number for each UIS, and update it whenever its corresponding statement is recycled. (o! 2) Establish the sequence of instructions that performs operation equivalent to the removed statement.

(d3) Determine the "RV" Review Vector for a PR.

(d4) Determine "TM" Interrupt Masks for previous SRs in a PR.

(d5) Determine Effective Review Index "ERI".

(d6) Determine Active Review Vector "ARV".

(e) Emulation of the statement removed in (b).

(el) Verify that a computer program

SRi is running on a processor

PRj, for i <j.

(e2) Store in ERI the difference between the

Indexes j and i.

(e3) Identify in ARV the TM corresponding to the index calculated in (e2).

(e4) Verify that a given instruction called by the SR is included in the selected TM.

(e5) Execute the alternate sequence of instructions equivalent to the instruction identified in (e4).

[14] By defining the term processor revision (PR) and software version, or software revision (SR), it can be said that "PR" identifies the instruction set implemented in the processor as "SR" indicates the "PR" for which the software was compiled. [15] The unique instruction signature (UI-S) is a unique instruction identifier. This identifier is usually associated with the same statement across different generations, from the same architecture to ensure compatibility with legacy code. The set of all valid UISs determines a UIS space and the insertion of new ^' UISs may compromise the available space. A UIS can then be reused by disassociating from an old instruction and associating with a new instruction. reuse of ^' UIS implies sequential processor revisions.- ^' This process ^' can continue for more than once, with one UIS - covering ^' the useful life of several different instructions, and therefore several different 'PRs'. For example, throughout its history, the x86 instruction set architecture or ISA had only one PR, as it never had a recycled UIS.

[16] As that set architecture instructions and processors "evolve, their" PR "is incremented, ^■ and may therefore exist several versions of the processor (ie PR1, PR2, PRN) and therefore several , software versions (ie SRI, SR2, SR) Software with version SRi is fully compatible with a processor in version PRj if i = j.

[17] However, whenever a PR arises, the previous SRi (i <j). are not guaranteed compatible because they may request an unavailable instruction. ^: Nesta In this situation, the program will request a UIS that will take you to a completely different instruction than you want, preventing its correct execution.

[18] When a particular statement is considered obsolete and its UIS is reusable, an outdated stage is usually promoted. It guarantees enough time for compiler and operating system developer teams to properly upgrade their products, and consists of the Creation, Downgrading, and Recycling steps (Figure 1):

Creation

[19] Initially, a new instruction is created and associated with a UIS in PR. TUI may never have been used before (a previously ^■ invalid instruction), or may have been recycled from another instruction (as stage of "outdated" below). Only after a long process of software evolution will this instruction actually be incorporated into user programs, as it may take time for this instruction to be adopted by compilers and libraries distributed to users.

Downgrading

[20] Technological advances and new market demands drive the evolution of processors, bringing new instruction set that may override the functionality of older instructions. Thus, very processor-specific features may become obsolete. After deciding to obsolescer an instruction, in some At the moment between two PRs of a processor, the processor manufacturer must announce this fact to the community. As a result, compiler manufacturers remove support for this instruction, and operating system manufacturers begin using alternative instructions to the obsolete one.

Recycling

[21] Downgrading an instruction makes a UIS available for the next PR and allows it to be associated with the newly created instruction. A UIS must be associated with a single statement, and vice versa.

Backward compatibility

[22] By definition, a PR1 processor has at least one UIS recycled from PRO, and has different implementations. Running an SRi on a PRj (i <j) will cause backward compatibility issues if the UIS (s) in question exist in the running software. As shown in Figure 1, PRb's VADD instruction has the same opcode as PRa's AAA.

[23] As can be seen, this stage of downgrading requires considerable time, and almost always implies the need to recompile a computer program to the new processor (PR) version to ensure its proper functioning. Also, it presents a problem for the end user of this application, who should purchase newer versions (or updates) of this computer program or never upgrade the processor to a newer model. [24] In this context the usefulness of the present invention is considered, which allows to associate old UIS to new instructions, or different instructions, without breaking the compatibility with legacy code, through a new recycling mechanism. With this technique, when an SRi program executed in a PRj (i <j) requests a previously removed instruction, an emulation routine is established in order to find an alternative path using existing instructions, allowing its correct execution. More specifically, it provides the behavior of the old instruction through software emulation through CPU interrupts. Each file that stores software has its SR annotated in the header to indicate the specific PR it was designed for, telling the Operating System how to configure the potential emulation routines needed if the software revision is different from the processor's.

UIS Review

[25] For the application of the present invention, since recycling and creation steps occur simultaneously in the same PR, each UIS must be endowed with its own UIS Revision Number (UR), which accompanies how many instructions have been associated. to this specific UIS in earlier versions of a processor, as shown in Figure 2. A change of at least one UR implies updating the PR, as a change in the association between a UIS and an instruction will change the processor revision. _. An exception occurs when a UIS is first associated, in which case that there is no modification of PR. Finally, changing one UR never affects the other URs, which establishes an orthogonality to this approach.

Emulation Instruction Sequence

An instruction can only be removed if it is possible to find among the remaining architecture instructions an alternative sequence of instructions that can perform the first behavior. This task is handled by processor designers, and alternate sequences should be distributed to Operating System developers as emulation routines of the removed instruction.

Revision Vectors and Interrupt Mask

[26] Let the operator be an "exclusive OR" defined as follows:

A θ B = 0, if A = B

A θ B - 1, if A ≠ B (equation 1)

[27] And let the operator be defined as an "exclusive OR" between elements of the same position in different sets as follows:

X ® Y = {χθ,.,., Χη} ® {yO, ..., yn}

X ® Y = (xO Θ yO, ..., χ ^η Θ yn} (equation 2)

[28] Defining a Review Vector (RV) as the set of UR that uniquely identifies a PR, for a given PRx, its RVx is defined as:

RVx = {URO, URn} ^' (equation 3)

[29] Applying the operator (g) between two RVs results in the difference between each element. The result is called an Interrupt mask, or trap mask (TM):

TM {x, y} = RVx <¾ RVy

= {UR {x, 0}, UR {x, n}} <g) {UR {y, 0}, UR {y, n}}

= {UR {x, 0} Θ UR {y, 0}, {UR {x, n} Θ UR {y, n}}

(equation 4)

[30] Thus, TM {x, y} indicates the list of all instructions that need to be emulated when running SRx software on the PRy processor. The interrupt routine is responsible for providing the specific emulation routines. The better you choose which instructions to remove, the lower the overhead or extra cost of emulation routines. Figure 3 illustrates this process well.

Additional Settings

[31] The "+" (plus) operator is defined as a logical "OR" between two bits. Given two successive but non-sequential reviews of PRs, such as PRa and PRe, assuming PRb, PRc and PRd as the intermediate revisions, we define the Pack operator as:

Pack (PRa, PRe) - TM {a, e} + TB {b, e} + TM {c, e} + TM {d, e}

(equation 5)

[32] The modulo operator of set S, denoted by \ S \ indicates how many nonzero elements exist in set S.

Implementation - Active Review Vector

[33] For a PRi processor revision, all SRj software with j <i will require emulation support. A feasible implementation involves efficient support for Newer SRs and more costly support for older revisions. For this, the 4-bit Effective Review Index (ERI) is proposed, which encodes all supported revisions: current, previous 14, and all other collapses with the Pack operator. An ERI is an index for the Active Review Vector (ARV), where each element contains a direct connection to PR and RV. Thus, using an ERI to index an ARV element, we select the TM that the processor will use to generate the interrupts. All ERIs with older revisions are mapped to a single ARV element and the TM is calculated via the Pack operator. How this TM is the union of all old revisions and | Pack | is large (more instructions to emulate), this emulation will be more expensive. It is noteworthy that index the last 14 reviews. always reduces 1 TM 1 since only current PR and SR are relevant to the calculation and fewer instructions will need emulation.

[34] An example of this configuration is shown in Figure 4, where an SR5O program running on a PR60 processor implies an ERI = 60 - 50 = 10, ie the ARV indexing position 10: ARV [10], which corresponds to the mask TM50,60. If an SR40 version of a program runs on this processor, the calculated ERI will be ERI = 60 - 40 = 20. Since the ARV limit is 16 positions only, the effective result will be ERI = 15, which corresponds to the last ARV entry. : ARV [15]. The resulting masJf trap for ARV [15] will all be collapsed with the Pack operator: ΤΜ ^ ο, εο = Pack (PRo, PReo-i5 = 45), ie consolidate first revisions in one.

Statement emulation removed

[35] Once an unimplemented instruction needs to be executed, the processor will interrupt program execution by transferring control to the operating system, which will decode the instruction and, together with the corresponding SR, transfer control to " Emulation Instruction Sequence "for this instruction, as shown in Figure 5.

Hardware

[36] The processor hardware design must include enough information to decide when to emulate a no statement. For this, the processor must be aware of the currently running software version to compare against its own revision. One of several ways to implement this functionality is to create a specific instruction that tells the processor the version of the next instructions (instruction granularity). Another form is a virtual memory architecture that includes version information on each page (page granularity). Statement granularity implies the use of an extra statement to indicate that new code is about to be executed. Page granularity avoids having to include this new instruction for linking distinct pieces of software. Your schematic can be better observed from Figure 6.

Page Table Extension [37] To support page granularity, each page table entry must include the SR of its content in the form of ERI, along with the page protection bits. TLB (memory that stores a portion of the page table inside the processor to speed up program execution) also needs to store this information. Thus, the software tools needed to build a new program: compiler, assembler, and linker should indicate to the operating system module responsible for loading the programs in memory that it should allocate code with different ERI to different pages. Figure 7 illustrates software development flow and phases of the software review process.

Implementation in early processor stages

[38] Interrupt verification hardware should use the current ERI, read from TLB, and use the TM to identify instructions for which to generate interrupts. Check interrupts can be accomplished in two ways: first â uses every bit of TM to enable / disable interruption ^'to each affected instruction. This is the most flexible method and allows any kind of evolution, even non-sequential, of instruction generations, as currently occurs between Intel and AMD editions when creating new extensions. In the case of conflicting scenarios, both vendors can emulate each other's instructions through emulation mechanisms as described now. The second mechanism is more linear and considers only the values of the UR. Each UIS will have its URx: PRy to be compared with URx: SRy, generating an interrupt when the SR is older.

[39] In both cases, the extra hardware is proportional to the number of recycled UIS in all supported revisions. Neither mechanism makes the decoder smaller as it will still have to ^" recognize old instructions and generate an interrupt instead of transferring control to the microcode ROM. Still, it is still a considerable advantage to reduce the microcode ROM by removing implementations of hardware instructions and transferring them to software.

[40] In the case of out-of-order pipelines, an alternative mechanism is to check for interrupts only at statement commit time. In this case, despite the interruption delay, the verification process will go out of the critical processor path, allowing for simpler decoders. In either case, recycling old hardware instructions will yield benefits such as reducing microcode ROM, code compression, and reducing the number of misses in the instruction cache that outweigh the cost of additional hardware to make it possible.

Instruction Set Specialization for Specific Applications

[41] By carefully choosing a subset of instructions to create a new revision, you can dramatically reduce the processor-supported set, allowing the processor to enter markets where its current complexity is very high. Alternatively, it is also possible. add statements for specific domains, such as cryptographic statements, without having to include them in all family processors, simply by providing emulation libraries for OS providers.

Software

[42] The software part consists of the emulation layer that allows execution of the removed instructions, as well as changes to the following components: linkers, loaders and system calls. All of these components need to be aware of the code version to correctly update page table entries. The SR needs to be noted in the file containing the software, such as in the ELF or PE format header. All unnotated files should be considered SRO (Figure 7).

Connectors

[43] You must ensure that each module loads its version to the final executable file. If there is a difference between SR from two different modules, the linker needs to indicate that they should be allocated on different pages, each with its own SR. No different SR module should be placed together on the same page. To facilitate this process, intermediate files should also contain their assembler-generated SRs (Figure 7). Operating system and charger

[44] Recognizes SR information for each loadable segment present in the executable file and allocates memory pages with their respective SR. At this time, operating system memory page allocation routines should be expanded to contain the SR of the new page as the application may need to create new code pages instead of data pages. Finally, whenever an SR is required and one is not available, the operating system should assume the same as the current running version (Figure 7).

Emulation Routines

[45] Emulation routines provide the behavior of removed statements with a few restrictions. Emulation routines cannot use removed instructions and cannot emulate instructions that change the internal state of the processor or special characteristics such as atomicity that cannot be reproduced in software. The amount of these special instructions is limited in current instruction sets. Using as an example the instructions of Figure 2 for UIS 14h, assuming a software with UR (14h) = 2, indicating the implementation of the instruction VADD256 that performs the sum of two 256-bit vectors, running on a processor with UR (14h). = 3, indicating the VADD512 implementation that sums two 512-bit vectors, the VADD256 instruction emulation routine can be implemented using the VADD512 instruction itself leaving the upper 256 bits zero-value, yielding a result equivalent. Note that you may need to use more than one statement to supplement the correct behavior of the removed statement.

Claims

1. Method of removing instructions in a processor and executing legacy code comprising the steps of:

(a) creation of a new instruction;

(b) Removal of an old instruction;

(c) recycling of the corresponding unique instruction signature (UIS);

(d) Preparation for emulation of instruction removed in (b).

(e) Emulation of the statement removed in (b).

Method according to claim 1, characterized in that the step of preparing the emulation (d) comprises the following substeps:

(d3) Determine the Review Vector (RV) for a PR.

(d4) Determine interrupt masks (TM) for previous SRs in a PR.

(d5) Determine Effective Review Index (ERI).

(d6) Determine Active Review Vector (ARV).

Method according to claim 1, characterized in that the emulation step (e) comprises the following substeps:

(el) Verify that an SRi computer program is running on a PR processor, for i <j.

Method according to claim 1, characterized in that at least one UIS recycled in (c) implies updating the corresponding PR.

Method according to claim 1, characterized in that the "UR" UIS Revision (dl) indicates how many instructions were associated with the recycled UIS in previous versions of a processor.

Method according to claim 1, characterized in that an UR of one UIS never affects an UR of another UIS.

Method according to claim 1, characterized in that the "RV" Revision Vector (d3) is determined by the set of RUs that uniquely identify a PR (equation 3).

Method according to claim 1, characterized in that the "TM {x, y}" Interruption Mask (d4) is determined by the operation ® between two RVx and RVy Revision Vectors (equation '4).

Method according to claim 1, characterized in that TM {x, y} indicates the list of all instructions that need to be emulated when SRx software is executed on the PRy processor.

Method according to claim 1, characterized in that the Pack operator consists of the logical "OR" operation between two successive and non-sequential revisions, including intermediate revisions (equation 5).

Method according to claim 1, characterized in that the Effective Review Index "ERI" (d5) _. code all supported revisions on a given PR processor.

12. Method according to claim 1, characterized by an ERI "n" bits consist of an index for the active review vector "ARV" 2 ⁿ elements.

Method according to claim 1, characterized in that the ARV elements (d6) consist of the TM set of a PR processor, 1 being the current revision, (2 ⁿ -2) previous revisions, and the last element being other previous revisions collapsed with the Pack operator.

Method according to claim 1, characterized in that the substep (e5) of the emulation occurs in software through CPU interrupts in the execution of the program, and transfers control to the operating system.

Method according to claim 14, characterized in that the operating system decodes the instruction and, together with the corresponding SR, transfers control to the "Emulation Instruction Sequence" for that instruction.

16. A system for removing instructions in a processor and executing legacy code, comprising:

(a) Method according to any one of claims 1 to 15;

(b) Processor with structure for emulating an instruction.

System according to claim 16, characterized in that the processor identifies the version of the SR software running and compares it to its own revision PR.

System according to claim 17, characterized in that the identification of the SR is carried out by a virtual memory architecture that includes version information on each page or alternatively via specific instruction.

System according to claim 18, characterized in that each entry in the page table and the TLB includes the SR of its content in the form of ERI, together with the page protection bits.

System according to claim 16, characterized in that the interrupt checking hardware uses the current ERI and uses the TM to identify instructions for which interrupts are to be generated.

System according to claim 17, characterized in that the interrupt enable / disable is performed by each bit of the selected TM.

Use of the system as defined in claims 15 to 21, characterized in that it is for emulating instructions removed in versions of a processor.

Use of the system as defined in claims 15 to 21, characterized in that it is for reducing the instruction set supported by a processor.

Use of the system as defined in claims 15 to 21, characterized in that it is for emulating specific application instructions.