fix(threads/cortex_m): don't save high regs on first schedule

[elenaf9]

Description

I noticed that threading on the nrf5340 is currently broken/ hard faults.

Some debugging showed that the problem is that on run, the PendSV tries to stored the r4-r11 registers in a null pointer.
This didn't cause any problems on the rpi-pico or nrf54840, but apparently for the nrf5340/ CortexM33 it's problematic.

To fix this, we have to skip storing/ loading of r4-r11 if the pointer is zero, i.e. when there was no previously running thread whose context has to be saved.

An alternative would be to directly in the sched code when current_pid.is_none() return 0 so that no context save/ reload happens, but then the psp update would also be skipped and we'd manually have to do that before returning the 0.

The PR also includes some small optimizations/ clean-ups in sched.

Issues/PRs references

The bug was a side-effekt of #262.

Open Questions

Change checklist

• I have cleaned up my commit history and squashed fixup commits.
• I have followed the Coding Conventions.
• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.

[kaspar030]

This looks lije a special case for the first schedule, which hits only once. How does the cycle count look for this? If it is measurably slower, I'd rather have some more logic in start_threading().

[kaspar030]

But nice catch! :)

[elenaf9]

This looks lije a special case for the first schedule, which hits only once. How does the cycle count look for this? If it is measurably slower, I'd rather have some more logic in start_threading().

Not sure if it's possible to solve it in start_threading. It could be solved it in the else branch inside sched when we check if current_pid is None: e61ea5d. But this impacts compiler optimizations.

Depending on which board (so far only rpi-pico and nrf53840dk; don't have an nrf52840dk with me right now) I test, one or the other solution performs better. But both variations overall don't negatively impact performance, because the PR includes some other small optimizations within sched. On rpi-pico bench_sched_yield 293 -> 291 ticks per context switch.

[kaspar030]

LGTM, please squash!