Re: Zve should be a strict subset of V, use new option to relax VLEN
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
Subject: [RISC-V] [tech-vector-ext] Zve should be a strict subset of V, use new option to relax VLEN
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.