Re: Zve should be a strict subset of V, use new option to relax VLEN
|
Bill Huffman
Hi Krste,
toggle quoted message
Show quoted text
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 | 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. | 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 | |
|
|