Device and method for slow-motion synchronous page table updates with minimal effort

Abstract

Processor (870, 880), including the following: multiple cores (1210, 1211) to execute instructions and process data; one or more translation buffers, TLBs, (1220), comprising multiple entries to accommodate address translations from virtual to physical, which are usable by at least one of the multiple cores (1210, 1211) when executing instructions; a page table entry, PTE, invalidation circuit (1214) to execute a PTE invalidation instruction on a first core to invalidate a first PTE in TLBs (1220) of other cores, wherein the PTE invalidation circuit (1214), in response to an execution of the PTE invalidation instruction, determines a number of other TLBs (1220) of other cores which need to be notified of the PTE invalidation, transmits PTE invalidation messages to the other TLBs (1220) and waits for replies; a lock-switching complex to allow a thread to lock the first PTE in the first TLB (1220) to ensure that only one thread can modify the first PTE at any given time, wherein the first TLB (1220) serves to modify the first PTE when the thread acquires the lock, and wherein the lock-switching complex releases the lock on the first PTE in response to receiving replies from all the other TLBs (1220), wherein each TLB (1220) includes a PTE invalidation request treatment circuit complex (1221) to receive invalidation requests transmitted from other TLBs (1220), wherein the invalidation request treatment circuit complex (1221) in response causes the TLBs (1220) to invalidate one or more PTEs identified in the invalidation requests and transmits a reply indicating the invalidation; and a PTE invalidation sequence control circuit (1224) which is to be programmed with a counter value initially set to the number of other TLBs (1220) which need to be notified, wherein the PTE invalidation sequence control circuit (1224) decrements the counter value upon receiving each reply from each of the other TLBs (1220), wherein the blocking circuit complex releases the block when the counter value has been decremented to a threshold value.

Description

BACKGROUND Area of ​​the invention

[0001] This invention relates generally to the field of computer processors. In particular, the invention relates to a method and a device for synchronous page table updates with minimal effort. Description of related technology: 1. Processor microarchitectures

[0002] An instruction set, or instruction set architecture (ISA), is the part of computer architecture that pertains to programming. It encompasses 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" here generally refers to macro instructions—that is, instructions provided to the processor for execution—as opposed to micro instructions or micro-operations—that is, the result of a processor decoder decoding macro instructions. Micro instructions or micro-operations can be configured to instruct an execution unit on the processor to perform operations to implement the logic associated with the macro instruction.

[0003] The ISA is distinguished from the microarchitecture, which is the set of processor design methods 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. in Sunnyvale, CA, implement nearly identical versions of the x86 instruction set (with some extensions added in newer versions), but have different internal designs. For example, the same register architecture of the ISA can 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 write-out register file). Unless otherwise described, the terms register architecture, register file, and register are used here to denote what is visible to the software / programmer and to describe the way in which instructions specify registers. Where a distinction is necessary, the adjectives "logical," "architectural," or "software-visible" are used to indicate registers / files in the register architecture, while different adjectives are used to denote registers in a given microarchitecture (e.g., physical register, reorder buffer, write-out register, register collection). 2. TLB coherence

[0004] In a shared memory system, both caches and TLBs must be kept coherent to provide all threads with the same memory view. One of the main reasons for maintaining coherence for TLBs is that it is difficult to keep the overall data state coherent when two different CPUs have different address translations for the same page. Keeping TLBs coherent is relatively inexpensive when page table entries (PTEs) change very infrequently, as is the case today. Current systems use a combination of inert PTE reuse, supported on rare occasions by immediate TLB kills. TLB kills are enormously resource-intensive, but in current systems, they are the only way to propagate a PTE change in a synchronous manner.It is expected that the frequency of PTE changes will increase in the near future, necessitating a more efficient mechanism for propagating PTE changes.

[0005] US 2004 O 059 872 A1 relates to a method and system for improving input / output (I / O) performance by proactively flushing and locking an entire page from the caches of the multiprocessor system. An exemplary method includes proactively flushing and locking a memory region of arbitrary size from the caches of the multiprocessor system. SUMMARY OF THE INVENTION

[0006] The present invention is defined by a processor having the features according to main claim 1, a method having the features according to dependent claim 6, and a system having the features according to dependent claim 11. The dependent claims define further developments of the processor, method, and system according to the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, wherein: Fig. 1A and Fig. 1B Block diagrams are shown, illustrating a general vector-friendly command format and command templates thereof according to embodiments of the invention. Fig. Figures 2A to D are a block diagram illustrating an exemplary specific vector-friendly command format according to embodiments of the invention. Fig. 3 a block diagram of a register architecture according to an embodiment of the invention; and Fig.4A is a block diagram illustrating both an exemplary in-order pipeline for retrieving, decoding and posting, and an exemplary register renaming out-of-order output / execution pipeline according to embodiments of the invention; Fig. 4B is a block diagram illustrating both an embodiment of an in-order kernel for retrieving, decoding and posting, and an exemplary register renaming-out-of-order output / execution architecture kernel to be included in a processor according to embodiments of the invention; Fig. 5A is a block diagram of a single processor core together with its connection to an on-die interconnect network; Fig. 5B shows an extended view of part of the processor core in Fig. 5A illustrated according to embodiments of the invention; Fig.6 a block diagram of a single-core processor and a multi-core processor with integrated memory control and graphics according to embodiments of the invention; Fig. 7 illustrates a block diagram of a system according to an embodiment of the present invention; Fig. 8 illustrates a block diagram of a second system according to an embodiment of the present invention; Fig. 9 illustrates a block diagram of a third system according to an embodiment of the present invention; Fig. Figure 10 illustrates a block diagram of a SoC (System-on-Chip) according to an embodiment of the present invention; Fig. Figure 11 illustrates a block diagram contrasting the use of a software instruction converter for converting binary instructions in a source instruction set to binary instructions in a target instruction set according to embodiments of the invention; Fig. 12 illustrates an architecture according to an embodiment of the invention; Fig. Figure 13 illustrates operations that are implemented by an initiator (e.g., a kernel / agent) and one or more other kernel / agent translation buffers (TLBs: Translation Lookaside Buffers) according to an embodiment of the invention; and Fig. Figure 14 illustrates an embodiment which uses fence operations to ensure data coherence. DETAILED DESCRIPTION

[0008] For explanatory purposes, numerous specific details are presented in the following description to provide a thorough understanding of the embodiments of the invention described below. However, it is obvious to those skilled in the art that the embodiments of the invention can be implemented in practice without some of these specific details. In other cases, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the embodiments of the invention. EXEMPLARY PROCESSOR ARCHITECTURES AND DATA TYPES

[0009] An instruction set comprises one or more instruction formats. A given instruction format defines various fields (number of bits, bit locations) to specify, among other things, the operation to be performed (opcode) and the operand(s) on which the operation is to be carried out. Some instruction formats are further subdivided by defining instruction templates (or subformats). For example, the instruction templates of a given instruction format may be defined such that they contain different subsets of the fields of the instruction format (the fields they contain are typically in the same order, but at least some have different bit positions because they contain fewer fields), and / or they may be defined such that they contain a given field that is interpreted differently.Accordingly, each command in an ISA is expressed using a given command format (and, if defined, in a given command template of that command format) and includes fields to specify the operation and operands. For example, an example ADD command has a specific opcode and a command format that includes an opcode field to specify that opcode and operand fields to select operands (source 1 / destination and source 2); and an occurrence of this ADD command in a command stream will have specific contents in the operand fields that select specific operands. A set of SIMD extensions, called AVX (Advanced Vector Extensions) (AVX1 and AVX2), which use the VEX encoding scheme (VEX: Vector Extensions), has been released and / or published (see, for example, the VEX documentation).Intel® 64 and IA-32 Architectures Software Developers Manual, October 2011; and Intel® Advanced Vector Extensions Programming Reference, June 2011). Example command formats

[0010] Implementations of the command(s) described here can be executed in various formats. Furthermore, exemplary systems, architectures, and pipelines are described in detail below. Implementations of the command(s) can be executed on such systems, architectures, and pipelines, but are not limited to those described in detail. A. General vector-friendly command format

[0011] A vector-friendly command format is a command format suitable for vector commands (e.g., it has specific fields for vector operations). Although implementations have been described that support both vector and scalar operations, alternative implementations use only vector operations through the vector-friendly command format.

[0012] Fig. Figures 1A to 1B are block diagrams illustrating a general vector-friendly command format and command templates thereof according to embodiments of the invention. Fig. Figure 1A is a block diagram illustrating a general vector-friendly command format and Class A command templates according to embodiments of the invention; while Fig.Figure 1B is a block diagram illustrating the general vector-friendly instruction format and class-B instruction templates thereof according to embodiments of the invention. In particular, a general vector-friendly instruction format 100 for which class-A and class-B instruction templates are defined, both of which include instruction templates without memory access 105 and instruction templates with memory access 120. The term "general" in the context of the vector-friendly instruction format indicates that the instruction format is not bound to any specific instruction set.

[0013] Although embodiments of the invention are described in which the vector-friendly instruction format supports the following: a 64-byte vector operand length (or size) with 32-bit (4-byte) or 64-bit (8-byte) data element widths (or sizes) (and thus a 64-byte vector consists of either 16 double-word elements or alternatively 8 four-word elements); a 64-byte vector operand length (or size) with 16-bit (2-byte) or 8-bit (1-byte) data element widths (or sizes); a 32-byte vector operand length (or size) with 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte), or 8-bit (1-byte) data element widths (or sizes); and a 16-byte vector operand length (or size) with 32-bit (4-byte), 64-bit (8-byte), 16-bit (2-byte) or 8-bit (1-byte) data element widths (or sizes); alternative embodiments may have more, fewer and / or different vector operand sizes (e.g.256-byte vector operands) with more, fewer or different data element widths (e.g. 128-bit (16-byte) data element widths).

