Exclusive monitoring command

Abstract

The apparatus includes an instruction decoder 20 and processing circuitry 22. A monitoring circuitry 36 monitors one or more events indicative of a potential update to data associated with any of the set of monitored addresses and makes accessible to software executing on the processing circuitry 22 a monitoring report indication indicating whether an event has occurred for at least one of the set of monitored addresses. In response to decoding a set exclusive status instruction specifying a given address, the processing circuitry 22 sets an exclusive status associated with the given address. The exclusive status is cleared in response to detecting an event indicative of a conflicting memory access to the given address. In response to decoding a monitor exclusive instruction, the processing circuitry 22 determines whether an exclusive status is associated with a target address and, if so, assigns the target address to be one of the set of monitored addresses.

Description

[Technical Field]

[0001] The present technique relates to the field of data processing.

[0002] A data processing system may have multiple requesting devices that may share access to a shared memory system. Occasionally, a process executing on a given requester device may need to wait for data to be updated in memory in response to a request from another requester device. For example, software executing on a CPU or other processing element may be waiting for a queue of data in memory to be updated by an input / output device such as a network interface controller. Similar problems may arise when multiple processes executing on the same processing element use structures in memory to provide inter-process communication. If the number of distinct addresses in memory monitored for changes by a given software process is large, it may be inefficient for the software to perform this monitoring by repeatedly polling each address.

[0003] At least some examples provide an apparatus comprising: an instruction decoder for decoding instructions; a processing circuit for performing data processing in response to instructions decoded by the instruction decoder; and a monitoring circuit for monitoring one or more events indicative of a potential update to data associated with any of a set of monitored addresses and making accessible to software executing on the processing circuit a monitoring report indication indicative of whether any of the one or more events has occurred for at least one of the set of monitored addresses; wherein in response to the instruction decoder decoding an exclusive status setting instruction specifying a given address, the processing circuit is configured to set an exclusive status associated with the given address; and in response to detecting an event indicative of a conflicting memory access to the given address, the processing circuit is configured to: in response to the instruction decoder decoding the monitoring exclusive instruction, determine whether an exclusive status is associated with a target address; and, if it is determined that an exclusive status is associated with the target address, assign the target address to be one of the set of monitored addresses for which one or more events are monitored by the monitoring circuit.

[0004] At least some examples provide a method that includes: setting an exclusive status associated with the given address in response to decoding a set exclusive status instruction that specifies the given address; clearing the exclusive status associated with the given address in response to detecting an event that indicates a conflicting memory access to the given address; determining whether an exclusive status is associated with the target address in response to decoding a monitor exclusive instruction, and assigning the target address to be one of a set of monitored addresses if it is determined that the exclusive status is associated with the target address; monitoring one or more events that indicate a potential update to data associated with any of the set of monitored addresses; and making a monitor report indication accessible to software that indicates whether any of the one or more events has occurred for at least one of the set of monitored addresses.

[0005] At least some examples provide a computer program that, when executed on a host data processing apparatus, controls the host data processing apparatus to provide an instruction execution environment for executing instructions of target code, the computer program comprising: instruction decoding program logic for decoding instructions of the target code and controlling the host data processing apparatus to perform data processing corresponding to the instructions of the target code; and monitor program logic for monitoring one or more events indicative of potential updates to data associated with any of a set of monitored addresses in a simulated address space and making monitor reporting indications accessible to the target code indicative of whether any of the one or more events has occurred for at least one of the set of monitored addresses, wherein in response to a set exclusive status instruction in the target code specifying a given address in the simulated address space: The instruction decode program logic is configured to control the host data processing apparatus to set an exclusive status associated with a given address, and the computer program includes exclusive status clear program logic for clearing the exclusive status associated with the given address in response to detecting an event indicative of a conflicting memory access to the given address within the simulated address space, and in response to a monitor exclusive instruction in the target code, the instruction decode program logic is configured to control the host data processing apparatus to determine whether an exclusive status is associated with a target address within the simulated address space, and, if it is determined that an exclusive status is associated with the target address, assign the target address to be one of a set of monitored addresses for which one or more events are monitored by the monitor program logic.

[0006] The computer program may be stored in a computer-readable storage medium, which may be a non-transitory storage medium. [Brief explanation of the drawings]

[0007] Further aspects, features, and advantages of the present technique will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates a schematic diagram of an example data processing system having a plurality of requestor devices and an interconnect for coupling the requestor devices and controlling access to a shared memory by the requestor devices. [Figure 2] 1 illustrates an example of a processing element that functions as one of the requester devices and includes address monitoring circuitry. [Figure 3] 1 shows the processing of a load exclusive instruction. [Figure 4] Indicates clearing of exclusive status. [Figure 5] 1 shows the processing of a store exclusive instruction. [Figure 6] Several variations of monitor exclusive commands and methods for processing monitor exclusive commands are presented. [Figure 7] Indicates that potential updates to data associated with the set of monitored addresses are to be monitored. [Figure 8] 1 illustrates an alternative address tracking structure for use in address monitoring. [Figure 9] 1 illustrates an alternative address tracking structure for use in address monitoring. [Figure 10] Two variations of the monitor polling command and a method for processing the monitor polling command are shown. [Figure 11] The processing of the monitor polling command is shown in more detail. [Figure 12] An example of a simulation is shown below.

[0008] The apparatus may have an instruction decoder for decoding instructions and processing circuitry for performing data processing in accordance with the instructions decoded by the instruction decoder. The instruction decoder and processing circuitry may support instructions defined according to a particular instruction set architecture (ISA).

[0009] A monitoring circuit may be provided to monitor one or more events indicative of potential updates to data associated with any of the set of monitored addresses. The monitoring circuit may make accessible to software executing on the processing circuit a monitoring report indication indicating whether any of the one or more events has occurred for at least one of the set of monitored addresses. Such a monitoring circuit may be useful because it allows the software to identify whether a monitored address has been updated without having to explicitly poll the particular address by repeatedly issuing read requests to the monitored address. The monitoring circuit may have circuit logic implemented in hardware that can monitor for relevant events that may indicate potential updates to one of the set of monitored addresses and provide monitoring report information to the software when such an event occurs. The set of monitored addresses may be configurable by software, allowing more than one address to be designated as the monitored set, and thus not limited to monitoring only a single address.

[0010] In systems with monitoring circuitry, there may be some performance overhead associated with software configuring a set of monitored addresses to control which addresses should be monitored by the hardware-provided monitoring circuitry. For example, software may be monitoring updates to a number of queues stored in memory, but not all queues may need to be monitored at a given time; in some cases, the software may need to evaluate specific status information about each queue, such as whether the queue is active or ready to accept updates, to determine whether the queue needs to be monitored. The software may need to prevent potential updates to the status information between the time the status information is read and the time it is determined whether to monitor the corresponding address. It will be understood that this example of monitoring queues and checking status information is just one potential use case that software may implement (there are others), and illustrates an exemplary scenario in which there may be some overhead in establishing a set of monitored addresses to be monitored for updates.

[0011] In the example described below, the instruction decoder and processing circuitry support processing of a monitor exclusive instruction. The monitor exclusive instruction may be an instruction defined by an ISA supported by the instruction decoder and processing circuitry. In response to the instruction decoder decoding the monitor exclusive instruction, the processing determines whether an exclusive status is associated with the target address, and if it is determined that an exclusive status is associated with the target address, assigns the target address to be one of a set of monitored addresses that are monitored for one or more events by the monitoring circuitry.

[0012] An exclusive status can be set for a particular address by executing a set exclusive status instruction. In response to the instruction decoder decoding a set exclusive status instruction specifying a given address, the processing circuitry may set the exclusive status associated with the given address. In response to detecting an event indicating a conflicting memory access to the given address, the processing circuitry may clear the exclusive status associated with the given address. Detection of such an event indicating a conflicting memory access can be implemented in hardware and does not necessarily include an explicit software instruction executed by the process that executed the set exclusive status instruction. The set exclusive status instruction allows software to set the exclusive status for a particular address, so that the subsequent instruction can check whether a conflicting memory access occurred during the period between the set exclusive status instruction and the subsequent instruction. However, in practice, processors that support such exclusive status setting instructions may often limit the exclusive status to being set for a relatively small number of addresses (possibly only a single address), so exclusive status alone may be insufficient to address multi-address monitoring use cases where the number of addresses to be monitored for changes may be large (e.g., 50-100 or more), and thus monitoring circuitry may be more appropriate for problems involving multiple addresses being monitored. Nevertheless, supporting assigning exclusive status to addresses may be useful for supporting monitoring exclusive instructions that can improve the ease of configuring the set of monitored addresses to be monitored by the monitoring circuitry.

[0013] Thus, in response to a monitor exclusive instruction, a check is made to see if an exclusive status is associated with the target address, and if it is determined that an exclusive status is still associated with the target address (indicating that there have been no conflicting memory accesses to that target address since the exclusive status was assigned), the target address is assigned to be one of a set of monitored addresses that are monitored for one or more events by the monitor circuitry. This is useful for allowing status information checks (to determine whether a target address should be monitored) to be implemented atomically, even if they require more complex checks that cannot be performed in a single instruction.

