Processor zero overhead task scheduling

A method for scheduling tasks on a processor includes detecting, in a task selection device communicatively coupled to the processor, a condition of each of a plurality of components of a computer system comprising the processor, determining a plurality of tasks that can be next executed on the processor based on the condition of each of the plurality of components, transmitting a signal to an arbiter of the task selection device that the plurality of tasks can be executed, determining, at the arbiter, a next task to be executed on the processor, storing, by the task selection device, the entry point address of the next task to be executed on the processor, and transferring, by the processor, execution to the stored entry point address of the next task to be executed.

FIELD OF THE INVENTION

The present invention generally relates to systems and methods to automate the scheduling of tasks on a processor.

BACKGROUND OF THE INVENTION

Computer systems often require running multiple independent tasks on a single processor. Conventionally, scheduling the execution of tasks is software-dependent and involves the overhead of a multi-tasking operating system or runtime environment. In one approach for conventional systems that avoids this overhead, the processor runs in a loop, calling each task in turn which on entry polls status registers to check whether prerequisite conditions required for execution of the task are present to determine if it can proceed. If the prerequisite conditions are not fulfilled for a particular task, the task immediately exits and the processor calls the next task which polls the status registers for its prerequisite conditions to proceed, and so on. Polling the status registers for each task incurs unnecessary overhead and wastes between 10 and 15% of central processing unit (CPU) cycles.

Consistently polling registers at the beginning of each task not only wastes CPU cycle time and is inefficient, but also results in increased power usage for a small amount of actual work done by tasks on the processor. The processor is consistently busy polling registers to determine if and when a task can be executed.

Accordingly, there is an unmet need to design systems capable of efficiently scheduling tasks for execution on a processor.

BRIEF DESCRIPTION OF THE INVENTION

In an aspect, a method for scheduling tasks on a processor includes hardware logic of a task selection device communicatively coupled to the processor, which detects a condition of each of a plurality of components of a computer system including the processor, determines a plurality of tasks that can be executed on the processor based on the condition of each of the plurality of components, and transmits a signal to an arbiter of the task selection device indicating that the plurality of tasks can be executed. The method includes the arbiter of the task selection device which selects a first task of the plurality of tasks to be executed next on the processor. The method further includes the task selection device which determines an entry point address of the first task and the processor which transfers execution to the entry point address of the first task.

In another aspect, a system for automated scheduling of a plurality of tasks on a processor includes components necessary for the execution of the plurality of tasks, a memory communicatively coupled to the processor, and a task scheduling device communicatively coupled to the memory. The task scheduling device includes hardware logic and an arbiter. The hardware logic receives a plurality of trigger conditions from the components, changes a status bit within the hardware logic for each of the plurality of triggers, and determines a plurality of tasks that can be next executed, based on programmed relationships between the trigger conditions. The arbiter receives an enable signal for each of the plurality of tasks, and determines the next task of the plurality of tasks to be executed on the processor. The processor executes one task of the plurality of tasks at a time and schedules the next task to be executed on the processor.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1shows a block diagram of a task scheduling system100including a task selection device102, task trigger inputs114and a processor104. The task selection device102includes hardware logic126, an arbiter110, and a function pointer table112. The task selection device102is communicatively coupled to a processor104by a bus106via a memory or register132.

The task selection device102includes input selectors118,120,122, and124corresponding to the four tasks140,142,144, and146which run on the processor104. While only four input selectors (118,120,122, and124) for four tasks (140,142,144, and146) are shown for clarity, any number of tasks may be supported with a corresponding selector for each task. Task selection device102also includes an enable function128and a force function130.

Task trigger inputs114are provided to task selection device102from the wider computer system (not shown for clarity) of which the task scheduling system100is a part. The inputs114indicate the status of various components in the computer system necessary for the execution of tasks on the processor104. Examples of such inputs include, but are not limited to, availability or readiness of resources, notification of status of external events, and so on. Tasks may include a single command or a plurality of commands which carry out a given task.

For clarity, inputs114inFIG. 1are provided to four task selectors,118,120,122, and124for tasks140,142,144, and146, which select which inputs are relevant for the associated task. There may be any number of inputs114to the hardware logic126, only limited by the space occupied or power consumed by the task selection device102. Inputs114from the wider computer system may include, for example, an indication that a component is available, that space exists in a memory, or notification of an event like a data packet being available, or of a timer expiring, among other possible inputs. Each input selector has a select register input (not shown for clarity), which may be used to configure which inputs are relevant for a particular task and are to be selected.

