Hi Krste,

At the summit, you mentioned that the V opcode space would be extended by using P opcodes since an implementation would not have both P and V. Andes vector cores do have the P extension and we would need the ability to determine in a multitasking scenario, which unit was in use by a thread. Is there one CSR that has this information in it?

-rich

We generally want to avoid using CSRs for runtime discovery, instead
preferring a user-accessible data structure provided by the runtime
system. Under Linux, there is a user API to figure out the current
hart's capabilities. Other execution environments could adopt a
similar approach to provide the same information to user tasks.

At the M-mode level, the misa CSR has a bit for the V extension, and
assuming P moves forward as a single-letter extension, that could also
be allocated in the misa CSR. However, the misa.V bit only indicates
presence of the base V extension, not of any further Zv* extensions
that would overlap P opcodes. Similarly, the misa.P bit would only
indicate the existence of the base P extension, not any further Zp*
extensions.

The proposed base P and ratified base V extensions do not conflict, so
assuming P moves forward as currently proposed, both misa.V and misa.P
could be set in the misa.CSR. If a hart has further Zv* extensions
that conflict with P, then misa.P would not be set. Similarly, if a
hart had further Zp* extensions that conflicted with V, then misa.V
would not be set. If a single hart implementation wanted to support
multiple alternative extensions that conflicted in instruction
encoding then the *envcfg registers should be used.

Work continues on more general platform-level discovery mechanisms
that can capture a greater variety of extensions.

Krste

On Fri, 23 Dec 2022 00:15:02 -0800, "Andrew Waterman" <andrew@...> said:

| On Fri, Dec 23, 2022 at 12:06 AM Allen Baum <allen.baum@...>
| wrote:

| I actually interpreted Krste's statement differently. Not
| necessarily correctly.
| It sounded to me like there wasn't enough room in the current vector
| encoding space to fit possible extensions, 
| so the thought was to *extend* into the P encoding space, e.g. any unused
| opcodes under the P-extension major opcode.

| Given what I know about the number of P-extension opcode (from memory),
| the number of unused opcodes might be pretty tiny though., 
| That makes it less likely my interpretation would be correct.

| Yeah, Rich's interpretation was right; see 
| https://lists.riscv.org/g/tech-crypto-ext/message/856

| On Thu, Dec 22, 2022 at 8:56 PM Rich Fuhler <rfuhler@...> wrote:

| Thanks much, Andrew. Makes perfect sense.

| -rich

| -------- Original message --------
| From: Andrew Waterman <andrew@...>
| Date: 12/22/22 7:25 PM (GMT-08:00)
| To: Rich Fuhler <rfuhler@...>
| Cc: tech-vector-ext@...
| Subject: Re: [RISC-V] [tech-vector-ext] Overlapping P and V opcodes

| Hey Rich,

| Although I'm not Krste, I'll inject my two cents.  I think there are
| two separate issues here:

| - The immediate one.  Formally at RVIA, the P extension is a proposal,
| not yet a standard.  So, vendors who have implemented the proposal are
| effectively implementing what the spec refers to as a non-conforming
| extension (because it uses standard encoding space despite not being a
| standard).  This is a perfectly legitimate thing to do.  Assuming Zvk*
| is standardized as proposed, then the usual technique for resolving
| conflicts between a standard extension and a non-conforming extension
| applies: a custom mode bit (specified by the vendor) can be used to
| enable the non-conforming extension.  When the custom mode bit enables
| the non-conforming extension, the processor does not implement Zvk*. 
| At the opposite polarity, the processor might implement Zvk*.

| - The longer-term one.  When P (or more likely Zp*) is standardized,
| RVIA could choose to define analogous mode bits (e.g., as part of the
| *envcfg CSRs).  This would make sense to do as part of the
| standardization of Zp*, rather than as a preemptive measure, because
| we don't yet know with certainty which opcodes Zp* will use.

| HTH,
| Andrew

| On Thu, Dec 22, 2022 at 4:36 PM Rich Fuhler <rfuhler@...>
| wrote:

| Hi Krste,

| At the summit, you mentioned that the V opcode space would be
| extended by using P opcodes since an implementation would not have
| both P and V. Andes vector cores do have the P extension and we
| would need the ability to determine in a multitasking scenario,
| which unit was in use by a thread. Is there one CSR that has this
| information in it?

| -rich

|

also please note the unified discovery effort is underway. i am adding in philipp and aaron to the chain.

Mark

--------
sent from a mobile device. please forgive any typos.