PROCESSOR PERFORMANCE PROFILING USING TRACE ACTIONS

In a general aspect, a processor can include an instruction processing unit configured to execute a software program that includes a plurality of machine-readable instructions, and a hardware performance monitoring unit. The hardware performance monitoring unit can include a plurality of counters configured to count respective processing events associated with execution of the software program, and a counter overflow monitor configured to generate an indication of a respective counter-overflow trace action in response to overflow of a counter of the plurality of counters. The processor can also include a trace encoder configured to receive the indication of the respective counter-overflow trace action from the hardware performance monitoring unit, and, in response to the indication of the respective counter-overflow trace action, perform the respective counter-overflow trace action.

TECHNICAL FIELD

This description relates to computer processing apparatuses, such as microprocessors, processors, central processing units, and the like. More specifically, this disclosure relates to computer processing apparatuses, and associated systems and methods for profiling performance of a processor using trace actions.

BACKGROUND

Analyzing performance and operation of processors and related systems, including execution of programs (e.g., software) on such processors and systems, is often carried out to understand, improve, and/or debug that performance and operation. For instance, processors, such as RISC-V® processors, x86 processors, ARM® processors, Power® processors, etc., can include circuitry (e.g., performance monitoring circuitry or hardware) that is used to collect information related to hardware performance when executing a software program. In a number of conventional approaches, collection of such performance information is accomplished using counters included in the performance monitoring hardware to statistically sample software execution. In such approaches, the performance monitoring hardware triggers an interrupt when a counter, counting occurrences of a respective type of processing event, overflows. An interrupt handler of the processor can then collect context information corresponding with execution of a software program. Such approaches, however, have a number of drawbacks. For instance, interrupt handling can adversely affect execution performance of the software program for which profiling information is being collected. Further, interrupts can be masked by software, which can interfere with, or prevent, collection of performance information, resulting in so-called profiling blind spots.

One approach that has been implemented to address the issue of profiling blind spots is to map performance counter overflow interrupts to non-maskable interrupts (NMIs). However, such approaches also have drawbacks. For instance, NMIs can be used to indicate a large number of different types of processing events. Accordingly, associated interrupt handling can be complex and operate slowly, e.g., relative to interrupt handling of maskable interrupts, which can further add to the performance impact associated with the use of interrupts for collecting performance monitoring information. Additionally, in some processor architectures. NMIs may only be handled in specific modes of operation, which can present complications, such as dependency on firmware, or privileged software to support sample collection.

Another approach that has been implemented for collecting profiling information is the use of hardware sampling mechanisms. In such approaches, a processor can include memory and/or registers that buffer (store) processor state information or other execution state information in response to performance counter overflows. In this approach, rather than an interrupt being issued each time a performance counter overflows, an interrupt can be issued when storage capacity for such state information is full, or nearly full, and the collected state information can then be written out to another, e.g., larger, memory storage area. While hardware sampling can address some of the drawbacks of interrupt based sampling, such approaches can require a substantial amount of circuitry, and can be complicated to implement, which can make them expensive from both design and product cost standpoints (e.g., due to their complexity and associated increased semiconductor die size). Further, hardware sampling can still have adverse impacts on execution performance of an associated software program. For instance, in some implementations, profiling information is stored to memory using shared memory bandwidth, which can adversely affect execution performance. Further, in some implementations, software execution is paused when collecting and/or storing profiling information.

SUMMARY

In a general aspect, the techniques described herein relate to a processor including an instruction processing unit configured to execute a software program that includes a plurality of machine-readable instructions, and a hardware performance monitoring unit. The hardware performance monitoring unit includes a plurality of counters configured to count respective processing events associated with execution of the software program, and a counter overflow monitor configured to generate an indication of a respective counter-overflow trace action in response to overflow of a counter of the plurality of counters. The processor also includes a trace encoder configured to receive the indication of the respective counter-overflow trace action from the hardware performance monitoring unit, and, in response to the indication of the respective counter-overflow trace action, perform the respective counter-overflow trace action.

Implementations can include one or more of the following features, or any combination thereof. For example, the respective counter-overflow trace action can include encoding a trace packet that includes an address of a machine-readable instruction of the plurality of machine-readable instructions. The address can correspond with the overflow of the counter of the plurality of counters.

The indication of the respective counter-overflow trace action can include an identifier of the counter of the plurality of counters. The trace packet can further include the identifier of the counter of the plurality of counters.

