Data processing device and method of collecting given state information of the device

Abstract

The present disclosure provides a technique for collecting state information of a device. The device has a processing pipeline for executing a sequence of instructions, and an instruction of interest specifying circuit for identifying at least one instruction in the sequence as an instruction of interest. Each instruction of interest is an instruction for which given state information of the device associated with execution of the instruction of interest is to be collected. The instruction of interest specifying circuit is arranged to apply a defined selection criterion to each identified instruction of interest to determine a further instruction in the sequence later than the instruction of interest, and to mark the further instruction as having a synchronisation exception associated therewith. The processing pipeline, in response to the further instruction reaching a given stage of the processing pipeline and being marked as having the synchronisation exception associated therewith, triggers the synchronisation exception without executing the further instruction, causing the processing pipeline to execute a given exception handling routine in order to collect the given state information.

Description

Background Technology

[0001] The present invention relates to a mechanism for collecting status information of a device.

[0002] There are many situations where monitoring program execution is desired. When performing such monitoring, it is often desirable to apply an exception to the regulatory code at a specific point in time so that information related to the program's execution can be extracted. For example, during statistical analysis, the execution of specific instructions may cause the creation of records to capture information related to the execution of those instructions, and may subsequently raise an exception. Typically, this exception is an asynchronous exception, sometimes called an interrupt, which is issued to an interrupt controller that handles multiple interrupt sources in order of priority. In this way, the interrupt controller can then trigger an appropriate exception handling routine to reference the records created by such statistical analysis.

[0003] For example, performance monitoring techniques can be used to track the occurrence of specific events using a series of counters, and at a specific point in time, an asynchronous exception may be triggered on the interrupt controller, allowing exception handling routines to be run to view event information maintained as a result of such performance monitoring.

[0004] In addition to the information described above that can be captured during program execution, it may be desirable to capture other information about the state of the device at the time when the event causing the information captured by those program monitoring techniques occurs. However, when an asynchronous exception has been selected by the interrupt controller to cause the execution of the relevant exception handling routine, program execution will continue during the intervention period. Therefore, the state of the system at the time of execution of the exception handling routine may not accurately reflect the state of the system at an earlier point in time of interest, and thus it may be difficult to correlate such state information of the device with the information obtained from monitoring program execution. Summary of the Invention

[0005] In one exemplary arrangement, an apparatus is provided, comprising: a processing pipeline for executing a sequence of instructions; and an instruction of interest designation circuitry for identifying at least one instruction in the sequence of instructions as an instruction of interest, each instruction of interest being an instruction for which the apparatus will collect given state information associated with the execution of the instruction of interest; wherein: the instruction of interest designation circuitry is configured to apply defined criteria to each identified instruction of interest to determine a further instruction following the instruction of interest in the instruction sequence and to mark the further instruction as having an associated synchronization exception; and the processing pipeline, in response to the further instruction reaching a given stage of the processing pipeline and being marked as having the associated synchronization exception, triggers the synchronization exception instead of executing the further instruction, thereby causing the processing pipeline to execute a given exception handling routine to collect the given state information.

[0006] In another exemplary arrangement, a method for collecting given state information of a device is provided, the method comprising: employing a processing pipeline to execute a sequence of instructions; and identifying at least one instruction in the sequence as an instruction of interest, each instruction of interest being an instruction for which the collection of given state information of the device associated with the execution of the instruction of interest is to be made; for each identified instruction of interest, applying defined criteria to determine a further instruction in the instruction sequence that follows the instruction of interest, and marking the further instruction as having an associated synchronization exception; and in response to the further instruction reaching a given stage of the processing pipeline and being marked as having the associated synchronization exception, triggering the synchronization exception instead of executing the further instruction, thereby causing the processing pipeline to execute a given exception handling routine to collect the given state information.

[0007] In another exemplary arrangement, a computer program is provided for controlling a host data processing apparatus to provide an instruction execution environment. The computer program includes: process logic for executing a sequence of instructions in a series of pipeline stages; and instruction of interest specifying program logic for identifying at least one instruction in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information associated with the execution of the instruction of interest will be collected; wherein: the instruction of interest specifying program logic is configured to apply defined criteria to each identified instruction of interest to determine a further instruction following the instruction of interest in the instruction sequence and to mark the further instruction as having an associated synchronization exception; and the process logic, in response to the further instruction arriving at a given pipeline stage and being marked as having the associated synchronization exception, triggers the synchronization exception instead of executing the further instruction, thereby causing the process logic to execute a given exception handling routine to collect the given state information.

[0008] In another exemplary arrangement, an apparatus is provided, comprising: a processing pipeline apparatus for executing a sequence of instructions; and an instruction of interest designation apparatus for identifying at least one instruction in the sequence of instructions as an instruction of interest, each instruction of interest being an instruction for which the apparatus will collect given state information associated with the execution of the instruction of interest; wherein: the instruction of interest designation apparatus is configured to apply defined criteria to each identified instruction of interest to determine a further instruction following the instruction of interest in the instruction sequence, and to mark the further instruction as having an associated synchronization exception; and the processing pipeline apparatus, in response to the further instruction reaching a given stage of the processing pipeline apparatus and being marked as having the associated synchronization exception, triggers the synchronization exception instead of executing the further instruction, thereby causing the processing pipeline apparatus to execute a given exception handling routine to collect the given state information. Attached Figure Description

[0009] The present technology will be further described by way of illustration only, with reference to examples of the present technology shown in the accompanying drawings, wherein:

[0010] Figure 1 It is a block diagram of an apparatus according to an exemplary specific implementation;

[0011] Figure 2 This is shown in an exemplary arrangement. Figure 1 The flowchart of the operation of the circuit specified by the instruction of interest;

[0012] Figure 3 It is a flowchart illustrating the operation of a processing pipeline in response to further instructions identified by a circuit specified by an instruction of interest, according to an exemplary arrangement;

[0013] Figure 4 This is a flowchart illustrating the use of the stack buffer during program execution;

[0014] Figures 5A to 5C This document illustrates various types of criteria that can be used to determine further instructions based on the techniques described herein;

[0015] Figure 6 This is a flowchart illustrating a statistical analysis technique that can be used in one exemplary specific implementation;

[0016] Figure 7 This is a flowchart illustrating an alternative statistical analysis technique that can be used according to an exemplary specific implementation, wherein a filtering mechanism is employed;

[0017] Figure 8 This is a flowchart illustrating a performance monitoring technique that can be used according to an exemplary specific implementation;

[0018] Figure 9 This is a flowchart illustrating how circuitry specified by an instruction of interest according to an exemplary specific implementation is associated with and used in conjunction with the call stack buffer; and

[0019] Figure 10 A specific implementation of the available simulator is shown. Detailed Implementation

[0020] As discussed earlier, various techniques exist for monitoring program execution, such as statistical analysis that generates records associated with the execution of specific instructions, and performance monitoring that continuously tracks the occurrence of specific events during program execution. In the latter case, those events are typically caused by the execution of specific instructions.

[0021] According to the technology described herein, an apparatus is provided, comprising: a processing pipeline for executing a sequence of instructions; and an instruction of interest designation circuitry for identifying at least one instruction in the sequence of instructions as an instruction of interest, each instruction of interest being an instruction for which the apparatus will collect given state information associated with the execution of the instruction of interest.

[0022] Therefore, according to the techniques described herein, specific instructions are identified as those for which associated state information about the device's state at the time of execution of those instructions is desired. However, as previously mentioned, during monitoring program execution, asynchronous exception mechanisms are typically used, and in particular, circuitry provided within the device for monitoring program execution may raise asynchronous exceptions at specific points in time, which are then handled by the interrupt controller, leading to timely invocation of exception handling routines to handle those asynchronous exceptions. However, if such mechanisms are used after the execution of instructions of interest, a significant slippage has been found between the time of execution of the instructions of interest and the subsequent time of execution of the exception handling routines. Therefore, while such exception handling routines can be arranged to acquire the desired state information of the device, the acquired state information may not accurately represent the state of the device at the time of execution of the instructions of interest, and thus may be of limited use.

