Re: [PATCH v3 3/6] target/riscv: add remaining named features

[Andrew Jones <ajones@ventanamicro.com>]

On Thu, Feb 15, 2024 at 11:13:51AM -0300, Daniel Henrique Barboza wrote:
...
> > I want to raise my frustration with the crock we've been given here by
> > RVI. Any "named feature" that just creates a name for something that
> > already is assumed is completely useless, and DT property that is used
> > to communicate it's presence cannot be used - instead the property needs
> > to be inverted - indicating the absence of that named feature.
> 
> Let's say that I'm not the biggest fan of how these profile extensions are being
> dealt with in the spec :) the text is vague w.r.t whether zicclsm and others
> are actual extensions, or a 'named feature'( like we're calling here in QEMU)
>

The text is vague, I certainly didn't get it at first, but it's been
clarified that these "named features" are considered extensions with
the given names and those extensions are ratified at the time the profile
in which they first appear is ratified. As I said in my other reply, I
hope the need to name old features is behind us now that the first
profiles are done.

> that is just a glorified way of saying, for example, "zic64b" instead of "all
> cache blocks have 64 bytes".

The note that accompanies "Zic64b" also states that the cache blocks may
be larger or smaller than 64 bytes. So, when a platform includes this
"Zic64b" extension in its DT it doesn't mean all blocks are 64 bytes, it
means they're all compatible with 64 bytes by either using 64-byte sub-
blocks (when they're bigger) or by sequencing cache ops across multiple
blocks (when they're smaller). So, while we can derive 'zic64b' from a
platform which does have all blocks of size 64, some platforms will need
to explicitly add it to the ISA string when they know they're compatible,
since they'll be putting other block sizes in the block size descriptions.

Thanks,
drew