Hybrid performance monitoring unit (PMU) enumeration

Abstract

Examples of hybrid (heterogeneous) performance monitoring unit enumeration are detailed herein. In some examples, a processor supports instructions enumerated by a performance monitoring unit. For example, a processor includes decoder circuitry to decode an instance of a single instruction, the single instruction including a field for an opcode; and execution circuitry to execute the decoded instruction in accordance with the opcode to return processor identification and feature information, the processor identification and feature information including enumeration of heterogeneous performance monitoring unit capabilities.

Description

Background Art

[0001] Performance monitoring of processors (e.g., using techniques such as Intel's Precise Event Based Sampling (PEBS)) can be used for characterization, debugging, and tuning software and program code. However, the amount of data to analyze can be very large. High-performance processors go to great lengths to keep their execution pipelines busy, applying techniques such as large-window out-of-order execution, speculative speculation, and hardware prefetching. These techniques complicate the task of software tuning and result in changes in the cost of common monitored events. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0003] Figure 1 is a block diagram illustrating a processor that generates and stores PEBS and NPEBS records according to an embodiment.

[0004] Figure 2 An embodiment of a process of generating and storing PEBS records in a storage buffer and storing the storage buffer to a PEBS trace file is shown.

[0005] Figure 3 An embodiment of a process for programming a PEBS handler circuit to monitor processor performance and generate PEBS records for storage in a PEBS storage buffer and then in a PEBS trace file is shown.

[0006] Figure 4 An embodiment of a method using hardware and firmware to add a performance cost to a sample (eg, PEBS) recording is shown.

[0007] Figure 5 An example of CPUID instruction execution is shown.

[0008] Figure 6 An example method executed by a processor to process a processor identification and characteristic information (CPUID) instruction is shown.

[0009] Figure 7 An example system configuration with three cores is shown, where core 1 and core 3 each have 4 counters, and core 2 has only 2 counters.

[0010] Figure 8 An example system configuration with three cores is shown, where core 1 and core 3 each have 4 counters, and core 2 has only 2 counters.

[0011] Fig. 9An example system is shown in which three OSs are shown running simultaneously on a system with a hypervisor (ie, virtualization enabled). OS1 runs with maximum privileges (ie, full trust), OS 2 runs with medium privileges, and OS 3 runs with minimum privileges (ie, untrusted).

[0012] Fig.10 An example of computing hardware processing a CPUID instruction is shown.

[0013] Fig.11 An example computing system is shown.

[0014] Fig.12 A block diagram of an example processor and / or system on a chip (SoC) is shown, which may have one or more cores and an integrated memory controller.

[0015] FIG. 13(A) is a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example.

[0016] FIG. 13(B) is a block diagram illustrating both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor, according to an example.

[0017] Fig.14 Examples of execution unit(s) circuitry are shown.

[0018] Fig.15 is a block diagram of a register architecture according to some examples.

[0019] Fig.16 An example of the instruction format is shown.

[0020] Fig.17 An example of an addressing information field is shown.

[0021] Fig.18 An example of a first prefix is ​​shown.

[0022] Figures 19(A)-(D) show how to use Fig.18 Example of the R, X, and B fields of the first prefix in .

[0023] 20(A)-(B) show examples of the second prefix.

[0024] Fig.21 An example of a third prefix is ​​shown.

[0025] Fig. 22 The block diagram illustrates use of a software instruction converter to convert binary instructions in a source instruction set architecture to binary instructions in a target instruction set architecture according to an example. DETAILED DESCRIPTION

[0026] Embodiments of the present invention provide performance cost (e.g., time, latency) information for monitoring events. In an embodiment, existing performance monitoring architectures (e.g., Intel's PEBS, AMD's Instruction Based Sampling (IBS), ARM's Statistical Profiling Extension) can be extended by using storage buffers (e.g., in PEBS) or processor registers (e.g., in IBS) to provide time in addition to information collected for monitoring events (e.g., instruction pointer, data address). For convenience and to provide examples, this specification may use the terms "PEBS" and / or "timed PEBS" in the description of the embodiments; however, the embodiments are not limited to PEBS or the use of time to measure performance costs.

[0027] For example, for MEM_LOAD_RETIRED.L3_HIT, the time would be the retirement push-out caused by the following instruction: the load that hit the level 3 (L3) cache belongs to this instruction. Embodiments may allow software to sort a sample of events based on their impact on overall performance. For example, a load that hits the L3 cache as part of a sequential access pattern may have less impact on performance than a load that is part of a random access pattern.

[0028] Embodiments may provide precise performance costs in the form of elapsed retirement cycles, which may be superior to approaches that provide some coarse bucketing (eg, by load data source or branch misprediction type) that may indirectly point to the range of potential costs.

[0029] Embodiments may provide costs at instruction-level granularity (e.g., the performance cost of the specific instruction that triggered the event), which may be superior to approaches that may provide costs for sequences of instructions that do not take branches (sometimes called "super blocks," which may be quite long sequences of instructions) for some compiler-generated code.

[0030] Embodiments may provide top-down targeted costs (e.g., by adding performance cost information to generic events (e.g., INST_RETIRE.ANY, BR_MISP_RETIRED.ALL_BRANCHES, ASSISTS.ANY)), which may be superior to approaches that target a small number of precise events in a bottom-up manner, which may limit capabilities in terms of performance coverage.

[0031] Embodiments may provide sampling without blind spots because time costs may be provided for any occurrence of any precise event, which may be superior to approaches that pre-select certain transactions to monitor each time.

[0032] Embodiments may be used to optimize software stacks and tune software to hardware, for example, by measuring the performance cost of instruction cache misses so that the cost of instruction cache misses can be mitigated by inserting software prefetch instructions.

[0033] Precise and Imprecise Event-Based Sampling (PEBS and NPEBS)

[0034] The performance monitoring capability used in some embodiments can be based on three groups of event counters: fixed function counters, general purpose counters, and timing PEBS counters. In an embodiment, three fixed function counters can be defined and implemented to count instruction retirement, reference clock, and core clock. General purpose counters and timing PEBS counters can be defined and implemented as described below. In an embodiment, any number of general purpose counters can be associated with corresponding timing PEBS counters. In an embodiment, any number of timing PEBS counters can be used in combination with monitoring events (e.g., load STLB hits), which may not be defined and / or can be selected as PEBS events according to previous PEBS architectures.

[0035] As used herein, a precise event is a performance event that is linked to a specific instruction or micro-operation in an instruction trace and occurs when the instruction or micro-operation retires. Such precise events may include, but are not limited to, instruction retirement, branch instruction retirement, cache reference, or cache miss, to name a few examples. On the other hand, an imprecise event is a performance event that is not linked to a specific instruction or micro-operation in an instruction trace, or that can occur speculatively even when the instruction or micro-operation is not retired. For example, an imprecise event may include, but is not limited to, reference clock ticks, core clock ticks, cycles when interrupts are masked, to name a few examples.

[0036] In some embodiments, the performance of the processing device is monitored to manage events and measure their impact on performance. In some embodiments, the processing device tracks precise and imprecise events and uses a mechanism on the processing device to store architectural and microarchitectural metadata about the events in a non-intrusive manner without the intervention of a performance monitoring interrupt (PMI).

[0037] The operation of the processing device may include the occurrence of multiple events that monitor the performance of the system. An event may include any operation, occurrence or action in the processor. In an embodiment, an event is a response to a given instruction and data flow in the processing device. The event may be associated with architectural metadata including state information of the processing device, including but not limited to instruction pointers, timestamp counters, and register states. An event may also be a generic event (e.g., INST_RETIRED) that may be marked with a performance cost.

[0038] In an embodiment, a performance counter is configured to count one or more types of events. When the counter is incremented or decremented, the software reads the counter at a selected interval to determine the number of events counted between the intervals. The counter can be implemented in a variety of ways. In an embodiment, the counter is decremented from a positive starting value and overflows when the count reaches zero. In other embodiments, the counter starts with a zero value and increments the count that occurs until it overflows at a specified value. In other embodiments, the counter starts with a negative value and increments until it overflows when it reaches zero. The performance counter can generate a performance record or a performance monitoring interrupt (PMI) when the counter overflows. In order to trigger an overflow, the counter can be preset to a modulus value that causes the counter to overflow after a specific number of events have been counted, which generates a PMI or performance record, for example, a precise event-based sampling (PEBS) record.

[0039] As described further below, the performance record may include a performance cost or penalty indicator that will help rank the severity of the event on performance. In an embodiment, the cost may be measured in terms of the retirement push-out time caused by the event.

[0040] Embodiments may include new (e.g., not defined and / or selectable as PEBS events according to previous PEBS architectures) precision events (e.g., for STLB hit retirement load / store, BR_MISP_RETIRED.PLUS_ONE (triggered on the first instruction after a branch misprediction), and / or upgrade events (MACHINE_CLEARS) to be precise.

[0041] Tracking precise events

[0042] There are several types of mechanisms for monitoring and managing various events. One type is the PEBS mechanism, which is used to monitor and manage precise events. Precise events are performance events that are linked to specific instructions or micro-operations in instruction tracking and occur when the instructions or micro-operations retire. Such precise events may include, but are not limited to, instruction retirement, branch instruction retirement, cache reference, or cache miss, to name just a few examples. The PEBS mechanism may include several components, such as an event selection (ES) control, a performance counter, a PEBS enable circuit, and a PEBS handler circuit. The ES control can be programmed with an event identifier, which causes the performance counter corresponding to the ES control to begin tracking the programmed event corresponding to the event identifier (e.g., counting its occurrence).

[0043] Embodiments may also include a PEBS enabling circuit of a processing device that controls when a PEBS record is generated. When the PEBS enabling circuit is activated, the PEBS record is stored in a memory of the PEBS handler circuit when a performance counter corresponding to the PEBS enabling circuit overflows. In embodiments, a user (e.g., software) may activate or set the PEBS enabling circuit. The PEBS record may include architectural metadata of the state of the system when the performance counter overflows. Such architectural metadata may include, but is not limited to, an instruction pointer (IP), a timestamp counter (TSC), and register states. Therefore, the PEBS record not only allows accurate analysis of the location of precise events in instruction tracing, but also provides additional information for software optimization, hardware optimization, performance tuning, and the like.

[0044] PEBS records may also include microarchitectural information that can measure the performance cost of an event. For example, in the case of MEM_LOAD_RETIRED.L3_MISS (a requested load access misses the L3 cache), the PEBS record may include a performance cost or penalty indicator that will help rank the severity of misses at different IPs.

[0045] Tracking Imprecise Events

[0046] Embodiments may also utilize the PEBS mechanism to track and manage imprecise events of a processing device. Imprecise events are performance events that are not linked to a specific instruction or micro-operation in instruction trace, or that can occur speculatively even when the instruction or micro-operation is not retired. For example, imprecise events may include, but are not limited to, reference clock ticks, core clock ticks, cycles when interrupts are masked, and the like.

[0047] Some embodiments introduce a non-precise event based sampling (NPEBS) handler circuit of a processing device that allows the NPEBS handler circuit to generate NPEBS records for programmed imprecise events and store the NPEBS records for the imprecise events in a PEBS storage buffer of the PEBS handler circuit.

[0048] In an embodiment, the NPEBS record shares the same format as the PEBS record. In other embodiments, the format of the NPEBS record is different from the PEBS record.

[0049] The PEBS handler circuit and the NPEBS handler circuit may share some circuits. The NPEBS handler circuit may use resources of the PEBS handler circuit and differs from the PEBS handler circuit only in name. In one example, when the ES control is programmed with an imprecise event identifier, a performance counter associated with the ES control and the PEBS enable circuit tracks the programmed imprecise event. In an embodiment, the NPEBS handler circuit is coupled to the PEBS enable circuit, and the PEBS enable circuit is coupled to the performance counter so that when the performance counter overflows, the PEBS enable circuit causes the NPEBS handler circuit to generate an NPEBS record for the imprecise event. Thus, architectural metadata associated with the imprecise event can be captured without the need for a PML.

[0050] In an embodiment, the NPEBS handler circuit controls the timing of generating the NPEBS record for the imprecise event. In one embodiment, the NPEBS record for the imprecise event is generated immediately when a performance counter that tracks the imprecise event overflows. In other embodiments, the NPEBS record for the imprecise event is generated immediately after the performance counter that tracks the imprecise event overflows (e.g., when the next subsequent instruction is executed). In one embodiment, the NPEBS handler circuit stores the NPEBS record for the imprecise event in a storage device of the NPEBS handler circuit.

[0051] Some embodiments include compact circuits and are therefore implemented as an integral part of various processing units without causing significant increases in cost and power consumption. Some embodiments are programmable circuit logic and are used to track and manage different types of imprecise events on the same circuit logic. The NPEBS handler circuit can also be extended to track multiple processing units. The NPEBS handler circuit can be shared by multiple applications running on the same processor and managed as a shared resource by an operating system (OS) or a virtual machine.

[0052] Exemplary Processor for Generating and Storing PEBS and NPEBS Records

[0053] Figure 1is a block diagram illustrating a processor that generates and stores PEBS and NPEBS records according to an embodiment. Figure 1 Any or all of the blocks shown may represent circuitry and / or logic in a performance management unit (PMU) of a processor. In some examples, the PMU supports timed PEBS and hybrid enumeration architectures via CPUID.

[0054] The CPUID leaf enhances the enumeration of PMU capabilities. Specifically, in some examples, CPUID sub-leaving accommodates future PMU extensions, hybrid resources are exposed by core type, bitmap hybrid enumeration using generic counter availability, bitmap hybrid enumeration using fixed counter availability, and new architectural PMU capabilities can be exposed via CPUID.

[0055] exist Figure 1 In the embodiment of the present invention, a core 102 of a multi-core processor (e.g., having one or more performance cores and one or more efficiency cores, other cores 190 and 191 are shown, which may be performance cores or efficiency cores) includes an NPEBS handler circuit 106 and a PEBS handler circuit 108 having one or more storage devices 110a to 110n (which may be implemented as physical storage devices, such as buffers). The PEBS handler circuit 108 may also include a performance monitoring interrupt (PMI) component 112 as described above. In addition, the processor 102 may include one or more event selection (ES) control devices 114a to 114n, which correspond to one or more general performance counters 116a-116n, and further correspond to one or more PEBS enable circuits 118a-118n (the details of which are described above). In some implementations, the PEBS enable circuits 118a-118n may be located in a single control register (e.g., a machine specific register or MSR). In some examples, the performance core(s) and the efficiency core(s) share an instruction set architecture. In some examples, the performance core(s) and the efficiency core(s) have different instruction set architectures.

[0056] In addition, Figure 1 In the illustrated embodiment, fixed function counters 160a-c are used to apply PEBS, NPEBS, and Precise Distribution of Instructions Retired (PDIR) operations. In an embodiment, three fixed function counters 160a-c are defined and implemented to count instruction retirements, reference clocks, and core clocks. However, it will be understood that the underlying principles of the present invention are not limited to any particular number of fixed function counters or any particular fixed function counter implementation.

[0057] As described, the processor 102 may execute an instruction stream that may be embedded with markers for events that may be placed on the bus / interconnect structure 104. The execution of a segment of instructions may constitute one or more imprecise events. An imprecise event is a performance event that is not linked to a specific instruction or micro-operation in the instruction trace, or that can occur speculatively even when the instruction or micro-operation is not retired. Such imprecise events may include, but are not limited to, reference clocks, core clocks, and cycles, to name a few examples. In an embodiment, the imprecise event is generated by the processor 102. In an embodiment, the imprecise event is generated external to the processor 102 and transmitted to the processor via the bus / interconnect structure 104.

[0058] In an embodiment, Figure 1 The illustrated event selection (ES) control means 150a-c perform similar operations as the ES control means 114a-c described above, but correspond to fixed function performance counters 160a-c, and further correspond to PEBS enable circuits 170a-c associated with the fixed function counters 160a-c. In one embodiment, the PEBS enable circuits 118a-118n and 170a-c are located in a single control register.

[0059] In one embodiment, the ES control devices 150a-c are programmed so that the performance counters 160a-c corresponding to the programmed ES control devices track the occurrence of specific programmed imprecise / precise events. In some embodiments, any event that is not defined as a precise event is considered an imprecise event. In one embodiment, the ES control devices 150a-c are programmed by an executing application. In another embodiment, a user programs the ES control devices 150a-c with imprecise / precise event identifiers.

[0060] When the ES control device 150a-c is programmed with an event identifier, the performance counter 160a-c corresponding to the ES control device 150a-c is incremented or decremented each time the programmed event occurs. The PEBS enable circuit 170a-c corresponding to the ES control device 150a-c and the fixed function performance counter 160a-c can be set (e.g., activated, a flag is set, a bit is set to 1, etc.) to generate a PEBS record when the fixed function performance counter 160a-c overflows or (if the counter is decremented) when the fixed function performance counter 160a-c reaches a value of zero. In one embodiment, the PEBS enable bit is set to enable the PEBS handler circuit 108 to generate a PEBS record when the fixed function performance counter 160a-c counting events overflows or reaches a value of zero. As described above, the PEBS record includes architectural metadata of the state of the system when the fixed function performance counter 160a-c overflows or reaches a value of zero. For example, the architectural metadata may include, but is not limited to, IP, TSC, or register state.

[0061] In one embodiment, NPEBS handler circuit 106 is coupled to PEBS enable circuits 170a-c such that when fixed function performance counters 160a-c overflow or reach a zero value, NPEBS handler circuit 106 causes PEBS enable circuits 170a-c to generate PEBS records of events. In some embodiments, NPEBS handler circuit 106 controls the timing of generating PEBS records of events. For example, in one embodiment, NPEBS handler circuit 106 causes PEBS enable circuits 170a-c to generate PEBS records of events immediately when performance counters 160a-c that track and count programmed events overflow or reach a zero value.

[0062] In another embodiment, the NPEBS handler circuit 106 causes the PEBS enable circuit 170a-c to generate a PEBS record for an event immediately after a fixed function performance counter 160a-c that tracks and counts the programmed event overflows or reaches a zero value. In this embodiment, the PEBS record is generated after the next instruction that retires (i.e., after the next instruction in the instruction trace that triggers the fixed function performance counter 160a-c to overflow or run to zero is completed). In one embodiment, the PEBS record generated by the PEBS handler circuit 108 for the event is stored in the storage device 110 of the PEBS handler circuit 108. Therefore, architectural metadata associated with the event can be captured without using PMI.

[0063] In one embodiment, the PMI component 112 collects PEBS records stored in the storage device(s) 110a-110n of the PEBS handler circuit 108. The PMI component 112 may immediately collect the PEBS records stored in the storage devices 110a-110n. In another embodiment, the PMI component 112 is delayed in immediately collecting the PEBS records in the storage devices 110a-110n. The interface may be provided as an MSR.

[0064] Applying PEBS / NPEBS / PDIR to fixed function counters 160a-c provides similar benefits as adding these features to general purpose counters 116a-n, but allows the general purpose counters to be freely used for other activities. These and other benefits and additional features of embodiments of the present invention are discussed below.

[0065] The performance capability control register 190 (eg, IA32_PERF_CAPABILITIES MSR) enhances the enumeration of non-architectural features of the PMU. For the hybrid portion, this register 190 includes a per-field attribute to indicate whether the reporting is common or hybrid across core types. An example format is as follows.

[0066] Field Name Bit type LBR FMT 5:0 Share PEBS Trap 6 Share PEBS Arch Regs 7 Share PEBS FMT 11:8 Share Freeze while SMM 12 Share Full Write 13 Share PEBS Baseline 14 Share Perf Metrics Available 15 mix PEBS Output PT Available 16 mix PEBS Timing Info 17 Share TSX Store Address Register 18 mix RDPMC Clear Metrics 19 mix

[0067] Example process for generating and storing PEBS records

[0068] Figure 2 An embodiment of a process of generating PEBS records and storing the PEBS records in a storage buffer and storing the storage buffer to a PEBS trace file is shown. After starting, at 202, the PMU counter is set to -N. Starting with a negative value, the PMU counter in this embodiment increments each time a PEBS record is generated until it reaches zero (0). In an alternative embodiment not shown, the PMU counter is set to +N and decrements each time a PEBS record is generated. At 204, N PEBS records are generated and stored in a PEBS storage buffer. At 206, the N PEBS records are stored in a PEBS trace file. This step is also shown as 210, which shows that the N PEBS records are stored in a PEBS trace file 212. At 208, the PEBS trace file is post-processed, after which the process ends.

[0069] Figure 3An embodiment of a process of programming a PEBS handler circuit to monitor processor performance and generate PEBS records to be stored in a PEBS storage buffer and then in a PEBS trace file is shown. After starting, at 302, a PMU counter is programmed to count function calls (e.g., BR_INST_RETIRED and NEAR_CALL_PS events) and overflow after N calls. At 304, the PEBS handler circuit is programmed to generate a PEBS record configured to contain architectural metadata after each overflow, the architectural metadata including state information of the processor, including but not limited to an instruction pointer, a timestamp counter, register states, and performance costs. The configuration of the processor information is monitored by the PEBS and stored in a PEBS data record. At 306, after the PEBS memory is filled, the PEBS memory contents are stored to a PEBS trace file. The process then ends.

[0070] Exemplary methods and hardware / firmware for adding performance costs to PEBS recordings

[0071] Figure 4 An embodiment of a method for adding a performance cost to a sample (e.g., PEBS) recording using hardware and firmware is shown. Figure 4 As shown, PMU 410 (which may include Figure 1 Any or all of the blocks shown in the processor 102 and / or corresponding to the Figure 1 ), the PMU described in the foregoing, the retirement unit 420, and the firmware / microcode 430 collaborate to provide performance cost. One or more timing counters (e.g., 412 and / or Figure 1 A timing PEBS counter 117a-117n) in the PMU may be included to count the duration between retirements of instructions.

[0072] At 440, the counter value may be sampled while a sample (e.g., PEBS) is pending (and just before it is reset due to retirement of the same instruction) at 442. At 446, the microcode may read the sampled value and write it to a memory resident record, similar to how it reports other information (e.g., IP).

[0073] In an embodiment, the timing counter may be a 16-bit counter added to the reorder buffer (ROB) so that it can measure time by counting clock cycles (e.g., MCLK) between retirements of instructions. For example, at 448, it may be reset when an instruction retires (e.g., EOM stream marker). In an embodiment, it may be enabled / disabled based on one or more settings and / or indicators to enable / disable sampling (e.g., PEBS) and / or performance monitoring (e.g., PMonThreadsActive is set). In an embodiment, it may saturate when it is all ones.

[0074] In an embodiment, the ROB may save a snapshot of the timing counter to a per-thread register (e.g., a control register) when a sample (e.g., for a corresponding event) is pending, cleared (e.g., MoNukeOnPebs), and / or both (e.g., whichever is earliest). In an embodiment, at 444, the microcode may be called to store the value of the register to a corresponding record.

[0075] Hybrid PMU Enumeration

[0076] In some examples, a heterogeneous (hybrid) architecture is used, meaning that a processor, SOC, etc. is composed of multiple CPU types (i.e., architectural designs). These individual CPUs are called cores. Heterogeneous architectures provide significant benefits in terms of performance and power consumption, but they introduce new complexities. Each core type (based on a different architecture) may have a different feature set, including different performance monitoring unit (PMU) implementations with different capabilities.

[0077] As an example, some processors contain a combination of some performance cores and some efficiency cores, with the two types having different performance monitoring (referred to herein as PM) capabilities. One of these capabilities is PM counters, which are individual registers in the CPU used for telemetry. The number of PM counters can vary between each core type. In the application space (i.e., performance monitoring software), various formulas are used to combine the measurements of these counters to create performance metrics. Existing PM capability enumeration methods are unable to simultaneously represent the capabilities of different types of cores. Therefore, the enumeration structure in the architecture currently presents the minimum set of counters available across all core types. This results in a significant loss of performance analysis capabilities in the platform for cores that have more than the minimum number of counters.

[0078] To address the problem of performance monitoring, several solutions have been implemented, but none of them are sufficient to achieve full performance analysis capabilities:

[0079] 1. Enumerate a minimal number of counters across all core types: A limitation of this solution is that a reduced set of counters is used that is common to all core types in the system, resulting in suboptimal performance monitoring capabilities.

[0080] 2. Maintaining a database in the performance monitoring software that lists the PM capabilities of all types of CPUs: This solution relies on identifying the CPU model information (i.e., "family, model, and stepping") and keeping track of the PM capabilities available on each CPU model, rather than querying the processor to obtain the same information. This solution allows the software to utilize different PM capabilities for each core type, but comes with a heavy burden of maintaining and updating the database for each CPU model. As the number of supported CPU models increases, it becomes impractical to reliably maintain the PM software tools. In addition, if the operating system and hypervisor only expose CPU enumeration features and do not update the database at the same cadence as the user-space PM software tools, this method becomes unusable for the user-space PM tools.

[0081] The examples detailed herein provide the ability to enumerate PMUs in hybrid architectures through the new CPUID (a mechanism provided by CPU vendors to system software to enumerate CPU features) leaf to allow system software to leverage a full set of performance monitoring capabilities across all core types on a heterogeneous system.

[0082] The solution outlined in this invention ensures that software can query a hybrid platform individually for the PM capabilities of each of its core types. This overcomes existing limitations in exposing performance monitoring capabilities in hybrid SoCs to OS and software tools. The solution does not rely on a common set of counters used by previous approaches, and does not require software developers to maintain a database of PM capabilities for each CPU model in their PM software. Furthermore, the enumeration mechanism works seamlessly with the existing homogeneous CPUID enumeration of PM features, thus allowing legacy software to continue to work as expected.

[0083] Figure 5 An example of CPUID instruction execution is shown. As shown, core / processor 500 includes execution circuit 501 to perform one or more actions in response to a decoded single processor identification and feature information instruction. In some examples, the opcode is 0F A2H and / or the mnemonic is CPUID.

[0084] The CPUID circuit 503 accesses processor identification and feature information 523 from a storage device (e.g., non-volatile storage device 521 (e.g., read-only memory, etc.)) that includes the capabilities of the core / processor 500. In some examples, one or more registers written before the CPUID instruction provide an indication of what will be written. In some examples, the first register used for the indication is EAX. In some examples, the second register used for the indication is ECX. In some examples, the first and / or second registers are implicit (i.e., they are not explicitly identified by the encoding of the instruction). In some examples, the first and / or second registers are explicit (i.e., they are explicitly identified by the encoding of the instruction). In some examples, the load circuit 505 loads or retrieves the data from one or more storage locations based on the one or more registers.

[0085] The loaded or retrieved processor identification and feature information (including capabilities) is then written to one or more registers (e.g., first register 511, second register 513, third register 515, and / or fourth register 517). In some examples, write circuit 507 performs the write(s).

[0086] CPUID leaf 23H (decimal 35) can be used by PM software to find out which PM counters exist on each core and configure performance monitoring capabilities independently on each core to obtain a complete set of performance information from each core. However, in some examples, PM software should first read CPUID leaf 0 to find out the number of CPUID leaves available on the first core, and only continue using CPUID leaf 23H when at least 23H leaves are available.

[0087] In some examples, CPUID leaf 23H must be read individually on each core to retrieve the set of per-core available performance counters. The value read is a bitmap where each bit describes the presence or absence of a specific counter. Using performance counters on each core must conform to the bitmap read from leaf 23H.

[0088] For legacy software that does not support CPUID leaf 23H, CPUID leaf AH (decimal 10) will continue to report the minimum set of PM counters available across all cores on each core. Therefore, it is expected that legacy PM software using CPUID leaf 0xA will work reliably as if CPUID leaf 23H did not exist.

[0089] The CPUID instruction supports the use of "sub-leafs" for each leaf, which group related information within the leaf together. CPUID Leaf 23H utilizes the sub-leaf design of CPUID. This means that software needs to provide the sub-leaf number as well as the leaf number when executing the CPUID instruction. The first sub-leaf that should be read within Leaf 23H is Leaf 0, which returns "valid sub-leaf" information. The output will be a 32-bit bitmap returned in the EAX register in the CPU, where each bit describes whether a specific sub-leaf exists. For example, bit 0 is 1 to indicate that sub-leaf 0 exists, and bit 2 is 0 to indicate that sub-leaf 2 does not exist.

[0090] If bit 1 in leaf 0 is 1, then PM counter availability information is present in leaf 1. Leaf 1 will output the number of "fixed" and "general" counters in two different registers. Each "fixed" counter is always designed to count a specific performance event (e.g., instruction retirements), while the "general" counters can be programmed to count one of several events during the measurement period (e.g., branch mispredictions, cache misses, etc.).

[0091] In some examples, CPUID leaf 23H also defines sub-leaf 3. Each bit of the output of sub-leaf 3 indicates the presence or absence of a specific standardized event (referred to as an "Arch PerfMon event"). For example, bit 1 of the output of sub-leaf 3 being 1 indicates the presence of an "instruction retirement" event in the core. This sub-leaf provides a simple way for the hardware to disclose the presence of each such standardized event.

[0092] Exemplary leaf and cotyledon contents of 23H are described in detail below.

[0093] CPUID leaf 023H format

[0094]

[0095]

[0096] Generic Counter Bitmap

[0097] In some examples, when CPUID.(EAX=23H,ECX=01H):EAX reports a bitmap of available general purpose counters. (CPUID.0AH reports only the total number of general purpose counters.) This capability enables VMX root software to reserve lower index counters for its own use while exposing higher index counters to guest software. This is especially important if the general purpose counters are not fully homogeneous.

[0098] Software can use the new bitmap to report (including detection) the number of available general-purpose counters. To facilitate this conversion, the number of general-purpose counters in the CPUID leaf 0AH will not exceed 8, even if the processor supports more than 8 general-purpose counters.

[0099] Fixed counter hybrid bitmap

[0100] In some examples, when CPUID.(EAX=23H,ECX=01H):EBX reports a bitmap of available fixed counters. (In addition to the common bitmap of fixed counter availability, CPUID leaf 0AH also reports the common number of consecutive fixed function counters.)

[0101] This capability enables privileged software to expose per-core type fixed counter enumeration. This is especially important if fixed counters are not available on all logical processors.

[0102] Architecture Performance Monitoring Event Bitmap

[0103] In some examples, when CPUID.(EAX=23H,ECX=03H):EAX provides a true view of the architectural performance monitoring events available per core type.For each bit n set in this field, the processor supports architectural performance monitoring events of index n (positive polarity).

[0104] In contrast, CPUID leaf 0AH provides the maximum common set of architectural performance monitoring events supported by all core types, where if bit n is set, it indicates that the processor does not necessarily support the architectural performance monitoring event of index n on all logical processors (negative polarity).

[0105] In some examples, CPUID leaf 23H also has the following benefits: system software or PM software can choose to use the full set of counters, or calculate the minimum set across all cores through a logical and (AND) operation and use the resulting set of counters instead. For example, if there are four counters, where the first counter, the second counter, and the fourth counter are available on one core, the bitmap output from leaf 23H will be 1011, and assuming that only the first counter and the fourth counter are available on another core, the bitmap output from the second core will be 1001. The result of the AND operation will be 1001, which represents the minimum common set (i.e., the first counter and the fourth counter).

[0106] In some examples, the PMU supports timed PEBS, which enables the recording of time in each PEBS record. It extends the PEBS record with timing information in a new "Retire Latency" field, which is located in the Basic Info group of the PEBS record, as shown in the following table.

[0107]

[0108] Retirement latency reports the number of core clocks that have passed between the retirement of the current instruction (as indicated by the instruction pointer field of the PEBS record) and the retirement of the previous instruction. When this number exceeds 16 bits, all ones are reported.

[0109] In some examples, the PMU includes performance monitoring events for top-down analysis, as shown below. Topdown Microarchitectureal Analysis (TMA) can allow for repair heuristics.

[0110]

[0111]

[0112] Top-down back-end boundary-event selection A4H, Umask 02H

[0113] This event counts a subset of Topdown Slots events that are not consumed by the backend pipeline due to lack of backend resources caused by memory subsystem latency, execution unit limitations, or other conditions. In some examples, this count is distributed among unstopped logical processors (hyperthreads) sharing the same physical core. Software can use this event as a nominee for the backend boundary metric (or top category) of the Top-down Microarchitecture Analysis method.

[0114] Top-down bad guessing - event selection 73H, Umask 00H

[0115] This event counts a subset of top-down slot events that are wasted due to mis-speculation caused by incorrect control flow or data speculation. Common examples include branch mispredictions and memory ordering flushes. In some examples, this count may be distributed across affected logical processors (hyperthreads or SMT threads) that share the same physical core. Software can use this event as a nominee for a bad speculation indicator (or top category) for top-down microarchitectural analysis methods.

[0116] Top-down front boundary-event selection 9CH, Umask 01H

[0117] This event counts a subset of top-down slot events where no operations were delivered to the backend pipeline due to instruction fetch limits when the backend could accept more operations. Common examples include instruction cache misses or x86 instruction decode limits.

[0118] In processors supporting Intel Hyper-Threading Technology, this count can be distributed across the unstopped logical processors (hyperthreads) that share the same physical core.

[0119] Software can use this event as a nominee for the front-end boundary metric (or top-level category) of a top-down microarchitectural analysis approach.

[0120] Top-down exit-event selection C2H, Umask 02H

[0121] This event counts a subset of top-down slot events that are eventually utilized by operations that are retired (committed) by the processor pipeline. Typically, this event is positively correlated with higher performance, for example, measured in instructions per cycle metrics.

[0122] Software can use this event as a nominee for a retirement metric (or top-level category) for a top-down microarchitectural analysis approach.

[0123] Figure 6 An example method executed by a processor to process a processor identification and feature information (CPUID) instruction is shown. For example, a processor core as shown in other figures detailed herein executes the method.

[0124] At 601, an instance of a single instruction is obtained. For example, an instruction is obtained. The instruction includes a field for an opcode, the single instruction has a field for an opcode, and the opcode indicates that the execution circuit returns a processor identification and feature information determined by an input to a first register and a second register, wherein the processor identification and feature information at least include an enumeration of heterogeneous performance monitoring unit capabilities.

[0125] At 603, the fetched instructions are decoded. For example, the fetched processor identification and characteristic information instructions are decoded by a decoder circuit (eg, decoder circuit 405 or decode circuit 1340 as described in detail herein).

[0126] At 605, when the decoded instruction is dispatched, data values ​​associated with the source operands of the decoded instruction are retrieved. For example, when one or more source operands are memory operands, data from the indicated memory location is retrieved.

[0127] At 607, the decoded instruction is executed by execution circuitry (hardware) (e.g., execution circuitry as described in detail herein). For the processor identification and feature information instruction, the execution will cause the execution circuitry to perform the operations described in conjunction with the opcode to return the processor identification and feature information, which includes at least an enumeration of the heterogeneous performance monitoring unit capabilities.

[0128] In some examples, at 609 , the instructions are committed or retired.

[0129] Figure 7An example system configuration with three cores is shown, where core 1 705 and core 3 709 each have 4 counters, and core 2 707 has only 2 counters. PM software 703 runs in operating system 701, which uses the traditional CPUID leaf 0xA to query the PM counters of each core. Due to the limitation of CPUID leaf 0xA, it receives output from each core as 2 counters, which is the minimum common set across cores.

[0130] Figure 8 An example system configuration with three cores is shown, where core 1 805 and core 3 809 each have 4 counters, and core 2 807 has only 2 counters. The PM software 803 in OS 801 queries CPUID leaf 0x23 instead of 0xA. In this case, the output will be a separate bitmap for each core, which represents the counters available on that core. For example, 1001 indicates that counters 1 and 4 are available, but counters 2 and 3 are not available.

[0131] One challenge can be the enumeration of performance monitoring features in a virtualized environment, i.e. when using a hypervisor or virtual machine monitor (VMM). This means that the operating system and PM software do not have full access to system resources, but rather the hypervisor has full control over system resources. In this case, the hypervisor will first query each core to discover the PM counter set. Since CPUID leaf 0xA only reads the minimum set of counters on a core, the hypervisor is limited to enumerating and exposing only these counters to the operating system, but with CPUID leaf 0x23, it can access the full set of PM counters for each core.

[0132] The hypervisor is built so that multiple OSes can run simultaneously on the same system, with different privileges given to them based on security requirements. Therefore, using CPUID leaf 0x23, the hypervisor can choose to: a) expose the full set of counters per core to a privileged and trusted OS, b) expose the minimal common set to another OS via the above calculation logical AND method, or c) for an unprivileged or untrusted OS, it can choose not to expose counters. The PM software in each OS will only have access to the set of counters exposed to it by the hypervisor.

