DEVICE, METHOD, AND SYSTEM TO DETERMINE A COUNT OF RETIRED PREFETCH INSTRUCTIONS

Techniques and mechanisms for circuitry of a processor to determine a count of prefetch instructions which have been retired, or are designated for retirement. In an embodiment, a performance monitoring unit (PMU) monitors the execution of an instruction sequence by a core of said processor. The PMU detects the retirement of a first instruction, and further makes a first determination that the instruction is of a prefetch instruction type. Based on the first determination, counter circuitry of the processor updates a count of one or more instruction retirements, wherein each such retired instruction is of the prefetch instruction type. The PMU further makes a second determination that another retired second instruction is of a non-prefetch instruction type. In another embodiment, the counter circuitry prevents any updating of that same count based on the second determination.

BACKGROUND

1. Technical Field

This disclosure generally relates to processor operations and more particularly, but not exclusively, to monitor the retirement of prefetch instructions by a processor.

2. Background Art

Performance analysis provides a foundation for characterizing, debugging, and tuning a micro-architectural processor design, for finding and fixing performance bottlenecks in hardware and software, and for locating avoidable performance issues. Various processors support the generation of trace data regarding software which is being executed. Such trace data is typically used by programmers for debugging purposes, and/or by system administrators, technical support personnel or software monitoring tools to diagnose problems with installed software.

An additional debugging feature referred to as Precise Event Based Sampling (PEBS) is also provided in various types of processors. PEBS is a profiling mechanism that logs a snapshot of processor state at the time of the event, allowing users to attribute performance events to actual instruction pointers (IPs). As the computer industry progresses, the ability to analyze the performance of a microarchitecture and make changes to the microarchitecture based on that analysis becomes more complex and important.

DETAILED DESCRIPTION

Embodiments described herein variously provide techniques and mechanisms for circuitry of a processor to determine a count of prefetch instructions which have been retired, or are designated for retirement. In some embodiments, a first counter of a processor is dedicated to maintain up-to-date a first count of retirement events for instructions which are each of a prefetch instruction type. In one such embodiment, a second counter of said processor is operable to concurrently maintain up-to-date a second count of retirement events for other instructions including, for example, one or more instructions other than any prefetch instruction.

The technologies described herein may be implemented in one or more electronic devices. Non-limiting examples of electronic devices that may utilize the technologies described herein include any kind of mobile device and/or stationary device, such as cameras, cell phones, computer terminals, desktop computers, electronic readers, facsimile machines, kiosks, laptop computers, netbook computers, notebook computers, internet devices, payment terminals, personal digital assistants, media players and/or recorders, servers (e.g., blade server, rack mount server, combinations thereof, etc.), set-top boxes, smart phones, tablet personal computers, ultra-mobile personal computers, wired telephones, combinations thereof, and the like. More generally, the technologies described herein may be employed in any of a variety of electronic devices including a processor that supports performance monitoring functionality.

Performance Monitoring Metrics, or Perf Metrics, are a type of feature which is implemented in some processors. This feature allows a CPU (or other processor) to expose a performance metric directly to software. By way of example, Instructions-Retired and Cycles are two commonly available performance monitoring events. In traditional performance monitoring mechanisms, software queries one or more counters which are variously configured each to maintain a respective count of events which are of a corresponding event type. The processor exposes one or more counts of performance monitoring events, which (for example) are used by software to determine metrics of processor performance.

In one embodiment, a processor generates performance monitoring metrics based on collected performance monitor data and exposes the performance monitoring metrics directly to software.FIG.1illustrates an exemplary system100, according to one example embodiment, which comprises a processor125and a system memory126coupled thereto via (for example) a shared Level 3 (L3) cache116. Processor125comprises one or more cores (e.g., including the illustrative plurality of cores 0-N shown) each for executing a respective instruction thread. A plurality of counters (e.g., including the illustrative counters161,162shown), which may include fixed function counters and/or programmable counters, may collect performance monitor data from various stages of the instruction processing pipeline such as instructions retired and, for example, a number of cycles.

A performance monitor unit (PMU)160, illustrated with respect to Core0, performs the techniques described herein using data such as that stored in the counters161,162. In particular, a performance metric generator170uses the performance data accumulated in the performance counters161,162to generate a specific set of performance metric values, which are stored (in one embodiment) within one or more performance metric model specific registers (MSRs)180.

While details of only a single core (Core0) are shown inFIG.1, it will be understood that each of one or more other cores of processor125may include similar components. Moreover, while the PMU160is illustrated as a separate unit within Core0, components of the PMU, such as counters161,162may be variously distributed at various instruction processing pipeline stages (e.g., within the retirement unit150to maintain a count of retired instructions). Prior to describing additional details of some embodiments, a description of the various components of the exemplary processor125are provided.

As mentioned, the exemplary embodiment includes a plurality of cores 0-N, each including a memory management unit190for performing memory operations (e.g., such as load/store operations), a set of general purpose registers (GPRs)105, a set of vector registers106, and a set of mask registers107. In one embodiment, multiple vector data elements are packed into each one of the vector registers106, which may have a 512 bit width for storing two 256 bit values, four 128 bit values, eight 64 bit values, sixteen 32 bit values, etc. However, various embodiments are not limited to any particular size/type of vector data. In one embodiment, the mask registers107include eight 64-bit operand mask registers used for performing bit masking operations on the values stored in the vector registers106. However, some embodiments are not limited to any particular mask register size/type.

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

