public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nelson Chu <nelson@rivosinc.com>
To: Andrew Waterman <andrew@sifive.com>
Cc: Jeff Law <jeffreyalaw@gmail.com>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	 binutils@sourceware.org, Kito Cheng <kito.cheng@sifive.com>,
	 Nelson Chu <nelson.chu@sifive.com>,
	Christoph Muellner <christoph.muellner@vrull.eu>,
	 Jim Wilson <jim.wilson.gcc@gmail.com>,
	Palmer Dabbelt <palmer@rivosinc.com>
Subject: Re: [RFC PATCH v1] RISC-V: Support Zicond extension
Date: Wed, 1 Mar 2023 09:58:29 +0800	[thread overview]
Message-ID: <CAPpQWtABrzj14t8vKehScX5U_N_TTzmE-7=AZazY4cbdP1Q8PA@mail.gmail.com> (raw)
In-Reply-To: <CA++6G0DdsuSN5MjSHwZM-bA9Py_mVGEocufj0N=e0dZ51vZ7-w@mail.gmail.com>

Hey Guys,

I had heard that the final ratification of the zicond extension is
coming soon, so it's time to see what we should do for those old
vendor mnemonics and encodings, according to the current gnu policy.
Not sure if maintaining compatibility of vendor stuff is worth it, but
considering that obsolete vendor stuff should be replaced by the
ratified zicond as soon as possible (or we should encourage everyone
to use the RVI extension rather than the vendor one), maybe just
removing them when the zicond committed is more intuitive.

Thanks
Nelson

On Thu, Jan 26, 2023 at 9:03 AM Andrew Waterman <andrew@sifive.com> wrote:
>
> On Wed, Jan 25, 2023 at 4:27 PM Jeff Law via Binutils
> <binutils@sourceware.org> wrote:
> >
> >
> >
> > On 1/20/23 17:29, Philipp Tomsich wrote:
> > > *** Zicond is not FROZEN at this time. Do not merge until FROZEN. ***
> > >
> > > This implements the Zicond (conditional integer operations) extension,
> > > as of version 1.0-draft-20230120.
> > >
> > > The Zicond extension acts as a building block for branchless sequences
> > > including conditional-arithmetic, conditional-logic and
> > > conditional-select/move.
> > > The following instructions constitute Zicond:
> > >    - czero.eqz rd, rs1, rs2  =>  rd = (rs2 == 0) ? 0 : rs1
> > >    - czero.nez rd, rs1, rs2  =>  rd = (rs2 != 0) ? 0 : rs1
> > >
> > > See
> > >    https://github.com/riscv/riscv-zicond/releases/download/v1.0-draft-20230120/riscv-zicond_1.0-draft-20230120.pdf
> > > for the proposed specification and usage details.
> > >
> > > bfd/ChangeLog:
> > >
> > >       * elfxx-riscv.c (riscv_multi_subset_supports): Recognize
> > >          INSN_CLASS_XVENTANACONDOPS.
> > >       (riscv_multi_subset_supports_ext): Recognize
> > >       INSN_CLASS_XVENTANACONDOPS,
> > >
> > > gas/ChangeLog:
> > >
> > >       * testsuite/gas/riscv/zicond.d: New test.
> > >       * testsuite/gas/riscv/zicond.s: New test.
> > >
> > > include/ChangeLog:
> > >
> > >       * opcode/riscv-opc.h (MATCH_CZERO_EQZ): Define.
> > >       (MASK_CZERO_EQZ): Define.
> > >       (MATCH_CZERO_NEZ): Define,
> > >       (MASK_CZERO_NEZ): Define.
> > >       (DECLARE_INSN): Add czero.eqz and czero.nez.
> > >       * opcode/riscv.h (enum riscv_insn_class): Add
> > >          INSN_CLASS_ZICOND
> > >
> > > opcodes/ChangeLog:
> > >
> > >       * riscv-opc.c: Add czero.eqz and czero.nez.
> > Given this extension is derived from the Ventana condops extension, I
> > may be somewhat biased.
>
> This is very much a standardized version of Ventana's custom condops
> extension, modulo some details.
>
> > The mnemonics and encoding is obviously
> > different, but the behavior is the same (perhaps differing in timing
> > characteristics, but I think that's outside of what we care about here).
> >
> > I assume nobody cares about gdbsim, so nothing to do there.  With that
> > assumption this is fine to go forward once the spec freezes.
>
> As for a status update, the RVI architecture-review committee recently
> voted to approve the extension, so the official freeze should be
> forthcoming.
>
> >
> > jeff
> >

  reply	other threads:[~2023-03-01  1:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-21  0:29 Philipp Tomsich
2023-01-26  0:26 ` Jeff Law
2023-01-26  1:02   ` Andrew Waterman
2023-03-01  1:58     ` Nelson Chu [this message]
2023-03-01  2:03       ` Palmer Dabbelt
2023-06-19 14:21   ` Philipp Tomsich
2023-06-21  4:25     ` Jeff Law
2023-06-21  4:38       ` Palmer Dabbelt
2023-06-27 13:27         ` Jeff Law
2023-06-27 14:32           ` Philipp Tomsich
2023-06-27 23:12             ` Jeff Law
2023-06-27 23:33               ` Palmer Dabbelt
2023-06-27 14:48           ` Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPpQWtABrzj14t8vKehScX5U_N_TTzmE-7=AZazY4cbdP1Q8PA@mail.gmail.com' \
    --to=nelson@rivosinc.com \
    --cc=andrew@sifive.com \
    --cc=binutils@sourceware.org \
    --cc=christoph.muellner@vrull.eu \
    --cc=jeffreyalaw@gmail.com \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=nelson.chu@sifive.com \
    --cc=palmer@rivosinc.com \
    --cc=philipp.tomsich@vrull.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).