[0133] Fig. 9An example system is shown, wherein three OSs running simultaneously on a system with a hypervisor (i.e., virtualization is enabled) are shown. OS1 901 runs with maximum privileges (i.e., fully trusted), OS2 911 runs with medium privileges, and OS 3 921 runs with minimum privileges (i.e., untrusted). These privilege levels are established for OS by the hypervisor based on its own policies. Each OS is shown to run PM software (PM software 903, 913, and 923). Hypervisor 925 first uses CPUID leaf 0x23 to query each core (905, 907, and 909) individually to obtain the bitmask of the PM counter from each core. Typically, hypervisor 925 saves these values ​​to memory. When PM software 1903 running in the highest privilege operating system 1 901 queries CPUID leaf 0x23 on each core individually, hypervisor 925 will intercept each of these requests and return the complete bitmask value of each core previously saved. This means that it will respond to requests from cores 1 and 3 with 1111, and to requests from core 2 with 1001, which is the full set of PM counters on each core. When PM software 2 913 running in a medium privilege operating system 2 911 queries CPUID leaf 0x23 on each core individually, the hypervisor 925 responds with the same value for all cores 1, 2, and 3, which is the bit mask 1001, which is the minimum common set since this is a medium privilege OS. When PM software 3 923 running in a minimum privilege operating system 3 921 queries CPUID leaf 0x23 on each core individually, the hypervisor should respond with 0000 for all cores 1, 2, and 3, i.e., no PM counters can be accessed.

