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

|