This idea originally stemed from the fact that x64 has quite a lot more registers than x86.
N⋆ is meant to be a semi-portable assembly language, but it is impossible to restrict the entire language to the smallest register set available across all 32+bits platforms.
This was also recently seen in the magus project:
x86 and x64 code is almost compatible. The main differences are pointer width and number of registers available. Both can be somewhat solved using symbolic register names, f.e. ptr_reg8 can be translated into either r8 or [esp+4*8] depending on CPU
Instead, we propose that the number of registers be either unbounded (meaning that %rN with N ∈ ℕ may be a virtual register depending on the target architecture) or large enough to accomodate to at least x64 (meaning that there would be at least 12 registers %r0 to %r11).
The first registers of this set would be mapped to the architecture's register (eax, etc) and all of the remaining registers would be strategically spilled on the stack. Although there is a very little performance hit from doing so, this allows not to worry too much about which registers are available or not when generating code from a compiler (from a user point of view too, but in this case the user itself could maybe use target-specific blocks — see #37 — for better handling of registers across multiple architectures).
This idea originally stemed from the fact that x64 has quite a lot more registers than x86. N⋆ is meant to be a semi-portable assembly language, but it is impossible to restrict the entire language to the smallest register set available across all 32+bits platforms. This was also recently seen in the magus project:
Instead, we propose that the number of registers be either unbounded (meaning that
%rNwithN ∈ ℕmay be a virtual register depending on the target architecture) or large enough to accomodate to at least x64 (meaning that there would be at least 12 registers%r0to%r11). The first registers of this set would be mapped to the architecture's register (eax, etc) and all of the remaining registers would be strategically spilled on the stack. Although there is a very little performance hit from doing so, this allows not to worry too much about which registers are available or not when generating code from a compiler (from a user point of view too, but in this case the user itself could maybe use target-specific blocks — see #37 — for better handling of registers across multiple architectures).