GB2506169A

GB2506169A - Limiting task context restore if a flag indicates task processing is disabled

Info

Publication number: GB2506169A
Application number: GB1216997.5A
Authority: GB
Inventors: Robert Graham Isherwood; Guixin Wang; Hugh Jackson
Original assignee: Imagination Technologies Ltd
Current assignee: Imagination Technologies Ltd
Priority date: 2012-09-24
Filing date: 2012-09-24
Publication date: 2014-03-26
Also published as: GB201216997D0

Abstract

A processor includes a flag in a hardware register. Setting the flag enables interrupt processing but disables task processing. Clearing the flag enables both interrupt and normal task processing. The value of the flag is stored as part of a task context. When an interrupt occurs, the context associated with a task is restored, including the flag. If the flag is set, then the whole context is not restored. If the flag is not set, the processor may save the current context when an interrupt occurs. The processor may be a multi-threaded processor. In this case, there may be a flag for each thread.

Description

LOW LATENCY INTERRUPT WAITING MODE

BackQround Reducing the power consumption of electronic devices, such as portable computing devices (e.g. smartphones, laptops, tablet computers, games consoles etc.), is beneficial because it increases the battery life or enables use of smaller form-factor batteries for the same battery life. Where such electronic devices are not battery-powered but instead are plugged into an electricity supply, reduction of power consumption reduces the operating costs and environmental impact.

When running software on a processor, there are often times when the processor is idle; for example, where the program is waiting for an interrupt to begin execution again. In such a situation, an instruction sequence may be run at background or interrupt level on the processor which puts a part of the processor into an idle or lower power state until the interrupt arrives. The interrupt itself may be triggered by any mechanism, including the expiry of a timer or an external access (e.g. a user input). When the interrupt arrives, an interrupt sequence begins (context save, Interrupt Service Routine, context restore) and the context save part of the sequence introduces a delay before instructions can be executed, even where the processor has not been powered down in any way. Where the processor has been powered down, exit from a specific power down instruction state as the processor wakes up and the subsequent interrupt handling sequence that then follows contributes to the delay and load on a processor that is handling interrupts whilst otherwise idle.

The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known methods of operating a processor or known methods of handling interrupts.

Summary

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

A low latency interrupt waiting mode is described. In one embodiment, a method is described in which a thread of a processor is put into an execution state in which interrupt processing is enabled and background processing is disabled. The thread enters this execution state when a mode bit associated with that thread is set in a register. In various embodiments, the mode bit is set indirectly by a scheduler, such as a background task scheduler, by selecting a task that has the mode bit set in its context. In various embodiments, the method further comprises an optimized exit sequence from the execution state in which context is not fully restored and need not be re-saved when a subsequent interrupt occurs. In various embodiments, the processor is a multi-threaded processor and there is a separate mode bit for each thread. In other embodiments, the processor is a single-threaded processor.

A first aspect provides a method of operating a processor, the method comprising, in response to an interrupt relating to a thread in the processor: restoring context associated with a next task, wherein restoring context associated with the next task sets or clears a mode bit associated with the thread in a hardware register in the processor; and if the mode bit associated with the thread is set in the hardware register, putting the thread into an execution state in which interrupt processing is enabled and background processing is disabled.

A second aspect provides a processor comprising: one or more registers arranged to store a mode bit for a thread as part of context associated with a task; and hardware logic arranged to: restore context associated with a next task from memory to the one or more registers and thereby set or clear the mode bit for a thread; and if a mode bit for the thread is set in the one or more registers, to put the thread into an execution state in which interrupt processing is

enabled and background processing is disabled.

A third aspect provides a multi-threaded processor substantially as described with reference to figure 1 of the drawings.

A fourth aspect provides a method of operating a processor substantially as described with reference to any of figures 2-5 of the drawings.

The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of non-transitory (or tangible) storage media include disks, thumb drives, memory cards etc and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

This acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls "dumb" or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes" or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.

Brief Description of the Drawings

Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which: Figure 1 is a schematic diagram of a multi-threaded processor; Figure 2 is a flow diagram of an example method of operation of a processor; Figure 3 shows an example timeline for the method shown in figure 2; Figure 4 shows a flow diagram of an example method of setting a mode bit; and Figure 5 shows a flow diagram of another example method of operation of a processor.

Common reference numerals are used throughout the figures to indicate similar features.

Detailed Description

Embodiments of the present invention are described below by way of example only. These examples represent the best ways of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved.

The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