[0023] Another type of exception is the synchronization exception. When a synchronization exception is associated with an instruction, the exception is used instead of the instruction being executed when the instruction is encountered, for example, when the instruction reaches a specific stage in the processor pipeline. Synchronization exceptions can be used in various situations, such as to implement an "instruction failure" mechanism. For example, if a load or store instruction is seeking access to a memory region it does not have permission to access, a synchronization exception technique can be used to trigger a failure instead of attempting to execute the load or store instruction.

[0024] However, triggering a synchronization exception instead of executing the instruction of interest would not be useful, because it is necessary to execute the instruction of interest so that the given state information of the device associated with the execution of the instruction of interest can subsequently be captured. It is also necessary to execute the instruction of interest so that the information associated with the execution of that instruction can be captured by the program monitoring circuitry mentioned above (e.g., the statistical analysis or performance monitoring circuitry discussed earlier).

[0025] According to the technique described herein, to alleviate the aforementioned problem associated with the slippage between the time of triggering an asynchronous exception and the time of calling the associated exception handling routine, the aforementioned concept of synchronous exceptions is utilized, but not associated with the instruction of interest itself. Specifically, the instruction of interest designation circuitry is arranged to apply defined criteria to each identified instruction of interest to determine the next instruction following it in the instruction sequence, and is subsequently arranged to mark the next instruction as having an associated synchronous exception. Depending on the criteria used to select the instruction of interest, it is possible that a next instruction has already been extracted by the processing pipeline; however, if not, the instruction of interest designation circuitry can enter a state of monitoring extracted instructions, waiting for an instruction that meets the criteria (e.g., the next instruction of a specific type) to be extracted, at which point that instruction can be identified as a next instruction.

[0026] Then, in response to a further instruction arriving at a given stage of the processing pipeline and being marked as having an associated synchronization exception, the processing pipeline triggers a synchronization exception instead of executing the further instruction. This causes the processing pipeline to execute a given exception handling routine to collect given state information. The stage that triggers the synchronization exception when a further instruction arrives at a given stage of the processing pipeline can be any suitable stage within the processing pipeline. The given stage can be, for example, an execution stage that would execute a further instruction, in which case the synchronization exception is triggered instead of executing that further instruction. However, the given stage can alternatively be a stage earlier than the execution stage, where a synchronization exception is triggered again instead of allowing further instruction execution to continue.

[0027] It should be noted that, in addition to executing a given exception handling routine for collecting given state information, the device may also use other existing mechanisms (such as the statistical analysis mechanisms or performance monitoring mechanisms discussed earlier) to collect additional information. Since the given state information collected by the given exception handling routine when a further instruction arrives at a given stage of the processing pipeline is triggered by a synchronous exception, it is more likely that this given state information may be related to other information, such as information associated with the execution of the instruction of interest. In particular, because the further instruction has been selected by the instruction of interest designation circuitry based on the identified instruction of interest, there is a greater deterministic correlation between the execution time of the instruction of interest and the point in time when the given exception handling routine is executed in response to a synchronous exception triggered by a further instruction, compared to the deterministic correlation that would exist using the asynchronous exception mechanism described earlier.

[0028] However, it should be noted that the above techniques are useful even if no other information is collected by other components in the system. In particular, given state information may actually be the only information collected, but it can still effectively provide information related to the execution of the instruction of interest, due to the way the circuitry specifying the instruction of interest selects further instructions.

[0029] As described above, because a synchronous exception is associated with a further instruction, the processing pipeline triggers a synchronous exception instead of allowing the further instruction to be executed when that further instruction reaches a given stage of the processing pipeline. In one exemplary implementation, the processing pipeline may then be configured to execute the further instruction upon timely return from the given exception handling routine. Therefore, the association between a synchronous exception and a further instruction may actually only delay the execution of that further instruction while the exception handling routine is executed.

[0030] The criteria applied by the instruction of interest designator circuitry to determine the definition of further instructions for each identified instruction of interest can take many forms. In one exemplary implementation, the defined criteria cause the instruction of interest designator circuitry to identify the instruction appearing at a predetermined position in the instruction sequence relative to the instruction of interest as a further instruction. Therefore, the instruction of interest designator circuitry may select only the Nth instruction following the instruction of interest as a further instruction, where N can be chosen according to the specific implementation. For example, how N is chosen may depend on the desired instruction dependency. For instance, if the instruction of interest Y immediately follows instruction X in the instruction sequence, but the processing pipeline allows out-of-order execution, and it is common for instruction Y to actually execute before instruction X, then associating a synchronization exception with instruction Y will force an ordering between instructions X and Y and prevent instruction Y from executing before instruction X. This may potentially lead to a kind of probe action that might be desirable to avoid, and in this case, it may be decided to make N greater than 1. However, in the absence of such instruction dependency issues, it may be determined that setting N to equal 1 is appropriate to minimize the gap between the execution of the instruction of interest and the triggering of a synchronization exception by a further instruction.

[0031] For example, a defined criterion allows the circuitry to identify at least one instruction of a given type appearing in the instruction sequence following the instruction of interest as a further instruction. Various types of instructions can be selected here, but those of particular interest are those that, when executed, may cause a change in the given state information that is expected to be collected. In particular, as discussed earlier, it is desirable that the given state information provides useful information about the state of the device at the time of execution of the instruction of interest, and therefore it is desirable to avoid the execution of any subsequent instructions that might alter the given state information in a manner that determines its form at the time of execution of the instruction of interest.

[0032] As an example of an instruction that might be of interest to specify the particular type of instruction a circuit considers when selecting further instructions, a particular type of load or store instruction might be of interest because it would cause changes to the contents of a register set. Similarly, an executing program might consist of multiple distinct subroutines. Some types of instructions will cause transitions between those subroutines, which in turn will cause changes to the contents of specific state information maintained by the device to continuously track those subroutines. For example, a call stack buffer might maintain information for handling transitions between subroutines, where whenever a transition to a new subroutine is about to occur, an entry is added to the top of the buffer to capture the information used when returning appropriately from that subroutine. Similarly, whenever a return from a subroutine occurs, the most recently added entry to the call stack buffer is removed and the information stored therein is consumed.

[0033] The criteria defined by the circuitry specifying the instruction of interest can monitor any number of given types of instructions of interest, such as considering examples of all the instructions mentioned above or only a subset thereof, and can then be arranged to identify one or more monitored types of instructions that appear next in the instruction sequence after the instruction of interest as further instructions. Alternatively, the defined criteria can cause the circuitry specifying the instruction of interest not to designate the next instruction of one of the monitored types as a further instruction, but rather to designate the Nth instruction of one of the monitored types appearing in the instruction sequence as a further instruction.

[0034] In one exemplary embodiment, at least one instruction of a given type may be a return instruction for returning the processing pipeline to execute program code that was executing prior to the execution of the current subroutine. Alternatively or otherwise, at least one instruction of a given type may be a linked branch instruction that, when executed, causes the processing pipeline to stop processing the current subroutine and begin execution of another subroutine.

[0035] The current subroutine mentioned above when discussing return instructions and linked branch instructions can take many forms. However, in one exemplary implementation, the current subroutine can be a subroutine that includes the instruction of interest. Therefore, the above techniques can be used to associate synchronization exceptions with further instructions that occur in the same subroutine as the subroutine containing the instruction of interest. This allows given state information (such as the contents of the call stack buffer mentioned earlier) to be captured by the exception handling routine before the subroutine changes, thus giving the given state information of interest an opportunity to prevent changes in the way that the state information is determined when the instruction of interest is executed.

[0036] As another exemplary method for determining further instructions, the defined criteria could be such that the instruction of interest designation circuitry determines any instruction in the instruction sequence that appears after the instruction of interest, up to but not exceeding the next instruction of at least one given type in the instruction sequence that appears after the instruction of interest. Therefore, when employing such a method, the actual instruction selected as the further instruction is not considered important, as long as it appears after the instruction of interest and up to but not exceeding the specific type of instruction. By way of example only, it might be desirable for a synchronization anomaly to occur before or at least as late as the next linked branch instruction after the instruction of interest is encountered, and the method mentioned above achieves this without otherwise precisely restricting which instruction has an associated synchronization anomaly.

