add 09/25 ad hoc meeting notes on TG requirements for single/multiple…

… CX selections and multiple opcode subranges

meetings/2024-09-25-minutes.md

@@ -0,0 +1,155 @@
+# Meeting Minutes 2024-09-25
+
+- CX TG Requirements Ad-Hoc Meeting: Single or Multiple Simultaneous CX selections, Custom Subranges
+
+- Attendees
+
+  Darius Rad (Bluespec)
+  Jan Gray (Individual)
+  Guy Lemieux (Individual)
+  Anton Kuzmin (Individual)
+  David Weaver (Akeana)
+  Rich Fuhler (Andes)
+
+- Discussion
+
+Jan presented a summary of the issue and past mailing list discussions,
+posted to
+https://lists.riscv.org/g/tech-composable-custom-extensions/message/242
+and included below. General concurrence with this summary. Guy noted
+potential impact of someday transition to 64b opcodes.
+
+Jan recommended single selection per hart, but was open to a forward
+compatibility requirement to support multi-selection in some future
+standard, without resort to breaking changes.
+
+Some felt the need for the additional complexity of multi-selection is
+not yet demonstrated. There followed extensive discussion of a likely
+scenario involving legacy custom instructions tightly interleaved (in
+a hot code path) with a composable extension's custom instructions.
+
+The single-selection and basis spec design handles this correctly
+but requires repeatedly selecting back and forth between the legacy
+custom extension(s) and the composable custom extension (incurring
+additional CSR writes and possible CPU pipeline disruptions).
+
+With multi-selection, software might select a custom opcode segment for its
+CX use that does not conflict with ts legacy custom instructions' opcodes,
+eliminating the need for many CX selector CSR writes in the hot code.
+
+Note, however, this scenario does not occur in portable (CPU agnostic)
+CX software that never issues CPU-specific legacy custom instructions,
+only CX custom instructions. Proposed terminology:
+
+* CX software: independently authored & versioned software that discovers,
+  selects, and issues custom instructions of a CX.
+
+* Agile CX software: CX software that includes no CPU-specific legacy
+  custom instructions. Works on any CX framework compatible CPU.
+
+* CPU-specific CX software: CX software that includes CPU-specific
+  legacy custom instructions. Might fail on a CPU that lacks these
+  legacy custom instructions.
+
+The TG's anticipated catalog of mix-and-match reusable CXs and CX software
+consists of agile CX software binaries. But less-reusable CPU-specific
+CX software will also be commonplace within an organization or market
+segment, composing CX(s) with software optimized for specific CPU(s) and
+their legacy custom extension(s).
+
+Guy proposed an alternative to multi-selection to support the interleaved
+legacy + CX instructions scenario: a CSR with one bit per custom spaces
+segment, to determine which custom opcodes segments are subject to CX
+multiplexing vs. which always specify built-in legacy custom instructions.
+Darius noted this could disincentivize promulgation of CXs.
+
+We also realized that whether the TG requires support for one, or
+multiple, simultaneous CX selections, the TG must also separately decide
+whether to subject all, or just a subset, of the custom opcode and CSR
+ranges to CX multiplexing.
+
+We discussed the TG survey extant custom extensions across the RISC-V
+ecosystem, to collect the general ranges of custom opcodes used and the
+total number of unique custom opcodes used per system.
+
+We decided to continue to study whether the interleaved legacy + CX
+instructions scenario requires more than one selection (as in the basis
+spec), and therefore tabled the decision to to include or exclude the
+multiple subranges requirement.
+
+---
+
+Subject requirements:
+
+* *[discuss] Allow splitting the opcode space into more manageable portions.*
+* *[discuss] Support, or allow logical enhancement for, multiple opcode spaces.*
+
+Issues summary
+
+1. CX multiplexing enables composition of multiple CXs and their CX
+   software binaries in a system.
+
+2. CX will add unpriv CSR(s) written by software to select the hart’s
+   current CX(s) to perform subsequent custom instructions & CSRs.
+
+3. In basis spec, N=1 CSR, one current selection, applies to all custom
+   instructions & CSRs.
+
+4. [discuss] N>1 CSRs, N current selections, each applies to a segment
+   of 1/N of custom instructions & CSRs.
+
+5. Many CXs will not use or require the full complement of custom
+   instructions & CSRs.
+
+6. If N>1, a CX’s custom instructions/CSRs opcodes/indices can be
+   segment-agile. In effect each CX custom instruction can be accessed by
+   an opcode/index from each of the N segments.
+
+7. Within one CX software binary (**) compiled instructions that use
+   any specific CX will be hard coded to a specific segment and specific
+   opcodes/indices.
+
+8. Advantages of N=1: minimal, essential, simple, frugal
+
+9. Advantages of N>1: multiple selections enables fewer CSR writes when
+   using several CXs (incl. legacy custom extensions) in a hot code path.
+
+10. Both alternatives require CSR writes when calling across CX software binaries.
+
+11. Issue is conjoined with CX ABI requirements and design.
+
+12. Calls across CX software binaries require at least M<=N CSR writes
+    to establish the M CX selections required by the called binary.
+
+13. Calls within a CX software binary that uses M>1 CXs may see fewer
+    dynamic CSR writes to switch back and forth amongst CXs.
+
+14. Unclear how often the inessential additional complexity of N>1
+    will provide value: how often will a single CX software binary rapidly
+    multiplex among >1 CX?
+
+15. An important use case is rapid reuse of 1 CX and the CPU’s legacy
+    custom extensions. Consider the case where a CPU’s compiler injects
+    legacy custom instructions and we must interleave those that with the
+    CX’s custom instructions. We need to have a good story for this. One
+    approach is to disable compiler synthesis of legacy custom instructions
+    in CX software functions, but this seems undesirable and potentially
+    hard to build.
+
+16. TG charter mandates forward compatibility considerations / planning
+    for future versions. Here, the TG will decide how much, or all, of custom
+    opcode and CSR spaces to make subject to CX multiplexing. Providing a
+    subset now, e.g. custom-0 or custom-1 only, can be revised in a future
+    CX major revision to providing the entire range, but not vice-versa.
+
+17. Guy noted (Jan's restatement:) in an organization that controls
+    1) CX A, 2) CX B, and 3) a CX software binary that uses CXs A and B,
+    the organization could define a new CX AB = A (union) B, and use that,
+    with a single selector, in their CX software binaries. This is true,
+    and if this were common it could reduce the value proposition of multiple
+    selections/subranges. However, this TG is chartered to make independently
+    authored CXs and CX software binaries compose well, so it’s a bit of
+    a red herring.
+
+18. Custom-2/3 are not available for RV128 systems.
+