Is it possible to prohibit the use of certain registers for a small piece of C ++ code?

I have already addressed this issue , but none of the two solutions work for me for the following reasons.

  • I am trying to prevent C ++ code from dealing with registers, not assemblies, so the clobber list will not work.
  • I would like to do this locally, not globally, so global explicit register variables are too heavy.

Is there any way to wrap a set of C ++ instructions to tell the compiler not to use certain registers?

+6
source share
2 answers

Not figuratively, of course. C ++ - the semantic level knows nothing about this entry (despite the presence of the register keyword).

g++ for example, can allocate a register globally or locally to a variable, in which case the compiler will never touch that register. This can sometimes be useful (I used this with the serious nature of performance in a virtual machine to implement Lisp without having to write everything in the assembly manually).

I suspect, of course, that if you also do not recompile the entire standard library, changing the standard headers, to include an announcement that the code in the library may touch the register (and depending on the ABI, it is possible that the registers you want to use are declared "scratches" "and therefore are not saved or restored).

Maybe other compilers also have this option ( clang , although, for example, although it is almost compatible with g ++, it does not support allocation of support registers).

+1
source

No, C ++ has a rather simplified model below.

If you think about it, how does the C ++ compiler know about the registries on which it should be compiled?

Without going into assembler, you cannot do this.

Since you want certain registers not to be used, you had to write code from the place you want to ban these registers until the moment when this requirement is no longer required - which can be a lot of code.

Without details about why you want to prevent access to certain registers and how long this prevention has been, I can only give a vague generalization.

0
source

All Articles