Open marceg opened 5 years ago
gp is likely to have a single value throughout the program, in which case interrupt dispatch doesn't touch it.
I agree.
In the case of tp: in most OS, interrupt handlers don't touch thread-local data, as they don't run in the context of a thread, so again interrupt dispatch need not touch it.
I did not use thread-local data in my past RTOSes, and the thread pointer was implemented as a global variable, updated by the context switch code, but I tend to agree with this statement too.
In the current ABI, they are treated as neither caller-saved nor callee-saved. gp is immutable and tp is only written on context switches.
That seems to me to be the right thing to do for software that links the interrupt handlers together with the application code, because it allows the interrupt handlers to use gp without reloading it. In addition to usually being the more performant choice, this approach also reduces toolchain complexity, because the linker doesn't need to be informed that it shouldn't relax global variable references to gp within interrupt-handler code.
If tp or gp are unused, it seems more appropriate to treat them as saved registers (callee-saved) than as temporary registers (caller-saved). This allows interrupt dispatch code to consistenly ignore them (avoid saving and restoring them), for better interrupt latency. In the case of gp: most RTOS are linked in a single image with the application, so that if used, gp is likely to have a single value throughout the program, in which case interrupt dispatch doesn't touch it. In the case of tp: in most OS, interrupt handlers don't touch thread-local data, as they don't run in the context of a thread, so again interrupt dispatch need not touch it.