From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id 80F0D384F025 for ; Fri, 13 May 2022 07:55:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 80F0D384F025 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-wm1-x329.google.com with SMTP id k126so4335517wme.2 for ; Fri, 13 May 2022 00:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1EMk46ChvNEZHDtSTUz+TR7YCFY/JGopkxJBmUFI5TQ=; b=c/DpYRrIDDpDuKju6IW06IN/wNxNmAKmORcf/dOrCkAqa9CtQRhQ13LGrdMkYt5tQn 2SN3uCJckV6vDBMJUtFEnbkWK+K7eS1rAEp14GDyzcDmkK9gNwoExgBoqmyC6Rquqexc s5jJYpThPD2yYYMn88jUcDd2TsQfI7XmPN/aTU7wXhgQ6kWNrySFwtQ4DV93jSUOashL 4Y2p8RtuY+r6RSiAt5xFpZjXTd4RT75QwEJrlsnLdv3lnummcUgO/9vrT8W3k8supLUK KbHOoif2pPYxVYqKeRnzIMzHPdcLFv+p2ae6Fmu2aNPwAP4/lHbQfNTHv/8Py+ajJgvx GX3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1EMk46ChvNEZHDtSTUz+TR7YCFY/JGopkxJBmUFI5TQ=; b=JNBPryYG6WRI/C0+zyMo7FuahFSMesuJIjI0wC6wPtuVT7NWHLzysejO+wzYqjIfO6 FJaLb44c/bxCEhTq+kKuvfVa8IXSIrW5UsGbgta61UTIuPZn/ndMbv/2rbIYGki3Xy2m cgdVW+O3ciP0eHWzxtrdsnfxx4J048UQ8/GOf4esswYLQN6bHkhJABUWD7ed7W8cBdpG xe/8h+InwAID3J8qHjitcRfr32szekFIGQKECKiwWW/1mEBES3qBS32/ZOOCAKuYfD8D N/6H7V8oIva9qApQm1rBBlkWaVI3DzRF4dx0a92DaAWTaGzsAA98mTkoks1Ry2c1PkBB 3Z1A== X-Gm-Message-State: AOAM5313PjkFez4opgbUA+aeO0P5+hXnJlyXytjVnxnP88va6GG1MsvI Rz4wjkK6cRFCiYsRo0yK/Fnyt2c1fVrKlCrACvaX+A== X-Google-Smtp-Source: ABdhPJxelc7GDl4TdqaJZhdDA+dYIYzTn4X5TyRoSe9G6WAINqyJ+jKhCX9HXY6oYVDMK748vX6hCq/P6ugWxf8d94Y= X-Received: by 2002:a05:600c:35c1:b0:394:8621:a1d5 with SMTP id r1-20020a05600c35c100b003948621a1d5mr13726545wmq.196.1652428536088; Fri, 13 May 2022 00:55:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Tomsich Date: Fri, 13 May 2022 09:55:25 +0200 Message-ID: Subject: Re: [PATCH v1] RISC-V: Support XVentanaCondOps extension To: Palmer Dabbelt Cc: Nelson Chu , kito.cheng@sifive.com, Kito Cheng , binutils@sourceware.org, gfavor@ventanamicro.com, Jim Wilson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2022 07:55:41 -0000 On Fri, 13 May 2022 at 00:23, Palmer Dabbelt wrote: > > On Thu, 12 May 2022 12:59:58 PDT (-0700), philipp.tomsich@vrull.eu wrote: > > Nelson, > > > > The PR on the toolchain conventions was merged last week after weeks of > > discussions and everyone agreeing to these. > > Can we move this forward now? > > This has been a persistent problem with the RISC-V foundation. These > RISC-V ports are very small parts of much larger community-oriented > projects with well established communication mechanisms, and trying to > claim that everyone was involved in discussions that happened inside the > RISC-V foundation just isn't accurate. We consistently get very > valuable feedback from upstream contributors who chose to stick to > upstream-focused forums for discussion, pretending that feedback doesn't > exist just leads to unnecessary friction. Don't get me wrong here (I am merely trying to be pragmatic): projects don't have to adopt these conventions if they disagree. But: we had representation from the Binutils (nelson and andrew), GCC (kito), LLVM (asb), and QEMU (alistair) maintainers working on the (now merged) draft document. The expectation was that these same maintainers would represent their respective projects and then adopt a subset or superset of these conventions. Note that QEMU posed some additional requirements on top of these conventions (mainly how the vendor-specific extensions should be interfaced/factored out from the standard extensions=E2=80=94e.g., to make removing them in the future easier). I hope that anyone working on the software ecosystem as part of the RISC-V Foundation would earnestly believe that they can make the rules for upstream projects=E2=80= =A6 What happens inside of the RISC-V Foundation only governs its membership. However, we need to provide some general guidelines (as in: "If you don't have at least these minimal requirements covered, expect to be loudly ignored.") for said membership on what it takes to get vendor-defined extensions upstream. The conventions give a small, pragmatic, consensus-driven minimum set of requirements (again: upstream projects can choose to require more or less than this): (a) publicly available documentation and the (b) subdivision of the mnemonics namespace. I would imagine that some projects will have additional requirements (e.g., Should qemu-support be a requirement for acceptance into gcc or linux? There will be different opinions, and I don't want to presume what the consensus there will be=E2=80=A6). In contrast, others are waiving some of these (e.g., OpenSSL doesn't care for mnemonics and accepts hex-encoded instructions=E2=80=A6). The procedural question to get vendor-defined extensions (that don't require vendor-specific relocations) flowing into binutils is: 1. We had representation from RISC-V maintainers for binutils (I realise that neither you nor Jim commented, but would hope that you had been made aware of this =E2=80=94 of not, we'll need to figure that iss= ue out separately=E2=80=A6) on these conventions: Are we going to adopt them f= or the RISC-V backend in binutils? 2. And of course: are there additional requirements we want to pose (e.g. introduce a dependency on QEMU; require the vendor to list someone as a maintainer for the relevant extension)? We will be asking ourselves similar questions for GCC, once we submit the respective series for GCC (where XVentanaCondOps support lives in a separate .md-file). Just as an aside: I didn't expect all of this to be easy and straightforward; this is exactly the reason why I picked XVentanaCondOps (custom instruction opcode space, just 2 instructions, no relocations=E2=80=A6) to get the discussions moving forward. As soon as something more involved gets submitted, we will have to have some follow-on discussions and define additional rules (e.g., when vendor-defined relocations are required). > There's another thread started that includes the various GNU toolchain > projects and proposes taking support for vendor extensions. That is the > result of a handful of discussions, the RISC-V naming conventions are > part of that but there's a lot more than how to name extensions that's > proposed. What there is the best I could come up with after talking to > a handful of people, happy to discuss things further. Could you point me to the thread you refer to? There have been multiple threads in multiple forums, and I don't know which one is the leading one. Thanks, Philipp. > Those discussions > really need to happen in the relevant forums, though, as this is a > really big policy change that has wide-reaching ramifications. > > > Thanks, > > Philipp. > > > > On Mon, 25 Apr 2022 at 11:38, Nelson Chu wrote: > > > >> On Sat, Apr 23, 2022 at 9:42 AM Kito Cheng wro= te: > >> > > >> > Hi Philipp: > >> > > >> > I guess we can settle down Conventions for vendor extension[1] befor= e > >> > merging this? > >> > We are pretty close to a consensus, no objection for the generally i= dea, > >> > just remaining minor stuffs on the prefix naming scheme, > >> > so I believe that could resolve soon. > >> > > >> > [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pul= l/17 > >> > >> Once the PR is merged and most of the people agree with the rules > >> there, I will say LGTM for the vendor extensions in general. > >> > >> Thanks > >> Nelson > >> > >> > On Fri, Apr 22, 2022 at 6:37 PM Philipp Tomsich > >> > wrote: > >> > > > >> > > Nelson, > >> > > > >> > > Can we make some progress on this, please? > >> > > There are already some dependent/similar changes in the queue (e.g= . > >> xtheadcmo)... > >> > > > >> > > Philipp. > >> > > > >> > > On Wed, 20 Apr 2022 at 14:42, Kito Cheng wr= ote: > >> > >> > >> > >> Hi Philipp: > >> > >> > >> > >> I believe we have a consensus among most GNU toolchain maintainer= s for > >> > >> accepting vendor extension to upstream / master branch, > >> > >> so I am +1 for this patch, but I think we still need Nelson, Palm= er or > >> > >> Jim to give something LGTM here since I am not a binutils maintai= ner > >> > >> :) > >> > >> > >> > >> On Wed, Apr 20, 2022 at 7:38 PM Philipp Tomsich > >> > >> wrote: > >> > >> > > >> > >> > Kito & Nelson, > >> > >> > > >> > >> > What is the status on this one? > >> > >> > Let me know if it is approved for master, so I can rebase and > >> commit. > >> > >> > > >> > >> > Thanks, > >> > >> > Philipp. > >> > >> > > >> > >> > On Sun, 9 Jan 2022 at 20:29, Philipp Tomsich < > >> philipp.tomsich@vrull.eu> > >> > >> > wrote: > >> > >> > > >> > >> > > Ventana Micro has published the specification for their > >> > >> > > XVentanaCondOps ("conditional ops") extension at > >> > >> > > > >> > >> > > > >> https://github.com/ventanamicro/ventana-custom-extensions/releases/dow= nload/v1.0.0/ventana-custom-extensions-v1.0.0.pdf > >> > >> > > which contains two new instructions > >> > >> > > - vt.maskc > >> > >> > > - vt.maskcn > >> > >> > > that can be used in constructing branchless sequences for > >> > >> > > various conditional-arithmetic, conditional-logical, and > >> > >> > > conditional-select operations. > >> > >> > > > >> > >> > > To support such vendor-defined instructions in the mainline > >> binutils, > >> > >> > > this change also adds a riscv_supported_vendor_x_ext secondar= y > >> > >> > > dispatch table (but also keeps the behaviour of allowing any > >> unknow > >> > >> > > X-extension to be specified in addition to the known ones fro= m > >> this > >> > >> > > table). > >> > >> > > > >> > >> > > As discussed, this change already includes the planned/agreed > >> future > >> > >> > > requirements for X-extensions (which are likely to be capture= d in > >> the > >> > >> > > riscv-toolchain-conventions repository): > >> > >> > > - a public specification document is available (see above) = and > >> is > >> > >> > > referenced from the gas-documentation > >> > >> > > - the naming follows chapter 27 of the RISC-V ISA specifica= tion > >> > >> > > - instructions are prefixed by a vendor-prefix (vt for Vent= ana) > >> > >> > > to ensure that they neither conflict with future standard > >> > >> > > extensions nor clash with other vendors > >> > >> > > > >> > >> > > bfd/ChangeLog: > >> > >> > > > >> > >> > > * elfxx-riscv.c (riscv_get_default_ext_version): Add > >> > >> > > riscv_supported_vendor_x_ext. > >> > >> > > (riscv_multi_subset_supports): Recognize > >> > >> > > INSN_CLASS_XVENTANACONDOPS. > >> > >> > > > >> > >> > > gas/ChangeLog: > >> > >> > > > >> > >> > > * doc/c-riscv.texi: Add section to list custom extens= ions > >> and > >> > >> > > their documentation URLs. > >> > >> > > * testsuite/gas/riscv/x-ventana-condops.d: New test. > >> > >> > > * testsuite/gas/riscv/x-ventana-condops.s: New test. > >> > >> > > > >> > >> > > include/ChangeLog: > >> > >> > > > >> > >> > > * opcode/riscv-opc.h Add vt.maskc and vt.maskcn. > >> > >> > > * opcode/riscv.h (enum riscv_insn_class): Add > >> > >> > > INSN_CLASS_XVENTANACONDOPS. > >> > >> > > > >> > >> > > opcodes/ChangeLog: > >> > >> > > > >> > >> > > * riscv-opc.c: Add vt.maskc and vt.maskcn. > >> > >> > > > >> > >> > > --- > >> > >> > > > >> > >> > > bfd/elfxx-riscv.c | 13 +++++++++++= -- > >> > >> > > gas/doc/c-riscv.texi | 20 > >> ++++++++++++++++++++ > >> > >> > > gas/testsuite/gas/riscv/x-ventana-condops.d | 12 +++++++++++= + > >> > >> > > gas/testsuite/gas/riscv/x-ventana-condops.s | 4 ++++ > >> > >> > > include/opcode/riscv-opc.h | 7 +++++++ > >> > >> > > include/opcode/riscv.h | 1 + > >> > >> > > opcodes/riscv-opc.c | 4 ++++ > >> > >> > > 7 files changed, 59 insertions(+), 2 deletions(-) > >> > >> > > create mode 100644 gas/testsuite/gas/riscv/x-ventana-condops= .d > >> > >> > > create mode 100644 gas/testsuite/gas/riscv/x-ventana-condops= .s > >> > >> > > > >> > >> > > diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c > >> > >> > > index 8409c0254e5..39fc1e9911b 100644 > >> > >> > > --- a/bfd/elfxx-riscv.c > >> > >> > > +++ b/bfd/elfxx-riscv.c > >> > >> > > @@ -1241,6 +1241,13 @@ static struct riscv_supported_ext > >> > >> > > riscv_supported_std_zxm_ext[] =3D > >> > >> > > {NULL, 0, 0, 0, 0} > >> > >> > > }; > >> > >> > > > >> > >> > > +static struct riscv_supported_ext riscv_supported_vendor_x_e= xt[] > >> =3D > >> > >> > > +{ > >> > >> > > + /* XVentanaCondOps: > >> > >> > > > >> https://github.com/ventanamicro/ventana-custom-extensions/releases/dow= nload/v1.0.0/ventana-custom-extensions-v1.0.0.pdf > >> > >> > > */ > >> > >> > > + {"xventanacondops", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 }, > >> > >> > > + {NULL, 0, 0, 0, 0} > >> > >> > > +}; > >> > >> > > + > >> > >> > > const struct riscv_supported_ext *riscv_all_supported_ext[] = =3D > >> > >> > > { > >> > >> > > riscv_supported_std_ext, > >> > >> > > @@ -1248,6 +1255,7 @@ const struct riscv_supported_ext > >> > >> > > *riscv_all_supported_ext[] =3D > >> > >> > > riscv_supported_std_s_ext, > >> > >> > > riscv_supported_std_h_ext, > >> > >> > > riscv_supported_std_zxm_ext, > >> > >> > > + riscv_supported_vendor_x_ext, > >> > >> > > NULL > >> > >> > > }; > >> > >> > > > >> > >> > > @@ -1513,8 +1521,7 @@ riscv_get_default_ext_version (enum > >> riscv_spec_class > >> > >> > > *default_isa_spec, > >> > >> > > case RV_ISA_CLASS_Z: table =3D riscv_supported_std_z_ext= ; > >> break; > >> > >> > > case RV_ISA_CLASS_S: table =3D riscv_supported_std_s_ext= ; > >> break; > >> > >> > > case RV_ISA_CLASS_H: table =3D riscv_supported_std_h_ext= ; > >> break; > >> > >> > > - case RV_ISA_CLASS_X: > >> > >> > > - break; > >> > >> > > + case RV_ISA_CLASS_X: table =3D riscv_supported_vendor_x_= ext; > >> break; > >> > >> > > default: > >> > >> > > table =3D riscv_supported_std_ext; > >> > >> > > } > >> > >> > > @@ -2406,6 +2413,8 @@ riscv_multi_subset_supports > >> (riscv_parse_subset_t > >> > >> > > *rps, > >> > >> > > || riscv_subset_supports (rps, "zve32f")); > >> > >> > > case INSN_CLASS_SVINVAL: > >> > >> > > return riscv_subset_supports (rps, "svinval"); > >> > >> > > + case INSN_CLASS_XVENTANACONDOPS: > >> > >> > > + return riscv_subset_supports (rps, "xventanacondops"); > >> > >> > > default: > >> > >> > > rps->error_handler > >> > >> > > (_("internal: unreachable INSN_CLASS_*")); > >> > >> > > diff --git a/gas/doc/c-riscv.texi b/gas/doc/c-riscv.texi > >> > >> > > index be9c1148355..1e24053cbdc 100644 > >> > >> > > --- a/gas/doc/c-riscv.texi > >> > >> > > +++ b/gas/doc/c-riscv.texi > >> > >> > > @@ -20,6 +20,7 @@ > >> > >> > > * RISC-V-Modifiers:: RISC-V Assembler Modifiers > >> > >> > > * RISC-V-Formats:: RISC-V Instruction Formats > >> > >> > > * RISC-V-ATTRIBUTE:: RISC-V Object Attribute > >> > >> > > +* RISC-V-CustomExts:: RISC-V Custom (Vendor-Defined) > >> Extensions > >> > >> > > @end menu > >> > >> > > > >> > >> > > @node RISC-V-Options > >> > >> > > @@ -692,3 +693,22 @@ the privileged specification. It will > >> report errors > >> > >> > > if object files of > >> > >> > > different privileged specification versions are merged. > >> > >> > > > >> > >> > > @end table > >> > >> > > + > >> > >> > > +@node RISC-V-CustomExts > >> > >> > > +@section RISC-V Custom (Vendor-Defined) Extensions > >> > >> > > +@cindex custom (vendor-defined) extensions, RISC-V > >> > >> > > +@cindex RISC-V custom (vendor-defined) extensions > >> > >> > > + > >> > >> > > +The following table lists the custom (vendor-defined) RISC-V > >> > >> > > +extensions supported and provides the location of their > >> > >> > > +publicly-released documentation: > >> > >> > > + > >> > >> > > +@table @r > >> > >> > > +@item XVentanaCondOps > >> > >> > > +XVentanaCondOps extension provides instructions for branchle= ss > >> > >> > > +sequences that perform conditional arithmetic, conditional > >> > >> > > +bitwise-logic, and conditional select operations. > >> > >> > > + > >> > >> > > +It is documented at @url{ > >> > >> > > > >> https://github.com/ventanamicro/ventana-custom-extensions/releases/dow= nload/v1.0.0/ventana-custom-extensions-v1.0.0.pdf > >> > >> > > }. > >> > >> > > + > >> > >> > > +@end table > >> > >> > > diff --git a/gas/testsuite/gas/riscv/x-ventana-condops.d > >> > >> > > b/gas/testsuite/gas/riscv/x-ventana-condops.d > >> > >> > > new file mode 100644 > >> > >> > > index 00000000000..cab0cc8dc12 > >> > >> > > --- /dev/null > >> > >> > > +++ b/gas/testsuite/gas/riscv/x-ventana-condops.d > >> > >> > > @@ -0,0 +1,12 @@ > >> > >> > > +#as: -march=3Drv64i_xventanacondops1p0 > >> > >> > > +#source: x-ventana-condops.s > >> > >> > > +#objdump: -d > >> > >> > > + > >> > >> > > +.*:[ ]+file format .* > >> > >> > > + > >> > >> > > + > >> > >> > > +Disassembly of section .text: > >> > >> > > + > >> > >> > > +0+000 : > >> > >> > > +[ ]+0:[ ]+00c5e57b[ ]+vt.maskc[ ]+a0,a1,a2 > >> > >> > > +[ ]+4:[ ]+00e6f57b[ ]+vt.maskcn[ ]+a0,a3,a4 > >> > >> > > diff --git a/gas/testsuite/gas/riscv/x-ventana-condops.s > >> > >> > > b/gas/testsuite/gas/riscv/x-ventana-condops.s > >> > >> > > new file mode 100644 > >> > >> > > index 00000000000..562cf7384f7 > >> > >> > > --- /dev/null > >> > >> > > +++ b/gas/testsuite/gas/riscv/x-ventana-condops.s > >> > >> > > @@ -0,0 +1,4 @@ > >> > >> > > +target: > >> > >> > > + vt.maskc a0, a1, a2 > >> > >> > > + vt.maskcn a0, a3, a4 > >> > >> > > + > >> > >> > > diff --git a/include/opcode/riscv-opc.h > >> b/include/opcode/riscv-opc.h > >> > >> > > index 0b8cc6c7ddb..07c613163b7 100644 > >> > >> > > --- a/include/opcode/riscv-opc.h > >> > >> > > +++ b/include/opcode/riscv-opc.h > >> > >> > > @@ -2029,6 +2029,11 @@ > >> > >> > > #define MASK_HSV_W 0xfe007fff > >> > >> > > #define MATCH_HSV_D 0x6e004073 > >> > >> > > #define MASK_HSV_D 0xfe007fff > >> > >> > > +/* Vendor-specific (Ventana Microsystems) XVentanaCondOps > >> instructions */ > >> > >> > > +#define MATCH_VT_MASKC 0x607b > >> > >> > > +#define MASK_VT_MASKC 0xfe00707f > >> > >> > > +#define MATCH_VT_MASKCN 0x707b > >> > >> > > +#define MASK_VT_MASKCN 0xfe00707f > >> > >> > > /* Privileged CSR addresses. */ > >> > >> > > #define CSR_USTATUS 0x0 > >> > >> > > #define CSR_UIE 0x4 > >> > >> > > @@ -2628,6 +2633,8 @@ DECLARE_INSN(hsv_b, MATCH_HSV_B, MASK_H= SV_B) > >> > >> > > DECLARE_INSN(hsv_h, MATCH_HSV_H, MASK_HSV_H) > >> > >> > > DECLARE_INSN(hsv_w, MATCH_HSV_W, MASK_HSV_W) > >> > >> > > DECLARE_INSN(hsv_d, MATCH_HSV_D, MASK_HSV_D) > >> > >> > > +DECLARE_INSN(vt_maskc, MATCH_VT_MASKC, MASK_VT_MASKC) > >> > >> > > +DECLARE_INSN(vt_maskcn, MATCH_VT_MASKCN, MASK_VT_MASKCN) > >> > >> > > #endif /* DECLARE_INSN */ > >> > >> > > #ifdef DECLARE_CSR > >> > >> > > /* Privileged CSRs. */ > >> > >> > > diff --git a/include/opcode/riscv.h b/include/opcode/riscv.h > >> > >> > > index 048ab0a5d68..9384c6eb84b 100644 > >> > >> > > --- a/include/opcode/riscv.h > >> > >> > > +++ b/include/opcode/riscv.h > >> > >> > > @@ -388,6 +388,7 @@ enum riscv_insn_class > >> > >> > > INSN_CLASS_V, > >> > >> > > INSN_CLASS_ZVEF, > >> > >> > > INSN_CLASS_SVINVAL, > >> > >> > > + INSN_CLASS_XVENTANACONDOPS, > >> > >> > > }; > >> > >> > > > >> > >> > > /* This structure holds information for a particular > >> instruction. */ > >> > >> > > diff --git a/opcodes/riscv-opc.c b/opcodes/riscv-opc.c > >> > >> > > index 2da0f7cf0a4..6c70c5b99f3 100644 > >> > >> > > --- a/opcodes/riscv-opc.c > >> > >> > > +++ b/opcodes/riscv-opc.c > >> > >> > > @@ -1753,6 +1753,10 @@ const struct riscv_opcode riscv_opcode= s[] =3D > >> > >> > > {"hsv.w", 0, INSN_CLASS_I, "t,0(s)", MATCH_HSV_W, > >> MASK_HSV_W, > >> > >> > > match_opcode, INSN_DREF|INSN_4_BYTE }, > >> > >> > > {"hsv.d", 64, INSN_CLASS_I, "t,0(s)", MATCH_HSV_D, > >> MASK_HSV_D, > >> > >> > > match_opcode, INSN_DREF|INSN_8_BYTE }, > >> > >> > > > >> > >> > > +/* Vendor-specific (Ventana Microsystems) XVentanaCondOps > >> instructions */ > >> > >> > > +{"vt.maskc", 0, INSN_CLASS_XVENTANACONDOPS, "d,s,t", > >> MATCH_VT_MASKC, > >> > >> > > MASK_VT_MASKC, match_opcode, 0 }, > >> > >> > > +{"vt.maskcn", 0, INSN_CLASS_XVENTANACONDOPS, "d,s,t", > >> MATCH_VT_MASKCN, > >> > >> > > MASK_VT_MASKCN, match_opcode, 0 }, > >> > >> > > + > >> > >> > > /* Terminate the list. */ > >> > >> > > {0, 0, INSN_CLASS_NONE, 0, 0, 0, 0, 0} > >> > >> > > }; > >> > >> > > -- > >> > >> > > 2.33.1 > >> > >> > > > >> > >> > > > >>