Probably not. The out-of-order execution units in the cores rely heavily on register renaming to remove anti-dependences in the instructions stream and get more instructions executing in parallel. History (so far in most cases) has shown that this is a better approach to getting good performance than having compilers or humans try to statically manage all the physical registers themselves.

Your programs can potentially use all of those registers (or all those assigned to your task, if the particular core uses static partioning for registers). Unlike the compiler's work, the core does this based on real, current runtime information.

More architected (i.e. program-visible) registers require more bits to encode.

Back when AMD designed x86_64 asked that question: they concluded that it was better only show a few registers because that was all compilers really needed (compilers writers had learned a lot of tricks from the mess that x86 was), and so they could better deal with a small instruction set that fewer registers offers for greater performance.

But AMD also increased the number of general-purpose registers from ~6 in x86 (eax to edx and the not fully general purpose esi, edi, esp, ebp) to ~16 in AMD64 (rax to r16). ARM has ~32.

> from the mess that x86 was

Is ARM seen as a mess? Are x86's days numbered as ARM catches up and becomes more widespread for personal computing devices?

ARM is much better as an instruction set, but it isn't clear if that will ever matter.

It depends on the complexity of the sensitive variables. This looks like a purely academic exercise.

They are accessible - they aren’t sitting there unused. They’re dynamically allocated to logical names as the program runs.