Offloading shared memory update task

Abstract

An approach for offloading shared memory update tasks 10, including decoding instructions using a decoding circuitry 13. Data processing operations is performed by data processing circuitry 6 in resp

Description

The present technique relates to the field of data processing. Some processing workloads may involve access to shared memory data shared between multiple threads. A thread accessing shared memory data may include an atomic read-modify-write update to the shared memory data. At least some examples of the present technique provide an apparatus comprising: decoding circuitry configured to decode instructions; and processing circuitry configured to perform data processing operations in response to the instructions decoded by the decoding circuitry; wherein: in response to a shared memory update task offloading instruction, the decoding circuitry or the processing circuitry is configured to control offloading, to extension processing circuitry, of a shared memory update task to be performed by the extension processing circuitry asynchronously with respect to other data processing operations performed by the processing circuitry, the shared memory update task comprising at least one atomic read-modify-write update to shared memory data. At least some examples of the present technique provide computer-readable code for fabrication of the apparatus described above. The computer-readable code may be stored on storage medium. The storage medium may be a non-transitory storage medium. At least some examples provide a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: decoding program logic configured to decode instructions of the target program code; and processing program logic configured to control the host data processing apparatus to perform data processing operations in response to the instructions decoded by the decoding program logic; wherein: in response to a shared memory update task offloading instruction, the decoding program logic is configured to control the host data processing system to simulate offloading, to extension processing circuitry, of a shared memory update task to be performed by the extension processing circuitry asynchronously with respect to other data processing operations performed by simulated processing circuitry in response to the target program code, the shared memory update task comprising at least one atomic read-modify-write update to shared memory data. The computer program may be stored on storage medium. The storage medium may be a non-transitory storage medium. At least some examples of the present technique provide a method comprising: decoding instructions using decoding circuitry; in response to the decoded instructions, performing data processing operations using processing circuitry; and in response to a shared memory update task offloading instruction, offloading, to extension processing circuitry, a shared memory update task to be performed by the extension processing circuitry asynchronously with respect to other data processing operations performed by the processing circuitry, the shared memory update task comprising at least one atomic read-modify-write update to shared memory data. Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which: Figure 1 illustrates an example of an apparatus comprising decoding circuitry, processing circuitry and extension processing circuitry; Figure 2 illustrates a method of processing instructions; Figure 3 illustrates a method of offloading a shared memory update task to extension processing circuitry; Figure 4 illustrates a method of processing the shared memory update task using the extension processing circuitry; Figure 5 illustrates an example of a processing system; Figure 6 illustrates a first example of the extension processing circuitry; Figure 7 illustrates a second example of the extension processing circuitry; Figure 8 illustrates an example of a shared memory update task offloading instruction; Figure 9 illustrates commitment of the shared memory update task offloading instruction upon acceptance of the shared memory update task by the extension processing circuitry; Figure 10 illustrates an example of an extension task status checking instruction; Figure 11 illustrates an example of an extension task result obtaining instruction; and Figure 12 illustrates a simulation example. Atomic read-modify-write (RMW) operations are normally performed by processing circuitry synchronously with the program execution of the thread that requires the atomic read-modify-write operation. However, atomic operations are used on shared memory which is often contended, causing the processing circuitry to stall on memory accesses to such contended data, which slows down program execution and decreases processor utilisation. In scenarios with heavy memory contention, software could be stalled for very long periods of time as a given thread would wait for all previous threads contending for the same data to complete their updates. It gets worse with more complex updates that consist of multiple dependent atomic (and non-atomic) accesses. In the examples discussed below, an apparatus comprises decoding circuitry configured to decode instructions; and processing circuitry configured to perform data processing operations in response to the instructions decoded by the decoding circuitry. In response to a shared memory update task offloading instruction, the decoding circuitry or the processing circuitry is configured to control offloading, to extension processing circuitry, of a shared memory update task to be performed by the extension processing circuitry asynchronously with respect to other data processing operations performed by the processing circuitry, the shared memory update task comprising at least one atomic read-modify-write update to shared memory data. Hence, by performing shared memory update tasks involving at least one atomic read-modify-write update operation asynchronously using the extension processing circuitry, this avoids software executing on the processing circuitry from needing to stall waiting on the update to complete, and frees up the processing circuitry to be able to perform other useful work, improving processor utilisation and throughput. Therefore, use of extension processing circuitry to perform the shared memory update task asynchronously with respect to other processing operations performed by the processing circuitry can greatly improve processing performance for software involving atomic read-modify-write operations to shared memory data. This approach may be seen as counter-intuitive, as one might think that if the software thread offloading the shared memory update task involves subsequent operations dependent on the outcome of that task, there would be no benefit to offloading the task to perform asynchronously. However, the inventors recognised that there can be some shared memory update tasks (such as queue enqueue or lock release operations) for which the update behaves primarily as a store and so can complete asynchronously in the background without needing to return a result for subsequent instructions of the software to use. In any case, even if the shared memory update task returns a value to be used by a dependent operation in the thread that offloaded the shared memory update task, offloading the shared memory update task to the extension processing circuitry can free up the processing circuitry to perform other independent operations (e.g. another context switched to using light-weight context switching techniques) while waiting for the shared memory update task to complete on the extension processing circuitry. Therefore, even in the presence of dependencies between the shared memory update task and a subsequent part of the thread, there can still be a performance benefit to offloading the shared memory update task to perform it asynchronously while allowing continued nonblocked execution on the processing circuitry. The shared memory update task may comprise at least one operation to trigger a request for the shared memory data to be brought into a cache in an exclusive coherency state. The exclusive coherency state (also known as a unique coherency state) may be a state in which data for a given address held in a private cache may be modified without issuing any further coherence transaction to a home node to check for whether other private caches also hold data for that address. This contrasts with a shared coherency state (also known as non-exclusive or nonunique coherency state), in which modification of data for the given address held in a private cache would require first issuing a coherence transaction to a home node in case other private caches also hold a copy of the data for the given address. Shared memory update tasks may often involve requests to cache data in the exclusive coherency state, to ensure that contending threads which have also read the data invalidate their cached copies of the data before the write terminating the atomic read-modify-write sequence completes. When data is requested in the exclusive coherency state, this therefore may require a home node (the system element responsible for maintaining coherency between cached data in private caches of a number of requesters) to snoop other private caches to check for cached copies and trigger the invalidations. Hence, there can be a considerable snoop response latency in awaiting responses to those snoop requests before the home node can grant exclusive access to the cached data to the original requesters. Even worse, when there is high contention, there can be many requests for data to be obtained in the exclusive coherency state pending in a queue at the home node, and so a given thread’s request may have to wait for each earlier thread’s request to be processed before the given thread can obtain the shared data in the exclusive coherency state. Therefore, shared memory update tasks involving a request for data to be cached in the exclusive coherency state can incur a significant delay if performed synchronously with respect to other instructions of the program thread that requires the shared memory update. By offloading the shared memory update task to the extension processing circuitry, processing performance can be improved. The shared memory update task may comprise, in response to a failure of a critical section comprising the at least one atomic read-modify-write update, retrying the critical section. A critical section may comprise a sequence of memory accesses (loads and stores) which are to be observed as being completed atomically (indivisibly). A critical section in a given thread may typically involve a conditional operation which is dependent on a condition being satisfied, where that condition will fail if there is a risk that a contending thread may have accessed the shared data in a way which risks loss of the atomicity of the critical sections in the given thread and contending thread. If the condition fails, the critical section is retried. Hence, the shared memory update task may, in cases of high contention between threads, involving repeating the critical section multiple times until eventually the update succeeds. The delay caused by repeatedly trying the critical section may cause significant loss of performance if the shared memory update task is performed synchronously by the processing circuitry, so offloading the shared memory update task to the extension processing circuitry to be performed asynchronously can greatly improve performance by allowing other operations to proceed while waiting for completion of the critical section. The atomic read-modify-write update could be implemented in different ways, using different types of operation. However, in some examples, the shared memory update task may comprise at least one atomic compare-and-swap operation. A compare-and-swap operation takes as inputs a given address, a compare value and a swap value, and causes the memory data value stored at a memory system location corresponding to the given address to be read and compared with the compare value. If the memory data value and compare value match (or otherwise satisfy a comparison condition), the condition is satisfied and the data at the given address is updated based on the swap value. A compare-and-swap operation may be used, for example, to implement a conditional write at the end of the atomic read-modify-write sequence. In some examples the shared memory update task comprises a set of multiple memory accesses for which a later memory access in the set is dependent on an earlier memory access in the set. In particular, the set of dependent accesses could include accesses to two or more different cache lines of data. For example, the shared memory update task may involve multiple dependent atomic (and possibly non-atomic) accesses. Also, in some examples, the shared memory update task comprises updates to two or more cache lines of shared memory data. If there are dependencies between multiple memory accesses, and accesses to and / or updates to multiple cache lines of shared memory data, this can prolong the critical section involved in the shared memory update task, and exacerbate delays if the shared memory update task is performed synchronously, so it can be particularly beneficial to perform such shared memory update tasks asynchronously. In some examples, the shared memory update task comprises at least one read operation, a set of arithmetic / logical operations dependent on the at least one read operation, and the at least one update to shared memory data dependent on the plurality of arithmetic / logical operations, wherein the set of arithmetic / logical operations is too complex to be performed synchronously by the processing circuitry as a unitary operation in response to a single instruction of an instruction set architecture supported by the decoding circuitry and the processing circuitry. For such more complex shared memory updates, as there is no single instruction that can perform the required modification of shared memory data, there may be a greater delay in performing that modification synchronously on the processing circuitry. Therefore, it can be useful to provide the extension processing circuitry which can perform the required task asynchronously. The shared memory update task offloading instruction could be implemented in different ways. In some examples, the shared memory update task offloading instruction may be a type of instruction defined in an instruction set architecture (ISA) supported by the decoding circuitry and processing circuitry which is specifically intended for offloading of extension tasks to extension processing circuitry. Other examples may use, as the shared memory update task offloading instruction which, depending on a value of a parameter or operand of the instruction, can also serve other purposes not related to extension task offload. For example, the shared memory update task offloading instruction may comprise an extension task offloading instruction specifying an extension operation identifier indicative of which of a plurality of extension tasks is to be performed by the extension processing circuitry, where for the shared memory update task offloading instruction the extension operation identifier has a value corresponding to the shared memory update task. The extension operation identifier may support encodings corresponding to a range of different types of extension tasks to be performed asynchronously. At least one encoding of the extension operation identifier may be allocated to correspond to a given variant of the shared memory update task. In some examples, two or more distinct variants of the shared memory update task may be supported, identified by different values of the extension operation identifier. The shared memory update task offloading instruction may specify at least one register operand indicative of one or more parameters to be passed to the extension processing circuitry for controlling the shared memory update task. For example, the at least one register operand may include an address operand indicative of a memory address of the shared memory data to be updated in the shared memory update task. The at least one register operand could also include one or more parameters identifying the type of shared memory update task to be performed, or other configuration options governing how the shared memory update task should be performed. Another approach can be that the shared memory update task offloading instruction comprises an instruction which writes to a control register. For example, a set of control registers (e.g. system registers or memory-mapped registers) may be provided which are used as an interface for configuring the extension processing circuitry to perform an offloaded extension task. The control registers may include registers for defining parameters of the shared memory update task (e.g. the address of one or more items of shared memory data to be updated in the atomic read-modify-write update), and a launch register. In some examples, the shared memory update task offloading instruction could therefore be an instruction which writes to the launch register, triggering offloading of the extension task to the extension processing circuitry (with the extension processing circuitry also being passed any other control parameters which may have been written to other registers of the set of control registers prior to executing the instruction which writes to the launch register). In the case where the shared memory update task offloading instruction is an instruction which writes to a control register, the instruction type of the control register updating instruction could be a generic instruction type also used for other control register updates not related to extension task offload. For example, the shared memory update task offloading instruction could be a system register updating instruction, or a store instruction specifying an address mapped to the launch register. The shared memory update task offloading instruction may therefore be associated with a parameter that distinguishes whether a particular instance of the instruction represents the shared memory update task offloading instruction or represents a register update instruction or memory access instruction not related to extension task offload. That parameter could be defined in different ways. In some examples, the parameter could be specified as an operand of the shared memory update task instruction, e.g. a register operand where the instruction references a selected register and the value stored in that register defines the parameter identifying whether the instruction is the shared memory update task offloading instruction. Alternatively, the parameter may be stored in another control register other than the control register written by the shared memory update task offloading instruction, which may have been written to that other control register by an earlier instruction than the shared memory update task offloading instruction. For example, where the set of control registers includes the launch register and one or more parameter registers for defining parameters for controlling the offloaded extension task, the shared memory update task offloading instruction may specify that the launch register should be updated, but the parameter distinguishing that the particular extension task to be offloaded is a shared memory update task may be in one of the parameter registers and so may not itself be directly specified by the shared memory update task offloading instruction. Nevertheless, even though the overall sequence of instructions for controlling the offload may involve a sequence of multiple instructions (one or more instructions to set the parameter registers, followed by the instruction writing to the launch register), the final instruction of the sequence which writes to the launch register can be regarded as the shared memory update task offloading instruction which actually causes the shared memory update task to be offloaded to the extension processing circuitry. Hence, it will be appreciated that there are a variety of ways in which the interface for controlling offload of extension tasks to the extension processing circuitry can be controlled using instructions decoded by the decoding circuitry. In some examples, in response to the shared memory update task offloading instruction or an extension task identifier obtaining instruction subsequent to the shared memory update task offloading instruction, the processing circuitry is configured to obtain from the extension processing circuitry an extension task identifier used by the extension processing circuitry to identify a specific instance of the shared memory update task initiated by the shared memory update task offloading instruction. The extension task identifier may be a “handle” assigned by the extension processing circuitry to a specific instance of an extension task (such as the shared memory update task or other types of extension task), which may be used to differentiate multiple instances of extension tasks assigned to the extension processing circuitry. The extension task identifier may be referenced in subsequent instructions relating to a given instance of an extension task, e.g. for querying accelerator status or completion of the given instance of the shared memory update task or, in some examples, for obtaining a result of the shared memory update task. In some examples, the shared memory update task offloading instruction itself may cause the extension task identifier to be returned to the processing circuitry (e.g. the extension task identifier could be written to a destination register of the shared memory update task offloading instruction, from which it can be read as an input operand of a subsequent instruction). In other examples, the shared memory update task offloading instruction may cause the extension processing circuitry to assign an extension task identifier to the specific instance of the shared memory update task initiated by the shared memory update task offloading instruction, but to obtain the extension task identifier to make it available for use as an operand of a subsequent instruction, a subsequent instruction (e.g. a system register read instruction) may be executed by the processing circuitry to cause the extension task identifier to be read from a system location at which the extension processing circuitry stored in the extension task identifier, and transfer the extension task identifier to a destination register of the subsequent instruction. Hence, there can be different ways of implementing the architectural mechanism to allow the extension task identifier assigned by the extension processing circuitry to be made available to software processed by the processing circuitry. In some examples, in response to an extension task status checking instruction associated with an extension task identifier indicative of a specific instance of an extension task offloaded to the extension processing circuitry, the processing circuitry is configured to obtain status information indicative of a current status of the extension task at the extension processing circuitry. For example, the status information may support encodings corresponding to any two or more of the following list: • an in-progress state indicating that the extension processing circuitry has not yet completed the extension task; • a completed state indicating that the extension processing circuitry has completed the extension task; • an interrupted state indicating that the extension processing circuitry was interrupted while performing the extension task; • a failed state indicating that an error occurred while performing the extension task. Such status indications can be used by the software thread which offloaded the extension task to decide whether the result of the extension task can be obtained yet or whether to continue waiting, or whether an alternative operation (such as an error handling response) should be performed. In some examples, the extension task status checking instruction may itself specify the associated extension task identifier (e.g. by specifying an immediate operand identifying the extension task identifier or a general purpose register storing the extension task identifier). In other examples, the extension task status checking instruction may not explicitly reference the extension task identifier as an operand. For example, a given system register may by default be designated for storing extension task identifier, and in this case it may be that, without that system register explicitly being referenced in the encoding of the extension task status checking instruction, the extension task status checking instruction causes the processing circuitry to obtain the extension task identifier from that system register, and to obtain the status information corresponding to that extension task identifier. Hence, in some cases, the extension task status checking instruction could, when in use as part of a software routine, be preceded by an earlier instruction which causes the extension task identifier to be written to the system register which would subsequently be referenced by the extension task status checking instruction. In some examples, in response to an extension status obtaining instruction specifying at least one destination register and an extension task identifier indicative of a specific instance of an extension task offloaded to the extension processing circuitry, the decoding circuitry is configured to control the processing circuitry to assign to the at least one destination register status information indicative of a current status of the extension task at the extension processing circuitry. Hence, one example of the extension tasks status checking instruction could cause the status information to be returned to a particular destination register. Other examples may cause the status information to be written to a memory location. In some examples, when the shared memory update task is accepted by the extension processing circuitry, the processing circuitry is configured to commit the shared memory update task offloading instruction without waiting for completion of the shared memory update task by the extension processing circuitry. In some examples, the processing circuitry is configured to obtain a result of the shared memory update task in response to the decoding circuitry decoding an extension task result obtaining instruction separate from the shared memory update task offloading instruction. This contrasts with synchronously processed instructions processed on the processing circuitry, for which the result of an operation triggered to be performed by a given instruction would be returned in response to that given instruction itself (e.g. by writing the result to a register). With the extension processing circuitry, as the operation is performed asynchronously, the shared memory update task offloading instruction can be regarded as committed once the extension processing circuitry has accepted the shared memory update task and then does not involve return of the result as part of the instruction definition of the shared memory update task offloading instruction. A separate instruction is used to obtain any result of performing the shared memory update task (e.g. the result could include a value returned by a compare-and-swap operation or the modified value written to the shared data in the read-modify-write sequence). The extension task result obtaining instruction could be implemented in different ways. In some examples, the extension task result obtaining instruction could be a load instruction. For example, the extension processing circuitry may have written its result to memory and so a load instruction subsequently executed can read the result from memory. Alternatively, the extension task result obtaining instruction could be an instruction which reads a given control register to which the extension processing circuitry makes the result of the extension task available. In some examples, in response to an extension task result synchronisation instruction specifying at least one destination register and an extension task identifier indicative of a specific instance of an extension task offloaded to the extension processing circuitry, the processing circuitry is configured to assign to the at least one destination register result information obtained from the extension processing circuitry by processing the extension task identified by the extension task identifier. The extension task result synchronisation instruction can be one particular example of the extension task result obtaining instruction mentioned above. The processing circuitry can continue processing of other instructions while the shared memory update task is performed by, or pending at, the extension processing circuitry. In particular, the shared memory update task, when performed asynchronously by the extension processing circuitry, is non-blocking, so subsequent instructions of the thread of processing that offloads the shared memory update task can continue to make forward progress, even if the shared memory update task is stalled. In some examples, a central processing unit (CPU) comprises the decoding circuitry, the processing circuitry and the extension processing circuitry. Hence, the extension processing circuitry is local to a CPU and provides support for certain extension tasks to be performed asynchronously with respect to other operations processed (synchronously) by the processing circuitry of the CPU. Compared to a remote accelerator coupled to a memory system which is configured via control data structures stored in memory, the extension processing circuitry local to the CPU can be much quicker to configure and by reducing the configuration overhead, it may become feasible to offload much shorter extension tasks, such as an atomic read-modify-write sequence of a shared memory update task, to the asynchronous extension processing circuitry (in contrast for a remote accelerator given the long latency in configuring the accelerator it tends to be that the accelerator is useful only for longer jobs). In some examples, the decoding circuitry comprises shared decoding circuitry configured to decode arithmetic / logical instructions, branch instructions and load / store instructions of an instruction set architecture supported by the decoding circuitry and the processing circuitry, as well as being configured to decode the shared memory update task offloading instruction. Hence, the shared memory update task offloading instruction may be part of a general purpose instruction set also including general purpose arithmetic / logical instructions, branch instructions and load / store instructions. This contrasts with typical accelerator control mechanisms for controlling a remote accelerator where the accelerator commands are designated in an accelerator-specific format which does not support simple arithmetic / logical instructions, branch instructions and load / store instructions. By controlling offloading of a shared memory update task using an instruction of a general purpose instruction set architecture, the extension processing circuitry can be coupled much more closely into a CPU, improving the performance benefits of offloading to the extension processing circuitry. In some examples, the apparatus comprises a configuration signal path configured to convey control signals to the extension processing circuitry in response to decoding of the shared memory update task offloading instruction by the decoding circuitry, where the configuration signal path is separate from a load / store data path used by the processing circuitry to issue load / store memory access requests to a memory system. For example, a dedicated path, separate from the path via which coherence transactions are issued to a memory system, may be provided for configuration of the extension processing circuitry. This means the extension processing circuitry can be integrated more tightly into a CPU, avoiding the relatively slow configuration overhead of configuring a remote accelerator via memory-based communication. In some examples, during offloading of the shared memory update task to the extension processing circuitry, the extension processing circuitry is configured to directly access state in architectural registers defined by an instruction set architecture supported by the decoding circuitry and the processing circuitry. By enabling the architectural registers of a processor to be used to define parameters for controlling the shared memory update task with direct access to those registers at the time of offloading the shared memory update task, this can support faster offload than if all parameters of the shared memory update task have to be read from memory by the extension processing circuitry. It will be appreciated that the register state passed to the extension processing circuitry at the time of offload may not be the only parameters or state information needed for the extension processing circuitry to perform the shared memory update task, so some state information could also be read from memory, but by providing at least some parameters to the extension processing circuitry via a path directly from the registers to the extension processing circuitry (not requiring access to a cache or memory), this can speed up offload. In some examples, the extension processing circuitry may only have direct access to the state in the architectural registers during the offload phase of passing the extension task to the extension processing circuitry. Given the asynchronous nature of the extension task performed on the extension processing circuitry, it may be difficult to allow the extension processing circuitry to continue to access the registers which other operations which need to access the registers are being performed synchronously by the processing circuitry. Therefore, during the main running of the shared memory update task, the extension processing circuitry may not have direct access to state in the architectural registers. In some examples, the processing circuitry and the extension processing circuitry may share a private cache private to a processing element comprising the processing circuitry and the extension processing circuitry and inaccessible to any other processing element of the apparatus. This can allow the processing circuitry and extension processing circuitry to exchange configuration information, status information and / or results of extension tasks faster than if communication of this information had to be performed via main memory without the extension processing circuitry having direct access into the private cache of the processing circuitry. In some examples, the processing circuitry and the extension processing circuitry may share translation table walk circuitry configured to control translation table walk operations for obtaining translation table data from a memory system. By reusing the translation table walk circuitry of the processing circuitry for memory accesses triggered by the extension processing circuitry which miss in a translation lookaside buffer, this saves circuit area by avoiding the need to duplicate the translation table walk circuitry at both processing circuitry and extension processing circuitry. In some examples, the processing circuitry and extension processing circuitry could also share at least one translation lookaside buffer (TLB) for caching address translation information obtained in a translation table walk operation. However, it is also possible for the extension processing circuitry to have its own dedicated TLB looked up for memory accesses triggered by the extension processing circuitry to identify address translation information. Nevertheless, if the TLB of the extension processing circuitry detects a miss for a given address to be accessed by the extension processing circuitry, the shared translation table walk circuitry associated with the processing circuitry can be used to perform the translation table walk operation to find the missing address translation information. In some examples, the extension processing circuitry may be external to the apparatus comprising the decoding circuitry and processing circuitry. However, in some examples the apparatus comprises the extension processing circuitry. In some examples, the extension processing circuitry may support the shared memory update task and another extension task being in progress simultaneously. For example, there could be multiple instances of extension processing circuitry to process multiple extension tasks in parallel (either multiple instances of the shared memory update task, or one instance of the shared memory update task in parallel with another type of extension task which is not a shared memory update task). In this case, there could be dependencies (e.g. data dependencies or address dependencies) between the shared memory update task and the other extension task, if the respective extension tasks involve access to a same memory address. Hence, the extension processing circuitry may control ordering of the shared memory update task with respect to the other extension task based on dependencies between the shared memory update task and the other extension task. The presence of dependencies between respective extension tasks could be detected by the extension processing circuitry, or could be identified by software-provided information identifying the dependencies. Specific examples are now described with reference to the drawings. Figure 1 illustrates an example of an apparatus 10. The apparatus 10 may for example be a data processing system such as a system-on-chip or collection of chiplets implementing at least one processor and its memory storage. For example, the components of the apparatus 10 illustrated in Figure 1 may be part of a given processor, e.g. a central processing unit (CPU). While Figure 1 shows the processor as a standalone apparatus (a design for an individual processor core could, for example, be licensed as a separate product from other parts of a wider processing system), as shown in Figure 5 discussed further below the apparatus 10 could also form part of a wider processing system 2 which comprises two or more processors 10 capable of executing respective threads of processing in parallel with each other. The apparatus 10 includes decoding circuitry 13 which decodes instructions fetched from an instruction cache or a memory system, and processing circuitry 6 which processes the instructions decoded by the decoding circuitry 13 to perform data processing operations on operands obtained from registers 8 or the memory system, to generate processing results which may be written back to the registers 8 or to the memory system. The processing circuitry 6 comprises a pipeline comprising a number of pipeline stages for performing respective functions in response to the instructions, with the pipeline stages operating in a pipelined manner so that a later pipeline stage can be performing a later stage of processing on an older instruction in parallel with an earlier pipeline stage performing an earlier stage of processing on a younger instruction which appears later in program order than the earlier instruction. In some instances, it is also possible to perform out-of-order processing where a younger instruction in program order can bypass an older instruction to be executed in an order which differs from the order in which those instructions appear in program order. Instructions processed by the pipeline of the processing circuitry 6 may be processed synchronously, such that for a given instruction the access to registers 8 to obtain instruction operands and writeback to registers 8 to write a processing result can be synchronised in timing relative to register read / write operations for other instructions. For synchronously processed arithmetic / logical instructions, a given instruction type may be associated with a certain defined number of cycles required for the instruction to execute, so that if the instruction is dispatched for execution in a given cycle then its result is guaranteed to be available by a certain subsequent cycle. Also, for the synchronously processed instructions, the architectural result of that instruction is made available as part of executing the instruction itself, so commitment of the synchronously processed instruction implies the result of that instruction will be made available for reference by a subsequent instruction. If a given synchronously processed instruction is stalled, then any dependent operations referencing the result of that instruction may also be blocked from being executed (unless a speculation mechanism is provided to predict the result of the synchronously processed instruction to break the chain of dependency). The apparatus 10 also has extension processing circuitry 23 to which the decoding circuitry 13 can, in response to an extension task offloading instruction, offload an extension task which is to be performed by the extension processing circuitry 23 asynchronously with respect to other data processing operations performed by the processing circuitry 6. Unlike for synchronously processed instructions, the result of the extension task is not guaranteed to be available once the extension task offloading instruction has been committed. Instead, separate instructions (separate from the offloading instruction) may be decoded to allow querying of whether the extension task is complete and to obtain any results. The extension task offloading instruction is non-blocking in that it can be committed when the extension processing circuitry 23 has accepted the offloaded extension task (or otherwise indicated that it is unavailable to accept the offload extension task), but does not require its commitment to be delayed until the extension task is actually performed. This means that younger instructions in the thread of processing including the extension task offloading instruction can continue to be processed on the processing circuitry 6, while the extension task is performed asynchronously on the extension processing circuitry 23 in the background of ongoing processing on the processing circuitry 6. The instructions processed synchronously on the processing circuitry 6 may, at a later point of program flow, query whether the extension processing circuitry 23 has completed its task and if so obtain any results either directly from extension processing circuitry 23 or from a cache or memory. As shown in Figure 1, the apparatus 10 has a direct configuration path for the decoding circuitry 13 to cause offloading of an extension task to the extension processing circuitry 23, where the direct configuration path is separate from the path by which the processing circuitry 6 issues requests (e.g. coherence transactions) to a memory system to request access to data stored in the memory system. This means the exception processing circuitry 23 can be integrated directly into the regular processing circuitry 6 of a processor, rather than being a remote accelerator accessed via the memory system. In some examples, the extension processing circuitry 23 may have direct access to the register file 8 used by the processing circuitry 6, which can be useful during the handover phase when an extension task is being offloaded to the extension processing circuitry 23 or when the result of the extension task is being transferred back to the processing circuitry 6, to allow parameters of the extension task and results to be shared between the processing circuitry 6 and the extension processing circuitry 23 via the registers 8. It is also possible for such sharing of parameters and results to be via a private cache (e.g. level 1 cache) associated with the processing circuitry 6. One type of extension task supported by the processing circuitry is a shared memory update task which involves at least one atomic read-modify-write update to shared memory data. Shared memory data is data which is at risk of contention for access to the shared memory data by multiple threads. Memory contention may occur when multiple threads access the same memory location (cache line) and at least one of those accesses is a write access. In a system comprising multiple processors with coherent access to shared memory, it can often be useful for performance to parallelize multiple updates to a shared data structure by causing multiple software threads executing on different processors to perform atomic read / modify / write updates on shared data in memory. For example, a sequence to be performed by each thread may include a read of a shared memory location, one or more operations dependent on the read data to generate a modified value, and a write of the modified value to the shared memory location. To illustrate the danger of synchronisation errors when multiple threads contend for updates to shared data, consider an example where such a read / modify / write sequence is used to update a bank account balance in response to a request to transfer money to the account. The read / modify / write sequence could therefore be something like the following: read the memory location representing the account balance of the required bank account; add the transferred amount to the account balance to generate a modified account balance; - write the modified account balance back to the memory location representing the account balance of the required bank account. As a bank may be processing a high rate of transfer requests, to improve processing performance it can be desirable to parallelize multiple updates by executing a number of threads on multiple CPUs of a processing system, each comprising the above read / modify / write sequence. On many occasions, the transfer requests processed in parallel may relate to different bank accounts and so there is no contention. However, there is a risk that if two threads process respective transfer requests for the same bank account in parallel, if the read / modify / write sequences for processing those transfer requests overlap and the software is written poorly without any measures enforcing synchronisation of the corresponding updates, this could lead to a synchronisation error in the following scenario: Thread 1 Thread 2 Read balance of memory location X e.g. balance[X] = 1000 Add transferred amount 1 to balance to generate modified balance 1 e.g. 1000 + 200= 1200 Read balance of memory location X e.g. balance[X] = 1000 Write modified balance 1 to memory location X e.g. write 1200 to balance[X] Add transferred amount 2 to balance to generate modified balance 2 e.g. 1000 + 40 = 1040 Write modified balance 2 to memory location X e.g. write 1040 to balance[X] Here, as the read for thread 2 occurred between the read and write operations for thread 1, this means the read for thread 2 did not take into account the modified balance (1200) written by thread 1, and so the subsequent write of modified balance 2 by thread 2 causes the end result to be that the balance in account X is set to 1040. This overwrites modified balance 1 = 1200 written by thread 1, effectively causing the transferred amount 1 (e.g. £200) to be lost. The final balance shown by memory location X does not consider the transferred amount 1 even though thread 1 seems to have finished processing the request to transfer amount 1 to the bank account. Hence, the owner of the account may find they have lost money that they were entitled to. Hence, this kind of synchronisation error can have serious consequences for some processing workloads. It will be appreciated that the above example is just a simplified example for illustrating the problem, and in practice many shared memory functions may be considerably more complex than the example shown above, e.g. involving updates to multiple locations and with more complex modification sequences between the initial read and the write. To avoid such synchronisation error, software developers may write the program code for threads to include a “critical section” which is to be observed as executing atomically (indivisibly). For example, the critical section can include the read, add, write sequence of the example shown above. A number of techniques can be used to ensure atomic access to the shared memory location. For example, a lock variable may be used to negotiate exclusive access to the shared memory location, with a given thread not entering the critical section until it has acquired the lock for the shared memory location. However, lock-based techniques (which are blocking techniques, as the lock holder blocks all other threads from making progress) may have poor scalability from a multiple thread perspective. Other non-blocking techniques are possible, in which threads cannot be blocked indefinitely by other threads and one of the threads is guaranteed to be able to make progress. For example, each thread could start processing the critical section without first acquiring a lock, but may ensure synchronisation by, for example, making the final write operation of the critical section conditional on a condition which will fail if another thread has written to the shared memory location X in the period between the read and write. For example, a compare-and-swap operation may be used to implement the final write, with the write being conditional on a comparison between a value re-read from memory location X in response to the compare-and-swap operation and a compare value which corresponds to the previously read value at the start of the atomic sequence. This can cause the critical section to fail (and not implement the final write) if the value at memory location X has changed during processing of the critical section. For example, in the above example, a compare-and-swap implementing the write for thread 2 would find that the current value for location X (1200) does not match the value (1000) read earlier in the critical section, so the write could be suppressed and the critical section of thread 2 repeated based on the latest value read from the memory location. An alternative to using compare-and-swap may be to use a load-exclusive operation to perform the initial read (which in addition to loading the read data for location X will also cause an exclusive monitor to be set for location X). A store-exclusive operation can then perform the final write back to location X. A store-exclusive operation causes the write to location X to be made conditional on the exclusive monitor still being set for location X. Invalidating snoop requests detected as occurring between the load / store exclusive instructions (which can be an indication that another requester has updated, or will update, location X) will cause the exclusive monitor to be cleared for location X so that a subsequent store-exclusive to location X would fail its condition. A loop can be included in the thread software to ensure that following a failed conditional write, the critical section is tried again. These are just some examples of possible techniques for implementing critical sections. It will be appreciated that there are a wide variety of software techniques which can be used to implement such critical sections with protective measures to ensure atomic updates to the shared data, so the techniques discussed below are not limited to any particular technique for implementing such atomic updates. The above example is a very simple example involving a single read, modification and write, but more complex examples may involve multiple dependent memory accesses and could read or update more than one shared data location, and could involve more complex modifications to generate the modified value to be written back, potentially involving multiple dependent arithmetic / logical operations which are too complex to be performed in one instruction on the processing circuitry 6. Hence, in general a shared memory update task may include at least one atomic readmodify-write operation to represent a critical section to be observed atomically with respect to other threads. The critical section starts with a read of the memory location and ends with a conditional write to the location. If critical sections may seem to overlap between threads (e.g. many threads / processors can read a location and have the cache line in shared state at the same time), only one thread will succeed with the corresponding update and other threads will have to restart their critical sections. Such atomic read-modify-write (RMW) operations are normally performed synchronously with the program execution. This is simple since software often depends on the output of the atomic operation. Atomic operations are used on shared memory which is often contended. The CPU may stall on memory accesses to such contended data, this slows down program execution and decreases CPU utilisation. It gets worse with more complex updates that consist of multiple dependent atomic (and non-atomic) accesses. Thus, synchronous atomic operations are not ideal. In scenarios with heavy memory contention, software could be stalled for very long periods of time as all previous threads must first complete their updates. Hence, asynchronous operations can be particularly useful for software requiring shared memory updates to be performed using atomic read-modify-write operations, particularly for the more complex types of atomic RMW function that involve multiple dependent atomic / non-atomic accesses. This will enable the CPU to avoid waiting on the completion of the shared memory update, and instead perform other useful work. Hence, shared memory updates can be performed asynchronously as an extension task using the extension processing circuitry 23, without blocking the software thread. This technique could be used for many types of shared memory update task, depending on design choice of which particular types of shared memory update task are supported by a given implementation of the extension processing circuitry 23. Suitable shared memory updates may primarily include those which behave more like stores and can complete in the background without returning any results to software. Examples are queue enqueue and lock release operations. However, also operations which return results that software depends on in order to continue execution (e.g. queue dequeue) can be performed asynchronously, because the software could use light-weight context switching (e.g. fibers or coroutines) to continue execution while the asynchronous operation completes. When later returning to the original light-weight context, the completion status of the asynchronous operation can be checked, or alternatively a scheduler could check the completion status of asynchronous operations and schedule (wake up) any fiber / coroutine whose operation has completed. Spin-waiting on shared memory locations and potentially modifying that and other locations could also be performed asynchronously. Some examples are waiting for a lock to be free and attempting to acquire it (vanilla spin lock) or waiting for a lock to become ours (e.g. ticket lock, MCS or CLH lock). Other examples of shared memory update tasks that could be offloaded to the extension processing circuitry 23 include operations performed on any of the following types of shared memory data structures: • Ring buffer (single / multi producer, single / multi consumer). The enqueue operation for enqueuing an item to the ring buffer, and / or the dequeue operation for dequeuing an item from the ring buffer could each be offloaded as a given example of an extension task to be performed on the extension processing circuitry. Here the enqueue and dequeue operations read head and tail “pointers” (actually free-running indexes), compute the number of available slots in the ring buffer and atomically update (using CAS - atomic compare and swap) the tail or head pointer, and then the elements in the actual ring array are read or written (copied to / from private memory) and finally some more metadata is updated atomically. • Michael &Scott lock-free queue. Again, possible examples of an extension task can include the enqueue operation and / or dequeue operation for enqueuing / dequeuing items on the Michael &Scott lock-free queue. The enqueue performs 2 CAS operations on shared data + 1 CAS to help other enqueue operation. The dequeue operation loads some shared data, performs a memory copy operation (memcpy) from private data to shared data and then performs a CAS on shared data. • Treiber lock-free stack. Again, possible examples of an extension task can include the enqueue operation and / or dequeue operation for enqueuing / dequeuing items on the Treiber lock-free stack. The enqueue (push) operation reads shared data, writes private data and performs 1 CAS operation on shared data. The dequeue (pop) operation reads shared data, reads more shared data dependent on the first read, writes private data and performs 1 CAS operation on shared data. • MCS lock. Possible examples of an extension task can include the acquire operation to acquire the lock and / or the release operation to release the lock. The acquire (lock) operation reads and writes (store, atomic-exchange) shared data, and also waits on the shared location (to have a specific value). The release (unlock) operation reads and writes (store, CAS) shared data, and also conditionally waits on the shared location. These are just a selected subset of possible complex shared memory operations which could be implemented as extension tasks offloaded to be performed asynchronously by the extension processing circuitry 23. Other examples can include operations performed on non-blocking hash tables (cuckoo or hopscotch), or multi-location CAS operations (which are built from a sequence of single-location CAS operations). It will be appreciated that there are many other possible shared memory update functions which would normally be implemented as library code written using instructions to be processed synchronously by the processing circuitry 6. However, in an implementation supporting a given one of such shared memory update tasks as an extension task on the extension processing circuitry 23, the extension processing circuitry comprises hardware circuit logic which can perform the corresponding shared memory update task asynchronously once given appropriate control parameters are provided by the decoding circuitry 13 or processing circuitry 6 in the offload phase. For example, those control parameters may define one or more addresses of the shared data to be processed in the shared memory update task, an identifier of the specific form of the extension task to be performed (e.g. distinguishing between two or more types of shared memory update function which are supported by respective instances of extension processing logic in hardware) and / or other control parameters which could be passed to the extension processing either via registers 8, via a private cache associated with the processing circuitry 6 or in memory. Multiple operations and updates processed by the extension processing circuitry 23 may be related and dependent. E.g. the output of one operation (e.g. a memory address or some counter value) might be used as an input to a further update. The different operations would then be ordered according to their dependencies and information transferred between them. Information can be transferred through CPU registers (for synchronous execution) or designated memory locations (via the private cache shared by the processing circuitry 6 and extension processing circuitry 23, or via main memory). Hence, the technique described above enables certain (complex) shared memory updates (“operations”) to be handed over to an “automaton” (the extension processing circuitry 23) which performs the operations asynchronously from the program execution. If necessary, software executing on the processing circuitry 6 can check for completion status and results (either in a blocking or non-blocking way). In some examples, an offload instruction with a variable number of register operands specifies the specific “atomic” operation and its parameters (e.g. addresses and values). The instruction causes the decoding circuitry 13 to send a request to the automaton associated with the PE, and a corresponding extension task identifier (handle) can be returned which is used to identify the operation. The register operands may specify the addresses of memory locations. Some of these memory locations are used for input or output or both. When a memory location is used for output from one operation and input to another operation, a dependency is created, and the operations are ordered accordingly. Another instruction can be used to check the status (e.g. in-progress, completed, interrupted) of the asynchronous operation, and the handle is passed in a register and the status is returned in another register (may include the status register with condition codes). A third instruction can be used to return the results (outputs) (if any) of the (completed) asynchronous operation and reclaim the handle. A variable number of registers are used for the outputs. Results may also have been written to memory and are available after the operation has completed. Other instructions which communicate with the asynchronous offload automaton may also exist. Such instructions might be used for error handling (e.g. when handling page faults caused by the asynchronous atomic operation) and OS context switches (managing availability of the extension processing circuitry 23 to a particular process executing on the processing circuitry 6). Since instructions are used to communicate with the automaton, the automaton can be located close to the CPU core or even implemented as a part of the CPU core. This approach can reduce the otherwise high performance costs associated with shared memory update tasks blocking ongoing execution at the processing circuitry 6 due to the shared memory update task stalling in the case of high contention with other threads for updates to the same shared memory data. By performing the shared memory updates asynchronously on the extension processing circuitry 23, the processing circuitry 6 is unblocked to allow forward progress on other instructions. This can greatly improve performance for shared memory workloads. Figure 2 illustrates a method of processing instructions. At step 200, the decoding circuitry 13 decodes instructions. At step 202, the processing circuitry 6 performs data processing operations in response to the instructions decoded by the decoding circuitry 13. Figure 3 illustrates a method of offloading a shared memory update task. At step 210, it is determined whether an instruction decoded by the decoding circuitry 13 is a shared memory update task offloading instruction. In some examples, it could be the decoding circuitry 13 itself which determines that a given instruction is a shared memory update task offloading instruction (or at least that the instruction is an extension task offloading instruction which requires offload of an extension task to the extension processing circuitry). In some examples where the shared memory update task offloading instruction is an extension task offloading instruction which specifies an extension operation identifier which identifies the particular type of extension task to be performed, the extension operation identifier may not necessarily be decoded by the decoding circuitry 13, and it might be downstream circuitry (either at the processing circuitry 6 or at the extension processing circuitry 23) that interprets that extension operation identifier and so determines that this particular instance of the extension task offloading instruction represents the shared memory update task offloading instruction. Also, in some examples, the shared memory update task offloading instruction may be an instruction type which is more generic and can also be used for other operations not involving offload of an extension task to the extension processing circuitry 23. For example, in some implementations the configuration interface for controlling the extension processing circuitry 23 may involve a set of system registers associated with the processing circuitry 6. A system register updating instruction may have an encoding which identifies a register identifier of the particular system register to be updated, and so some instances of system register updating instructions may specify an identifier of one of the system registers for controlling the extension processing circuitry 23 (e.g. a launch register for controlling launching of a command to the extension processing circuitry 23) and so be treated as the shared memory update task offloading instruction, while other instances of system register updating instructions could specify an identifier of a different system register which has a function unrelated to the extension processing circuitry 23 and so this system register updating instruction would not be treated as the shared memory update task offloading instruction. Similarly, if the configuration interface for controlling the extension processing circuitry 23 involves memory mapped control registers, the shared memory update task offloading instruction may be a store instruction which specifies as its store target address an address mapped to the relevant launch control register used to trigger offload commands to the extension processing circuitry 23, but other instances of store instructions specifying other addresses would not be treated as shared memory update task offloading instruction. In this case, it might be that the circuitry which identifies whether a particular decoded instruction represents the shared memory update task offloading instruction is circuitry provided within the processing circuitry 6 (e.g. in a load / store unit) which checks the target address of a store instruction and determines whether that target address is an address mapped to the launch control register. Hence, in general at step 210, some circuitry determines whether a decoded instruction decoded by the decoding circuitry 13 is a shared memory update task offloading instruction, but it will be appreciated that the circuitry performing step 210 is not necessarily the decoding circuitry 13 itself. If the decoded instruction is a shared memory update task offloading instruction, then at step 212 the decoding circuitry 13 and / or the processing circuitry 6 controls offloading of a shared memory update task to the extension processing circuitry 23. The shared memory update task is to be performed asynchronously with respect to other operations performed by the processing circuitry 6. If the decoded instruction is not a shared memory update task offloading instruction, then at step 214 another type of instruction is processed. Figure 4 illustrates a method for performing the shared memory update task on the extension processing circuitry 23. At step 230, the extension processing circuitry 23 obtains parameters relating to the shared memory update task. For example, the parameters may define addresses of one or more data items to be accessed in memory, operands for operations to be performed in the shared memory update task, or other control parameters. The parameters could be obtained from the processor registers 8 or from a cache or main memory. At step 232 the extension processing circuitry 23 starts performing the shared memory update task. The shared memory update task could include one or more preliminary operations before starting a critical section involving an atomic read-modify-write update operation, but eventually the shared memory update task reaches a critical section to be performed atomically with respect to other threads of processing. At step 234 the extension processing circuitry 23 attempts to perform the critical section and checks at step 236 whether the critical section was successful. The critical section may fail if a condition checked within the critical section is not satisfied, where that condition is designed to be not satisfied in scenarios where another thread accesses shared memory data used in the critical section in the period between a read of the shared data and a write of modified data depending on the read value for the shared data. If the critical section is successful, then at step 238 the shared memory update task can be completed and result information can be made available for obtaining by the processing circuitry 6. For example, the result information may be stored at one or more locations in memory, and / or could be returned to one or more registers 8 of the processor in response to the decoding circuitry 13 decoding a further result obtaining instruction (e.g. the XSYNC instruction described below). If the critical section is unsuccessful, then at step 240 the extension processing circuitry determines whether a timeout condition is satisfied. For example, the timeout condition may be considered to be satisfied if a certain number of attempts at performing the critical section have already been performed without success, or if the time since the start of the shared memory update task has exceeded a threshold. If the timeout condition is not yet satisfied, then at step 242 the extension processing circuitry repeats the critical section to try once more to make progress in the critical section. When the critical section is repeated, the initial read of shared memory data can be repeated so that any updates made by other threads are considered for the next attempt at the critical section (alternatively, the conditional write operation executed at the end of a critical section may have a side effect of returning the current value of an item of shared memory data to the extension processing circuitry, in which case the repeated instance of processing the critical section may not need to read the shared data again). Hence, the extension processing circuitry may spin through steps 234, 236, 240, 242 a variable number of times until either the critical section is successfully completed or the timeout condition is satisfied. If the timeout condition is satisfied, then at step 244 the extension processing circuitry 23 halts the shared memory update task, and sets a status indication to a “failed” state which can be read by the processing circuitry 6 to determine that the shared memory update task did not succeed. Software executing on the processing circuitry may use that status indication to determine whether to try once more to offload the shared memory update task to the extension processing circuitry 23 or whether to perform another operation (e.g. switch to a fallback path which performs the same atomic read-modify-write memory update using synchronous instructions executing on the processing circuitry 6). While Figure 4 shows a relatively simple example involving a single critical section, it will be appreciated that some more complex atomic updates may involve multiple critical sections, so that the completion of the shared memory update task as a whole may depend on successfully completing multiple critical sections. Figure 1 discussed above shows components of an individual processor 10. However, Figure 5 shows an example showing the processor in a wider context 10 of a data processing system 2. The processing system 2 comprising at least one CPU 10 which comprises the decoding circuitry 13, processing circuitry 6, registers 8 and extension processing circuitry 23 as discussed above. There could also be at least one other CPU 10 which does not comprise the extension processing circuitry. The CPUs 10 are examples of memory system requesters which access shared memory 110 via an interconnect 106. The memory 110 may also be shared with other types of memory system requester, such as a graphics processing unit (GPU) 100, input / output (I / O) device 102 or remote hardware accelerator 104. The hardware accelerator 104 is coupled to the memory system interconnect 106, remote from the CPU 10. Software executing on a CPU 10 can configure the hardware accelerator 104 to perform a particular class of processing function on data stored in memory 110, by configuring control data structures also stored in the memory 110 which define command queues and / or other parameters for controlling the hardware accelerator 104. Hardware accelerator commands are defined as part of a command set dedicated to a particular hardware implementation of hardware accelerator, rather than being generic ISA instructions in the instruction set supported by the instruction decoding circuitry 13 of a CPU 10. As the configuration path between the processing circuitry 6 of a CPU 10 and the hardware accelerator 104 is via memory-based data structures, offloading of operations from CPU 10 to hardware accelerator 104 is much slower than offloading of an extension task from processing circuitry 6 to extension processing circuitry 23, as memory accesses to those structures may contend for bandwidth on the memory system interconnect 106 shared with the other requesters 10, 100, 102. The interconnect 106 may be a coherent interconnect which includes home node circuitry (not shown in Figure 5) to manage coherency between data cached in private caches of the requesters 10, 100, according to a particular coherency protocol. Often the shared memory update tasks of the type described above may cause requests for data to be cached in a private cache of a given requester in an exclusive coherency state in which further modification can be made to the data without checking again with the home node. When multiple threads executing on different processors 10 contend for shared data, this may cause each thread to request data in the exclusive coherency state. The home node circuitry at the interconnect 106 may queue such requests for exclusive access to data and process each request in turn such that while one requesting thread executing a critical section gets a go at completing its critical section, other threads seeking to access the same data may have to wait for their turn. Figures 6 and 7 show two examples of how the extension processing circuitry 23 could be provided in association with a particular processor 10 (CPU). In the example of Figure 6, the processor (CPU) 10 is schematically shown to have a pipelined configuration, which for the purposes of brevity and clarity is shown in a conceptual representation here. The illustrated pipeline stages comprise an instruction cache 11, a fetch stage 12, a decode stage 13, a micro-op cache 14, an issue stage 15, and a register access stage 16. A sequence of instructions is retrieved from memory (not shown) and cached in the instruction cache 11. The fetch stage 12 controls which instructions are retrieved as the sequence of instructions and these instructions are then decoded in the decode stage 13. This decoding essentially identifies the type of each instruction, as well as any further operands specified by the instruction, and generates control signals to control the remainder of the apparatus to perform the data processing operation(s) defined by the instruction. Decoding the instructions may comprise splitting an instruction into one or more micro-ops, and these micro-ops can be cached in the micro-op cache 14. The final stage of the pipeline before execution is the issue stage 15, where instructions (or micro-ops) are queued pending the availability of the register values they specify as operands and the corresponding functional unit of the data processing pipeline which will carry out the defined operation. Generally the data processing operation(s) defined by the instructions are carried out by the functional units that form part of the data processing pipeline, namely the load / store unit 17, the execute unit 18, and the execute unit 19. These latter execute units may for example be arithmetic logic units (ALUs), floating point units (FPUs), and so on. The functional units that form part of the data processing pipeline perform their data processing operations on data values which are provided from a set of registers (conceptually represented by the register access stage 16 in the figure) and result values of those data processing operations are returned to the set of registers. The load / store unit 17 is provided for the purpose of storing values from the set of registers to the memory system, of which only a level 1 cache 21 and a level 2 cache 22 are shown in the figure. At least the L1 cache 21 is private to the CPU 10 and the L2 cache 22 could be either private or shared with another CPU 10, when part of a wider data processing system. The data processing apparatus 10 is also shown to comprise a branch unit 20, which is used to execute branch instructions and which may feed back information about branch outcomes to the fetch stage 12 for use in training a branch predictor provided in the fetch stage 12 for predicting outcomes of branch instructions. The processor 10 also comprises extension processing circuitry 23, which is provided to support efficient performance of one or more defined functions, including the shared memory update task described earlier. The extension processing circuitry is closely associated with the data processing pipeline and is configured to perform the defined function (also referred to herein as a delegated task or extension task) in response to a delegation signal received from the data processing pipeline. The extension processing circuitry 23 is an example of a threadlet extension (TE). The sequence of operations it carries out to perform the defined function can be referred to as a threadlet. The extension processing circuitry 23, although closely associated with the data processing pipeline, is configured to perform the delegated task asynchronously to the data processing operations performed by data processing pipeline. Threadlets are functions or collections of operations that can be executed asynchronously relative to other CPU activity once launched. The directive or command sent to the extension processing circuitry 23 to initiate the delegated task is generated in response to an extension task offload instruction, such as an extension start instruction defined for this purpose in the instruction set of the data processing pipeline. Thus, an extension start instruction progresses along the data processing pipeline in the manner that any other CPU instruction would, but when the decoding circuitry 13 identifies the extension start instruction it can signal directly to the extension processing circuitry 23. The close integration of the extension processing circuitry 23 with data processing pipeline is illustrated by the fact that the extension processing circuitry 23 has direct access to the load / store unit 17, and thus it shares the data processing pipeline’s path to memory (e.g. having access to the private cache 21 of the CPU 10). The extension processing circuitry 23 can also share translation table walk circuitry (not shown in Figure 6) which is used to obtain address translation information from memory. The extension processing circuitry 23 also has access to the set of registers 8 accessed by register access stage 16, such that for example, the extension start instruction can specify one or more registers as operands, and the values from these registers are then passed directly to the extension processing circuitry 23 in association with the command sent to initiate the delegated task. Upon completion of the task, results of the delegated task can be returned to the register values via an extension synchronisation instruction. Figure 7 schematically illustrates an alternative implementation of the apparatus 10 according to some examples. This example provides a comparison to the examples of Figure 6, in which examples the extension processing circuitry was closely embedded with the data processing pipeline, to the extent that those instances of extension processing circuitry may be considered to be within the CPU. In the example of Figure 7, the apparatus 10 comprises a CPU 51 and separate extension processing circuitry (threadlet extension) 23 which are not as closely integrated. For example this is illustrated by the fact that each has its own path to memory, with an L1 cache 53 private to the CPU 51 and an L1 cache 54 private to the threadlet extension 23. They share the L2 cache 55 (which can still be regarded as a private cache of the CPU 51 as this cache may not be shared with any other memory system requester, so a cache coherency protocol implemented by system interconnect 106 may treat the L2 cache as if it is a private cache). Nevertheless, the threadlet extension 23 remains tightly coupled to the CPU 51, and can be launched quickly when an extension start instruction is encountered in the CPU pipeline specifying the function this threadlet extension 23 performs. The threadlet extension 23 can get data directly from CPU registers at the start of its execution. Upon completion, it can return values via an extension synchronisation instruction. Figure 7 also shows the threadlet extension 23 as having its own private TLB 56, in which it can cache currently used address translations. As a preparatory step before or associated with the delegation signal, content from the TLB 57 in the CPU 51 can be copied into the private TLB 56 in order to pre-warm this cache before the threadlet begins operation. If a memory access request issued by the extension circuitry 23 misses in its private TLB 56, a signal may be issued to a memory management unit (MMU) 58 of the CPU 51 which causes translation table walk circuitry 59 of the CPU 51 to obtain address translation information from memory and return the required address translation information to the private TLB 56 of the threadlet extension processing circuitry 23 for use in translating a memory address specified by the memory access request. Figure 8 schematically illustrates an extension start instruction for delegating a task to one of several instances of extension processing circuitry 109, 110, 111 (collectively corresponding to the extension processing circuitry 23 described earlier), in accordance with some examples. Here, the XSTART instruction takes the form: XSTART {x0 - x7}, #imm. In this example, there are multiple instances of extension processing circuitry and the immediate value #imm is used as an extension operation identifier to select between them. Thus an XSTART instruction 105 of this form, when decoded by the CPU’s decoder 13, causes the content of registers x0-x7 to be retrieved from the registers 8. Extension control circuitry 108, on the basis of the immediate value #imm (or signals based on the immediate value #imm) directs the register values to the selected extension processing circuitry 110. In this case, the other instances of extension processing circuitry 109 and 111 are not activated by this instruction. While Figure 8 shows an example where the extension operation identifier is specified as an immediate value, other examples could designate the extension operation identifier using a register operand. Each instance of the extension processing circuitry 109, 110, 111 could for example be configured to perform a different type of extension task. At least one of the extension processing circuit instances supports a shared memory update task as its extension task. Hence, when the extension operation identifier (#imm) specified by the XSTART instruction corresponds to a shared memory update task, this will control the corresponding instance of extension processing circuitry 110 to perform that shared memory update task. In some examples, extension processing circuit instances 109, 110, 111 may be provided for supporting two or more distinct types of shared memory update task, with the extension operation identifier of the XSTART instruction distinguishing which particular shared memory update task to perform. The register operands x0-x7 passed with the extension offload command can specify parameters such as the address of data to be accessed in memory within the shared memory update task and any other control parameters. The particular steps to be taken to perform the shared memory update task do not need to be explicitly identified by the control parameters or the XSTART instruction, as they are hardwired into the circuit logic of the extension processing circuitry (documentation available to the software developer or compiler developer may identify what operations should be expected when requesting that an extension task with a given value for the extension operation identifier (#imm) is performed on a given system implementation). Different system implementations may support different sets of extension tasks using the extension processing circuitry, so the extension processing circuitry 23 (or the configuration interface for controlling the extension processing circuitry) may support a mechanism by which a given extension task offload may be rejected if the particular system implementation running the software requesting the offload does not actually support the requested type of extension task. This failure indication may be used by the software to select an alternative fallback path (e.g. a sequence of operations using instructions processed synchronously on the main processing pipeline). As shown in Figure 8, when the extension processing circuitry 23 accepts a given extension task, the extension processing circuitry 23 assigns an extension task identifier (“handle”) to the specific instance of the extension task that has been accepted, and returns the handle to the processing circuitry 6, e.g. by writing it to a given destination register of the register file 8. The handle can be used to differentiate respective instances of extension task, and can be used to query status of a particular instance of an extension task or trigger return of results. The extension task identifier (handle) is distinct from the extension operation identifier (#imm), since the extension operation identifier identifies a particular class of extension task, so will be the same whenever that class of extension task is to be performed, while the extension task identifier distinguishes different instances of extension tasks (and so if the same class of extension task is requested multiple times to be performed on different data values, say, each instance of requesting the extension task is assigned a different extension task identifier). Figure 9 schematically illustrates extension processing circuitry accepting a delegated task in accordance with some examples. The data processing pipeline 120 of a processor 10 is shown to include a commit stage 121. An instruction which passes through this data processing pipeline 120 will finally be committed, when it is definitively known that this instruction should be executed, or will be cancelled when it is established that this instruction should not be executed. For example, when the data processing pipeline follows a prediction for a particular branch made by its branch prediction unit, when that branch is resolved as taken or not taken, further instructions which were provisionally executed on the assumption that the branch prediction was correct be committed. Here, an XSTART instruction has caused a task to be delegated to the extension processing circuitry 122, and commits when the extension processing circuitry 122 signals to the data processing pipeline 120 that it is accepting the task. The XSTART instruction could also be committed if the extension processing circuitry 23 rejects accepting the extension task, which could arise because, say, the requested extension task is not supported by the particular extension processing units 109, 110, 111 present on this system implementation, or because while supported, the extension processing units 109, 110, 111 are currently busy (e.g. because they were previously assigned to perform an extension task on behalf of the different processing context to the thread currently executing). Figure 10 illustrates an example of an extension task status checking instruction (XSTATUS instruction) specifying an extension task identifier indicative of a specific instance of an extension task offloaded to the extension processing circuitry - i.e. the handle that was returned by the extension processing circuitry 23 at the time of accepting the offloaded extension task. For example, the extension task identifier can be specified in a register referenced by a register field (xA) encoded in the XSTATUS instruction. In response to the XSTATUS instruction, the instruction decoding circuitry 13 provides a signal to the extension processing circuitry 23 specifying the extension task identifier. In response, the extension processing circuitry 23 returns a status indication to the processing circuitry 6, e.g. by writing to one of the registers 8. The status indication may distinguish information such as whether the extension processing circuitry 23 has completed the assigned extension task or has been interrupted, or whether an error has occurred, for example. Figure 11 illustrates an example of an extension task result synchronisation instruction (XSYNC instruction) specifying an extension task identifier indicative of a specific instance of an extension task offloaded to the extension processing circuitry. For example, the extension task identifier can be specified in a register referenced by a register field encoded in the XSYNC instruction. The XSYNC instruction can also encode other register fields which may define destination registers to which result values are to be written in response to the XSYNC instruction. In response to the XSYNC instruction, the instruction decoding circuitry 13 provides a signal to the extension processing circuitry 23 specifying the extension task identifier. In response, the extension processing circuitry 23 returns one or more result values to respective registers 8 of the processing circuitry 6. As well as results being passed via registers 8, it is also possible that the completion of the extension task may signal that further results are available from memory, which have been written to memory during the extension task. While Figures 8 to 11 show examples of dedicated instruction types for controlling the extension processing circuitry 23, as mentioned above it is also possible to provide a registerbased control interface for configuring the extension processing circuitry 23 and requesting return of status or result values, in which case similar functionality may be controlled by instructions which write to a control register (e.g. a system register or memory-mapped register). In some cases, it may be that the ISA does not supporta single instruction which can both write an operand from a source general purpose register to a system register and read a value from a system register to a destination general purpose register, so in some cases the functionality of one of the instructions discussed above may be split into two separate instructions: - a system register write instruction to write an operand (e.g. an extension task identifier of a specific instance of an extension task to be referenced in a subsequent instruction) from a specified source general purpose register to a given system register; and a system register read instruction, to read a value (e.g. the status information corresponding to the XSTATUS instruction described above, or part of the result information returned by the XSYNC instruction described above) corresponding to the extension task identifier stored in the given system register, and return that value to a specified destination general purpose register. Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein. For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concepts. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a HDL representation of the one or more logic circuits embodying the apparatus in Verilog, System Verilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using system-level modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts. Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly. The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated. Such computer-readable code can be disposed in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept. Figure 12 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is 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. Varieties of 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 730, optionally running a host operating system 720, supporting the simulator program 710. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or 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, Pages 53 - 63. To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 730), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 710. Thus, the program instructions of the target code 700 described above, may be executed from within the instruction execution environment using the simulator program 710, so that a host computer 730 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features. The simulator program 710 enables software development for software which will make use of the hardware features discussed above to start to be developed before any hardware actually supporting those features is available. The simulator program 710 includes decoding program logic 712, processing program logic 714 and extension processing program logic 716 which emulates the functionality of the decoding circuitry 13, processing circuitry 6 and extension processing circuitry 23 described earlier. Hence, the decoding program logic 712 decodes instructions of the target program code and the processing program logic 714 controls the host computer 730 to perform data processing operations in response to the instructions decoded by the decoding program logic 712. For example, the simulator code 710 may include a number of instances of function code corresponding to the respective instructions defined in the instruction set architecture used to writ the target code 700. The decoding program logic 712 may comprise instructions which check the encoding of a given instruction of the target code 700 and select the appropriate function corresponding to that instruction type, depending on the instruction encoding. The processing program logic 714 may comprise the function code itself which is selected by the decoding program logic 712, and which comprises a series of instructions, written in the native instruction set architecture supported by the host hardware 730, to simulate the functionality of the given instruction. In response to a shared memory update task offloading instruction, the decoding program logic 712 is configured to control the host data processing system to simulate offloading, to extension processing circuitry 714, of a shared memory update task to be performed by the extension processing circuitry asynchronously with respect to other data processing operations performed by simulated processing circuitry in response to the target program code. The shared memory update task comprises at least one atomic read-modify-write update to shared memory data. In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation. In the present application, lists of features preceded with the phrase “at least one of mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination. Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. An apparatus comprising:decoding circuitry configured to decode instructions; andprocessing circuitry configured to perform data processing operations in response to the instructions decoded by the decoding circuitry; wherein:in response to a shared memory update task offloading instruction, the decoding circuitry or the processing circuitry is configured to control offloading, to extension processing circuitry, of a shared memory update task to be performed by the extension processing circuitry asynchronously with respect to other data processing operations performed by the processing circuitry, the shared memory update task comprising at least one atomic read-modify-write update to shared memory data.