[0037] In one exemplary embodiment, the apparatus further includes statistical analysis circuitry that, in response to the execution of a given instruction of interest, generates a record comprising multiple information items relating to the execution of the given instruction of interest. In such an embodiment, given state information collected by executing a given exception handling routine may include additional information not included in the record generated by the statistical analysis circuitry. Therefore, by using the mechanism described above, information beyond that collected within the record generated by the statistical analysis circuitry can be obtained by executing a given exception handling routine.

[0038] The multiple information items generated in the record by the statistical analysis circuit can take many forms, but in a limited enumeration, the record can identify the instruction address of the instruction of interest, the instruction type (e.g., whether the instruction is a branch instruction, a load instruction, or a store instruction), the execution context (e.g., at which exception level the processing pipeline is operating, thus, for example, whether the processing pipeline is operating in user space, operating system space, or hypervisor space), which software process is running at that exception level (which can also be called a context identifier), the delay of the instruction of interest, etc.

[0039] The additional information that forms the given state information collected by executing a given exception handling routine can take many forms, but in one example, it includes at least one software-defined state item associated with the execution of a given instruction of interest. Such software-defined state will not be naturally captured by statistical analysis circuitry, but it can provide useful additional information when seeking to analyze the records generated for the instruction of interest. For example, the software-defined state can be used to determine which instruction execution path was followed before reaching the instruction of interest.

[0040] Although software-defined states can take many different forms, one such software-defined state entry may include the contents of the aforementioned call stack buffer maintained by the device. By understanding the contents of the call stack buffer, it may be possible to determine the sequence of subroutines that have been executed before the subroutine containing the instruction of interest.

[0041] In one exemplary implementation, the statistical analysis circuitry is further arranged to include an indication of the current call stack buffer pointer value at the time of execution of the given instruction of interest, among multiple information items related to the execution of the given instruction of interest. Where the given state information collected through the execution of a given exception handling routine includes at least the contents of the call stack buffer, providing this additional information (i.e., the call stack buffer pointer value present at the time of execution of the given instruction of interest) in the record can help interpret the contents of the call stack buffer. In particular, even if the transition period between the time of execution of the instruction of interest and the time when the contents of the call stack buffer are collected by the exception handling routine has changed, with the additional information configured regarding the call stack buffer pointer value present at the time of execution of the instruction of interest, it may be possible to accurately reconstruct the contents of the call stack buffer at the time of execution of the instruction of interest.

[0042] This information about the current call stack buffer pointer value at the time of execution of a given instruction of interest can be used directly by the exception handling routine to determine which part of the call stack contents to collect, or alternatively, the exception handling routine can capture the entire call stack contents and then, at a later point in time, use the information about the current call stack buffer pointer value at the time of execution of the given instruction of interest when executing the captured call stack contents.

[0043] There are multiple ways in which the instruction of interest (IOI) designation circuitry can be arranged to identify each IIOI. However, in one exemplary implementation, the IIOI designation circuitry is arranged to apply selection criteria to identify each IIOI for which the statistical analysis circuitry will record multiple information items when the IIOI is executed. Various forms of selection criteria are available. For example, the selection criteria can be arranged such that every Nth instruction is selected, or more complex criteria can be applied, such as seeking to detect the occurrence of a specific type of instruction and then selecting that specific type of instruction as the IIOI.

[0044] When using the techniques described herein, in the case of performing statistical analysis, the statistical analysis circuitry can be arranged to generate a record for each identified instruction of interest, and further, for each instruction of interest, a further instruction having an associated synchronous exception, so that when the further instruction reaches a given stage of the processing pipeline, a given exception handling routine is executed using the synchronous exception mechanism described above. While this allows the exception handling routine to collect the aforementioned given state information for use, for example, in conjunction with the record generated by the statistical analysis circuitry for each instruction of interest, this may lead to an increase in the number of exceptions employed. For example, without using the techniques of this invention, the statistical analysis circuitry might generate records for multiple instructions of interest, store those records in a buffer, and then issue asynchronous exceptions at some predetermined point in time, making it not necessarily possible to employ exceptions for every instruction of interest.

[0045] While the techniques described in this invention have the beneficial effect of enabling the collection of specific state information of the device for each instruction of interest, in some cases it may be desirable to reduce the amount of exception handling required within the device. In one exemplary embodiment, this is achieved by arranging the selection criteria to include an initial selection criterion and a further selection criterion. The instruction of interest designation circuitry can then be arranged to apply the initial selection criteria to identify candidate instructions of interest. However, the instruction of interest designation circuitry may further include a filter circuitry that applies the further selection criteria to determine which candidate instructions of interest will be used as actual instructions of interest. Thus, some of the candidate instructions of interest in the initially selected list can be filtered, thereby reducing the number of times exception handling routines are triggered in response to synchronization exceptions associated with the corresponding further instructions.

[0046] The timing of the filtering mechanism can vary depending on the specific implementation. For example, in one implementation, the filter circuitry can be arranged to treat only the candidate instruction of interest as an instruction of interest if the type of the candidate instruction of interest belongs to one or more given instruction types. Thus, with such an approach, filtering can be applied relatively early (e.g., in the decoding stage of the pipeline) to reduce the number of instructions of interest that the device will consider.

[0047] However, alternatively or otherwise, the filter circuitry can be arranged to treat a candidate instruction of interest as an instruction of interest when a given behavior is observed during the execution of that instruction. Thus, according to such a method, candidate instructions of interest can pass through the pipeline, and the decision on whether a candidate instruction of interest will actually be considered an instruction of interest can be postponed until the execution behavior of that candidate instruction of interest is known. If the execution behavior is not of interest, this allows the instruction of interest to be effectively excluded from further consideration as an instruction of interest. By way of illustrative example only, load or store instructions can be identified as candidate instructions of interest, but it can be determined that only the aforementioned given state information associated with those load or store instructions having relatively long delays is of interest. Therefore, any load or store instructions that execute relatively quickly can be excluded from further consideration as instructions of interest at this stage, such that only load or store instructions that execute relatively slowly are retained as instructions of interest, and thus the further instructions associated with these instructions have the synchronization anomalies associated with them.

[0048] In one exemplary implementation, the statistical analysis circuit responds to the execution of a given candidate instruction of interest to obtain multiple information items associated with the execution of that given candidate instruction of interest, but the filter circuit maintains only the record containing those multiple information items when it determines that a given behavior has been observed. Therefore, the statistical analysis circuit can initially treat a candidate instruction of interest as any other instruction of interest and begin collecting multiple information items that it wishes to store in a record in association with that instruction of interest. However, if the aforementioned given behavior of the instruction is not observed when the candidate instruction of interest is executed, it can be decided not to maintain a record for that instruction of interest.

[0049] Regarding the handling of further instructions, if a record of the associated candidate instructions of interest has not yet been maintained, the apparatus may be configured to not employ a synchronization exception when a further instruction is encountered, but instead allow the further instruction to simply continue to execute as normal.

[0050] There are several ways to process further instructions associated with a candidate instruction of interest. In one exemplary implementation, the associated further instruction is marked as having a synchronization exception only when the candidate instruction of interest is processed by the filter circuitry into an actual instruction of interest. Therefore, by the time the further instruction reaches that stage of the processing pipeline, if the candidate instruction of interest is no longer considered an actual instruction of interest, the further instruction may no longer be considered to have a synchronization exception.

[0051] In one exemplary implementation, once it has been determined that a candidate instruction of interest is an actual instruction of interest, a further instruction may only have a synchronization exception associated with it. Alternatively, a further instruction associated with a candidate instruction of interest may initially have a synchronization exception associated with it, but if it is later determined that the candidate instruction of interest will not be considered an actual instruction of interest, the synchronization exception association may be removed from the further instruction.

[0052] In some exemplary embodiments, the apparatus may also include performance monitoring circuitry for maintaining a record indicating the occurrence of one or more events during the execution of an instruction sequence. In such cases, the instruction of interest designation circuitry may be arranged to identify a given instruction in the sequence as an instruction of interest when the execution of a given instruction causes a given event to occur and the performance monitoring circuitry indicates that the occurrence of the given event has reached a threshold level. Through this method, a synchronization exception can be triggered in response to an associated further instruction, thereby enabling the capture of the previously mentioned given state information, which can then be used for further analysis, such as to provide some further contextual information related to the point in time when the occurrence of the given event has reached the threshold level. The given state information captured during the execution of a given exception handling routine can take various forms. For example, the given state information can have the forms discussed above, such as providing at least one software-defined state item associated with the execution of a given instruction of interest, such as the contents of a call stack buffer.

