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

[Alan Modra]

On Fri, Mar 19, 2021 at 02:25:57AM +0000, lkcl wrote:
> (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.

Sure, I'm not fussed at all over gcc assembly output.

> 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.

Have you thought about objdump -d?  I'm not worried about that for an
initial binutils contribution, but you just know people are going to
ask for disassembly that looks like their asm, don't you?

> 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.

Or just let everything go ahead to the point where gas is ready to
write out the instruction, then twiddle anything necessary.

> 
> > 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?

Not that I know of, but someone might want to tack on ".v", say, and
not know the trick to paste a macro parameter without white-space.

> >  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]

Good.

> 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.

Segher was probably worried about expressions rather than macros, in
particular, expressions in operands.  But from what I've understood so
far, you're not augmenting operands so this isn't a consideration.

Incidentally, I expect you can ignore the fact that powerpc-solaris
targets use '/' to start a comment.  Those targets are 32-bit only and
likely not built by anyone nowadays.

> ` 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.

None of the three slashes above will make their way into assembly.
I'm not aware of any special meaning given to a slash in the "some
instructions" part of that asm, except of course how the assembler
might interpret it.  '%', '{', '|' and '}' are special.

-- 
Alan Modra
Australia Development Lab, IBM