FW: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions

Tariq Kurd

A recap for Mark:


We’ve had a complaint from an upstream LLVM developer about Zfinx, because it *changes* the F and D extension.

And it has the same effect on V, which also uses F registers (e.f. vfmv.f.s)


So the principle has been F / FD / V + Zfinx meaning something different to F / FD / V but it might be that we need to define different extensions for


Z[fdv]inx – if that’s the right naming so you choose

-          F or Zfinx.

-          D or Zdinx (which implies Zfinx also)

-          V or Zvinx (the naming scheme breaks down a bit here)


So it’s a fundamental question of how we define extensions.




From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Tariq Kurd via
Sent: 16 February 2021 12:04
To: tech-unprivileged@...; allen.baum@...
Subject: Re: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions


There are implications for the vector spec as well, e.g.


vfmv.f.s rd, vs2  # f[rd] = vs2[0] (rs1=0)

vfmv.s.f vd, rs1  # vd[0] = f[rs1] (vs2=0)

which access F registers, so Zfinx will affect the V spec too.


So do we need:

-          V and Zfinx specified separately

-          Zvinx – combines V and Zfinx extension, incompatible with V

-          Ban the combination?





From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Allen Baum
Sent: 15 February 2021 17:02
To: tech-unprivileged@...; Allen Baum <allen.baum@...>
Cc: Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions


Ah, and I just read the entire thread; I may not care, but upstream tools certainly do care.

We do need to watch out for any other extensions that expect to use FPRegs, then.


On Mon, Feb 15, 2021 at 8:57 AM Allen Baum via <> wrote:

I was trying to understand why this is an incompatibility, as opposed to a dependency (Zfinx depends on F).


What sets Zfinx apart is that it removes FPRegs, and some instructions (FLd/St/Mv).

In that sense, it is actually more like a different architecture (RV32noFPregI, RV32noFPregI) than an extension.

I know Krste has said in the past that extensions never remove a feature from another extension;  you would instead create a sub-extension that has only the remaining parts.

I'm not sure that quite works here, as it is far more than simply removing an instruction, it is also redefining existing instructions.


On the other hand: I don't feel so strongly about changing the ISA string because of that.

Currently the 4 combinations are.   F, FD, F_Zfinx, FD_Zfinx

The proposal would change that to F, FD,     Zfinx,      ZDinx.

I have no strong opinions about that.




On Mon, Feb 15, 2021 at 6:47 AM Tariq Kurd via <> wrote:

Hi everyone,


This started as a thread on the Zfinx mailing list but I think unpriv is a better place for it.


Basically Jessica is complaining that F and Zfinx are two different incompatible extensions.

At the moment the Zfinx spec allows the Zfinx specifier to modify F, all other extensions AFAIK are additive and compatible.


So it seems that instead of specifying




It would need to be RV32IMC_Zfinx – so the F and the Zfinx become one.


Then for RV32IMCD_Zfinx we would need


RV32IMC_Zdinx – where Zdinx also implies Zfinx, just as D also implies F.


My intention was for the Zfinx to be orthogonal to any/all FP extensions, but maybe that can’t be the case so we need a Zfinx / normal version of each.


What do you think?




Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Aztec West, Bristol, UK, BS32 4TR


This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!