2. The apparatus according to claim 1, in which the shared memory update task comprises at least one operation to trigger a request for the shared memory data to be brought into a cache in an exclusive coherency state.

3. The apparatus according to any preceding claim, in which the shared memory update task comprises, in response to a failure of a critical section comprising the at least one atomic readmodify-write update, retrying the critical section.

4. The apparatus according to any preceding claim, in which the shared memory update task comprises a set of multiple memory accesses for which a later memory access in the set is dependent on an earlier memory access in the set.

5. The apparatus according to any preceding claim, in which the shared memory update task comprises updates to two or more cache lines of shared memory data.

6. The apparatus according to any preceding claim, in which the shared memory update task comprises at least one read operation, a set of arithmetic / logical operations dependent on the at least one read operation, and the at least one update to shared memory data dependent on the plurality of arithmetic / logical operations, wherein the set of arithmetic / logical operations is too complex to be performed synchronously by the processing circuitry as a unitary operation in response to a single instruction of an instruction set architecture supported by the decoding circuitry and the processing circuitry.

7. The apparatus according to any preceding claim, in which the shared memory update task offloading instruction comprises an extension task offloading instruction specifying an extensionoperation identifier indicative of which of a plurality of extension tasks is to be performed by the extension processing circuitry, where for the shared memory update task offloading instruction the extension operation identifier has a value corresponding to the shared memory update task.