[0014] The Class A command templates in Fig. 1A includes the following: 1) within the command templates without memory access 105, a command template for a full round-off control operation without memory access 110 and a command template for a data transformation type operation without memory access 115 are shown; and 2) within the command templates with memory access 120, a temporal command template with memory access 125 and a non-temporal command template with memory access 130 are shown. The class B command templates in Fig.1B includes the following: 1) within the command templates without memory access 105, a command template for a write mask control partial rounding control operation without memory access 112 and a command template for a write mask control VSIZE type operation without memory access 117 are shown; and 2) within the command templates with memory access 120, a command template for a write mask control with memory access 127 is shown.

[0015] The general vector-friendly command format 100 includes the following fields, which are described below in the Fig. 1A to 1B are listed in illustrated order.

[0016] Format field 140 – a specific value (a command format identifier value) in this field uniquely identifies the vector-friendly command format and, consequently, the occurrence of commands in the vector-friendly command format in command streams. As such, this field is optional in the sense that it is not required for a command set that only contains the general vector-friendly command format.

[0017] Basic operation field 142 - its content distinguishes various basic operations.

[0018] Register index field 144 – its contents specify, directly or by address generation, the locations of the source and destination operands, whether in registers or in memory. These comprise a sufficient number of bits to select N registers from a PxQ (e.g., 32×512, 16×128, 32×1024, 64×1024) register file. While in one embodiment N can be up to three source registers and one destination register, alternative embodiments can support more or fewer source and destination registers (e.g., they can support up to two sources, one of which also acts as the destination; they can support up to three sources, one of which also acts as the destination; they can support up to two sources and one destination).

[0019] Modifier field 146 – its content distinguishes between instructions in the general vector instruction format that specify memory access and those that do not; i.e., between instruction templates without memory access (105) and instruction templates with memory access (120). Memory access operations read and / or write to the memory hierarchy (where, in some cases, the source and / or destination addresses are specified using values ​​in registers), while operations without memory access do not (e.g., the source and destinations are registers). While in one embodiment this field also selects between three different ways to perform memory address calculations, alternative embodiments may support more, fewer, or different ways to perform memory address calculations.

[0020] Supplementary operation field 150 – its content distinguishes which of a variety of different operations are to be performed in addition to the basic operation. This field is context-specific. In one embodiment of the invention, this field is subdivided into a class field 168, an alpha field 152, and a beta field 154. The supplementary operation field 150 makes it possible to perform common groups of operations in a single command instead of in two, three, or four commands.

[0021] Scaling field 160 - its content allows scaling of the content of the index field for memory address generation (e.g., for address generation which has 2 Skalierung * Index + base used).

[0022] Displacement field 162A - its contents are used as part of memory address generation (e.g., for address generation, which 2 Skalierung * Index + Base + Shift used).

[0023] Shift factor field 162B (note that the juxtaposition of shift field 162A directly above shift factor field 162B indicates that one or the other is being used) - its contents are used as part of address generation; it specifies a shift factor to be scaled by the size of a memory access (N) - where N is the number of bytes in the memory access (e.g., for address generation, which is 2 Skalierung* Index + base + scaled shift used). Redundant lower-order bits are ignored, and therefore the contents of the shift factor field are multiplied by the total memory operand size (N) to produce the final shift to be used when calculating an effective address. The value of N is determined by the processor hardware at runtime based on the full opcode field 174 (described below) and the data manipulation field 154C. The shift field 162A and the shift factor field 162B are optional in the sense that they are not used for the no-memory instruction templates 105 and / or different embodiments may implement only one or neither of them.

[0024] Data element width field 164 – its content specifies which of a number of data element widths should be used (in some implementations for all instructions; in other implementations for only some of the instructions). This field is optional in the sense that it is not required if only one data element width is supported and / or if data element widths are supported that use a certain aspect of the opcodes.

[0025] Write mask field 170 – its content controls, on a per-data-element basis, whether that data element position in the target vector operand reflects the result of the base operation and the complement operation. Class A command templates support merge write masking, while Class B command templates support both merge and zero write masking. In merge mode, vector masks allow each set of elements in the target to be protected from updates during the execution of an operation (specified by the base operation and the complement operation); in another embodiment, they allow the old value of each element in the target to be preserved where the corresponding mask bit is 0.In contrast, zeroing vector masks allow each set of elements in the target to be zeroed out during the execution of an operation (specified by the base operation and the complement operation); in one embodiment, an element of the target is set to 0 if the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the operation performed (i.e., the span of modified elements from the first to the last); however, it is not necessary for the elements being modified to be consecutive. Thus, the write mask field allows 170 sub-vector operations, including load, store, arithmetic, logic operations, and so on.While embodiments of the invention are described in which the content of the write mask field 170 selects one from a number of write mask registers which contains the write mask to be used (and thus the content of the write mask field 170 indirectly identifies the masking to be performed), alternative embodiments allow instead or additionally the content of the write mask field 170 to directly specify the masking to be performed.

[0026] Immediate field 172 – its content allows the specification of an immediate. This field is optional in the sense that it is not present in an implementation of the general vector-friendly format, which does not support an immediate, and is not present in commands that do not use an immediate.

[0027] Class field 168 – its content distinguishes between different classes of commands. With reference to Fig. 1A to B select the contents of this field between commands of class A and class B. Fig. In sections 1A to B, rectangles with rounded corners are used to indicate that a specific value is present in a field (e.g., Class A 168A and Class B 168B for class field 168 in [reference to class A]). Fig. 1A to B). Class A command templates

[0028] In the case of the Class A instruction templates without memory access 105, the alpha field 152 is interpreted as an RS field 152A, the content of which distinguishes which of the various complement operation types are to be executed (e.g., round 152A.1 and data transformation 152A.2 are specified for the instruction templates for a rounding type operation without memory access 110 and for a data transformation type operation without memory access 115, respectively), while the beta field 154 distinguishes which of the operations of the specified type are to be performed. The scaling field 160, the shift field 162A, and the shift scaling field 162B are not present in the instruction templates without memory access 105. Command templates without memory access - full rounding control type operation

[0029] In the instruction template for a full rounding control type operation without memory access 110, the beta field 154 is interpreted as a rounding control field 154A, the content(s) of which provide a static rounding operation. While in the described embodiments of the invention the rounding control field 154A comprises an SAE field 156 (SAE: Suppress All Floating Point Exceptions) and a rounding operation control field 158, alternative embodiments can encode these two concepts in the same field or have only one or the other of these concepts / fields (e.g., they can have only the rounding operation control field 158).

[0030] SAE field 156 - its content distinguishes whether exception event reporting is disabled or not; if the content of SAE field 156 indicates that suppression is enabled, a given command will not report any type of floating-point exception flag and will not trigger a floating-point exception handler.

[0031] The rounding operation control field 158 – its content distinguishes which of a group of rounding operations is to be performed (e.g., rounding up, rounding down, rounding to zero, and rounding to the nearest). Accordingly, the rounding operation control field 158 allows the rounding mode to be changed on a per-instruction basis. In an embodiment of the invention in which a processor includes a control register for specifying rounding modes, the content of the rounding operation control field 150 overrides this register value. Command templates without memory access - data transformation type operation

[0032] In the command template for a data transformation type operation without memory access 115, the beta field 154 is interpreted as a data transformation field 154B, the content of which distinguishes which of a number of data transformations is to be performed (e.g. no data transformation, swizzle, broadcast).

[0033] In the case of a Class A instruction template with memory access 120, the alpha field 152 is interpreted as an evacuation notice field 152B, the content of which distinguishes which of the evacuation notices should be used (in Fig.1A specifies Temporal 152B.1 and Nontemporal 152B.2, respectively, for the Temporal instruction template with memory access 125 and the Nontemporal instruction template with memory access 130, while the Beta field 154 is interpreted as a Data Manipulation field 154C, the contents of which distinguish which of a number of data manipulation operations (also known as primitives) is to be performed (e.g., no manipulation; broadcast; upconversion of a source and downconversion of a destination). The Instruction Templates with memory access 120 include the Scaling field 160 and optionally the Shift field 162A or the Shift Scaling field 162B.

[0034] Vector store commands perform vector loading from memory and vector storage to memory with conversion support. Like regular vector commands, vector store commands transfer data to / from memory in a data-element-wise manner, with the elements actually transferred being dictated by the contents of the vector mask selected as the write mask. Command templates with memory access - Temporal

[0035] Temporal data is data that is likely to be reused soon enough to benefit from caching. However, this is a hint, and different processors can implement it in different ways, including ignoring the hint entirely. Command templates with memory access - Non-temporal

[0036] Non-temporal data is data that is unlikely to be reused soon enough to benefit from caching in the first-level cache and should therefore be given priority for clearing. However, this is a suggestion, and different processors may implement it in different ways, including ignoring the suggestion entirely. Class B command templates

[0037] In the case of the command templates of class B, the alpha field 152 is interpreted as a write mask control (Z) field 152C, the content of which distinguishes whether the write masking controlled by the write mask field 170 must be a merge or a zeroing.

[0038] In the case of the Class B no-memory command templates 105, part of the beta field 154 is interpreted as an RL field 157A, the content of which distinguishes which of the various complement operation types are to be executed (e.g., Round 157A.1 and Vector Length (VSIZE) 157A.2 are specified for the no-memory command template for a write mask control partial rounding control operation 112 and the no-memory command template for a write mask control VSIZE type operation 117, respectively), while the remainder of the beta field 154 distinguishes which of the operations of the specified type are to be performed. The no-memory command templates 105 do not contain the scaling field 160, the displacement field 162A, or the displacement scaling field 162B.

[0039] In the command template for a write mask control partial rounding control operation without memory access 110, the remainder of the beta field 154 is interpreted as a rounding operation field 159A and exception event reporting is disabled (a given command does not report any type of floating-point exception flag and does not trigger a floating-point exception handler).

[0040] Rounding operation control field 159A – like rounding operation control field 158 – distinguishes its content according to which group of rounding operations is to be performed (e.g., rounding up, rounding down, rounding to zero, and rounding to the nearest). Accordingly, rounding operation control field 159A allows the rounding mode to be changed on a per-instruction basis. In an embodiment of the invention in which a processor includes a control register for specifying rounding modes, the content of rounding operation control field 150 overrides this register value.

[0041] In the command template for a write mask control VSIZE type operation without memory access 117, the remainder of the beta field 154 is interpreted as a vector length field 159B, the contents of which distinguishes which of a number of data vector lengths is to be executed (e.g. 128, 256 or 512 bytes).

[0042] In the case of a Class B instruction template with memory access 120, part of the beta field 154 is interpreted as a broadcast field 157B, the content of which determines whether the broadcast-type data manipulation operation should be performed or not, while the remainder of the beta field 154 is interpreted as the vector length field 159B. The instruction templates with memory access 120 include the scale field 160 and optionally the displacement field 162A or the displacement-scale field 162B.

[0043] With reference to the general vector-friendly command format 100, a full opcode field 174 is shown, including the format field 140, the basic operation field 142, and the data element width field 164. While one embodiment is shown in which the full opcode field 174 includes all of these fields, in embodiments that do not support all of them, the full opcode field 174 includes fewer than all of these fields. The full opcode field 174 provides the operation code (opcode).

[0044] The supplementary operation field 150, the data element width field 164 and the write mask field 170 allow these features to be specified on a per-command basis in the general vector-friendly command format.

[0045] The combination of the write mask field and the data element width field creates typed commands insofar as it allows the mask to be applied based on different data element widths.

[0046] The various instruction templates found within Class A and Class B are advantageous in different situations. In some embodiments of the invention, different processors or different cores within a processor may support only Class A, only Class B, or both classes. For example, a high-performance, general-purpose, out-of-order core intended for general-purpose computing may support only Class B; a core intended primarily for graphics and / or scientific (throughput) computing may support only Class A; and a core intended for both may support both (of course, a core that has a mixture of templates and instructions from both classes, but not all templates and instructions from both classes, is within the scope of the invention).Furthermore, a single processor can comprise multiple cores, all of which support the same class, or in which different cores support different classes. For example, in a processor with separate graphics and general-purpose cores, one of the graphics cores, primarily intended for graphics and / or scientific computing, may support only Class A, while one or more of the general-purpose cores may be high-performance general-purpose cores with out-of-order execution and register renaming intended for general-purpose computing, supporting only Class B. Another processor, which does not have a separate graphics core, may comprise one or more general-purpose in-order or out-of-order cores that support both Class A and Class B. Naturally, in different embodiments of the invention, features from one class may also be implemented in the other class.Programs written in a higher-level language would be implemented in a variety of different executable forms (e.g., just-in-time compiled or statically compiled), including: 1) a form containing only instructions of the class(es) supported for execution by the target processor; or 2) a form containing alternative routines written using various combinations of instructions from all classes and featuring control flow code that selects the routines to be executed based on the instructions supported by the processor currently executing the code. B. Example of a specific vector-friendly command format

