Topics

Zfinx and mutated extensions


Tariq Kurd
 

Hi everyone,

 

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

 

https://github.com/riscv/riscv-zfinx/issues/8

 

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

 

RV32IMCF_Zfinx

 

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

 

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

315px-Huawei    http://www.huawei.com

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 !

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

 


Allen Baum
 

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 lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

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

 

https://github.com/riscv/riscv-zfinx/issues/8

 

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

 

RV32IMCF_Zfinx

 

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

 

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

315px-Huawei    http://www.huawei.com

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 !

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

 


Allen Baum
 

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 lists.riscv.org <allen.baum=esperantotech.com@...> 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 lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

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

 

https://github.com/riscv/riscv-zfinx/issues/8

 

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

 

RV32IMCF_Zfinx

 

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

 

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

315px-Huawei    http://www.huawei.com

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 !

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

 


Tariq Kurd
 

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?

 

Tariq

 

 

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 lists.riscv.org <allen.baum=esperantotech.com@...> 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 lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

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

 

https://github.com/riscv/riscv-zfinx/issues/8

 

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

 

RV32IMCF_Zfinx

 

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

 

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

315px-Huawei    http://www.huawei.com

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 !

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

 


Tariq Kurd
 

Hi everyone,

 

I’ve made a big update to the Zfinx spec:

 

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

 

Please review it – it affects all floating point extensions.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Tariq Kurd via lists.riscv.org
Sent: 16 February 2021 17:39
To: Mark Himelstein <markhimelstein@...>
Cc: tech-unprivileged@...
Subject: FW: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions

 

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.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Tariq Kurd via lists.riscv.org
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?

 

Tariq

 

 

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 lists.riscv.org <allen.baum=esperantotech.com@...> 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 lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

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

 

https://github.com/riscv/riscv-zfinx/issues/8

 

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

 

RV32IMCF_Zfinx

 

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

 

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

315px-Huawei    http://www.huawei.com

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 !

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

 


Tariq Kurd
 

Unfortunately there’s still a problem with the Zfinx spec – there’s no discovery mechanism.

 

Previously it used a combination of misa.[FDQ] and a simple software sequence to show whether integer registers were changing state.

 

But now – Z[FDQ]inx are *not* the FDQ extensions, so we *can’t* set misa.[FDQ].

 

So we need another method to know whether Z[FDQ]inx are implemented.

 

How does the discovery mechanism for Zfh work? Maybe I can use the same mechanism.

 

Tariq

 

From: Tariq Kurd
Sent: 22 February 2021 12:36
To: tech-unprivileged@...; Tariq Kurd <tariq.kurd@...>; Mark Himelstein <markhimelstein@...>
Subject: RE: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions

 

Hi everyone,

 

I’ve made a big update to the Zfinx spec:

 

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

 

Please review it – it affects all floating point extensions.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Tariq Kurd via lists.riscv.org
Sent: 16 February 2021 17:39
To: Mark Himelstein <markhimelstein@...>
Cc: tech-unprivileged@...
Subject: FW: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions

 

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.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Tariq Kurd via lists.riscv.org
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?

 

Tariq

 

 

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 lists.riscv.org <allen.baum=esperantotech.com@...> 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 lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

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

 

https://github.com/riscv/riscv-zfinx/issues/8

 

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

 

RV32IMCF_Zfinx

 

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

 

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

315px-Huawei    http://www.huawei.com

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 !

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

 


mark
 

also Krste has mentioned migrating to CSRs for all discovery (unless I misunderstood). Can we define that and start using it for new extensions?

thanks
Mark

On Mon, Feb 22, 2021 at 12:04 PM Tariq Kurd <tariq.kurd@...> wrote:

Unfortunately there’s still a problem with the Zfinx spec – there’s no discovery mechanism.

 

Previously it used a combination of misa.[FDQ] and a simple software sequence to show whether integer registers were changing state.

 

But now – Z[FDQ]inx are *not* the FDQ extensions, so we *can’t* set misa.[FDQ].

 

So we need another method to know whether Z[FDQ]inx are implemented.

 

How does the discovery mechanism for Zfh work? Maybe I can use the same mechanism.

 

Tariq

 

From: Tariq Kurd
Sent: 22 February 2021 12:36
To: tech-unprivileged@...; Tariq Kurd <tariq.kurd@...>; Mark Himelstein <markhimelstein@...>
Subject: RE: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions

 

Hi everyone,

 

I’ve made a big update to the Zfinx spec:

 

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

 

Please review it – it affects all floating point extensions.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Tariq Kurd via lists.riscv.org
Sent: 16 February 2021 17:39
To: Mark Himelstein <markhimelstein@...>
Cc: tech-unprivileged@...
Subject: FW: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions

 

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.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Tariq Kurd via lists.riscv.org
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?

 

Tariq

 

 

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 lists.riscv.org <allen.baum=esperantotech.com@...> 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 lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

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

 

https://github.com/riscv/riscv-zfinx/issues/8

 

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

 

RV32IMCF_Zfinx

 

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

 

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

315px-Huawei    http://www.huawei.com

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 !

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

 


Allen Baum
 

Isn't that being defined by Ti Newsome's Config-Structure TG?
He's mostly working on the encoding issue, not the access method, and it is more of ROM structure, though certainly it could be accessed via a CSR  or pointed to by a CSR in MMIO address space..
That may be much more heavyweight than what Krste has in mind, as it is being designed to be self-describing, extensible, and capable of encompassing all architectural options, not just the ISA string.
I suspect you could encode only the ISA string and leave the rest out though.
I have conflicts with that TG meeting time now, so haven't been able to track more closely.



On Mon, Feb 22, 2021 at 12:09 PM mark <markhimelstein@...> wrote:
also Krste has mentioned migrating to CSRs for all discovery (unless I misunderstood). Can we define that and start using it for new extensions?

thanks
Mark

On Mon, Feb 22, 2021 at 12:04 PM Tariq Kurd <tariq.kurd@...> wrote:

Unfortunately there’s still a problem with the Zfinx spec – there’s no discovery mechanism.

 

Previously it used a combination of misa.[FDQ] and a simple software sequence to show whether integer registers were changing state.

 

But now – Z[FDQ]inx are *not* the FDQ extensions, so we *can’t* set misa.[FDQ].

 

So we need another method to know whether Z[FDQ]inx are implemented.

 

How does the discovery mechanism for Zfh work? Maybe I can use the same mechanism.

 

Tariq

 

From: Tariq Kurd
Sent: 22 February 2021 12:36
To: tech-unprivileged@...; Tariq Kurd <tariq.kurd@...>; Mark Himelstein <markhimelstein@...>
Subject: RE: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions

 

Hi everyone,

 

I’ve made a big update to the Zfinx spec:

 

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

 

Please review it – it affects all floating point extensions.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Tariq Kurd via lists.riscv.org
Sent: 16 February 2021 17:39
To: Mark Himelstein <markhimelstein@...>
Cc: tech-unprivileged@...
Subject: FW: [RISC-V] [tech-unprivileged] Zfinx and mutated extensions

 

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.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Tariq Kurd via lists.riscv.org
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?

 

Tariq

 

 

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 lists.riscv.org <allen.baum=esperantotech.com@...> 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 lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

Hi everyone,

 

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

 

https://github.com/riscv/riscv-zfinx/issues/8

 

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

 

RV32IMCF_Zfinx

 

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

 

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

315px-Huawei    http://www.huawei.com

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 !

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