Being frustrated with debugging my new port, searching for the reason the integer-math tasks fail every 15,000 iterations or so, I noticed something funny with the idle-task. Perhaps this could lead to another optimization.
When running just the integer-math-tasks, performace is severly degraded by the idle-task consuming it’s timeslice doing absolutely nothing usefull. I think the same does apply with tasks waiting for eg external interrupts while other tasks are constantly doing heavy calculations at idle-priority. But why at idle-priority? Well, eg because the calc-tasks run continously and the idle-task must get control now and then to cleanup deleted-tasks-stuff.
Running all at idle-priority it is imperative that round-robin handles timeslicing between these tasks. I think it might be a good idea to have a fast mechanism (only for the idletask??) to determine if another task would be swapped in if the idletask calls yield(). If so, the idletask indeed calls yield(), if not the idletask just loops as it does now.
To (perhaps) simplify the design of such fast way of checking: It does not harm much if the idletask now and then makes a wrong descision and calls yield() to only be pre-empted again immediately.