In an embodiment, the instruction fetch unit110includes any of various well known components including a next instruction pointer103for storing the address of the next instruction to be fetched from memory126(or one of the caches); an instruction translation look-aside buffer (ITLB)104for storing a map of recently used virtual-to-physical instruction addresses to improve the speed of address translation; a branch prediction unit102for speculatively predicting instruction branch addresses; and branch target buffers (BTBs)101for storing branch addresses and target addresses. Once fetched, instructions are then streamed to the remaining stages of the instruction pipeline including the decode unit130for decoding the instructions to generate micro-operations (micro-operations), the execution unit140to execute the micro-operations, and the writeback/retirement unit150to retire the instructions. The structure and function of each of these units is well understood by those of ordinary skill in the art and will not be described here in detail to avoid obscuring the pertinent aspects of different embodiments.

In one embodiment, built-in metrics are specified—e.g., in a microarchitecture-specific, or alternatively, a microarchitecture-independent and/or otherwise abstracted manner —such that they can apply to an of various implementations. In particular, in one embodiment, counter161may count prefetch instructions which have been retired and counter162may count other instructions (i.e., including at least some instructions which are of a type other than a prefetch type) which have been retired.

The performance metric generator170may collect some or all of these values from their respective counters to generate one or more performance metric values, which it then stores in the performance monitor model specific register(s)180. In one embodiment, software may then access the MSR values to determine the current performance metric values.

As illustrated inFIG.1, in one embodiment, the processor125implements one or more internal (e.g., software invisible) counters—such as the illustrative counters161,162shown—for any of various supported metrics. The internal counters161,162may, for example, be microarchitecture specific and different architectures may include different numbers of them (e.g., 2, 4, 6, etc.). In one embodiment, the performance metric generator170, which may be implemented in microcode and/or dedicated circuitry, converts these internal counters161,162(and/or other counters of Core0) to the software-visible performance metric data when requested by software. The performance monitor data may then be stored within one or more model specific register(s)180which are exposed to the software.

Some embodiments variously modify, expand or otherwise adapt a functionality, such as that provided in certain existing processor architectures, which facilitates the counting of events which are each of a particular event type. By way of illustration and not limitation, some embodiments variously extend a functionality—such as that provide by the MEM_INST_RETIRED event monitoring by various x86 processor architectures—to monitor retired instructions. The maintaining of a given current count of events is also referred to herein as “tracking” said count. For example, some embodiments variously maintain a current count of events which are variously referred to herein as “instruction retirement events,” “instruction retirements,” or (for brevity) simply “retirements.” A given instruction retirement event includes the retirement of a respective instruction (e.g., a retirement by writeback/retirement unit150), the execution of which was at least attempted—and, in some cases, completed—by one or more processor cores for which the count in question is being maintained.

In various embodiments, processor125supports the tracking of a count of instruction retirements which are each of a more particular sub-type of the instruction retirement type. In one such embodiment, for each instruction retirement which is counted with (or “included in”) a given count, the retirement is that of a respective instruction which is of a prefetch instruction type. For example, some instruction sets (such as that for various x86 instruction set architectures) variously support some type of prefetch instruction which is to explicitly request that one or more instructions, and/or some data, are to be prefetched—e.g., from a cache, if available—for earlier retrieval, speculative execution and/or any of various other purposes. This type of prefetch instruction (or “prefetch instruction type” herein) is to be distinguished, for example, from one or more other non-prefetch types of instructions. For example, instructions of another instruction type—referred to herein as a “demand” instruction type—are executed within a predetermined instruction sequence, wherein said execution is to perform an operation other than the prefetching of other information. By way of illustration and not limitation, a load instruction (to load data from memory for use by a processor) is one example of an instruction which is of a demand instruction type.

In various embodiments, the respective retirements of some or all prefetch instructions are candidates to be at least potentially included in a count of instruction retirements. For example, the fact that a given instruction is of a prefetch instruction type at least provisionally qualifies the retirement of said instruction for inclusion in a retirement event count—e.g., wherein the retirement qualifies for further evaluation to determine whether such inclusion is to be permitted or prevented. By contrast, in some embodiments, the fact that another given instruction is of a non-prefetch instruction type (e.g., is of a demand type) precludes the retirement of said other instruction from being included in that same retirement event count.

In various embodiments, the inclusion of a given retirement in a count of prefetch instruction retirements is conditioned upon whether the retired instruction in question is of a prefetch instruction type. In some embodiments, such inclusion is further conditioned on one more other criteria (e.g., one or more “filter rules”) regarding, for example, the attempted execution of the instruction in question. By way of illustration and not limitation, in some embodiments, the retirement is to be included in the count, according to one filter rule, where it is determined that the attempt to execute the instruction resulted in a hit of a translation look-aside buffer (“TLB”)—e.g., a hit of ITLB104, or a shared TLB (STLB). In another embodiment, the retirement is to be included in the count, according to an alternative filter rule, where it is instead determined that the attempt to execute the instruction resulted in a miss of the TLB. Additionally or alternatively, the retirement is to be included in the count, according to a different filter rule, where it is determined that the attempt to execute the instruction resulted in a detection of (e.g., an attempt to access) a locked object. Additionally or alternatively, the retirement is to be included in the count, according to a different filter rule, where it is determined that the attempt to execute the instruction resulted in an access to (e.g., a reading of, or alternatively, a writing of) an object which is split across multiple cache lines. In some embodiments, the inclusion of a given prefetch retirement in a count of prefetch instruction retirements is additionally or alternatively conditioned upon a privilege level or other security characteristic of a software process or other resource which includes, utilizes or is otherwise associated with the prefetch instruction.