[0014] For example, before assigning a particular address to the set of monitored addresses, software may need to check the state of some information in memory. This may be done by loading data from a particular address and checking the data using a sequence of one or more instructions, and then, if the state of the data is as expected, monitoring may begin by assigning that address to the set of monitored addresses. However, to avoid race conditions (where the data at the address being checked is updated by another process or device between reading the address and determining the result of checking that address), these operations may need to be performed atomically. This may be relatively simple if the check is simply a single comparison of the data against a known value, in which case a single instruction may be able to load the address, compare it, and, if the comparison matches, assign it to the set of monitored addresses. However, the inventors have recognized that in practice, software may need to test more than a single comparison condition associated with an address, for example, potentially testing multiple elements in different parts of the addressed memory location or applying a comparison condition more complex than just a single equality comparison; thus, this may require two or more instructions to evaluate whether the condition required to assign an address to the set of monitored addresses is met. The support for the monitor exclusive instruction described above means that a sequence of code comprising a set exclusive status instruction, followed by several instructions to implement the check, followed by a monitor exclusive select, can atomically check the data, perform the required comparison operation and, if successful, promote the target address to the set of monitored addresses being tracked by the monitor circuitry, thereby allowing software to implement arbitrarily complex comparison conditions while still avoiding race conditions by being able to perform the check atomically.Therefore, providing ISA support for monitor-exclusive instructions can make the configuration of the set of monitored addresses easier to manage for software, while still allowing arbitrarily complex test conditions and providing support for atomic operations that avoid data race conditions.

[0015] There may be various ways for the monitoring circuit to implement monitoring for one or more events indicative of potential updates to data associated with any of the set of monitored addresses. In some cases, the monitoring circuit may reuse some functionality that may already be provided within a data processing system for managing coherency between caches in different requesting devices. Such a coherency scheme may require, for example, that when data at a particular address is accessed, specific coherency messages (e.g., memory access requests / responses or snoop requests / responses) be exchanged between a requester device and an interconnect, which may send snoop requests to other requester devices that, as necessary, maintain coherency between data cached for the same address at different locations within the system. In some cases, the monitoring for events by the monitoring circuit may be based on intercepting several snoop messages exchanged within the system and detecting from the snoop messages / responses when a given address is potentially being updated. Alternatively, the monitoring circuitry may monitor cache coherency state transitions in caches associated with the processing circuit to detect changes in cache coherency state that may be triggered by such snoop requests (rather than checking the snoop requests themselves). However, unlike conventional coherency mechanisms, any changes in the coherency state of data cached at a particular requester device, and any snoop messaging exchanged between different devices to maintain coherency, may be transparent to software executing on the processing circuit, such that the software is not notified when data cached at one device is accessed from another device; rather, the monitoring is performed by the monitoring circuitry, which may make monitor report indications accessible to the software executing on the processing circuitry that indicate whether any events have occurred for one or more of a set of monitored addresses.

[0016] For example, this monitor reporting indication may be an interrupt sent to interrupt processing currently running on the processing circuitry, so that the processing circuitry can execute instructions (e.g., one or more instances of the monitor polling instructions described below) to check which addresses may have been updated. It is not essential that the monitor reporting indication itself identify the specific one of the set of monitored addresses that encountered the event. In some cases, the sent interrupt may be a general interrupt indicating that an event has occurred for any one of the set of monitored addresses, without distinguishing which address encountered the event. Alternatively, another approach may provide the monitor reporting indication in the form of an interrupt that is also associated with specific status / syndrome information (e.g., stored in a software-accessible register and updated by the monitor circuitry when an event occurs for a monitored address) that can be checked to check which addresses had an update. Another example may not interrupt the processor when the event occurs, but may simply make available data in a software-accessible register that can at least indicate whether any of the set of monitored addresses encountered an update, and optionally also report which addresses were updated. It will therefore be appreciated that there are a variety of techniques by which the monitoring circuitry can make the monitoring reporting indications accessible to software.

[0017] In some cases, an event detected by the monitoring circuitry may indicate that data associated with one of the monitored set of addresses has been updated, but may also include events that may be false-positive events that may be detected on other occasions even if the data has not actually been updated. Thus, an event detected by the monitoring circuitry may be any event that may indicate, at least on some occasions, that there is a risk that the data may have been updated. It is not necessary for the monitoring circuitry to actually detect whether the data has been reliably updated. For example, occasionally the monitoring circuitry may detect a cache entry invalidation (or a change in the coherency state of a cached entry) that may have occurred due to a snoop request sent as a result of a request from another requester device that has not yet updated the corresponding data but may only be priming the system to ensure that no conflicting copies of the data remain in other caches (e.g., preparing other requester devices for exclusive access to the data so that multiple subsequent updates can be performed more efficiently by not having to check the coherency status of other caches). On other occasions, the invalidation or coherency state transition of the same cache entry may be caused by an actual update. Thus, such invalidations or coherency state transitions may be examples of events that indicate a potential update, but may be false positives since the update may not have occurred yet.

[0018] In response to the instruction decoder decoding the monitor exclusive instruction, the processing circuitry may return a monitor allocation status indication accessible to software that indicates whether the target address was successfully assigned to become one of the set of monitored addresses in response to the monitor exclusive instruction, which may be useful for the software to determine whether it needs to retry the operation to assign the target address to the set of monitored addresses.

[0019] If the allocation of the target address to become one of the set of monitored addresses fails, the monitor allocation status indication may indicate the reason for the allocation failure. For example, the monitor allocation status indication may distinguish between at least two of the following reasons: exclusive status is no longer set for the target address, exclusive status is set for an address other than the target address, and the monitor circuitry is unavailable or not yet configured to accept assignment of an address to the set of monitored addresses. For example, the monitor allocation status indication may be a multi-bit indicator with one encoding assigned to indicate a successful allocation and multiple other encodings corresponding to different reasons for failure. Distinguishing between the different reasons can help software determine how to proceed.

[0020] In some examples, the monitor allocation status indication may be made accessible to software by writing it to a software accessible register, which may be a destination register specified by a register field of the monitor exclusive instruction, or may be a default register that is implicitly assumed to be the register to use for writing the monitor allocation status indication without an explicit register field identifying that register being specified in the instruction encoding of the monitor exclusive instruction.

[0021] The target address may be specified by the monitor exclusive instruction in various ways. In one example, the monitor exclusive instruction itself specifies the target address. For example, the encoding of the monitor exclusive instruction may include operand information for identifying the target address. For example, the monitor exclusive instruction may specify a register specifier that identifies an architectural register that provides address information for determining the target address.

[0022] However, in other examples, the monitor exclusive instruction need not itself identify a target address; instead, the target address may be implicitly identified as being the address designated as the given address by the most recent set exclusive status instruction prior to the monitor exclusive instruction. For example, circuit logic for tracking the exclusive status associated with a particular address may maintain an indication of the address at which the exclusive status was most recently set, and then, when a monitor exclusive instruction is encountered, this address may be assumed to be the target address of the monitor exclusive instruction. The indication of the most recently set exclusive address tracked by the exclusive status tracking hardware need not explicitly identify the address itself (although this is one option). Another option is to identify the address via other information associated with the address, such as information identifying a particular cache entry that caches data associated with the address. While the ISA definition of the monitor exclusive instruction may specify that the target address is the most recent address at which the exclusive status was set by a previous set exclusive status instruction, it will be understood that the specific manner in which the processing circuit hardware tracks which address was the most recent address with exclusive status may vary in an implementation-specific manner.

[0023] An advantage of implicitly defining the target address as the given address specified by the most recent exclusive status setting instruction is that it frees up bit space that can be used for other purposes in the encoding of the monitor exclusive instruction. Instruction encoding space can be at a premium in many ISAs, and therefore encoding efficiencies can be valuable even if they save only a relatively small number of bits. For example, by not having to encode a register field corresponding to the target address, the encoding of the monitor exclusive instruction can support a register field for specifying other information.

[0024] In some examples, when the instruction decoder decodes the monitor exclusive instruction and determines that an exclusive status is associated with the target address, the processing circuitry may assign an identifier value specified as an operand of the monitor exclusive instruction to an entry in the identifier storage structure corresponding to the target address. For example, the identifier value may be specified as an immediate value in the encoding of the monitor exclusive instruction or may be read from a register identified based on a register field specified in the encoding of the monitor exclusive instruction. This allows software to assign an identifier value (arbitrarily selected by software) to represent a target address that is assigned to the set of addresses to be monitored.

[0025] This can be useful because in many processing systems, software configuring the monitoring can identify a particular data structure in memory using a virtual address; however, monitoring can also be based on physical addresses, for example, because the monitoring can reuse information from coherency messages that identify addresses using physical addresses corresponding to particular locations in the memory system. In many systems, there may not be an efficient mechanism for reverse address translation, which converts physical addresses back to virtual addresses; therefore, when the monitoring circuitry identifies that an update has occurred to a particular monitored physical address, it may be desirable to provide a mechanism by which the monitoring circuitry can identify to software some information that enables the software to identify which monitored address was the address in the monitored set that encountered the event. For example, the software-assigned identifier may identify one of multiple queues in the monitored memory, or it may be an array index used by the software to identify an element in an array structure (the exact meaning of the identifier is up to the software and is not a feature of the processor architecture or hardware of the data processing apparatus).

[0026] Thus, when the monitoring circuitry detects that any of one or more events has occurred for a given monitored address, the monitoring circuitry can make accessible to software an indication of the identifier stored in the entry of the identifier storage structure that corresponds to the given monitored address at which the event occurred. This helps the software to identify which relevant locations in memory have been updated without having to implement a reverse translation mechanism, which may be more costly in terms of circuit area and / or performance (depending on the extent supported in hardware or software).

