From: Andrew Jones <ajones@ventanamicro.com> To: Conor Dooley <conor@kernel.org> Cc: Conor Dooley <conor.dooley@microchip.com>, 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 Date: Tue, 29 Nov 2022 18:19:51 +0100 [thread overview] Message-ID: <20221129171951.6kvvleeny5e2x2nk@kamzik> (raw) In-Reply-To: <Y4Y5O83NCNr1TOAy@spud> 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 <conor.dooley@microchip.com> > > > --- > > > 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. 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). I don't feel that strongly about it though, so we can keep the text the spec paraphrasing too. Thanks, drew > > > /* > > * 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. > > */ > > > > > > Thanks, > > drew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Jones <ajones@ventanamicro.com> To: Conor Dooley <conor@kernel.org> Cc: Conor Dooley <conor.dooley@microchip.com>, 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 Date: Tue, 29 Nov 2022 18:19:51 +0100 [thread overview] Message-ID: <20221129171951.6kvvleeny5e2x2nk@kamzik> (raw) In-Reply-To: <Y4Y5O83NCNr1TOAy@spud> 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 <conor.dooley@microchip.com> > > > --- > > > 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. 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). I don't feel that strongly about it though, so we can keep the text the spec paraphrasing too. Thanks, drew > > > /* > > * 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. > > */ > > > > > > Thanks, > > drew _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-11-29 17:20 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-24 13:04 [PATCH 0/2] riscv,isa fixups Conor Dooley 2022-11-24 13:04 ` Conor Dooley 2022-11-24 13:04 ` [PATCH 1/2] dt-bindings: riscv: fix underscore requirement for addtional standard extensions Conor Dooley 2022-11-24 13:04 ` Conor Dooley 2022-11-25 1:12 ` Guo Ren 2022-11-25 1:12 ` Guo Ren 2022-11-24 13:04 ` [PATCH 2/2] dt-bindings: riscv: fix single letter canonical order Conor Dooley 2022-11-24 13:04 ` Conor Dooley 2022-11-24 13:42 ` Heiko Stübner 2022-11-24 13:42 ` Heiko Stübner 2022-11-24 13:52 ` Conor Dooley 2022-11-24 13:52 ` Conor Dooley 2022-11-28 17:41 ` Palmer Dabbelt 2022-11-28 17:41 ` Palmer Dabbelt 2022-11-28 18:08 ` Conor Dooley 2022-11-28 18:08 ` Conor Dooley 2022-11-28 18:12 ` Palmer Dabbelt 2022-11-28 18:12 ` Palmer Dabbelt 2022-11-28 19:17 ` Conor Dooley 2022-11-28 19:17 ` Conor Dooley 2022-11-28 23:41 ` Palmer Dabbelt 2022-11-28 23:41 ` Palmer Dabbelt 2022-11-29 5:19 ` Andrew Jones 2022-11-29 5:19 ` Andrew Jones 2022-11-29 11:40 ` Conor Dooley 2022-11-29 11:40 ` Conor Dooley 2022-11-29 14:47 ` [RFC 0/2] Putting some basic order on isa extension stuff Conor Dooley 2022-11-29 14:47 ` Conor Dooley 2022-11-29 15:48 ` Andrew Jones 2022-11-29 15:48 ` Andrew Jones 2022-11-29 16:50 ` Conor Dooley 2022-11-29 16:50 ` Conor Dooley 2022-11-29 14:47 ` [RFC 1/2] RISC-V: clarify ISA string ordering rules in cpu.c Conor Dooley 2022-11-29 14:47 ` Conor Dooley 2022-11-29 16:12 ` Andrew Jones 2022-11-29 16:12 ` Andrew Jones 2022-11-29 16:54 ` Conor Dooley 2022-11-29 16:54 ` Conor Dooley 2022-11-29 17:19 ` Andrew Jones [this message] 2022-11-29 17:19 ` Andrew Jones 2022-11-29 17:48 ` Conor Dooley 2022-11-29 17:48 ` Conor Dooley 2022-11-29 14:47 ` [RFC 2/2] RISC-V: resort all extensions in "canonical" order Conor Dooley 2022-11-29 14:47 ` Conor Dooley 2022-11-29 16:35 ` Andrew Jones 2022-11-29 16:35 ` Andrew Jones 2022-12-01 13:51 ` [PATCH] Documentation: riscv: note that counter access is part of the uABI Conor Dooley 2022-12-01 13:51 ` Conor Dooley 2022-12-01 19:21 ` Palmer Dabbelt 2022-12-01 19:21 ` Palmer Dabbelt 2022-12-03 10:38 ` Jonathan Corbet 2022-12-03 10:38 ` Jonathan Corbet 2022-12-03 10:45 ` Jonathan Corbet 2022-12-03 10:45 ` Jonathan Corbet 2022-12-03 10:56 ` Conor Dooley 2022-12-03 10:56 ` Conor Dooley 2023-01-09 21:36 ` Atish Patra 2023-01-09 21:36 ` Atish Patra 2023-01-09 21:46 ` Conor Dooley 2023-01-09 21:46 ` Conor Dooley 2022-11-25 1:13 ` [PATCH 2/2] dt-bindings: riscv: fix single letter canonical order Guo Ren 2022-11-25 1:13 ` Guo Ren
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=20221129171951.6kvvleeny5e2x2nk@kamzik \ --to=ajones@ventanamicro.com \ --cc=aou@eecs.berkeley.edu \ --cc=conor.dooley@microchip.com \ --cc=conor@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=guoren@kernel.org \ --cc=heiko@sntech.de \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=robh+dt@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.