From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 6E6703858D3C for ; Wed, 1 Mar 2023 02:03:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6E6703858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pl1-x62b.google.com with SMTP id y11so8324579plg.1 for ; Tue, 28 Feb 2023 18:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1677636229; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=V9q1eG0j5m/GZ7hcvazcsKww0+4sLtqDRLBeAd8uF00=; b=I+eXl5MxBKhZ4z9Z7cBwN0mX6U5rc+GWAVWDegpvpI3ldF9GgFkauYxujabbN1rawa 9ys9mX05tdoZnqzluhattiRDrEP2mRB8ehBKtpPIsF6LD82PTZPgYmZuWIAMieNgEkc2 r7YCCBi5XBhbHaw1Ja2C04tpPPpYkHq6ir4CeZ2wt8PgO6qju3dZF7ns3ZePDHuOq3Py 8Sw8MsEDQh39dbnSpo+6wORwnv9sjJstjTlQEievFL2ZFd1XW0zN7wMfkHOaEmg/nHw4 9Jc4qDoOUc5nDfIXIOV/xJJHp1woQc80DXjgo5ogDOlHCWbhWBjAivjYK8vEu6BhZ2ji hsvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677636229; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=V9q1eG0j5m/GZ7hcvazcsKww0+4sLtqDRLBeAd8uF00=; b=VaGuDhjvSagLqQDw/ZfSeVsNxId6ujju4zEg8LnD/AM4ZzONjhvguNkM+e5SnNGKC0 toxNWWyD5wmJ7Oyn/LFSUNbfOFA0rR3PI8nvuxqFiGQ6AgXtEaLV0nRBh1k9L7UvpMyg y6TtnmQdA0iCmKVuoqzqV0vxHpMzjVBWsYKcTXDNi+b9EqtIwh/o0VnqlFxKq35KV+is 7U6anWjNx9csSx1z6v/QaMGIOGVxvLE7IFqzJ6EbfAN739bT37YhcUYoe6xzebPSF3JI tKACx3MqMkTiQ9M65hStnawfngxpXt1/tkI+MyR6GZ248qjelsvq/u0NgtZxnXqchP51 LstA== X-Gm-Message-State: AO0yUKXK++g3PtVNz002Ml1biID/+OmQDEWK35q9Z1trU9JKAar1fRvV pqGhunYu5jtHpekRiUR9gdIo3Q== X-Google-Smtp-Source: AK7set8Kw+0sAGyJ23RNBtOANR63RZvcD0Yk9GvI7HRHNzhH5iWeUTazFMFpAS3rUAjRbScO1224dQ== X-Received: by 2002:a17:902:e801:b0:19a:b4a9:9df7 with SMTP id u1-20020a170902e80100b0019ab4a99df7mr5501480plg.53.1677636229245; Tue, 28 Feb 2023 18:03:49 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id f15-20020a170902684f00b0019a70a42b0asm7172298pln.169.2023.02.28.18.03.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Feb 2023 18:03:48 -0800 (PST) Date: Tue, 28 Feb 2023 18:03:48 -0800 (PST) X-Google-Original-Date: Tue, 28 Feb 2023 18:03:00 PST (-0800) Subject: Re: [RFC PATCH v1] RISC-V: Support Zicond extension In-Reply-To: CC: Andrew Waterman , jeffreyalaw@gmail.com, philipp.tomsich@vrull.eu, binutils@sourceware.org, kito.cheng@sifive.com, Nelson Chu , christoph.muellner@vrull.eu, Jim Wilson From: Palmer Dabbelt To: nelson@rivosinc.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 28 Feb 2023 17:58:29 PST (-0800), nelson@rivosinc.com wrote: > 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. Do you mean the Ventana cond ops? IIUC those are in their chip, so we'd need to support them regardless of what happens at RVI. > 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. Unless I'm missing something, neither the pre-freeze flavors of Zicond or the Ventana cond ops have landed upstream yet. So we shouldn't need to remove anything (which would generally be a problem if it had been released). > > Thanks > Nelson > > On Thu, Jan 26, 2023 at 9:03 AM Andrew Waterman wrote: >> >> On Wed, Jan 25, 2023 at 4:27 PM Jeff Law via Binutils >> 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 >> >