[0053] In one exemplary implementation, a given exception handling routine, in response to the execution of a further instruction associated with a given instruction arriving at a given stage of the processing pipeline, captures the current state of a record maintained by performance monitoring circuitry, in addition to the given state information. Therefore, in addition to the previously mentioned given state information that can be captured, the contents of the record maintained by performance monitoring circuitry, or at least a subset of that contents, can also be captured when the exception handling routine is executed by the further instruction.

[0054] The log maintained by the performance monitoring circuitry can take many forms, but in one exemplary implementation, for each of one or more events, the log includes a counter value indicating the number of times the event has occurred since the counter value was initialized. The events tracked by various counters can take many forms, and virtually any suitable metric within the system can be tracked if needed. By way of example only, one counter can be used to track the number of cache misses within a specific cache. For example, when a load or store instruction is executed, it can be determined whether a miss exists in the L1 data cache, and if so, the event counter for the cache miss event can be incremented. When such counters are maintained within the device for multiple events, this provides a useful performance monitoring log that can be analyzed later when an analysis program is executed.

[0055] Considering the cache miss example mentioned above, when the execution of a load or store instruction causes the event counter for a cache miss to reach a threshold level, the load or store instruction can be marked as an instruction of interest. The instruction of interest specifying circuitry can then apply selection criteria to determine further instructions that will have an associated synchronization exception. When this further instruction subsequently arrives at a given stage in the pipeline, a synchronization exception is triggered, causing the previously mentioned exception handling routine to be executed to collect desired device state information, and optionally also to collect information about all or a subset of counters maintained by performance monitoring circuitry.

