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


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@... <tech-vector-ext@...> On Behalf Of Krste Asanovic
Sent: Thursday, July 15, 2021 3:03 AM
To: Bill Huffman <huffman@...>
Cc: Guy Lemieux <guy.lemieux@...>; tech-vector-ext@...
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@...> 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@...
| <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

|

Join tech-vector-ext@lists.riscv.org to automatically receive all group messages.