[0047] Fig. Figure 2 is a block diagram illustrating an exemplary specific vector-friendly command format according to embodiments of the invention. Fig.Figure 2 shows a specific vector-friendly instruction format 200, which is specific in that it specifies the location, size, interpretation, and order of fields, as well as values ​​for some of these fields. The specific vector-friendly instruction format 200 can be used to extend the x86 instruction set, and accordingly, some of the fields are similar to or the same as those used in the existing x86 instruction set and an extension thereof (e.g., AVX). This format remains consistent with the prefix encoding field, real opcode byte field, MOD R / M field, SIB field, displacement field, and immediate fields of the existing x86 instruction set with extensions. The fields from Fig. 1, onto which the fields from Fig. The two images shown are depicted.

[0048] It is understood that, although embodiments of the invention are described for illustrative purposes with reference to the specific vector-friendly command format 200 in connection with the general vector-friendly command format 100, the invention is not limited to the specific vector-friendly command format 200, except where claimed. For example, the general vector-friendly command format 100 considers a variety of possible sizes for the different fields, whereas the specific vector-friendly command format 200 is shown with fields of specific sizes. As a specific example, although the data element width field 164 is illustrated as a one-bit field in the specific vector-friendly command format 200, the invention is not so limited (that is, the general vector-friendly command format 100 considers other sizes of the data element width field 164).

[0049] The general vector-friendly command format 100 includes the following fields, which are shown below in the Fig. 2A are listed in the illustrated order.

[0050] EVEX prefix (bytes 0 to 3) 202 - is encoded in a four-bit form.

[0051] Format field 140 (EVEX byte 0, bits [7:0]) - the first byte (EVEX byte 0) is the format field 140 and it comprises 0x62 (the unique value which, in one embodiment of the invention, is used to distinguish the vector-friendly command format).

[0052] The second to fourth bytes (EVEX bytes 1 to 3) comprise a number of bit fields which provide a specific capability.

[0053] REX field 205 (EVEX byte 1, bits [7-5]) consists of an EVEX.R bit field (EVEX byte 1, bit [7] - R), an EVEX.X bit field (EVEX byte 1, bit [6] - X), and 1157BEX byte 1, bit [5] - B). The EVEX.R, EVEX.X, and EVEX.B bit fields provide the same functionality as the corresponding VEX bit fields and are encoded using a 1s complement form, i.e., ZMM0 is encoded as 1111B, ZMM15 is encoded as 0000B. Other fields of the instructions encode the lower three bits of the register indices as is known in engineering (rrr, xxx and bbb), so that Rrrr, Xxxx and Bbbb can be formed by adding EVEX.R, EVEX.X and EVEX.B.

[0054] REX' field 110 – this is the first part of REX' field 110 and is the EVEX.R' bit field (EVEX byte 1, bit [4] – R'), which is used to encode either the upper 16 or the lower 16 of the extended 32-register set. In one embodiment of the invention, this bit, along with others as specified below, is stored in bit-inverted format to distinguish it (in the known x86 32-bit mode) from the BOUND instruction, whose real opcode byte is 62, but does not accept the value 11 in the MOD R / M field (described below); alternative embodiments of the invention do not store this and the other bits specified below in the inverted format. A value of 1 is used to encode the lower 16 registers. In other words, R'Rrrr is formed by combining EVEX.R', EVEX.R and the other RRR from other fields.

[0055] Opcode map field 215 (EVEX byte 1, bits [3:0] - mmmm) - its contents encode an implied leading opcode byte (0F, 0F 38 or 0F 3).

[0056] Data element width field 164 (EVEX byte 2, bit [7] - W) - is represented by the notation EVEX.W. EVEX.W is used to define the granularity (size) of the data type (either 32-bit data elements or 64-bit data elements).

[0057] EVEX.vw 220 (EVEX byte 2, bits [6:3]-vvvv) - the role of EVEX.vvvv can include the following: 1) EVEX.vvvv encodes the first source register operand, which is specified in inverted (1s complement) form and is valid for instructions with 2 or more source operands; 2) EVEX.vvvv encodes the destination register operand, which is specified in 1s complement form for certain vector shifts; or 3) EVEX.vvv does not encode any operand, the field is reserved and must contain 1111b. Accordingly, the EVEX.vvvv field 220 encodes the 4 lower-order bits of the first source register specification symbol, which are stored in inverted (1s complement) form. Depending on the command, an additional different EVEX bit field is used to extend the specification symbol size to 32 registers.

[0058] Class field EVEX.U 168 (EVEX byte 2, bit [2]-U) - if EVEX.U = 0, it specifies class A or EVEX.U0; if EVEX.U = 1, it specifies class B or EVEX.U1.

[0059] Prefix encoding field 225 (EVEX byte 2, bits [1:0]-pp) provides additional bits for the basic operation field. In addition to providing support for the deprecated SSE instructions in the EVEX prefix format, this also has the advantage of compacting the SIMD prefix (instead of requiring one byte to express the SIMD prefix, the EVEX prefix requires only 2 bits). In one embodiment, to support deprecated SSE instructions that use a SIMD prefix (66H, F2H, F3H) in both the deprecated and EVEX prefix formats, these deprecated SIMD prefixes are encoded in the SIMD prefix encoding field. and at runtime they are expanded into the deprecated SIMD prefix before being provided to the decoder's PLA (so the PLA can execute both the deprecated and EVEX formats of these deprecated instructions without modification).Although newer instructions could directly use the contents of the EVEX prefix encoding field as an opcode extension, certain implementations extend in a similar way for consistency, but allow different meanings to be specified using these deprecated SIMD prefixes. An alternative implementation can redesign the PLA to support the 2-bit SIMD prefix encodings and therefore does not require the extension.

[0060] Alpha field 152 (EVEX byte 3, bit [7] - EH; also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.WriteMaskControl and EVEX.N; also illustrated with α) - as previously described, this field is context-specific.

[0061] Beta field 154 (EVEX byte 3, bits [6:4]-SSS, also known as EVEX.s 2-0 EVEX.r 2-0 , EVEX.rr1, EVEX.LL0, EVEX.LLB; also illustrated with βββ) - as previously described, this field is context-specific.

[0062] REX' field 110 - this is the remainder of the REX' field and is the EVEX.V' bit field (EVEX byte 3, bit [3] - V'), which can be used to encode either the upper 16 or the lower 16 of the extended 32-register set. This bit is stored in bit-inverted format. A value of 1 is used to encode the lower 16 registers. In other words, V'VVVV is formed by combining EVEX.V' and EVEX.vvw.

[0063] Write mask field 170 (EVEX byte 3, bits [2:0]-kkk) - its contents specify the index of a register in the write mask registers, as previously described. In one embodiment of the invention, the special value EVEX.kkk = 000 exhibits special behavior, which implies that no write mask is used for the particular instruction (this can be implemented in a variety of ways, including the use of a write mask hardwired to all ones, or hardware that bypasses the masking hardware).

[0064] Real opcode field 230 (byte 4) is also known as the opcode byte. Part of the opcode is specified in this field.

[0065] MOD R / M field 240 (byte 5) comprises MOD field 242, Reg field 244, and R / M field 246. As previously described, the content of MOD field 242 distinguishes between memory-accessing and non-memory-accessing operations. The role of Reg field 244 can be summarized in two ways: encoding either the destination register operand or a source register operand, or being treated as an opcode extension and not being used to encode an instruction operand. The role of R / M field 246 can include: encoding the instruction operand that references a memory address, or encoding either the destination register operand or a source register operand.