8. The apparatus according to any preceding claim, in which the shared memory update task offloading instruction specifies at least one register operand indicative of one or more parameters to be passed to the extension processing circuitry for controlling the shared memory update task.

9. The apparatus according to any preceding claim, in which the shared memory update task offloading instruction comprises an instruction which writes to a control register.

10. The apparatus according to any preceding claim, in which, in response to the shared memory update task offloading instruction or an extension task identifier obtaining instruction subsequent to the shared memory update task offloading instruction, the processing circuitry is configured to obtain from the extension processing circuitry an extension task identifier used by the extension processing circuitry to identify a specific instance of the shared memory update task initiated by the shared memory update task offloading instruction.

11. The apparatus according to any preceding claim, in which, in response to an extension task status checking instruction associated with an extension task identifier indicative of a specific instance of an extension task offloaded to the extension processing circuitry, the processing circuitry is configured to obtain status information indicative of a current status of the extension task at the extension processing circuitry.

12. The apparatus according to any preceding claim, in which when the shared memory update task is accepted by the extension processing circuitry, the processing circuitry is configured to commit the shared memory update task offloading instruction without waiting for completion of the shared memory update task by the extension processing circuitry.

13. The apparatus according to any preceding claim, in which the processing circuitry is configured to obtain a result of the shared memory update task in response to the decoding circuitry decoding an extension task result obtaining instruction separate from the shared memory update task offloading instruction.

