[RFC] SVP64 Cray-style Vectorisation of the OpenPOWER scalar ISA

[lkcl]

(thank you for ccing, Alain, am set digest)

btw just so you know: for gcc after speaking with David we came up with the
idea for creating an EXT01 opcode named "svp64".  gcc would emit that as a
prefix in front of every augmented instruction.

the prefix would have the register augmentation already encoded, probably
as a hex number.

however the separation of the prefix from the suffix makes it virtually
impossible to read at the assembly level.

therefore we'd still like to add the sv.xxx/yyy/ etc syntax, for use in
inline assembly, but gcc itsrlf would *not* use it.  turns out to be far
too disruptive to the rs6000.md config, where marking each macro "set attr
can_svp64" is easy.

On Friday, March 19, 2021, Alan Modra <amodra@gmail.com> wrote:

> On Mon, Mar 15, 2021 at 02:13:27PM +0000, lkcl via Binutils wrote:
> >     sv.{v3.0Bopcode} / augmentation=x / augmentation=y  r0.v, r30.s,
> r75.v
> >
> > with "=" and "/" already being used in gcc/binutils macro expressions,
> > what could be used instead?
>
> I don't see anything particularly wrong with the syntax you have
> chosen, except that someone using gas macros might have some
> difficulty passing a string like pr=eq when invoking a macro since
> that is likely to hit "Parameter named `pr' does not exist for
> macro".  Someone trying to do that will figure a way around that
> problem, I guess.


using ? instead of = as suggested below helps avoid it.  exccellent.


> I'm assuming that you would implement support for this extension by
> scanning and consuming the "sv.", any augmentation strings,


>
yes.  aoliva started along these lines



> and the
> ".v" or ".s" suffixes before passing the rest of the line to the
> existing md_assemble opcode lookup and parameter handling.


yes that was the plan.  although... option one is to add 128 FP reg
patterns to the regs lookup patterns and 128 INT regs and 128 CR patterns

(bleh)

or, to spot the ".v" or ".s", parse it (extracting the top 2 bits) and
*replace* the operand string with the reg number that needs to go into the
32bit op.


> ie. much
> the same as you already do using python.


yehyeh.  the principle is, we don't invent new opcode formats: it's simply
too much work at every level (for us and everyone else).

use existing v3.0B ones, extra bits "augment", job done.

That should work so long as
> you are flexible with white-space


wait, whur? :) ohhh yes, macros.

ahh do gnu-as users  _really_ use macros that create register names with
spaces? "f 0" rather than "f0" for example?


>  and the augmentation specifiers
> don't so anything silly like start with '*'.  Also, I think it would
> be a good idea to not accept a plain '.' suffix for scalars.


the ".s" can be left out, i.e. implicitly if not specified it's a scalar.
the scalar reg number which can be 0-127 still needs processing.


> Something like "1." could be a floating point constant.


fortunately in SVP64 we don't augment any immediates or other operands,
just the register numbers [and their bit width but that's in the / side]

the underlying behaviour has to remain the same for SVP64 to be called
"simple".  otherwise it's Complex-V :)


>  Regarding
> white-space, this user input:
>  sv.add / xx = 1 / yy = foo 3 .v, 4 .v, 5
> is turned into this input to md_assemble by app.c:do_scrub_chars
>  sv.add/ xx=1/yy=foo 3 .v,4 .v,5
>
> The fact that the first '/' is pasted onto the "sv.add" is probably a
> bug in '/*' comment handling code.  :-(


hmm would "." do as the separator instead?

sv.add.xx=1

no it wouldn't because of Rc=1 using "."


>
> If you want a replacement for '=' in your augmentation syntax to avoid
> the clash with macro args, '?' might be a better choice.


ahh thank you

do you happen to know of a 2nd one?  Segher recommended avoiding "/"
because it clashes with macro "divide" operator.

` backtick
' singlequote
! exclamation (not? or is that ~)
: colon

looking here
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm
this example is given:

__asm__ ("some instructions"
   : /* No outputs. */
   : "r" (Offset / 8));

does that get processed out by gcc? i ask because i think Segher may
have been referring to gcc inline asm macro processing rather than
gnu-as macro processing. we have to satisfy both.

thx Alain.

l.