DEVICE, METHOD AND SYSTEM TO DETERMINE A MODE OF PROCESSOR OPERATION BASED ON PAGE TABLE METADATA

Techniques and mechanisms for a processor to determine an operational mode based on metadata for a page table. In an embodiment, an instruction fetch unit of the processor detects a pointer to a next instruction, in a sequence of instructions, which is to be prepared for execution with a core of the processor. Based on the pointer, a page table is identified as including an entry which indicates a location of the instruction. The page table includes, or otherwise corresponds to, metadata which comprises an identifier of an operational mode of the processor. Based on the metadata, the processor is transitioned to the operational mode in preparation for an execution of the instruction. In another embodiment, the operational mode is one of multiple operational modes which each correspond to a different instruction set architecture.

BACKGROUND

1. Technical Field

This disclosure generally relates to computer processors and more particularly, but not exclusively, to the selection of an operational mode of a processor.

2. Background Art

An instruction set, or instruction set architecture (ISA), is the part of the computer architecture related to programming, including the native data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input and output (I/O). It should be noted that the term “instruction” generally refers herein to macro-instructions—that is instructions that are provided to the processor for execution—as opposed to micro-instructions or micro-ops—that is the result of a processor's decoder decoding macro-instructions. The micro-instructions or micro-ops can be configured to instruct an execution unit on the processor to perform operations to implement the logic associated with the macro-instruction.

The ISA is distinguished from the microarchitecture, which is the set of processor design techniques used to implement the instruction set. Processors with different microarchitectures can share a common instruction set. For example, Intel® Pentium 4 processors, Intel® Core™ processors, and processors from Advanced Micro Devices, Inc. of Sunnyvale Calif. implement nearly identical versions of the x86 instruction set (with some extensions that have been added with newer versions), but have different internal designs. For example, the same register architecture of the ISA may be implemented in different ways in different microarchitectures using well-known techniques, including dedicated physical registers, one or more dynamically allocated physical registers using a register renaming mechanism (e.g., the use of a Register Alias Table (RAT), a Reorder Buffer (ROB) and a retirement register file). Unless otherwise specified, the phrases register architecture, register file, and register are used herein to refer to that which is visible to the software/programmer and the manner in which instructions specify registers. Where a distinction is required, the adjective “logical,” “architectural,” or “software visible” will be used to indicate registers/files in the register architecture, while different adjectives will be used to designate registers in a given microarchitecture (e.g., physical register, reorder buffer, retirement register, register pool).

An instruction set includes one or more instruction formats. A given instruction format defines various fields (number of bits, location of bits) to specify, among other things, the operation to be performed and the operand(s) on which that operation is to be performed. Some instruction formats are further broken down though the definition of instruction templates (or subformats). For example, the instruction templates of a given instruction format may be defined to have different subsets of the instruction format's fields (the included fields are typically in the same order, but at least some have different bit positions because there are less fields included) and/or defined to have a given field interpreted differently. A given instruction is expressed using a given instruction format (and, if defined, in a given one of the instruction templates of that instruction format) and specifies the operation and the operands. An instruction stream is a specific sequence of instructions, where each instruction in the sequence is an occurrence of an instruction in an instruction format (and, if defined, a given one of the instruction templates of that instruction format).

DETAILED DESCRIPTION

Embodiments discussed herein variously provide techniques and mechanisms for determining an operational mode of a processor based on metadata for a page table. The technologies described herein may be implemented in one or more electronic devices. Non-limiting examples of electronic devices that may utilize the technologies described herein include any kind of mobile device and/or stationary device, such as cameras, cell phones, computer terminals, desktop computers, electronic readers, facsimile machines, kiosks, laptop computers, netbook computers, notebook computers, internet devices, payment terminals, personal digital assistants, media players and/or recorders, servers (e.g., blade server, rack mount server, combinations thereof, etc.), set-top boxes, smart phones, tablet personal computers, ultra-mobile personal computers, wired telephones, combinations thereof, and the like. More generally, the technologies described herein may be employed in any of a variety of electronic devices including a processor which supports multiple modes of instruction execution.

Some existing processors, e.g., in certain x86 architectures and in certain ARM architectures, are variously (re)configurable each to provide, at different times, any one of a respective plurality of operational modes. For example, there are instances wherein, over time, a given instruction set architecture (ISA) is subjected to “retrofitting” which provides additional features and/or alternative features, such as a style of encoding, one or more new instructions, changes to behavioral properties of a given instruction, or the like. In x86 processors (for example), ISA evolution has trended toward longer and longer encoding sequences because relatively dense coding sequences are more likely to be already occupied, and all new encodings must be legacy compliant. Even more unfortunate, sometimes the densest instructions encodings have relatively low usefulness for newer types of software.

To accommodate ISA modifications (for example), some existing processors support different modes of execution including a mode which enables execution of instructions for one ISA, and another mode which enables execution of instructions for another ISA, such as an updated version of the one ISA (or alternatively, an entirely different ISA).

Furthermore, some existing processors are capable of executing relatively “high-power” instructions, such as wide single instruction multiple data (SIMD) instructions, certain types of floating point instructions, and instructions which utilize hardware offload engines. These high-power instructions have a power, voltage and/or frequency penalty associated with their execution. This is typically because the high power or current draw of such instructions cannot always be sustained at the same frequency, current, and/or voltage levels as that required for lower-power instructions. To accommodate a power-efficient execution of various types of instructions (for example), some existing processors additionally or alternatively support different modes of execution including a mode which includes or otherwise corresponds to a first power performance profile for one or more high-power instructions, and another mode which includes or otherwise corresponds to a second power performance profile for one or more low-power instructions.

However, transitioning a processor between different operational modes has, to-date, required an explicit software control—e.g., wherein a software instruction has an opcode and/or parameter which the processor recognizes as an explicit identifier of a particular operational mode to be implemented. For example, in x86, mode switches usually involve explicit “long” branches or “long” calls to switch from 64-bit mode to 32-bit mode and vice versa. In ARM, mode switches for regular and Thumb modes use specialized instructions, or specialized branches that were able to switch modes. This reliance on explicit software controls for operational mode transitions is problematic when one or more types of processors—and/or legacy software, for example—do not know how to manage or otherwise operate with a given one or more modes. Also, the use of various mode switch instructions, under current techniques, cause problems which, for example, relate to tracking processor state with out of order execution, requiring a pipeline flush, or the like. As a result, conventional processor mode management techniques are usually difficult to extend, have higher overhead, are not speculation proof, and/or are not transparent (for example).

FIG.1shows features of a device100to determine a mode of execution by a processor according to an embodiment. Device100illustrates one example of an embodiment wherein a processor comprises circuitry to access metadata for a page table, wherein the accessing is based on a next instruction in an instruction sequence. The metadata is used to determine an operational mode which is to be a basis for the execution of the next instruction.

As shown inFIG.1, device100comprises a processor125which (for example) includes a plurality of cores 0-N on which embodiments may be implemented. While only the details of a single core, Core 0, are shown, each of the other cores 1-N may include the same or a similar architecture as illustrated for Core 0. In other embodiments, processor125comprises only a single core.

In one embodiment, each core 0-N of the processor125includes a memory management unit190for performing memory operations such as load/store operations. In addition, each core 0-N includes a set of general purpose registers (GPRs)105, a set of vector registers106, and a set of mask registers107. In one embodiment, multiple vector data elements are packed into each vector register106which may have a 512 bit width for storing two 256 bit values, four 128 bit values, eight 64 bit values, sixteen 32 bit values, etc. However, the underlying principles of some embodiments are not limited to any particular size/type of vector data. In one embodiment, the mask registers107include eight 64-bit operand mask registers used for performing bit masking operations on the values stored in the vector registers106. However, the underlying principles of some embodiments are not limited to any particular mask register size/type. Furthermore, the illustrated connections between the components of Core 0 are merely illustrative, and other embodiments include more, fewer and/or different connections to variously facilitate signal communications within Core 0.

In one embodiment, each core may include a dedicated Level 1 (L1) cache112and Level 2 (L2) cache111for caching instructions and data according to a specified cache management policy. The L1 cache112includes a separate instruction cache120for storing instructions and a separate data cache121for storing data. The instructions and data stored within the various processor caches are managed at the granularity of cache lines which may be a fixed size (e.g., 64, 128, 512 Bytes in length). Each core of this exemplary embodiment has an instruction fetch unit110for fetching instructions from a main memory126and/or a shared Level 3 (L3) cache116; a decode unit130for decoding the instructions (e.g., decoding program instructions into micro-operations or “micro-operations”); an execution unit140for executing the instructions; and a writeback unit150for retiring the instructions and writing back the results. In another embodiment, device100omits, but accommodates coupling to and operation with, main memory126.

The instruction fetch unit110includes various well known components including a next instruction pointer (IP)103for storing the address of the next instruction to be fetched from memory126(or one of the caches); an instruction translation look-aside buffer (ITLB)104for storing a map of recently used virtual-to-physical instruction addresses to improve the speed of address translation; a branch prediction unit102for speculatively predicting instruction branch addresses; and branch target buffers (BTBs)101for storing branch addresses and target addresses. Once fetched, instructions are then streamed to the remaining stages of the instruction pipeline including the decode unit130, the execution unit140, and the writeback unit150. Various structures and functions of each of these units are adapted from conventional processor architectures, in some embodiments. Such conventional processor structures and functions are well understood by those of ordinary skill in the art, and will not be described here in detail to avoid obscuring pertinent aspects of different embodiments.

