2025-03-14 Ordinary Meeting Notes

Date

Mar 14, 2025

Name	Affiliation

Instructions are essentially transformation of architectural state
What state should composable custom extensions have access to?
Types of state
- Hart state (x/f/d/v registers, CSRs, PC)
  - User mode only, other privilege modes
- Memory
  - Idempotent, non-idempotent
- Composable custom extension state
  - Hart state, or not
  - Idempotent, non-idempotent
  - Other extensions on same hart?
  - Other extensions on other harts?
Each type of state requires definition of behavior with respect to ordering, consistency, exceptions
- RVWMO only gives us so much
- Vector specification can be used as template for simple loads and stores

Darius presented a summary and categorization of various types of architectural state being discussed in the context of the composability criteria.
Jan expressed the desire to support composable custom extensions that have state that is not visible in the sense of having documented meaning for every state element, but is nonetheless capable of being saved, restored, and impacting computation. He provided an example of an extension that computes a running average.
Darius stated that his interpretation of visible state is consistent with the type of extensions that Jan would like to support; visibility of state means that it impacts functional behavior, not that the state elements are fully documented for arbitrary use.
Guy expressed concern that allowing extensions to use state from other extensions, or overlapping state (such as with F and D) would be problematic to track necessary dependencies in order for proper operating system state save and restore.