| RVI_Disclosures_Female_Short.mp4 |
|
Composability Criteria and Architectural State Visibility
Open Discussion
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.