In the illustrated embodiment, the decode unit130includes operational mode selector unit108to implement the techniques described herein for dynamically selecting between a plurality of operational modes. While illustrated within the decode unit130inFIG.1, the operational mode selector108may be implemented within the execution unit140in an alternate embodiment (e.g., in the front end of the execution unit, prior to micro-operation execution). The underlying principles of some embodiments are not limited to any particular architectural location of the operational mode selector unit108.

In an illustrative scenario according to one embodiment, a given operational mode of Core 0 comprises a mode of decoding (or “decode mode”) of decoder130, and/or a mode of execution by execution unit140. By way of illustration and not limitation, one decode mode supports one or more instructions which are not supported by another of decode mode. Additionally or alternatively, a given two decode modes support different respective encodings to represent the same instruction. Additionally or alternatively, a given two decode modes map the same instruction to the same micro-operations, to be executed with by execution unit140with the same micro-operation controls. In other embodiments, a given two decode modes map the same instruction to the same micro-operations, but are to be executed by execution unit140with different micro-operation controls—e.g., in different execution modes of execution unit140. In still other embodiments, a given two decode modes map the same instruction to different respective micro-operations. In some embodiments, one of execution modes341, . . . ,342supports one or more micro-operation controls which are not supported in another of execution modes341, . . . ,342.

To efficiently determine a mode of execution for a processor (such as processor125), some embodiments variously provide, as metadata which is in—or otherwise corresponds to—a page table, an identifier of an operational mode which is to correspond to one or more instructions which are each associated with a respective entry of that page table. In response to an indication that one such instruction is a next instruction in a sequence of instructions, the metadata for the page table is accessed to determine which operational mode is identified by the metadata as corresponding to that instruction. Based on such accessing, the processor core in question is transitioned to the identified operational mode (if the core not already in said mode), and the instruction is subsequently executed based on said mode. In one such embodiment, the transition to the operational mode is performed independent of the instruction (or any other instruction in the sequence) explicitly identifying said operational mode. In some embodiments, the mode transition is relatively “lightweight,” as compared (for example) to one implemented, under existing techniques, by an explicit mode switch instruction. For example, the mode transition is performed with a multiplexer and/or any of various other types of circuitry which are suitable for selecting between different decoder circuits and/or between different execution circuits—e.g., without requiring a pipeline flush (for example) by the processor125.

By way of illustration and not limitation, a core of processor125(such as Core 0) comprises circuitry which is operable to access some or all of the one or more page tables160based on an indication of a next instruction to be prepared for execution. In one such embodiment, circuitry of the instruction fetch unit110accesses ITLB104based on the next instruction pointer103—e.g., wherein the circuitry performs a translation, search, or other suitable operation to identify a particular page table as including an entry which corresponds to the next instruction pointer103.

In various embodiments, such accessing of one or more page tables160includes reading metadata162of the identified page table to determine an operational mode identifier which corresponds to the instruction indicated by the next instruction pointer103. In one such embodiment, the operational mode selector unit108is coupled to receive or otherwise operate based on the operational mode identifier of metadata162—e.g., wherein mode selector unit108transitions execution unit140(and/or other circuitry of Core 0) to the identified operational mode. Subsequently, the instruction indicated by the next instruction pointer103is executed while Core 0 is in the operational mode which is identified by metadata162. In the example embodiment, the metadata162is in (and is descriptive of) a corresponding one of the one or more page tables160. However, in other embodiments, metadata162is provided at a mode register or other suitable resource which is external to, but associated with, the corresponding page table.

In providing an operational mode identifier as metadata which is included in or otherwise associated with a page table (e.g., wherein the mode identifier is in addition to, or “overlays,” code pages for various ISAs), some embodiments variously allow code-type information to accompany a code stream for efficient use during instruction decode, for example. Some embodiments thus facilitate a transition between operational modes without requiring explicit management by software. Accordingly, said embodiments variously facilitate the introduction of new modal features that are fully compatible with legacy code (e.g., program, libraries, etc.) and that can be overlayed and imposed on legacy code, if desired.

In an embodiment, an operational mode identifier is accessed as page table metadata which a processor accesses as part of operations which (for example) are to fetch and interpret code bytes for consumption by a decoder. In an embodiment, this additional metadata accompanies (e.g., is descriptive of, but is distinguished from) the instruction bytes. Furthermore, this additional metadata informs the decoder circuitry and/or execution unit circuitry of any new rules or other properties regarding instruction decoding and semantics—e.g., without having to implement heavyweight, serializing, global modes within the processor pipeline.

In various embodiments, an operational mode identifier is provided as page table metadata to serve as a lightweight code-type annotation that (for example) is speculation resistant and/or transparent. For example, in various embodiments, a sequence of instructions includes instructions which variously correspond to different page tables that each include a respective operational mode identifier as metadata. During an execution of such a sequence of instructions, various operational mode identifiers are successively determined by accessing the different page tables, which allows one or more mode transitions to occur transparently and safely—e.g., without polluting a binary with explicit instructions for mode switching. This allows for potentially radical encoding and/or semantic changes to be made to a given ISA (for example), while maintaining transparent interoperability with legacy code.

In some embodiments, the mode transition is specific to circuitry of one core—e.g., wherein the respective operational modes of one or more other cores of the processor remain the same. For example, the transition changes a mode of instruction decoding by a decoder unit of the core, and/or changes a mode of instruction execution by an execution unit of the core. Additionally or alternatively, the mode transition changes a power performance characteristic of the processor—e.g., including a power performance characteristic of at least the processor core in question. In one such embodiment, a mode transition occurs independent of any need to flush an execution pipeline of the core.

FIG.2shows features of a method200, which is performed with a processor, to configure an operational mode of the processor according to an embodiment. The method200illustrates one example of an embodiment wherein a processor determines, based on metadata associated with a page table, whether (or not) at least one core of the processor is to be transitioned to a particular operational mode. Operations such as those of method200are performed, for example, with some or all of device100. To illustrate certain features of various embodiments, method200is described herein with reference to operations by an example device300which is shown inFIG.3. However, in other embodiments, one or more operations of method200are performed with any of various other suitable devices which provide functionality described herein.

As shown inFIG.2, method200comprises (at210) receiving a pointer to an instruction which is one of multiple instructions in a sequence of instructions which are to be executed with the processor. For example,FIG.3shows features of a device300to execute an instruction based on an operational mode which is determined based on page table metadata according to an embodiment. As shown inFIG.3, a processor of device300comprises an instruction fetch unit310, a decoder unit330, an execution unit340, and a writeback unit350which—for example—provide functionality such as that of instruction fetch unit110, decode unit130, execution unit140, and writeback unit150(respectively). For example, an instruction cache320, an ITLB304of instruction fetch unit310, and a mode selector unit305of decoder unit330correspond functionally to instruction cache120, ITLB104, and mode selector unit108(respectively).

The processor is coupled to access page tables360which, for example, correspond functionally to the one or more page tables160of main memory126. By way of illustration and not limitation, a first page table370comprises one or more page table entries (PTEs)—such as the illustrative PTEs372a, . . . ,372xshown—which variously correspond each to a respective instruction or to respective data. The first page table370further comprises metadata (MD)371which includes an identifier of an operational mode that corresponds to some or all of the instructions which are indicated each by a respective one of PTEs372a, . . . ,372x. Alternatively or in addition, a second page table380comprises one or more other PTEs—such as the illustrative PTEs382a, . . . ,382yshown—which similarly correspond each to a respective instruction or to respective data. Page table380further comprises metadata (MD)381which includes an identifier of an operational mode that corresponds to some or all of the instructions which are indicated each by a respective one of PTEs382a, . . . ,382y.

In one such embodiment, the receiving at210comprises instruction fetch unit310receiving or otherwise identifying a next IP303in an IP sequence301—i.e., wherein IP sequence301is a sequence of instructions pointers which represents a corresponding sequence of instructions to be executed with the processor of device300. The next IP303specifies or otherwise indicates to instruction fetch unit310a location of a next instruction which is to be decoded and/or otherwise prepared for execution with the processor.

Referring again toFIG.2, method200further comprises (at212) identifying a page table—based on the pointer received at210—as comprising an entry which corresponds to the instruction. Based on the identifying at212, method200(at214) accesses metadata which is associated with (i.e., which is descriptive of and, in some embodiments, is included in) the page table to determine an operational mode of the processor. For example, in one illustrative embodiment, the identifying at212comprises instruction fetch unit310accessing page table370based on next IP303—e.g., based on a determination that one of PTEs372a, . . . ,372xcomprises information indicating a location of the instruction to which next IP303points. In one such embodiment, such accessing includes or is otherwise based on a use of the next IP303to search ITLB304—e.g., wherein the accessing includes operations adapted from conventional page table techniques. Based on a determination that a PTE of page table370(for example) corresponds to the instruction indicated by the next IP303, instruction fetch unit310accesses the metadata MD371of that page table370to read or otherwise determine an identifier of an operational mode which corresponds to the instruction in question. Although metadata371is shown as being external to page table entries372a, . . . ,372x, in other embodiments, an operational mode identifier is included in a PTE.

In an embodiment, page table metadata—e.g., MD371or MD372—comprises a field which, for example, includes n bits (where n is a positive integer) to identify any of 2npossible operational modes. Additionally or alternatively, such page table metadata comprises a bitmap field including bits which each correspond to a different respective functionality. For each such bit of the bitmap field, a value of the bit specifies whether the corresponding functionality is to be enabled or disabled—e.g., wherein multiple operational modes each comprise a different respective combination of enablement states for the various functionalities.

Referring again toFIG.2, method200further comprises (at216) transitioning the processor to the operational mode based on the accessing of the metadata at214. In some embodiments, the operational mode is that of merely one given core of the processor—e.g., wherein one or more other cores of the processor are each in a respective operational mode that is concurrent with and (for example) independent of the operational mode of that one given core. Accordingly, page table metadata in such embodiments variously facilitates a low overhead mechanism for indicating that a transient and/or non-global operational mode is to be implemented (for example) with one—e.g., only one—processor core. Such an indication is provided implicitly, in various embodiments—e.g., independent of the code stream in question and/or in a layered manner. In one such embodiment, a given page of code (based on metadata corresponding thereto) determines a mode of decoding by the one given core, which in turn affects other downstream operations of that core.

For example, the operational mode which is read from metadata371, based on the next IP303, is provided to a mode selector unit305of decoder unit330. The mode selector unit305includes, has access to, or is otherwise coupled to operate based on, information which corresponds various operational mode identifiers each with a different respective one or more configurations of decoder330and/or a different respective one or more configurations of execution unit340. By way of illustration and not limitation, a first configuration of decoder unit330implements a first decode mode331, wherein a second configuration of decoder unit330implements a second decode mode332. In some embodiments, decoder unit330is configurable to additionally or alternatively implement any of one or more other decode modes (not shown).

In an illustrative scenario according to one embodiment, decode mode331is to decode an instruction which is encoded according to a first instruction set architecture (ISA), wherein decode mode332is to decode an instruction which is encoded according to a second ISA. In one example embodiment, decode modes331,332support different respective encodings for a given instruction, but (for example) each support a common mapping of that instruction to the same micro-operations—e.g., wherein execution semantics and/or assembly-level notations for executing the instruction are to be the same. In some embodiments, the transitioning at216comprises mode selector unit305selecting one of the decode modes331, . . . ,332over the others of the decode modes331, . . . ,332—e.g., wherein such selection is based on MD371(or on other suitable metadata which is associated with page table PT370).

Alternatively or in addition, a first configuration of execution unit340implements a first execution mode341of execution unit340, wherein a second configuration of execution unit340implements a second execution mode342of execution unit340. In some embodiments, execution unit340is configurable to additionally or alternatively implement any of one or more other execution modes (not shown).

In an illustrative scenario according to one embodiment, operational mode341is to implement executions based on a first ISA, wherein operational mode342is to implement executions based on a second ISA. In another embodiment, operational mode341is to provide a first level of a power performance parameter, wherein operational mode342is to provide a second level of the same power performance parameter. By way of illustration and not limitation, the power performance parameter comprises a supply voltage parameter, a clock frequency parameter, and/or the like. In still another embodiment, operational mode341is to enable one or more security features, wherein operational mode342is to disable the one or more security features—e.g., wherein the one or more security features comprise an access permission, a speculative execution control and/or the like. In some embodiments, the transitioning at216additionally or alternatively comprises mode selector unit305providing to execution unit340a control signal336to select one of the execution modes341, . . . ,342over the others of the execution modes341, . . . ,342—e.g., wherein such selection is based on MD371(or on other suitable metadata which is associated with page table PT370). In one such embodiment, decoder unit330provides a decoded instruction334which is to be executed with execution unit340based on the operational mode of the processor.

Referring again toFIG.2, method200further comprises (at218) executing the instruction based on the operational mode, and (at220) committing a result of the executed instruction. In various embodiments, method200omits the committing at220—e.g., wherein an execution of the instruction at218results in an error, fault or other such event.

FIG.4shows features of a system400to identify an operational mode with page table metadata according to an embodiment. The system400illustrates one example of an embodiment wherein an output by code generation logic is used to determine that a page table is to provide metadata which identifies an operational mode as corresponding to one or more instructions in an instruction sequence. In various embodiments, system400facilitates functionality such as that of device100or method200—e.g., wherein one or more operations of method200are performed based on information provided with system400.

As shown inFIG.4, system400comprises a code generator410(for example, including a compiler, an assembler and/or other suitable logic) which is to provide information which is used to determine the provisioning of metadata for a page table. In one such embodiment, code generator410generates a file420which, for example, is compatible with an Executable and Linkable Format (ELF). By way of illustration and not limitation, file420comprises both a file header421, which identifies a format of file420, and a program header422which specifies or otherwise indicates the respective offsets, sizes, permissions and/or other relevant information for one or more segments in file420(such as the illustrative Segments A, B, . . . , N shown). Program header422, which is to be used for code execution, is provided to indicate to a kernel (or a runtime linker, for example) what is to be loaded into memory, a location of dynamic linking information, and/or the like.

In various embodiments, code generator410additionally or alternatively generates a file430which is also compatible with an ELF, for example. By way of illustration and not limitation, file430comprises a file header431which identifies a format of file430, and further comprises a section header432which specifies or otherwise indicates the respective offsets, sizes and/or other relevant information for one or more sections in file430(such as the illustrative Sections 1, 2, . . . , X shown). In an embodiment, the one or more sections each comprise respective information which is used to link a target object file for building an executable.

To facilitate a provisioning of metadata which is associated with a page table (wherein the metadata comprises an operational mode identifier), code generator410provides property information which is included in, or with, file420and/or file430. For example, in one such embodiment, property segment423of file420provides values M(a), M(b), . . . , M(n) which corresponds to segments A, B, . . . , N (respectively). For a given one of the values M(a), M(b), . . . , M(n), the value identifies a respective processor operational mode which is to be provided for any one or more instructions which are associated with the corresponding one of segments A, B, . . . , N. Alternatively or in addition, property segment433of file430provides values M(1), M(2), . . . , M(x) which corresponds to segments A, B, . . . , N (respectively). For a given one of the values M(1), M(2), . . . , M(x), the value identifies a respective processor operational mode which is to be provided for any one or more instructions which are associated with the corresponding one of sections 1, 2, . . . , X. In one such embodiment, at least two such operational modes each correspond to a different respective ISA—e.g., including two ISAs which are each defined or otherwise implemented with a respective one of the illustrative code pages461,462in a physical memory460.

In an illustrative embodiment, code generator410performs compiling, assembling and/or other suitable operations—based on input from a programmer—to generate one or each of files420,430, which are provided to a linker and loader440of system400. The linker and loader440comprises any of various suitable combinations of hardware and/or executing software logic to perform linking operations based on the information from code generator410, resulting in an output442which (for example) operates one or more application programming interfaces (APIs)450to load information which facilitates the execution of a sequence of instructions. In various embodiments, API(s)450include, for example, a mmap function of a Linux operating system (OS), a VirutalProtect function of a Windows OS, or the like.

In various embodiments, the API(s)450of system400are operated to variously place segments A, B, . . . , N into memory460at appropriate locations—e.g., with permissions and memory-types in accordance with application requirements. In one such embodiment, entries in page tables452are variously updated or otherwise accessed to indicate the respective locations of data and/or instructions in memory. Furthermore, mode registers454are accessed, in some embodiments, to facilitate the provisioning of metadata which is associated with a given one of page tables452.

By way of illustration and not limitation, a given mode register is accessed to store operational mode identifiers based on some or all of the values M(a), M(b), . . . , M(n) and/or based on some or all of the values M(1), M(2), . . . , M(x). In one such embodiment, the operational mode identifiers are available in the mode registers454as metadata which is associated with page tables452(e.g., wherein each such operational mode identifier is metadata for any instructions represented in an entry of a corresponding page table). Additionally or alternatively, providing the operational mode identifiers in the mode registers454results in the operational mode identifiers being further provided each as metadata at a corresponding one of page tables452(e.g., whereby each such operational mode identifier is associated with any instruction which is represented in an entry of the corresponding page table).

FIG.5shows features of a method500to executing instructions each based on a respective processor mode according to an embodiment. The method500illustrates one example of an embodiment wherein a processor performs multiple operational mode transitions each for a different respective one or more instructions of the same instruction sequence. Method500is performed, for example, with device100, device300, or system400—e.g., wherein method500comprises operations of method200.

As shown inFIG.5, method500comprises performing an evaluation (at510) to determine whether an instruction pointer (IP), for a next instruction of the instruction sequence, has been received or otherwise detected. For example, the evaluating at510is performed with instruction fetch unit110or instruction fetch unit310, in various embodiments.

Where it is determined at510that a next IP has been detected, method500(at512) performs a translation, ITLB lookup and/or any of various other suitable operations—based on the most recently detected IP—to identify a page table which corresponds to the IP. For example, the identifying comprises determining that the page table includes an entry which indicates a location from which the next instruction of the sequence is to be retrieved for decoding. Where it is instead determined at510that a next IP has yet to be detected, method500performs a next instance of the evaluating at510(e.g., until execution of the instruction sequence has completed, is interrupted, or otherwise ends).

After the page table is identified at512, method500(at514) retrieves the instruction which corresponds to—e.g., which is pointed to by—the IP which is most recently detected at510. In some embodiments, the instruction is retrieved from an instruction cache (for example), or is retrieved from a location indicated by an entry of the corresponding page table.

Method500further comprises (at516) accessing metadata for the page table which is most recently identified at512, and (at518) determining an operational mode identifier of the accessed metadata. For example, the accessing at516comprises reading an identifier of an operational mode of the processor—e.g., wherein the metadata defines or otherwise indicates a correspondence of the identified operational mode with any instructions which are represented by some or all entries of the page table. The metadata thus serves as an indication that execution of any such instructions is to be based on the identified operational mode.