[0066] Byte for scaling, index, base (SIB) (Byte 6) - As described previously, the contents of scaling field 150 are used for memory address generation. SIB.xxx 254 and SIB.bbb 256 - the contents of these fields were previously referenced with regard to the register indices Xxxx and Bbbb.

[0067] Shift field 162A (bytes 7 to 10) - if MOD field 242 contains 10, then bytes 7 to 10 are the shift field 162A, and it works the same as the obsolete 32-bit shift (disp32) and operates at byte granularity.

[0068] Shift factor field 162B (byte 7) - if the MOD field contains 242 01, then byte 7 is the shift factor field 162B. The location of this field is the same as that of the 8-bit shift (disp8) of the obsolete x86 instruction set, which operates at byte granularity. Because disp8 is sign-expanded, it can only address offsets between -128 and 127 bytes; with respect to 64-byte cache lines, disp8 uses 8 bits, which can be set to only four really useful values: -128, -64, 0, and 64; since a larger range is often needed, disp32 is used; however, disp32 requires 4 bytes. Unlike disp8 and disp32, the shift factor field 162B is a reinterpretation of disp8. When using the shift factor field 162B, the actual shift is determined by multiplying the content of the shift factor field by the size of the memory operand access (N). This type of shift is called disp8*N.This reduces the average instruction length (a single byte is used for the shift, but with a much larger range). Such a compressed shift is based on the assumption that the effective shift is a multiple of the memory access granularity, and therefore the redundant lower-order bits of the address offset do not need to be encoded. In other words, the 162B shift factor field replaces the deprecated 8-bit shift of the x86 instruction set. Accordingly, the 162B shift factor field is encoded in the same way as an 8-bit shift of the x86 instruction set (as long as there are no changes to the ModRM / SIB encoding rules), with the sole exception that disp8 is overloaded to disp8*N.In other words, there are no changes to the coding rules or coding lengths, but only to the hardware's interpretation of the shift value (which must scale the shift with the size of the memory operand to obtain a byte-wise address offset).

[0069] Immediate field 172 operates as described above. Full opcode field

[0070] Fig. Figure 2B is a block diagram illustrating the fields of the specific vector-friendly command format 200, which constitute the full opcode field 174, according to an embodiment of the invention. In particular, the full opcode field 174 comprises the format field 140, the basic operation field 142, and the data element width (W) field 164. The basic operation field 142 comprises the prefix encoding field 225, the opcode map field 215, and the real opcode field 230. Register index field

[0071] Fig.Figure 2C is a block diagram illustrating the fields of the specific vector-friendly command format 200 that constitute the register index field 144 according to an embodiment of the invention. In particular, the register index field 144 comprises the REX field 205, the REX' field 210, the MODR / M.reg field 244, the MODR / Mr / m field 246, the VVVV field 220, the xxx field 254, and the bbb field 256. Supplementary operational field

[0072] Fig.Figure 2D is a block diagram illustrating the fields of the specific vector-friendly command format 200, which constitute the supplementary operation field 150, according to one embodiment of the invention. When the class (U) field 168 contains 0, it is designated EVEX.U0 (Class A 168A); when it contains 1, it is designated EVEX.U1 (Class B 168B). When U = 0 and the MOD field 242 contains 11 (which denotes a no-memory operation), the alpha field 152 (EVEX byte 3, bit [7] - EH) is interpreted as the rs field 152A. When the rs field 152A contains 1 (round 152A.1), the beta field 154 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the rounding control field 154A. The rounding control field 154A comprises a one-bit SAE field 156 and a two-bit rounding operation field 158. If the rs field 152A contains a 0 (data transformation 152A.2), the beta field 154 (EVEX byte 3, bits [6:4]-SSS) is interpreted as a three-bit data transformation field 154B.If U = 0 and the MOD field 242 contains 00, 01 or 10 (which denotes a memory access operation), the alpha field 152 (EVEX byte 3, bit [7-] - EH) is interpreted as the evacuation hint (EH) field 152B, and the beta field 154 (EVEX byte 3, bits [6:4]-SSS) is interpreted as a three-bit data manipulation field 154C.

[0073] If U = 1, the alpha field 152 (EVEX byte 3, bit [7] - EH) is interpreted as the write mask control (Z) field 152C. If U = 1 and the MOD field 242 contains 11 (which denotes a no-memory operation), part of the beta field 154 (EVEX byte 3, bit [4] - S0) is interpreted as the RL field 157A; if it contains a 1 (rounding 157A.1), the remainder of the beta field 154 (EVEX byte 3, bit [6-5] - S0) is interpreted as the RL field 157A. 2-1 ) is interpreted as the rounding operation field 159A, whereas if the RL field 157A contains a 0 (VSIZE 157.A2), the remainder of the beta field 154 (EVEX byte 3, bit [6-5]- S 2-1) as the vector length field 159B (EVEX byte 3, bit [6-5]- L 1-0 ) is interpreted. If U = 1 and the MOD field 242 contains 00, 01 or 10 (which denotes a memory access operation), the beta field 154 (EVEX byte 3, bits [6:4]- SSS) is interpreted as the vector length field 159B (EVEX byte 3, bit [6-5]- L). 1-0 ) and the broadcast field 157B (EVEX byte 3, bit [4]- B) is interpreted. C. Exemplary Register Architecture

[0074] Fig.Figure 3 is a block diagram of a register architecture 300 according to an embodiment of the invention. In the illustrated embodiment, there are 32 vector registers 310, each 512 bits wide; these registers are designated zmm0 to zmm31. The 256 bits of lower order from the lower 16 zmm registers are superimposed onto registers ymm0 to 16. The 128 bits of lower order from the lower 16 zmm registers (the 128 bits of lower order from the ymm registers) are superimposed onto registers xmm0 to 15. The specific vector-friendly instruction format 200 operates on these superimposed register files, as illustrated in the following tables. Adjustable vector length Class Operations register Command templates that do not include the vector length field 159B A(Figure1A;U = 0) 110, 115,125, 130 zmm register (vector length is 64 bytes) B (Figure1B;U = 1) 112 zmm register (vector length is 64 bytes) Command templates which include the vector length field 159B B (Figure1B;U = 1) 117, 127 zmm, ymm or xmm register (the vector length is 64 bytes, 32 bytes or 16 bytes) depending on the vector length field 159B

[0075] In other words, the vector length field 159B selects between a maximum length and one or more other shorter lengths, each such shorter length being half the length of the preceding length; and instruction templates without the vector length field 159B operate on the maximum vector length. Furthermore, in one embodiment, the Class B instruction templates of the specific vector-friendly instruction format 200 operate on packed or scalar single / double-precision floating-point data and packed or scalar integer data. Scalar operations are operations performed on the lowest-order data element position in a zmm / ymm / xmm register; depending on the embodiment, higher-order data element positions either remain the same as before the instruction or are set to zero.

[0076] Write mask registers 315 – in the illustrated embodiment, there are 8 write mask registers (k0 to k7), each with a size of 64 bits. In an alternative embodiment, the write mask registers 315 have a size of 16 bits. As described above, in one embodiment of the invention, the vector mask register k0 cannot be used as a write mask; if the encoding that would normally specify k0 is used for a write mask, it selects a hard-wired write mask of 0xFFFF, effectively disabling write masking for that instruction.

[0077] General Purpose Register 325 - In the illustrated embodiment, there are sixteen 64-bit general purpose registers which, together with the existing x86 addressing modes, are used to address memory operands. These registers are designated RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0078] Scalar floating-point stack register file (x87 stack) 345, to which the MMX-packed integer flat register file 350 is aliased - in the illustrated embodiment, the x87 stack is a stack of eight elements used to perform scalar floating-point operations on 32- / 64- / 80-bit floating-point data using the x87 instruction set extension; while the MMX registers are used to perform operations on packed 64-bit integer data and to hold operands for some operations performed between the MMX and XMM registers.

[0079] Alternative embodiments of the invention may use wider or narrower registers. Furthermore, alternative embodiments of the invention may use more, fewer, or different register files and registers. D. Exemplary core architectures, processors and computer architectures

[0080] Processor cores can be implemented in various ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) a general-purpose in-order core intended for general-purpose computing; 2) a high-performance general-purpose out-of-order core intended for general-purpose computing; 3) a special-purpose core primarily intended for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) a CPU comprising one or more general-purpose in-order cores intended for general-purpose computing and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor comprising one or more special-purpose cores primarily intended for graphics and / or scientific (throughput) computing.Such different processors lead to different computer system architectures, which may include: 1) the coprocessor on a chip separate from the CPU; 2) the coprocessor on a separate die in the same package as a CPU; 3) the coprocessor on the same die as a CPU (in this case, such a coprocessor is sometimes referred to as special logic, such as integrated graphics and / or scientific (throughput) logic, or as special cores); and 4) a system-on-a-chip that may include, on the same die as the CPU described (sometimes referred to as the application core(s) or application processor(s)), the coprocessor described above, and additional functionalities. Exemplary core architectures are described next, followed by descriptions of exemplary processors and computer architectures.

[0081] Fig.Figure 4A is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming out-of-order output / execution pipeline according to embodiments of the invention. Fig. Figure 4B is a block diagram illustrating both an exemplary embodiment of an in-order architecture kernel and an exemplary register renaming out-of-order output / execution architecture kernel to be included in a processor according to embodiments of the invention. The boxes with solid lines from Fig.Figures 4A to B illustrate an in-order pipeline and an in-order kernel, while the optional addition of the dashed-line boxes illustrates the register renaming, out-of-order output / execution pipeline and kernel. Assuming that the in-order viewpoint is a subset of the out-of-order viewpoint, the out-of-order viewpoint is described.

[0082] In Fig. 4A comprises a processor pipeline 400, a retrieval stage 402, a length decoding stage 404, a decoding stage 406, an allocation stage 408, a renaming stage 410, a flow control stage (also known as distribution or output stage) 412, a register read / memory read stage 414, an execution stage 416, a write-back / memory write stage 418, an exception handling stage 422, and a transfer stage 424.