[0134] CPUID leaf 0x23 allows software to have a comprehensive view of PM counters on heterogeneous processors and detect standardized events. It also enables software to use homogeneous or heterogeneous PM counter sets as needed, and enables system software to establish privilege levels, each privilege level allowing the use of different counter sets.

[0135] Fig.10 An example of computing hardware that processes a CPUID instruction is shown. As shown, a storage device 1003 stores a CPUID instruction 1001 to be executed.

[0136] Instruction 1001 is received by decoder circuit 1005. For example, decoder circuit 1005 receives the instruction from a fetch circuit (not shown). The instruction may be in any suitable format, for example, as described below. Fig.16 In one example, the instruction includes fields for an opcode and a source identifier.

[0137] A more detailed example of at least one instruction format for an instruction will be described in detail later. Decoder circuit 1005 decodes the instruction into one or more operations. In some examples, the decoding includes generating a plurality of micro-operations to be executed by an execution circuit (e.g., execution circuit 1009). Decoder circuit 1005 also decodes an instruction prefix.

[0138] In some examples, register renaming, register allocation and / or scheduling circuitry 1007 provides one or more of the following functions: 1) renaming logical operand values ​​to physical operand values ​​(e.g., a register alias table in some examples), 2) assigning status bits and flags to decoded instructions, and 3) scheduling decoded instructions from an instruction pool for execution circuitry to execute (e.g., using a reservation station in some examples).