Method500further comprises performing an evaluation (at520) to determine, based on the operational mode determined at518, whether the processor has to be transitioned from a current operational mode—i.e., including determining whether (or not) the processor is currently in the operational mode which is identified by the metadata accessed at516. Where it is determined at520that a mode transition of the processor is indicated, method500(at522) configures a decoder unit, an execution unit (execution unit140or execution unit340, for example) and/or other suitable circuitry of the processor to transition the processor from one operational mode to the different operational mode which is determined at518. In an embodiment, the operational mode is specific to one core of the processor (e.g., wherein the mode is concurrent with, and independent of, the currently configured operational mode of any other core of the processor). Subsequently (at524), method500executes the instruction based on the currently configured operational mode.

Where it is instead determined at520that no operational mode transition of the processor is indicated, method500simply performs the executing at524—i.e., without any operational mode transition such as that which is performed at522. After the executing of the instruction at524, method500performs a next instance of the evaluating at510—e.g., to facilitate providing a suitable operational mode for a next instruction of the instruction sequence.

FIGS.6A,6Bshow respective mode registers600,650which are to variously provide reference information for use in determining an operational mode of a processor according to an embodiment. In various embodiments, mode registers600,650are provided at a processor of device100, device300, or system400—e.g., wherein one or more operations of method200or method500are performed based on mode registers600,650.

As shown inFIG.6A, the illustrative 64-bit mode register600comprises eight page attribute (PAT) fields PAT0 through PAT7 which are variously available each to be programmed to configure a respective page table. For a given one of the fields PAT0 through PAT7, the field is available to receive a value which, according to an encoding scheme such as that illustrated in table610, identifies a particular memory type which is to be used for implementing the corresponding page table. By way of illustration and not limitation, mode register600has features such as those of the IA32_PAT mode set register which is in various x86 processor architectures from Intel Corporation of Santa Clara, CA.

As shown inFIG.6A, the illustrative 64-bit mode register650comprises eight code attribute table (CAT) fields CT0 through CT7 which each correspond (for example) to a respective one of fields PAT0 through PAT7 (or otherwise correspond each to a respective one or more page tables). For a given one of fields CT0 through CT7, the field is available be programmed to identify an operational mode which is to be associated with the corresponding one or more page tables. For example, a given one of the fields CT0 through CT7 receives a value which, according to an encoding scheme such as that illustrated in table660, identifies a particular operational mode which is to be associated with a given page table (and, for example, with one or more instructions—if any—which are represented in the page table).

In an illustrative scenario according to one embodiment, the respective fields PAT0 and CT0 of mode registers600,650each correspond to a first page table. The field PAT0 is programmed with a value which indicates a first memory type to be used for implementing the first page table. Furthermore, the field CT0 is programmed with a value which identifies a first operational mode as corresponding to some or all entries of the first page table. More particularly, the value of field CT0 indicates that, for one or more instructions (if any) which are represented each by a respective entry of the first page table, execution of the instruction with a given core of the processor is to take place while that core in the first operational mode. In one such embodiment, the field CT0 (or other metadata which describes entries of the first page table) is accessed based on a determination that an entry in the first page table includes information regarding a next instruction in an instruction sequence which is being executed with the processor. Based on such accessing, the processor is transitioned to the first operational mode (if it is not already in that first operational mode), and the instruction in question is subsequently executed based on said first operational mode.

Additionally or alternatively, the respective fields PAT1 and CT1 of mode registers600,650each correspond to a second page table. The field PAT1 is programmed with a value which indicates a second memory type to be used for implementing the second page table—e.g., wherein the field CT1 is programmed with a value which identifies a second operational mode as corresponding to some or all entries of the second page table. In one such embodiment, the field CT1 (or other metadata which describes entries of the second page table) is accessed based on a determination that an entry in the second page table includes information regarding a different next instruction in the instruction sequence. Based on such accessing, the processor is transitioned to the second operational mode (if it is not already in that second operational mode), and the instruction in question is subsequently executed based on said second operational mode.

In a similar way, fields PAT2 and CT2 each correspond to a third page table, fields PAT3 and CT3 each correspond to a fourth page table, and the like. As a result, some embodiments provide mode registers600,650to variously associate page tables (and instructions variously represented by entries of said page tables) each with a respective one of multiple available operational modes of the processor.

In the illustrative embodiment shown, the encoding scheme shown in table660enables an identification of a first operational mode which is to enable execution of an instruction in a first ISA (identified with the illustrative type label “x86”). Furthermore, the encoding scheme enables the additional or alternative identification of a second operational mode which is instead to enable execution of an instruction in a second ISA (identified with the illustrative type label “x86++”).

In various embodiments, an encoding such as that illustrated by table660enables a given one of fields CT0 through CT7 to be used for identifying any of multiple operational modes which each support a different respective ISA. In one such embodiment, a first operational mode supports a first ISA, wherein a second operational mode supports a second ISA which (for example) is an updated or otherwise modified version of the first ISA. By way of illustration and not limitation, the second ISA includes additional encodings which are not available in the first ISA (e.g., including encodings for new instructions not supported by the first ISA). Alternatively or in addition, the second ISA includes a modified version of one or more encodings of the first ISA, and/or deprecates or repurposes one or more other encodings of the first ISA (e.g., for instructions which are no longer legal).

In some embodiments, the multiple operational modes additionally or alternatively include a mode which supports one type of instruction execution for a given ISA, and another mode which supports an alternative type of instruction execution for that same ISA. Such modes implement different respective timing features, power performance features, security based features and/or the like, but share the instruction semantics (for example) of the same ISA. In one such embodiment, a mode provides relatively enhanced security (as compared to another mode) by disabling or otherwise restricting one or more micro-architectural optimizations—e.g., in order to prevent side channel observations of the executing code.

FIG.7illustrates an exemplary system. Multiprocessor system700is a point-to-point interconnect system and includes a plurality of processors including a first processor770and a second processor780coupled via a point-to-point interconnect750. In some examples, the first processor770and the second processor780are homogeneous. In some examples, first processor770and the second processor780are heterogenous. Though the exemplary system700is shown to have two processors, the system may have three or more processors, or may be a single processor system.

Processors770and780are shown including integrated memory controller (IMC) circuitry772and782, respectively. Processor770also includes as part of its interconnect controller point-to-point (P-P) interfaces776and778; similarly, second processor780includes P-P interfaces786and788. Processors770,780may exchange information via the point-to-point (P-P) interconnect750using P-P interface circuits778,788. IMCs772and782couple the processors770,780to respective memories, namely a memory732and a memory734, which may be portions of main memory locally attached to the respective processors.

Processors770,780may each exchange information with a chipset790via individual P-P interconnects752,754using point to point interface circuits776,794,786,798. Chipset790may optionally exchange information with a coprocessor738via an interface792. In some examples, the coprocessor738is a special-purpose processor, such as, for example, a high-throughput processor, a network or communication processor, compression engine, graphics processor, general purpose graphics processing unit (GPGPU), neural-network processing unit (NPU), embedded processor, or the like.

Chipset790may be coupled to a first interconnect716via an interface796. In some examples, first interconnect716may be a Peripheral Component Interconnect (PCI) interconnect, or an interconnect such as a PCI Express interconnect or another I/O interconnect. In some examples, one of the interconnects couples to a power control unit (PCU)717, which may include circuitry, software, and/or firmware to perform power management operations with regard to the processors770,780and/or co-processor738. PCU717provides control information to a voltage regulator (not shown) to cause the voltage regulator to generate the appropriate regulated voltage. PCU717also provides control information to control the operating voltage generated. In various examples, PCU717may include a variety of power management logic units (circuitry) to perform hardware-based power management. Such power management may be wholly processor controlled (e.g., by various processor hardware, and which may be triggered by workload and/or power, thermal or other processor constraints) and/or the power management may be performed responsive to external sources (such as a platform or power management source or system software).

PCU717is illustrated as being present as logic separate from the processor770and/or processor780. In other cases, PCU717may execute on a given one or more of cores (not shown) of processor770or780. In some cases, PCU717may be implemented as a microcontroller (dedicated or general-purpose) or other control logic configured to execute its own dedicated power management code, sometimes referred to as P-code. In yet other examples, power management operations to be performed by PCU717may be implemented externally to a processor, such as by way of a separate power management integrated circuit (PMIC) or another component external to the processor. In yet other examples, power management operations to be performed by PCU717may be implemented within BIOS or other system software.

