From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) by sourceware.org (Postfix) with ESMTPS id 911A93858C52 for ; Thu, 19 Oct 2023 08:33:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 911A93858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 911A93858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4860:4864:20::35 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697704405; cv=none; b=kkMKlLBc1eWYTFzkNeH9ndbDeVSANm3pmHGa4mcbwOeld97VbBoiwZy5qYEic1YSGMZQsEShocYV4ffugyWp2P6yaUEU11cpUr0QdPCx84DWFrRV5dcMJpp9thoHyNLF3iN0qAqC33VP1T0IFGXlLtq81LBMeKXJYlfeh3InIvA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697704405; c=relaxed/simple; bh=nfhozjenN0e+Ch9GYvRPzf3hlcsiFyA5fx0XH3/qTZ8=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=OgEIfRJch/9nq62UxsDXNd0WjVkpMBvH4hx4qMi626Siqf8NNHJRc8PIcF6vZLs16E2qjtYpS+whe2RjY1ZwZPEiIRuT5a9pbFQVhT6UvvZfLCWlUD9awMIgsiZGUpmkUdNgfK6+MkgurTcubVwU3O5P76p8/ToNnXNPH3mk0Jk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-1c0fcbf7ae4so5334230fac.0 for ; Thu, 19 Oct 2023 01:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1697704400; x=1698309200; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dJSeI1GUd5pBcyyT8vQvjIQ+PgzbRmsB1tSkUVptmZI=; b=f/pr/u/JYXupLF0XMeuJXpxV7GGRvbNEGiq3wlbxCw+p6tnhMXe1GivLCn5kKXiAYm NaEWQn8uqLYAY3VrPYXGl7CAC+prXDl0Em1q9rAIkoL8KH4JI5VVbYLfpoSiMJr1UtJz JwJxz25We5esDbslssQN1I7CegsQp/2lCTMdGVnHLr5szir3FNVJv0AB5OiuH2tatZiS 9ZqXbtxqyrjqGT9LWyDBFc8cfbkA0AMxnVL2reICwkNcF0YIMHGsypjsXPEjIWWZ2bMK WQfmtqjNpyk/Ngz6pSl1beSYJSaZOOy2OLQwqj1RgLBJo15KQ3Nn1J4JUuBM7fl3mZr4 7Dfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697704400; x=1698309200; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dJSeI1GUd5pBcyyT8vQvjIQ+PgzbRmsB1tSkUVptmZI=; b=nmFIqn06/bhzzzTCNX9HV62fL74NkgbCKagDG2OZUct1E5jyVBu8fQG0WXpa1iTyBA rwmRB2+irJ0fTEBfazN7wVnvkS7cn+32fSwXsREL841KvLESLxlcDk5vMSbF8etxl1RX ZpYTs7dnAe7Z9czAb/txzKV72Hu7jng1iKRH7lQKZaEuelJeeOBRGPLNqH4xpUrIXY7S ED9CeZXVXM5ajQA45tcFG9727F5g31mnTM7Qck6qmzO0tB+1HNxJ81Jf8XuQJTcyrKo3 vaRQdjMPvCeEpSM6fJAR5sYP3jiBrbt26nlyEjaG9b4erI9mbtgAG3/Uyk5YxPDKly8W bYxw== X-Gm-Message-State: AOJu0YzH5RrtmAv7NSqecP0lzyHID5mz+unS0089INjQ2T1dtuGosKbB LZ/Xa9gTOLxKjOTvrZCpCeN0e+m/ad5LmI02uNGVI1oC2XWfhlkrnPswCQ== X-Google-Smtp-Source: AGHT+IG68+C6zm6HdypEehUtTY3NadlHjsL4KHhtFOpDDQbUcxHRyAQcyU/kkawBP/45yT/pEXeADNFNjsKepVVFoLk= X-Received: by 2002:a05:6870:7184:b0:1e9:f220:ac3b with SMTP id d4-20020a056870718400b001e9f220ac3bmr1850369oah.32.1697704399745; Thu, 19 Oct 2023 01:33:19 -0700 (PDT) MIME-Version: 1.0 References: <3a56687f-e513-4662-aca9-f3d2a6587acb@irq.a4lg.com> In-Reply-To: <3a56687f-e513-4662-aca9-f3d2a6587acb@irq.a4lg.com> From: Nelson Chu Date: Thu, 19 Oct 2023 16:33:08 +0800 Message-ID: Subject: Re: [PING^1][RFC PATCH 0/2] RISC-V: Add 'Zicntr' and 'Zihpm' support with compatibility measures To: Tsukasa OI Cc: binutils@sourceware.org Content-Type: multipart/alternative; boundary="000000000000ae4e6506080d9bb4" X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,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: --000000000000ae4e6506080d9bb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I hope we can remove the support of -misa-spec and -mpriv-spec from binutils, and then simply support the newest extension versions and CSRs by default. These features are good until spec 20191213 and privileged spec 2.2, but they are harmful later, since spec no longer needs its own versions. Continuing to build on all this mistake will make it all look worse, so I hope we can stop supporting -misa-spec/-mpriv-spec to take care of the compatibility issues. Only in this way can we prevent us from wasting time on these faults caused by me many years ago. Thanks Nelson On Thu, Oct 19, 2023 at 3:58=E2=80=AFPM Tsukasa OI wrote: > Ping to all RISC-V folks, > > Though there are more possible ways than described in the original > e-mail, at least I would like to hear from you all what do you want when > we are going to support now ratified 'Zicntr' and 'Zihpm' extensions. > > > Additional Note 1. When "zicntr" and/or "zihpm" are explicitly stated? > > My initial RFC PATCH suppresses output of Zicntr and Zihpm extensions > unless the version number is specified explicitly (there's room to fix > this issue). > > Additional Note 2. Warn, instead of making errors? > > We have an option to make warnings when 'Zicntr' instructions are used > without the 'Zicntr' extension (when we are going to "compliant mode"). > That will add a special code path but can be less breaking for users. > > > Sincerely, > Tsukasa > > On 2023/08/08 12:17, Tsukasa OI wrote: > > Hi, > > > > The role of this patch set is very simple: implement recently ratified > > 'Zicntr' (basic counters and timers) and 'Zihpm' (hardware performance > > counters) extensions, formerly a part of the 'I' extension, version 2.0. > > > > Since some draft extensions depend on those extensions, implementing > counter > > extensions (as a part of data structure) is becoming mandatory. > > > > However, we need to be *very* careful to the implementation. Because > > CSRs and pseudoinstructions for those extensions were a part of 'I' and > > more importantly, the first version which separated counters from the '= I' > > extension, did not give counters extension names. So, we needed to > > implement such CSRs and pseudoinstructions as a part of 'I' > (continuously). > > > > > > Not breaking the compatibility here is vital (the only exception might = be > > the new ratified ISA after version 20191213). So, I implemented those > > extensions not to break anything as possible. > > > > The basic idea is, an extension (riscv_subset_t) with an unknown version > is > > not emitted to an object file (ELF attributes, mapping symbols etc...). > > > > The default mode for existing ISAs is the compatibility mode (Option 1). > > > > > > [Option 1: Compatibility Mode] > > > > In the compatibility mode (as default), > > > > 1. 'I' implies 'Zicntr' and 'Zihpm'. > > 2. 'Zicntr' and 'Zihpm' DO NOT imply 'Zicsr'. > > 3. 'Zicntr' and 'Zihpm' don't have version information. > > > > (2.) is the point. The ratified document says 'Zicntr' and 'Zihpm' > depend > > on the 'Zicsr' extension but if we do it unconditionally, that would me= an > > that the 'I' extension indirectly depends on 'Zicsr' (because of 1.), > making > > a difference from the ratified 'I' extension version 2.1. In order to > keep > > the compatibility, making 'Zicntr' and 'Zihpm' against the documentation > was > > (sadly) necessary. > > > > In the compatibility mode, code like: > > > >> riscv_subset_supports(&rps, "zicntr") > > > > will return true. Because, even that the version information is missin= g, > > the 'Zicntr' extension exists in the riscv_subset_list_t. But an > extension > > with no version means, it will not be a part of the architectural string > > emitted as a part of an object file. > > > > > > [Option 2: Compliant Mode] > > > > We can continue this forever but we have another option. Break false > > dependency when a new ISA (with its version) is ratified and in that > time, > > require those extensions separately like -march=3D..._zicntr_zihpm. > > > > In the compliant mode: > > > > 1. 'I' DOES NOT imply 'Zicntr' and 'Zihpm'. > > 2. 'Zicntr' and 'Zihpm' DO imply 'Zicsr'. > > 3. 'Zicntr' and 'Zihpm' have its version information > > (ratified version 2.0 or possibly a later version) > > > > Note that (1.) and (2.) are very opposite from the compatibility mode. > > > > In this mode, it is compliant to the specification completely. > > > > > > > > > > [Implementing an Option on future ISAs] > > > > Assume that we have a new ISA specification class, > ISA_SPEC_CLASS_2024XXXX. > > We can choose which option to implement as follows. > > > > > > [Option 1: Compatibility Mode] > > > > 1. Change the contents of check_implicit_compat_counter_from_i. > > > >> /* Old. */ > >> return *rps->isa_spec <=3D ISA_SPEC_CLASS_20191213; > > > >> /* New. */ > >> return *rps->isa_spec <=3D ISA_SPEC_CLASS_2024XXXX; > > > > Note that the reason we are looking for the ISA specification (instead = of > > the version of the 'I' extension) is, the 'I' extension version 2.1 is > > unlikely to change even when the new ISA specification is ratified. > > I assume that two behaviors (option 1 and 2) share the same 'I' version > 2.1. > > > > If the version of the 'I' extension changes (even if no *actual* changes > > are made) in the new unprivileged ISA version, that would be a bit > simpler. > > > > 2. Add following entries to riscv_supported_std_z_ext. > > > > Make sure that they don't have the version number. > > > >> /* ... */ > >> {"zicntr", ISA_SPEC_CLASS_2024XXXX, > RISCV_UNKNOWN_VERSION, RISCV_UNKNOWN_VERSION, 0 }, /* Compat. */ > >> /* ... */ > >> {"zihpm", ISA_SPEC_CLASS_2024XXXX, > RISCV_UNKNOWN_VERSION, RISCV_UNKNOWN_VERSION, 0 }, /* Compat. */ > > > > > > [Option 2: Compliant Mode] > > > > 1. DO NOT change the contents of check_implicit_compat_counter_from_i. > > 2. Add following entries to riscv_supported_std_z_ext. > > > > Make sure that they DO have the version number. > > > >> /* ... */ > >> {"zicntr", ISA_SPEC_CLASS_2024XXXX, 2, 0, 0 }, > >> /* ... */ > >> {"zihpm", ISA_SPEC_CLASS_2024XXXX, 2, 0, 0 }, > > > > ...and for compatibility, we need to slightly modify riscv-dis.c. The > > disassembler defaults to the latest non-draft ISA and there's currently > no > > ways to change it. We need to make changes to riscv-dis.c by either: > > > > 1. Entering special compatibility mode (even on the latest ISA, enable > > 'Zicntr' extension ['Zihpm' is not necessary on the disassembler]) = or > > 2. Enabling to change the ISA version from disassembler options. > > Like my long proposed disassembler changes: adding overridable "arc= h" > > and "priv-spec" options, we have an option to change the ISA using > the > > disassembler option. > > > > > > > > In either case, this patch set leaves both options to implement yet > > supporting 'Zicntr' and 'Zihpm' extensions directly. > > > > > > > > > > Along with those changes (in PATCH 2), PATCH 1 makes possible to consid= er > > implication by using *more* information than before. This is practical= ly > > the same as: > > , > > a patch to demonstrate how to implement the 'Zce' superset extension > > ('Zcf' must be implied by 'Zce' ONLY IF 'F' is ALSO enabled). > > > > The only difference is a minor type change as follows (to enable using > > the "riscv_subset_supports" function). > > > > * Before: "const riscv_parse_subset_t *" > > * After: " riscv_parse_subset_t *" > > > > > > > > > > Is there any other options? Should I simplify the patch assuming we > choose > > the compatibility mode (Option 1) forever? > > > > In any case, I would like to hear your thoughts. > > > > Thanks, > > Tsukasa > > > > > > > > > > Tsukasa OI (2): > > RISC-V: Base for complex extension implications > > RISC-V: Add 'Zicntr' and 'Zihpm' support with compatibility measures > > > > bfd/elfxx-riscv.c | 86 +++++-- > > gas/config/tc-riscv.c | 16 ++ > > gas/testsuite/gas/riscv/march-imply-i.s | 8 + > > include/opcode/riscv-opc.h | 310 ++++++++++++------------ > > include/opcode/riscv.h | 1 + > > opcodes/riscv-opc.c | 12 +- > > 6 files changed, 256 insertions(+), 177 deletions(-) > > > > > > base-commit: d734d43a048b33ee12df2c06c2e782887e9715f6 > --000000000000ae4e6506080d9bb4--