great! again this is meant as informational for when this goes to vote. this should be discussable now in email with questions and comments. please include this in the ratification materials (place in

I filled out the RISC-V Policy: Change and Extension Rationale as best I could for the issue #427. I believe it is accessible by all. But I will also paste the contents below.

RISC V needs CMOs, and hence a CMO Working Group EditNew Page

I posted a comment to the closed #427 Not everyone subscribes to GitHub, so I post it below, I am requesting this proposal be reconsidered/re-evaluated for V1.0 inclusion in

On 8/3/20 1:41 PM, Andrew Waterman wrote: I agree with your computation with a really tiny difference (I get that it just barely rounds to 2^-7.32040). I can't say why I got 37 when I did it 8-10

Thanks for validating against your table, Bill. With my value for that entry, the worst error on the interval of interest is 2^-7.32041, for input 0x3f1a0000. With yours, it's 2^-7.3164 for

The recip table matches mine as does the worst case error. I have one different entry in the square root table. For entry 77, where you have 36, I have 37. I'm not sure whether it matters. Also,

Now annotated version --detail https://github.com/David-Horner/recip/blob/master/vrecip.cc For the 7x7 below notice the biased value does not exceed 21 for recip (5 of 7 bits) and 15

I should have said that my results are for the 7/7 case. And it sounds like we're in agreement then. We probably have the same table. Bill On 8/2/20 9:50 AM, DSHORNER wrote:

This is the link to the revised code that does n by m LUT https://github.com/David-Horner/recip/blob/master/vrecip.cc On 2020-08-01 4:51 p.m., David Horner via

What I initially posted was a compilation from days previously, and I pulled in some bogus test results. Here is a fresh run : ./a.out 7 5 ;./a.out 7 6 ;./a.out 7 7 ;./a.out 7 8

David, Here are a series of statements leading to my worst case answer: For the mantissa range 0xF5_0000 to 0xF5_FFFF, the reciprocal estimate is 0x85_0000 The largest error is for 0xF5_0000 The

This is the program Andrew wrote. https://github.com/riscv/riscv-v-spec/blob/vfrecip/recip.cc On 2020-07-31 4:46 p.m., Bill Huffman wrote: That is correct,

David, Because of the errors you get, I'm assuming your "output width" and "input width" do not include the hidden bit. Right? It's interesting. I did a similar exercise a number of years ago and

The error is relative error. The calculation is unchanged from Andrew's original. (Although I explicitly force double even when it shouldn't matter). The test range is from 0.5 to 1 inclusive. Again I

David, Are the max errors absolute? Or relative to the recip or rsqrt, which is presumably in the range (1.0, 2.0]? That you use [0.5, 1] when you might have meant [0.5, 1) leaves some question

The current LUT generator assumes N-by-N look up table. I will load in my github Andrew's program modified to  take input (index size) and output (estimate number of bits) arguments.   (--verilog

Date: 2020/7/24 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~18 Current issues on github: https://github.com/riscv/riscv-v-spec Issues

To be clear, this is SEW/LMUL ratio change, correct? All other values being valid and the "SEW and LMUL" combination itself being valid. Providing an invalid SEW and LMUL combination will set vill

this is in the x0,x0 case? I see this as the only case that needs to be considered. The EE does not have to both set vill and establish a saved vl value in the same instruction. A sequence of vsetvl