Accordingly, some embodiments variously facilitate the provisioning of a count of some or all prefetch instruction retirements—e.g., wherein said count is exclusive of demand instruction retirements and/or other non-prefetch instruction retirements. Such embodiments thus provide a more specific type of performance monitoring information which, for example, helps programmers understand whether and/or how prefetch instructions are being (in)efficiently placed in software code.

FIG.2Aillustrates features of a method200which is performed with a processor to provide information describing a retirement of instructions according to an embodiment. Method200illustrates one example of an embodiment wherein a first count of retired first instructions is tracked in addition to a second count of retired second instructions, wherein each of the first instructions is of a prefetch instruction type, and wherein some or all of the second instructions are each of a respective type other than any prefetch instruction type. For example, method200is performed with processor125, in some embodiments.

As shown inFIG.2A, method200comprises (at210) monitoring an execution of instructions by the processor. For example, in one embodiment, the monitoring at210includes or is otherwise based on PMU160receiving—e.g., from execution unit140or the writeback/retirement unit150—information which specifies or otherwise indicates, for each of multiple instructions in an instruction stream, the respective status of processing of that instruction by Core0of processor125. In various embodiments, the monitoring at210includes operations which (for example) are adapted from conventional performance monitoring techniques, which are not detailed herein to avoid obscuring said embodiments.

Method200further comprises (at212) detecting a retirement of a first instruction, and making a first determination (at214) that the first instruction is of a prefetch type. In one such embodiment, the first determination is made at214by circuitry of PMU160identifying an opcode of the first instruction as belonging to a prefetch opcode type. Based on the first determination, method200(at216) updates a first count of one or more retirements each of a respective instruction which is of the prefetch type. In one illustrative embodiment, the first count is maintained by counter161. For example, in one such embodiment, counter161is a fixed function counter at least insofar as it is dedicated to counting only retirement events for instructions which are each of a prefetch instruction type. However, in some embodiments, counter161comprises or otherwise operates based on circuitry which is (re)programmable or otherwise (re)configurable to selectively apply one or more filter rules in the counting of prefetch retirement events.

Method200further comprises (at218) detecting a retirement of a second instruction, and making a second determination (at220) that the second instruction is of an instruction type other than the prefetch type. In one such embodiment, the second determination is made at220by circuitry of PMU160identifying an opcode of the second instruction as belonging to a demand opcode type (for example).

Based on the second determination, method200(at222) generates a signal to prevent an update of the first count. Accordingly, in some embodiments the first count is specific to only one or more types of prefetch instruction retirements, and does not further reflect any demand (or other non-prefetch) instruction type(s). In various embodiment, method200—based on the second determination—further updates a second count of one or more retirements. For example, the one or more retirements indicated by the second count are each for a respective instruction which is of an instruction type other than any prefetch instruction type. For example, the second count represents a count of only demand instruction retirement events, in some embodiments. In other embodiments, the second count represents a count of instruction retirement events including both demand instruction retirement events and prefetch instruction retirement events.

In one illustrative embodiment, the second count is maintained by counter162. For example, in one such embodiment, counter162is a fixed function counter at least insofar as it is dedicated to counting at least retirement events for instructions which are each of a demand instruction type. However, in some embodiments, counter162comprises or otherwise operates based on circuitry which is (re)programmable or otherwise (re)configurable to selectively apply one or more filter rules in the counting of retirement events.

In some embodiments, method200further comprises one or more operations (not shown) which provide the first count and/or the second count as an output from the processor to a memory resource—e.g., for use by a programmer, system administrator, software monitoring tool or other suitable agent. By way of illustration and not limitation, the processor outputs the first and second count in a performance monitoring report such as one which is generated in response to a predetermined trigger event including (for example) the exceeding of a threshold value by one of the first count or the second count.

FIG.2Billustrates features of a method250to provide counts of respective instruction retirements according to another embodiment. Method250is performed with processor125, in some embodiments—e.g., wherein method250includes or is otherwise based on some or all operations of method200.

Method250may begin at any suitable point and may execute in any suitable order. In one embodiment, method250may begin at260. In various embodiments, method250may be performed during operation of a processor component such as the Core0of processor125. Moreover, method250may be performed by any suitable combination of one or more elements of processor125—e.g., wherein method250is performed with PMU160.

At260, it may be determined whether an instruction, to change a state of enablement—e.g., to change between an enabled state and a disabled state—for tracking instruction retirements, has been received. If such an instruction has been received, method250may proceed to261. Otherwise, method250may proceed to262. In one embodiment, at261, if such an instruction has been received, a functionality to track instruction retirements may be enabled or disabled by execution of the instruction, as appropriate.

Moreover, parameters of such tracking may be enacted or released at261. Such parameters include, for example, one or more filter rules to be applied in the determining of whether, for a given instruction (e.g., a prefetch instruction or, alternatively, a demand instruction), a retirement of said instruction is to be reflected in a particular count. In one such embodiment, a filter rule comprises one or more test criteria which are distinct from—e.g., in addition to—whether the instruction in question is retired (or is expected to be retired). Additionally or alternatively, a filter rule comprises one or more test criteria which are distinct from whether the instruction in question is of a prefetch instruction type.

