I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example).

Who is the consumer of that identifier? Is this a value you would expect to be encoded in the config-struct of on-line discovery?

I am building a list of all architectural options that aren't controlled by CSR fields, for what it is worth, 

as well as all the named option value ranges, regardless of whether they're controlled by a CSR value or not.

The intent of this is to be able to configure the Sail model to implement the behavior they control.

On Fri, Jul 8, 2022 at 1:30 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> 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