Each task that can be executed on the processor104typically includes a set of prerequisite conditions needed for the task to execute. Inputs114include information about component statuses related to the prerequisite conditions for the execution of one or more tasks on the processor104. For each task, one or more inputs114, or combinations thereof, may be present or absent as a “trigger” before the task can proceed to execute on the processor104. An arbitrary number of triggers can be input into the task selection device102from around the wider system. For example, a task may require the availability of a resource such as space in a buffer, availability of data in a memory or buffer, or availability of a direct memory access (DMA) channel. A task may require that multiple conditions be met in order to run, which can be combined in an arbitrary way, for example: (input1AND input3AND not input5) OR (input6OR input7). The selection of which inputs are relevant for each task is done by task input selectors118,120,122, and124for tasks140,142,144, and146, respectively. Each task input selector may select a different set of inputs for each task. The logic to determine whether each task may be in a condition to run is contained within hardware logic126.

The inputs114enter the task selection device102at bus116which provides the inputs114to individual task input selectors118,120,122, and124, from which a subset of selected inputs are input into the hardware logic126. For example, from a set of M possible task trigger inputs114, a subset of N inputs may be selected by an input selector for a particular task. Input selectors118,120,122, and124select the inputs114relevant for tasks140,142,144, and146, respectively, and supply these inputs114to the hardware logic126. The input selectors118,120,122, and124transmit the status information derived from the inputs114as status bits. In some implementations, the inputs114may be input both as external inputs and located in I/O mapped registers. The hardware logic126utilizes an arbitrary logic equation for each set of selected inputs for each task to determine whether the received inputs114fulfils the prerequisite conditions to permit execution of one or more tasks on the processor. Alternatively, in some embodiments, the hardware logic126utilizes lookup tables to determine from the triggers whether the received inputs114fulfils the prerequisite conditions to permit execution of one or more tasks on the processor104. In the example case of four inputs114selected by each of the input selectors118,120,122, and124, the hardware logic126utilizes four 16-bit lookup tables, indicating the outcomes of the 16 possible combinations of the four selected inputs. In the general case of N inputs selected for a task, a 2Nbit lookup table would be employed for that task.

The hardware logic126can be programmed to represent any arbitrary logic, providing flexibility as to the conditions under which tasks can be enabled. The programmer or manufacturer can determine the tasks to be enabled by the hardware logic126and the inputs114which are prerequisite to the execution of the tasks by programming the lookup tables of hardware logic126and the selection registers (not shown for clarity) of the input selectors118,120,122, and124. The available tasks are set up statically at start-up of the task selection device102, each task with a selected subset of task trigger inputs and set of prerequisite conditions necessary for execution of the task. The arbitrary logic equations describing the prerequisite conditions for each of the tasks are also pre-determined at start-up. At any time after start-up, the selected subset of inputs and set of prerequisite conditions may be changed by reprogramming,

When the hardware logic126determines that the inputs114indicate that the conditions for execution of a particular task are met, then the task is considered for scheduling at the processor104. The hardware logic126transmits enable status signals for each of the tasks enabled by the received inputs114to be considered for scheduling to the arbiter110. When a task enable status signal is high, the task is considered for scheduling and the arbiter110selects one of the tasks using an arbitration algorithm, such as round-robin, weighted round-robin, fixed priority and so on. The arbiter110may include a mode register (not shown for clarity) which includes bits that can be set in order to select the arbitration algorithm.

The hardware logic126most often presents the enable status signals to the arbiter110via an enable function128. For example, in a case where there are eight possible tasks, eight individual signal wires127(represented by the single line inFIG. 1) may extend from the hardware logic126to the arbiter110. The enable function128has its own task enable register with bits for each task (not shown for clarity) to override the decision of the hardware logic126, such that unless both the enable register bit and the status signal for a task are set, the status signal for that task at the output of the enable function128is reset. This provides an override mechanism to disable one or more tasks, regardless of the state of the inputs114.

Conversely, a force function130may be used to override the hardware logic126in some circumstances. The force function130has its own task force register with bits for each task (not shown for clarity), such that if either the enable register bit or the status signal for a task are set, the status signal for that task at the output of the enable function128is set. Setting the force register bit for a task will cause the task to be considered for scheduling, irrespective of the state of the hardware logic126and the inputs114. The force function130provides a mechanism to enable one or more tasks, so that those tasks should always be considered for scheduling.