By way of illustration and not limitation, such a test criteria imposes a requirement that an attempt to execute the given instruction resulted in a TLB miss (or, alternatively, resulted in a TLB hit, for example). Alternatively or in addition, such a test criteria imposes a requirement that the attempt to execute the given instruction resulted in a delay due to an object being locked. Alternatively or in addition, such a test criteria imposes a requirement that the attempt to execute the given instruction resulted in the accessing of an object which is split across multiple lines of a cache. Alternatively or in addition, such a test criteria imposes a requirement that the instruction is that of an instruction sequence which corresponds to a particular type of software process, a particular access privilege, and/or the like. In some embodiments, a filter rule imposes any of various additional or alternative test criteria for tracking instruction retirements.

At262, it may be determined whether another instruction, which may be candidate for tracking, has been retired (or, according to some predetermined criteria, is expected to be retired). If not, method250may return to260. If such an instruction has been retired, method250may proceed to263.

At263, it may be determined whether functionality to track instruction retirements has been enabled. If so, method250may proceed to264. Otherwise, method250may proceed to260, and the enablement state of retirement tracking is reevaluated.

At264, in one embodiment it may be determined whether the instruction, for which a retirement was most recently detected at262, is of a prefetch instruction type. If so, method250may proceed to265for the purpose of updating—e.g., conditionally—a first counter which is dedicated to tracking for the retirement of instructions of the prefetch instruction type.

At265, method250performs an evaluation to determine whether a first one or more filter rules, which are currently-enabled, are satisfied by the prefetch instruction in question (and/or by the attempt to execute said prefetch instruction). In some embodiments, the first one or more filter rules provide additional criteria for determining whether the prefetch retirement in question is to be indicated in a first count (i.e., a count of retired prefetch instructions) that is maintained by the first counter. In another embodiment, method250omits the evaluating at265—e.g., wherein no filter rules are currently enabled for the counting of prefetch instruction retirements, and wherein all prefetch retirements (e.g., at least all of those retired by a particular processor core) are to be indicated in the first count.

Where it is determined at265that the first one or more filter rules are satisfied, method250(at266) increments or otherwise updates the first count of prefetch retirements based on the most recently detected retirement of a prefetch instruction. Where it is instead determined at265that the first one or more filter rules are not satisfied, method250returns to260.

Where it is instead determined at264that the instruction in question is of a type other than the prefetch instruction type, method250may proceed to267for the purpose of updating a second counter which provides tracking for the retirement of other instructions (e.g., including one or more types of demand instructions).

At267, method250performs an evaluation to determine whether a second one or more filter rules, which are currently-enabled, are satisfied by the instruction in question (and/or by the attempt to execute said instruction). In some embodiments, the second one or more filter rules provide additional criteria for determining whether the retirement in question is to be indicated in a second count (e.g., a count of retired instructions including one or more demand instructions) that is maintained by the second counter. In another embodiment, method250omits the evaluating at267—e.g., wherein no filter rules are currently enabled for the second count, and wherein all demand retirements (e.g., at least all of those retired by a particular processor core) are to be indicated in the second count.

Where it is determined at267that the second one or more filter rules are satisfied, method250(at268) increments or otherwise updates the second count of retirements based on the most recently detected retirement of an instruction. Where it is instead determined at267that the second one or more filter rules are not satisfied, method250returns to260.

After the updating at266(or at268), method250performs another evaluation (at269) to determine whether the first counter, or (for example) the second counter, has exceeded a corresponding threshold which specifies or otherwise indicates a respective maximum number of instruction retirements.

If a threshold has been met, method250may proceed to270. Otherwise, method250may proceed to260, and the enablement state of retirement tracking is reevaluated. At270, an alert may be generated. The alert may include an interrupt, a PEBS record, or any of various other suitable notifications. The alert may be sent, for example, to an interrupt handler or a user of a system—e.g., wherein the alert includes or otherwise communicates the respective current values of the first count and the second count.

FIG.3is a block diagram of a portion of a system300for generating a count of retired prefetch instructions, according to embodiments of the present disclosure. System300illustrates one example embodiment wherein circuitry of a processor is operable to concurrently track both a number of retired instructions which are each of a prefetch instruction type, and an additional number of other retired instructions including (for example) one or more instructions other than any prefetch instructions. In various embodiments, system300provides functionality such as that of system100—e.g., wherein operations of one of methods200,250are performed with a processor of system300.

As shown inFIG.3, system300comprises a processor302which is configured to execute instructions of an instruction stream304. Processor302may be implemented as processor125, for example. Processor302may include a front end306, which may receive and decode instructions from instruction stream304using a decoder308. The decoded instructions may be dispatched, allocated, and scheduled for execution by allocator/scheduler310, and allocated to specific execution units312or cores. After execution, instructions may be retired by a writeback stage or retirement unit314. Although various operations are described herein as performed by specific components of processor302, the functionality may be performed by any suitable portion of processor302.

In various embodiments, processor302may receive, decode, schedule, execute, and retire first instructions that are each of a prefetch instruction type, wherein processor302is to track a count of the first instructions (or, for example, a count of a subset of the first instructions). In some embodiments, processor302is further to receive, decode, schedule, execute, and retire second instructions including—for example—one or more instructions which are each of a respective type other than the prefetch instruction type. In one such embodiment, processor302is to further track a count of the second instructions—e.g., a count of retired demand (and/or other) instructions.