[0083] Fig.Figure 4B shows a processor core 490, which includes a front-end unit 430 coupled to an execution function unit 450, and both are coupled to a memory unit 470. The core 490 can be a RISC core (RISC: Reduced Instruction Set Computing), a CISC core (CISC: Complex Instruction Set Computing), a VLIW core (VLIW: Very Long Instruction Word), or a hybrid or alternative core type. Alternatively, the core 490 can be a special-purpose core, such as a network or communication core, a compression function unit, a coprocessor core, a GPGPU core (GPGPU: General Purpose Computing Graphics Processing Unit), a graphics core, or the like.

[0084] The front-end unit 430 includes a branch prediction unit 432, which is coupled to an instruction cache unit 434, which is coupled to an instruction TLB (translation lookaside buffer) 436, which is coupled to an instruction retrieval unit 438, which is coupled to a decoding unit 440. The decoding unit 440 (or decoder) can decode instructions and produce as an output: one or more microoperations, microcode entry points, microinstructions, or other instructions or control signals that have been decoded from, or otherwise reflect, or are otherwise derived from, the original instructions. The decoding unit 440 can be implemented using numerous different mechanisms.Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), read-only microcode memories (ROMs), etc. In one embodiment, the core 490 comprises a microcode ROM or other medium that stores microcode for specific macro instructions (e.g., in the decoder 440 or elsewhere within the front-end unit 430). The decoder 440 is coupled to a rename / map unit 452 in the execution unit 450.

[0085] The execution function unit 450 comprises the renaming / assignment unit 452, which is coupled to a write-out unit 454 and a set of one or more flow control units 456. The flow control unit(s) 456 represent any number of different flow controls, which include reservation stations, a central command window, etc. The flow control unit(s) 456 is / are coupled to the physical register file unit(s) 458. Each of the physical register file units 458 represents one or more physical register files, several of which store one or more different data types, such as scalar integers, scalar floating-point numbers, packed integers, packed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer which is the address of the next instruction to be executed), etc.In one embodiment, the physical register file(s) unit 458 comprises a vector register unit, a write mask register unit, and a scalar register unit. These register units can provide architectural vector registers, vector mask registers, and general-purpose registers. The physical register file(s) unit(s) 458 is / are overlapped by the write-out unit 454 to illustrate various ways in which register renaming and out-of-order execution can be implemented (e.g., using a reorder buffer (of reorder buffers) and a write-out register file (of write-out register files); using a future file (of future files), a history buffer (of history buffers), and a write-out register file (of write-out register files); using register mappings and a register pool, etc.).The write-out unit 454 and the physical register file unit(s) 458 are coupled to the execution cluster(s) 460. The execution cluster(s) 460 comprises a set of one or more execution units 462 and a set of one or more memory access units 464. The execution units 462 can perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various data types (e.g., scalar floating-point, packed integer, packed floating-point, vector count, vector floating-point). While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units, all of which perform all functions.The flow control unit(s) 456, the physical register file unit(s) 458, and the execution cluster(s) 460 are shown as possibly multiple because certain embodiments 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, each having its own flow control unit, physical register file unit(s), and / or execution cluster—and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of that pipeline has the memory access unit(s) 464). It is also understood that, when separate pipelines are used, one or more of these pipelines may be out-of-order output / execution, and the rest may be in-order.

[0086] The set of memory access units 464 is coupled to the memory unit 470, which comprises a data TLB unit 472, which is coupled to a data cache unit 474, which is coupled to a level 2 (L2) cache unit 476. In an exemplary embodiment, the memory access units 464 can comprise a load unit, an address storage unit, and a data storage unit, each of which is coupled to the data TLB unit 472 in the memory unit 470. The instruction cache unit 434 is further coupled to a level 2 (L2) cache unit 476 in the memory unit 470. The L2 cache unit 476 is connected to one or more other cache levels and finally to main memory.

[0087] For example, the exemplary register rename out-of-order output / execution core architecture can implement pipeline 400 as follows: 1) the instruction fetcher 438 performs fetch and length decode stages 402 and 404; 2) the decoder 440 performs decode stage 406; 3) the rename / map unit 452 performs mapping stage 408 and rename stage 410; 4) the flow control unit(s) 456 perform flow control stage 412; 5) the physical register file unit(s) 458 and the memory unit 470 perform register read / memory read stage 414; the execution cluster 460 performs execution stage 416; 6) The storage unit 470 and the physical register file unit(s) 458 perform the write-back / memory write stage 418;7) Different units can be involved in the exception handling stage 422 and 8) the write-out unit 454 and the physical register file unit(s) 458 carry out the transfer stage 424.;

[0088] The Kernel 490 can support one or more instruction sets (e.g., the x86 instruction set (with some extensions added in newer versions); the MIPS instruction set from MIPS Technologies in Sunnyvale, CA; the ARM instruction set (with optional additional extensions such as NEON) from ARM Holdings in Sunnyvale, CA), which includes the instructions described here. In one embodiment, the Kernel 490 includes logic to support an instruction set extension using packed data (e.g., AVX1, AVX2), enabling operations used by many multimedia applications to be performed using packed data.

[0089] It is understood that the core can support multithreading (executing two or more parallel sets of operations or threads) and can do so in a variety of ways, including time-slice multithreading, simultaneous multithreading (where a single physical core provides a logical core for each of the threads that the physical core handles simultaneously in multithreading), or a combination thereof (e.g., time-slice retrieval and decoding, followed by simultaneous multithreading, as in Intel® Hyperthreading technology).

[0090] While register renaming is described in the context of out-of-order execution, it is understood that register renaming can also be used in an in-order architecture. While the illustrated embodiment of the processor also includes separate instruction and data cache units 434 / 474 and a shared L2 cache unit 476, alternative embodiments may have a single internal cache for both instructions and data, such as an internal Level 1 (L1) cache or multiple levels of an internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache, which is external with respect to the core and / or the processor. Alternatively, the entire cache may be external with respect to the core and / or the processor.

[0091] Fig.Figures 5A to B illustrate a block diagram of a more specific, exemplary in-order core architecture, where the core would be one of several logic blocks (including other cores of the same and / or different types) on a single chip. The logic blocks communicate through a high-bandwidth interconnect network (e.g., a ring network) with fixed functional logic, memory I / O interfaces, and other necessary I / O logic, depending on the application.

[0092] Fig.Figure 5A is a block diagram of a single processor core together with its connection to the on-die interconnect network 502 and with its local subset of the Level 2 (L2) cache 504 according to embodiments of the invention. In one embodiment, an instruction decoder 500 supports the x86 instruction set with an instruction set extension for packed data. An L1 cache 506 enables low-latency access to cache memory in the scalar and vector units. While in one embodiment (to simplify the design) a scalar unit 508 and a vector unit 510 use separate register sets (scalar register 512 and vector register 514, respectively), and data transferred between them is written to a memory and then read back from a Level 1 (L1) cache 506, alternative embodiments of the invention may use a different approach (e.g.,(use a single register set or include a communication path that allows data to be transferred between the two register files without being written and read back).

[0093] The local subset of the L2 cache 504 is part of a global L2 cache, which is divided into separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset of the L2 cache 504. Data read by a processor core is stored in its L2 cache subset 504 and can be accessed quickly in parallel by other processor cores accessing their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset 504 and is cleared from other subsets as needed. The ring network ensures the coherence of shared data. The ring network is bidirectional to allow agents, such as processor cores, L2 caches, and other logic blocks, to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0094] Fig. 5B is an extended view of a portion of the processor core in Fig. 5A according to embodiments of the invention. Fig. 5B includes an L1 data cache 506A, which is part of the L1 cache 504, as well as further details regarding the vector unit 510 and the vector registers 514. Specifically, the vector unit 510 is a 16-width vector processing unit (VPU) (see the 16-width ALU 528) that executes one or more integer instructions, single-precision floating-point instructions, and double-precision floating-point instructions. The VPU supports swizzling of register inputs with the swizzling unit 520, numeric conversion with numeric conversion units 522A through B, and replication with the replication unit 524 on memory input. Write mask registers 526 enable prediction of resulting vector writes.

[0095] Fig.Figure 6 is a block diagram of a 600-series processor, which may have more than one core, an integrated memory controller, and integrated graphics, according to embodiments of the invention. The boxes with solid lines in Fig. Figure 6 illustrates a processor 600 with a single core 602A, a system agent 610, a set of one or more bus control units 616, while the optional addition of the boxes with a broken line illustrates an alternative processor 600 with multiple cores 602A to N, a set of one or more integrated memory control unit(s) 614 in the system agent unit 610, and special logic 608.

[0096] Accordingly, different implementations of the 600 processor can include: 1) a CPU, wherein the special logic 608 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores), and wherein the cores 602A to N are one or more general-purpose cores (e.g., general-purpose in-order cores, general-purpose out-of-order cores, a combination of both); 2) a coprocessor, wherein the cores 602A to N are a large number of general-purpose cores primarily dedicated to graphics and / or scientific (throughput) functions; and 3) a coprocessor, wherein the cores 602A to N are a large number of general-purpose in-order cores.Accordingly, the Processor 600 can be a general-purpose processor, a coprocessor, or a specialized processor, such as a network or communications processor, a compression unit, a graphics processor, a GPGPU (General Purpose Graphics Processing Unit), a high-throughput MIC coprocessor (MIC: Many Integrated Core) (comprising 30 or more cores), an embedded processor, or the like. The processor can be implemented on one or more chips. The Processor 600 can be part of, and / or implemented on, one or more substrates utilizing any number of process technologies, such as BiCMOS, CMOS, or NMOS.

[0097] The memory hierarchy comprises one or more levels of an in-core cache, a set or one or more shared cache units 606, and external memory (not shown) coupled to the set of integrated memory control units 614. The set of shared cache units 606 may include one or more mid-level caches, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other levels of a cache, a last-level cache (LLC), and / or combinations thereof. While in one embodiment a ring-based interconnect unit 612 connects the integrated graphics logic 608, the set of shared cache units 606, and the system agent unit 610 / integrated memory control unit(s) 614, alternative embodiments may employ any number of well-known techniques for interconnecting such units.In one embodiment, coherence is maintained between one or more cache units 606 and cores 602-A to N.