The arbiter110determines the next task to be executed based on the state of the signal wires127indicating enabled tasks to be considered for scheduling and the history of previously scheduled tasks. The arbiter110determines an order of tasks according to a pre-determined method, such as a priority rule, round-robin, or weighted method. A task will not be run if the enable function128is not set for the task.

The enable function128and force function130allows the system to dynamically and rapidly respond to unusual, temporary or specific conditions by immediately enabling or disabling tasks. For example, if a particular component is unavailable or disabled, tasks that rely on the availability of this component can be disabled by setting the related bits of the status register of the enable function128to zero, without having to modify the lookup table. The tasks that rely on the particular component will not be considered for scheduling by the arbiter110because the enable function128will not be set for the tasks. Conversely, the force function130can force a task or tasks to be considered for scheduling due to some rare event, for example a power loss event where a limited time is available with a limited backup power source (such as a capacitor or a battery) to complete certain essential tasks. The enable function128and force function130can therefore override the decision of the hardware logic126and allow the system to respond quickly to unusual or temporary conditions without having to re-program the hardware logic126or the selection registers of the input selectors118,120,122, and124.

The arbiter110, after choosing a next task to be executed on the processor104, outputs a task ID to reference a function pointer table112which in turn outputs a task address which is the entry point in program address space of the task function. The entry point address of the task may be stored in a RAM, for example, static RAM (SRAM) which is accessible by the processor or directly in a processor register. The processor uses this stored entry point address to transfer execution to the next scheduled task without the added overhead of polling registers to see which tasks may be run. This may be performed by the processor reading the stored entry point address and performing a jump directly to it, or by executing a task schedule instruction which causes the stored entry point address to be loaded into the program counter of the processor, thereby transferring execution to the next scheduled task. Because the inputs114are evaluated in the hardware logic126to determine which tasks can be executed based on conditions of required components, no polling of registers is required and tasks which are scheduled by the arbiter110can be executed on the processor104without further software decisions. Scheduling of tasks which are already known to be executable provides a seamless transition between one task and the next.

Tasks run to completion on the processor104, and then the arbiter110determines a next task to be run based on the enabled tasks presented by the hardware logic126. Once the arbiter110determines the next task for execution, the arbiter110uses the determined task ID to reference the function pointer table112, the output of which is stored as the entry point address of the determined task and used by the processor to transfer execution to the determined next task.

The function pointer table112provides to the processor104an address of the next task to be executed. The output of the function pointer table112may be stored in a memory132connected to the processor104, which may be an SRAM or a register of the processor, which the processor104either reads and jumps to directly or uses the task schedule instruction to load the contents of the special register into the program counter of the processor104, i.e. perform a jump to the address stored in the register. In this way the processor104may transfer execution from one task to another when instructed to by a task, wherein execution is transferred to the entry point which has most recently been selected and stored by the task selection logic. The transfer of execution is generally used at the end of normal processing for each task. The transfer of execution causes the processor104to jump to the entry point address of the next scheduled task as output by the function pointer table112addressed by the arbiter110, eliminating any need for a register read.

The transfer of execution can also optionally be used in order to yield between tasks at any point of execution within a task. For example, when the task cannot progress to completion, for example because of the unavailability of a resource, the task may include a branch which calls the special instruction to instruct the processor104to jump to the next task immediately rather than wait for the current task to complete. A task may be exited before completion when a resource which is not a prerequisite for enabling of the task is not available, or if a resource which is a prerequisite for enabling the task is no longer available. Yielding of one task for another may require that the task-specific current state be saved and restored when the task is resumed. The execution of the special instruction immediately changes the program counter of the processor104to the next task which is able to run on the processor104, thereby significantly reducing the overhead. The special instruction is dynamic and based on the output of the arbiter110and the contents of the function pointer table112. The function pointer table may be reprogrammable, for example by implementing in a non-volatile memory such as NAND flash memory, thereby enabling multiple tasks or entry points in a task to be addressed with a single task ID. The function pointer table112may be programmed upon first instantiation or installation of the software tasks required to be run on the processor104, then may be reprogrammed if the software tasks are updated or changed.

In some implementations, when a task yields to another task before completion, the prerequisite conditions required for the particular task to run are updated in the hardware logic126to include the availability of an additional resource or removal of an unavailable resource. In some implementations, prior to executing the special instruction, the function pointer table112may be updated to contain the address following the yield branch point, such that the next time the task is selected by the arbiter110, the task will resume at the point after the branch was taken. In some implementations, the task may be programmed to branch to a yield instruction in the middle of the task in order to allow another task to complete after a particular number of CPU cycles have been spent on the particular task. In some implementations, when a task yields to another task the processor104performs an automatic bulk save of the context of the task, including the internal state of the processor104, to a stack area associated with the task being exited.