The respective counter-overflow trace action can include one of enabling the trace encoder, or disabling the trace encoder.

The processor can include a trigger block configured to administer a plurality of trigger conditions, and receive, from the instruction processing unit, address and data values associated with execution of the software program. The trigger block can be configured to compare the received address and data values with the plurality of trigger conditions. In response to a match between a given value of the received address and data values and a trigger condition of the plurality of trigger conditions, the trigger block can indicate a respective trigger trace action. The trace encoder can be configured to receive the indication of the respective trigger trace action, and, in response to the indication of the respective trigger trace action, perform the respective trigger trace action.

The respective trigger trace action can include encoding a trace packet including an address of a machine-readable instruction of the plurality of machine-readable instructions corresponding with the matched trigger condition.

The indication of the respective trigger trace action can include an identifier of the trigger condition of the plurality of trigger conditions. The trace packet can include the identifier of the trigger condition of the plurality of trigger conditions.

The respective counter-overflow trace action can be one of a trace enable action, a trace disable action, or a trace notify action. The respective trigger trace action can be one of the trace enable action, the trace disable action, or the trace notify action. The processor can include logic configured to combine indications of the trace enable action from the hardware performance monitoring unit with indications of the trace enable action from the trigger block, combine indications of the trace disable action from the hardware performance monitoring unit with indications of the trace disable action from the trigger block, and combine indications of the trace notify action from the hardware performance monitoring unit with indications of the trace notify action from the trigger block.

The received address and data values, e.g., received by the trigger block, can include at least one of an instruction address, a memory address, an instruction opcode, a data value stored by the processor, or a data value read by the processor.

The hardware performance monitoring unit can include a plurality of initialization registers respectively coupled with the plurality of counters. The plurality of initialization registers can be configured to load respective initialization values in the plurality of counters.

A counter of the plurality of counters can include a count value field, and an initialization value field. The counter can be configured to load an initialization value from the initialization value field into the count value field, e.g., upon counter overflow or other conditions.

In another general aspect, the techniques described herein relate to a processor including an instruction processing unit configured to execute a software program including a plurality of machine-readable instructions, a hardware performance monitoring unit configured to provide first trace action indication signals in response to overflow of counters configured to count processing events occurring during execution of the software program, a trigger block configured to provide second trace action indication signals in response to matching of trigger conditions during execution of the software program, combinational logic configured to respectively combine the first trace action indication signals with the second trace action indication signals to produce combined trace action indication signals, and a trace encoder. The trace encoder is configured to receive the combined trace action indication signals, and, in response to the combined trace action indication signals, perform respective trace actions.

Implementations can include one or more of the following features, or any combination thereof. For example, the respective trace actions can include enabling the trace encoder, encoding a trace packet including an address of a machine-readable instruction of the plurality of machine-readable instructions, and disabling the trace encoder.

The address of the machine-readable instruction of the plurality of machine-readable instructions can correspond with one of a counter overflow, or a matched trigger condition. The trace packet can include one of an indication of a counter that overflowed, or the matched trigger condition.

The trigger conditions can be based on address and data values associated with execution of the software program.

In another general aspect, the techniques described herein relate to a method of operating a processor. The method includes executing, by an instruction processing unit, a software program that includes a plurality of machine-readable instructions. The method also includes counting, by a hardware performance monitoring unit having a plurality of counters, respective processing events associated with execution of the software program, and indicating, by the hardware performance monitoring unit in response to overflow of a counter of the plurality of counters, a respective counter-overflow trace action. The method further includes receiving, by a trace encoder, the indication of the respective counter-overflow trace action from the hardware performance monitoring unit, and performing, by the trace encoder in response to the indication of the respective counter-overflow trace action, the respective counter-overflow trace action.

Implementations can include one or more of the following features, or any combination thereof. For example, the respective counter-overflow trace action can include encoding a trace packet including an address of a machine-readable instruction of the plurality of machine-readable instructions corresponding with the overflow of the counter of the plurality of counters.

The method can include administering, by a trigger block, a plurality of trigger conditions; receiving, by the trigger block from the instruction processing unit, address and data values associated with execution of the software program; comparing, by the trigger block, the received address and data values with the plurality of trigger conditions; indicating, by the trigger block in response to a match between a given value of the received address and data values and a trigger condition of the plurality of trigger conditions, a respective trigger trace action; receiving, by the trace encoder, the indication of the respective trigger trace action; and performing, by the trace encoder in response to the indication of the respective trigger trace action, the respective trigger trace action.