As described above, the standard sequence of events which is triggered by an interrupt comprises: context save, Interrupt Service Routine and context restore. As is known in the ad, the context is the processor state and the context which is saved and restored in the interrupt sequence (e.g. by the hardware on interrupt entry / exit) may comprise a subset of the context. Where the processor is a multi-threaded processor, the context which is saved and restored is the state associated with the thread which is being interrupted. Where the interrupt is used to wake a processor from a low power or idle state, this sequence introduces a delay (which may be referred to as interrupt latency' and measured as a number of cycles) before program instructions are executed.

In one solution, special software instructions are used to cause the processor to enter the lower power state in certain circumstances and these special instructions may, for example, be appended to the end of a special, longer, interrupt sequence.

The methods described below provide an alternative solution to reduce this delay. The methods involve setting a bit in a register which disables background operations (or background processing) and triggers the use of an optimized re-entry sequence which significantly reduces the interrupt latency time (e.g. in some instances, the interrupt latency time is reduced to zero). This bit which is set may be referred to as a mode bit' or control bit'.

Figure 1 shows a schematic diagram of a multi-threaded processor 100. The multi-threaded processor 100 comprises a plurality of threads 102-108 (e.g. four in the example shown). As is well-known in the art, a thread comprises a stream of instructions acting to utilize the resources of the processor and these resources may be specific to a particular thread (e.g. there may be separate fetch and decode stages for each thread) or may be shared between threads (e.g. global registers). The multi-threaded processor 100 further comprises an instruction scheduler 110 which issues instructions to one of a plurality of pipelines (or execution pipelines) 112 within the multi-threaded processor 100. In addition to the instruction scheduler 110, the processor further comprises a background task scheduler. The background task scheduler is a piece of software which schedules whole background tasks once a current background task which is running is either forced or volunteers to give up the thread. The multi-threaded processor 100 additionally comprises one or more registers 114, where a register may be a global register (i.e. a register which may be used by any of the threads 102-108) or a local register (i.e. a register which is dedicated to a particular thread and can only be accessed by that thread).

It will be appreciated that only a subset of the functional elements within a multi-threaded processor are shown in figure 1 and a multi-threaded processor may comprise other elements not shown in figure 1.

Figure 2 is a flow diagram of an example method of operation of a processor, such as the multi-threaded processor shown in figure 1, which may be described with reference to the example timeline shown in figure 3 and for one thread. The method may be initiated when a program running in the background (blocks 200 and 302) interrupts (block 202 and arrow 304) to tell the operating system (OS) that it has completed. The interrupt triggers the interrupt sequence: the context (or state) is saved (blocks 204 and 306) and an interrupt handler (IH1, blocks 212 and 308) is executed. This interrupt handler consults the background task scheduler in a standard way and a further background task may be scheduled and the context for that further background task restored (blocks 213 and 309).

If the background task schedules a standard background task, the context which is restored (in block 213) will contain a mode bit which is not set (such that the mode bit stored in a hardware register will be not set) and as a result, background execution will continue (block 200). Where, however, the task which is scheduled by the background task scheduler has the mode bit set in its context, performing a context restore (in blocks 213 and 309) for that task has the effect of setting the mode bit for the thread in the hardware register. As a result of setting the mode bit in the hardware register, the context restore is not completed (as described in more detail below) and the thread is put into an idle' state (blocks 208 and 310), which may alternatively be referred to as low latency interrupt waiting mode', in which interrupts are processed but background execution is disabled. This state may also be referred to as a low (or lower) power state or sleep state, as parts of the processor may be powered down whilst in this state, as described in more detail below, although in other examples, the thread may remain powered up. In this idle state (which is entered as a result of the mode bit being set in the hardware register), the instruction scheduler 110 will not select instructions from this thread for issue.

The idle state (blocks 208 and 310) which the thread! core enters as a result of the mode bit being set in the hardware register, as described above, may be considered to be a modified state in which the thread is held back, such that it cannot execute any background tasks. This is similar in behavior to other effects, such as when one thread holds back all other threads whilst it performs some performance critical code.

When a subsequent interrupt occurs (block 210 and arrow 312) for a thread which was in the idle state, an optimized re-entry sequence (from the idle state) is used. The use of this optimized re-entry sequence is a consequence of the mode bit being set in the hardware register which caused the optimization of the previous context restore (in blocks 213 and 309). In this optimized sequence, the context save step, which would occur in a standard interrupt sequence (e.g. block 204), is omitted. This context save step can be omitted because, as a consequence of the mode bit being set in a hardware register, the context restore (in blocks 213 and 309) was not completed (i.e. state was not unwound from the stack), background processing was disabled in the idle state and context restore to background level was never performed, so the background task context that has already been saved (in blocks 204 and 306) is still current (i.e. the background execution state are known to have not changed whilst in the idle state).

The optimized re-entry sequence therefore starts with the execution of the interrupt handler (1H2, blocks 212 and 314) and at this stage in the sequence, the mode bit remains set in the hardware register as it is not affected by interrupt processing. Depending on the particular type of interrupt which was received, the interrupt handler may consult the background task scheduler and this may trigger the clearing (or un-setting) of the mode bit in the hardware register as pad of the context restore operation (blocks 213 and 316), as described in more detail below. Where the mode bit is not set it may alternatively be referred to as being unset, clear or cleared. As described above, if the mode bit is cleared by the next context restore (in blocks 213 and 316), such that the mode bit in the hardware register is now not set, background execution is resumed (blocks 200 and 318). If, however, the mode bit in the hardware register is set again (or is not cleared) by the context restore (in blocks 213 and 316), the thread returns to the idle state (block 208).

There may be some interrupts that do not invoke the background task scheduler and hence the background task context remains unchanged and the mode bit in the hardware register also remains unchanged. Examples include those interrupts which solely affect a piece of hardware. Following such interrupts, as the mode bit in the hardware register remains unchanged, the thread returns to the idle state (block 208) and does not return to the

background level.

As shown in the timeline in figure 3, by setting the mode bit in the hardware register (indirectly, in block 309), response to the next interrupt does not require any context save (which would otherwise occur in a standard interrupt sequence) because the previous context restore was incomplete, thus reducing the interrupt latency time significantly (e.g. tending to zero). This is referred to herein as the optimized re-entry sequence. If the core has not been powered down in any way, the interrupt latency time is reduced to zero cycles, as shown in the example in figure 3 (arrow 320).

The method shown in figure 2 and described above may be implemented independently for each thread 102-108 in the multi-threaded processor 100, with each thread having a separate associated mode bit stored in hardware registers. As a result, at any time, the mode bits for different threads may have different values (e.g. set / clear) such that some threads may be in an idle state and other threads may be in any other state.

Where the mode bit is set (in the hardware registers) for all the threads in the processor and as a result all the threads in the processor are in the idle state, the processor may be powered down to a state where either the interrupt detection stays on or an external block handles this behaviour. Even where mode bits are not set for all the threads, setting the mode bit and the resultant entry into the idle state for one or more threads may enable parts of the processor to be powered down, thereby reducing the power consumption of the device.

As described above, the mode bit for a thread is stored in a hardware register, such as a control register for the thread (e.g. within registers 114 in figure 1) and this control register may be a local register or a global register. Where the control register is a global register, means may be provided to protect the register such that other threads cannot modify the mode bit.

In the example described above, the mode bit is part of the core state of the background execution state and so the mode bit is stored within the register state which is saved I restored by interrupt entry / exit (e.g. in blocks 204 and 213 of figure 2). Transition into or out of the idle state for a task (and hence later the thread) may be achieved by modifying the interrupt-entry-saved portion of the background execution state in memory (e.g. as stored in block 204) and this requires no additional physical register states to exist in order to control entry to or exit from the idle state in which background processing is disabled, i.e. no additional register is required for the mode bit.

In the example described above, the mode bit for a thread in a hardware register, which has the effect of informing (or notifying) the hardware for the particular thread not to enter background mode and also triggering use of the optimized re-entry sequence, may be set via context restore. The mode bit in the hardware register is set indirectly by the background task scheduler selecting a task which has the mode bit set in its saved context (i.e. the image of the mode bit in RAM is set). In other examples, the mode bit may be set at any point during the interrupt service routine (e.g. by the background task scheduler or an interrupt handler) and in other examples, the mode bit may be set almost permanently by selecting a single fixed background task context that will never execute with the mode bit set in it (e.g. in situations where there is no background code to run). The setting of the mode bit within a saved context (i.e. the setting of the image of the mode bit in memory) may be performed by the background task scheduler (or any other part of the operating system) and the background task scheduler may set the mode bit within the saved context of the current task or within the saved context of another task.

The mode bit for a thread in the hardware register may be cleared (or unset) via context restore. In the example described above, the mode bit is cleared by the background task scheduler scheduling a task which has the bit unset in its saved context (i.e. the image of the mode bit in RAM is not set). The same method may be used to both set and clear the mode bit in a hardware register, since the operation of clearing the mode bit may be considered to be setting the value of the mode bit (in the hardware register) to zero while the operation of setting the mode bit may be considered to be setting the value of the mode bit to one.

Similarly the same method may be used to both set and clear the image of the mode bit in memory.

An example application where the mode bit may be set permanently may be in a system where the processor runs discrete handlers upon interrupts and has no background code to execute between these discrete handlers. In such an example, blocks 200-204 in figure 2 will never occur as the mode bit will always be set.

Figure 4 shows a flow diagram 400 of an example method of setting and clearing the mode bit in the hardware register in which the mode bit in the hardware register is set indirectly by the background task scheduler selecting a task which has the mode bit set in its stored context (i.e. the image of the mode bit in memory is set) and the mode bit in the hardware register is cleared (again indirectly) by the background task scheduler selecting a task which has the mode bit not set (or cleared) in its stored context.

When a background task completes or otherwise changes state (block 404), the thread returns to interrupt level and performs a context save (block 410). The background task scheduler first functions as the interrupt handler for such a task related event (block 411) and may also modify the stored context associated with a background task (e.g. to set / clear the image of the mode bit in the saved context). The background task scheduler (in block 414) selects a next task (where this next task may, in some situations, be the same as the current task). These two operations are orthogonal in that the selection of a next task is separate from any selection of a task for modification of its stored context (e.g. the background task scheduler may modify the saved context of task A to set the image of the mode bit and may select task B as the next task).

Context is then restored for the selected task (block 416) which sets the value of the mode bit stored in a hardware register and if this mode bit stored in the hardware register is not set, background execution continues (block 418) and the selected task is executed. When this task completes or otherwise changes state (block 404), the thread returns to interrupt level and the method is repeated (e.g. blocks 410, 414, 416 followed by either block 418 or block 420).

Where, however, the mode bit stored in the hardware register is not set, background execution is disabled (block 420). When an interrupt occurs, an optimized re-entry sequence is used (as described above) and an interrupt handler executes (block 412). If the interrupt handler affected any task (Yes' in block 413), the background task scheduler (in block 414) may select a next task and may also modify the stored context associated with a background task (e.g. to set / clear the image of the mode bit in the saved context). Then the context is restored for the selected task (in block 416). If the interrupt handler did not affect a task (No' in block 413), then block 414 is omitted and the previously selected context is implicitly resumed via the context restore (in block 416). If following the context restore (in block 416), the mode bit in the register is set, background execution is disabled (block 420) and if it is not set, background execution resumes (block 418). The method then repeats.

In some examples as all real tasks may have completed, a task may be selected (in block 414) which has stored context which includes a set mode bit and which may be referred to as a null task'. This null task may not contain any code to be run and is never actually executed (as selection of this task always results in disabling of background execution).

In the description above, the background task scheduler is described as having the capability of manipulate the value of the mode bit in the stored context of a task (i.e. to manipulate the image of the mode bit). It will be appreciated however, that the background task is just one example of a part of the operating system running on the processor which may manipulate the stored context of a task and in other implementations, another part of the operating system may perform this manipulation.

The methods described above may be implemented by hardware logic 116 within the multi-threaded processor 100 (as shown in Figure 1) or in any suitable way. When context is restored, it is restored from memory (e.g. RAM) to the one or more registers 114. The memory may be on-chip (i.e. part of the processor 100) or off-chip. In some implementations, however, the stored I saved context which has previously been described as being stored I saved in memory, may instead be stored in hardware registers. In such an implementation, a context restore operation results in the stored context being switched between registers and the mode bit which causes the background execution to be disabled (and triggers use of the optimized re-entry sequence, etc) is the mode bit associated with a thread which is stored in a hardware register as opposed to the stored / saved context associated with a task which is stored in hardware registers. In a further implementation, the register states may be logically selected from a bank of similar states instead of being copied I transferred by a context restore. In such an implementation, if the mode register for a thread (i.e. the register containing the mode bit associated with a thread) is dynamically specified to use on of the hardware register states associated with the task, it need not be copied / duplicated as part of the context restore, but instead may be selected indirectly via another register that relates to the task I context that has been selected.

In the methods described above, the interrupt handlers are unmodified and in particular do not comprise additional code (e.g. special instructions) which causes the processor to return to the background level in a special way. Furthermore, no additional code is appended onto the interrupt handlers (e.g. in the form of a code stub) to cause the processor to return to the background level in a special way. Instead, in the methods described above, the thread does not return to the background level but instead enters an idle state in which background processing is disabled based on whether a mode bit stored in a hardware register is set or not. This mode bit is set indirectly by the background task scheduler selecting (stored) task contexts which have the mode bit set in them and the background task scheduler is consulted by the interrupt handlers during execution of those interrupt handlers in the standard way.

Where the mode bit in the hardware register is set, this triggers the optimized re-entry sequence (which has reduced latency) as described above. Alternate solutions would need to call specific code to handle the preamble, power-down and post-amble sequence instead of just scheduling an apparently normal task that is set not to run within its context.

The methods described above are particularly suited to multi-threaded processors, as such processors are already capable of stopping scheduling instructions from one thread in order that instructions from another thread can be scheduled. The methods are, however, also applicable to single-thread processors which may require an additional modification to their master control unit (e.g. additional logic) to provide a mechanism by which the execution of the processor may be paused until an interrupt is received.

Where the methods are implemented on a single-threaded processor, there will only be a single mode bit (corresponding to the single thread) stored in a hardware register and when this bit is set and background processing disabled, the core may be powered down to reduce the power consumption of the device and another entity may take control to wake the processor up. In another example, a subset of the processor (e.g. an interrupt unit) may not be powered down and may be arranged to wake the rest of the processor up.

There are many applications for the methods described above. An example usage of the methods described above relates to a low power embedded system which requires the processor to handle a number of interrupts but has no main background code to run (other than an initial set up). This example can be described with reference to figure 5.

In the set-up phase 50, an interrupt is triggered (block 502), the context is saved (block 504) and the mode bit in this saved context is set (block 506). Upon context restore (block 508), the mode bit in the hardware register is set (because the image of the mode bit in the saved context was set) and consequently, the core enters a low power idle state (block 510). By placing the core in this state, this minimizes the overhead for handling an interrupt (block 512), which can be important in low power time critical systems. As in the methods described above, the interrupt triggers an optimized re-entry sequence in which the interrupt handler executes (in block 514) without first re-storing any context and the previously stored context (i.e. the context manipulated in block 506) is subsequently restored (block 508) causing the core to return to the low power idle state (block 510).

Figure 5 also shows an option exit phase 52 which is triggered when an interrupt handler clears the saved mode bit (e.g. in a step which is the reverse of that in block 506). If this occurs, the context restore (in block 508) will result in the mode bit in the hardware register being cleared and the core will resume normal operation (block 516).

The methods described above (and shown in figures 2-5) provide an extremely low latency interrupt-response out of idle and this latency can be as low as zero cycles. According to the methods described above, setting the mode bit in the hardware register results in an optimization of the normal entry to and exit from an interrupt processing state, but does not require modification of the interrupt handlers.

The methods described above enable power saving, because it is possible to power down parts of the processor. In an example, where the mode bit is set (in hardware registers) for all the threads in the processor (where the processor may be a multi-threaded or single-threaded processor), the processor may be powered down and the interrupt processing handed off to a separate entity or to a part of the core which remains powered up. Even where this is not implemented, it is possible to power down more of the processor than when using a timer to wake the processor, because it is only necessary to run parts of the processor which can respond to an interrupt.

It will be appreciated that the methods described above may be used to provide low latency without any power saving or may be combined with power saving by putting parts of the processor to sleep or putting parts of the processor into another lower power mode. Where power saving methods are not employed, the latency of the optimized re-entry sequence tends to zero as there is no additional delay while parts of the processor wake up.

The term processor' and computer' are used herein to refer to any device with processing capability such that it can execute instructions. The term processor' is used herein to include microprocessors, multi-threaded processors and single-thread processors. In some examples, for example where a system on a chip architecture is used, a processor may include one or more fixed function blocks (also referred to as accelerators) which implement a particular function (e.g. part of a method implemented by the processor) in hardware (rather than software or firmware). Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term computer' includes set top boxes, media players, digital radios, PCs, servers, mobile telephones, personal digital assistants, games consoles and many other devices.

Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network).

Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.