[0027] The identifier storage structure can be implemented in different ways. In some cases, the identifier storage structure may include a dedicated address watchdog tracking structure with multiple entries, each entry for tracking information associated with a corresponding set of other addresses to be monitored. For example, the address watchdog tracking structure may be a dedicated structure implemented in hardware that is separate from the data cache. The address watchdog tracking structure may have entries large enough to accommodate software-defined identifiers associated with each monitored address. The address watchdog tracking structure may also track other information, such as whether any events have occurred for the monitored addresses in a particular entry.

[0028] However, in other examples, the identifier storage structure may comprise a data structure stored in memory. For example, the monitor exclusive instruction may specify a register field that can identify a register that provides a memory address that specifies information for identifying a base address of the identifier storage structure (the value in the register may be able to directly identify the base address or may identify other information from which the base address can be determined, such as another address from which the base address of the identifier storage structure depends at a fixed, implicitly-defined offset). In response to the monitor exclusive instruction, if the address allocation operation is successful, the processing circuitry can use the base address (and other information related to the target address, such as an offset derived from the target address or cache set / way information indicating the cache entry corresponding to the target address) to identify the address of an associated entry in the identifier storage structure to be updated with the identifier corresponding to the assigned target address.

[0029] By providing the identifier storage structure as a data structure stored in memory, hardware costs to support monitoring are lower because a dedicated storage structure for storing software-provided identifiers is not required in hardware. Note that the identifiers from the data structure representing the identifier storage structure may ultimately be stored in memory, but may be cached for faster access than the underlying memory. (In some cases, if cached in a write-back cache, it is not essential that the backing store in memory has been updated with the identifier when the monitoring circuitry later reads it back after an event occurs for the monitored address.) For example, the size of the identifier storage structure may be selected so as not to occupy the entire capacity of a level 1 (or subsequent level) data cache, such that there is room in the level 1 data cache for at least a portion of the identifier storage structure as well as a reasonable number of other data lines, such as cache lines corresponding to data at monitored addresses. An approach in which the identifier storage structure is a structure in memory (potentially cached) may be more efficient to implement in hardware.

[0030] The variation of the monitor exclusive instruction described above, which implicitly specifies the target address as a given address specified by the most recent set exclusive status instruction, may be particularly useful in allowing the identifier storage structure to be implemented as a memory-based structure, since by avoiding the need to specify the target address itself as an operand of the monitor exclusive instruction, space in the instruction encoding is freed up for other information, such as a register field for identifying an address for identifying the base address of the identifier storage structure.

[0031] As described above, the monitor report indication made accessible to software when an associated event occurs for a set of monitored addresses can have various forms, but in some cases the information provided may be relatively limited, for example, simply providing an indication that at least one event has occurred for any of the set of monitored addresses without specifically identifying more information about which addresses experienced the event. Therefore, in some implementations, it may be useful to support a monitor polling instruction that can provide more information about which addresses experienced an event. In response to the instruction decoder decoding the monitor polling instruction, at least one of the processing circuitry and the monitor circuitry may make monitor polling information indicating which of the set of monitored addresses experienced one or more events accessible to software. For example, the monitor polling information may be made accessible to software by writing to a destination register identified by the monitor polling instruction. The software may then include further instructions to process the monitor polling instruction using the destination register as a source register and then determine how to respond depending on which of the set of monitored addresses experienced the event.

[0032] In implementations in which the monitor exclusive instruction can specify a software-defined identifier that is assigned to the identifier storage structure upon successful address allocation as described above, the monitor polling information can also include an identifier value associated with at least one of the set of monitored addresses at which one or more events have been determined by the monitor circuitry to occur. Thus, the identifier value associated with the monitored address at which the event occurred need not necessarily be provided in the monitor report indication initially provided to notify software that the event has occurred, but may be provided in the monitor polling information made available to the software when the software subsequently executes the monitor polling instruction. To support this use case in implementations in which the identifier storage structure is a memory-based structure, a variation of the monitor polling instruction can specify information for specifying the base address of the identifier storage structure as one of its operands, similar to the monitor exclusive instruction that specifies information for identifying this base address as described above.

[0033] Another piece of information that may be included in the monitor polling information may be a count value indicating the number of addresses in the set of monitored addresses for which one or more events have occurred. In some cases, this count value may indicate the total number of addresses for which an event has occurred, or the number of remaining addresses in the set of monitored addresses for which one or more events have occurred and for which the software has not yet triggered the return of information about that particular address by executing a monitor polling instruction. For example, in some cases, the monitor polling information returned in response to a single instance of a monitor polling instruction may return information about a single monitored address at a time; therefore, if an event has occurred for more than one of the set of monitored addresses, this may require multiple instances of the monitor polling instruction to be executed to return identifiers or other information about the updated addresses for which the event occurred. For example, the software may include a loop that iterates for each monitored address for which an event has been determined to have occurred. Thus, by returning a count value indicating the total or remaining number of addresses for which an event has occurred that have not yet been checked, the count value can be used by the software to determine whether it is still necessary to perform further iterations of the monitor polling operation.

[0034] The set exclusive instruction may be any instruction capable of controlling the processing circuit to set an exclusive status for a given address. However, in one example, the set exclusive status instruction is a load exclusive instruction. In response to the instruction decoder decoding the load exclusive instruction, the processing circuit may load data associated with the given address into at least one destination register specified by the load exclusive instruction and set the exclusive status associated with the given address. Supporting a load exclusive instruction that sets the exclusive status and loads the data associated with the address whose exclusive status is set may be useful for supporting a set of atomic operations, such as those described above for configuring a set of monitored addresses, since separate instructions do not need to be issued to load data from the given address and mark the address as exclusive.

[0035] The type of instruction that uses the exclusive status that can be configured by the exclusive status setting instruction may not be limited to the monitor exclusive instruction. Another type of instruction supported by the ISA may be a store exclusive instruction that specifies a store target address and at least one source register. In response to decoding the store exclusive instruction by the instruction decoder, the processing circuitry may determine whether an exclusive status is associated with the store target address, and if so, store data from the at least one source register to a memory location associated with the store target address. Thus, the monitor exclusive instruction may reuse the same infrastructure for tracking exclusive status that may already be supported for processing load / store exclusive instruction pairs, and therefore may be implemented at relatively little additional cost compared to architectures that already support load / store exclusive instructions.