The respective trigger trace action can include encoding a trace packet including an address of a machine-readable instruction of the plurality of machine-readable instructions corresponding with the matched trigger condition.

Like reference symbols in the various drawings indicate like and/or similar elements.

DETAILED DESCRIPTION

This disclosure relates to computer processing apparatuses, such as processors, microprocessors, central processing units, graphics processing units, tensor processing units, and accelerators, etc. (hereafter “processor(s)”), and related systems and methods, that can overcome at least some of the drawbacks of prior approaches for obtaining profiling information by statistically sampling execution of a software program using trace encoder actions (trace actions). For instance, in implementations described herein, a processor includes a hardware performance monitoring unit (HPMU) that includes one or more counters configured to count respective processing events that occur during execution of a software program. In response to overflow of the counters, the HPMU provides indications of respective trace actions to a trace encoder. These trace actions, which can be referred to herein as counter-overflow trace actions, can be one of a trace enable action, a trace notify action, or a trace disable action. In some implementations, the HPMU can provide an indication of a respective trace action in response to a counter reaching a threshold value, rather than in response to counter overflow. In response to receiving an indication of a trace notify action, the trace encoder can be configured to generate a trace packet corresponding with the counter that overflowed, or reached a threshold value, where generated trace packets provide statistically sampled profiling information of execution of the software program.

Such approaches for statistically sampling software execution are accomplished without issuing interrupts in response to a counter of the HPMU overflowing or reaching a threshold value, or issuing interrupts in response to trigger conditions being matched. As generation of trace packets for statistical sampling can be done without interrupting, or stalling execution of a software program, as with interrupt-based sampling or hardware-based sampling, adverse impact of software execution can be reduced. As a result, sampling rates can be increased without resulting in a substantial impact to software execution performance, and/or sampling of every occurrence of rare processing events can be performed. In some implementations, there can be some processing overhead associated with copying trace packets from an internal, e.g., circular, storage buffer to external memory, or system memory, but that impact, for typical sampling rates, can be negligible as compared to prior approaches. Also, the approaches described herein support statistical sampling when interrupts are masked, which can avoid the occurrence of profiling blind spots.

FIG.1is a block diagram illustrating an example processor100that can perform statistical sampling of software execution using trace actions. As shown inFIG.1, the processor100includes an instruction processing unit105, memory110, a HPMU115(hardware performance monitor), and a trace encoder125. In the example ofFIG.1, the instruction processing unit105can communicate with the memory110via an interface106. The memory110can include instruction memory, e.g., instruction cache, and data memory, e.g., data cache. In some implementations, the memory110can include other types of memory, such as read-only memory (ROM). The memory110can also include an interface to external memory, such as system memory (not shown inFIG.1), or such a memory interface can be separately implemented. During execution of a software program including a plurality of machine-readable instructions, the instruction processing unit105can access the memory110, via the interface106, to fetch instructions of the software program for execution, read (load) data values related to execution from data memory, and write (store) data values related to execution to data memory.

As shown inFIG.1, the instruction processing unit105can communicate with the HPMU115via an interface107and can communicate with the trigger block120via an interface108. For instance, the instruction processing unit105can indicate occurrence of processing events during execution of the software program to the HPMU115via the interface107. Further, the instruction processing unit105can provide, to the trigger block120via the interface108, execution information, such as addresses of instructions accessed in the memory110, opcodes of accessed instructions, memory addresses accessed in the memory110, and/or data values read from, or written to the memory110.

In this example, the HPMU115can include a plurality of counters that are configured to count respective processing events associated with execution of the software program, such as processing events indicated by the instruction processing unit105. Examples of such processing events are shown inFIG.4. The HPMU115can also include a counter overflow monitor (action processing block) that is configured to generate an indication of a respective counter-overflow trace action in response to overflow of a counter of the plurality of counters. As an example, a counter included in the HPMU115can be configured to count taken branches when executing a software program. The counter can be initialized such that it overflows after a desired number of branch-taken processing events occur. This overflow can be indicated to the counter overflow monitor, and the counter overflow monitor can then indicate a respective counter-overflow trace action to the trace encoder125via an interface122.