Various I/O devices714may be coupled to first interconnect716, along with a bus bridge718which couples first interconnect716to a second interconnect720. In some examples, one or more additional processor(s)715, such as coprocessors, high-throughput many integrated core (MIC) processors, GPGPUs, accelerators (such as graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays (FPGAs), or any other processor, are coupled to first interconnect716. In some examples, second interconnect720may be a low pin count (LPC) interconnect. Various devices may be coupled to second interconnect720including, for example, a keyboard and/or mouse722, communication devices727and a storage circuitry728. Storage circuitry728may be one or more non-transitory machine-readable storage media as described below, such as a disk drive or other mass storage device which may include instructions/code and data730in some examples. Further, an audio I/O724may be coupled to second interconnect720. Note that other architectures than the point-to-point architecture described above are possible. For example, instead of the point-to-point architecture, a system such as multiprocessor system700may implement a multi-drop interconnect or other such architecture.

FIG.8illustrates a block diagram of an example processor800that may have more than one core and an integrated memory controller. The solid lined boxes illustrate a processor800with a single core802A, a system agent unit circuitry810, a set of one or more interconnect controller unit(s) circuitry816, while the optional addition of the dashed lined boxes illustrates an alternative processor800with multiple cores802A-N, a set of one or more integrated memory controller unit(s) circuitry814in the system agent unit circuitry810, and special purpose logic808, as well as a set of one or more interconnect controller units circuitry816. Note that the processor800may be one of the processors770or780, or co-processor738or715ofFIG.7.

A memory hierarchy includes one or more levels of cache unit(s) circuitry804A-N within the cores802A-N, a set of one or more shared cache unit(s) circuitry806, and external memory (not shown) coupled to the set of integrated memory controller unit(s) circuitry814. The set of one or more shared cache unit(s) circuitry806may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, such as a last level cache (LLC), and/or combinations thereof. While in some examples ring-based interconnect network circuitry812interconnects the special purpose logic808(e.g., integrated graphics logic), the set of shared cache unit(s) circuitry806, and the system agent unit circuitry810, alternative examples use any number of well-known techniques for interconnecting such units. In some examples, coherency is maintained between one or more of the shared cache unit(s) circuitry806and cores802A-N.

In some examples, one or more of the cores802A-N are capable of multi-threading. The system agent unit circuitry810includes those components coordinating and operating cores802A-N. The system agent unit circuitry810may include, for example, power control unit (PCU) circuitry and/or display unit circuitry (not shown). The PCU may be or may include logic and components needed for regulating the power state of the cores802A-N and/or the special purpose logic808(e.g., integrated graphics logic). The display unit circuitry is for driving one or more externally connected displays.

The cores802A-N may be homogenous in terms of instruction set architecture (ISA). Alternatively, the cores802A-N may be heterogeneous in terms of ISA; that is, a subset of the cores802A-N may be capable of executing an ISA, while other cores may be capable of executing only a subset of that ISA or another ISA.

Exemplary Core Architectures—In-Order and Out-of-Order Core Block Diagram

InFIG.9A, a processor pipeline900includes a fetch stage902, an optional length decoding stage904, a decode stage906, an optional allocation (Alloc) stage908, an optional renaming stage910, a schedule (also known as a dispatch or issue) stage912, an optional register read/memory read stage914, an execute stage916, a write back/memory write stage918, an optional exception handling stage922, and an optional commit stage924. One or more operations can be performed in each of these processor pipeline stages. For example, during the fetch stage902, one or more instructions are fetched from instruction memory, and during the decode stage906, the one or more fetched instructions may be decoded, addresses (e.g., load store unit (LSU) addresses) using forwarded register ports may be generated, and branch forwarding (e.g., immediate offset or a link register (LR)) may be performed. In one example, the decode stage906and the register read/memory read stage914may be combined into one pipeline stage. In one example, during the execute stage916, the decoded instructions may be executed, LSU address/data pipelining to an Advanced Microcontroller Bus (AMB) interface may be performed, multiply and add operations may be performed, arithmetic operations with branch results may be performed, etc.

By way of example, the exemplary register renaming, out-of-order issue/execution architecture core ofFIG.9Bmay implement the pipeline900as follows: 1) the instruction fetch circuitry938performs the fetch and length decoding stages902and904; 2) the decode circuitry940performs the decode stage906; 3) the rename/allocator unit circuitry952performs the allocation stage908and renaming stage910; 4) the scheduler(s) circuitry956performs the schedule stage912; 5) the physical register file(s) circuitry958and the memory unit circuitry970perform the register read/memory read stage914; the execution cluster(s)960perform the execute stage916; 6) the memory unit circuitry970and the physical register file(s) circuitry958perform the write back/memory write stage918; 7) various circuitry may be involved in the exception handling stage922; and 8) the retirement unit circuitry954and the physical register file(s) circuitry958perform the commit stage924.

FIG.9Bshows a processor core990including front-end unit circuitry930coupled to an execution engine unit circuitry950, and both are coupled to a memory unit circuitry970. The core990may be a reduced instruction set architecture computing (RISC) core, a complex instruction set architecture computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core990may be a special-purpose core, such as, for example, a network or communication core, compression engine, coprocessor core, general purpose computing graphics processing unit (GPGPU) core, graphics core, or the like.

The front end unit circuitry930may include branch prediction circuitry932coupled to an instruction cache circuitry934, which is coupled to an instruction translation lookaside buffer (TLB)936, which is coupled to instruction fetch circuitry938, which is coupled to decode circuitry940. In one example, the instruction cache circuitry934is included in the memory unit circuitry970rather than the front-end circuitry930. The decode circuitry940(or decoder) may decode instructions, and generate as an output one or more micro-operations, micro-code entry points, microinstructions, other instructions, or other control signals, which are decoded from, or which otherwise reflect, or are derived from, the original instructions. The decode circuitry940may further include an address generation unit (AGU, not shown) circuitry. In one example, the AGU generates an LSU address using forwarded register ports, and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decode circuitry940may be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read only memories (ROMs), etc. In one example, the core990includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in decode circuitry940or otherwise within the front end circuitry930). In one example, the decode circuitry940includes a micro-operation (micro-op) or operation cache (not shown) to hold/cache decoded operations, micro-tags, or micro-operations generated during the decode or other stages of the processor pipeline900. The decode circuitry940may be coupled to rename/allocator unit circuitry952in the execution engine circuitry950.

The execution engine circuitry950includes the rename/allocator unit circuitry952coupled to a retirement unit circuitry954and a set of one or more scheduler(s) circuitry956. The scheduler(s) circuitry956represents any number of different schedulers, including reservations stations, central instruction window, etc. In some examples, the scheduler(s) circuitry956can include arithmetic logic unit (ALU) scheduler/scheduling circuitry, ALU queues, arithmetic generation unit (AGU) scheduler/scheduling circuitry, AGU queues, etc. The scheduler(s) circuitry956is coupled to the physical register file(s) circuitry958. Each of the physical register file(s) circuitry958represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating-point, packed integer, packed floating-point, vector integer, vector floating-point, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc. In one example, the physical register file(s) circuitry958includes vector registers unit circuitry, writemask registers unit circuitry, and scalar register unit circuitry. These register units may provide architectural vector registers, vector mask registers, general-purpose registers, etc. The physical register file(s) circuitry958is coupled to the retirement unit circuitry954(also known as a retire queue or a retirement queue) to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) (ROB(s)) and a retirement register file(s); using a future file(s), a history buffer(s), and a retirement register file(s); using a register maps and a pool of registers; etc.). The retirement unit circuitry954and the physical register file(s) circuitry958are coupled to the execution cluster(s)960. The execution cluster(s)960includes a set of one or more execution unit(s) circuitry962and a set of one or more memory access circuitry964. The execution unit(s) circuitry962may perform various arithmetic, logic, floating-point or other types of operations (e.g., shifts, addition, subtraction, multiplication) and on various types of data (e.g., scalar integer, scalar floating-point, packed integer, packed floating-point, vector integer, vector floating-point). While some examples may include a number of execution units or execution unit circuitry dedicated to specific functions or sets of functions, other examples may include only one execution unit circuitry or multiple execution units/execution unit circuitry that all perform all functions. The scheduler(s) circuitry956, physical register file(s) circuitry958, and execution cluster(s)960are shown as being possibly plural because certain examples create separate pipelines for certain types of data/operations (e.g., a scalar integer pipeline, a scalar floating-point/packed integer/packed floating-point/vector integer/vector floating-point pipeline, and/or a memory access pipeline that each have their own scheduler circuitry, physical register file(s) circuitry, and/or execution cluster—and in the case of a separate memory access pipeline, certain examples are implemented in which only the execution cluster of this pipeline has the memory access unit(s) circuitry964). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the rest in-order.

In some examples, the execution engine unit circuitry950may perform load store unit (LSU) address/data pipelining to an Advanced Microcontroller Bus (AMB) interface (not shown), and address phase and writeback, data phase load, store, and branches.

The set of memory access circuitry964is coupled to the memory unit circuitry970, which includes data TLB circuitry972coupled to a data cache circuitry974coupled to a level 2 (L2) cache circuitry976. In one exemplary example, the memory access circuitry964may include a load unit circuitry, a store address unit circuit, and a store data unit circuitry, each of which is coupled to the data TLB circuitry972in the memory unit circuitry970. The instruction cache circuitry934is further coupled to the level 2 (L2) cache circuitry976in the memory unit circuitry970. In one example, the instruction cache934and the data cache974are combined into a single instruction and data cache (not shown) in L2 cache circuitry976, a level 3 (L3) cache circuitry (not shown), and/or main memory. The L2 cache circuitry976is coupled to one or more other levels of cache and eventually to a main memory.

The core990may support one or more instructions sets (e.g., the x86 instruction set architecture (optionally with some extensions that have been added with newer versions); the MIPS instruction set architecture; the ARM instruction set architecture (optionally with optional additional extensions such as NEON)), including the instruction(s) described herein. In one example, the core990includes logic to support a packed data instruction set architecture extension (e.g., AVX1, AVX2), thereby allowing the operations used by many multimedia applications to be performed using packed data.

