Merge pull request #469 from jrtc27/reserve-standard-encodings

Document reserving standard encodings

Author: kito-cheng

introduction.adoc

@@ -61,4 +61,12 @@ This specification uses the following terms and abbreviations:
 NOTE: ABI for big-endian is *NOT* included in this specification, we intend to
 define that in future version of this specification.
 
+Any encodings that are marked as reserved for a specific extension (ISA or
+purely ABI addition) should be treated by standard tools identically to any
+other encodings reserved for future standard extensions. Such reservations are
+solely declarations of intent to reduce conflicts between in-flight standard
+extensions, and may be reclaimed for future reassignment at any point for any
+reason. Any encodings marked as reserved have draft, not ratified, status,
+regardless of whether they are reserved for a ratified ISA extension.
+
 :sectnums:

policy.md

@@ -51,6 +51,27 @@ Each type of modification has a different policy, based on the following rules:
     needed for reviews, but in case you want to reach out yourself you can find
     an incomplete list from [RISC-V International's wiki page].
 
+# Reserving Encodings
+
+- Relocations within the standard encoding space, or program header types etc.,
+  may be reserved for in-development standard extensions
+  - Such extensions must be under development by an existing TG and be well on
+    the way to ratification (such as, but not strictly required, be in the
+    stable state)
+  - A proof-of-concept toolchain ideally should exist
+  - A specification for the ABI additions ideally should exist
+  - The nature of extensions can vary, and so the policy here is intentionally
+    vague and incomplete; each request will be evaluated on a case-by-case
+    basis by the psABI community
+- Encoding reservations are voluntary and non-binding; whilst the psABI
+  community intends to honour reasonable requests, it reserves the right to stop
+  reserving such encodings for any reason, including in the following
+  non-exhaustive list of cases:
+  - If an extension is abandoned instead of proceeding to ratification, its
+    reserved encodings will be reclaimed
+  - If an extension is ratified but does not end up requiring all of its
+    reserved encodings, its unused encodings will be reclaimed
+
 [@kito-cheng]: https://github.com/kito-cheng
 [@jrtc27]: https://github.com/jrtc27
 [RISC-V International's wiki page]: https://wiki.riscv.org/display/TECH/Toolchain+Projects