[0056] As another exemplary use case of the technology described herein, it may be useful to detect when the call stack buffer reaches a specific threshold level of fullness or emptiness. As discussed previously, the call stack buffer maintains information for handling transitions between subroutines, wherein whenever a linked branch instruction is encountered, an entry is added to the call stack buffer to capture information used when returning from a subroutine entered in response to that linked branch instruction. Furthermore, whenever a return instruction is encountered, the most recently added entry is removed from the call stack buffer, and the information stored therein is consumed. The information maintained within entries in the call stack buffer can take various forms. For example, an entry may include an address associated with the caller of the subroutine (either a linked branch instruction or the target of the subroutine's return, which would be the next sequential instruction following the linked branch instruction) or an address associated with the called subroutine.

[0057] Regardless of whether the information is stored in the call stack buffer, the buffer has a finite size, so if the buffer reaches a full or empty threshold, such as if the buffer becomes full or empty, intervention may be required.

[0058] According to the technique described herein, the instruction of interest designation circuitry can be arranged to identify a given instruction in a sequence as an instruction of interest when the execution of a given instruction causes the number of entries in the call stack buffer to reach a trigger level. Further instructions suspending a synchronization exception are then identified, such that when that further instruction reaches a given stage in the pipeline, a synchronization exception is employed to enable the execution of an exception handling routine, which can then capture potentially useful system state while analyzing the state of the call stack buffer.

[0059] In one exemplary implementation, the trigger level indicates that the call stack buffer is full, and the given instruction identified as the instruction of interest is a linked branch instruction that causes the trigger level to be reached. A further instruction is a subsequent instruction flow modification instruction of a given type. For example, a subsequent linked branch instruction would be of particular interest here, as this instruction would seek to add another entry to the call stack buffer if it is full. However, in some exemplary implementations, it may be more convenient to mark the next instruction flow modification instruction that would cause any interaction with the call stack buffer as a further instruction; therefore, in one exemplary implementation, the further instruction could be the instruction that occurs first in a subsequent linked branch instruction or a subsequent return instruction. When an exception handling routine is triggered in a timely manner when the subsequent instruction flow modification instruction reaches a given stage in the pipeline, the exception handling routine can then determine whether any intervention in the state of the call stack buffer is necessary.

[0060] Similarly, the trigger level may alternatively or otherwise indicate that the call stack buffer is empty. When the trigger level indicates that the call stack buffer is empty, the given instruction identified as the instruction of interest could be a return instruction that causes the trigger level to be reached. Likewise, a further instruction could be a subsequent instruction flow change instruction of a given type. Of particular interest here is a subsequent return instruction that might seek to pop an entry from the stack when the stack is empty. However, for the same reasons discussed earlier, from a hardware perspective, it is simpler to mark the instruction following any instruction flow change instruction that will interact with the call stack buffer as a further instruction, such as marking the instruction following a return instruction or a linked branch instruction as a further instruction.

[0061] A specific example will now be described with reference to the accompanying drawings.

[0062] Figure 1 This is a block diagram of an apparatus according to an exemplary embodiment. A processor pipeline 10 is provided for executing a sequence of instructions fetched from memory. The processing pipeline includes multiple stages, such as... Figure 1 The diagram shows extraction stage 15, decoding stage 20, output stage 25, and execution stage 30. It should be understood that in some systems, further stages may exist within the processing pipeline, such as a renaming stage that facilitates register renaming in out-of-order processors.

[0063] The fetch stage 15 is configured to issue fetch requests to memory, which are processed via instruction cache 50 (and any intermediate caches, if necessary) to retrieve the sequence of instructions for execution. The fetch circuitry may have access to specific structures that help determine which instructions to fetch, such as branch prediction circuitry, which predicts whether a branch instruction will be fetched and, in some cases, the target address of the branch to be fetched.

[0064] The fetched instructions pass through decoding stage 20, where they are decoded to identify the operations required for execution by the processing pipeline to carry out the execution of each instruction. The decoded instructions are then passed to dispatch stage 25, where they are queued to await scheduling to execution stage 30. Execution stage 30 may include multiple different execution units for performing various data processing tasks, such as an arithmetic logic unit (ALU), a floating-point unit (FPU), a load / store unit (LSU), etc. Load instructions within the fetched sequence can be executed within the LSU to load data from memory into registers in register file 60 via one or more caches, including data cache 55. Similarly, store instructions can be executed within the LSU to store data from registers in register file 60 back to memory (the store operation allows data to be cached in a cache hierarchy (such as data cache 55) rather than written back to memory at that time).

[0065] The issue phase can be arranged so that once the source operands required by the instruction are available, for example, once those source operand values ​​are available in register file 60, or on a forwarding path provided to the execution phase 30, those instructions can be scheduled to the execution phase.

[0066] Statistical analysis circuitry 65 can be arranged to generate records in response to the execution of specific instructions, including multiple information items related to the execution of those instructions. A buffer 70 can be provided for storing the records generated by statistical analysis circuitry 65. Depending on the specific implementation, the information items captured by the statistical analysis circuitry in each record can take various forms, but are generally information items related to the execution of the instructions associated with that record. Thus, for example, the record may capture the instruction address, instruction type, execution context (e.g., in which exception level the processing pipeline 10 is operating), an indication of the software process running in that exception level (which may also be called a context identifier), information about the delay of the instruction, etc. Such records can then be analyzed as part of the process of monitoring the execution of a program within the processing pipeline 10. Such monitoring activities can be performed in various situations, such as when seeking to debug program code or during normal operation of the processing pipeline.

[0067] Other structures can also be used to obtain useful information that can be analyzed during the execution of the monitoring program. An example is a performance monitoring unit (PMU) 75, which tracks specific events of interest occurring within the device. For instance, the PMU 75 may maintain a series of counters 80, each associated with a specific event, with the counters incrementing to continuously track the number of occurrences of each event of interest. Events of interest can take many forms, but a concrete example could be a counter used to track cache misses in a specific cache, such as the L1 data cache 55 coupled to the LSU of execution phase 30. Similar to the records generated by the statistical analysis circuitry 65, the counters 80 maintained by the PMU 75 can provide useful information when analyzing the operation of the device during program execution.

[0068] However, when analyzing such information, it may also be useful to have access to specific state information about the state of the device when a particular record is created by the statistical analysis circuitry and / or when a specific threshold within a counter is reached. Alternatively, it may be useful to obtain such state information to give an indication of the information in the form of a specific point in time of interest (such as the execution of a particular instruction). The state information of interest may take many forms, but in one exemplary embodiment, the state information of interest is at least one software-defined state item, such as a state that is generally not tracked by components (such as the statistical analysis circuitry 65 or the PMU 75). As a specific example, the contents of the call stack buffer 85 when a particular instruction is executed may be useful, either for its own purposes or to provide additional context when analyzing information such as records generated by the statistical analysis circuitry 65 or counter 80 generated by the PMU 75.

[0069] According to the technology described herein, a mechanism is provided that enables the collection of desired state information of the apparatus at a point in time when the captured state information indicates the state present at the time of execution of the instruction of interest, without directly interfering with the execution of the instruction of interest. Specifically, an instruction of interest designation circuit 40 is provided, which is arranged to apply specific criteria to identify one or more instructions of interest appearing in a sequence of instructions executed within the processing pipeline 10. Instructions of interest can be selected in various ways. For example, considering the statistical analysis circuit 65, each instruction used to trigger the statistical analysis circuit to generate a record can be designated as an instruction of interest by the instruction of interest designation circuit 40. As another example, when an instruction is executed that causes an event in an event being tracked by the PMU 75 to occur, and the occurrence of this instance of the event causes the corresponding counter 80 in the PMU to reach a threshold level, the instruction can also be identified as an instruction of interest.

[0070] For example, an instruction that causes a change to a subroutine being executed by the processing pipeline 10 can cause an entry to be pushed onto or popped from the call stack buffer 85, and such an instruction can also be identified as an instruction of interest if the execution of such an instruction causes a specific full or empty threshold of the call stack buffer 85 to be reached.

[0071] According to the technique described herein, when an instruction of interest is identified by the instruction of interest designation circuit 40, the instruction of interest designation circuit also applies defined criteria to determine a further instruction in the instruction sequence that follows the instruction of interest, and then marks the further instruction as having a synchronization anomaly associated with it.

[0072] Therefore, the execution of the instruction of interest continues as usual, but when a further instruction arrives at a given stage of the processing pipeline, and assuming a synchronization exception is still associated with that further instruction (also referred to herein as suspending the further instruction), this can be used to trigger a synchronization exception instead of continuing the execution of the further instruction. The given stage for performing this analysis can be any suitable stage within processing pipeline 10. In one exemplary embodiment, the given stage could be execution stage 30, but in another alternative embodiment, an earlier stage in the processing pipeline can be used as the given stage that triggers a synchronization exception when a further instruction arrives at that stage.

[0073] When a synchronization exception is triggered, this causes the processing pipeline to execute a given exception handling routine to collect the aforementioned state of interest information, such as, for example, the contents of the call stack buffer 85. This state of interest information may be stored internally or output from the device and may be combined with other information, such as associated records generated by the statistical analysis circuitry 65 for the instruction of interest, or the contents of one or more counters 80 maintained by the PMU 75, which may be useful, for example, when the instruction of interest causes an event to occur, thereby causing one of the counters to reach a threshold level.

[0074] Since the synchronization exception is not associated with the instruction of interest itself, this does not prevent the instruction of interest from executing normally. However, by appropriately selecting the further instructions to be associated with the instruction of interest, it is possible to ensure that the synchronization exception is used at a predetermined point in time after the execution of the instruction of interest. This can significantly improve the usefulness of the state information collected when executing the exception handling routine in response to the synchronization exception.

[0075] Figure 2This is a flowchart illustrating the operation of the instruction of interest designation circuit 40. At step 100, the instruction of interest designation circuit 40 identifies the instruction of interest. As discussed previously, various different criteria can be used to identify each instruction of interest. For example, the instruction of interest designation circuit can monitor specific types of instructions and mark those instructions as instructions of interest, and / or can be arranged to identify every Nth instruction in a sequence as an instruction of interest.

[0076] Once the instruction of interest has been identified, defined criteria are applied in step 105 to determine further instructions in the instruction sequence that appear later than the instruction of interest. The criteria applied here can take various forms, and will be referenced later. Figures 5A to 5C Let's discuss some examples. However, the aim is to identify suitable instructions such that when a synchronization exception is triggered in response to those instructions, and thus when specific state information is collected, that state information is likely to represent the form in which the instruction of interest is executed, or at least a form in which such information can be deduced from, for example, captured state information.

[0077] Once a further instruction has been identified at step 105, it is marked as having an associated synchronization exception at step 110, and this mark is passed through the processing pipeline along with the further instruction. As will be discussed in more detail later, in some exemplary implementations, it may be possible to remove the association between the synchronization exception and the further instruction before the further instruction reaches the previously mentioned given stage; however, assuming that the synchronization exception is still suspended for the further instruction when it reaches the given stage, this will trigger the synchronization exception, thereby causing the execution of the previously mentioned exception handling routine to collect given state information.

[0078] refer to Figure 3 The process will be discussed in more detail. In particular, at step 150, it is determined whether further instructions have reached a given stage of the processing pipeline and are still flagged as having a synchronization exception associated with it. As discussed earlier, the given stage may be, for example, execution stage 30, but may alternatively be an earlier stage in the processing pipeline.

[0079] If, at step 150, it is determined that a further instruction has reached a given stage and is marked as having a synchronous exception pending it, then the synchronous exception is triggered at step 155. This causes the processing pipeline to halt the execution of the fetched instructions, and instead, an exception handling routine is executed at step 160 to gather given state information. The exact exception handling routine executed typically depends on the form of the synchronous exception; therefore, the synchronous exception triggered at step 155 will be used to determine the specific exception handling routine that needs to be executed.

[0080] At step 165, once the given state information has been collected by the exception handling routine, it is output from the device, or alternatively, stored in a suitable internal storage structure of the device for later analysis. Then, at step 170, processing returns from the exception handling routine, and execution of the instruction flow can subsequently resume. Further instructions can then be executed. This can occur immediately upon returning from the exception handling routine, for example, if the given stage that triggered the synchronization exception is the execution stage, or alternatively, one or more other instructions can be executed first, while further instructions proceed through the remainder of the processing pipeline until they reach the execution stage, at which point the further instructions are executed.

[0081] Figure 4 A form of state information that can be effectively captured by the techniques described herein is illustrated schematically. Specifically, the state information may include the contents of a call stack buffer 85. The call stack buffer is used to maintain information for handling transitions between subroutines, wherein whenever a linked branch (BL) instruction is encountered, an entry is added to the call stack buffer to capture information used in a timely manner when returning from a subroutine entered in response to that BL instruction. Such an action is generally referred to as pushing an entry into the call stack buffer. Furthermore, whenever a return instruction is encountered, the most recently added entry is removed and the information stored in the call stack buffer is consumed; such an action is generally referred to as popping an entry from the stack.

[0082] The information pushed onto the call stack buffer in response to a BL instruction can take various forms, provided that its indication is sufficient to allow a subsequent return from the subroutine branching off from the BL instruction. Figure 4 In the example shown, whenever a BL instruction is encountered, the return address of the subroutine from its branch, which is being branched by the BL instruction, is pushed into the call stack buffer. A call stack pointer is maintained to identify the topmost entry in the call stack buffer at any given point in time. Therefore, consider... Figure 4Suppose that subroutine A is initially being executed, and then at time point 200, a BL instruction is encountered that causes a transition to subroutine B. This pushes the return address for subroutine A (i.e., the address of the next instruction to be executed in subroutine A when processing returns to subroutine A at the appropriate time) onto the entry of the call stack pointed to by the current call stack pointer. Furthermore, the call stack pointer is then incremented, and processing branches to subroutine B. As shown at times 205 and 210 in this example, multiple subroutines are nested, so whenever a subroutine change occurs due to the BL instruction, another return address entry is pushed onto the call stack buffer 85. Therefore, at time point 205, the return address of subroutine B is pushed onto the call stack, and the call stack pointer is then incremented, and processing subsequently branches to subroutine C. Similarly, at time point 210, the return address for subroutine C is pushed onto the call stack, and the call stack pointer is incremented, whereby processing then proceeds to subroutine D.

[0083] At that point in time, the contents of stack buffer 85 are as follows: Figure 4 As shown. Specifically, there are three entries storing the return addresses for subroutines A, B, and C, and the call stack pointer has been incremented to point to the next empty entry. When time point 215 is reached, a return instruction indicating that subroutine D has completed is encountered. At this time, the call stack pointer is decremented, and subsequently, the entry pointed to by the call stack pointer is popped from the call stack. This information provides the return address for subroutine C, thus allowing execution to return to subroutine C. It should be noted that although the entry containing the return address for subroutine C has been popped and its information has been consumed, it is not usually overwritten at that time. However, since the current call stack pointer now points to this entry, if a subsequent BL instruction is encountered, the new return address will overwrite the return address information for subroutine C because a new return address is pushed onto the call stack into the entry pointed to by the call stack pointer.

[0084] At step 220, assume another return instruction is encountered, causing the call stack pointer to decrement, and the call stack pointer is popped from its current return address, i.e., the return address of subroutine B. Then, the process returns to subroutine B.

[0085] If, for example, the instruction of interest occurs at time 217 in subroutine D, it might be desirable to capture the contents of the call stack buffer as is when the instruction of interest is executed. As discussed earlier, this would be in the form of calling stack buffer 85, such as... Figure 4As shown. However, if another BL instruction is encountered before the contents of the call stack buffer are collected, a new entry will be pushed into the call stack buffer, and the contents of the call stack buffer will have changed. Similarly, if one or more return instructions are encountered, the entry will be popped from the call stack, and the call stack pointer will be decremented. Although the popped information is not immediately overwritten, the current call stack pointer will no longer correspond to the call stack pointer that existed at time point 217. Furthermore, if a subsequent BL instruction is encountered, such as that indicated at time point 225, and this occurs before the exception handling routine is triggered to capture the call stack buffer state information, this may cause the contents of the call stack buffer that existed at time point 217 to be overwritten, making the contents undeterminable.

[0086] According to the techniques described herein, the likelihood of such scenarios occurring can be reduced by appropriately selecting further instructions following the instruction of interest, thereby causing synchronization anomalies to be triggered. Figures 5A to 5C Three possible exemplary methods are shown in the figure. Figure 5A When an instruction of interest is identified at step 250, processing proceeds to step 255, where the instruction of interest designation circuit 40 identifies the instruction to be executed immediately following the instruction of interest as a further instruction. This thus prevents processing from potentially transitioning to a different subroutine before capturing the state of the call stack buffer.

[0087] However, in some cases, it may be deemed inappropriate to mark an immediately following instruction as a further instruction. For example, out-of-order execution of instructions may be supported, and it is often likely that the immediately following instruction would be allowed to execute before the instruction of interest. However, by designating the immediately following instruction as a further instruction, thus suspending it with a synchronization exception, such reordering can be prevented, and potentially, probe-like behavior can be introduced. If this is considered problematic, it can be mitigated by suspending a synchronization exception on the Nth instruction following the instruction of interest (where N is greater than 1).

[0088] As another example of a technology that can be used to select further instructions, such as Figure 5B As shown, when an instruction of interest is identified at step 260, the instruction of interest designation circuit 40 can be arranged to identify the next return instruction as a further instruction. This ensures that if another BL instruction occurs before a next return instruction occurs, the synchronization exception still occurs within the same subroutine. However, even if another BL instruction occurs, causing a new entry to be pushed onto the stack, by identifying the next return instruction as a further instruction, it is ensured that the call stack pointer will not decrease to a value lower than the call stack pointer at the time the instruction of interest occurred, thus avoiding the risk of overwriting existing related call stack contents when executing the instruction of interest.

[0089] For example, such as Figure 5C As shown, when an instruction of interest is identified at step 270, the instruction of interest designation circuit 40 can identify the next BL instruction as a further instruction at step 275. This ensures that even if one or more return instructions are encountered first, causing the call stack pointer to decrement, the call stack contents will not be overwritten before a synchronization exception is employed. Therefore, through the measures discussed above, the instruction of interest can be allowed to execute normally, but a definite point in time at which a synchronization exception will be employed is provided, thereby allowing the contents of the call stack buffer to be analyzed before its contents are changed in a manner that prevents the contents of the call stack buffer from being determined when the instruction of interest is executed.

[0090] As another exemplary method for determining further instructions, the instruction of interest designation circuit 40 may identify any instruction in the instruction sequence that appears after the instruction of interest up to, but not exceeding, at least one instruction of a given type as a further instruction. In this case, the actual instruction selected as a further instruction is not considered important, as long as it appears after the instruction of interest up to, but not exceeding, an instruction of the specified type. For example, the specified type here could be a BL instruction, so such a method would ensure that a synchronization exception occurs at least until the next BL instruction is encountered, without precisely limiting which instruction has a synchronization exception that is pending it.

[0091] Figure 6 This is a flowchart illustrating how the techniques described herein can be used in conjunction with statistical analysis, such as that performed by statistical analysis circuit 65. At step 300, selection criteria are applied to identify the next instruction of interest, these criteria being applied by instruction of interest specifying circuit 40. For the statistical analysis example, multiple criteria may be used; for example, the criteria may select only every Nth instruction within the sequence, or alternatively, specific types of instructions may be sought to be marked as instructions of interest.

[0092] At step 305, the instruction of interest designation circuit 40 then identifies a further instruction and marks it as having an associated synchronization anomaly. Any suitable scheme can be used to select the further instruction, such as, for example, using a previously referenced... Figures 5A to 5C The techniques of discussion.

[0093] At step 310, when an instruction of interest is executed, the statistical analysis circuitry can collect multiple information items related to the execution of that instruction of interest and store the collected information as records in buffer 70. Various types of information that can be collected at this time, such as instruction address, instruction type, execution context, etc., have been discussed previously. In a particular exemplary implementation, the collected general information can be supplemented by one or more additional information items (such as, for example, the current call stack pointer value at the time of execution of the instruction of interest). The collection of the current call stack pointer value can be helpful when seeking to analyze the contents of the call stack buffer obtained later when executing an exception handling routine, for example, by enabling a comparison of this call stack pointer value with the call stack pointer value present at the time of execution of the exception handling routine.

[0094] At step 315, when a further instruction arrives at the previously mentioned given stage, a synchronous exception is employed to execute the corresponding exception handling routine in order to acquire specific state information not present in the record stored in buffer 70. As discussed earlier, this specific state information can be a specific software-defined state, such as the contents of the call stack buffer 85.

[0095] At step 320, the additional status information is output or stored in association with the record for the instruction of interest, and then at step 325, the process returns to the exception handling routine to allow the execution of further instructions.

[0096] By acquiring this additional state information, supplementary and useful contextual information can be provided when analyzing the records generated by the statistical analysis circuitry for the instruction of interest. For example, by using the call stack buffer, such as its contents at the time the instruction of interest is being executed, a sequence of subroutines executed before reaching the instruction of interest can be identified.

[0097] When a further instruction is selected as the next call stack (BL) or a return instruction following the instruction of interest, it is ensured that while the exception handling routine is executing to capture the contents of the call stack buffer, processing remains within the same subroutine where the instruction of interest was encountered. However, if another criterion is chosen to select the further instruction, such as only the next return instruction or only the next BL instruction, the call stack contents may have changed, but it is still ensured that all original call stack contents present at the time of execution of the instruction of interest have not been overwritten. In such cases, the exact form of the call stack buffer at the time of execution of the instruction of interest can be determined by capturing the current call stack pointer value within a record generated by the statistical analysis circuitry. In particular, the form of the call stack buffer at the time of execution of the instruction of interest can be recreated by comparing the call stack pointer value maintained in the record with the call stack pointer value present when the call stack buffer is analyzed by the exception handling routine.

[0098] Figure 7 This is a flowchart illustrating alternative methods that can be used when performing statistical analysis using the techniques described above. According to Figure 7 In the scenario shown, the instruction of interest specifying circuit 40 includes a filter circuit 45, which can be used to reduce the number of instructions of interest, and thus reduce the number of synchronization exceptions employed. Specifically, as... Figure 7 As shown, at step 350, the instruction of interest designation circuit 40 may apply initial selection criteria to identify candidate instructions of interest. This may, for example, involve selecting every Nth instruction within the sequence. Then, at step 355, at least until a candidate instruction of interest has been executed, further selection criteria may be applied to evaluate whether the candidate instruction of interest is considered an actual instruction of interest.

[0099] The timing of applying this further selection criterion can vary depending on the specific implementation. For example, the application can be pre-done, for instance, to exclude specific types of instructions from the list of instructions of interest. Thus, while the initial selection criterion may select every Nth instruction, the further selection criterion may focus on the type of candidate instructions of interest for each such selection, excluding specific types of instructions known not to be of particular interest from further consideration. Alternatively or otherwise, candidate instructions of interest may be allowed to proceed through the pipeline to execution time, but their behavior during execution can then be analyzed to determine whether they are still of interest and therefore should be maintained as actual instructions of interest.

[0100] In a concrete example, it may be determined that only relatively slow load or store instructions are of interest. The initial filtering at step 355 can thus remove any instructions that are not load or store instructions from further consideration, while a later filtering at execution time can subsequently filter out any relatively fast-executing load or store instructions, so that only slow-executing load or store instructions remain as the actual instructions of interest.

[0101] At step 360, if a candidate instruction of interest is to be considered an actual instruction of interest, it is decided to maintain only the record in buffer 70. Therefore, although the statistical analysis circuit 65 may go through the process of collecting information that will be stored in the record when executing a candidate instruction of interest, the record will not be maintained if it is subsequently determined that the candidate instruction of interest is no longer of interest.

[0102] At step 365, in order to determine which steps are relevant to further instructions, it is determined whether a record has been maintained. As mentioned earlier, the given stage for evaluating further instructions can be the execution stage or an earlier stage in the pipeline. If the given stage is an earlier stage in the pipeline, it is possible to pause the processing of further instructions at that given stage until it is known whether a record is being maintained for the instruction of interest.

[0103] If the record is maintained, the process proceeds to step 370, where a synchronization exception is used when further instructions reach a given stage, and the process then proceeds as follows. Figure 6 The remaining parts continue (i.e., steps 315, 320, and 325 are performed).

[0104] However, if no record is maintained, then at step 375, when a further instruction reaches a given stage, a synchronization exception is not adopted, and the further instructions are allowed to continue execution as normal.

[0105] In cases where the decision regarding whether to maintain a record for an instruction of interest occurs before a further instruction reaches a given stage, in one exemplary implementation, a synchronization exception can be kept pending for the further instruction; however, if it is determined that the record has not yet been maintained, the synchronization exception is ignored when the further instruction reaches the given stage. Alternatively, if it is determined that no record is being maintained, the synchronization exception can be removed from the further instruction such that when the further instruction reaches the given stage, it no longer has a pending synchronization exception for it and will therefore simply continue execution without embracing any exception.

[0106] Figure 8 This is a flowchart illustrating a performance monitoring technique that can be employed when utilizing the previously described techniques. At step 400, the PMU 75 maintains an event counter 80 for multiple events. At step 405, it is determined whether the execution of the instruction caused the occurrence of one of the monitored events; if not, no further action is required at step 420. However, if the execution of the instruction did cause the occurrence of a monitored event, the relevant counter is updated at step 410, and subsequently, at step 415, it is evaluated whether the counter has reached a threshold level. If not, no further action is required at step 420.

[0107] However, if it is determined at step 415 that a threshold level has been reached, then at step 425, the instruction that caused the monitored event is considered an instruction of interest. Therefore, further instructions are identified for this instruction of interest, and these further instructions are marked as having an associated synchronization anomaly.

[0108] When further instructions reach a given stage, at step 430, a synchronous exception is employed to execute an exception handling routine to collect specific state information. This can take various forms, such as software-defined states, like the contents of the call stack buffer discussed earlier.

[0109] At step 435, such additional status information is output or stored in association with the current counter value for the monitored event, as maintained by the PMU. This provides additional contextual information that can be used when analyzing those counter values.

[0110] At step 440, it may be optional to decide to reset one or more counters. For example, resetting a counter that has reached a threshold level may at least be appropriate. Furthermore, processing then returns from the exception handling routine, thereby allowing further instructions to continue execution.

[0111] Figure 9 This is a flowchart illustrating another exemplary use case of using the techniques described herein to track when the call stack buffer reaches a full or empty threshold level. At step 450, when the BL instruction is executed, it is determined whether the execution of the BL instruction causes the call stack buffer to become full. If so, at step 465, the BL instruction is marked as an instruction of interest, and subsequently... Figure 9 In the example shown, the next linked branch or return instruction (whichever occurs first) is marked as a further instruction with a synchronization exception pending it. Of particular interest would be the next branching (BL) instruction that occurs before any intermediate return instruction, as this instruction would then seek to add another entry to the call stack buffer if it is full. However, for program efficiency, it might be easier to simply mark any BL or return instruction that occurs next in the instruction sequence as a further instruction. Alternatively, only the next BL instruction might be used as a further instruction.

[0112] If it is determined at step 450 that the BL instruction will not fill the call stack buffer, then at step 455 it is determined whether a return instruction that would empty the call stack buffer is being executed. If not, the process returns to step 450.

[0113] However, if it is determined that a return instruction that caused the call stack buffer to become empty has been executed, then at step 460, the return instruction is marked as an instruction of interest, and... Figure 9 In the example shown, the next return or BL instruction is marked as a further instruction with a pending synchronization exception. Of particular interest is a scenario where another return instruction follows a return instruction that emptys the call stack buffer, which would seek to pop an entry from the call stack buffer if it is empty. However, for program efficiency, it might be easier to simply mark either the next return or BL instruction that occurs first after the instruction of interest. Alternatively, the instruction of interest designation circuit 40 can be arranged to find only the next return instruction following the instruction of interest and mark it as a further instruction.

[0114] Figure 10A specific implementation of a usable simulator is illustrated. While the previously described example implementations emulate the invention in terms of apparatus and methods for operating specific processing hardware supporting the technologies involved, it is also possible to provide an instruction execution environment implemented using a computer program according to the examples described herein. Such computer programs are generally referred to as simulators, in part because they provide a software-based implementation of a hardware architecture. Types of simulator computer programs include emulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, the simulator implementation can run on a host processor 515 supporting the simulator program 505, optionally running a host operating system 510. In some arrangements, multiple emulation layers may exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors were required to provide simulator implementations that execute at a reasonable speed, but this approach may be reasonable in certain situations, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, the simulator implementation may provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of the simulation is given in the following literature: “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0115] With respect to the examples previously described with reference to specific hardware constructs or features, in a specific implementation of the simulation, equivalent functionality may be provided by suitable software constructs or features. For example, specific circuitry may be provided as computer program logic in a specific implementation of the simulation. Similarly, memory hardware (such as registers or caches) may be provided as software data structures in a specific implementation of the simulation. Furthermore, the physical address space for accessing memory in the hardware device may be simulated as a virtual address space, which is mapped by the simulator 505 to a virtual address space used by the host operating system 510. One or more of the hardware elements referenced in the previously described examples exist in an arrangement on the host hardware (e.g., the host processor 515), and where appropriate, some implementations of the simulation may utilize the host hardware.