As an illustrative example of the task scheduling process, a processor104may include a fetch task, among other available tasks. The hardware logic126receives inputs indicating the availability of various resources and determines if the conditions required for execution of the fetch task are met. In the example case, the fetch task may require only one prerequisite condition: the presence of data in the FIFO. The fetch task is enabled by the presence of data in the FIFO, which is indicated as an input114. The hardware logic126determines that the fetch task can be executed based on the current status of the FIFO, and outputs the fetch task enable signal to the arbiter110to schedule execution on the processor104.

If the hardware logic126determines that no task can be executed on the processor104, the hardware logic126may transmit to the arbiter110an enable signal for a null task, or alternatively, the arbiter110may assume that if no task is enabled, then it should output a null task ID. The null task may be a sleep command which allows the processor104to enter a low power state until another task is enabled. The null task may be ended by the presence of an enable signal of a task transmitted to the arbiter110. By enabling a null task when no other tasks are available, the arbiter110improves efficiency of the system and reduces power usage.

FIG. 2shows a flow diagram of a simplified task scheduling method200. The task scheduling method begins at step202when inputs (for example inputs114inFIG. 1) related to the availability of resources or notification of events to a processor (for example processor104inFIG. 1) or within a computing device are presented to the hardware logic (for example hardware logic126inFIG. 1). The inputs may be presented as bit status indicators for particular conditions or events which are prerequisites to the execution of a task on the processor. At step204, the hardware logic compares the input conditions with an arbitrary logic or lookup table describing the prerequisite conditions for execution of one or more tasks. At step206, the hardware logic outputs any tasks which are enabled by the inputs to a task arbiter (for example arbiter110inFIG. 1).

At step208, the task arbiter determines a next task from the enabled tasks. The task arbiter determines the next task based on a history of tasks executed at the processor and a pre-determined method for selection of a next task, such as priority rules, round-robin, or weighting of tasks. At step210, the task arbiter outputs a task ID to address a function pointer table (for example function pointer table112inFIG. 1) to the chosen next task for execution by the processor.

FIGS. 3A, 3B, 3C, and D illustrate an example of the operation of the automated task scheduling method by showing the task selection device and processor execution during execution of four tasks over four points in time.FIG. 3Ashows a block diagram of the operation of the task selection device301aand program counter311aof a processor during execution of a first task at a first time point.FIG. 3Bshows a block diagram of the operation of the task selection device301band program counter311bof a processor during execution of a second task at a second time point.FIG. 3Cshows a block diagram of the operation of the task selection device301cand program counter311cof a processor during execution of a third task at a third time point.FIG. 3Dshows a block diagram of the operation of the task selection device301dand program counter311dof a processor during execution of a fourth task at a fourth time point.

For clarity,FIGS. 3A-Dillustrate an example in which there are four possible tasks which can be executed on the processor: A, B, C, and D. The four tasks include prerequisite conditions described by 32 input triggers. In some embodiments, there may be any arbitrary number of possible tasks which can be run on the processor, for example eight tasks.

FIG. 3Aillustrates the state of the task selection device at a first point in time (Point1)301a, including a state of the trigger inputs308and select inputs306ato the hardware logic305a. Each of the select inputs306a, Sel-A, Sel-B, Sel-C and Sel-D, selects a different subset of the 32 possible trigger inputs for Tasks A, B, C and D respectively. Based on the trigger inputs308aand the select inputs306a, the hardware logic305adetermines that Task A and Task D of possible tasks310aare ready to run, and presents these tasks to the task scheduling arbiter312aas an input. The possible tasks310aare shown as status bits presented to the arbiter312a. The arbiter312aselects Task A and addresses, with the task ID of task A, the pointer table314which outputs the value (TASK_A_EP)315which is the entry point address of Task A.FIG. 3Aillustrates the processor execution passing to Task A318by executing the SCHED316instruction at Point1. When the SCHED316instruction is executed, the program counter311aof the processor is loaded with the entry point of Task A, TASK_A_EP315, from the pointer table314and the execution transfers to Task A318.

Task A executes its instructions320, INSTR_1, INSTR_2. . . INSTR_n, and then at Point2yields control to another task by executing the SCHED322instruction again.FIG. 3Billustrates the state of the task selection device301bat Point2in time, after Task A318has yielded control. The state of the trigger inputs308band select inputs306bindicate that Task B, Task C, or Task D of the possible tasks310bare ready for execution. The arbiter312bselects TASK C and the addresses, with the task ID of task C, the pointer table324which outputs the value (TASK_C_EP)325which is the entry point address of Task C.