14. The apparatus according to any preceding claim, in which, in response to an extension task result synchronisation instruction specifying at least one destination register and an extension task identifier indicative of a specific instance of an extension task offloaded to the extension processing circuitry, the processing circuitry is configured to assign to the at least onedestination register result information obtained from the extension processing circuitry by processing the extension task identified by the extension task identifier.

15. The apparatus according to any preceding claim, in which the processing circuitry is configured to continue processing of other instructions while the shared memory update task is performed by, or pending at, the extension processing circuitry.

16. The apparatus according to any preceding claim, comprising a central processing unit (CPU) comprising the decoding circuitry, the processing circuitry and the extension processing circuitry.

17. The apparatus according to any preceding claim, in which the decoding circuitry comprisesshared decoding circuitry configured to decode arithmetic / logical instructions, branch instructions and load / store instructions of an instruction set architecture supported by the decoding circuitry and the processing circuitry, as well as being configured to decode the shared memory update task offloading instruction.

18. The apparatus according to any preceding claim, comprising a configuration signal path configured to convey control signals to the extension processing circuitry in response to the shared memory update task offloading instruction;wherein the configuration signal path is separate from a load / store data path used by the processing circuitry to issue load / store memory access requests to a memory system.

19. The apparatus according to any preceding claim, in which during offloading of the shared memory update task to the extension processing circuitry, the extension processing circuitry is configured to directly access state in architectural registers defined by an instruction set architecture supported by the decoding circuitry and the processing circuitry.

