RISC-V: V vs Z?inx

[Andrew Waterman]

On Tue, Apr 7, 2026 at 1:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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.)

Glad we're on the same page now.

Krste's comment was only about reusing the name "D"; as you point out,
there would be non-trivial semantic differences between e.g. the D in
RV32LIFX_D and the D in RV32ID.  If any other suggestions come to
mind, feel free to let me know privately and I'll pass them along.

>
> Jan