At Point2inFIG. 3B, the execution of the processor passes to Task C328as the next task for execution on the processor. Execution of the SCHED instruction322at the end of execution of Task A318(shown inFIG. 3A) loads the program counter311bwith the entry point address for Task C325(TASK_C_EP), the next task for execution as determined by arbiter312b. Task C328executes its instructions330, INSTR_1, INSTR_2. . . INSTR_n, and then comes to a point where its instructions indicate yielding control to another task by executing the SCHED332instruction at Point3.

FIG. 3Cillustrates the state of the task selection device301cat Point3in time, after Task C328has yielded control (shown inFIG. 3B). The state of the trigger inputs308cand select inputs306cindicate that Task B or Task D of the possible tasks310care ready for execution. The arbiter312cselects TASK B and addresses, with the task ID of task B, the pointer table334which outputs the value (TASK_B_EP)335which is the entry point address of Task B. At Point3inFIG. 3C, the execution of the processor is passed to Task B338as the next task for execution on the processor. Execution of the SCHED instruction332at the end of execution of Task C (shown inFIG. 3B)328loads the program counter311cwith the entry point address for Task B335(TASK_B_EP).

Task B338executes its instructions340, INSTR_1, INSTR_2. . . INSTR_n, and then comes to a decision point341where Task B338it unable to continue. For example, Task B may require a resource to become available or for an input to be made available. Task B338yields control to another task by executing the SCHED342instruction at Point4rather than complete execution of its instructions.

FIG. 3Dillustrates the state of the task selection device at a fourth time301d, after Task B338has yielded control. The state of the trigger inputs308dand select inputs306dindicate that only Task D of the possible tasks310dare ready for execution. The arbiter312dselects TASK D and addresses, with the task ID of task D, the pointer table344which outputs the value (TASK_D_EP)345which is the entry point address of Task D. At Point4inFIG. 3D, the execution of the processor passes to Task D348as the next task for execution on the processor.

Task D348executes its instructions350, INSTR_1, INSTR_2. . . INSTR_n. At the end of Task D348, the SCHED352instruction is executed at Point5. At this point there is no other task ready to run, so execution of the SCHED instruction352at the end of execution of Task D348loads the program counter311dwith the entry point address for Task D345(TASK_D_EP). Task D may be a background task, or any other task that runs whenever there is no other task available to run, for example a null task such as a low power sleep. If there were another task ready for execution, the arbiter312dwould choose that task in preference to task D, as occurred inFIG. 3A-3C. If at any time another task is enabled by input conditions meeting the prerequisite conditions for execution, the task will be selected by the arbiter312dand execution will transfer to the entry point of that task.

The entry points of tasks are set up before execution begins by storing the address values in the function pointer table (for example function pointer table112inFIG. 1). The function pointer table can be updated at any time. For example, inFIG. 3C, Task B could update the function pointer table with the address TASK_B_EP2355upon reaching the decision to yield341before completion, such that when Task B338is next selected by the arbiter312c, control would transfer to the address TASK_B_EP2355at Point6to the instruction after decision point341. Task B338would then resume execution at the point after it had decided to yield, and the instructions would execute until completed when the SCHED instruction356would be executed to prompt the arbiter312cto update the function pointer table.

FIG. 4shows a flow diagram400for a method of automated task scheduling. At step402, the hardware logic (for example hardware logic126inFIG. 1) detects a condition of each of a plurality of components of the computer system. The hardware logic takes in a collection of events from the various hardware peripherals or computer system components and allows an arbitrary logic function of inputs to be programmed as a task enable. The hardware supports a number of programmable tasks, for example four, seven, or more tasks, and one default task (“null task”) which is called when no other tasks can be executed. The default task may be a sleep task which places the processor in a low power sleep mode. The conditions of the plurality of components of the computer system are selected to be those which are prerequisites for execution of one or more tasks on the processor (for example processor104inFIG. 1).

At step404, the hardware logic determines, based on the condition of each of the plurality of components, a plurality of tasks that can be executed on the processor. The hardware logic utilizes arbitrary logic or a lookup table to determine the tasks for which all prerequisite conditions are met by the conditions of the components. A task enable signal is passed on to the arbiter (for example arbiter110inFIG. 1) only when the prerequisite conditions for execution of the task are fulfilled. At step406, the hardware logic transmits an enable signal to an arbiter for each of the plurality of tasks which can be executed.