FIG.10illustrates examples of execution unit(s) circuitry, such as execution unit(s) circuitry962ofFIG.9B. As illustrated, execution unit(s) circuitry962may include one or more ALU circuits1001, optional vector/single instruction multiple data (SIMD) circuits1003, load/store circuits1005, branch/jump circuits1007, and/or Floating-point unit (FPU) circuits1009. ALU circuits1001perform integer arithmetic and/or Boolean operations. Vector/SIMD circuits1003perform vector/SIMD operations on packed data (such as SIMD/vector registers). Load/store circuits1005execute load and store instructions to load data from memory into registers or store from registers to memory. Load/store circuits1005may also generate addresses. Branch/jump circuits1007cause a branch or jump to a memory address depending on the instruction. FPU circuits1009perform floating-point arithmetic. The width of the execution unit(s) circuitry962varies depending upon the example and can range from 16-bit to 1,024-bit, for example. In some examples, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit).

Exemplary Register Architecture

FIG.11is a block diagram of a register architecture1100according to some examples. As illustrated, the register architecture1100includes vector/SIMD registers1110that vary from 128-bit to 1,024 bits width. In some examples, the vector/SIMD registers1110are physically 512-bits and, depending upon the mapping, only some of the lower bits are used. For example, in some examples, the vector/SIMD registers1110are ZMM registers which are 512 bits: the lower 256 bits are used for YMM registers and the lower 128 bits are used for XMM registers. As such, there is an overlay of registers. In some examples, a vector length field selects between a maximum length and one or more other shorter lengths, where each such shorter length is half the length of the preceding length. Scalar operations are operations performed on the lowest order data element position in a ZMM/YMM/XMM register; the higher order data element positions are either left the same as they were prior to the instruction or zeroed depending on the example.

In some examples, the register architecture1100includes writemask/predicate registers1115. For example, in some examples, there are 8 writemask/predicate registers (sometimes called k0 through k7) that are each 16-bit, 32-bit, 64-bit, or 128-bit in size. Writemask/predicate registers1115may allow for merging (e.g., allowing any set of elements in the destination to be protected from updates during the execution of any operation) and/or zeroing (e.g., zeroing vector masks allow any set of elements in the destination to be zeroed during the execution of any operation). In some examples, each data element position in a given writemask/predicate register1115corresponds to a data element position of the destination. In other examples, the writemask/predicate registers1115are scalable and consists of a set number of enable bits for a given vector element (e.g., 8 enable bits per 64-bit vector element).

The register architecture1100includes a plurality of general-purpose registers1125. These registers may be 16-bit, 32-bit, 64-bit, etc. and can be used for scalar operations. In some examples, these registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

In some examples, the register architecture1100includes scalar floating-point (FP) register1145which is used for scalar floating-point operations on 32/64/80-bit floating-point data using the x87 instruction set architecture extension or as MMX registers to perform operations on 64-bit packed integer data, as well as to hold operands for some operations performed between the MMX and XMM registers.

One or more flag registers1140(e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, compare, and system operations. For example, the one or more flag registers1140may store condition code information such as carry, parity, auxiliary carry, zero, sign, and overflow. In some examples, the one or more flag registers1140are called program status and control registers.

Segment registers1120contain segment points for use in accessing memory. In some examples, these registers are referenced by the names CS, DS, SS, ES, FS, and GS.

Machine specific registers (MSRs)1135control and report on processor performance. Most MSRs1135handle system-related functions and are not accessible to an application program. Machine check registers1160consist of control, status, and error reporting MSRs that are used to detect and report on hardware errors.

One or more instruction pointer register(s)1130store an instruction pointer value. Control register(s)1155(e.g., CR0-CR4) determine the operating mode of a processor (e.g., processor770,780,738,715, and/or800) and the characteristics of a currently executing task. Debug registers1150control and allow for the monitoring of a processor or core's debugging operations.

Memory (mem) management registers1165specify the locations of data structures used in protected mode memory management. These registers may include a GDTR, IDRT, task register, and a LDTR register.

Alternative examples may use wider or narrower registers. Additionally, alternative examples may use more, less, or different register files and registers. The register architecture1100may, for example, be used in physical register file(s) circuitry958.

Instruction Set Architectures.

FIG.12illustrates examples of an instruction format. As illustrated, an instruction may include multiple components including, but not limited to, one or more fields for: one or more prefixes1201, an opcode1203, addressing information1205(e.g., register identifiers, memory addressing information, etc.), a displacement value1207, and/or an immediate value1209. Note that some instructions utilize some or all of the fields of the format whereas others may only use the field for the opcode1203. In some examples, the order illustrated is the order in which these fields are to be encoded, however, it should be appreciated that in other examples these fields may be encoded in a different order, combined, etc.

The prefix(es) field(s)1201, when used, modifies an instruction. In some examples, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), to provide section overrides (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), to perform bus lock operations, and/or to change operand (e.g., 0x66) and address sizes (e.g., 0x67). Certain instructions require a mandatory prefix (e.g., 0x66, 0xF2, 0xF3, etc.). Certain of these prefixes may be considered “legacy” prefixes. Other prefixes, one or more examples of which are detailed herein, indicate, and/or provide further capability, such as specifying particular registers, etc. The other prefixes typically follow the “legacy” prefixes.

The opcode field1203is used to at least partially define the operation to be performed upon a decoding of the instruction. In some examples, a primary opcode encoded in the opcode field1203is one, two, or three bytes in length. In other examples, a primary opcode can be a different length. An additional 3-bit opcode field is sometimes encoded in another field.

The addressing field1205is used to address one or more operands of the instruction, such as a location in memory or one or more registers.FIG.13illustrates examples of the addressing field1205. In this illustration, an optional ModR/M byte1302and an optional Scale, Index, Base (SIB) byte1304are shown. The ModR/M byte1302and the SIB byte1304are used to encode up to two operands of an instruction, each of which is a direct register or effective memory address. Note that each of these fields are optional in that not all instructions include one or more of these fields. The MOD R/M byte1302includes a MOD field1342, a register (reg) field1344, and R/M field1346.

The content of the MOD field1342distinguishes between memory access and non-memory access modes. In some examples, when the MOD field1342has a binary value of 11 (11b), a register-direct addressing mode is utilized, and otherwise register-indirect addressing is used.

The register field1344may encode either the destination register operand or a source register operand, or may encode an opcode extension and not be used to encode any instruction operand. The content of register index field1344, directly or through address generation, specifies the locations of a source or destination operand (either in a register or in memory). In some examples, the register field1344is supplemented with an additional bit from a prefix (e.g., prefix1201) to allow for greater addressing.

The R/M field1346may be used to encode an instruction operand that references a memory address or may be used to encode either the destination register operand or a source register operand. Note the R/M field1346may be combined with the MOD field1342to dictate an addressing mode in some examples.

The SIB byte1304includes a scale field1352, an index field1354, and a base field1356to be used in the generation of an address. The scale field1352indicates scaling factor. The index field1354specifies an index register to use. In some examples, the index field1354is supplemented with an additional bit from a prefix (e.g., prefix1201) to allow for greater addressing. The base field1356specifies a base register to use. In some examples, the base field1356is supplemented with an additional bit from a prefix (e.g., prefix1201) to allow for greater addressing. In practice, the content of the scale field1352allows for the scaling of the content of the index field1354for memory address generation (e.g., for address generation that uses 2scale*index+base).

Some addressing forms utilize a displacement value to generate a memory address. For example, a memory address may be generated according to 2scale*index+base+displacement, index*scale+displacement, r/m+displacement, instruction pointer (RIP/EIP)+displacement, register+displacement, etc. The displacement may be a 1-byte, 2-byte, 4-byte, etc. value. In some examples, a displacement1207provides this value. Additionally, in some examples, a displacement factor usage is encoded in the MOD field of the addressing field1205that indicates a compressed displacement scheme for which a displacement value is calculated and stored in the displacement field1207.

In some examples, an immediate field1209specifies an immediate value for the instruction. An immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, etc.

FIG.14illustrates examples of a first prefix1201(A). In some examples, the first prefix1201(A) is an example of a REX prefix. Instructions that use this prefix may specify general purpose registers, 64-bit packed data registers (e.g., single instruction, multiple data (SIMD) registers or vector registers), and/or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

Instructions using the first prefix1201(A) may specify up to three registers using 3-bit fields depending on the format: 1) using the reg field1344and the R/M field1346of the Mod R/M byte1302; 2) using the Mod R/M byte1302with the SIB byte1304including using the reg field1344and the base field1356and index field1354; or 3) using the register field of an opcode.

In the first prefix1201(A), bit positions 7:4 are set as0100. Bit position 3 (W) can be used to determine the operand size but may not solely determine operand width. As such, when W=0, the operand size is determined by a code segment descriptor (CS.D) and when W=1, the operand size is 64-bit.

Note that the addition of another bit allows for 16 (24) registers to be addressed, whereas the MOD R/M reg field1344and MOD R/M R/M field1346alone can each only address 8 registers.

In the first prefix1201(A), bit position 2 (R) may be an extension of the MOD R/M reg field1344and may be used to modify the ModR/M reg field1344when that field encodes a general-purpose register, a 64-bit packed data register (e.g., a SSE register), or a control or debug register. R is ignored when Mod R/M byte1302specifies other registers or defines an extended opcode.

Bit position 1 (X) may modify the SIB byte index field1354.

Bit position 0 (B) may modify the base in the Mod R/M R/M field1346or the SIB byte base field1356; or it may modify the opcode register field used for accessing general purpose registers (e.g., general purpose registers1125).