[0036] The above-described techniques may be implemented within a data processing apparatus having hardware circuitry provided for implementing the instruction decoder, processing circuitry, and monitoring circuitry described above. However, the same techniques may also be implemented in a computer program that runs on a host data processing apparatus to provide an instruction execution environment for execution of target code. Such a computer program may control the host data processing apparatus to simulate the architectural environment provided on a hardware apparatus that actually supports a particular instruction set architecture, even if the host data processing apparatus itself does not support that architecture. Thus, the computer program may include instruction decode program logic that decodes program instructions of the target code and controls the host data processing apparatus to perform data processing in accordance with the program instructions of the target code (e.g., mapping each instruction of the target code to a sequence of one or more instructions in the host's native instruction set that perform equivalent functionality). The instruction decode program logic may support the monitor exclusive instruction and the set exclusive status instruction, as described above. The instruction decode program logic may also support other instructions described above (e.g., a monitor polling instruction, a load exclusive instruction, and a store exclusive instruction). The computing program may also include exclusive status clearing program logic that clears the exclusive status in a manner equivalent to the clearing performed by the processing circuitry described above, and monitor program logic that corresponds to the functionality of the monitor circuitry described above. In the simulation program, the address space addressed by the target code may be in a simulated address space that may not be the same as the host address space used by the host processor, so that memory accesses may be emulated in a simulated manner. The simulation may also simulate registers defined by the simulated architecture using accesses to host storage (e.g., host registers or host memory) of the host processor.Such a simulation program is useful, for example, when legacy code written for one instruction set architecture is being executed on a host processor that supports a different instruction set architecture. Also, running software on a simulation execution environment can enable testing of the software in parallel with the ongoing development of hardware that supports the new architecture, so that simulation can enable software development of a new version of an instruction set architecture to begin before the hardware that supports the new architecture version is deployed. The simulation program may be stored on a storage medium, which may be a non-transitory storage medium.

[0037] FIG. 1 schematically illustrates an example of a data processing system 2 (e.g., an integrated circuit or system-on-chip) including multiple requestor devices 4, 6, and 8 and an interconnect 10 for managing coherency between data cached in caches 12 of the respective requestor devices. The interconnect 10 also controls access to a shared memory 14. As shown in FIG. 1, there may be two or more memory modules 14 coupled to the interconnect 10 that can be accessed by any of the requestor devices 4, 6, and 8. In this example, the requestor devices include one or more processing elements 4, 6, which are elements that support the execution of instructions defined according to a particular instruction set architecture (ISA). The processing elements 4, 6 may include one or more caches 12 (although FIG. 1 shows only a single cache for simplicity, a cache may be implemented as a multi-level hierarchy of caches). The processing elements 4, 6 may be, for example, central processing units (CPUs) for performing general-purpose processing or graphics processing units (GPUs) for performing graphics processing. The system may also include one or more requestor devices 8 that may not have their own cache 12, but may have direct memory access (DMA) to memory 14 so that they can issue requests to access memory without being explicitly controlled by the processing elements 4, 6. For example, the devices 8 may be input / output (I / O) devices such as a network interface controller (NIC) for controlling the transmission and reception of data over a network, a display controller for controlling the display of data on a screen, a direct memory access (DMA) controller for controlling the transfer of data between memory and peripheral devices, to name just a few.

[0038] Interconnect 10 is responsible for maintaining coherency among data cached in cache 12. A coherency protocol is used to define the rules governing how the system responds to an access by one requestor to a given address, and may ensure that subsequent accesses to the same address from other requestors see data that is consistent with the result of the request from the initial requestor. For example, a coherency protocol may define multiple coherency states that may be associated with data stored in cache 12 or in system cache 16 provided within interconnect 10 (system cache 16 is shared among requestors and provides faster access to data compared to having to retrieve the data from memory 14), as well as multiple request and response messages and protocols for when various types of messages should be generated. For example, when one processing element 4 initiates a request to read or write data from a particular address in its cache 12, depending on the current coherency state, this may trigger various requests to the interconnect, which may, if necessary, send snoop requests to caches 12 in other requesters to inquire about the coherency state of the data in that requester's cache, or, if necessary, trigger invalidation of data from that requester's cache. In some cases, the interconnect may have a snoop filter (which may be combined with system cache 16, as shown in FIG. 1, but may also be a separate element) that at least partially tracks which requesters have cached data from a given address and allows some snoop traffic to be filtered out if a requester's cache 12 is known not to have cached data from a particular address. Any known coherency protocol may be used to maintain coherency.Examples of coherency protocols that may be used are the AMBA® 4 ACE and AMBA® 5 CHI coherency protocols provided by Arm® Limited of Cambridge, UK, although it will be appreciated that other coherency protocols may also be used to maintain coherency.

[0039] In a system such as that shown in FIG. 1 , interactions between different requesters may be performed by accessing a shared data structure in the memory system. For example, if device 8 is a network interface controller, as data is received from the network, queues of data may be updated based on the received packets. Software running on one of the processing elements 4, 6 may need to check these queues to see if there is available data to be processed and, if so, to perform corresponding actions. If the number of queues being monitored is not particularly large, it may be feasible for the software to simply periodically execute a load instruction to read the addresses in memory mapped to each queue and check if anything has changed that requires processing. However, the number of queues being monitored may be large, e.g., more than 100, and therefore such polling of addresses in memory may incur significant overhead. The following example describes an address monitoring function that may be supported in the hardware implementation architecture of the processing elements 4, 6 to reduce the performance and power costs of monitoring addresses in memory to check if they have been updated. By providing some hardware that can be configured by software to monitor updates to specific addresses so that an indication is provided to software when any of those addresses are updated, this avoids the software having to explicitly read those addresses repeatedly. If there is no other processing to be performed, this allows the processing elements 4, 6 to enter a power-saving mode for a period of time, waiting for an event to be reported when one of the monitored addresses is updated, thereby saving power, which would not be possible if the software had to keep issuing explicit read requests to access locations in memory corresponding to the monitored addresses.

[0040] Although Figure 1 shows a scenario in which software running on a processing element 4, 6 is waiting for a data structure to be updated by another requester device 8 such as a network controller, similar address monitoring issues can arise when multiple software processes running on the same processing element 4, 6 are communicating using updates to data at addresses in shared memory 14, and therefore it is not necessary that the monitoring be for changes by another requester device.

[0041] Figure 2 shows features of one of the processing elements 4, 6 in more detail. It will be appreciated that it is not necessary for all of the processing elements 4, 6 in a system to have the same design; for example, it is possible to provide an asymmetric multiprocessor system that includes processing elements that support the same ISA but have different microarchitecture implementations. Thus, it is not necessary for all processing elements to have the features shown in Figure 2. For example, it is not necessary for all processing elements to include address monitoring circuitry 36.

[0042] Each processing element 4, 6 includes an instruction decoder 20 for receiving program instructions (defined according to a particular instruction set architecture) fetched from memory 14 or from an instruction cache (not shown in FIGS. 1 and 2 , but which may be provided within the processing element). The instruction decoder 20 decodes the fetched instructions and generates control signals for controlling processing circuits 22 to perform the operations represented by the instructions. The processing circuits 22 have access to registers 24 that may be used to store operands of the instructions and results of instructions processed by the processing circuits 22. The processing circuits 22 may include multiple execution units for executing different types of instructions, such as an arithmetic / logic unit (ALU) for executing arithmetic or logical instructions, or a branch unit for executing branch instructions. For simplicity, different types of execution units are not shown in FIG. 2 , except for a load / store unit 26 for executing load instructions for loading data from a memory system (including main memory 14 and any caches 12, 16) into a register 24 or store instructions for storing data from a register 24 into the memory system 12, 14, 16. A memory management unit 28 may be provided to provide memory protection and / or address translation functions to control which addresses within the memory address space are permitted to be accessed by particular software executing on processing circuitry 22, and / or to manage the translation between virtual addresses specified by the software and physical addresses used to identify locations within the memory system. While Figure 2 shows a single data cache 12 as an example of a processing element's cache, it will be appreciated that multiple levels of cache may be dedicated to a particular processing element, such as a level 1 data cache and a level 2 cache (or additional levels of cache). Thus, reference to cache 12 may include a multi-level cache hierarchy.

[0043] The processing element has exclusive status tracking circuitry 30 for tracking the exclusive status associated with a particular address. The address selected for exclusive status may be selected by executing an exclusive status setting instruction (e.g., a load exclusive instruction as described below with respect to FIG. 3) on processing circuitry 22. When an exclusive status setting instruction is executed specifying a given address, a tracked address indication 32 indicating the given address is stored, and an exclusive status indication 34 is set to indicate that the given address indicated by tracked address indication 32 has exclusive status. Thereafter, exclusive status tracking circuitry 30 monitors for events that may indicate a conflicting memory access to the tracked address, and when one of such events is detected, the exclusive status is cleared by changing the state of exclusive status indicator 34. A particular instruction may test whether the tracked address is still indicated as having exclusive status and may control processing circuitry 22 to perform an operation that is conditional on whether the address remains indicated as having exclusive status. This can be useful to ensure that a particular sequence of instructions is executed atomically between the first operation with the tracked address and any subsequent operations, which can be useful to avoid data race conditions when multiple requestors make conflicting accesses to an address in memory, which can have the effect of one of those accesses being lost or one of those accesses accessing potentially out-of-date data.

[0044] However, the exclusive status tracking circuit 30 may be relatively limited in the number of addresses it can monitor, e.g., limited to tracking a single address at a time. Therefore, an address monitoring circuit 36 ​​is also provided to perform monitoring of a wider set of monitored addresses and report to software when one of the previously configured set of monitored addresses encounters an event indicating a potential update to the data at that address. For example, as shown in FIG. 2 , the address monitoring circuit 36 ​​may send an interrupt signal to the processing circuit 22 to interrupt currently executing processing (or, if the processing circuit was in a power-saving state, the interrupt may wake up the processing circuit), so that software can respond to the interrupt by identifying which address changed state and executing instructions to perform subsequent processing based on which address was updated. This may be useful for supporting the queue monitoring use case discussed above, but may also be used for other purposes. The address monitoring circuit 36 ​​is described in more detail below, but exclusive status tracking will first be described in more detail.

[0045] FIG. 3 illustrates the processing of a load exclusive instruction LDXR, which is an example of an exclusive status setting instruction. The load exclusive instruction specifies a destination register Xd and an address operand register Xn that stores a value indicating a given address. In step S100 of FIG. 3, the instruction decoder 20 decodes the load exclusive instruction. In response to the load exclusive instruction, the instruction decoder controls the processing circuit 22 to execute the subsequent steps of FIG. 3. In step S102, the processing circuit sets an exclusive status associated with the given address. For example, the tracking address indication 32 may be updated to specify information that enables the given address to be identified, and the exclusive status indicator 34 may be set to a specific value that indicates the existence of an exclusive status. In some cases, the tracking address indication 32 may be updated to specify a physical address corresponding to the given address. However, the tracking address indication may also indirectly identify the given address by, for example, identifying a specific entry in the data cache 12 associated with the data of the given address. For example, the tracking address indication 32 may be information specifying a cache set / way identifier for identifying an associated entry in a cache implemented using a set-associative allocation policy. Such a format for the tracking address indication may, in some implementations, be easier to compare with information returned from a cache when a snoop or coherency state transition is detected for a particular address to identify whether the exclusive status needs to be cleared. While the encoding of the load-exclusive instruction and the exclusive status setting operation represented by that instruction may be specified in the ISA supported by the processing system, it will be understood that the exact format of the exclusive status tracking information 32, 34 used to track whether the exclusive status is set for a particular address may not be prescribed by the architecture and may vary from implementation to implementation. Thus, the exact format of the information 32, 34 is not a required feature.In general, any information can be stored that would allow the system to determine whether the exclusive status is still set for a given address.

[0046] In step S104, in response to the load-exclusive instruction, load / store unit 26 of processing circuitry 6 performs a load operation to load data associated with the given address from cache 12 or memory 14 into a destination register identified based on the register specifier Xd specified in the load-exclusive instruction. While steps S102 and S104 in Figure 3 are shown in sequence, it will be understood that other implementations may perform these steps in the reverse order or in parallel.

[0047] 3 shows a load exclusive instruction as an example of an exclusive status setting instruction. Some ISAs may also support an exclusive status setting instruction that allows exclusive status to be set for an address without triggering a load of data associated with the target address.

[0048] 4 shows steps performed by exclusive status tracking circuit 30 to maintain exclusive status indicator 34 while monitoring for events that may indicate a conflicting memory access. In step S110, exclusive status tracking circuit 30 detects whether an event has been detected that indicates a conflicting memory access may have occurred for a given address indicated by tracked address indication 32 for which exclusive status has been set. For example, this event may be the detection of a snoop request received from interconnect 10 indicating that another requestor has requested to write data to a location associated with the given address, or has requested the invalidation or clearing of any cached data from cache 12 that may be cached associated with the given address. Additionally, an event indicating a conflicting memory access may be the invalidation of a cache entry in data cache 12 associated with a given address (which may potentially be triggered by a snoop from another device that may update the data at that address), or a particular transition in the coherency state of the cache entry associated with a given address (e.g., a transition from an “exclusive” coherency state to a “shared” or “invalid” coherency state, where an “exclusive” coherency state indicates that the corresponding cached data may be updated by the requester owning that cache without issuing a snoop to the interconnect to check whether there is corresponding cached data in other caches 12, a “shared” coherency state indicates that the corresponding cached data is valid, but that the requester owning this cache must send a message to interconnect 10 to enable it to check whether other requesters hold the corresponding data before updating the cached data, and an “invalid” coherency state indicates that the cache does not hold valid data for the corresponding address).Note that the “exclusive” coherency state referred to herein refers to one of a set of coherency states defined according to the coherency protocol used by interconnect 10 and caches 12, 16, which is orthogonal to the exclusive status indicated by exclusive status tracking circuitry 30. Thus, a cache entry may be marked as having an exclusive coherency state even if the corresponding address is not tracked as exclusive by exclusive status tracking circuitry 30. Similarly, an address may be tracked as exclusive by exclusive status tracking circuitry 30 even if the corresponding cache data in cache 12 is not marked as having an exclusive coherency state.

[0049] If such an event indicating a conflicting memory access to a given address for which the exclusive status is set is detected in step S110, then in step S112 the exclusive status tracking circuit 30 clears the exclusive status of that address by toggling the state of the exclusive status indicator 34. This allows the processing circuit to determine that for any subsequent instruction having an encoding indicating that the operation is performed conditional on the exclusive status still being set, that operation should not be performed. This means that the execution of the conditional operation may depend on there having been no intervening memory access to the given address since the load exclusive instruction or other exclusive status setting instruction, which may be useful for implementing an atomic set of operations. It will be appreciated that an event indicating a conflicting memory access may not be the only type of event that can lead to the exclusive status being cleared for a tracked address. Because exclusive status tracking circuit 30 may only have a finite capacity to track exclusive status for a limited number of addresses (e.g., only a single address in the example of FIG. 2), executing another load-exclusive instruction that specifies a different address may clear the exclusive status for the previously tracked address by overwriting the indication 32 of the previously tracked address with an indication for the new address. Also, if an interrupt or exception occurs, this may cause exclusive status tracking circuit 30 to clear the exclusive status of the previously tracked address. Thus, there may be other events other than a conflicting memory access to the tracked address that cause the exclusive status to be lost.

[0050] 5 illustrates the processing of a store exclusive instruction STXR, which may be used by software to request that processing circuitry 22 execute a store operation to store data at a memory system location 12, 14, 16 identified by a store target address, the store being conditional on the store target address still being identified as exclusive by exclusive status tracking circuitry 30. In step S120, instruction decoder 20 decodes the store exclusive instruction. The store exclusive instruction specifies a destination register Xd, a source register Xs, and an address operand register Xn. The address operand register stores a value that can be used to determine the store target address. In response to the store exclusive instruction, in step S122, processing circuitry 22 is controlled to determine whether the exclusive status is still associated with the store target address. Thus, to determine whether the tracked address matches the store target address, information in tracked address indication 32 may be compared with information derived from the store target address, and exclusive status indicator 34 is also checked to determine whether it has a value indicating that the exclusive status is set. If the exclusive status is set and the store target address matches the address for which the exclusive status is set, then in step S124, load / store unit 26 continues with the store operation, storing the data from source register Xs into the memory location associated with the store target address. In step S126, the exclusive status for the store target address is cleared, and in step S128, destination register Xd is set to a status value indicating that the store operation was successful.In contrast, if it is determined in step S122 that the store target address is not set as exclusive (e.g., if the store target address does not match the tracking address indicated by the tracking address indication 32 or if the exclusive status indicator 34 is cleared), then in step S130 the store operation is omitted and in S132 the destination register Xd is set to a status value indicating that the store operation failed.

[0051] The status value written to destination register Xd can therefore be used by software to determine whether the store was successful and therefore whether the store needs to be retried (and possibly previous operations as well), or whether processing can continue beyond the store. This can be useful to allow a set of atomic operations to be defined, bounded by load-exclusive and store-exclusive instructions, to ensure that a store can only occur if there have been no intervening memory accesses since the load.

[0052] The exclusive status tracked by the exclusive status tracking circuit 30 may also be used for a monitor exclusive instruction, which may be used to allow software to configure the address monitoring circuit 36 ​​to monitor updates to a particular address. Figure 6 shows three alternative variations of the monitor exclusive instruction MONX. Different implementations may support different options, and therefore, any one or more of these variations may be supported in a given implementation.

[0053] In a first variation, the monitor exclusive instruction MONX specifies a destination register Xd that is updated with a status indication. Like the store exclusive instruction described above, the status indication may provide an indication of whether the monitor exclusive operation was successful, but unlike the store exclusive instruction described above, with the monitor exclusive instruction, the status indication may do more than just provide a binary indication of pass / fail, but in the event of failure, may provide information regarding the reason for the failure, potentially distinguishing between two or more different possible reasons for failure. In variation 1, the monitor exclusive instruction also specifies a register field that identifies an address register Xn that stores information for determining target addresses that are sought to be assigned to the set of monitored addresses tracked by the monitor circuit 36.

[0054] In variant 2, the destination register Xd and address register Xn are the same as variant 1, but the monitor exclusive instruction also specifies an additional source register Xs that can be used to provide a software-defined identifier value that can be assigned to an identifier structure, so that when the monitor circuitry 36 identifies that data has been updated for a monitored address, a software-defined identifier can be returned so that software can identify which address has changed.

[0055] Variant 3 of monitor exclusive instruction MONX specifies destination and source registers Xd, Xs as in variant 2, but in variant 3, the address indicated using address register Xn indicates information for identifying the base address of an identifier storage structure used to track software-defined identifiers (as further described below with respect to FIG. 9 ) instead of indicating the target address itself. In this example, the target address assigned to the set of addresses to be monitored is not encoded in the monitor exclusive instruction itself, but instead is implicit and defined as the address specified by the most recently executed exclusive status setting instruction (e.g., the address specified by the most recent load exclusive instruction in the same thread as the monitor exclusive instruction). For example, the target address may be identified based on the tracked address indication 32 identified by exclusive status tracking circuit 30.

[0056] The flowchart of Figure 6 illustrates the processing of any of three variations of the monitor exclusive instruction MONX. In step S150, the instruction decoder 20 decodes the monitor exclusive instruction and generates signals to control the processing circuitry 22 and other elements of the system, such as the address monitoring circuitry 36 or the exclusive status tracking circuitry 30, to perform the operations shown in the remaining steps of Figure 6.

[0057] In step S152, in response to the monitor exclusive instruction, the processing circuit determines whether an exclusive status is associated with the target address associated with the monitor exclusive instruction. In variants 1 and 2, the target address is identified based on the value stored in the address operand register Xn specified by the monitor exclusive instruction. In variant 3, the target address is a given address specified by the most recent exclusive status setting instruction. Therefore, in variant 1 or 2, a comparison may be performed between the tracked address indication 32 and the target address of the monitor exclusive instruction to check whether they match, and the exclusive status indicator 34 may be checked to determine whether the target address has an exclusive status. In variant 3, it may be implied that the target address of the monitor exclusive instruction matches the most recently tracked exclusive address, and therefore, in variant 3, checking the exclusive status indication 34 may be sufficient without an address comparison. In any event, once it is determined that an exclusive status is associated with the target address associated with the monitor exclusive instruction, in step S154 the processing circuitry also determines whether the monitor circuitry 36 is available and configured to accept assignment of addresses to the monitor's set of addresses. Some systems may support the address monitor circuitry 36 being disabled or powered down to conserve power, and thus the address monitor circuitry 36 may not always be available. Also, in some cases, certain control parameters may need to be set up before the address monitor circuitry 36 can be used, and therefore, if this has not yet been done, the monitor circuitry may not yet be configured to accept assignment of addresses to the monitored set of addresses.

[0058] If it is determined in step S154 that the monitoring circuitry is available and configured to accept assignment of an address to the set of monitored addresses, then in step S156 an address assignment operation can be performed, and the target address can thus be assigned to be one of the set of monitored addresses for which address monitoring is performed by the address monitoring circuitry 36. If the monitoring exclusive instruction is variant 2 or 3, then in step S158 the processing circuitry also assigns an identifier value read from the instruction's source register Xs to an entry in the identifier storage structure corresponding to the target address. As will be described below with respect to FIGS. 8 and 9, there may be various ways to implement this identifier storage structure. Also, if the address assignment operation can be performed, in step S160 the exclusive status tracked by the exclusive status tracking circuitry 30 is cleared for the target address (because the monitoring exclusive instruction has completed the set of atomic operations managed using the exclusive status indication). Also, in step S162 the instruction's destination register Xd is set to the monitoring assignment status indication, indicating that the address assignment operation was successful.

[0059] On the other hand, if in step S152 it is determined that the target address does not have exclusive status, or if in step S154 the monitor circuitry was unavailable or not configured to accept address allocation, then in step S164 the address allocation operation is omitted, and therefore none of steps S156, S158, S160, and S162 are performed; instead, in step S166, the destination register Xd is set to a monitor allocation status indication having a different value indicating that the address allocation operation failed.

[0060] In some cases, the monitor allocation status indication may be a single-bit value that may have one value (e.g., 0) indicating a successful address allocation operation and another value (e.g., 1) indicating an unsuccessful address allocation operation.

[0061] However, if the address allocation operation cannot be performed, it is also possible to provide a multi-bit allocation status indication that may provide more information regarding the reason for failure. For example, if the monitor allocation status indication is set to 0, this may indicate a successful address allocation operation, while a non-zero value may indicate various reasons for failure. For example, if the address allocation operation failed because it was determined that no exclusive status was associated with the target address, the monitor allocation status indication may be set to 1, while more than one monitor allocation status indication may be used for other reasons, such as the monitor circuit being determined to be unavailable or not configured in step S154, or, in the case of variants 1 or 2, the target address of the monitor exclusive instruction not matching the address tracked by the tracked address indication 32 of the exclusive status tracking circuit 30. Of course, other encodings of the monitor allocation status indication may also be used.

[0062] 6 depicts a sequential sequence of steps, it will be understood that steps may be reordered or performed in parallel. For example, steps S152 and S154 may be swapped or performed in parallel. Also, the various operations in steps S156, S158, S160, and S162, which are performed upon a successful allocation operation, may be performed in any order, or with two or more of these steps in parallel.

[0063] This monitor-exclusive instruction can be useful for enabling software to perform more complex checks than simply comparing a single value at a given address to determine whether a particular address within a set of monitored addresses requires monitoring. For example, this can be useful for testing multiple elements of a data structure to determine whether a particular software queue in memory requires monitoring. Such more complex checks can require relatively flexible comparison operations that may not be able to be performed in a single instruction. Thus, if data needs to be read from memory to perform the check, a challenge can arise as to how to perform those comparisons atomically, since the resulting conclusion may be reliable only if other requesters have updated some of the relevant data in the meantime by the time the check is completed.

[0064] Thus, by defining instruction set architecture support for the monitor exclusive instruction described herein, software can define the following sequence of code: The load-exclusive instruction discussed above can be used to load the data to be checked and mark the associated address as exclusive. One or more further instructions may be implemented to define the associated comparison operation. For example, this may include various arithmetic, logical, or comparison instructions. If the comparison operation is successful, a monitor exclusive instruction may be used to promote the address associated with the load exclusive operation to the address monitor implementation 36, provided that the address is still marked as having exclusive status.

[0065] The monitor exclusive instruction need not be the only instruction supported by the instruction decoder 20 and processing circuitry 22 for assigning addresses to the set of monitored addresses. It may also be possible to support instructions that assign addresses to the monitored set regardless of whether the address has exclusive status, which can be used when setting the monitored address does not depend on a set of atomic operations that compare state data in memory.

[0066] 7 illustrates monitoring by the address monitoring circuit 36. In step S170, the monitoring circuit 36 ​​detects an event indicating a potential update to data associated with any of the previously configured sets of monitored addresses. For example, the event detected by the monitoring circuit may be the receipt of a snoop request from the interconnect 10 indicating that the coherency state of the monitored address should change from “exclusive” to either “invalid” or “shared,” or the detection of such a coherency state transition in the cache 12. In response to detecting the event, in step S172, the monitoring circuit sets information indicating which of the set of monitored addresses encountered the event detected in step S170. For example, as described below, the address monitoring circuit 36 ​​may maintain a data structure in hardware or using data stored in memory that tracks which of the set of monitored addresses encountered the event. In step S174, the address monitoring circuit 36 ​​makes monitoring report information indicating that the event occurred accessible to software executing on the processing circuit 22. For example, this may be the generation of an interrupt that may cause processing circuitry 22 to wake up from a power saving state or switch to processing an interrupt handler, so that software that requires addresses to be monitored can respond to updates.

[0067] The interrupt indicated to indicate an event has occurred need not be generated every time the event occurs. For example, if an additional event is detected for one of the set of monitored addresses after an interrupt has already been generated but before the processing circuit has processed the interrupt and before the interrupt is cleared, a second interrupt may not need to be generated. Also, in some implementations, another mechanism may be used to notify software that an event has occurred for a monitored address other than generating an interrupt. For example, information may be stored in a register that can be read by software. However, an interrupt-based mechanism may be useful to allow processing circuit 22 to use a “wait for event” instruction that signals that processing circuit 22 should enter a power-saving mode until an interrupt is received indicating that an event has occurred for one of the monitored addresses. This may be useful when processing circuit 22 does not have other functional processing to perform until an event occurs for one of the monitored addresses.

[0068] 8 and 9 show different ways of implementing the address monitoring circuitry 36 and various structures for tracking the addresses being monitored. It will be understood that these are just two examples, and there may be other ways of structuring the information for tracking which addresses are being monitored and which of those addresses have experienced an event.

[0069] 8 illustrates a first approach that may be used for implementations that use variants 1 or 2 of the monitor exclusive instruction, where there is no support for specifying an address in memory to provide a metadata structure for tracking information about the monitored addresses. Therefore, in the approach illustrated in FIG. 8, a dedicated buffer 200 may be provided in hardware to serve as an address tracking structure for tracking information about the monitored addresses. Address monitoring circuitry 36 may also use state information stored in data cache 12 to monitor updates to data associated with particular addresses.

[0070] In this example, data cache 12 includes multiple entries 13, each capable of caching data 210 from a particular address within the memory system. A tag value 212 may be stored with each entry to indicate information for identifying an address associated with the corresponding data, and a valid flag 214 may be provided within each entry to indicate whether the data is valid. Each entry 13 may also specify a coherency state 216, which is used to identify whether the data is clean or dirty, or, as described above, whether the data is in an exclusive or shared coherency state. In some cases, coherency state 216 and valid flag 214 may be combined into a single indicator (with "invalid" being considered one of the coherency states indicated by coherency state field 216).

[0071] As shown in Figure 8, each cache entry may also be provided with a "monitor" indication 218 that indicates whether the address associated with that cache entry is within a set of monitored addresses previously configured by execution of a monitor exclusive instruction or other instruction that assigns an address to the monitored set. Thus, in this example, when step S156 of Figure 6 is performed, this may include setting the monitor indication 218 in the cache entry corresponding to the data associated with the target address to indicate that the target address is within the set of monitored addresses.

[0072] The address monitoring circuit 36 ​​also maintains an address tracking structure 200 as a separate cache structure, separate from the data cache 12 itself, to track further information about each monitored address. For example, the address tracking structure may have a certain number of entries, each corresponding to a particular cache entry 13 designated as corresponding to a monitored address. The number of entries in the address tracking structure 200 need not be as large as the number of entries in the cache 12. Each entry in the address tracking structure may specify, for example, a cache entry identifier 220 that identifies the corresponding cache entry, a software identifier 222, which may be the identifier assigned to the identifier storage structure in step S158 of FIG. 6 for the corresponding address, and a “snoop” indication 224, which may indicate whether an associated event (e.g., a snoop-triggered coherency state transition) has been detected for the corresponding monitored address. The address monitoring circuit 36 ​​may also maintain a count value 230 that tracks how many addresses in the monitored set have encountered a snoop event indicating that the corresponding address has been updated.

[0073] Thus, when assigning an address to the set of addresses to be monitored, a corresponding monitor indication 228 may be set in the associated cache entry, and a software-defined identifier value may be assigned to the corresponding entry in address tracking structure 200. Field 220 of the associated address tracking structure entry may be set to, for example, cache set / way information that identifies the location of the corresponding cache entry in data cache 12. When variant 1 of the monitor exclusive instruction is executed, software identifier 222 need not be supported.

[0074] Meanwhile, when a snoop received from interconnect 10 is detected by control circuit logic 240 associated with a data cache, cache control logic 240 may check data cache 12 to determine whether there is a corresponding entry associated with the address specified by the snoop request (by comparing tag fields 212 of one or more cache entries). If the address specified by the snoop request matches a valid cache entry with monitor indication 218 set, indicating that the corresponding address is part of a set of monitored addresses, address monitor circuit 36 ​​generates an interrupt or other notification to software to indicate that an event has occurred and increments count 230 of the number of snooped addresses found in the monitored set. Address monitor circuit 36 ​​also updates snoop indication 224 in the entry of address tracking structure 200 that corresponds to the snooped monitored address. This allows a subsequent monitor polling instruction to check which particular address was snooped and obtain the corresponding software ID 222.

[0075] 8 may be useful for avoiding consuming space in memory for address tracking, but may require a hardware implementation to provide additional address tracking structures. Alternatively, although FIG. 8 shows address tracking structure 200 as separate from data cache 12, other implementations may provide additional fields in each cache entry 13 for tracking software ID 222 and snoop indication 224. In either case, this may require additional circuit hardware to be provided.

[0076] 9 shows an alternative approach in which the address watchdog data structure can instead be stored in the memory system itself (and cached in data cache 12, if necessary) so that this additional hardware structure 200 does not need to be provided. This can be supported in implementations that support the above-described watchdog exclusive instruction variant 3, which uses its address register Xn to identify information for specifying the base address 250 of an identifier storage structure 260 stored in the memory system. The identifier storage structure 260 can store a software identifier 222 for the corresponding watched address assigned by the watchdog exclusive instruction variant 3. The identifier structure 260 can include an identifier for each cache line in data cache 12, and indexing into this structure can use an offset relative to the base address determined based on the data cache 12 entry being snooped (or the entry to which the watched address is assigned, if the identifier 222 is stored in structure 260 when allocating an address for watching). The address monitoring circuitry 36 may also maintain a "snoop" bitmap 270 of "snoop" flags indicating whether each monitored address has been snooped or otherwise encountered an event requiring reporting to software as a further data structure 270 stored in memory, which may be stored at an address that may also be determined relative to the identifier store base address 250 specified for a given monitoring instruction. For example, the snoop bitmap 270 may continue contiguously from the end of the identifier store 160.

[0077] Thus, in this approach, data cache 12 itself may be implemented with fields similar to those shown in Figure 8, including a monitor field 218 that tracks whether a given cache line is being monitored. When a new address is assigned to a monitored set, in addition to setting the monitor field 218 of the associated cache entry, the cache set / way ID of that cache entry may be used to derive an offset to be added to the base address 250 of the identifier store, and the memory location whose address corresponds to the sum of that base address and offset may be updated with a software-provided identifier provided by the monitor exclusive instruction variant 3.

[0078] When cache controller 240 detects a snoop from interconnect 10 that causes a cache entry marked as being monitored to change its coherency state 216 from exclusive to either shared or invalid, this signals address monitoring circuitry 36, which (in addition to interrupting processing circuitry 22) increments count 230 of the number of snooped monitoring addresses by one and updates the associated snoop indicator in bitmap 270 to indicate the particular monitored address that was snooped. Again, the associated offset for identifying the flag in snoop bitmap 270 to be updated may be derived from the set and way of the cache entry corresponding to the snooped monitored address. When a monitor polling instruction, described further below, is executed to poll for information about any addresses that may have encountered an event, snoop bitmap 270 may be parsed to identify the location in identifier store 260 for which software identifier should be returned to software corresponding to the monitored address that encountered the event.

[0079] The approach shown in FIG. 9 means that it is not necessary to incur the circuit area costs of implementing a dedicated hardware structure for address tracking, such as structure 200 shown in FIG. 8. The size of the structure that needs to be stored in memory can be relatively small compared to the overall amount of data cached in data cache 12, so that there is space in data cache 12 to store address monitoring structures 260, 270 and also store a reasonable number of monitored cache lines themselves, which helps improve performance. For example, assuming a 64 kB cache, this may have 1024 cache lines that can be monitored. If it is desirable to associate a software-provided identifier with each of these cache lines, this requires at least 10 bits for the identifier to be able to distinguish between 1024 different cache lines; thus, for example, a 2-byte (16-bit) identifier may be used. Assuming a 16-bit identifier, identifier structure 260 may occupy 2 kB of memory space, which can therefore easily fit within a 64 kB cache. Some additional space in the cache may also be required for the snoop bitmap 270, which may amount to 128 bytes (1024 x 1 bit per snoop flag). In some examples, the count value 230 may also be flushed to memory and cached, while still leaving enough additional space in the level 1 data cache for monitored cache lines. This is illustrated by the shaded portion 300 in FIG. 9, which may indicate the portion of the cache corresponding to the maximum range of the various address monitoring structures, with other portions left for monitored cache lines and other data at unmonitored addresses. While FIG. 9 illustrates this shaded portion as a single contiguous block, it will be understood that in practice the address monitoring structures may be cached in multiple, non-contiguous entries in the cache.

[0080] The instruction of Variant 3 shown above is particularly useful in supporting the use case shown in Figure 9. In Variant 3, by implicitly defining the target address by reference to the address specified by the most recently encountered set exclusive status instruction, this frees up space in the instruction encoding where a register field instead provides the base address 250 of the identifier storage structure, so that the approach shown in Figure 9 can be used. However, in other examples, even if the target address is explicitly encoded in the instruction, if there is also sufficient space for a further register field to identify the identifier structure base address, then the example monitor exclusive instruction encoded with an explicitly indicated target address can also use the approach shown in Figure 9 to provide an in-memory data structure for tracking software IDs.

[0081] Also, in the example described above, in the monitor exclusive instruction of Variation 3, the address in register Xn identifies base address 250 of identifier storage structure 260, but in other examples, the value in this register may provide other information that allows the identifier store base address to be determined. For example, if snoop bitmap 270, count value 230, and identifier storage structure 260 are located at fixed offsets relative to each other in the address space, the value in the register specified by the monitor exclusive instruction can point to any one of these structures, and the address of the other structure can be derived from the address in register Xn and the implicitly defined fixed offset.

[0082] FIG. 10 illustrates the processing of a monitor polling instruction that may be used by software to request the monitor circuit 36 ​​to return information regarding any of the monitored addresses at which an event has been detected. FIG. 10 illustrates two variations of the monitor polling instruction. In the first variation, the instruction specifies a destination register Xd to which the monitor polling information is written in response to the monitor polling instruction. In the second variation, the monitor polling instruction specifies, in addition to the destination register Xd, an address register Xn that provides information for identifying the base address of the identifier storage structure 260 described with respect to FIG. 9. Variation 2 may be supported in instances where it is desirable to store the identifier storage structure in memory instead of providing a dedicated hardware structure as in FIG. 8. Variation 1 can be used with the implementation shown in FIG. 8.

[0083] In both variations, in step S200, the instruction decoder 20 decodes the monitor polling instruction and, in response, in step S202, controls the processing circuitry to make monitor polling information accessible to software indicating which of the set of monitored addresses have encountered one or more events indicating a potential update to the data. The monitor polling information can be written to the destination register Xd specified by the monitor polling instruction.

[0084] Thus, a monitor polling instruction may be provided that software can execute after receiving an interrupt from the address monitoring circuitry 36 notifying the software of an update to any one of the set of monitored addresses. Because the interrupt itself does not distinguish which particular address has been updated, the monitor polling instruction may be used to return monitor polling information to a destination register that indicates more information about which addresses have been updated.

[0085] In some implementations, if more than one address experiences an event, the monitor polling information may be able to provide information about multiple different addresses in the set of monitored addresses. However, in practice, this information may not fit within one register, and collecting respective software IDs or other information for multiple addresses may not be efficient in a single instruction (for circuit implementation and timing reasons). Thus, in one example, a monitor polling instruction may be intended to return a single log of data associated with a single monitored address where an event occurred; if it is necessary to read information from address monitors for multiple addresses, a loop containing multiple monitor polling instructions may be required.

[0086] FIG. 11 illustrates in more detail the processing of a monitor poll instruction when the monitor polling information is assumed to return information about only one monitored address, even if multiple monitored addresses encounter an event. In step S210, the instruction decoder again decodes the monitor poll instruction. In response to step S212, the address monitoring circuit 36 ​​checks the snoop indicator 224 in the address tracking structure 200 of FIG. 8 or the snoop bitmap 270 of FIG. 9 to identify the next address in the monitored set for which an event was detected during monitoring. The address monitoring circuit reads the corresponding software identifier 222 (from an entry in the address tracking structure 200, provided as a dedicated storage structure in hardware, or from an associated offset in an identifier data structure 260 stored in memory or cache 12). In the case of a memory-based structure 260, the offset in the identifier structure 260 corresponds to the location of the snoop bit read from the snoop bitmap 270. The software ID is included in the monitor polling information written to the destination register Xd of the monitor poll instruction. Other information may also be included, as shown below, by way of example. For example, it may be useful to provide an indication of whether there are any further addresses, other than the address for which the software identifier is being returned, that have encountered one or more events, to enable the software to determine whether it needs to execute any further instances of the monitor polling command.

[0087] In step S214, the processing circuitry also clears, in response to decoding the monitor polling instruction, an indication that one or more events have occurred for the particular monitored address whose identifier was returned in step S212 (e.g., by clearing snoop field 224 of the associated entry in address tracking structure 200 or clearing the corresponding bit in bitmap 270). Also, if count 230 tracks the number of remaining addresses that have not yet been polled by the monitor polling instruction, then in step S214, count 230 may also be decremented by one, so that when the count returns to zero, the software determines that no addresses remain to be polled.

[0088] An exemplary format of the monitor polling information returned in destination register Xd may be as follows: |63:48 monId|47:32 logLen|31:16 monLen|15:0 status|

[0089] From this the software can read: monId - the identifier 222 associated with the first entry associated with the address marked as snooped, or a known default value (eg, 0xffff) if an error occurs for some reason. logLen - the number of remaining addresses marked as snooped, including addresses whose identifiers 222 are returned from the address tracking structure 200, 260. monLen - the total number of addresses in the set of monitored addresses. status - Status information indicating whether the monitor polling operation was successful (e.g., 0 for ok, 1 for error; it may be possible to indicate multiple reasons for error using different encodings of the status field). Of course, this is just one example, and other implementations may return different types of monitor polling information or in different formats.

[0090] FIG. 12 illustrates a simulator implementation that may be used. While the above embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques, it is also possible to provide an instruction execution environment according to the embodiments described herein implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 330 that supports the simulator program 310 and optionally runs a host operating system 320. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in certain situations, such as when it is desirable to execute code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or may provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0091] While embodiments have been described above with reference to particular hardware components or features, equivalent functionality may be provided in the simulated embodiments by appropriate software components or features. For example, particular circuitry may be implemented as computer program logic in the simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in the simulated embodiments. In arrangements where one or more of the hardware elements referenced in the foregoing embodiments reside in host hardware (e.g., host processor 330), some simulated embodiments may use the host hardware where appropriate.