[0139] Registers (register file) and / or memory 1008 store data as operands for instructions to be operated on by execution circuitry 1009. Example register types include packed data registers, general purpose registers (GPRs), and floating point registers.

[0140] Execution circuitry 1009 executes the decoded instructions. Example detailed execution circuitry includes the execution circuitry detailed herein.

[0141] In some examples, retirement / writeback circuitry 1011 architecturally commits the destination register to register or memory 1008 and retires the instruction.

[0142] An example of a format for a CPUID instruction is CPUID SRC1, SRC2. In some examples, OPCODE is the opcode mnemonic for the instruction. SRC1 and SRC2 are fields for source operands, such as packed data registers and / or memory. The source may be provided, at least in part, by REG 1744 and / or R / M 1746.

[0143] Other examples of architectures, processors, cores, SoCs, etc. that support the foregoing are described in detail below.

[0144] Example computer architecture.

[0145] The example computer architecture is described in detail below. Other system designs and configurations for laptops, desktop computers, handheld personal computers (PCs), personal digital assistants, engineering workstations, servers, decomposed servers, network devices, network hubs, switches, routers, embedded processors, digital signal processors (DSPs), graphic devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices known in the art are also appropriate. In a word, various systems or electronic devices that can include processors disclosed herein and / or other execution logics are generally appropriate.

[0146] Fig.11 An example computing system is shown. Multiprocessor system 1100 is an interfaced system and includes multiple processors or cores, including a first processor 1170 and a second processor 1180 coupled via an interface 1150 (e.g., a point-to-point (PP) interconnect, a fabric, and / or a bus). In some examples, first processor 1170 and second processor 1180 are isomorphic. In some examples, first processor 1170 and second processor 1180 are heterogeneous. Although example system 1100 is shown as having two processors, the system may have three or more processors, or may be a single processor system. In some examples, the computing system is a system on a chip (SoC).

[0147] Processors 1170 and 1180 are shown as including integrated memory controller (IMC) circuits 1172 and 1182, respectively. Processor 1170 also includes interface circuits 1176 and 1178; similarly, second processor 1180 includes interface circuits 1186 and 1188. Processors 1170, 1180 may exchange information via interface 1150 using interface circuits 1178, 1188. IMCs 1172 and 1182 couple processors 1170, 1180 to respective memories, namely memory 1132 and memory 1134, which may be part of the main memory locally attached to the respective processors.

[0148] Processors 1170, 1180 can each utilize interface circuits 1176, 1194, 1186, 1198 to exchange information with a network interface (NW I / F) 1190 via respective interfaces 1152, 1154. Network interface 1190 (e.g., one or more of an interconnect, bus, and / or structure, a chipset in some examples) can optionally exchange information with a coprocessor 1138 via interface circuit 1192. In some examples, coprocessor 1138 is a special-purpose processor, such as a high-throughput processor, a network or communication processor, a compression engine, a graphics processor, a general-purpose graphics processing unit (GPGPU), a neural network processing unit (NPU), an embedded processor, etc.

[0149] A shared cache (not shown) may be included in either processor 1170, 1180, or external to both processors but connected to the processors via an interface (e.g., a PP interconnect) such that if one processor is placed in a low power mode, local cache information for either or both processors may be stored in the shared cache.

