From: Conor Dooley <conor@kernel.org> To: Palmer Dabbelt <palmer@dabbelt.com>, linux-riscv@lists.infradead.org Cc: Conor Dooley <conor.dooley@microchip.com>, ajones@ventanamicro.com, aou@eecs.berkeley.edu, conor@kernel.org, corbet@lwn.net, guoren@kernel.org, heiko@sntech.de, paul.walmsley@sifive.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: [PATCH v1 3/3] Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo Date: Wed, 30 Nov 2022 23:41:26 +0000 [thread overview] Message-ID: <20221130234125.2722364-4-conor@kernel.org> (raw) In-Reply-To: <20221130234125.2722364-1-conor@kernel.org> From: Conor Dooley <conor.dooley@microchip.com> The RISC-V specs are permissive in what they allow as the ISA string, but how we output this to userspace in /proc/cpuinfo is quasi uAPI. Formalise this as part of the uAPI, by documenting the list of rules we use at this point in time. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> --- I've not "tested" these docs. The NIPA-esque pwbot should go and test it AFAICT. If it doesn't, I'll go add that. --- Documentation/riscv/uabi.rst | 42 ++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst index 21a82cfb6c4d..bc3c8ced644b 100644 --- a/Documentation/riscv/uabi.rst +++ b/Documentation/riscv/uabi.rst @@ -3,4 +3,46 @@ RISC-V Linux User ABI ===================== +Misaligned accesses +------------------- + Misaligned accesses are supported in userspace, but they may perform poorly. + +ISA string ordering in /proc/cpuinfo +------------------------------------ + +The canonical order of ISA extension names in the ISA string is defined in +chapter 27 of the unprivileged specification. +The specification uses vague wording, such as should, when it comes to +ordering, so for our purposes the following rules apply: + +#. Single-letter extensions come first, in "canonical order", so + "IMAFDQLCBKJTPVH". + +#. All multi-letter extensions will be separated from other multi-letter + extensions by an underscore. + +#. Additional standard extensions (starting with 'Z') will be sorted after + single-letter extensions and before any higher-privileged extensions. + +#. 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. + +#. Standard supervisor-level extensions (starting with 'S') will be listed + after standard unprivileged extensions. If multiple + supervisor-level extensions are listed, they will be ordered + alphabetically. + +#. Standard machine-level extensions (starting with 'Zxm') will be listed + after any lower-privileged, standard extensions. If multiple + machine-level extensions are listed, they will be ordered + alphabetically. + +#. Non-standard extensions (starts with 'X') will be listed after all + standard extensions. + +An example string following the order is: + rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux + -- 2.38.1
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org> To: Palmer Dabbelt <palmer@dabbelt.com>, linux-riscv@lists.infradead.org Cc: Conor Dooley <conor.dooley@microchip.com>, ajones@ventanamicro.com, aou@eecs.berkeley.edu, conor@kernel.org, corbet@lwn.net, guoren@kernel.org, heiko@sntech.de, paul.walmsley@sifive.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: [PATCH v1 3/3] Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo Date: Wed, 30 Nov 2022 23:41:26 +0000 [thread overview] Message-ID: <20221130234125.2722364-4-conor@kernel.org> (raw) In-Reply-To: <20221130234125.2722364-1-conor@kernel.org> From: Conor Dooley <conor.dooley@microchip.com> The RISC-V specs are permissive in what they allow as the ISA string, but how we output this to userspace in /proc/cpuinfo is quasi uAPI. Formalise this as part of the uAPI, by documenting the list of rules we use at this point in time. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> --- I've not "tested" these docs. The NIPA-esque pwbot should go and test it AFAICT. If it doesn't, I'll go add that. --- Documentation/riscv/uabi.rst | 42 ++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst index 21a82cfb6c4d..bc3c8ced644b 100644 --- a/Documentation/riscv/uabi.rst +++ b/Documentation/riscv/uabi.rst @@ -3,4 +3,46 @@ RISC-V Linux User ABI ===================== +Misaligned accesses +------------------- + Misaligned accesses are supported in userspace, but they may perform poorly. + +ISA string ordering in /proc/cpuinfo +------------------------------------ + +The canonical order of ISA extension names in the ISA string is defined in +chapter 27 of the unprivileged specification. +The specification uses vague wording, such as should, when it comes to +ordering, so for our purposes the following rules apply: + +#. Single-letter extensions come first, in "canonical order", so + "IMAFDQLCBKJTPVH". + +#. All multi-letter extensions will be separated from other multi-letter + extensions by an underscore. + +#. Additional standard extensions (starting with 'Z') will be sorted after + single-letter extensions and before any higher-privileged extensions. + +#. 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. + +#. Standard supervisor-level extensions (starting with 'S') will be listed + after standard unprivileged extensions. If multiple + supervisor-level extensions are listed, they will be ordered + alphabetically. + +#. Standard machine-level extensions (starting with 'Zxm') will be listed + after any lower-privileged, standard extensions. If multiple + machine-level extensions are listed, they will be ordered + alphabetically. + +#. Non-standard extensions (starts with 'X') will be listed after all + standard extensions. + +An example string following the order is: + rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux + -- 2.38.1 _______________________________________________ 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-30 23:42 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-30 23:41 [PATCH v1 0/3] Putting some basic order on isa extension lists Conor Dooley 2022-11-30 23:41 ` Conor Dooley 2022-11-30 23:41 ` [PATCH v1 1/3] RISC-V: clarify ISA string ordering rules in cpu.c Conor Dooley 2022-11-30 23:41 ` Conor Dooley 2022-12-01 8:27 ` Andrew Jones 2022-12-01 8:27 ` Andrew Jones 2022-12-01 8:48 ` Conor Dooley 2022-12-01 8:48 ` Conor Dooley 2022-11-30 23:41 ` [PATCH v1 2/3] RISC-V: resort all extensions in consistent orders Conor Dooley 2022-11-30 23:41 ` Conor Dooley 2022-12-01 9:00 ` Andrew Jones 2022-12-01 9:00 ` Andrew Jones 2022-12-01 10:47 ` Heiko Stübner 2022-12-01 10:47 ` Heiko Stübner 2022-12-01 11:38 ` Andrew Jones 2022-12-01 11:38 ` Andrew Jones 2022-12-01 12:29 ` Conor Dooley 2022-12-01 12:29 ` Conor Dooley 2022-12-01 12:37 ` Conor.Dooley 2022-12-01 12:37 ` Conor.Dooley 2022-12-01 10:48 ` Heiko Stübner 2022-12-01 10:48 ` Heiko Stübner 2022-11-30 23:41 ` Conor Dooley [this message] 2022-11-30 23:41 ` [PATCH v1 3/3] Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo Conor Dooley 2022-11-30 23:46 ` Conor Dooley 2022-11-30 23:46 ` Conor Dooley 2022-12-01 3:05 ` Bagas Sanjaya 2022-12-01 3:05 ` Bagas Sanjaya 2022-12-01 8:17 ` Conor Dooley 2022-12-01 8:17 ` Conor Dooley 2022-12-02 2:14 ` Bagas Sanjaya 2022-12-02 2:14 ` Bagas Sanjaya 2022-12-02 11:37 ` Conor Dooley 2022-12-02 11:37 ` Conor Dooley 2022-12-01 9:14 ` Andrew Jones 2022-12-01 9:14 ` Andrew Jones
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=20221130234125.2722364-4-conor@kernel.org \ --to=conor@kernel.org \ --cc=ajones@ventanamicro.com \ --cc=aou@eecs.berkeley.edu \ --cc=conor.dooley@microchip.com \ --cc=corbet@lwn.net \ --cc=guoren@kernel.org \ --cc=heiko@sntech.de \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ /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.