[CAUTION - External Sender] Re: [PATCH v6 02/15] RISC-V: Add support for the Zvbc extension

[Ken Dockser]

Hi,

This instruction is supported in RV32. The answer is in the pseudo code:

let op1 : bits (64) = if suffix =="vv" then get_velem(vs1,i)
                      else zext_or_truncate_to_sew(X(vs1));

The xv form of the instruction reads X(vs2) and zero-extends it to SEW=64.
When you need something other than 0s in the upper 32 bits of the vs1
operand, the vx form will not be very useful in RV32. However, the vv form
will continue to operate.


It looks like the SAIL code needs to be updated to match the spec.


Thanks,

Ken

On Mon, Jul 17, 2023 at 2:20 AM Christoph Müllner <
christoph.muellner@vrull.eu> wrote:

> +Ken Dockser
> +Nicolas Brunie
>
> I've added Ken and Nicolas (spec authors) to give an authoritative answer,
> and
> because this looks like a valid public-review comment for the
> specification.
>
> The spec indeed mentions "the 64-bit value from integer register rs1
> (vector-scalar)",
> which is unclear for RV32.
>
> BR
> Christoph
>
> On Mon, Jul 17, 2023 at 9:02 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 01.07.2023 07:20, Christoph Muellner wrote:
> > > --- a/opcodes/riscv-opc.c
> > > +++ b/opcodes/riscv-opc.c
> > > @@ -1902,6 +1902,12 @@ const struct riscv_opcode riscv_opcodes[] =
> > >  {"vwsll.vx",    0, INSN_CLASS_ZVBB, "Vd,Vt,sVm", MATCH_VWSLL_VX,
> MASK_VWSLL_VX, match_opcode, 0},
> > >  {"vwsll.vi",    0, INSN_CLASS_ZVBB, "Vd,Vt,VjVm", MATCH_VWSLL_VI,
> MASK_VWSLL_VI, match_opcode, 0},
> > >
> > > +/* Zvbc instructions.  */
> > > +{"vclmul.vv",   0, INSN_CLASS_ZVBC, "Vd,Vt,VsVm", MATCH_VCLMUL_VV,
> MASK_VCLMUL_VV, match_opcode, 0},
> > > +{"vclmul.vx",   0, INSN_CLASS_ZVBC, "Vd,Vt,sVm", MATCH_VCLMUL_VX,
> MASK_VCLMUL_VX, match_opcode, 0},
> >
> > I realize this is more a spec question than an implementation one, but
> > implementation might be affected by the answer to the question: What
> > exactly are this and ...
> >
> > > +{"vclmulh.vv",   0, INSN_CLASS_ZVBC, "Vd,Vt,VsVm", MATCH_VCLMULH_VV,
> MASK_VCLMULH_VV, match_opcode, 0},
> > > +{"vclmulh.vx",   0, INSN_CLASS_ZVBC, "Vd,Vt,sVm", MATCH_VCLMULH_VX,
> MASK_VCLMULH_VX, match_opcode, 0},
> >
> > ... this insn doing in RV32 mode? There are no 64 bits to take from
> > the GPR, yet that's what the doc presently says. Is the value coming
> > from a pair of GPRs, or is it sign- or zero-extended? Or is this an
> > RV64-only insn? (Note how the doc explicitly describes the behavior
> > for vandn's scalar-source form; the only thing left to be implied
> > there is that truncation / sign-extension are to - I assume - element
> > size, but maybe that's said somewhere in more general terms.)
> >
> > As a nit: The two vclmulh lines have one too many blanks, resulting
> > in columns to not be aligned.
> >
> > Jan
>