[0150] The network interface 1190 can be coupled to the first interface 1116 via the interface circuit 1196. In some examples, the first interface 1116 can be an interface such as a peripheral component interconnect (PCI) interconnect, a PCI Express interconnect, or another I / O interconnect. In some examples, the first interface 1116 is coupled to a power control unit (PCU) 1117, which can include circuits, software, and / or firmware to perform power management operations with respect to the processors 1170, 1180, and / or the coprocessor 1138. The PCU 1117 provides control information to a voltage regulator (not shown) so that the voltage regulator generates an appropriate regulated voltage. The PCU 1117 also provides control information to control the generated operating voltage. In various examples, the PCU 1117 can include various power management logic units (circuits) to perform hardware-based power management. Such power management may be entirely processor controlled (e.g., controlled by various processor hardware and may be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (e.g., a platform or power management source or system software).

[0151] PCU 1117 is illustrated as existing as logic separate from processor 1170 and / or processor 1180. In other cases, PCU 1117 may execute on a given one or more of the cores (not shown) of processor 1170 or 1180. In some cases, PCU 1117 may be implemented as a microcontroller (dedicated or general purpose) or other control logic that is configured to execute its own dedicated power management code (sometimes referred to as P-code). In still other examples, the power management operations to be performed by PCU 1117 may be implemented external to the processor, for example, by a separate power management integrated circuit (PMIC) or another component external to the processor. In still other examples, the power management operations to be performed by PCU 1117 may be implemented within BIOS or other system software.

[0152] Various I / O devices 1114 and a bus bridge 1118 can be coupled to the first interface 1116, which couples the first interface 1116 to the second interface 1120. In some examples, (one or more) additional processors 1115 are coupled to the first interface 1116, for example, a coprocessor, a high-throughput integrated many-core (MIC) processor, a GPGPU, an accelerator (e.g., a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor. In some examples, the second interface 1120 can be a low pin count (LPC) interface. Various devices can be coupled to the second interface 1120, including, for example, a keyboard and / or mouse 1122, a communication device 1127, and a storage circuit 1128. The storage circuit 1128 can be one or more non-transitory machine-readable storage media as described below, for example, a disk drive or other mass storage device, which in some examples may include instructions / codes and data 1130 and can implement the storage device 1003. In addition, audio I / O 1124 can be coupled to second interface 1120. Note that other architectures besides the point-to-point architecture described above are possible. For example, a system such as multiprocessor system 1100 can implement a multi-drop interface or other such architecture instead of a point-to-point architecture. Example core architectures, processors, and computer architectures.

[0153] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of these cores may include: 1) general-purpose in-order cores, for general-purpose computing; 2) high-performance general-purpose out-of-order cores, for general-purpose computing; 3) special-purpose cores, mainly for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) CPUs, including one or more general-purpose in-order cores for general-purpose computing and / or one or more general-purpose out-of-order cores for general-purpose computing; and 2) coprocessors, including one or more special-purpose cores, mainly for graphics and / or scientific (throughput) computing. These different processors result in different computer system architectures, which may include: 1) coprocessors on separate chips from the CPU; 2) coprocessors on separate dies from the CPU in the same package; 3) coprocessors on the same die as the CPU (in which case such coprocessors are sometimes referred to as dedicated logic, e.g., integrated graphics and / or scientific (throughput) logic, or as dedicated cores); and 4) systems on a chip (SoCs), which may be included on the same die as the described CPU (sometimes referred to as application core(s) or application processor(s), the coprocessors described above, and additional functionality. An example core architecture is described next, followed by a description of an example processor and computer architecture.

[0154] Fig.12 A block diagram of an example processor and / or SoC 1200 is shown, which may have one or more cores and an integrated memory controller. The processor 1200 illustrated in solid line boxes has a single core 1202(A), a system agent unit circuit 1210, and a set of one or more interface controller unit circuits 1216, while the optionally added dashed line boxes illustrate an alternative processor 1200 as having multiple cores 1202(A)-(N), a set of one or more integrated memory control unit circuits 1214 in the system agent unit circuit 1210, dedicated logic 1208, and a set of one or more interface controller unit circuits 1216. Note that the processor 1200 may be Fig.11 One of processors 1170 or 1180 or coprocessors 1138 or 1115.

[0155] Thus, different implementations of processor 1200 may include: 1) a CPU, where dedicated logic 1208 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 1202(A)-(N) are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of the two); 2) a coprocessor, where cores 1202(A)-(N) are a large number of dedicated cores primarily for graphics and / or scientific (throughput); and 3) a coprocessor, where cores 1202(A)-(N) are a large number of general purpose in-order cores. Thus, processor 1200 may be a general purpose processor, a coprocessor, or a dedicated processor, such as a network or communications processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. Processor 1200 may be part of and / or may be implemented on one or more substrates using any of a variety of process technologies, such as complementary metal oxide semiconductor (CMOS), bipolar CMOS (BiCMOS), P-type metal oxide semiconductor (PMOS), or N-type metal oxide semiconductor (NMOS).

[0156] The memory hierarchy includes one or more levels of cache unit circuits 1204(A)-(N) within the cores 1202(A)-(N), a set of one or more shared cache unit circuits 1206, and external memory (not shown) coupled to the set of integrated memory controller unit circuits 1214. The set of one or more shared cache unit circuits 1206 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, such as last level cache (LLC), and / or combinations thereof. While in some examples an interface network circuit 1212 (e.g., a ring interconnect) interfaces with dedicated logic 1208 (e.g., integrated graphics logic), the set of shared cache unit circuits 1206, and the system agent unit circuit 1210, alternative examples use any number of well-known techniques to interface with these units. In some examples, coherency is maintained between one or more of the shared cache unit circuits 1206 and the cores 1202(A)-(N). In some examples, interface controller unit circuit 1216 couples core 1202 to one or more other devices 1218, such as one or more I / O devices, storage devices, one or more communication devices (e.g., wireless network, wired network, etc.), etc.

[0157] In some examples, one or more of the cores 1202(A)-(N) have multi-threading capabilities. System agent unit circuitry 1210 includes those components that coordinate and operate the cores 1202(A)-(N). System agent unit circuitry 1210 may include, for example, power control unit (PCU) circuitry and / or display unit circuitry (not shown). The PCU may be or may include logic and components required to regulate the power state of the cores 1202(A)-(N) and / or the dedicated logic 1208 (e.g., integrated graphics logic). The display unit circuitry is used to drive one or more externally connected displays.

[0158] The cores 1202(A)-(N) may be homogeneous with respect to an instruction set architecture (ISA). Alternatively, the cores 1202(A)-(N) may be heterogeneous with respect to an ISA; that is, a subset of the cores 1202(A)-(N) may be capable of executing one ISA, while other cores may be capable of executing only a subset of the ISA or may be capable of executing another ISA.

[0159] Example core architectures - in-order and out-of-order core block diagrams.

[0160] The block diagram of FIG. 13(A) illustrates both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example. The block diagram of FIG. 13(B) illustrates both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example. The solid line boxes in FIG. 13(A)-(B) illustrate the in-order pipeline and in-order core, while the optional addition of dashed line boxes illustrates the register renaming, out-of-order issue / execution pipeline and core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0161] In FIG. 13(A), the processor pipeline 1300 includes a fetch stage 1302, an optional length decoding stage 1304, a decode stage 1306, an optional allocation (Alloc) stage 1308, an optional rename stage 1310, a dispatch (also called dispatch or issue) stage 1312, an optional register read / memory read stage 1314, an execute stage 1316, a write back / memory write stage 1318, an optional exception handling stage 1322, and an optional commit stage 1324. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 1302, one or more instructions are fetched from the instruction memory, and during the decode stage 1306, the fetched one or more instructions may be decoded, an address using a forwarding register port (e.g., a load store unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) may be performed. In one example, the decode stage 1306 and the register read / memory read stage 1314 can be combined into one pipeline stage. In one example, during the execute stage 1316, decoded instructions can be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AMB) interface can be performed, multiplication and addition operations can be performed, arithmetic operations with branch results can be performed, etc.

[0162] As an example, the example register renaming, out-of-order issue / execution architecture core of FIG. 13(B) may implement pipeline 1300 in the following manner: 1) instruction fetch circuit 1338 executes fetch and length decoding stages 1302 and 1304; 2) decoding circuit 1340 executes decoding stage 1306; 3) renaming / allocator unit circuit 1352 executes allocation stage 1308 and renaming stage 1310; 4) (one or more) scheduler circuit 1356 executes scheduling stage 1312; 5) (one or more) physical registers 1314; (one or more) execution clusters 1360 perform the execution stage 1316; 6) the memory unit circuit 1370 and (one or more) physical register file circuits 1358 perform the write back / memory write stage 1318; 7) various circuits may be involved in the exception handling stage 1322; and 8) the retirement unit circuit 1354 and (one or more) physical register file circuits 1358 perform the commit stage 1324.

[0163] 13(B) shows that the processor core 1390 includes a front end unit circuit 1330 coupled to an execution engine unit circuit 1350, and both are coupled to a memory unit circuit 1370. The core 1390 can be a reduced instruction set architecture computing (RISC) core, a complex instruction set architecture computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the core 1390 can be a dedicated core, for example, a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, etc.

[0164] The front end unit circuit 1330 may include a branch prediction circuit 1332 coupled to an instruction cache circuit 1334 coupled to an instruction translation lookaside buffer (TLB) 1336 coupled to an instruction fetch circuit 1338 coupled to a decode circuit 1340. In one example, the instruction cache circuit 1334 is included in the memory unit circuit 1370 instead of the front end circuit 1330. The decode circuit 1340 (or decoder) may decode the instruction and generate one or more micro-operations, microcode entry points, micro-instructions, other instructions, or other control signals as outputs, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decode circuit 1340 may also include an address generation unit (AGU, not shown) circuit. In one example, the AGU uses the forwarded register port to generate the LSU address and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decode circuit 1340 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read-only memories (ROMs), etc. In one example, the core 1390 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode circuit 1340 or otherwise within the front-end circuit 1330). In one example, the decode circuit 1340 includes a micro-op or operation cache (not shown) to save / cache decode operations, micro-tags, or micro-operations generated during decoding or other stages of the processor pipeline 1300. The decode circuit 1340 may be coupled to the rename / allocator unit circuit 1352 in the execution engine circuit 1350.