[0116] The simulator program 505 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a virtual hardware interface (instruction execution environment) to the target code 500 (which may include an application program, a guest operating system, and a hypervisor), the virtual hardware interface being identical to the hardware interface of the hardware architecture modeled by the simulator program 505. Therefore, the simulator program 505 can be used to execute program instructions of the target code 500 from within the instruction execution environment, enabling the host computer 515, which does not actually possess the hardware characteristics of the devices discussed above, to emulate these characteristics. The simulator program may include processing program logic 520 for emulating the behavior of the processing pipeline 10, and instruction of interest specifying program logic 525 for emulating the behavior of the instruction of interest specifying circuit 40. Simulation program logic (not shown) using data structures maintained by the simulator code 505 can also be used to emulate the system's architecture registers 60, mapping the architecture registers of the target architecture to memory space used by the host hardware 515. Therefore, in Figure 10 In the example, the technique described herein for collecting device status information can be executed in software by simulator program 505.

[0117] In this application, the phrase "configured as..." is used to mean that the elements of the device have a configuration capable of performing the defined operation. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, the device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured as" does not mean that the elements of the device need to be changed in any way to provide the defined operation.

[0118] While exemplary embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise embodiments, and various changes, additions, and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, features of the dependent claims may be combined with features of the independent claims in various ways without departing from the scope of the invention.