By way of illustration and not limitation, processor302comprises circuitry—e.g., a processor trace unit (PTU)316, a performance monitoring unit (PMU)318, and/or the like —which is suitable to monitor the execution of instructions, and to generate one or more counts each of a respective one or more instruction retirements. In one embodiment, PMU318includes, is coupled to, or is otherwise operable to update some or all such counts—e.g., wherein the updating of a given count is conditioned based on one or more count filter rules. In some embodiments, PTU316is configured to produce status data based on some predetermined event, such as a threshold number of times that instructions of a particular instruction type have been retired.

In one embodiment, processor302comprises multiple counters (e.g., including the illustrative first counter330and second counter332shown) which are variously available each to maintain a respective count of events including, for example, instruction retirements. In one such embodiment, at least one counter is operated to count only retirements of prefetch instructions—e.g., wherein at least one other counter is operated to count retirements of at least some other type(s) of instructions. For example, some embodiments provide one or more fixed counters which are variously dedicated each to counting only a respective type (or types) of instructions. Some embodiments additionally or alternatively provide (re)configurable counter circuitry to selectively enable the counting of retirements for any of various combinations of one or more instruction types.

In an illustrative scenario according to one embodiment, the first counter330is operated to count the retirements of some or all prefetch instructions. In one such embodiment, first counter330is a dedicated, fixed function counter which able to count retirements for only instructions of a prefetch instruction type. In some embodiments, first counter330is (re)configurable to selectively provide retirement counting for any of various combinations of some or all sub-types of the prefetch instruction type.

By contrast, second counter332(for example) is operable to count instructions which are each of a respective type other than the prefetch instruction type. In one such embodiment, second counter332is a dedicated, fixed function counter which able to count retirements for only instructions of a demand instruction type (and/or other non-prefetch instruction type). In some embodiments, second counter332is (re)configurable to selectively provide retirement counting for any of various combinations of some or all sub-types of a demand (and/or other) instruction type.

Instructions, bootup configuration, and/or other mechanisms to enable or disable the counting of retired instructions may be implemented in any suitable manner. In one embodiment, a “count” instruction may be available for instruction on processor302that includes parameters identifying a given counter, and one or more types of instructions for which retirements are to be counted with that given counter. A “clear” or “disable counting” instruction may reverse the operation of the “count” function. In some embodiments, the instructions for enabling or disabling tracking may include one or more parameters to further define counter operations to be performed by processor302.

The processor302may include any of various suitable number and kind of resources320to support the tracking of prefetch instruction retirements. Resources320may be variously implemented as registers, flags, data structures, bits, instructions, or other suitable mechanisms. Multiple sets of some or all of resources320may be included so that different types of instructions retirement events can be tracked each with a different respective count—e.g., wherein a given counter of processor302is (re)configurable to maintain a count in any of multiple different ways.

By way of illustration and not limitation, processor302comprises a mechanism to selectively enable performance monitoring such as that which enables the tracking of instruction retirements. For example, resources320may include an enable PEBS register340to enable precise event based sampling (PEBS) or any other suitable designation of data to be returned. Furthermore, the format or types of data to be provided as part of the PEBS may be specified. In addition, other actions, such as interrupts, may be specified by registers in system300. A call stack, PerfMon framework, instruction pointer, architectural state of processor302, and register values may be included in the PEBS, for example.

In some embodiments, resources320additionally or alternatively comprises an enable CTRS register338to identify which counters are to be used for determining one or more event counts. For example, enable CTRS register338identifies a particular combination of counters—e.g., including first counter330, and second counter332, in one example scenario—as being variously enabled each to maintain a respective event count.

In some embodiments, resources320additionally or alternatively comprises one or more filter rule registers326which are used to selectively enact or release any of various rules according to which a given instruction retirement is to be included in (or alternatively, excluded from) a particular retirement count. Filter rule register(s)326are updated, for example, based on one or more parameters of a “count” instruction to enable or disable the counting of retired instructions. By way of illustration and not limitation, filter rule register(s)326facilitate the enacting of a rule that an instruction retirement is to be counted where (for example) an attempt to execute the instruction in question resulted in a TLB miss. Alternatively or in addition, filter rule register(s)326facilitate the enacting of a rule that an instruction retirement is to be counted where the attempt to execute the instruction in question resulted in a TLB hit. In some embodiments, filter rule register(s)326facilitate the enacting of an additional or alternative rule that an instruction retirement is to be counted where the attempt to execute the given instruction resulted in a delay due to an object being locked. Alternatively or in addition, filter rule register(s)326facilitate the enacting of a rule that an instruction retirement is to be counted where the attempt to execute the given instruction resulted in the accessing of an object which is split across multiple lines of a cache. In some embodiments, filter rule register(s)326facilitate the enacting of an additional or alternative rule that an instruction retirement is to be counted where the instruction in question is that of an instruction sequence which corresponds to a particular type of software process, a particular access privilege, and/or the like. However, filter rule register(s)326enable any of various other rules, in different embodiments.

In an embodiment, resources320includes or otherwise has access to one or more thresholds334for determining when a first count and a second count—e.g., maintained by first counter330and second counter332, respectively—are to be provided as an output to a programmer, system administrator, operating system, software monitoring tool or other suitable agent. Threshold(s)334are provided, for example, to a mode register based on one or more parameters of a “count” instruction to enable or disable the counting of retired instructions. In some embodiments, multiple thresholds are variously set each for a different respective counter of resources320.

In an illustrative scenario according to one embodiment, when a given counter has reached a corresponding one of threshold(s)334, then PMU318or PTU316may take a previously specified action. After the action is taken, the first counter330and second counter332may be cleared by PMU318or PTU316, for example.