In the processor100, the trace encoder125can be configured to receive the indication of the respective counter-overflow trace action from the hardware performance monitoring unit. In response to the received indication of the respective counter-overflow trace action, the trace encoder125can then perform the respective counter-overflow trace action. The trace actions can be one of a trace start action, a trace notify action, and a trace stop action. The trace start action can enable the trace encoder125to generate trace packets. The trace stop action can disable the trace encoder125, where the trace encoder125does not generate trace packets even though counter overflows may continue to occur.

The trace notify action can include the trace encoder125producing a trace packet that includes an instruction address (e.g., a program counter value, instruction pointer value, etc.) of an instruction associated with the counter overflow that resulted in the counter-overflow trace action indication. That instruction address can be a specific address of an instruction that resulted in the counter overflow, or can be an address of an instruction that executes in an execution cycle in which overflow of the counter occurs (e.g., that identifies a relevant section of code of the software program). In this example, the instruction address can be provided to the trace encoder125by the instruction processing unit105via an interface109. The interface109can also be used to provide other execution context to the trace encoder125for inclusion in trace packets, such as execution times, register values, call-stack data, branch history, timestamp (in units of processor clock cycles, instructions retired, wall-clock time, etc.), or other information related to execution of a software program. In some implementations, instruction addresses and other execution context can be provided to the trace encoder125in other ways. For instance, such information can be included with indications of counter-overflow trace actions, e.g., provided to the HPMU115by the instruction processing unit105, rather than via the interface109.

The trace packet produced by the trace encoder125can be communicated via an interface127to a memory buffer, e.g., a trace buffer, such as an internal memory buffer of the processor100(not shown inFIG.1). In some implementations, the trace buffer can be a circular buffer that wraps and overwrites when full. In example implementations, trace packets stored in such a trace buffer can be written out to external memory periodically, written out in response to a flush command, or written out as part of an interrupt routine, as some examples.

The trigger block120of the processor100can administer a number of triggers that can be used, in cooperation with the HPMU115, to statistically sample software execution. The trigger block120can compare execution information received from the instruction processing unit105via the interface108and, if an item of execution information, e.g., an address, opcode or data value, is matched to a trigger condition, the trigger block120can indicate a respective trigger trace action assigned to that trigger condition. The available trace trigger actions can include the trace start action, the trace notify action, and the trace stop action, and are referred to as trace trigger actions to distinguish them from the indications of corresponding counter-overflow trace actions. The trigger trace actions can be performed by the trace encoder125in similar manners as the respective counter-overflow trace actions described above. In some implementations, other actions can be taken in response to a matched trigger condition, such as recording (saving, storing, etc.) last branch records or other information regarding execution state. The particular respective actions taken in response to trigger conditions being matched will depend on the specific implementation.

In the processor100, the trace encoder125can be configured to receive the indication of the respective trigger trace action from the trigger block120. In response to the received indication of the respective trigger trace action, the trace encoder125can then perform the respective trigger trace action. In some implementations, such as the example ofFIG.2, combinational logic can be used to combine indications of counter-overflow trace actions with their corresponding indications of trigger trace actions. That is, such combinational logic can produce combined trace action indications that are provided to the trace encoder125, rather than providing separate indications from the HPMU115and the trigger block120. For instance, indications of trace start actions can be combined, indications of trace notify actions can be combined, and indications of trace stop actions can be combined. Such combinational logic can be included in the interface122.

FIG.2is a block diagram illustrating an example of a sampling circuit200that includes a HPMU215, a trigger block220and a trace encoder225. In some implementations, the sampling circuit200can be implemented in the processor ofFIG.1. As shown inFIG.2, events207(processing events) can be provided to the HPMU215from an instruction processing unit, such as the instruction processing unit105. Also, execution information208, e.g., addresses and data values, can be provided to the trigger block220by the instruction processing unit.

As shown inFIG.2, the HPMU215includes counters218that are configured to respectively count processing events of the events207. In the example ofFIG.2, the counters218are designated as Counter 0 to Counter i, where i is greater than or equal to 1. That is, if a processor includes 29 counters, i would be 28. The number of counters218will depend on the particular implementation.

In the HPMU215, the counters218can provide respective overflow indications216(e.g., Ovf 0 to Ovf i) to an action processing block219, where the action processing block219acts as a counter overflow monitor. In this example, the action processing block219can be configured to receive the respective overflow indications216and provide indications222aof corresponding counter-overflow trace actions, e.g., trace start, trace notify, or trace stop. That is, each of the respective overflow indications216can have a specific trace action assigned, and the action processing block219can then provide the appropriate indication of the indications222abased on those assignments. In some implementations, the relationships between counter overflows and respective trace actions can be included in a look-up table, an indexed list, or any other appropriate data structure.