Claims

1. A data processing apparatus comprising: a processing pipeline for executing a sequence of instructions; and an instruction of interest specifying circuit for identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information of the apparatus associated with execution of the instruction of interest is to be collected; wherein: the instruction of interest specifying circuit is arranged to apply a defined criterion to each identified instruction of interest to determine a further instruction later in the sequence of instructions than the instruction of interest and to mark the further instruction as having a synchronisation exception associated therewith; and the processing pipeline, in response to the further instruction reaching a given stage of the processing pipeline and being marked as having the synchronisation exception associated therewith, triggers the synchronisation exception rather than executing the further instruction, causing the processing pipeline to execute a given exception handling routine in order to collect the given state information.

2. The apparatus of claim 1, wherein on return from the given exception handling routine, the processing pipeline is arranged to execute the further instruction.

3. The apparatus of claim 1 or claim 2, wherein the defined criterion is such that the instruction of interest specifying circuit determines as the further instruction an instruction occurring at a predetermined position in the sequence of instructions relative to the instruction of interest.

4. The apparatus of claim 3, wherein the defined criterion is such that the instruction of interest specifying circuit determines as the further instruction an instruction immediately following the instruction of interest in the sequence of instructions.

5. The apparatus of claim 1, wherein the defined criterion is such that the instruction of interest specifying circuit determines as the further instruction at least one given type of instruction occurring after the instruction of interest in the sequence of instructions.