FIG.4illustrates features of a system400which is operable to monitor retired instructions according to an embodiment. System400illustrates one embodiment wherein a processor tracks the respective counts of two or more types of instruction retirements, including a count of prefetch instruction retirements, and another count of retirements including those of non-prefetch (e.g., demand) instructions. In various embodiments, system400provides functionality such as that of system100or system300—e.g., wherein operations of one of methods200,250are performed with a processor of system400.

In the example embodiment of system400, an instruction—to enable, disable or otherwise (re)configure a counting of instruction retirements—is received, at (1), for execution by a processor402. At (2), the instruction enabling or disabling the counting of instruction retirements is executed and resources are set as appropriate. For example, an initialization of a first counter—which is dedicated (or alternatively, is configurable) to count only prefetch instruction retirements—may be issued from PTU416to PMU418. Additionally or alternatively, an initialization of a second counter—which is dedicated (or alternatively, is configurable) to count demand (and/or other non-prefetch) instruction retirements—may be similarly issued. Furthermore, any of various filter rules and/or other parameters for event counting may be provided—e.g., as one or more parameters of the instruction received at (1).

At (3), a subsequent instruction may be received for execution at processor402. At (4), the subsequent instruction may be executed and retired by a retirement stage414. The address, instruction pointer, process id, priority, and other suitable information about the instruction may be provided to PMU418.

In an embodiment, PMU418includes, or is coupled to, counter circuitry which applies one or more filter rules to determine whether, for a given count of retired instructions, the retirement of the subsequent instruction received at (3) is to be include in said count. In one embodiment, at (5) PMU418may count the retired instruction based upon the process of the instruction if retirement count has been enabled. If the retired instruction matches an identifier of processes to be tracked (such as an identifier stored in a register424), the retirement of the instruction may remain as a candidate to possibly be counted. Otherwise the retired instruction may be filtered from inclusion in some or all retirement counts.

At (6), in one embodiment PMU418may additionally or alternatively determine (if privilege-based count filtering has been enabled) whether to filter a counting of the retired instruction based upon a privilege of the instruction. If the retired instruction's privilege level matches an identifier of the privilege of processes to be tracked (such as an identifier stored in a register428), the instruction may remain as a candidate to possibly be counted. Otherwise the retired instruction may be filtered from inclusion in some or all retirement counts.

At (7), if one or more additional filter rules are currently enacted, and if the retired instruction qualifies for counting under each of said one or more additional filter rules, then in one embodiment, an appropriate count (such as one of the illustrative counts430,432shown), is incremented or otherwise updated by PMU418.

At (8), in one embodiment PMU418determines if the value of a given counter exceeds a corresponding threshold (such as the illustrative threshold434for count430, and the threshold436for count432). If such a threshold has been reached, PMU418may determine whether (for example) performance monitoring data is to be output, and/or whether corrective action is to be taken. By way of illustration and not limitation, at (9), in one embodiment PMU418determine what actions are to be taken, such as generating an interrupt, generating a PEBS record, determining what data is to be included in a PEBS record440, or another sort of alert. At (10), the alert may be sent to an appropriate consumer, such as an interrupt handler or a user of processor402.

FIG.5illustrates features of processor circuitry500which is operable to track retired instructions according to an embodiment. Processor circuitry500provides functionality to perform operations of one of methods200,250(for example)—e.g., wherein one of processors125,302,402comprises processor circuitry500.

As shown inFIG.5, processor circuitry500is coupled to receive a control signal510which indicates whether a counting of retired prefetch instructions (e.g., only retired prefetch instructions) is to be enabled. Furthermore, processor circuitry500is coupled to receive a signal511which indicates whether a next instruction in a pipeline of the processor has been retired, wherein said retirement is to be evaluated for possible counting with processor circuitry500. Further still, processor circuitry500is coupled to receive a signal512which indicates whether the next retired instruction is of a prefetch type.

In one such embodiment, processor circuitry500further receives one or more signals (such as the illustrative signals513-517shown) which each indicate whether, for a given prefetch instruction under consideration, a corresponding filter rule has been satisfied for including a retirement of said prefetch instruction in a count of retired instructions. For a given one of signals513through517, the signal is set to a logic low state if the corresponding filter rule is not currently enacted.

By way of illustration and not limitation, signal513indicates whether the retired prefetch instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that an attempt to execute the prefetch instruction in question resulted in a TLB hit. Alternatively or in addition, signal514indicates whether the retired prefetch instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that an attempt to execute the prefetch instruction in question resulted in a TLB miss.

In some embodiments, signal515indicates whether the retired prefetch instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that an attempt to execute the prefetch instruction in question resulted in a locked object being accessed or otherwise detected. Alternatively or in addition, signal516indicates whether the retired prefetch instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that an attempt to execute the prefetch instruction in question resulted in the accessing of an object which is split across multiple lines of a cache. In various embodiments, signal517indicates whether the retired prefetch instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that any retired prefetch instruction is to be included in the counting.

In one such embodiment, processor circuitry500is further coupled to receive another control signal520which indicates whether a counting of retired demand instructions (e.g., only retired demand instructions) is to be enabled. In one such embodiment, processor circuitry500further receives one or more additional signals (such as the illustrative signals523-527shown) which each indicate whether, for a given demand instruction under consideration, a corresponding filter rule has been satisfied for including a retirement of said demand instruction in a count of retired instructions. For a given one of signals523through527, the signal is set to a logic low state if the corresponding filter rule is not currently enacted.

