From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 56034385BF92 for ; Mon, 21 Feb 2022 14:50:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56034385BF92 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-lf1-x133.google.com with SMTP id i11so19123879lfu.3 for ; Mon, 21 Feb 2022 06:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MeSkBdw+x6HW+xUm2alAxeecaH7HMOMAXUzT7gHtgTY=; b=h1iAbv3ex28c463u59EDbJMSetEPyq9G/nePJiR+EZLqtXHQcNFWgZ2Fqn9SRhNN5V lBsPiS1TU8lt2WwLl/4dhkxdNAgeerl1MMLHX9HvQMeZms7VoHJcfbxDoJpGU6kY/jKL QBRfbdRSbImScvX1hO9J92hUWgf2P/fyieA1UuAdy3CK/Ni+iMaa1pIw7COYvhGPLZ25 rIiJJei5vVAxWmfUmlnBupchjvJWa8cUQjAVVgaH0nq1MWGBQl1/ZDGPiE8kdLwA23KQ RA3tFgR5pfyJyuK8FpIwA/nbRKk1nBWKCG4hf80M6+1yrxy9LNrKMYdUsG7HVh2ev5qI UlNw== 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=MeSkBdw+x6HW+xUm2alAxeecaH7HMOMAXUzT7gHtgTY=; b=z2SCxVi8PEkp6vmd5Tt67lP1rxWLcRvY8u9zrUzax/4tq2fOrw+k6cNQHG+2QcZsjN Nf4vdYhbx+uARDhHLtQ4olwmpeS8fhcnXNoNbXirfFcZ0JXkyBHx9ZbBMyQmeVr1Ayp8 M8I03SSnJhFJ9DgpjVvvXp4jTUDGBt7DhFzY7XrRWZZXdRQy3uz2RA8kkeoFPo7dDeAH 9yaGdFXDPNI7cU7ltol/kCaJKqQjcqyaAP/4W2gGMbidtSs5M3JkMg/HYSFQjk2di+uT HsR7ryNgg2MLh8OjM2VdA/6YFPZI8n2tEObxNPywvuVIxTbYXA9a5hb22qSTknYNVnGA IOuQ== X-Gm-Message-State: AOAM532PdGV/ovZT+k3+/iw42bXxobMp1BO1ksZSlLQqxWWGiWMQl/XX W4HGvLpfyZrKTVX2CyzQ3SKlevmJWE21+I+0QTLKtA== X-Google-Smtp-Source: ABdhPJyEXHJCe3b7sWBqvqcqbXRwexXyH1E0w/3rtMVkR4+4iJ6EnkK9RMy2NColwOhc7ivdCEP2kJKYL3R20/fS2KA= X-Received: by 2002:ac2:58d8:0:b0:442:bc4b:afb7 with SMTP id u24-20020ac258d8000000b00442bc4bafb7mr13523773lfo.99.1645455057160; Mon, 21 Feb 2022 06:50:57 -0800 (PST) MIME-Version: 1.0 References: <20211115030343.276103-1-jiawei@iscas.ac.cn> <20211115030343.276103-2-jiawei@iscas.ac.cn> <1490a2a8.1571c.17f1ca1de44.Coremail.jiawei@iscas.ac.cn> <4e5c118b-ce03-88c8-b1ac-864af25c8bfd@irq.a4lg.com> In-Reply-To: <4e5c118b-ce03-88c8-b1ac-864af25c8bfd@irq.a4lg.com> From: Kito Cheng Date: Mon, 21 Feb 2022 22:50:46 +0800 Message-ID: Subject: Re: [PATCH v4 1/3] RISC-V: Minimal support of scalar crypto extension To: Tsukasa OI Cc: Philipp Tomsich , jiawei , ben.marshall@pqshield.com, mjos@pqshield.com, siyu@isrc.iscas.ac.cn, Christoph Muellner , Binutils , Andreas Schwab , Jim Wilson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 21 Feb 2022 14:51:00 -0000 Maybe hold a string for the canonical order? I think accepting those extensions is kind of buggy. My patch for this proposal: https://sourceware.org/pipermail/binutils/2022-February/119827.html On Mon, Feb 21, 2022 at 10:44 PM Tsukasa OI wrote: > > > > On 2022/02/21 23:16, Philipp Tomsich wrote: > > On Mon, 21 Feb 2022 at 15:14, wrote: > >> > >> > >> > >> > >> > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > >> > =E5=8F=91=E4=BB=B6=E4=BA=BA: "Jan Beulich" > >> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2022-02-21 21:24:11 (=E6=98= =9F=E6=9C=9F=E4=B8=80) > >> > =E6=94=B6=E4=BB=B6=E4=BA=BA: jiawei > >> > =E6=8A=84=E9=80=81: kito.cheng@sifive.com, nelson.chu@sifive.com,= jimw@sifive.com, philipp.tomsich@vrull.eu, mjos@pqshield.com, ben.marshall= @pqshield.com, cmuellner@ventanamicro.com, palmer@dabbelt.com, andrew@sifiv= e.com, lazyparser@gmail.com, siyu@isrc.iscas.ac.cn, schwab@linux-m68k.org, = binutils@sourceware.org > >> > =E4=B8=BB=E9=A2=98: Re: [PATCH v4 1/3] RISC-V: Minimal support of= scalar crypto extension > >> > > >> > On 15.11.2021 04:03, jiawei wrote: > >> > > Minimal support of scalar crypto extension, add "k" in riscv= _supported_std_ext[] to make the order check right with "zk" behind "zb".= "zbk*" is sub-extension for k-ext, so it added behind "zbs" in riscv_suppo= rted_std_z_ext[]. > >> > > --- > >> > > bfd/elfxx-riscv.c | 28 ++++++++++++++++++++++++++++ > >> > > 1 file changed, 28 insertions(+) > >> > > > >> > > diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c > >> > > index 3ffbaad66dd..152fbe3d160 100644 > >> > > --- a/bfd/elfxx-riscv.c > >> > > +++ b/bfd/elfxx-riscv.c > >> > > @@ -1075,6 +1075,20 @@ static struct riscv_implicit_subset r= iscv_implicit_subsets[] =3D > >> > > {"q", "d", check_implicit_always}, > >> > > {"d", "f", check_implicit_always}, > >> > > {"f", "zicsr", check_implicit_always}, > >> > > + {"zk", "zkn", check_implicit_always}, > >> > > + {"zk", "zkr", check_implicit_always}, > >> > > + {"zk", "zkt", check_implicit_always}, > >> > > + {"zkn", "zbkb", check_implicit_always}, > >> > > + {"zkn", "zbkc", check_implicit_always}, > >> > > + {"zkn", "zbkx", check_implicit_always}, > >> > > + {"zkn", "zkne", check_implicit_always}, > >> > > + {"zkn", "zknd", check_implicit_always}, > >> > > + {"zkn", "zknh", check_implicit_always}, > >> > > + {"zks", "zbkb", check_implicit_always}, > >> > > + {"zks", "zbkc", check_implicit_always}, > >> > > + {"zks", "zbkx", check_implicit_always}, > >> > > + {"zks", "zksed", check_implicit_always}, > >> > > + {"zks", "zksh", check_implicit_always}, > >> > > {NULL, NULL, NULL} > >> > > }; > >> > > > >> > > @@ -1127,6 +1141,7 @@ static struct riscv_supported_ext risc= v_supported_std_ext[] =3D > >> > > {"c", ISA_SPEC_CLASS_20190608, 2, 0, = 0 }, > >> > > {"c", ISA_SPEC_CLASS_2P2, 2, 0, = 0 }, > >> > > {"b", ISA_SPEC_CLASS_NONE, RISCV_UNKNOWN_VER= SION, RISCV_UNKNOWN_VERSION, 0 }, > >> > > + {"k", ISA_SPEC_CLASS_NONE, RISCV_UNKNOWN_VER= SION, RISCV_UNKNOWN_VERSION, 0 }, > >> > > >> > May I ask what purpose this addition serves? Without its use enab= ling > >> > smaller scope extensions implicitly, I find it at best unhelpful = that > >> > ".option arch, +k" is accepted without having any effect. > >> > > >> > Jan > >> > >> It's same like bitmanip extension, add this will make k extension as a= subextension > >> and set it's canonical order as ISA spec defined. > > > > Let me point out that this is not the same as with the > > bit-manipulation family of extensions. > > Zb[abcs] are all standalone extensions, and there is no Zb. > > > > --Phil. > > I agree. > > But we cannot remove these now for a good reason. > > This is because riscv_supported_std_ext is used to determine canonical > order of multi-letter extensions (starting with 'Z'). See > riscv_init_ext_order function (bfd/elfxx-riscv.c) for details. > > Maybe we should make a marker (flag?) for "canonical order is determined > by this but not an actual extension". This will apply to... > > - "L" > - "B" > - "K" > - "J" > - "T" > - "P" > - "N" > > Tsukasa > > > > >> > >> > > >> > > @@ -1146,6 +1161,19 @@ static struct riscv_supported_ext ris= cv_supported_std_z_ext[] =3D > >> > > {"zba", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > {"zbc", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > {"zbs", ISA_SPEC_CLASS_DRAFT, 1, = 0, 0 }, > >> > > + {"zbkb", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zbkc", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zbkx", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zk", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zkn", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zknd", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zkne", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zknh", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zkr", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zks", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zksed", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 }, > >> > > + {"zksh", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > + {"zkt", ISA_SPEC_CLASS_DRAFT, 1, 0, = 0 }, > >> > > {NULL, 0, 0, 0, 0} > >> > > }; > >> > > > >> > >