[0092] Simulator program 310 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides target code 300 (which may include applications, an operating system, and a hypervisor) with a program interface (an instruction execution environment) that is the same as the interface of the hardware architecture modeled by simulator program 310. Program instructions of target code 300, including the monitor exclusive instructions, monitor polling instructions, exclusive status setting instructions (e.g., load exclusive instructions), and store exclusive instructions described above, may be executed from within the instruction execution environment using simulator program 310, thereby allowing host computer 330, which does not actually have the hardware functions of device 2 discussed above, to emulate these functions.

[0093] The simulator program 310 may have instruction decode program logic 311 that includes instructions that check the instruction encodings of the program instructions of the target code 300 and map each type of instruction to a corresponding set of one or more program instructions in a native instruction set supported by the host hardware 330 that executes functionality corresponding to the functionality represented by the decoded instruction. The instruction decode program logic 311 supports decoding of the various types of instructions described above.

[0094] The simulator program 310 also includes register simulation program logic 312, which may include a set of instructions that maintain a register simulation data structure in host storage (e.g., the virtual address space of the host data processing unit 330 or a register of the host data processing unit 330). The register simulation data structure represents the register contents of registers 24 that the target code expects to be provided in hardware, but that may not actually be provided in the hardware of the host device 330. Instructions in the target code 300 are expected to reference particular registers in the simulated instruction set architecture, and may cause the register simulation program logic 312 to generate load / store instructions in the host device's native instruction set to read / write the corresponding simulated register state from / to the register simulation data structure stored in the host device's memory. Similarly, the simulation program 310 may include memory simulation program logic 313 that implements virtual-to-physical address translations (based on page table data) between the virtual address space used by the target code 300 and a simulated physical address space that, from the perspective of the target code 300, is expected to refer to actual physical memory storage, but is in fact mapped by the memory simulation program logic 313 to a range of virtual addresses within the virtual address space used by the real host data processing device 330 (which may itself undergo further address translations to the real physical address space used to refer to host memory).