As shown inFIG.2, the action processing block219can also provide counter information to the trace encoder225via an interface219a. For instance, for a given indication of a counter-overflow trace action, the action processing block219can provide an indication of the counter that overflowed to result in the given indication to the trace encoder225. In some implementations, if the counter-overflow trace action is a trace notify action, the trace encoder225can be configured to include the respective counter information in a corresponding trace packet, along with an instruction address corresponding with the counter overflow, where the instruction address can be provided to the trace encoder225using the approaches described herein.

In addition to providing the indications222a, the action processing block219can also be configured to provide a local counter overflow interrupt signal (a LCOFI signal219b) in response to overflow of one or more of the counters218. That is, overflow of one or more of the counters218can be associated with generation of an interrupt, rather than indicating a trace action via the indications222a. Actions taken in response to the LCOFI signal219bwill depend on the particular implementation.

As shown inFIG.2, the trigger block220includes comparators221that are configured to administer a plurality of trigger conditions. In the example ofFIG.2, the comparators221can compare execution information208provided by an instruction processing unit to the trigger conditions. Match indications217can be provided in response to the comparators221respectively matching an item of execution information to one of the plurality of trigger conditions. For instance, the trigger block220can administer 0 to n trigger conditions, where n is greater than or equal to 1, and the comparators221can respectively generate the match indications217. That is, if n is 29, there would be 30 trigger conditions administered by the trigger block220. The number of trigger conditions will depend on the particular implementation.

In the trigger block220, the comparators221can provide match indications217(e.g., match 0 to match n) to an action processing block224. In this example, the action processing block224can be configured to receive the match indications217and provide indications222bof corresponding trigger trace actions, e.g., trace start, trace notify, or trace stop. That is, each of the match indications217can have a specific trace action assigned, and the action processing block224can then provide the appropriate indication of the indications222bbased on those assignments. In some implementations, the relationships between trigger condition matches and respective trigger trace actions can be included in a look-up table, an indexed list, or any other appropriate data structure.

As shown inFIG.2, the action processing block224can also provide trigger information to the trace encoder225via an interface224a. For example, for a given indication of a trigger condition match, the action processing block224can provide an indication of the trigger condition that was matched to result in the given indication to the trace encoder225. In some implementations, if the trigger trace action is a trace notify action, the trace encoder225can be configured to include the associated trigger information in a corresponding trace packet, along with an instruction address corresponding with the counter overflow, where the instruction address can be provided to the trace encoder225using the approaches described herein.

In addition to providing the indications222b, the action processing block224can also be configured to provide a breakpoint signal224bor a debug signal224cin response to the comparators221indicating a trigger condition match. That is, matching of one or more of the trigger conditions can be associated with generation of the breakpoint signal224b, or generation of the debug signal224c, rather than indicating a trace action via the indications222a. Actions taken in response to the breakpoint signal224bor the debug signal224cwill depend on the particular implementation.

In the sampling circuit200, the indications222aand the indications222bcan be respectively combined by combinational, e.g., OR logic or an OR logic gate. That is the trace start action indications from the HPMU215can be combined with trace start action indications from the trigger block220using OR logic223a, trace stop action indications from the HPMU215can be combined with trace stop action indications from the trigger block220using OR logic223b, and trace notify action indications from the HPMU215can be combined with trace start notify indications from the trigger block220using OR logic223c.

In an example implementation, the sampling circuit200can be used to statistically sample software execution for a particular section of code of a software program as follows. In this example, a first trigger condition for a starting instruction address of the section of the code and a second trigger condition for an ending address of the section of the code can be administered by the trigger block220. In this example, the first trigger condition can be associated with a trace start action, to start tracing at the beginning of the section of code. Also, in this example, the second trace condition can be associated with a trace stop action, to stop tracing after the section of code is executed, or exited. That is, the starting and ending addresses can define an instruction address range during which tracing is performed.

