RISC-V: V vs Z?inx

[Jan Beulich]

On 06.04.2026 23:07, Andrew Waterman wrote:
> On Sat, Apr 4, 2026 at 11:36 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 03.04.2026 01:01, Andrew Waterman wrote:
>>> There's a normative statement in the spec that V implies D, as you
>>> pointed out.
>>
>> Well, really I didn't. It was only later that I actually found that
>> statement (which I meant to clarify in a reply, when I saw you already
>> responded).
>>
>>>  The comment that the vector extension is compatible with
>>> Zfinx is non-normative, so although there's a contradiction, the
>>> former statement wins.
>>
>> Interesting.
>>
>>> We have a plan to rectify this situation in the future: eventually
>>> Zfinx will become its own base ISA, and in that new context, V will be
>>> redefined to imply Zdinx instead of D.  That will happen sometime this
>>> year.
>>
>> Is this going to be a good move? Wouldn't V better depend on F/D _or_
>> Z{f,d}inx? (Which effectively it is as per what's written today, just
>> not explicitly, and - as you put it - not normatively.)
> 
> To be clear, under this proposal, V would only be redefined in the
> context of the new Zfinx base ISAs, RV32LIFX and RV64LIFX.  So, for
> example, RV32LIFX_V would mean RV32I + Zfinx + Zdinx + V, whereas
> RV32IV would continue to mean RV32IFDV.  There are no
> backwards-incompatible changes.
> 
> (If you are interested, you can read the extended-base-ISAs proposal
> here: https://lists.riscv.org/g/tech-unprivileged/message/1134)

Ah yes, thanks for the link. This helps a lot in terms of context. In
particular, with Z?inx intended to be losing their "extension" status,
I now understand ...

>>>  For the time being, it makes the most sense to continue
>>> rejecting the V + Zfinx combination.
>>
>> Why would that be? Furthermore, some change is going to be needed anyway
>> in binutils, as otherwise with the planned change above, V would become
>> incompatible with F/D.
> 
> It's only that I don't think it's advisable for binutils to start
> accepting ISA combinations that contradict normative statements in the
> ISA manual.  I think we should wait until the proposal I mentioned is
> accepted, at which point the vector extensions chapter will also be
> revised to sanction the RV32LIFX_V.

... this. (Whether that move is a good one is a separate question,
which I see was brought up there.)

I have no idea how to comment there, yet there's one aspect that
particularly struck me as odd while reading: Krste said "We should have
been able to reuse D without needing Zdinx for example." If that was to
be possible, D would have to have provisions towards RV32's use of GPR
pairs. Same for Q then as to both RV32 and RV64. (Note how GNU binutils
know of Zqinx despite, afaict, there not being any official extension
like that.)

Jan