[Libre-soc-dev] proposal of change of register name convention in SVP64

[Luke Kenneth Casson Leighton]

On Tue, Jun 28, 2022 at 6:58 AM Lauri Kasanen <cand at gmx.com> wrote:

> Then my preference is "v.r0".

mine too simply because i picked "." in the first place and there's 750
uses in unit tests, now, plus the spec, all of which needs updating if
this goes ahead.

the problem with "v.{xxxxx}" is that there's a RISC-violating clash
with "v.0".  the fundamental principle that we're applying is that
the prefixing *right across the board* is unambigous and completely
separated from and in no way impinges on the scalar instruction
*being* prefixed.

spec, assembler, hardware, simulator, compiler - *everything* should
be clearly and unambiguously "RISC" and in no way detrimentally
impact or encroach on the scalar element, present or future

thus i originally picked "suffixing" "{xxxx}.v" because that's simply
not a syntax used by anyone at all, and won't be.  nobody is
going to create a *scalar* register name "5.v" or "r32.v".

if swapping to prefixing "v.{xxxxx}" then the prefix has to work
unambiguously without damage to present *OR FUTURE* scalar
register naming.

yes, really, it will be possible to prefix VSX registers.

    v.v.0

will be a valid register name (assuming "v." is picked as the prefix)

we cannot and must not have exceptions in any code which says:

      if SVP64 then
           follow naming convention X for **SCALAR** registers
           as embedded as an element
      else
           follow naming convention Y for scalar registers
           as per Power ISA spec

bottom line is that the prefix needs to be so radically different
from anything else anyone else has ever used that there is
no possibility - ever - of anyone adding to the Power ISA or
extending SVP64 into future areas - and finding "oh s***
that register name's confused"

hence the suggestions "v:" as the prefix because ":" is
unused (and not a mathematical operator, either)

    v:v.0

would be a legitimate and unambiguous name.

l.