Date
1 - 5 of 5
Zve should be a strict subset of V, use new option to relax VLEN
|
ghost
* 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.FYI, I'm working with Elisa Sawyer and others on a style and content guide for extension proposals, mostly based on the excellent bitmanip v1.0.0-rc1 draft. That draft includes a table like the one you're suggesting, and I'm advocating putting that in the guide as a recommendation. -- L Peter Deutsch <ghost@...> :: Aladdin Enterprises :: Healdsburg, CA Was your vote really counted? http://www.verifiedvoting.org |
|
|
|
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 | |
|
|
|
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 | |
|
|
|
Bill Huffman
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 |
|
|
|
Guy Lemieux
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 |
|
|