6. The apparatus of claim 5, wherein the at least one given type of the instruction is a return instruction for returning the processing pipeline to execute program code being executed prior to execution of a current subroutine.

7. The apparatus of claim 5 or claim 6, wherein the at least one given type of the instruction is a branch instruction with a link, the branch instruction with a link when executed causing the processing pipeline to stop processing of a current subroutine and start execution of another subroutine.

8. The apparatus of claim 1 or claim 2, wherein the defined criterion is such that the instruction of interest specifying circuit determines as the further instruction any instruction occurring after the instruction of interest in the sequence of instructions up to but not including a next instruction of at least one given type occurring after the instruction of interest in the sequence of instructions.

9. The apparatus of claim 1, further comprising: a statistical analysis circuit, responsive to execution of a given instruction of interest, to generate a record comprising a plurality of items of information relating to the execution of the given instruction of interest; and a record store for storing the record. ​ The given status information collected by executing the given exception handling routine comprises additional information not included in the record generated by the statistical analysis circuit.

10. The apparatus of claim 9, wherein the additional information comprises at least one software-defined status item associated with execution of the given instruction of interest.

11. The apparatus of claim 10, wherein the at least one software-defined status item comprises contents of a call stack buffer maintained by the apparatus.

12. The apparatus of claim 11, wherein the statistical analysis circuit is arranged to include, within the plurality of items of information relating to the execution of the given instruction of interest, an indication of a current call stack buffer pointer value at the time of execution of the given instruction of interest.

13. The apparatus of any one of claims 9 to 12, wherein the instruction of interest specifying circuit is arranged to apply selection criteria to identify each instruction of interest for which the statistical analysis circuit is to record the plurality of items of information at the time of execution of the instruction of interest.

14. The apparatus of claim 13, wherein: the selection criteria comprises initial selection criteria and further selection criteria; the instruction of interest specifying circuit is arranged to apply the initial selection criteria so as to identify candidate instructions of interest; and the instruction of interest specifying circuit comprises a filter circuit that applies the further selection criteria to determine which candidate instructions of interest are to be used as the instructions of interest.

15. The apparatus of claim 14, wherein the filter circuit is arranged to regard a candidate instruction of interest as an instruction of interest only when a type of the candidate instruction of interest belongs to one or more given instruction types.

16. The apparatus of claim 14, wherein the filter circuit is arranged to regard a candidate instruction of interest as an instruction of interest when a given behaviour is observed at the time of execution of the candidate instruction of interest.

17. The apparatus of claim 16, wherein the statistical analysis circuit obtains the plurality of items of information relating to the execution of a given candidate instruction of interest in response to the execution of the given candidate instruction of interest, but only maintains the record comprising the plurality of items of information when the filter circuit determines that the given behaviour is observed.

18. The apparatus of any one of claims 14 to 17, wherein only when a candidate instruction of interest is regarded as an instruction of interest by the filter circuit is the further instruction associated therewith tagged as having a synchronisation exception associated therewith at the time the further instruction reaches the given stage of the processing pipeline.

19. The apparatus of claim 1, further comprising: a performance monitoring circuit to maintain, during execution of the sequence of instructions, a record indicative of occurrence of one or more events; and a The instruction of interest specifying circuitry is arranged to identify a given instruction in the sequence as an instruction of interest when execution of the given instruction causes a given event to occur and the performance monitoring circuitry indicates that the occurrence of the given event has reached a threshold level.

20. The apparatus of claim 19, wherein the given exception handling routine is responsive to execution of the further instruction associated with the given instruction reaching the given stage of the processing pipeline to cause capture of a current state of the record maintained by the performance monitoring circuitry in addition to the given state information.

21. The apparatus of claim 19 or claim 20, wherein, for each of the one or more events, the record maintained by the performance monitoring circuitry comprises a counter value indicating a number of occurrences of the event since initialization of the counter value.

22. The apparatus of claim 1, further comprising: a call stack buffer to maintain information used to handle transitions between subroutines, wherein each time a branch with link instruction is encountered, an entry is added to the call stack buffer to capture information used when returning from a subroutine entered in response to the branch with link instruction, and each time a return instruction is encountered, a most recently added entry is removed and the information stored in the call stack buffer is consumed; and the instruction of interest specifying circuitry is arranged to identify a given instruction in the sequence as an instruction of interest when execution of the given instruction causes a number of entries in the call stack buffer to reach a trigger level.

23. The apparatus of claim 22, wherein: the trigger level indicates that the call stack buffer is full; the given instruction identified as the instruction of interest is a branch with link instruction that causes the trigger level to be reached; and the further instruction is a subsequent instruction stream change instruction of a given type.

24. The apparatus of claim 22 or claim 23, wherein: the trigger level indicates that the call stack buffer is empty; the given instruction identified as the instruction of interest is a return instruction that causes the trigger level to be reached; and the further instruction is a subsequent instruction stream change instruction of a given type.

25. A method of collecting given state information of an apparatus, comprising: employing a processing pipeline to execute a sequence of instructions; and identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information of the apparatus associated with execution of the instruction of interest is to be collected; for each identified instruction of interest, applying a defined criterion to determine a further instruction later in the sequence of instructions than the instruction of interest and marking the further instruction as having a synchronization exception associated therewith; and in response to the further instruction reaching a given stage of the processing pipeline and being marked as having the synchronisation exception associated therewith, the synchronisation exception is triggered rather than the further instruction being executed, thereby causing the processing pipeline to execute a given exception handling routine in order to collect the given state information.

26. A computer program product comprising a computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: processing program logic for executing a sequence of instructions in a series of pipeline stages; and instruction of interest specifying program logic for identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information associated with execution of the instruction of interest is to be collected; wherein: the instruction of interest specifying program logic is arranged, for each identified instruction of interest, to apply a defined criterion to determine a further instruction later in the sequence of instructions than the instruction of interest, and to mark the further instruction as having a synchronisation exception associated therewith; and the processing program logic, in response to the further instruction reaching a given pipeline stage and being marked as having the synchronisation exception associated therewith, triggers the synchronisation exception rather than the further instruction being executed, thereby causing the processing program logic to execute a given exception handling routine in order to collect the given state information.

27. A host data processing apparatus comprising: processing program logic for executing a sequence of instructions in a series of pipeline stages; and instruction of interest specifying program logic for identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information associated with execution of the instruction of interest is to be collected; wherein: the instruction of interest specifying program logic is arranged, for each identified instruction of interest, to apply a defined criterion to determine a further instruction later in the sequence of instructions than the instruction of interest, and to mark the further instruction as having a synchronisation exception associated therewith; and the processing program logic, in response to the further instruction reaching a given pipeline stage and being marked as having the synchronisation exception associated therewith, triggers the synchronisation exception rather than the further instruction being executed, thereby causing the processing program logic to execute a given exception handling routine in order to collect the given state information.

Images