[0165] The execution engine circuit 1350 includes a rename / allocator unit circuit 1352, which is coupled to a retirement unit circuit 1354 and a set of one or more scheduler circuits 1356. The scheduler circuit(s) 1356 represent any number of different schedulers, including reservation stations, central instruction windows, etc. In some examples, the scheduler circuit(s) 1356 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuit, an AGU queue, etc. The scheduler circuit(s) 1356 are coupled to physical register file(s) circuit(s) 1358. Each of the physical register file(s) circuit(s) 1358 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc. In one example, the (one or more) physical register file circuits 1358 include vector register unit circuits, write mask register unit circuits, and scalar register unit circuits. These register units can provide architected vector registers, vector mask registers, general registers, etc. The (one or more) physical register file circuits 1358 are coupled to the retirement unit circuits 1354 (also called retirement queues) to demonstrate various ways that register renaming and out-of-order execution can be implemented (e.g., using (one or more) reorder buffers (ROBs) and (one or more) retirement register files; using (one or more) future stacks, (one or more) history buffers, and (one or more) retirement register files; using register maps and register pools; etc.). The retirement unit circuits 1354 and (one or more) physical register file circuits 1358 are coupled to (one or more) execution clusters 1360. The (one or more) execution clusters 1360 include a set of one or more execution unit circuits 1362 and a set of one or more memory access circuits 1364. The execution unit circuit(s) 1362 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some examples may include several execution units or execution unit circuits dedicated to a particular function or set of functions, other examples may include only one execution unit circuit or multiple execution units / execution unit circuits that all perform all functions.Scheduler circuit(s) 1356, physical register file circuit(s) 1358, and execution cluster(s) 1360 are shown as possibly multiple because some examples create separate pipelines for certain types of data / operations (e.g., scalar integer pipeline, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or memory access pipeline, each with its own scheduler circuit, physical register file circuit(s), and / or execution cluster - and in the case of a separate memory access pipeline, only the execution cluster of that pipeline has memory access unit circuit(s) 1364 in some examples of the implementation). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest are in-order.

[0166] In some examples, the execution engine unit circuit 1350 may perform load store unit (LSU) address / data pipelining to an advanced microcontroller bus (AMB) interface (not shown), as well as address stage and writeback, data stage loads, stores, and branches.

[0167] The set of memory access circuits 1364 is coupled to a memory cell circuit 1370, which includes a data TLB circuit 1372, which is coupled to a data cache circuit 1374, which is coupled to a level 2 (L2) cache circuit 1376. In one example, the memory access circuit 1364 may include a load unit circuit, a storage address unit circuit, and a storage data unit circuit, each of which is coupled to the data TLB circuit 1372 in the memory cell circuit 1370. The instruction cache circuit 1334 is further coupled to the level 2 (L2) cache circuit 1376 in the memory cell circuit 1370. In one example, the instruction cache 1334 and the data cache 1374 are combined into a single instruction and data cache in the L2 cache circuit 1376, a level 3 (L3) cache circuit (not shown), and / or a main memory (not shown). The L2 cache circuit 1376 is coupled to one or more other levels of cache and ultimately to the main memory.

[0168] Core 1390 may support one or more instruction sets (e.g., x86 instruction set architecture (optionally with some extensions that have been added with updated versions); MIPS instruction set architecture; ARM instruction set architecture (optionally with optional additional extensions, such as NEON)), including the instruction(s) described herein. In one example, core 1390 includes logic to support packed data instruction set architecture extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using packed data.

[0169] Example execution unit circuit(s).

[0170] Fig.14 An example of (one or more) execution unit circuits is shown, for example, (one or more) execution unit circuits 1362 of FIG. 13 (B). As shown, (one or more) execution unit circuits 1362 may include one or more ALU circuits 1401, optional vector / single instruction multiple data (SIMD) circuits 1403, load / store circuits 1405, branch / jump circuits 1407, and / or floating point unit (FPU) circuits 1409. ALU circuits 1401 perform integer arithmetic and / or Boolean operations. Vector / SIMD circuits 1403 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store circuits 1405 execute load and store instructions to load data from memory into registers or store data from registers to memory. Load / store circuits 1405 may also generate addresses. Branch / jump circuits 1407 cause branches or jumps to memory addresses depending on the instructions. FPU circuits 1409 perform floating point arithmetic. The width of execution unit circuit(s) 1362 varies depending on the example and may range, for example, from 16 bits to 1024 bits. In some examples, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit).

[0171] Example register architecture.

[0172] Fig.15 1 is a block diagram of a register architecture 1500 according to some examples. As shown, the register architecture 1500 includes a vector / SIMD register 1510, whose width varies from 128 bits to 1024 bits. In some examples, the vector / SIMD register 1510 is physically 512 bits, and depending on the mapping, only some low-order bits are used. For example, in some examples, the vector / SIMD register 1510 is a 512-bit ZMM register: the low-order 256 bits are used for the YMM register, and the low-order 128 bits are used for the XMM register. Therefore, there is an overlay of registers. In some examples, the vector length field selects between the maximum length and one or more other shorter lengths, wherein each such shorter length is half the length of the previous length. Scalar operations are operations performed on the lowest-order data element position in the ZMM / YMM / XMM register; higher-order data element positions are either maintained as the same as before the instruction, or are zeroed, depending on the example.

[0173] In some examples, the register architecture 1500 includes a write mask / predicate register 1515. For example, in some examples, there are 8 write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16 bits, 32 bits, 64 bits, or 128 bits in size. The write mask / predicate register 1515 can allow merging (e.g., allowing any set of elements in the destination to be protected from update during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some examples, each data element position in a given write mask / predicate register 1515 corresponds to a data element position in the destination. In other examples, the write mask / predicate register 1515 is scalable and consists of a set number of enable bits for a given vector element (e.g., 8 enable bits per 64-bit vector element).

[0174] The register architecture 1500 includes a plurality of general registers 1525. These registers may be 16 bits, 32 bits, 64 bits, etc., and may be used for scalar operations. In some examples, these registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0175] In some examples, the register architecture 1500 includes a scalar floating point (FP) register file 1545, which is used to perform scalar floating point operations on 32 / 64 / 80-bit floating point data using the x87 instruction set architecture extension, or as an MMX register to perform operations on 64-bit packed integer data, and to store operands for some operations performed between MMX and XMM registers.

[0176] One or more flag registers 1540 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operations. For example, one or more flag registers 1540 can store condition code information, such as carry, parity, auxiliary carry, zero, sign, and overflow. In some examples, one or more flag registers 1540 are referred to as program status and control registers.

[0177] Segment registers 1520 contain segment points for accessing memory. In some examples, these registers are referenced by the names CS, DS, SS, ES, FS, and GS.

[0178] Model-specific registers or machine-specific registers (MSRs) 1535 control and report processor performance. Most MSRs 1535 handle system-related functions and are not accessible to applications. For example, MSRs may provide control of one or more of the following: performance monitoring counters, debug extensions, memory type range registers, thermal and power management, instruction-specific support, and / or processor feature / mode support. Machine check registers 1560 consist of control, status, and error reporting MSRs for detecting and reporting hardware errors. (One or more) control registers 1555 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processors 1170, 1180, 1138, 1115, and / or 1200) and the characteristics of the task currently being executed. In some examples, MSRs 1535 are a subset of control registers 1555.

[0179] One or more instruction pointer registers 1530 store instruction pointer values. Debug registers 1550 control and allow monitoring of debug operations of the processor or core.

[0180] Memory (mem) management registers 1565 specify the location of data structures used for protected mode memory management. These registers may include the Global Descriptor Table Register (GDTR), Interrupt Descriptor Table Register (IDTR), Task Register, and Local Descriptor Table Register (LDTR) registers.

[0181] Alternative examples may use wider or narrower registers. In addition, alternative examples may use more, fewer, or different register files and registers. Register architecture 1500 may be used, for example, in register file / memory 1008, or in (one or more) physical register file circuits 1358.

[0182] Instruction set architecture.

[0183] Instruction set architecture (ISA) can include one or more instruction formats. A given instruction format can define various fields (e.g., the number of bits, the position of bits) to specify the operation to be performed (e.g., opcode) and the (one or more) operation objects and / or other (one or more) data fields (e.g., mask) etc. to be performed on the operation. Some instruction formats are further decomposed by the definition of instruction templates (or sub-formats). For example, the instruction templates of a given instruction format can be defined as having different subsets of the fields of the instruction format (the included fields are usually in the same order, but at least some have different bit positions because the included fields are fewer) and / or defined as having given fields interpreted in different ways. Therefore, each instruction of the ISA is expressed using a given instruction format (and if defined, expressed with a given instruction template in the instruction template of the instruction format), and includes fields for specifying operations and operation objects. For example, the example ADD instruction has a specific opcode and instruction format, the instruction format includes an opcode field to specify the opcode, and includes an operand field to select an operand (source 1 / destination and source 2); and the appearance of the ADD instruction in the instruction stream will have specific content in the operand field that selects the specific operand. In addition, although the following description is made in the context of the x86 ISA, it is within the knowledge of those skilled in the art to apply the teachings of the present disclosure to other ISAs.

[0184] Example instruction format.

[0185] The examples of the (one or more) instructions described herein may be implemented in different formats. In addition, example systems, architectures, and pipelines are described in detail below. The examples of (one or more) instructions may be executed on these systems, architectures, and pipelines, but are not limited to those described in detail.

[0186] Fig.16 An example of an instruction format is shown. As shown, an instruction may include multiple components, including but not limited to one or more fields for the following items: one or more prefixes 1601, an opcode 1603, addressing information 1605 (e.g., a register identifier, memory addressing information, etc.), a displacement value 1607, and / or an immediate value 1609. Note that some instructions utilize some or all of the fields of the format, while other instructions may only use the opcode 1603 field. In some examples, the illustrated order is the order in which these fields are to be encoded, however it should be understood that in other examples, these fields may be encoded in a different order, combined, etc.