When executing the section of code, a counter of the counters218in the HPMU215can be configured to count processing events of interest and, on overflow of the counter, indicate a trace notify action to cause the trace encoder225to encode a trace packet. Depending on the particular implementation, the counter can be configured to overflow on every occurrence of a specific processing event, or configured to overflow after occurrence of a specific number of occurrences of the specific processing event. The number of event occurrences that will result in overflow of the counter can be established based on an initialization value of the counter. For instance, if overflow is desired for every occurrence of a processing event being counted, the counter can be initialized with a value that is one count away from (one less than) its overflow value. If overflow is desired after occurrence of a specific number of occurrences of a processing event, the counter can be initialized with a value that is less than its overflow value by that specific number.

In another example, the sampling circuit200can be used to statistically sample events during execution of software without the use of trigger conditions administered by the trigger block220. For instance, multiple counters of the counters218can be configured to count occurrences of a specific processing event. Each of the counters can be initialized with different values, such that they overflow at different counts. For example, if branch mispredictions are being sampled, a first counter can be configured to overflow at first value, e.g., to overflow after 1000 branch misprediction. Overflow of the first counter could then result in a trace start action, to enable the trace encoder225to generate trace packets. A second counter could be configured to overflow every 10 branch mispredictions, and result in a trace notify action and generation of a trace packet. A third counter could be configured to overflow after 1500 branch mispredictions have occurred, and result in a trace stop action. Accordingly, in this example, 50 branch mispredictions would be sampled, and 50 corresponding trace packets would be produced by the trace encoder225.

FIGS.3A and3Bare block diagrams illustrating example approaches for initializing processing event counters, such as the counters218ofFIG.2. In the example ofFIG.3A, a counter318can be configured to count occurrences of a specific processing event (events307). The counter318can be initialized with a counter initialization register330. In this example, overflow of the counter318indicated on signal line335can cause the counter initialization register330to load the initialization value into the counter318. In some implementations, loading of the counter initialization value from the counter initialization register330can be accomplished in other ways, such as in response to overflow of other counters included in a HPMU. In some implementations, the counter318and the counter initialization register330can be implemented using control/status registers (also referred to as CSRs).

In the example ofFIG.3B, a register368, e.g., a control/status register, can be used to implement both a count value368a(counter value) and an initialization value380, e.g., as fields of the register368. The count value368acan be initialized with the initialization value380. In this example, overflow of the count value368aindicated on signal line385can cause the initialization value380to be loaded into the register field containing the count value368a. In some implementations, initializing the count value368awith the initialization value380from the can be accomplished in other ways, such as in response to overflow of other counters (or count values of other registers) included in a HPMU.

FIG.4is a table400including example execution events that can be monitored (counted) by a hardware performance monitoring unit in a processor, such as in the examples ofFIGS.1and2. The processing events shown in the table400are given by way of example, and the events that are counted will depend on the specific implementation. For instance, in some implementations, multiple counters that are initialized with different values can count occurrences of the same processing event (e.g., branch), and their respective overflow can initiate different trace actions. Further, in the table400, number designations of counters for counting different processing events are shown by way of example. In some implementations, the order of counters and/or the order of associated processing events counted by a specific counter can be different. In some implementations, event counters can be configured (e.g., by an associated software program) to count occurrences of a specific processing event.

The example processing events listed in table400, which can be implemented, e.g., in a given processor architecture, include branch mispredictions (counter 0), exceptions (counter 1), interrupts (counter 2), control/status register (CSR) operations (counter 3), jumps (counter 4), branches (counter 5), multiply and divide operations (counter 6), read-after-write (RAW) stalls (counter 7), execution unit (instruction processing unit) stalls (counter 8), instruction cache accesses (counter 9), instruction cache misses (counter 10), instruction cache fill-buffer hits (counter 11), instruction cache non-cacheable accesses (counter 12), instruction cache fill-buffer releases (counter 13), data cache read accesses (counter 14), data cache write accesses (counter 15), data cache atomic accesses (counter 16), data cache non-cached read accesses (counter 17), data cache non-cached write accesses (counter 18), data cache read misses (counter 19), data cache write misses (counter 20), data cache atomic misses (counter 21), data cache read fill-buffer hits (counter 22), data cache write fill-buffer hits (counter 23), data cache atomic fill-buffer hits (counter 24), data cache fill-buffer releases (counter 25), and data cache line evictions (counter 26). In some implementations, additional or fewer event counters can be included in a processor. That is, additional processing events can be counted, and/or counting of one or more processing events can be omitted. For instance, a processor can include a number of programmable counters (e.g., four to eight programmable counters), which can be respectively configured to count specific events.