It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.

Any reference to an' item refers to one or more of those items. The term comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. The arrows between boxes in the figures show one example sequence of method steps but are not intended to exclude other sequences or the performance of multiple steps in parallel. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought. Where elements of the figures are shown connected by arrows, it will be appreciated that these arrows show just one example flow of communications (including data and control messages) between elements. The flow between elements may be in either direction or in both directions.

It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art.

Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.

Claims

Claims 1. A method of operating a processor, the method comprising, in response to an interrupt relating to a thread in the processor (202, 210): restoring context associated with a next task (213, 416, 508), wherein restoring context associated with the next task sets or clears a mode bit associated with the thread in a hardware register in the processor; and if the mode bit associated with the thread is set in the hardware register, putting the thread into an execution state in which interrupt processing is enabled and background processing is disabled (208, 420).
2. A method according to claim 1, wherein if the step of restoring context associated with the new task sets the mode bit associated with the thread, the context is not fully restored.
3. A method according to claim 1 or 2, further comprising: if the mode bit associated with the thread is cleared in the hardware register, resuming execution of the thread (200).
4. A method according to claim 3, wherein resuming execution of the thread comprises resuming background processing of the thread (418).
5. A method according to any of the preceding claims, further comprising, in response to subsequent interrupt: saving context to memory within the processor (204, 410) if the mode bit associated with the thread is cleared and not saving the context to memory if the mode bit associated with the thread is set.
6. A method according to claim 5, further comprising: selecting a next task (414); restoring context associated with the next task (213, 416, 508), wherein restoring context associated with the next task sets or clears the mode bit associated with the thread in the hardware register in the processor; and if the mode bit associated with the thread is set in the hardware register, putting the thread into an execution state in which interrupt processing is enabled and background processing is disabled (208, 420).
7. A method according to claim 5 or 6, further comprising: modifying, by an operating system running on the processor, a stored context associated with a task.
8. A method according to any of the preceding claims, wherein the processor is a multi-threaded processor.
9. A method according to claim 8, further comprising in response to an interrupt relating to a second thread in the processor (202, 210): restoring context associated with a next task for the second thread (213, 416), wherein restoring context associated with the next task sets or clears a mode bit associated with the second thread in a hardware register in the processor; and if the mode bit associated with the second thread is set in the hardware register, putting the second thread into an execution state in which interrupt processing is enabled andbackground processing is disabled (208, 420).
10. A method according to claim 89, further comprising: powering down at least a part of the multi-threaded processor when each thread in the multi-threaded processor is in an execution state in which interrupt processing is enabledand background processing is disabled.
11. A processor (100) comprising: one or more registers (114) arranged to store a mode bit for a thread as part of context associated with a task; and hardware logic (116) arranged to: restore context associated with a next task from memory to the one or more registers and thereby set or clear the mode bit for a thread; and if a mode bit for the thread is set in the one or more registers, to put the thread into an execution state in which interrupt processing is enabled and background processing is disabled.
12. A processor according to claim 11, wherein the hardware logic is further arranged to stop restoring context before it is fully completed, where restoring context sets the mode bit for a thread.
13. A processor according to claim 11 or 12, wherein the hardware logic is further arranged to resume execution of the thread if a mode bit associated with the thread is cleared in the one or more registers.
14. A processor according to claim 13, wherein resuming execution of the thread comprises resuming background processing of the thread.
15. A processor according to any of claims 11-14, wherein the hardware logic is further arranged, in response to subsequent interrupt: to save context to memory within the processor if the mode bit associated with the thread is cleared; and not to save the context to memory if the mode bit associated with the thread is set.
16. A processor according to any of claims 11-16, further comprising a background task scheduler, the background task scheduler comprising instructions which when executed cause selection of a the next task, wherein the next task.
17. A processor according to claim 16, wherein the background task scheduler further comprises instructions which when executed modify a stored context associated with a task.
18. A processor according to any of claims 11-17, wherein the processor is a multi-threaded processor.
19. A processor according to claim 18, wherein the one or more registers are further arranged to store a mode bit for second thread as part of context associated with a task associated with the second thread and wherein hardware logic is further arranged, in response to an interrupt relating to the second thread: to restore context associated with a next task associated with the second thread from memory to the one or more registers wherein restoring context associated with the next task sets or clears the mode bit associated with the second thread; and if the mode bit associated with the second thread is set, to put the second thread into an execution state in which interrupt processing is enabled and background processing is disabled.
20. A processor according to claim 18 or 19, further comprising: hardware logic arranged to power down at least a part of the multi-threaded processor when each thread in the multi-threaded processor is in an execution state in which interrupt processing is enabled and background processing is disabled.
21. A processor according to any of claims 11-17, wherein the processor is a single-threaded processor.
22. A multi-threaded processor substantially as described with reference to figure 1 of the drawings.
23. A method of operating a processor substantially as described with reference to any of figures 2-5 of the drawings.