By way of illustration and not limitation, signal523indicates whether the retired demand instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that an attempt to execute the demand instruction in question resulted in a TLB hit. Alternatively or in addition, signal524indicates whether the retired demand instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that an attempt to execute the demand instruction in question resulted in a TLB miss.

In some embodiments, signal525indicates whether the retired demand instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that an attempt to execute the demand instruction in question resulted in a locked object being accessed or otherwise detected. Alternatively or in addition, signal526indicates whether the retired demand instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that an attempt to execute the demand instruction in question resulted in the accessing of an object which is split across multiple lines of a cache. In various embodiments, signal527indicates whether the retired demand instruction which is currently under consideration satisfies a currently-enacted count filtering rule (if any) that any retired demand instruction is to be included in the counting.

In the example embodiment shown, a logic gate530of processor circuitry500is operable to generate, based on signals513-517, a signal531which indicates whether any currently-enacted filter rule has been satisfied by a prefetch instruction (if any) which is under consideration. Based on the signals510-512, and on signal531, a logic gate540of processor circuitry500generates a signal541to indicate whether a retired prefetch instruction (where applicable) qualifies to be included in a retirement count. Alternatively or in addition, a logic gate532of processor circuitry500is operable to generate, based on signals523-527, a signal533which indicates whether any currently-enacted filter rule has been satisfied by a demand instruction (if any) which is under consideration. Based on the signals520,512,533—and on an inverted version of signal511(provided by inverter gate534)—a logic gate542of processor circuitry500generates a signal543to indicate whether a retired demand instruction (where applicable) qualifies to be included in a retirement count. In one such embodiment, a logic gate550generates a signal552, based on signals541,543, to conditionally increment or otherwise update a count of instruction retirements.

FIG.6is an illustration of an example mode register600to facilitate the configuring of an instruction retirement counting functionality, according to embodiments of the present disclosure. In an embodiment, mode register600is accessed to determine retirement counting by one of processors125,302,402, and/or with processor circuitry500—e.g., wherein operations of one of methods200,250include or are otherwise based on such access.

As shown inFIG.6, mode register600comprises fields to variously facilitate the selective configuration of one or more counters (in this example, up to two counters) which are each to maintain a respective count of instruction retirements. In the example embodiment shown, mode register600comprises first fields602,604,606,608which correspond to a first counter, and further comprises second fields612,614,616,618which correspond to a second counter. However, in various embodiments, mode register600alternatively supports the configuration of more, fewer, or different counters—e.g., wherein the particular number, sizes and types of the fields in mode register600are different.

By way of illustration and not limitation, field602provides a bitmap, or other suitable information, to specify or otherwise indicate which one or more filter rules (if any) are to be enacted to determine whether a given retirement event is to be selectively included in (or excluded from) a first count by the first counter. For example, such a bit map comprises bits each corresponding to a different respective type of event which—according to a corresponding filter rule—is required to take place if the retirement event in question is to be included in the first count. For each such bit of the bitmap, a value of the bit identifies whether the filter rule which requires the corresponding type of event is currently enacted.

In one such embodiment, a bitmap in field602encodes information according to a scheme such as that represented in the legend601shown. In an illustrative scenario according to one embodiment, bit0of field602indicates whether the retirement of an instruction which results in a TLB hit is to be included in the first count—e.g., wherein bit1of field602indicates whether the retirement of an instruction which results in a TLB miss is to be included in the first count. Furthermore, bit2of field602indicates whether the retirement of an instruction which results in the accessing (or other detection) of a locked object is to be included in the first count—e.g., wherein bit3of field602indicates whether the retirement of an instruction which results in the accessing of an object which is split across cache lines is to be included in the first count. Further still, bit4of field602indicates whether the retirement of any instruction (e.g., of a type determined by field604) is to be included in the first count.

Field604indicates a particular one or more instruction types which are to be subject to evaluation based on the filter rules (if any) which are enacted based on field602. By way of illustration and not limitation, field604includes encoded information to indicate whether only prefetch instruction retirements, or only demand instruction retirements, or both prefetch instruction retirements and demand instruction retirements, are candidates to potentially be included in the first count.

Field606indicates a first threshold count value which, if reached by the first count, is to cause the first count (and/or other suitable performance monitoring information) to be provided by the processor as an output to a programmer, system administrator, operating system, software monitoring tool or other suitable agent. Field608indicates a software privilege level, thread type or other information which, in some embodiments, further limits or otherwise qualifies which instruction retirements are candidates to potentially be included in the first count.

In one such embodiment, field612provides any of various types of information which are suitable to specify or otherwise indicate which one or more filter rules (if any) are to be enacted to determine whether a given retirement event is to be selectively included in (or excluded from) a second count by the second counter. For example, a bitmap in field612encodes information—e.g., according to a scheme similar to that represented in legend601—to indicate a particular combination of filter rules (if any) which are to be applied in determining whether a given instruction retirement is to be counted with the second count.

Field614indicates a particular one or more instruction types which are to be subject to evaluation based on the filter rules (if any) which are enacted based on field612. By way of illustration and not limitation, field614includes encoded information to indicate whether only prefetch instruction retirements, or only demand instruction retirements, or both prefetch instruction retirements and demand instruction retirements, are candidates to potentially be included in the second count.