[0098] In some embodiments, one or more of the cores 602A to N are capable of multi-threaded processing. The system agent 610 comprises components that coordinate and operate the cores 602A to N. The system agent unit 610 can, for example, include a power control unit (PCU) and a display unit. The PCU can be or include logic and components required to regulate the power state of the cores 602A to N and the integrated graphics logic 608. The display unit is used to drive one or more externally connected displays.

[0099] The 602A to N cores can be homogeneous or heterogeneous with respect to an architectural instruction set; i.e., two or more of the 602A to N cores may be capable of executing the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set.

[0100] Fig. 7, Fig. 8, Fig. 9 to Fig.Figure 10 are block diagrams of exemplary computer architectures. Other system designs and configurations known in the technology for laptops, desktops, handheld PCs, personal digital assistants, technical workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, portable devices, and various other electronic devices are also suitable. In general, a wide variety of systems or electronic devices capable of incorporating a processor and / or other execution logic, as disclosed herein, are generally suitable.

[0101] Now, with reference to Fig.Figure 7 shows a block diagram of a system 700 according to an embodiment of the present invention. The system 700 can comprise one or more processors 710, 715, which are coupled to a control hub 720. In one embodiment, the control hub 720 comprises a graphics memory controller hub (GMCH) 790 and an input / output hub (IOH) 750 (which may be located on separate chips); the GMCH 790 comprises memory and graphics controllers to which memory 740 and a coprocessor 745 are coupled; The IOH 750 couples input / output (I / O) devices 760 to the GMCH 790. Alternatively, one or both of the memory and graphics controllers are integrated into the processor (as described here), the memory 740 and the coprocessor 745 are directly coupled to the processor 710, and the control hub 720 is integrated into a single chip with the IOH 750.

[0102] The optional nature of additional 715 processors is in Fig. 7 marked with broken lines. Each 710, 715 processor can contain one or more of the processing cores described here and can be a version of the 600 processor.

[0103] The memory 740 can be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of both. In at least one embodiment, the control hub 720 communicates with the processor(s) 710, 715 via a multipoint bus, such as a front-side bus (FSB), a point-to-point interface, such as QuickPath Interconnect (QPI), or a similar connection 795.

[0104] In one embodiment, the coprocessor 745 is a specialized processor, such as a high-throughput MIC processor, a network or communications processor, a compression unit, a graphics processor, a GPGPU, an embedded processor, or the like. In one embodiment, the control hub 720 may include an integrated graphics accelerator.

[0105] There can be a variety of differences with respect to a spectrum of performance metrics, including architectural, microarchitecture, thermal, power consumption characteristics and the like, between the physical resources 710, 715.

[0106] In one embodiment, the processor 710 executes instructions that control general-purpose data processing operations. These instructions may contain embedded coprocessor instructions. The processor 710 recognizes these coprocessor instructions as being of a type that must be executed by the attached coprocessor 745. Accordingly, the processor 710 outputs these coprocessor instructions (or control signals representing coprocessor instructions) to the coprocessor 745 via a coprocessor bus or other intermediate connection. The coprocessor(s) 745 receives and executes the received coprocessor instructions.

[0107] Now, with reference to Fig. Figure 8 shows a block diagram of a first, more specific exemplary system 800 according to an embodiment of the present invention. As shown in Fig.As shown in Figure 8, the multiprocessor system 800 is a point-to-point interconnect system and comprises a first processor 870 and a second processor 880, which are coupled via a point-to-point interconnect 850. Each of the processors 870 and 880 can be a version of the processor 600. In one embodiment of the invention, the processors 870 and 880 are the processors 710 and 715, respectively, while the coprocessor 838 is the coprocessor 745. In another embodiment, the processors 870 and 880 are the processor 710 and the coprocessor 745, respectively.

[0108] Processors 870 and 880 are shown including IMC (Integrated Memory Controller) units 872 and 882, respectively. Processor 870 also includes, as part of its bus control units, the point-to-point (PP) interfaces 876 and 878; similarly, the second processor, 880, includes the PP interfaces 886 and 888. Processors 870 and 880 can exchange information via a point-to-point (PP) interface 850 using the PP interface circuits 878 and 888. As shown in Fig. As shown in Figure 8, the IMC 872 and 882 couple the processors with respective memories, namely a memory 832 and a memory 834, which can be parts of a main memory that are locally bound to the respective processors.

[0109] The processors 870 and 880 can each exchange information with a chipset 890 via individual PP interfaces 852 and 854 using point-to-point interface circuits 876, 894, 886, and 898. The chipset 890 can optionally exchange information with the coprocessor 838 via a high-performance interface 839. In one embodiment, the coprocessor 838 is a special-purpose processor, such as a high-throughput MIC processor, a network or communications processor, a compression functional unit, a GPGPU, an embedded processor, or the like.

[0110] A shared cache (not shown) can be located in both processors or outside of both processors, but connected to the processors via a PP intermediary, so that local cache information of one or both processors can be stored in the shared cache when one processor is put into a low-power mode.

[0111] The chipset 890 can be coupled to a first bus 816 via an interface 896. In one embodiment, the first bus 816 can be a PCI bus (PCI: Peripheral Component Interconnect) or a bus such as a PCI Express bus or another third-generation I / O intermediate bus, although the scope of protection of the present invention is not limited in this way.

[0112] As in Fig.As shown in Figure 8, various I / O devices 814, together with a bus bridge 818 which couples the first bus 816 to a second bus 820, can be coupled to the first bus 816. In one embodiment, one or more additional processors 815, such as coprocessors, high-throughput MIC processors, GPGPUs, accelerators (such as graphics accelerators or DSP units (DSP: Digital Signal Processing)), field-programmable gate arrays, or any other processor, are coupled to the first bus 816. In one embodiment, the second bus 820 can be an LPC bus (LPC: Low Pin Count).Various devices can be coupled to a second bus 820, which in one embodiment includes, for example, a keyboard and / or a mouse 822, communication devices 827, and a storage unit 828, such as a disk drive or other mass storage device, which can contain commands / code and data 830. Furthermore, an audio I / O 824 can be coupled to the second bus 820. It should be noted that other architectures are possible. For example, a system can use the point-to-point architecture of the... Fig. 8. Implement a multipoint bus or other similar architecture.

[0113] Now, with reference to Fig. Figure 9 shows a block diagram of a second, more specific exemplary system 900 according to an embodiment of the present invention. Identical elements in Fig. 8 and Fig. 9 bear the same reference numbers, and certain aspects of the Fig.8 were in Fig. 9 omitted to obscure other aspects of the Fig. 9 to avoid.

[0114] Fig. Figure 9 illustrates that the 870 and 880 processors can include integrated memory and I / O control logic (CL) 872 and 882, respectively. Accordingly, the CL 872 and 882 include integrated memory control units and I / O control logic. Fig. Figure 9 further illustrates that not only are the memory modules 832 and 834 coupled with the control logic modules 872 and 882, but also that the I / O modules 914 are coupled with the control logic modules 872 and 882. Obsolete I / O modules 915 are coupled with the chipset 890.

[0115] Now, with reference to Fig. Figure 10 shows a block diagram of a SoC 1000 according to an embodiment of the present invention. Identical elements in Fig.Six bear the same reference numbers. Additionally, boxes with broken lines are optional features on more advanced SoCs. Fig.10 is a connection unit(s) 1002 coupled with: an application processor 1010, comprising a set of one or more cores 202A to N and shared cache unit(s) 606; a system agent unit 610; a bus control unit 616; an integrated memory control unit 614; a set of one or more coprocessors 1020, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; an SRAM unit (SRAM - static random access memory) 1030; a DMA unit (DMA - direct access memory) 1032; and a display unit 1040 for coupling with one or more external displays. In one embodiment, the coprocessor(s) 1020 comprises a special processor, such as a network or communications processor, a compression functional unit, a GPGPU, a high-throughput MIC processor, an embedded processor or the like.

[0116] Embodiments of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of such implementation approaches. Embodiments of the invention can be implemented as computer programs or program code that are executed on programmable systems comprising at least one processor, a memory system (including volatile and non-volatile memory and / or memory elements), at least one input device, and at least one output device.

[0117] Program code, such as the one in Fig.Code 830, illustrated in Figure 8, can be applied to input commands to perform the functions described herein and to generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system comprises any system that includes a processor, such as a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0118] The program code can be implemented in a higher-level procedural or object-oriented programming language to communicate with a processing system. If desired, the program code can also be implemented in assembly or machine language. In fact, the protection mechanisms described here are not limited to a specific programming language. In any case, the language can be compiled or interpreted.

[0119] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium representing different logic within the processor. When read by a machine, these instructions cause the machine to fabricate logic to perform the techniques described herein. Such representations, known as "IP kernels," can be stored on a tangible machine-readable medium and delivered to various customers or manufacturing facilities to be loaded into the fabrication machines that actually produce the logic or the processor.