[0187] (One or more) prefix fields 1601 modify the instruction when used. In some examples, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), provide section override (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), perform bus lock operations, and / or change operation objects (e.g., 0x66) and address sizes (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered as "traditional" prefixes. Other prefixes (one or more examples of which are described in detail herein) indicate and / or provide further capabilities, for example, specify specific registers, etc. These other prefixes are usually followed by the "traditional" prefix.

[0188] The opcode field 1603 is used to at least partially define the operation to be performed when the instruction is decoded. In some examples, the length of the primary opcode encoded in the opcode field 1603 is one, two, or three bytes. In other examples, the primary opcode can be other lengths. The additional 3-bit opcode field is sometimes encoded in another field.

[0189] The addressing information field 1605 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Fig.17 An example of an addressing information field 1605 is shown. In this illustration, an optional MOD R / M byte 1702 and an optional scale, index, base (SIB) byte 1704 are shown. The MOD R / M byte 1702 and SIB byte 1704 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. Note that these fields are optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 1702 includes a MOD field 1742, a register (reg) field 1744, and an R / M field 1746.

[0190] The content of MOD field 1742 distinguishes between memory access and non-memory access modes. In some examples, when MOD field 1742 has a binary value of 11 (11b), register direct addressing mode is utilized, otherwise register indirect addressing mode is used.

[0191] Register field 1744 may encode a destination register operand or a source register operand, or may encode an opcode extension and not be used to encode any instruction operand. The contents of register field 1744 specify the location (in a register or in memory) of the source or destination operand directly or through address generation. In some examples, register field 1744 is supplemented with additional bits from a prefix (e.g., prefix 1601) to allow greater addressing.

[0192] R / M field 1746 may be used to encode an instruction operand that references a memory address, or may be used to encode a destination register operand or a source register operand. Note that in some examples, R / M field 1746 may be combined with MOD field 1742 to specify an addressing mode.

[0193] SIB byte 1704 includes a scale field 1752, an index field 1754, and a base address field 1756 for address generation. Scaling field 1752 indicates a scaling factor. Index field 1754 specifies the index register to be used. In some examples, index field 1754 is supplemented with additional bits from a prefix (e.g., prefix 1601) to allow for larger addressing. Base address field 1756 specifies the base address register to be used. In some examples, base address field 1756 is supplemented with additional bits from a prefix (e.g., prefix 1601) to allow for larger addressing. In practice, the contents of scale field 1752 allow the contents of index field 1754 to be scaled for memory address generation (e.g., for memory addresses using 2 缩放 * address generation of index + base address).

[0194] Some addressing forms use displacement values ​​to generate memory addresses. For example, 缩放 * index + base + displacement, index * scale + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. The displacement can be a value of 1 byte, 2 bytes, 4 bytes, etc. In some examples, the displacement field 1607 provides this value. In addition, in some examples, the displacement factor is encoded in the MOD field of the addressing information field 1605, which indicates a compressed displacement scheme, for which the displacement value is calculated and stored in the displacement field 1607.

[0195] In some examples, the immediate value field 1609 specifies an immediate value for the instruction. The immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, etc.

[0196] Fig.18An example of a first prefix 1601(A) is shown. In some examples, the first prefix 1601(A) is an example of a REX prefix. Instructions using this prefix can specify general registers, 64-bit packed data registers (e.g., single instruction multiple data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0197] Instructions using the first prefix 1601(A) can specify up to three registers using a 3-bit field, depending on the format: 1) using the register field 1744 and the R / M field 1746 of the MOD R / M byte 1702; 2) using the MOD R / M byte 1702 with the SIB byte 1704, including using the register field 1744 as well as the base field 1756 and the index field 1754; or 3) using the register field of the opcode.

[0198] In the first prefix 1601 (A), bit positions 7:4 are set to 0100. Bit position 3 (W) can be used to determine the operand size, but cannot determine the operand width alone. Therefore, when W=0, the operand size is determined by the code segment descriptor (CS.D), and when W=1, the operand size is 64 bits.

[0199] Note that adding another bit allows addressing 16 (2 4 ) registers, while the MOD R / M register field 1744 and the MODR / MR / M field 1746 can each only address 8 registers individually.

[0200] In the first prefix 1601(A), bit position 2 (R) may be an extension of the MOD R / M register field 1744 and may be used to modify the MOD R / M register field 1744 when the field encodes a general register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. When the MOD R / M byte 1702 specifies another register or defines an extended opcode, the R is ignored.

[0201] Bit position 1 (X) may modify the SIB byte index field 1754 .

[0202] Bit position 0 (B) may modify the base address in MOD R / MR / M field 1746 or SIB byte base address field 1756; or it may modify the opcode register field used to access a general purpose register (eg, general purpose register 1525).

[0203] 19(A)-(D) show examples of how the R, X, and B fields of the first prefix 1601(A) are used. FIG. 19(A) shows that when the SIB byte 1704 is not used for memory addressing, the R and B from the first prefix 1601(A) are used to extend the register field 1744 and the R / M field 1746 of the MOD R / M byte 1702. FIG. 19(B) shows that when the SIB byte 1704 is not used, the R and B from the first prefix 1601(A) are used to extend the register field 1744 and the R / M field 1746 of the MOD R / M byte 1702 (register-register addressing). FIG. 19(C) shows that when the SIB byte 1704 is used for memory addressing, the R, X, and B from the first prefix 1601(A) are used to extend the register field 1744, the index field 1754, and the base address field 1756 of the MOD R / M byte 1702. 19(D) shows that when a register is encoded in the opcode 1603, the B from the first prefix 1601(A) is used to extend the register field 1744 of the MOD R / M byte 1702.

[0204] Figure 20 (A)-(B) shows an example of a second prefix 1601 (B). In some examples, the second prefix 1601 (B) is an example of a VEX prefix. The second prefix 1601 (B) encoding allows instructions to have more than two operands, and allows SIMD vector registers (e.g., vector / SIMD registers 1510) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 1601 (B) provides a three-operand (or more) syntax. For example, a previous two-operand instruction performs an operation such as A=A+B, which overwrites the source operand. The use of the second prefix 1601 (B) enables the operand to perform non-destructive operations, for example, A=B+C.

[0205] In some examples, the second prefix 1601(B) has two forms - a two-byte form and a three-byte form. The two-byte second prefix 1601(B) is mainly used for 128-bit, scalar and some 256-bit instructions; while the three-byte second prefix 1601(B) provides a compact replacement for 3-byte opcode instructions and the first prefix 1601(A).

[0206] Figure 20 (A) shows an example of a two-byte form of the second prefix 1601 (B). In one example, format field 2001 (byte 0 2003) contains value C5H. In one example, byte 1 2005 includes an "R" value in bit [7]. This value is the complement of the "R" value of the first prefix 1601 (A). Bit [2] is used to specify the length (L) of a vector (wherein 0 value is a scalar or 128-bit vector, and 1 value is a 256-bit vector). Bit [1:0] provides an operation code extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, may be used to: 1) encode a first source register operand, which is specified in inverted (complement) form and is valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form for use with certain vector shifts; or 3) encode no operand, in which case the field is reserved and should contain some value, e.g., 1111b.

[0207] Instructions using this prefix may use MOD R / MR / M field 1746 to encode instruction operands that reference memory addresses, or to encode destination register operands or source register operands.

[0208] Instructions using this prefix may use MOD R / M register field 1744 to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0209] For instruction syntax supporting four operands, vvvv, MOD R / MR / M field 1746, and MOD R / M register field 1744 encode three of the four operands. Bits [7:4] of immediate value field 1609 are then used to encode the third source register operand.

[0210] Figure 20 (B) shows an example of a three-byte form of the second prefix 1601 (B). In one example, the format field 2011 (byte 0 2013) contains the value C4H. Byte 1 2015 includes "R", "X" and "B" in bit [7:5], which are the complements of these values ​​of the first prefix 1601 (A). Bit [4:0] (shown as mmmmm) of byte 1 2015 includes the content of encoding one or more implicit leading operation code bytes as needed. For example, 00001 means 0FH leading operation code, 00010 means 0F38H leading operation code, 00011 means 0F3AH leading operation code, etc.

[0211] The use of bit [7] of byte 2 2017 is similar to W of the first prefix 1601 (A), including helping to determine the size of the operand that can be promoted. Bit [2] is used to specify the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode the first source register operand, which is specified in inverted (inverse) form and is valid for instructions with 2 or more source operands; 2) encode the destination register operand, which is specified in inverse form for certain vector shifts; or 3) do not encode any operand, the field is reserved and should contain a value, for example, 1111b.

[0212] Instructions using this prefix may use MOD R / MR / M field 1746 to encode instruction operands that reference memory addresses, or to encode destination register operands or source register operands.

[0213] Instructions using this prefix may use MOD R / M register field 1744 to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0214] For instruction syntax supporting four operands, vvvv, MOD R / MR / M field 1746, and MOD R / M register field 1744 encode three of the four operands. Bits [7:4] of immediate value field 1609 are then used to encode the third source register operand.

[0215] Fig.21 An example of a third prefix 1601(C) is shown. In some examples, the third prefix 1601(C) is an example of an EVEX prefix. The third prefix 1601(C) is a four-byte prefix.

[0216] The third prefix 1601(C) can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some examples, write masks / operation masks are used (see the discussion of registers in the previous figure, such as Fig.15 ) or predicate instructions utilize this prefix. The operation mask register allows conditional processing or selection control. Operation mask instructions (whose source / destination operands are operation mask registers and the contents of the operation mask registers are treated as a single value) are encoded using the second prefix 1601 (B).

[0217] The third prefix 1601(C) may encode functionality specific to the instruction class (e.g., a packed instruction with “load+operation” semantics may support an embedded broadcast functionality, a floating-point instruction with rounding semantics may support a static rounding functionality, a floating-point instruction with non-rounding arithmetic semantics may support a “suppress all exceptions” functionality, etc.).

[0218] The first byte of the third prefix 1601 (C) is the format field 2111, which in one example has a value of 62 H. The subsequent bytes are called payload bytes 2115-2119, and together form a 24-bit value of P[23:0], providing specific capabilities in the form of one or more fields (described in detail herein).

[0219] In some examples, P[1:0] of payload byte 2119 is the same as the two mm bits in the lower order. In some examples, P[3:2] is reserved. Bit P[4] (R') allows access to the upper 16 vector register sets when combined with P[7] and MOD R / M register field 1744. When SIB type addressing is not required, P[6] can also provide access to the upper 16 vector registers. P[7:5] consists of R, X, and B, which are operand specifier modifier bits for vector registers, general registers, and memory addressing, and when combined with MOD R / M register field 1744 and MOD R / MR / M field 1746, allows access to the next set of 8 registers beyond the lower 8 registers. P[9:8] provides opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). P

[10] is a fixed value of 1 in some examples. P[14:11], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form and is valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain some value, for example, 1111b.

[0220] P

[15] is similar to W of the first prefix 1601 (A) and the second prefix 1611 (B), and can be used as an opcode extension bit or an operand size increase.

[0221] P[18:16] specifies the index of a register in an operation mask (write mask) register (e.g., write mask / predicate register 1515). In one example, a particular value aaa=000 has special behavior, implying that no operation mask is used for this particular instruction (this can be implemented in a variety of ways, including using an operation mask hardwired to all ones or hardware that bypasses the masking hardware). When merging, the vector mask allows any set of elements in the destination to be protected from update during the execution of any operation (specified by the basic operation and the enhanced operation); in another example, the old value of each element of the destination is retained (if the corresponding mask bit has a value of 0). Conversely, when zeroing, the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the basic operation and the enhanced operation); in one example, the elements of the destination are set to 0 when 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 being performed (i.e., the span of elements modified, from first to last); however, the elements modified do not have to be consecutive. Thus, the operation mask field allows for partial vector operations, including loads, stores, arithmetic, logical, etc. Although in the described examples, the contents of the operation mask field select one of several operation mask registers containing an operation mask to be used (thus the contents of the operation mask field indirectly identify the masking to be performed), alternative examples alternatively or additionally allow the contents of the mask write field to directly specify the masking to be performed.

[0222] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that can utilize P

[19] to access the upper 16 vector registers. P

[20] encodes a variety of features that vary between different classes of instructions and can affect the meaning of the vector length / rounding control specifier field (P[22:21]). P