At step408, the arbiter arbitrates among the plurality of tasks and determines the task ID of the task of the plurality of tasks which is to be next executed on the processor. The arbitration of the enabled tasks is built in to the arbiter, according to a priority rule, round-robin method, or weighted scheduling technique. The hardware of the arbiter is programmed with task IDs for each of the eight possible tasks, which is used to address a function table pointer which outputs the address of the entry point of the task to a special register so that instruction microcode of a special instruction simply loads the processor program counter with the special register to jump to the next task.

At step410, the arbiter addresses, with the determined task ID, a function pointer table (for example function pointer table112ofFIG. 1) which outputs the address of the entry point of the determined task to be executed on the processor. At step412, the processor transfers execution to the entry point of the next task determined by the arbiter. The processor executes the task knowing that the task has useful work to do because its prerequisite conditions are already known to be met. This technique eliminates conventional methods which rely on polling of multiple task functions in a sequential loop, and eliminates the need for most conditional checks for each of the task functions to determine whether all conditions are in place to proceed with execution to do useful work.

FIG. 5shows a system flow diagram500for automated task scheduling. On the left-hand side, steps502,504,506and508show the steps taken by the Task Selection Device (for example task selection device102inFIG. 1). On the right-hand side, steps510,512and514show the steps taken by the processor (for example processor104inFIG. 1) as it executes. At step502, the arbiter (for example arbiter110inFIG. 1) receives from hardware logic (for example hardware logic126inFIG. 1) an indication of a plurality of tasks where the state of the components of the computer system are such that the tasks can be executed on a processor. At step504, the arbiter determines a first task which is the next task of the plurality of tasks to be executed on the processor. At step506, the arbiter addresses, using the task ID of the first task, a function pointer table (for example function pointer table112inFIG. 1). At step508, the function pointer table outputs the entry point address of the first task which is loaded into a task register of the processor, following which the process repeats.

At step510, the processor executes task instructions which may be of a total of N possible tasks that may execute. The processor continues to process task instructions until it reaches the end of task activities, which may be at the very end of the task, or at some point in the middle of the task where it decides for any reason to finish its activities and yield to another task.

At step512, the arbiter may optionally save the current task-related context related to the task and update the task's entry point address in the function table pointer (in the event the task has been unable to fully complete processing and wishes to resume at the point after it yields, for example). Since this step is optional, the process of task switching can be made more efficient by removing the overhead of task context saving and restoring performed in some operating system based task switching systems. At step514, the processor executes a SCHED instruction, which loads the processor program counter (PC) with the current contents of the task register (which has been loaded with the entry point address of the first task in step508). The SCHED instruction may, in some implementations, read the output of the function pointer table directly and store the value in the PC.

The processor returns to executing task instructions at step510. Which task instructions of the possible N tasks are executed is determined by the state of the program counter which in turn will depend on the contents of the task register set in step508or the value of the function pointer table output read in step514.

This may include a null task if there is no active task which is enabled to be executed at step504, where the arbiter will determine that no tasks can currently be executed on the processor based on the trigger status bits transmitted to the arbiter from the hardware logic. The null task may be a sleep or power down task which allows the processor to enter a low power state when there is nothing else for the processor to do until a different task can be run. In some implementations, the null task may periodically end its instructions and return to step514where the contents of the task register or the output of the function pointer table will contain the entry point address of any task which is to be next executed on the processor. The execution of a null task requiring a lower power state reduces the power consumption of the processor.

Using hardware logic to determine tasks which can be executed on a processor and presenting the arbiter with only tasks that can currently be executed eliminates wasted cycles by allowing it to automate the scheduling of independent tasks without the need for polling registers for each task in turn, by using an instruction which automatically jumps to the next task which has been selected to be run by the arbiter. The method removes the overhead of continually calling any task until such a point that conditions are fulfilled so that the command can be run, removing the need for each task to read status registers on entry, because it is implicit from the fact that the task is running that the prerequisites are met. This allows for more efficient use of available CPU cycles, reducing power and time taken, as well as energy consumed, to perform any given task-based activity.

Other objects, advantages and embodiments of the various aspects of the present invention will be apparent to those who are skilled in the field of the invention and are within the scope of the description and the accompanying Figures. For example, but without limitation, structural or functional elements might be rearranged consistent with the present invention. Similarly, principles according to the present invention could be applied to other examples, which, even if not specifically described here in detail, would nevertheless be within the scope of the present invention.