[0095] The simulation code also includes exclusive status clearing program logic 314 and monitoring program logic 315, which comprise sets of software instructions that control host hardware 330 to perform functions equivalent to exclusive status tracking circuit 30 and address monitoring circuit 36, respectively.

[0096] In this application, the term "configured to..." is used to mean that an element of an apparatus has a configuration that is capable of performing a defined operation. In this context, "configuration" refers to a method of arranging or interconnecting hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to..." does not imply that an apparatus element needs to be modified in any way to provide the defined operation.

[0097] Although exemplary embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it will be understood that the invention is not limited to these precise embodiments, and that various changes and modifications can be made to the embodiments by those skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. 1. An apparatus comprising: an instruction decoder for decoding instructions; a processing circuit for performing data processing in response to the instruction decoded by the instruction decoder; monitoring circuitry for monitoring one or more events indicative of potential updates to data associated with any of a set of monitored addresses, and for making monitor reporting indications accessible to software executing on the processing circuitry indicative of whether any of the one or more events has occurred for at least one of the set of monitored addresses; in response to the instruction decoder decoding an exclusive status setting instruction that specifies a given address, the processing circuitry is configured to set an exclusive status associated with the given address; the processing circuitry is configured to clear the exclusive status associated with the given address in response to detecting an event indicative of a conflicting memory access to the given address; In response to the instruction decoder decoding a monitor exclusive instruction, the processing circuitry: determining whether the exclusive status is associated with a target address; and upon determining that the exclusive status is associated with the target address, assigning the target address to be one of the set of monitored addresses for which the one or more events are monitored by the monitoring circuitry.