20. The apparatus according to any preceding claim, in which the processing circuitry and the extension processing circuitry share at least one of:a private cache private to a processing element comprising the processing circuitry and the extension processing circuitry and inaccessible to any other processing element of the apparatus; andtranslation table walk circuitry configured to control translation table walk operations for obtaining translation table data from a memory system.

21. The apparatus according to any preceding claim, comprising the extension processing circuitry.

22. The apparatus according to claim 21, in which the extension processing circuitry is configured to support the shared memory update task and another extension task being in progress simultaneously; andthe extension processing circuitry is configured to control ordering of the shared memory update task with respect to the other extension task based on dependencies between the shared memory update task and the other extension task.

23. Computer-readable code for fabrication of an apparatus according to any preceding claim.

24. A computer program comprising instructions which, when executed by a host dataprocessing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: decoding program logic configured to decode instructions of the target program code; and processing program logic configured to control the host data processing apparatus to perform data processing operations in response to the instructions decoded by the decoding program logic; wherein:in response to a shared memory update task offloading instruction, the decoding program logic is configured to control the host data processing system to simulate offloading, to extension processing circuitry, of a shared memory update task to be performed by the extension processing circuitry asynchronously with respect to other data processing operations performed by simulated processing circuitry in response to the target program code, the shared memory update task comprising at least one atomic read-modify-write update to shared memory data.

25. A method comprising:decoding instructions using decoding circuitry;in response to the decoded instructions, performing data processing operations using processing circuitry; andin response to a shared memory update task offloading instruction, offloading, to extension processing circuitry, a shared memory update task to be performed by the extension processing circuitry asynchronously with respect to other data processing operations performed by the processing circuitry, the shared memory update task comprising at least one atomic read-modify-write update to shared memory data.36

Images