Field616indicates a second threshold count value which, if reached by the second count, is to cause the second count (and/or other suitable performance monitoring information) to be provided as an output from the processor. Field618provides functionality (similar to that of field608) which—based on a software privilege level, thread type or the like—further limits or otherwise qualifies which instruction retirements are candidates to potentially be included in the second count.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exemplary Register Architecture

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

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

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

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

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

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

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

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

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

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

Instruction Set Architectures

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bit position1(×) may modify the SIB byte index field1354.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In one or more first embodiments, a processor comprises performance monitor circuitry to monitor an execution of instructions by the processor, wherein the performance monitor circuitry is to detect a first retirement of a first instruction, and to detect a second retirement of a second instruction, counter circuitry coupled to the performance monitor circuitry, wherein the counter circuitry is to make a first determination that the first instruction is of a prefetch type, based on the first determination, update a first count of one or more retirements each of a respective instruction which is of the prefetch type, make a second determination that the second instruction is of an instruction type other than the prefetch type, and generate a signal to prevent an update of the first count based on the second determination.

In one or more second embodiments, further to the first embodiment, based on the second determination, the counter circuitry is further to update a second count of one or more other retirements.

In one or more third embodiments, further to the second embodiment, the one or more other retirements are each of a respective instruction type other than the prefetch instruction type.

In one or more fourth embodiments, further to the first embodiment or the second embodiment, the counter circuitry is to update the first count further based on a filter rule.

In one or more fifth embodiments, further to the fourth embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in a hit of a translation look-aside buffer.

In one or more sixth embodiments, further to the fourth embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in a miss of a translation look-aside buffer.

In one or more seventh embodiments, further to the fourth embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in a detection of a locked object.

In one or more eighth embodiments, further to the fourth embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in an access to an object which is split across multiple cache lines.

In one or more ninth embodiments, further to the first embodiment or the second embodiment, an instruction sequence comprises the first instruction and the second instruction, and wherein the counter circuitry to update the first count further based on a privilege level which is assigned to the instruction sequence.

In one or more tenth embodiments, a method at a processor comprises monitoring an execution of instructions by a processor, detecting a first retirement of a first instruction, making a first determination that the first instruction is of a prefetch type, based on the first determination, updating a first count of one or more retirements each of a respective instruction which is of the prefetch type, detecting a second retirement of a second instruction, making a second determination that the second instruction is of an instruction type other than the prefetch type, and generating a signal to prevent an update of the first count based on the second determination.

In one or more eleventh embodiments, further to the tenth embodiment, the method further comprises, based on the second determination, updating a second count of one or more other retirements.

In one or more twelfth embodiments, further to the eleventh embodiment, the one or more other retirements are each of a respective instruction type other than the prefetch instruction type.

In one or more thirteenth embodiments, further to the tenth embodiment or the eleventh embodiment, updating the first count is further based on a filter rule.

In one or more fourteenth embodiments, further to the thirteenth embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in a hit of a translation look-aside buffer.

In one or more fifteenth embodiments, further to the thirteenth embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in a miss of a translation look-aside buffer.

In one or more sixteenth embodiments, further to the thirteenth embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in a detection of a locked object.

In one or more seventeenth embodiments, further to the thirteenth embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in an access to an object which is split across multiple cache lines.

In one or more eighteenth embodiments, further to the tenth embodiment or the eleventh embodiment, an instruction sequence comprises the first instruction and the second instruction, and wherein updating the first count is further based on a privilege level which is assigned to the instruction sequence.

In one or more nineteenth embodiments, a system comprises a memory to store multiple instructions which are to be executed in a sequence, and a processor coupled to the memory, the processor comprising performance monitor circuitry to monitor an execution of the multiple instructions by the processor, wherein the performance monitor circuitry is to detect a first retirement of a first instruction, and to detect a second retirement of a second instruction, counter circuitry coupled to the performance monitor circuitry, wherein the counter circuitry is to make a first determination that the first instruction is of a prefetch type, based on the first determination, update a first count of one or more retirements each of a respective instruction which is of the prefetch type, make a second determination that the second instruction is of an instruction type other than the prefetch type, and generate a signal to prevent an update of the first count based on the second determination. The system further comprises a network interface coupled to the processor, the network interface to receive and transmit data over a network.

In one or more twentieth embodiments, further to the nineteenth embodiment, based on the second determination, the counter circuitry is further to update a second count of one or more other retirements.

In one or more twenty-first embodiments, further to the twentieth embodiment, the one or more other retirements are each of a respective instruction type other than the prefetch instruction type.

In one or more twenty-second embodiments, further to the nineteenth embodiment or the twentieth embodiment, the counter circuitry is to update the first count further based on a filter rule.

In one or more twenty-third embodiments, further to the twenty-second embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in a hit of a translation look-aside buffer.

In one or more twenty-fourth embodiments, further to the twenty-second embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in a miss of a translation look-aside buffer.

In one or more twenty-fifth embodiments, further to the twenty-second embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in a detection of a locked object.

In one or more twenty-sixth embodiments, further to the twenty-second embodiment, according to the filter rule, the first retirement is to be counted where it is determined that an attempt to execute the first instruction resulted in an access to an object which is split across multiple cache lines.

In one or more twenty-seventh embodiments, further to the nineteenth embodiment or the twentieth embodiment, an instruction sequence comprises the first instruction and the second instruction, and wherein the counter circuitry to update the first count further based on a privilege level which is assigned to the instruction sequence.

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