FIGS.15A-Dillustrate examples of how the R, X, and B fields of the first prefix1201(A) are used.FIG.15Aillustrates R and B from the first prefix1201(A) being used to extend the reg field1344and R/M field1346of the MOD R/M byte1302when the SIB byte1304is not used for memory addressing.FIG.15Billustrates R and B from the first prefix1201(A) being used to extend the reg field1344and R/M field1346of the MOD R/M byte1302when the SIB byte1304is not used (register-register addressing).FIG.15Cillustrates R, X, and B from the first prefix1201(A) being used to extend the reg field1344of the MOD R/M byte1302and the index field1354and base field1356when the SIB byte1304being used for memory addressing.FIG.15Dillustrates B from the first prefix1201(A) being used to extend the reg field1344of the MOD R/M byte1302when a register is encoded in the opcode1203.

FIGS.16A-Billustrate examples of a second prefix1201(B). In some examples, the second prefix1201(B) is an example of a VEX prefix. The second prefix1201(B) encoding allows instructions to have more than two operands, and allows SIMD vector registers (e.g., vector/SIMD registers1110) to be longer than 64-bits (e.g., 128-bit and 256-bit). The use of the second prefix1201(B) provides for three-operand (or more) syntax. For example, previous two-operand instructions performed operations such as A=A+B, which overwrites a source operand. The use of the second prefix1201(B) enables operands to perform nondestructive operations such as A=B+C.

In some examples, the second prefix1201(B) comes in two forms—a two-byte form and a three-byte form. The two-byte second prefix1201(B) is used mainly for 128-bit, scalar, and some 256-bit instructions; while the three-byte second prefix1201(B) provides a compact replacement of the first prefix1201(A) and 3-byte opcode instructions.

FIG.16Aillustrates examples of a two-byte form of the second prefix1201(B). In one example, a format field1601(byte 01603) contains the value C5H. In one example, byte 11605includes a “R” value in bit[7]. This value is the complement of the “R” value of the first prefix1201(A). Bit[2] is used to dictate the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector and a value of 1 is a 256-bit vector). Bits[1:0] provide opcode extensionality equivalent to some legacy prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits[6:3] shown as vvvv may be used to: 1) encode the first source register operand, specified in inverted (is complement) form and valid for instructions with 2 or more source operands; 2) encode the destination register operand, specified in 1 s complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a certain value, such as1111b.

Instructions that use this prefix may use the Mod R/M R/M field1346to encode the instruction operand that references a memory address or encode either the destination register operand or a source register operand.

Instructions that use this prefix may use the Mod R/M reg field1344to encode either the destination register operand or a source register operand, be treated as an opcode extension and not used to encode any instruction operand.

For instruction syntax that support four operands, vvvv, the Mod R/M R/M field1346and the Mod R/M reg field1344encode three of the four operands. Bits[7:4] of the immediate1209are then used to encode the third source register operand.

FIG.16Billustrates examples of a three-byte form of the second prefix1201(B). In one example, a format field1611(byte 01613) contains the value C4H. Byte 11615includes in bits[7:5] “R,” “X,” and “B” which are the complements of the same values of the first prefix1201(A). Bits[4:0] of byte 11615(shown as mmmmm) include content to encode, as need, one or more implied leading opcode bytes. For example, 00001 implies a OFH leading opcode, 00010 implies a 0F38H leading opcode, 00011 implies a leading OF3AH opcode, etc.

Bit[7] of byte 21617is used similar to W of the first prefix1201(A) including helping to determine promotable operand sizes. Bit[2] is used to dictate the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector and a value of 1 is a 256-bit vector). Bits[1:0] provide opcode extensionality equivalent to some legacy prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits[6:3], shown as vvvv, may be used to: 1) encode the first source register operand, specified in inverted (is complement) form and valid for instructions with 2 or more source operands; 2) encode the destination register operand, specified in is complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a certain value, such as1111b.

Instructions that use this prefix may use the Mod R/M R/M field1346to encode the instruction operand that references a memory address or encode either the destination register operand or a source register operand.

Instructions that use this prefix may use the Mod R/M reg field1344to encode either the destination register operand or a source register operand, be treated as an opcode extension and not used to encode any instruction operand.

For instruction syntax that support four operands, vvvv, the Mod R/M R/M field1346, and the Mod R/M reg field1344encode three of the four operands. Bits[7:4] of the immediate1209are then used to encode the third source register operand.

FIG.17illustrates examples of a third prefix1201(C). In some examples, the first prefix1201(A) is an example of an EVEX prefix. The third prefix1201(C) is a four-byte prefix.

The third prefix1201(C) can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some examples, instructions that utilize a writemask/opmask (see discussion of registers in a previous figure, such asFIG.11) or predication utilize this prefix. Opmask register allow for conditional processing or selection control. Opmask instructions, whose source/destination operands are opmask registers and treat the content of an opmask register as a single value, are encoded using the second prefix1201(B).

The third prefix1201(C) may encode functionality that is specific to instruction classes (e.g., a packed instruction with “load+op” semantic can support embedded broadcast functionality, a floating-point instruction with rounding semantic can support static rounding functionality, a floating-point instruction with non-rounding arithmetic semantic can support “suppress all exceptions” functionality, etc.).

The first byte of the third prefix1201(C) is a format field1711that has a value, in one example, of62H. Subsequent bytes are referred to as payload bytes1715-1719and collectively form a 24-bit value of P[23:0] providing specific capability in the form of one or more fields (detailed herein).

In some examples, P[1:0] of payload byte1719are identical to the low two mmmmm bits. P[3:2] are reserved in some examples. Bit P[4] (R′) allows access to the high 16 vector register set when combined with P[7] and the ModR/M reg field1344. P[6] can also provide access to a high 16 vector register when SIB-type addressing is not needed. P[7:5] consist of an R, X, and B which are operand specifier modifier bits for vector register, general purpose register, memory addressing and allow access to the next set of 8 registers beyond the low8registers when combined with the ModR/M register field1344and ModR/M R/M field1346. P[9:8] provide opcode extensionality equivalent to some legacy prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). P[10] in some examples is a fixed value of 1. P[14:11], shown as vvvv, may be used to: 1) encode the first source register operand, specified in inverted (1scomplement) form and valid for instructions with 2 or more source operands; 2) encode the destination register operand, specified in is complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a certain value, such as1111b.

P[15] is similar to W of the first prefix1201(A) and second prefix1211(B) and may serve as an opcode extension bit or operand size promotion.

P[18:16] specify the index of a register in the opmask (writemask) registers (e.g., writemask/predicate registers1115). In one example, the specific value aaa=000 has a special behavior implying no opmask is used for the particular instruction (this may be implemented in a variety of ways including the use of a opmask hardwired to all ones or hardware that bypasses the masking hardware). When merging, vector masks allow any set of elements in the destination to be protected from updates during the execution of any operation (specified by the base operation and the augmentation operation); in other one example, preserving the old value of each element of the destination where the corresponding mask bit has a 0. In contrast, when zeroing vector masks allow any set of elements in the destination to be zeroed during the execution of any operation (specified by the base operation and the augmentation operation); in one example, an element of the destination is set to 0 when the corresponding mask bit has a 0 value. A subset of this functionality is the ability to control the vector length of the operation being performed (that is, the span of elements being modified, from the first to the last one); however, it is not necessary that the elements that are modified be consecutive. Thus, the opmask field allows for partial vector operations, including loads, stores, arithmetic, logical, etc. While examples are described in which the opmask field's content selects one of a number of opmask registers that contains the opmask to be used (and thus the opmask field's content indirectly identifies that masking to be performed), alternative examples instead or additional allow the mask write field's content to directly specify the masking to be performed.