[0120] Such machine-readable storage media may, without limitation, include non-volatile tangible arrangements of articles produced or formed by a machine or apparatus, including storage media such as hard disks, any other type of disk, including floppy disks, optical disks, CD-ROM, CD-RW and magneto-optical disks, semiconductor devices such as read-only memory (ROM), random-access memory (RAM) such as dynamic random-access memory (DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase-change memory (PCM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

[0121] Accordingly, embodiments of the invention also include non-volatile, tangible, machine-readable media containing instructions or design data, such as HDL (Hardware Description Language), which defines structures, circuits, devices, processors, and / or system features described herein. Such embodiments can also be referred to as program products.

[0122] In some cases, an instruction converter can be used to transform an instruction from a source instruction set to a target instruction set. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), reshape, emulate, or otherwise convert an instruction into one or more other instructions to be processed by the kernel. The instruction converter can be implemented in software, hardware, firmware, or a combination thereof. The instruction converter can reside on the processor, off the processor, or partly on and partly off the processor.

[0123] Fig.Figure 11 is a block diagram that contrasts the use of a software instruction converter for converting binary instructions in a source instruction set to binary instructions in a target instruction set according to embodiments of the invention. In the illustrated embodiment, the instruction converter is a software instruction converter, although alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig.Figure 11 shows a program in a higher-level language 1102, which can be compiled using an x86 compiler 1104 to produce x86 binary code 1106, which can be executed natively by a processor with at least one x86 instruction set core 1116. The processor with at least one x86 instruction set core 1116 represents any processor that can perform substantially the same functions as an Intel processor with at least one x86 instruction set core by compliantly executing or otherwise processing (1) a substantial part of the Intel x86 instruction set core's instruction set or (2) object code versions of applications or other software intended to run on an Intel processor with at least one x86 instruction set core, to achieve substantially the same result as an Intel processor with at least one x86 instruction set core.The x86 compiler 1104 represents a compiler that can be operated to generate x86 binary code 1106 (e.g., object code), which can be executed with or without additional linking processing on a processor with at least one x86 instruction set core 1116. Likewise, shows... Fig.11, that the program in the higher language 1102 can be compiled using an alternative instruction set compiler 1108 to generate alternative instruction set binary code 1110, which can be executed natively by a processor without at least one x86 instruction set core 1114 (e.g., a processor with cores executing the MIPS instruction set from MIPS Technologies in Sunnyvale, CA, and / or the ARM instruction set from ARM Holdings in Sunnyvale, CA). The instruction converter 1112 is used to convert the x86 binary code 1106 into code that can be executed natively by the processor without an x86 instruction set core 1114. This converted code is likely not the same as the alternative instruction set binary code 1110, since an instruction converter capable of doing so is difficult to manufacture; However, the converted code will perform the general operation and will consist of commands from the alternative instruction set.Accordingly, instruction converter 1112 represents software, firmware, hardware or a combination thereof which, through emulation, simulation or any other process, enables a processor or other electronic device which does not have a processor or core with an x86 instruction set to execute the x86 binary code 1106. DEVICE AND METHOD FOR SLOW-BLOWING SYNCHRONED PAGE TABLE UPDATES

[0124] As described, in a shared memory system, both caches and TLBs must be kept coherent to provide all threads with the same memory view. One of the main reasons for maintaining coherence for TLBs is that it is difficult to keep the overall data state coherent when two different CPUs have different address translations for the same page. Keeping TLBs coherent is relatively inexpensive when page table entries (PTEs) change very infrequently, as is the case today. Current systems use a combination of inert PTE reuse, which is augmented on rare occasions by immediate TLB kills. TLB kills are enormously resource-intensive, but on current systems, they are the only way to propagate a PTE change in a synchronous manner.It is expected that the frequency of PTE changes will increase in the near future, necessitating a more efficient mechanism for propagating PTE changes.

[0125] One embodiment of the invention accelerates TLB processing by adding hardware to the TLBs to perform a synchronous TLB invalidation of a specific virtual address and a new instruction to control this hardware. Furthermore, some embodiments of the invention combine a mutex with this instruction to ensure that only one thread in the system will attempt to modify a given page table entry (PTE) at any given time.

[0126] Fig.Figure 12 illustrates an architecture on which embodiments of the invention can be implemented, comprising a TLB 1220 for cache storage of virtual-to-physical address translations, a memory hierarchy 1230 comprising system memory and one or more cache levels, and multiple cores 1210 to 1211 for executing instructions and processing data. Although illustrated as integrated within the core 1210, some architectures may choose to separate it so that one TLB serves more than one execution unit (core). To improve the speed of address translation, the TLB 1220 may include a fixed number of slots containing page table entries, each mapping a virtual address to a physical address in system memory.When attempting to access a specific page within the virtual address space, the 1210 core performs a TLB lookup, as illustrated. If the virtual-to-physical mapping exists in the 1220 TLB, then the physical address is provided to the 1210 memory management unit, which can then access the 1230 memory hierarchy using that physical address.

[0127] If the virtual-to-physical mapping is not present in the TLB 1220, this results in a "TLB misaccess." In one embodiment, the kernel 1210 responds to a TLB misaccess by accessing a page search unit 1223, which provides page search services. Although illustrated as a separate unit, in one embodiment the page search unit 1223 may be part of the TLB 1220 and / or the kernel 1210. A page search involves looking up the address mapping in the page table (which is stored in system memory) to determine if a mapping exists. If one exists, in one embodiment it is written back to the TLB 1220. Subsequent execution of the failed instruction results in a TLB hit, and the memory access continues.If no image exists, then an error exception can be initiated by a page defect handler 1222 (which in one embodiment can be implemented as software).

[0128] In one embodiment, the TLB 1220 is implemented as a Content Addressable Memory (CAM), although the underlying principles of the invention are not limited to a specific TLB type. The TLB is a component that is well understood by those skilled in the art, and therefore its basic operation is not described in detail here to avoid obscuring the underlying principles of the invention.

[0129] As in Fig.Figure 12 illustrates an embodiment of the invention comprising several new hardware components, which include a PTE (INVPTE) invalidation execution logic 1214 within the core 1210 to execute an INVPTE command described herein, and a fence command and TLB signaling logic 1216 to receive a signal from the TLB 1220, insert a fence operation (e.g. a fence uop), and signal the TLB 1220 when the fence is posted out. Hardware components in the TLB 1220 include a PTE invalidation request handling module 1221 to receive PTE invalidation request messages (PTE_INV_REQ) in order to invalidate the specified TLB entry in response, send a signal to the core 1210 and, once the core has signaled back, send a reply PTE_INV_REP to the initiator.Additionally, the TLB 1220 includes an INVPTE flow control unit 1224 (which can also be implemented in the core 1210) to send PTE_INV_REQ messages and wait for PTE_INV_REP replies when an INVPTE command is executed, as described below.

[0130] Fig.Figure 13 illustrates an example according to an embodiment in which an "initiator" thread 1300 (executing, for example, on core 1210) attempts to make a change to a page table entry (PTE) and is willing to wait for the change to become visible to all other threads in the system before resuming execution; that is, it wants to use a synchronous method to make a PTE change. In Figure 1301, the initiator thread 1300 first detects a mutex (or an equivalent common exclude / lock operation) associated with a given virtual page V. In one embodiment, this is done in software and ensures that only one thread makes a change to the PTE of that page at any given time.If there are too many pages to manage one mutex per page, a small set of mutexes can be allocated, and a hashing function can be used to map V to one of the mutexes. This is a common practice for reducing the memory footprint of a matrix of mutexes, which does not affect correctness but can lead to some unnecessary waiting if two threads try to work concurrently on different pages that are mapped to the same mutex. Using a single mutex to prevent concurrent threads from competing when performing a synchronous TLB launch need not be limited to a single PTE, and software may also choose to bundle the launch of a collection of PTEs for better efficiency.

[0131] In implementation 1302, the initiator thread 1300 modifies a PTE of a virtual page V, which is securely protected by the mutex. It then determines the number of other cores / agents 1320 that need to be notified of the modification of a PTE of virtual page V, identified by a response count (RESP_CNT). In one embodiment, it also determines the identity of these cores / agents, which are encoded in a bit mask ("mask"). The RESP_CNT is typically the number of cores / agents in the system minus one (for the initiator 1300), but it can be smaller if it can be determined that a subset of cores / agents cannot cache a PTE of virtual page V in their TLBs.

[0132] Next, the initiator 1300 executes a PTE invalidation instruction, INVPTE, at 1304. In one embodiment, each TLB 1310 of a responding kernel / agent receives the PTE invalidation request (PTE_INV_REQ(V)), which causes the TLBs at 1312 to invalidate entries for the virtual page V, and sends a reply indicating the invalidation at 1313. The instruction takes the address of the virtual page V, the reply counter, and the reply mask. The instruction can be primarily executed in execution logic integrated into the L1 cache control device 1212, the TLB 1220, or the kernel 1210 itself. This logic 1221 is in Fig. Figure 12 within the TLB 1220 illustrates how to encapsulate most of the new hardware. In one embodiment, the instruction serializes subsequent instructions in program order; they must wait for this instruction to be unchecked before they can begin execution.

[0133] In one embodiment, the instruction initializes the INVPTE flow control unit 1224 with the RESP_CNT and the mask. At 1306, the flow control unit 1224 then sends PTE invalidation requests for page V (PTE_INV_REQ(V)) according to the mask to the TLBs 1310 of other cores and waits for replies (PTE_INV_REP(V)), which are shown at 1313. Upon arrival of each reply, the TLB 1220 (CNT) decrements a counter of the number of replies it is waiting for at 1308 and checks at 1307 whether this number has reached zero. If so, it returns control to the core, releasing the mutex for virtual page V at 1309.

[0134] This ensures that all threads in the system use the new version of the PTE for virtual page V. Consequently, the software on the kernel releases the mutex for virtual page V and continues execution. The procedure just described presents a complication on kernels with out-of-order execution. The problem is that when the TLB of a responding kernel receives a PTE_INV_REQ, it may contain instructions in the pipeline that have already looked up the old version of the PTE for V but may not have completed (e.g., an L2 misaccess). To ensure that the initiator is not prematurely informed that use of the old version has ended, all such instructions must be completed (or cleared).

[0135] Fig.Figure 14 illustrates an embodiment that overcomes this challenge. Specifically, upon receiving a PTE_INV_REQ at 1311, the TLB notifies the core, which inserts a fence uop into the uop stream at 1401. At 1402, uops subsequently entering the pipeline must wait for the fence to be cleared before accessing the TLB. Once the fence is cleared, the core notifies the TLB, which then sends the PTE_INV_REP at 1313.

[0136] Possible optimizations to the embodiments of the invention include the following. First, with current software-based interprocess interrupt (IPI)-based TLB kills, the software can maintain a clearing notification mapping to avoid having to synchronize with all other CPUs / cores if the software has already taken steps to reduce the number of CPUs / cores that need to participate in a remote kill. This would involve clearing some bits from the mask for the INVPTE instruction. Additionally, in a multi-core, multi-socket system, each socket can act as a remote proxy for the other sockets to eliminate the invalidations described above, thus reducing the number of inter-socket signals to 1. Some centralized hardware, e.g.,One of the memory control devices or a shared lowest-level cache (LLC) can forward the invalidation requests to the cores in the socket, collect the responses, and send a single "group" response back to the initiator. Finally, software can implement algorithms for opportunistic bundling of multiple pages for synchronous kills to amortize the additional overhead of such kills during use of the above mechanism, so that its already reduced cost is further distributed among multiple remapping operations.

[0137] The embodiments of the invention offer superior performance compared to current methods for synchronous PTE updates that rely on interprocessor interrupts, which are extremely resource-intensive for both the initiator of a change and other threads in the system. These embodiments enable significantly more efficient synchronous PTE updates at very moderate hardware costs and with very moderate complexity.

[0138] The preceding specification describes the embodiments of the invention with reference to specific exemplary embodiments thereof. However, it is obvious that various modifications and changes can be made to them without deviating from the broader spirit and scope of protection of the invention, as set forth in the appended claims. Accordingly, the description and the drawings are to be viewed in an exemplary rather than a limiting sense.

[0139] Embodiments of the invention may comprise various steps, which have been described above. The steps may be embodied as machine-executable instructions, which can be used to cause a general-purpose or specialized processor to perform the steps. Alternatively, these steps may be performed by specific hardware components containing hard-wired logic for performing the steps, or by any combination of programmed computer components and customized hardware components.

[0140] As described here, instructions can refer to specific hardware configurations, such as application-specific integrated circuits (ASICs), configured to perform certain operations or possess predefined functionality or software instructions stored in memory embodied in a non-volatile, machine-readable medium. Thus, the methods shown in the figures can be implemented using code and data stored and executed on one or more electronic devices (e.g., a terminal, a network element, etc.). Such electronic devices store and communicate (internally and / or with other electronic devices via a network) code and data using machine-readable computer media, such as non-volatile, machine-readable computer storage media (e.g., USB flash drives).magnetic hard disks; optical hard disks; random access memory; read-only memory; flash memory devices; phase-change memory) and volatile machine-readable computer communication media (e.g., signals propagating electrically, optically, acoustically, or otherwise—such as carrier waves, infrared signals, digital signals, etc.). In addition, such electronic devices typically include a set of one or more processors coupled with one or more other components, such as one or more storage devices (non-volatile machine-readable storage media), user input / output devices (e.g., a keyboard, touchscreen, and / or display), and network connections. The coupling of the set of processors and other components is typically achieved through one or more buses and bridges (also known as bus controllers).The storage device and the signals carrying network traffic each represent one or more machine-readable storage media and machine-readable communication media. Thus, the storage device of a given electronic device typically stores code and / or data for execution on the set of one or more processors of that electronic device. Of course, one or more parts of an embodiment of the invention can be implemented using different combinations of software, firmware, and / or hardware. Throughout this detailed description, numerous specific details have been set forth for the purpose of providing a comprehensive understanding of the present invention. However, it is obvious to those skilled in the art that the invention can be implemented in practice without some of these specific details.In certain cases, well-known structures and functions were not described in detail to avoid obscuring the subject matter of the present invention. Accordingly, the scope of protection and the inventive concept must be assessed with regard to the following claims.

