I added vector length extensions to spec.
| Hello Guy,On Mon, 12 Jul 2021 14:31:07 +0000, "Bill Huffman" <huffman@...> said:
| 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.
| 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
| 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,