2. 2. The apparatus of claim 1, wherein in response to the instruction decoder decoding the monitor exclusive instruction, the processing circuitry is configured to return a monitor allocation status indication accessible to software, the monitor allocation status indication indicating whether the target address was successfully assigned to become one of the set of monitored addresses in response to the monitor exclusive instruction.

3. 3. The apparatus of claim 2, wherein if the allocation of the target address to be one of the set of monitored addresses fails, the monitor allocation status indication indicates a reason for the failure to allocate the target address.

4. The monitor assignment status indication may include: the exclusive status is no longer set for the target address; the exclusive status is set for an address other than the target address; and 4. The apparatus of claim 3, wherein the monitoring circuitry distinguishes between at least two of the following reasons: the monitoring circuitry is unavailable or is not yet configured to accept assignment of addresses to the set of monitored addresses.

5. The apparatus according to any one of claims 1 to 4, wherein the monitor exclusive command specifies the target address.

6. 5. The apparatus of claim 1, wherein the target address includes an address specified as the given address by a most recent set exclusive status command that precedes the monitor exclusive command.

7. When it is determined in response to the instruction decoder decoding the monitor exclusive instruction that the exclusive status is associated with the target address, the processing circuitry is configured to assign an identifier value specified as an operand of the monitor exclusive instruction to an entry in an identifier storage structure corresponding to the target address. An apparatus according to any one of claims 1 to 6.