Claims

[1] Processor (870, 880), comprising the following: multiple cores (1210, 1211) to execute instructions and process data; one or more translation buffers, TLBs, (1220), comprising multiple entries to accommodate address translations from virtual to physical, which are usable by at least one of the multiple cores (1210, 1211) when executing instructions; a page table entry, PTE, invalidation circuit (1214) to execute a PTE invalidation instruction on a first core to invalidate a first PTE in TLBs (1220) of other cores, wherein the PTE invalidation circuit (1214), in response to an execution of the PTE invalidation instruction, determines a number of other TLBs (1220) of other cores which need to be notified of the PTE invalidation, transmits PTE invalidation messages to the other TLBs (1220), and waits for replies; a lock-switching complex to allow a thread to lock the first PTE in the first TLB (1220) to ensure that only one thread can modify the first PTE at any given time, wherein the first TLB (1220) serves to modify the first PTE when the thread acquires the lock, and wherein the lock-switching complex releases the lock on the first PTE in response to receiving replies from all the other TLBs (1220), wherein each TLB (1220) includes a PTE invalidation request treatment circuit complex (1221) to receive invalidation requests transmitted from other TLBs (1220), wherein the invalidation request treatment circuit complex (1221) in response causes the TLBs (1220) to invalidate one or more PTEs identified in the invalidation requests and transmits a reply indicating the invalidation; and a PTE invalidation sequence control circuit (1224) which is to be programmed with a counter value initially set to the number of other TLBs (1220) which need to be notified, wherein the PTE invalidation sequence control circuit (1224) decrements the counter value upon receiving each reply from each of the other TLBs (1220), wherein the blocking circuit complex releases the block when the counter value has been decremented to a threshold value. [2] Processor (870, 880) according to claim 1, wherein the lock-switch complex serves to implement a mutex operation to obtain the lock on the first PTE. [3] Processor (870, 880) according to claim 1, wherein a mask value must be used to uniquely identify each of the other TLBs (1220) which is to be notified. [4] Processor (870, 880) according to claim 1, further comprising: Fence instruction logic (1216) of each of the other cores to insert a fence operation into an instruction stream to cause all instructions in a pipeline of the other cores to wait until the fence operation is booked out before accessing the TLBs (1220) of each of the other cores. [5] Processor (870, 880) according to claim 4, wherein the replies from the TLBs (1220) of the other cores are only to be sent after the fence operation has been booked out. [6] Procedure which includes the following: Storing multiple address translations from virtual to physical in a translation buffer, TLB, which can be used by the set of one or more kernels when executing instructions; Locking a first page table entry (PTE) in the TLB to ensure that only one thread can modify the first PTE at any given time, with the TLB serving to modify the first PTE upon acquiring the lock; Executing a PTE invalidation instruction on a first core to invalidate the first PTE in other TLBs of other cores, wherein, in response to the execution of the PTE invalidation instruction, the PTE invalidation circuit determines a number of other TLBs of other cores that need to be notified of the PTE invalidation, transmits PTE invalidation messages to the other TLBs, and waits for replies; and Releasing the lock on the first PTE in response to receiving replies from all the other TLBs, wherein each TLB includes a PTE invalidation request handling circuit complex to receive invalidation requests transmitted from other TLBs, wherein the invalidation request handling circuit complex in response causes the TLBs to invalidate one or more PTEs identified in the invalidation requests and transmit a reply indicating the invalidation, and wherein the method further comprises a PTE invalidation sequence control circuit which is to be programmed with a counter value which is initially set to the number of other TLBs which need to be notified, wherein the PTE invalidation sequence control circuit decrements the counter value upon receiving each reply from each of the other TLBs, wherein the lock-out complex releases the lock when the counter value has been decremented to a threshold value. [7] Method according to claim 6, wherein the blocking circuit complex serves to implement a mutex operation to obtain the block on the first PTE. [8] Method according to claim 6, wherein a mask value must be used to uniquely identify each of the other TLBs which is to be notified. [9] The method of claim 6, further comprising: Fence instruction logic of each of the other cores to insert a fence operation into an instruction stream to cause all instructions in a pipeline of the other cores to wait until the fence operation is booked out before accessing the TLBs of each of the other cores. [10] Method according to claim 9, wherein the replies from the TLBs of the other cores are only to be sent after the fence operation has been booked out. [11] System (800), which includes the following: a memory (834) to store instructions and data; a processor (870, 880) to execute the instructions and process the data; a graphics processor (838) to perform graphics operations in response to graphics commands; a network interface (827) to receive and transmit data over a network; an interface (822) for receiving user input from a mouse or position marker control device, wherein the multiple cores (1210, 1211) execute the commands and process the data in response to the user input; The processor (870, 880) includes the following: multiple cores (1210, 1211) to execute instructions and process data; a translation buffer, TLB, (1220), comprising multiple entries to accommodate address translations from virtual to physical, which can be used by at least one of the multiple cores (1210, 1211) when executing instructions; a locking circuit complex to allow a thread to lock a first page table entry, PTE, in which TLB (1220) locks to ensure that only one thread can modify the first PTE at any given time, with TLB (1220) serving to modify the first PTE when the thread acquires the lock; a PTE invalidation circuit (1214) to execute a PTE invalidation instruction on a first core to invalidate the first PTE in other TLBs (1220) of other cores, wherein, in response to an execution of the PTE invalidation instruction, the PTE invalidation circuit (1214) determines a number of other TLBs of other cores that need to be notified of the PTE invalidation, transmits PTE invalidation messages to the other TLBs (1220), and waits for replies; and The blocking circuit complex releases the lock on the first PTE in response to receiving replies from all the other TLBs (1220), wherein each TLB (1220) includes a PTE invalidation request treatment circuit complex (1221) to receive invalidation requests transmitted from other TLBs (1220), wherein the invalidation request treatment circuit complex (1221) in response causes the TLBs (1220) to invalidate one or more PTEs identified in the invalidation requests and transmits a response indicating the invalidation, and wherein the system further comprises a PTE invalidation sequence control circuit (1224) which is to be programmed with a counter value initially set to the number of other TLBs (1220) which need to be notified, wherein the PTE invalidation sequence control circuit (1224) decrements the counter value upon receiving each reply from each of the other TLBs (1220), wherein the lock circuit complex releases the lock when the counter value has been decremented to a threshold value. [12] System (800) according to claim 11, wherein the blocking circuit complex serves to implement a mutex operation to obtain the block on the first PTE. [13] System (800) according to claim 11, wherein a mask value must be used to uniquely identify each of the other TLBs (1220) which is to be notified. [14] System (800) according to claim 11, further comprising: Fence instruction logic (1216) of each of the other cores to insert a fence operation into an instruction stream to cause all instructions in a pipeline of the other cores to wait until the fence operation is booked out before accessing the TLBs (1220) of each of the other cores. [15] System (800) according to claim 14, wherein the replies from the TLBs (1220) of the other cores are only to be sent after the fence operation has been completed.

Images