Skip to content
This repository has been archived by the owner on Feb 2, 2024. It is now read-only.

Treating unused tp or gp as saved registers #6

Open
marceg opened this issue May 26, 2019 · 2 comments
Open

Treating unused tp or gp as saved registers #6

marceg opened this issue May 26, 2019 · 2 comments

Comments

@marceg
Copy link

marceg commented May 26, 2019

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.

@ilg-ul
Copy link

ilg-ul commented May 26, 2019

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.

@aswaterman
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants