Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1184799rwb; Tue, 29 Nov 2022 10:01:37 -0800 (PST) X-Google-Smtp-Source: AA0mqf7K8v0sQIyYKVjvEByfBgyFabqC5wGnpMDQ+u9wmhzaBb4pPTP51HJ6PZSfEqtxNrusBmU5 X-Received: by 2002:a17:90a:b298:b0:212:f923:2f90 with SMTP id c24-20020a17090ab29800b00212f9232f90mr59445443pjr.93.1669744897335; Tue, 29 Nov 2022 10:01:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669744897; cv=none; d=google.com; s=arc-20160816; b=VElo00vqqkjq4z8CjlCAwIIvHZdNvR8SAEzPnYFePWVO3O/vJDZQPXXhvu6DehjAUT 1MPKFIMAlLyPVA/tPxpx2F1M1sNcfcWETYhwynh3UA5W9EardOIDTN7JGar6Fb3AeTQo tYO7kTytlxTOEPuoFxDTBLA6za0VFUt89RT7okuQXH42AKHrW3xF6PIFkV6yb3gIei/e Cg0CXdT5Mf3t2IItDZjscEoUsYHL3HGprwjo2ZCQD+jw9bHuVFGzeA0x/PTNqywPYqKn BuSOX/C2nwI5HK3W/NU5+LnyUiIZTtp3f97huNrIzadHpzl1viOjIm72fQFsZl5Mcs69 IuKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=xMs7u3nOf2xr6UNPMDFYcJcsZ7IgNlKSlAu6UvIWC3A=; b=LAlJWgXshZ/pWtSJ7RSQvNmh+LleVV20+7ugi/JljqTkOkat9zPrPcqrWBXnmbTGFS j1K2bBGlhI5zgrlvvPVKI2yAiRKO/HmSaeX49x+Yov/vH9WhZmDEqUWblwzn4B5l/aUx evO0+ZVmy33qCsx3NfsAMntKXV8h741zuZRL+a8Y2D3sumKjlIqTFDib5QCpTSZ5HF3d pyxPf7TPVC4iwx2xo8UKSh8p6IE3UrwLwlCRearAo5ThLLR2deylq5vmG4a86C9OWdyq aMwVC8bLbURtYX1XZFXdFureiTs1q/cO5rKi43pfVGdfaOT69hmEESAk++GQaQpq/Vn6 Ozxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KyUCIBxF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d18-20020a170902ced200b0018946b0b641si17249289plg.371.2022.11.29.10.01.23; Tue, 29 Nov 2022 10:01:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KyUCIBxF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236328AbiK2RtV (ORCPT + 84 others); Tue, 29 Nov 2022 12:49:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235829AbiK2RtH (ORCPT ); Tue, 29 Nov 2022 12:49:07 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3424269AAC; Tue, 29 Nov 2022 09:48:57 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BF64561866; Tue, 29 Nov 2022 17:48:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA94FC433D6; Tue, 29 Nov 2022 17:48:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669744136; bh=yrbXN5X5h7Pny/XhUR9FOsWs1xs8Rvdy9a2TeeCgzxo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KyUCIBxFxCUw+Ri9kQ0SuNXRTPyfbjq4JJVPm1zYOgcoUkAHwmionlVrQviYJO34n hKPbXp84YX4u9hORCegfJ6WNCY98+BGzirQSB60xtxEDESASs8PIRZjSTZeskHx1+p TYk7RNlWS/HVqvQJm7Ll8K6Scy+qlk0O0Pc+pGAQ6DxQnS8RYHjjqpQuHSehfSGcp6 wVi7Q0HkSJyFDI6HRZNVkJ0OBHWXj28Lv2jpX1UmNVYLreK4+Rsh0xKEPqCtD2UsB1 DmNtdYvr09dbAp8CmTcv9roQ6lvl/Hpo7XCsAIGUDJssOKftdNi35t/z2NpKt7vRNe GLaQVJzV8Qriw== Date: Tue, 29 Nov 2022 17:48:51 +0000 From: Conor Dooley To: Andrew Jones Cc: Conor Dooley , linux-riscv@lists.infradead.org, aou@eecs.berkeley.edu, devicetree@vger.kernel.org, guoren@kernel.org, heiko@sntech.de, krzysztof.kozlowski+dt@linaro.org, linux-kernel@vger.kernel.org, palmer@dabbelt.com, paul.walmsley@sifive.com, robh+dt@kernel.org Subject: Re: [RFC 1/2] RISC-V: clarify ISA string ordering rules in cpu.c Message-ID: References: <20221129144742.2935581-2-conor.dooley@microchip.com> <20221129161223.gelsvctfnqg7pdwb@kamzik> <20221129171951.6kvvleeny5e2x2nk@kamzik> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221129171951.6kvvleeny5e2x2nk@kamzik> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 29, 2022 at 06:19:51PM +0100, Andrew Jones wrote: > On Tue, Nov 29, 2022 at 04:54:19PM +0000, Conor Dooley wrote: > > On Tue, Nov 29, 2022 at 05:12:23PM +0100, Andrew Jones wrote: > > > On Tue, Nov 29, 2022 at 02:47:42PM +0000, Conor Dooley wrote: > > > > While the list of rules may have been accurate when created, it now > > > > lacks some clarity in the face of isa-manual updates. Specifically: > > > > > > > > - there is no mention here of a distinction between regular 'Z' > > > > extensions which are "Additional Standard Extensions" and "Zxm" > > > > extensions which are "Standard Machine-Level Extensions" > > > > > > > > - there is also no explicit mention of where either should be sorted in > > > > the list > > > > > > > > - underscores are only required between two *multi-letter* extensions but > > > > the list of rules implies that this is required between a multi-letter > > > > extension and any other extension. IOW "rv64imafdzicsr_zifencei" is a > > > > valid string > > > > > > > > Attempt to clean up the list of rules, by adding information on the > > > > above & sprinkling in some white space for readability. > > > > > > > > Signed-off-by: Conor Dooley > > > > --- > > > > arch/riscv/kernel/cpu.c | 22 +++++++++++++++++----- > > > > 1 file changed, 17 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > > > > index 852ecccd8920..5e42c92a8456 100644 > > > > --- a/arch/riscv/kernel/cpu.c > > > > +++ b/arch/riscv/kernel/cpu.c > > > > @@ -120,20 +120,32 @@ device_initcall(riscv_cpuinfo_init); > > > > .uprop = #UPROP, \ > > > > .isa_ext_id = EXTID, \ > > > > } > > > > + > > > > /* > > > > * Here are the ordering rules of extension naming defined by RISC-V > > > > * specification : > > > > - * 1. All extensions should be separated from other multi-letter extensions > > > > - * by an underscore. > > > > + * > > > > + * 1. All multi-letter extensions should be separated from other multi-letter > > > > + * extensions by an underscore. > > > > + * > > > > * 2. The first letter following the 'Z' conventionally indicates the most > > > > * closely related alphabetical extension category, IMAFDQLCBKJTPVH. > > > > - * If multiple 'Z' extensions are named, they should be ordered first > > > > - * by category, then alphabetically within a category. > > > > + * 'Z' extensions should be sorted after single-letter extensions and before > > > > + * any higher-privileged extensions. > > > > + * If multiple 'Z' extensions are named, they should be ordered first by > > > > + * category, then alphabetically within a category. > > > > + * > > > > * 3. Standard supervisor-level extensions (starts with 'S') should be > > > > * listed after standard unprivileged extensions. If multiple > > > > * supervisor-level extensions are listed, they should be ordered > > > > * alphabetically. > > > > - * 4. Non-standard extensions (starts with 'X') must be listed after all > > > > + * > > > > + * 4 Standard machine-level extensions (starts with 'Zxm') should be > > > > + * listed after any lower-privileged, standard extensions. If multiple > > > > + * machine-level extensions are listed, they should be ordered > > > > + * alphabetically. > > > > + * > > > > + * 5. Non-standard extensions (starts with 'X') must be listed after all > > > > * standard extensions. They must be separated from other multi-letter > > > > * extensions by an underscore. > > > > */ > > > > -- > > > > 2.38.1 > > > > > > > > > > Alternatively, we could change the comment to just point out the spec > > > chapter and provide an example, e.g. > > > > IDK, maybe add the reference & the example but keep the summary? > > It risks needing to synchronize the comment with the spec. Heh, see I almost see this as an *advantage* of this approach! > Also, the > comment doesn't need to reproduce the flexible specifications, since > Linux has a single implementation (it always puts an underscore between > single-letter extensions and the first multi-letter extension, for > example). So, rather than paraphrase too much of the spec, we could just > point out Linux's specific implementation (with the help of an example). You're right here though. I've had my head stuck in the incoming-string side of things rather than outgoing. I'll wait for the all clear from Above, but ideally I'll reword this explaining where this info shows up (and therefore why it needs to be ordered), what elements of the rules matter here (entirely ordering) and then include your bits from below? > I don't feel that strongly about it though, so we can keep the text > the spec paraphrasing too. > > > /* > > > * The canonical order of ISA extension names in the ISA string is defined in > > > * chapter 27 of the unprivileged spec. An example string following the > > > * order is > > > * > > > * rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux > > > * > > > * Notice how Z-extensions are first sorted by category using the canonical > > > * order of the first letter following the Z. Extension groups are in the > > > * order specified in chapter 27. Extensions within each group are sorted > > > * alphabetically. > > > */