FIG.5is a flowchart illustrating a method500for operating a processor, such as the processor100ofFIG.1. In some implementations, the method500can be implemented using the techniques described herein. Accordingly, for purposes of illustration, and by way of example, the method500is described with further reference to, at least,FIGS.1,2and4. In some implementations, the method500can be implemented in processors having different architectures than those described herein.

As shown inFIG.5, at block505, the method500includes executing a software program with the instruction processing unit105of the processor100, where the software program can include a plurality of machine-readable instructions. At block510, the method500includes counting respective processing events, e.g., with the counters218of the HPMU215ofFIG.2(or event counters included in the HPMU115. For instance, processing events such as the example processing events shown in table400ofFIG.4can be counted by the counters218.

At block515, the method500includes indicating a counter-overflow action in response to overflow of a counter of the counters218. The counter-overflow action indication will depend on which of the counters218overflows. For instance, for a given counter of the counters218, an associated counter-overflow action can include a trace action and/or an interrupt action (e.g., an LCOFI action). In some instances, overflow of a given counter could result in neither a trace action or an interrupt action occurring. In an example implementation, one or more of the counters218can each be associated with a respective trace action, such as a trace enable (trace start) action, a trace notify (encode trace packet) action, or a trace disable (trace stop) action, one or more of the counters218can be associated with an interrupt action, and/or one or more of the counters can be unassociated with a trace action or an interrupt action.

At block520, the method includes the trace encoder225(or the trace encoder125) performing the indicated trace action, e.g., in response to receiving the indication of the desired action corresponding with the counter overflow. In the method500, if the indicated counter-overflow action is a trace notify action including encoding a trace packet, the trace packet can include an address of an instruction corresponding with overflow of the counter for which the trace action indication was generated. The instruction address can be a specific address of an instruction that resulted in the counter overflow, or can be an address of an instruction that executes in an execution cycle in which overflow of the counter occurs (e.g., identifies a relevant section of code of the software program). In some implementations, a trace packet is encoded in response to a trace notify action, e.g., in response to a counter overflow, can also include an indication of the counter that overflowed to initiate the trace notify action.

FIG.6is a flowchart illustrating a method600for operating a processor, such as the processor100ofFIG.1. In some implementations, the method600can be implemented in conjunction with the method500ofFIG.5. In some implementations, as with the method500, the method600can be implemented using the techniques described herein. Accordingly, for purposes of illustration, and by way of example, the method600is described with further reference to, at least,FIGS.1and2. In some implementations, the method600can be implemented in processors having different architectures than those described, herein.

As shown inFIG.6, at block605, the method600includes administering, by the trigger block220(or the trigger block120), a plurality of trigger conditions (e.g., watchpoints). For instance, the trigger conditions can include trigger conditions that are based on specific instruction addresses, memory addresses, instruction opcode data values (e.g., specific instructions), and/or specific data values, such as data values that the processor100may store in, or read from memory110. At block610, the trigger block120(of the trigger block220) can then receive addresses and data values, which can be referred to as execution information or execution information items, from the instruction processing unit105during execution of the software program. Also at block610, the trigger block220can compare the received execution information items with the plurality of trigger conditions.

At block615, if a specific execution information item received by the trigger block220matches one of the plurality of trigger conditions administered by the trigger block220, the method600includes indicating a respective trigger action. As with indications of counter-overflow actions, the trigger action indication will depend on which trigger condition, or trigger conditions of the plurality of trigger conditions matched. For instance, for a given trigger condition, an associated trigger action can include a trace action, a breakpoint exception, and/or result in entry into a debug mode. That is, one or more trigger conditions of the plurality of trigger conditions can be associated with a respective trace action, such as a trace enable (trace start) action, a trace notify (encode trace packet) action, or a trace disable (trace stop) action. One or more trigger conditions of the plurality of trigger conditions can be associated with a breakpoint exception, and one or more trigger conditions can be associated with entry into a debug mode. Further in some implementations, one or more trigger conditions of the plurality of trigger conditions can be unassociated with a trace action, a breakpoint exception, or entry into a debug mode.

At block620, the method includes the trace encoder225(or the trace encoder125) performing the indicated trigger action, e.g., in response to receiving the indication of the desired trace action corresponding with the matched trigger condition. In the event multiple triggers are matched, a set of priorities can be applied as to which respective trigger action is performed. In the method600, as with the method500, if the indicated trigger trace action is a trace notify action including encoding a trace packet, the trace packet can include an address of an instruction corresponding with, or associated with the trigger condition match for which the trace action indication was generated. The instruction address can be a specific address of an instruction that resulted in the matched trigger condition, or can be an address of an instruction that executes in an execution cycle in which matching of the trigger condition occurs (e.g., identifies a relevant section of code of the software program). In some implementations, a trace packet that is encoded in response to a trace notify action, e.g., in response to a matched trigger condition, can also include an indication of the trigger condition that matched to initiate the trace notify action.

FIG.7illustrates an example architecture of a computing device750that can be used to implement aspects of the present disclosure, including any of the plurality of computing devices described herein, such as a computing device including the processor100, or any other computing devices that may be utilized in the various possible embodiments. The computing device illustrated inFIG.7can be used to execute an operating system, application programs and software modules, such as described herein.

The computing device750includes, in some embodiments, at least one processing device760, such as a central processing unit (CPU). A variety of processing devices are available from a variety of manufacturers, for example, Intel or Advanced Micro Devices. In this example, the computing device750also includes a system memory762, and a system bus764that couples various system components including the system memory762to the processing device760. The system bus764is one of any number of types of bus structures including a memory bus, or memory controller; a peripheral bus; and a local bus using any of a variety of bus architectures.

Examples of computing devices suitable for the computing device750include a desktop computer, a laptop computer, a tablet computer, a mobile computing device (such as a smart phone, an iPod® or iPad® mobile digital device, or other mobile devices), or other devices configured to process digital instructions.

The system memory762includes read only memory766and random access memory768. A basic input/output system770containing the basic routines that act to transfer information within computing device750, such as during start up, is typically stored in the read only memory766.

The computing device750also includes a secondary storage device772in some embodiments, such as a hard disk drive, for storing digital data. The secondary storage device772is connected to the system bus764by a secondary storage interface774. The secondary storage devices772and their associated computer readable media provide nonvolatile storage of computer readable instructions (including application programs and program modules), data structures, and other data for the computing device750.

Although the example environment described herein employs a hard disk drive as a secondary storage device, other types of computer readable storage media are used in other embodiments. Examples of these other types of computer readable storage media include magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, compact disc read only memories, digital versatile disk read only memories, random access memories, or read only memories. Some embodiments include non-transitory computer-readable media. Additionally, such computer readable storage media can include local storage or cloud-based storage.

A number of program modules can be stored in secondary storage device772or system memory762, including an operating system776, one or more application programs778, other program modules780(such as the software engines described herein), and program data782. The computing device750can utilize any suitable operating system, such as Microsoft Windows™, Google Chrome™ OS or Android, Apple OS, Unix, or Linux and variants and any other operating system suitable for a computing device. Other examples can include Microsoft, Google, or Apple operating systems, or any other suitable operating system used in tablet computing devices.

In some embodiments, a user provides inputs to the computing device750through one or more input devices784. Examples of input devices784include a keyboard786, mouse788, microphone790, and touch sensor792(such as a touchpad or touch sensitive display). Other embodiments include other input devices784. The input devices are often connected to the processing device760through an input/output interface794that is coupled to the system bus764. These input devices784can be connected by any number of input/output interfaces, such as a parallel port, serial port, game port, or a universal serial bus. Wireless communication between input devices and the interface794is possible as well, and includes infrared, BLUETOOTH® wireless technology, 802.11a/b/g/n, cellular, ultra-wideband (UWB), ZigBee, or other radio frequency communication systems in some possible embodiments.

In this example embodiment, a display device796, such as a monitor, liquid crystal display device, projector, or touch sensitive display device, is also connected to the system bus764via an interface, such as a video adapter798. In addition to the display device796, the computing device750can include various other peripheral devices (not shown), such as speakers or a printer.

When used in a local area networking environment or a wide area networking environment (such as the Internet), the computing device750is typically connected to the network through a network interface1000, such as an Ethernet interface or WiFi interface. Other possible embodiments use other communication devices. For example, some embodiments of the computing device750include a modem for communicating across the network.

The computing device750typically includes at least some form of computer readable media. Computer readable media includes any available media that can be accessed by the computing device750. By way of example, computer readable media include computer readable storage media and computer readable communication media.

The computing device illustrated inFIG.7is also an example of programmable electronics, which may include one or more such computing devices, and when multiple computing devices are included, such computing devices can be coupled together with a suitable data communication network so as to collectively perform the various functions, methods, or operations disclosed herein.