8. 8. The apparatus of claim 7, wherein the identifier storage structure includes a dedicated address watchdog tracking structure containing a plurality of entries, each entry for tracking information associated with a corresponding one of the set of watched addresses.

9. The apparatus of claim 7 , wherein the identifier storage structure comprises a data structure stored in memory.

10. 10. The apparatus of claim 9, wherein the monitor exclusive instruction specifies information for identifying a base address of the identifier storage structure.

11. 11. The apparatus of claim 7, wherein the monitoring circuitry is configured to make accessible to software an indication of an identifier stored in an entry in the identifier storage structure corresponding to one of the set of monitored addresses at which the monitoring circuitry has detected the occurrence of any of the one or more events.

12. 12. The apparatus of claim 1, wherein in response to the instruction decoder decoding a monitor polling instruction, at least one of the processing circuitry and the monitor circuitry is configured to make monitor polling information accessible to software indicating which of the set of monitored addresses experienced the one or more events.

13. when it is determined in response to the instruction decoder decoding a monitor exclusive instruction that the exclusive status is associated with the target address, the processing circuitry is configured to assign an identifier value specified as an operand of the monitor exclusive instruction to an entry in an identifier storage structure corresponding to the target address; The apparatus of claim 12 , wherein the monitor polling information includes the identifier value associated with at least one of the set of monitored addresses at which the one or more events occurred.

14. 14. The apparatus of claim 13, wherein the identifier storage structure comprises a data structure stored in memory, and the monitor polling instruction specifies a base address of the identifier storage structure.

15. 14. The apparatus of claim 12, wherein the monitor polling information includes a count value indicating the number of addresses in the set of monitored addresses for which the one or more events have occurred.

16. 16. The apparatus of claim 12, wherein the processing circuitry is configured to make the monitor polling information accessible to software by writing the monitor polling information to a destination register identified by the monitor polling instruction.

17. 17. The apparatus of claim 1, wherein the exclusive status setting instruction includes a load exclusive instruction, and in response to the instruction decoder decoding the load exclusive instruction, the processing circuitry is configured to load data associated with the given address into at least one destination register specified by the load exclusive instruction and set the exclusive status associated with the given address.

18. In response to the instruction decoder decoding a store exclusive instruction specifying a store target address and at least one source register, the processing circuitry: determining whether the exclusive status is associated with the store target address; and storing data from the at least one source register to a memory location associated with the store target address when it is determined that the exclusive status is associated with the store target address.

19. A processor-implemented method comprising: setting an exclusive status associated with a given address in response to decoding an exclusive status setting instruction specifying the given address; clearing the exclusive status associated with the given address in response to detecting an event indicating a conflicting memory access to the given address; In response to decoding the monitor exclusive instruction, determining whether the exclusive status is associated with a target address; assigning the target address to be one of a set of monitored addresses upon determining that the exclusive status is associated with the target address; monitoring for one or more events indicative of potential updates to data associated with any of the set of monitored addresses; making accessible to software a monitoring report indication indicating whether any of said one or more events has occurred for at least one of said set of monitored addresses.

20. 1. A computer program which, when executed on a host data processing apparatus, controls said host data processing apparatus to provide an instruction execution environment for executing instructions of target code, said computer program comprising: instruction decoding program logic for controlling the host data processing apparatus to decode instructions of the target code and perform data operations corresponding to the instructions of the target code; monitor program logic for monitoring one or more events indicative of potential updates to data associated with any of a set of monitored addresses within a simulated address space, and for making monitor report indications accessible to the target code indicative of whether any of the one or more events have occurred for at least one of the set of monitored addresses; the instruction decode program logic is configured to control the host data processing apparatus to set an exclusive status associated with the given address in response to a set exclusive status instruction in the target code specifying the given address within the simulated address space, and the computer program includes exclusive status clear program logic for clearing the exclusive status associated with the given address in response to detecting an event indicative of a conflicting memory access to the given address within the simulated address space; In response to a monitor exclusive instruction in the target code, the instruction decode program logic controls the host data processing apparatus to: determining whether the exclusive status is associated with a target address within the simulated address space; and if it is determined that the exclusive status is associated with the target address, assigning the target address to be one of the set of monitored addresses for which the one or more events are monitored by the monitor program logic.

Images