Zve should be a strict subset of V, use new option to relax VLEN


Guy Lemieux
 

Hi,

The way 18.1 and 18.2 currently read in the V spec is a bit confusing.

It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor".

1) Processors vs Processor?

2) It appears the Zve extension relaxes VLEN rules which are not supported by V. This appears to be the only change that prevents Zve from being a strict subset of V.

3) I think Zve should be a strict subset of V.  The relaxation of VLEN should be an option that can be added to Zve or V. Some AP may wish to remain code-compatible with Zve, and this will make things more clear. This will clarify code generation and aid compatibility. Perhaps call this option Zvlen?

4) If there are other differences that I've missed in (3), they should be similarly separated.

Thank you,
Guy


Bill Huffman
 

Hello Guy,

 

It definitely would be good for Zve to be a strict subset of V.  I think that means the same thing as that any binary that runs on Zve will run correctly on Z.  But I’m not seeing how any code that runs on a Zve compliant core with VLEN < 128 will fail to run on V.  Do you have an example?  Is there a further relaxation that I’m not thinking about besides VLEN < 128?

 

Separately, I don’t think we can add an option that restricts.  All code that will run without an option should run with the option.  But I think V may be able to be a superset without that.

 

      Bill

 

From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Guy Lemieux
Sent: Monday, July 12, 2021 7:29 AM
To: tech-vector-ext@...
Subject: [RISC-V] [tech-vector-ext] Zve should be a strict subset of V, use new option to relax VLEN

 

EXTERNAL MAIL

Hi,

 

The way 18.1 and 18.2 currently read in the V spec is a bit confusing.

 

It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor".

 

1) Processors vs Processor?

 

2) It appears the Zve extension relaxes VLEN rules which are not supported by V. This appears to be the only change that prevents Zve from being a strict subset of V.

 

3) I think Zve should be a strict subset of V.  The relaxation of VLEN should be an option that can be added to Zve or V. Some AP may wish to remain code-compatible with Zve, and this will make things more clear. This will clarify code generation and aid compatibility. Perhaps call this option Zvlen?

 

4) If there are other differences that I've missed in (3), they should be similarly separated.

 

Thank you,

Guy


Krste Asanovic
 

I added vector length extensions to spec.

Please review,

Krste

On Mon, 12 Jul 2021 14:31:07 +0000, "Bill Huffman" <huffman@cadence.com> said:
| Hello Guy,
| It definitely would be good for Zve to be a strict subset of V. I think that means the same thing as that any binary that runs on Zve will run correctly on Z. But I’m not seeing how any code that
| runs on a Zve compliant core with VLEN < 128 will fail to run on V. Do you have an example? Is there a further relaxation that I’m not thinking about besides VLEN < 128?

| Separately, I don’t think we can add an option that restricts. All code that will run without an option should run with the option. But I think V may be able to be a superset without that.

| Bill

| From: tech-vector-ext@lists.riscv.org <tech-vector-ext@lists.riscv.org> On Behalf Of Guy Lemieux
| Sent: Monday, July 12, 2021 7:29 AM
| To: tech-vector-ext@lists.riscv.org
| Subject: [RISC-V] [tech-vector-ext] Zve should be a strict subset of V, use new option to relax VLEN

| EXTERNAL MAIL

| Hi,

| The way 18.1 and 18.2 currently read in the V spec is a bit confusing.

| It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor".

| 1) Processors vs Processor?

| 2) It appears the Zve extension relaxes VLEN rules which are not supported by V. This appears to be the only change that prevents Zve from being a strict subset of V.

| 3) I think Zve should be a strict subset of V. The relaxation of VLEN should be an option that can be added to Zve or V. Some AP may wish to remain code-compatible with Zve, and this will make
| things more clear. This will clarify code generation and aid compatibility. Perhaps call this option Zvlen?

| 4) If there are other differences that I've missed in (3), they should be similarly separated.

| Thank you,

| Guy

|


Bill Huffman
 

Hi Krste,

The descriptions of Zvl* look good. A couple of comments:

* The V description says vector length greater than or equal to 128. Should it instead refer to Zvl128b?

* I wonder if there could be a table for what Zve* and V include in instructions with both YES and NO on appropriate lines of the table for what each extension must include. The statements, understandably, include what instructions are supported. But I have trouble with the process-of-elimination to see what's not included as well as with the comparison of Zve to V.

Bill

-----Original Message-----
From: tech-vector-ext@lists.riscv.org <tech-vector-ext@lists.riscv.org> On Behalf Of Krste Asanovic
Sent: Thursday, July 15, 2021 3:03 AM
To: Bill Huffman <huffman@cadence.com>
Cc: Guy Lemieux <guy.lemieux@gmail.com>; tech-vector-ext@lists.riscv.org
Subject: Re: [RISC-V] [tech-vector-ext] Zve should be a strict subset of V, use new option to relax VLEN

EXTERNAL MAIL



I added vector length extensions to spec.

Please review,

Krste

On Mon, 12 Jul 2021 14:31:07 +0000, "Bill Huffman" <huffman@cadence.com> said:
| Hello Guy,
| It definitely would be good for Zve to be a strict subset of V. I
| think that means the same thing as that any binary that runs on Zve will run correctly on Z. But I’m not seeing how any code that runs on a Zve compliant core with VLEN < 128 will fail to run on V. Do you have an example? Is there a further relaxation that I’m not thinking about besides VLEN < 128?

| Separately, I don’t think we can add an option that restricts. All code that will run without an option should run with the option. But I think V may be able to be a superset without that.

| Bill

| From: tech-vector-ext@lists.riscv.org
| <tech-vector-ext@lists.riscv.org> On Behalf Of Guy Lemieux
| Sent: Monday, July 12, 2021 7:29 AM
| To: tech-vector-ext@lists.riscv.org
| Subject: [RISC-V] [tech-vector-ext] Zve should be a strict subset of
| V, use new option to relax VLEN

| EXTERNAL MAIL

| Hi,

| The way 18.1 and 18.2 currently read in the V spec is a bit confusing.

| It defines Zve as "Vector extensions for Embedded Processors", and V as a "Vector Extension for Application Processor".

| 1) Processors vs Processor?

| 2) It appears the Zve extension relaxes VLEN rules which are not supported by V. This appears to be the only change that prevents Zve from being a strict subset of V.

| 3) I think Zve should be a strict subset of V. The relaxation of VLEN
| should be an option that can be added to Zve or V. Some AP may wish to remain code-compatible with Zve, and this will make things more clear. This will clarify code generation and aid compatibility. Perhaps call this option Zvlen?

| 4) If there are other differences that I've missed in (3), they should be similarly separated.

| Thank you,

| Guy

|


ghost
 

* I wonder if there could be a table for what Zve* and V include in instructions with both YES and NO on appropriate lines of the table for what each extension must include. The statements, understandably, include what instructions are supported. But I have trouble with the process-of-elimination to see what's not included as well as with the comparison of Zve to V.
FYI, I'm working with Elisa Sawyer and others on a style and content guide for extension proposals, mostly based on the excellent bitmanip v1.0.0-rc1 draft. That draft includes a table like the one you're suggesting, and I'm advocating putting that in the guide as a recommendation.

--

L Peter Deutsch <ghost@major2nd.com> :: Aladdin Enterprises :: Healdsburg, CA

Was your vote really counted? http://www.verifiedvoting.org