To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.

The combinatorics of taking every optional behavior, every parameter that can take on a set of possible values, and every WARL field and the allowed range of possibilities, and then creating an "extension" name for every individual possible "key- value" pair are crazy.  (This is why people instead use key-value representations.)

For Profiles, these names have been created on an as-needed basis for specific "key-value" pairs, and no further.  Their motivation was to simply have acronymic "extension" names for each of these line items.

In contrast, discovery schemes - like Device Tree, ACPI, and RISC-V Unified Discovery - want something distinctly different.  Namely standard "key" names for options, parameters, and WARL fields; standard names for the values of a "key"; and a schema for representing a set of key-value pairs.

Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

Lastly, I think everyone would agree that option / parameter / WARL field names, and their associated value names, are not "extensions".  And hence should not be mixed up with the "extension" names created and used in Profiles.  Any standardization of "key" names and "value" names should simply focus on usage in discovery schemes (i.e. DT, ACPI, UD).  This needs to support all possible key-value pairs.

As to whether all these acronymic line items or "key-value" pairs in Profiles are "extensions", there is probably contention, but I would at least say that these are not extensions in the usual sense.  And they should exist and arise solely in the context of Profiles (for the intended purpose of giving an extension-like acronymic name to each line item).

In short, I would suggest that it is probably best to keep discussion of these two topics separate. 

Greg

On Fri, Jul 8, 2022, 1:30 PM Allen Baum <allen.baum@...> wrote:

If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.

They are names for the values of architectural options of extensions that already exist

 (which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented). 

So these are constraints on the spec'ed options that are required to run SW on the platform.

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:

Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?

2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?

3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

On Fri, Jul 8, 2022 at 3:25 PM Greg Favor <gfavor@...> wrote:

To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.

Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you named it. If we're going down that road, it would be good to have things consistent. 

 If we're going to not call them extensions, I suggest coining something we can use more accurately then. I don't have any great ideas atm.

On Mon, Jul 11, 2022 at 11:02 AM Aaron Durbin <adurbin@...> wrote:

On Fri, Jul 8, 2022 at 3:25 PM Greg Favor <gfavor@...> wrote:

To add on to Alan's point.  These "extension" names were created simply to represent individual line items in the Profiles.  In many cases these represent a one or two sentence statement in a Profile about an optional behavior or about a specific parameter value.

Any effort to standardize key names and value names across discovery schemes should be kept separate from the acronymic naming in Profiles of specific line items (aka specific key-value pairs).

It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you named it. If we're going down that road, it would be good to have things consistent. 

What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

 

 If we're going to not call them extensions, I suggest coining something we can use more accurately then. I don't have any great ideas atm.

As Alan mentioned, him and I threw around names like "profentions" (aka profile extensions), although more out of amusement than practical value.

Practically speaking they should have a reasonably self-descriptive (yet short-ish) name.  Maybe simply "mandate names"?  This also avoids any confusion with extension names and with K and V names that would be used in discovery structures.  This also covers mandate items that are one sentence behavioral descriptions (of either a behavioral allowance or disallowance).

Greg

On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:

What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification. 

On Mon, Jul 11, 2022 at 11:28 AM Aaron Durbin <adurbin@...> wrote:

On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:

What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification. 

But the problem is that a profile is just putting an extension-style name (e.g. Zi* or Ss*) to a specific combination of an option or parameter, and a specific value for that option or parameter.  Whereas in discovery structures one would choose at least somewhat descriptive intuitive names for options and parameters, and would use booleans, integers, enums, etc. - as appropriate - to specify values for the options and parameters.  The latter would be clean and clear and readily captured by a schema.

Instead using a very large number of terse extension-style names that cover the combinatorial namespace of all allowed K-V pairs, let alone needing to define a universal naming scheme to follow across the entire architecture now and into the future, seems to result in less comprehensible discovery info and will push out even farther into the future having all this worked out.  Whereas developing simple conventions for naming of options and parameters, and for specifying allowed values, and then having each TG that is developing an extension define the specific names (and allowed values) for the options and parameters of the extension, is relatively straightforward and scalable.  This is part of what tech-config was trying to enable.  (For past extensions, there of course is remedial work to be done, but the idea remains.)

In short we need to divide-and-conquer the overall issue and not pile everything into one big ball of yarn.  And let's focus on supporting UD/DT/ACPI discovery methods.  Practically speaking, let's leave the relatively very limited naming in profiles of line item mandates, to the profiles.  Let these be two different and only superficially related problems.   (Ok, I'll step off my soapbox now.)

Greg