[23] indicates support for merge-write masking (e.g., when set to 0) or support for zeroing and merge-write masking (e.g., when set to 1).

[0223] Examples of encodings of registers in instructions using the third prefix 1601 (C) are detailed in the table below.

[0224]

[0225] Table 1: 32-register support in 64-bit mode

[0226]

[0227] Table 2: Encoding register specifiers in 32-bit mode

[0228]

[0229]

[0230] Table 3: Operation Mask Register Specifier Encoding

[0231] Program code can be applied to input information to perform functions described herein and generate output information. Output information can be applied to one or more output devices in a known manner. For the present application, processing system includes any system with a processor, such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microprocessor or any combination thereof.

[0232] Program code can be implemented in a process-oriented or object-oriented high-level programming language to communicate with the processing system. If desired, program code can also be implemented in assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled language or an interpreted language.

[0233] Examples of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementations. Examples may be implemented as computer programs or program codes that are executed on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0234] One or more aspects of at least one example may be implemented by representative instructions stored on a machine-readable medium, which represent various logics within a processor, and which, when read by a machine, cause the machine to fabricate logic for performing the techniques described herein. These representations are referred to as "intellectual property (IP) cores" and may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into a fabrication machine that fabricates the logic or processor.

[0235] Such machine-readable storage media may include, but are not limited to, a non-transitory tangible arrangement of an article manufactured or formed by a machine or apparatus, including storage media such as a hard disk, any other type of disk (including floppy disks, optical disks, compact disk-read only memory (CD-ROM), compact disk-rewritable (CD-RW), and magneto-optical disks), semiconductor devices (e.g., 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 medium suitable for storing electronic instructions.

[0236] Thus, examples also include non-transitory tangible machine-readable media containing instructions or containing design data, such as hardware description languages ​​(HDL), that define the structures, circuits, devices, processors and / or system features described herein. Such examples may also be referred to as program products.

[0237] Simulation (including binary translation, code deformation, etc.).

[0238] In some cases, the instruction converter can be used to convert instructions from a source instruction set architecture to a target instruction set architecture. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions to one or more other instructions to be processed by the core. The instruction converter can be implemented with software, hardware, firmware or a combination thereof. The instruction converter can be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0239] Fig. 22 The block diagram of shows the use of a software instruction converter according to an example, which is used to convert binary instructions in a source ISA into binary instructions in a target ISA. In the illustrated example, the instruction converter is a software instruction converter, but alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig. 22 It is shown that a program in a high-level language 2202 can be compiled using a first ISA compiler 2204 to generate first ISA binary code 2206, which can be natively executed by a processor having at least one first ISA core 2216. The processor having at least one first ISA core 2216 represents any processor that is capable of executing or otherwise processing (1) a substantial portion of the first ISA or (2) a program in a first ISA on a processor having at least one first ISA core. The first ISA compiler 2204 represents a compiler operable to generate first ISA binary code 2206 (e.g., object code) that can be executed on a processor 2216 having at least one first ISA core with or without additional linking processing. Similarly, Fig. 22 It is shown that the program of high-level language 2202 can be compiled with alternative ISA compiler 2208 to generate alternative ISA binary code 2210, which can be executed natively by processor 2214 without first ISA core. Instruction converter 2212 is used to convert first ISA binary code 2206 into code that can be executed natively by processor 2214 without first ISA core. The conversion code is not necessarily the same as alternative ISA binary code 2210; however, the conversion code will implement the overall operation and be composed of instructions from the alternative ISA. Therefore, instruction converter 2212 represents software, firmware, hardware or a combination thereof, which allows a processor or other electronic device without a first ISA processor or core to execute first ISA binary code 2206 through simulation, emulation or any other process.

[0240] Reference to "one example," "example," etc. indicates that the example being described may include a particular feature, structure, or characteristic, but not every example may include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same example. In addition, when a particular feature, structure, or characteristic is described in conjunction with one example, it should be considered that it is within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other examples (whether or not explicitly described).

[0241] Examples include, but are not limited to:

[0242] 1. A device comprising:

[0243] decoder circuitry for decoding an instance of a single instruction, the single instruction including a field for an opcode; and

[0244] An execution circuit is configured to execute the decoded instruction according to the operation code to return processor identification and feature information, the processor identification and feature information including an enumeration of heterogeneous performance monitoring unit capabilities.

[0245] 2. The apparatus of example 1, wherein capabilities of the performance monitoring unit are enumerated using a leaf at EAX=23H.

[0246] 3. An apparatus as described in any of Examples 1-2, wherein the heterogeneous performance monitoring unit capabilities include an indication of valid sub-leafs.

[0247] 4. An apparatus as described in any of Examples 1-3, wherein the heterogeneous performance monitoring unit capabilities include an indication of supported general purpose counters.

[0248] 5. An apparatus as described in any of Examples 1-4, wherein the heterogeneous performance monitoring unit capabilities include an indication of supported fixed function counters.

[0249] 6. An apparatus as described in any of Examples 1-5, wherein the heterogeneous performance monitoring unit capabilities include an indication of supported performance monitoring events.

[0250] 7. An apparatus as described in any of Examples 1-6, wherein the operation code is 0F A2.

[0251] 8. A method comprising:

[0252] decoding an instance of a single instruction, the single instruction including a field for an opcode; and

[0253] The decoded instruction is executed according to the opcode to return processor identification and feature information, including an enumeration of heterogeneous performance monitoring unit capabilities.

[0254] 9. The method of example 8, wherein the heterogeneous performance monitoring unit capabilities are enumerated using the leaf at EAX=23H.

[0255] 10. A method according to any of Examples 8-9, wherein the enumerated heterogeneous performance monitoring unit capabilities include an indication of valid sub-leafs.

[0256] 11. A method according to any of Examples 8-10, wherein the enumerated heterogeneous performance monitoring unit capabilities include an indication of supported general counters.

[0257] 12. The method of any of Examples 8-11, wherein the enumerated heterogeneous performance monitoring unit capabilities include an indication of supported fixed function counters.

[0258] 13. A method according to any of Examples 8-12, wherein the enumerated heterogeneous performance monitoring unit capabilities include an indication of supported performance monitoring events.

[0259] 14. The method of any one of Examples 8-13, wherein the opcode is 0F A2.

[0260] 15. A system, including a method, comprising:

[0261] A memory for storing instances of individual instructions;

[0262] Processor core, including:

[0263] decoder circuitry for decoding an instance of a single instruction, the single instruction including a field for an opcode; and

[0264] An execution circuit is configured to execute the decoded instruction according to the operation code to return processor identification and feature information, the processor identification and feature information including an enumeration of heterogeneous performance monitoring unit capabilities.

[0265] 16. The system of example 15, wherein heterogeneous performance monitoring unit capabilities are enumerated using a leaf at EAX=23H.

[0266] 17. A system according to any of Examples 15-16, wherein the enumerated heterogeneous performance monitoring unit capabilities include an indication of valid sub-leafs.

[0267] 18. The system of any of Examples 15-17, wherein the enumerated heterogeneous performance monitoring unit capabilities include an indication of supported generic counters.

[0268] 19. A system according to any of Examples 15-18, wherein the enumerated heterogeneous performance monitoring unit capabilities include an indication of supported fixed function counters.

[0269] 20. The system of any of Examples 15-19, wherein the enumerated heterogeneous performance monitoring unit capabilities include an indication of supported performance monitoring events.

[0270] In addition, in the various examples described above, unless otherwise specifically noted, selection language such as phrases "at least one of A, B, or C" or "A, B and / or C" should be understood to refer to A, B, or C, or any combination thereof (i.e., A and B, A and C, B and C, and A, B and C).

[0271] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the claims.

Claims

1. A device comprising: decoder circuitry for decoding an instance of a single instruction, the single instruction including a field for an opcode; as well as An execution circuit is configured to execute the decoded instruction according to the opcode to return processor identification and feature information, the processor identification and feature information including an enumeration of heterogeneous performance monitoring unit capabilities.

2. The device according to claim 1, wherein: The capabilities of the performance monitoring unit are enumerated using the leaf at EAX=23H.

3. The device according to any one of claims 1 to 2, wherein: The heterogeneous performance monitoring unit capabilities include an indication of valid sub-leafs.

4. The device according to any one of claims 1 to 3, wherein: The heterogeneous performance monitoring unit capabilities include an indication of the supported generic counters.

5. The device according to any one of claims 1 to 4, wherein: The heterogeneous performance monitoring unit capabilities include an indication of supported fixed function counters.

6. The device according to any one of claims 1 to 5, wherein: The heterogeneous performance monitoring unit capabilities include an indication of supported performance monitoring events.

7. The device according to any one of claims 1 to 6, wherein: The operation code is 0FA2.

8. A method comprising: decoding an instance of a single instruction, the single instruction including a field for an opcode; as well as The decoded instruction is executed according to the opcode to return processor identification and feature information including an enumeration of heterogeneous performance monitoring unit capabilities.

9. The method according to claim 8, wherein: The heterogeneous performance monitoring unit capabilities are enumerated using the leaf at EAX=23H.

10. The method according to any one of claims 8 to 9, wherein: The enumerated heterogeneous performance monitoring unit capabilities include an indication of valid sub-leafs.

11. The method according to any one of claims 8 to 10, wherein: The enumerated heterogeneous performance monitoring unit capabilities include an indication of supported generic counters.

12. The method according to any one of claims 8 to 11, wherein: The enumerated heterogeneous performance monitoring unit capabilities include an indication of supported fixed function counters.

13. The method according to any one of claims 8 to 12, wherein: The enumerated heterogeneous performance monitoring unit capabilities include an indication of supported performance monitoring events.

14. The method according to any one of claims 8 to 13, wherein: The operation code is 0FA2.

15. A system, including a method, comprising: A memory for storing instances of individual instructions; Processor core, including: decoder circuitry for decoding said instance of said single instruction, said single instruction including a field for an opcode; as well as An execution circuit is configured to execute the decoded instruction according to the opcode to return processor identification and feature information, the processor identification and feature information including an enumeration of heterogeneous performance monitoring unit capabilities.

16. The system of claim 15, wherein: The heterogeneous performance monitoring unit capabilities are enumerated using the leaf at EAX=23H.

17. The system according to any one of claims 15-16, wherein: The enumerated heterogeneous performance monitoring unit capabilities include an indication of valid sub-leafs.

18. The system according to any one of claims 15 to 17, wherein: The enumerated heterogeneous performance monitoring unit capabilities include an indication of supported generic counters.

19. The system according to any one of claims 15 to 18, wherein: The enumerated heterogeneous performance monitoring unit capabilities include an indication of supported fixed function counters.

20. The system according to any one of claims 15 to 19, wherein: The enumerated heterogeneous performance monitoring unit capabilities include an indication of supported performance monitoring events.

Images