P[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax which can access an upper 16 vector registers using P[19]. P[20] encodes multiple functionalities, which differs across different classes of instructions and can affect the meaning of the vector length/rounding control specifier field (P[22:21]). P[23] indicates support for merging-writemasking (e.g., when set to 0) or support for zeroing and merging-writemasking (e.g., when set to 1).

Exemplary examples of encoding of registers in instructions using the third prefix1201(C) are detailed in the following tables.

Program code may be applied to input information to perform the functions described herein and generate output information. The output information may be applied to one or more output devices, in known fashion. For purposes of this application, a processing system includes any system that has a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microprocessor, or any combination thereof.

Accordingly, examples also include non-transitory, tangible machine-readable media containing instructions or containing design data, such as Hardware Description Language (HDL), which defines structures, circuits, apparatuses, processors and/or system features described herein. Such examples may also be referred to as program products.

FIG.18illustrates a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set architecture to binary instructions in a target instruction set architecture according to examples. In the illustrated example, the instruction converter is a software instruction converter, although alternatively the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof.FIG.18shows a program in a high-level language1802may be compiled using a first ISA compiler1804to generate first ISA binary code1806that may be natively executed by a processor with at least one first instruction set architecture core1816. The processor with at least one first ISA instruction set architecture core1816represents any processor that can perform substantially the same functions as an Intel® processor with at least one first ISA instruction set architecture core by compatibly executing or otherwise processing (1) a substantial portion of the instruction set architecture of the first ISA instruction set architecture core or (2) object code versions of applications or other software targeted to run on an Intel processor with at least one first ISA instruction set architecture core, in order to achieve substantially the same result as a processor with at least one first ISA instruction set architecture core. The first ISA compiler1804represents a compiler that is operable to generate first ISA binary code1806(e.g., object code) that can, with or without additional linkage processing, be executed on the processor with at least one first ISA instruction set architecture core1816. Similarly,FIG.18shows the program in the high-level language1802may be compiled using an alternative instruction set architecture compiler1808to generate alternative instruction set architecture binary code1810that may be natively executed by a processor without a first ISA instruction set architecture core1814. The instruction converter1812is used to convert the first ISA binary code1806into code that may be natively executed by the processor without a first ISA instruction set architecture core1814. This converted code is not necessarily to be the same as the alternative instruction set architecture binary code1810; however, the converted code will accomplish the general operation and be made up of instructions from the alternative instruction set architecture. Thus, the instruction converter1812represents software, firmware, hardware, or a combination thereof that, through emulation, simulation or any other process, allows a processor or other electronic device that does not have a first ISA instruction set architecture processor or core to execute the first ISA binary code1806.

Moreover, in the various examples described above, unless specifically noted otherwise, disjunctive language such as the phrase “at least one of A, B, or C” or “A, B, and/or C” is intended to be understood to mean either A, B, or C, or any combination thereof (i.e. A and B, A and C, B and C, and A, B and C).

It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the invention described herein are, for example, capable of operation in other orientations than those illustrated or otherwise described herein.

As used throughout this description, and in the claims, a list of items joined by the term “at least one of” or “one or more of” can mean any combination of the listed terms. For example, the phrase “at least one of A, B or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C. It is pointed out that those elements of a figure having the same reference numbers (or names) as the elements of any other figure can operate or function in any manner similar to that described, but are not limited to such.

In addition, the various elements of combinatorial logic and sequential logic discussed in the present disclosure may pertain both to physical structures (such as AND gates, OR gates, or XOR gates), or to synthesized or otherwise optimized collections of devices implementing the logical structures that are Boolean equivalents of the logic under discussion.

In one or more first embodiments, a processor comprises an instruction fetch unit comprising circuitry to receive a pointer to an instruction of an instruction sequence, based on the pointer, identify a page table as comprising an entry which corresponds to the instruction, and access metadata associated with the page table, the metadata comprising an identifier of an operational mode of the processor, and a mode selector unit coupled to receive the identifier of the operational mode from the instruction fetch unit, the mode selector unit comprising circuitry to perform a transition of the processor to the operational mode based on the identifier, and an execution unit coupled to the mode selector unit, the execution unit to execute the instruction based on the operational mode.

In one or more second embodiments, further to the first embodiment, the mode selector unit is to perform the transition independent of any explicit identification of the operational mode by the instruction sequence.

In one or more third embodiments, further to the first embodiment or the second embodiment, the mode selector unit to perform the transition comprises the mode selector unit to transition the processor between a first operational mode and a second operational mode, wherein the first operational mode corresponds to a first instruction set architecture (ISA), and wherein the second operational mode corresponds to a second ISA.

In one or more fourth embodiments, further to any of the first through third embodiments, the mode selector unit to perform the transition comprises the mode selector unit to transition the processor between a first operational mode and a second operational mode, wherein the first operational mode is to provide a first level of a power performance parameter, wherein the second operational mode is to provide a second level of the power performance parameter.

In one or more fifth embodiments, further to the fourth embodiment, the power performance parameter comprises a supply voltage parameter, or a clock frequency parameter.

In one or more sixth embodiments, further to any of the first through third embodiments, the mode selector unit to perform the transition comprises the mode selector unit to transition the processor between a first operational mode and a second operational mode, wherein the first operational mode enables a security feature, and wherein the second operational mode disables the security feature.

In one or more seventh embodiments, further to the sixth embodiment, the security feature comprises a speculative execution control.

In one or more eighth embodiments, further to any of the first through third embodiments, the metadata is to be accessed by the instruction fetch unit at a mode register of the processor.

In one or more ninth embodiments, further to any of the first through third embodiments, the metadata, the pointer, the instruction, the entry, the page table, and the operational mode are, respectively, first metadata, a first pointer, a first instruction, a first entry, a first page table, and a first operational mode, and wherein the instruction fetch unit is further to receive a second pointer to a second instruction of the instruction sequence, wherein, based on the second pointer, the instruction fetch unit is further to identify a second page table as comprising a second entry which corresponds to the second instruction, and access second metadata of the second page table to determine a second operational mode of the processor, wherein the mode selector unit is further to perform another transition of the processor to the second operational mode based on the second metadata, and wherein the execution unit is further to execute the second instruction based on the second operational mode.

In one or more tenth embodiments, one or more non-transitory computer-readable storage media having stored thereon instructions which, when executed by one or more processing units, cause the one or more processing units to perform a method comprising receiving a pointer to an instruction of an instruction sequence, based on the pointer identifying a page table as comprising an entry which corresponds to the instruction, accessing metadata associated with the page table, the metadata comprising an identifier of an operational mode of a processor, and performing a transition of the processor to the operational mode based on the identifier, and executing the instruction based on the operational mode.

In one or more eleventh embodiments, further to the tenth embodiment, the transition is performed independent of any explicit identification of the operational mode by the instruction sequence.

In one or more twelfth embodiments, further to the tenth embodiment or the eleventh embodiment, performing the transition comprises transitioning the processor between a first operational mode and a second operational mode, wherein the first operational mode corresponds to a first instruction set architecture (ISA), and wherein the second operational mode corresponds to a second ISA.

In one or more thirteenth embodiments, further to any of the tenth through twelfth embodiments, performing the transition comprises transitioning the processor between a first operational mode and a second operational mode, wherein the first operational mode is to provide a first level of a power performance parameter, wherein the second operational mode is to provide a second level of the power performance parameter.

In one or more fourteenth embodiments, further to the thirteenth embodiment, the power performance parameter comprises a supply voltage parameter, or a clock frequency parameter.

In one or more fifteenth embodiments, further to any of the tenth through twelfth embodiments, performing the transition comprises transitioning the processor between a first operational mode and a second operational mode, wherein the first operational mode enables a security feature, and wherein the second operational mode disables the security feature.

In one or more sixteenth embodiments, further to the fifteenth embodiment, the security feature comprises a speculative execution control.

In one or more seventeenth embodiments, further to any of the tenth through twelfth embodiments, the metadata is accessed at a mode register of the processor.

In one or more eighteenth embodiments, further to any of the tenth through twelfth embodiments, the metadata, the pointer, the instruction, the entry, the page table, and the operational mode are, respectively, first metadata, a first pointer, a first instruction, a first entry, a first page table, and a first operational mode, and wherein the method further comprises receiving a second pointer to a second instruction of the instruction sequence, based on the second pointer identifying a second page table as comprising a second entry which corresponds to the second instruction, accessing second metadata of the second page table to determine a second operational mode of the processor, and performing another transition of the processor to the second operational mode based on the second metadata, and executing the second instruction based on the second operational mode.

In one or more nineteenth embodiments, a system comprises a memory to store multiple instructions which are to be executed in a sequence, a processor coupled to the memory, the processor comprising an instruction fetch unit comprising circuitry to receive a pointer to an instruction of the multiple instructions, based on the pointer, identify the page table as comprising an entry which corresponds to the instruction, and access metadata associated with the page table, the metadata comprising an identifier of an operational mode of the processor, and a mode selector unit coupled to receive the identifier of the operational mode from the instruction fetch unit, the mode selector unit comprising circuitry to perform a transition of the processor to the operational mode based on the identifier, and an execution unit coupled to the mode selector unit, the execution unit to execute the instruction based on the operational mode.

In one or more twentieth embodiments, further to the nineteenth embodiment, the mode selector unit is to perform the transition independent of any explicit identification of the operational mode by the sequence.

In one or more twenty-first embodiments, further to the nineteenth embodiment or the twentieth embodiment, the mode selector unit to perform the transition comprises the mode selector unit to transition the processor between a first operational mode and a second operational mode, wherein the first operational mode corresponds to a first instruction set architecture (ISA), and wherein the second operational mode corresponds to a second ISA.

In one or more twenty-second embodiments, further to any of the nineteenth through twenty-first embodiments, the mode selector unit to perform the transition comprises the mode selector unit to transition the processor between a first operational mode and a second operational mode, wherein the first operational mode is to provide a first level of a power performance parameter, wherein the second operational mode is to provide a second level of the power performance parameter.

In one or more twenty-third embodiments, further to the twenty-second embodiment, the power performance parameter comprises a supply voltage parameter, or a clock frequency parameter.

In one or more twenty-fourth embodiments, further to any of the nineteenth through twenty-first embodiments, the mode selector unit to perform the transition comprises the mode selector unit to transition the processor between a first operational mode and a second operational mode, wherein the first operational mode enables a security feature, and wherein the second operational mode disables the security feature.

In one or more twenty-fifth embodiments, further to the twenty-fourth embodiment, the security feature comprises a speculative execution control.

In one or more twenty-sixth embodiments, further to any of the nineteenth through twenty-first embodiments, the metadata is to be accessed by the instruction fetch unit at a mode register of the processor.

In one or more twenty-seventh embodiments, further to any of the nineteenth through twenty-first embodiments, the metadata, the pointer, the instruction, the entry, the page table, and the operational mode are, respectively, first metadata, a first pointer, a first instruction, a first entry, a first page table, and a first operational mode, and wherein the instruction fetch unit is further to receive a second pointer to a second instruction of the multiple instructions, wherein, based on the second pointer, the instruction fetch unit is further to identify a second page table as comprising a second entry which corresponds to the second instruction, and access second metadata of the second page table to determine a second operational mode of the processor, wherein the mode selector unit is further to perform another transition of the processor to the second operational mode based on the second metadata, and wherein the execution unit is further to execute the second instruction based on the second operational mode.