As it stands, the spec requires a specific result for every argument. There's no flexibility at all. Particularly since these are single-input instructions, there's opcode space to allow for more

As it stands, I think the spec prevents an implementer from being more accurate than described, right? Should the spec specify "accurate to at least 7 bits" instead? I could envision an embedded

On 8/13/20 2:33 PM, Andrew Waterman wrote: Happily, yes. :-) Sounds good. Bill

Hopefully because we've converged, not simply due to exhaustion :) Thanks. I'm going to merge the pull request now, but additional feedback is still welcome, of course.

I think maybe I'm done complaining. :-) Except that the initial paragraph on recip operation needs the words "concatenated and" removed. Bill On 8/13/20 2:11 PM, Andrew Waterman wrote:

Good thinking. I've added analogous language for recip, too.

Andrew, I'll start at the top here... and with rsqrt since it's simpler. I think the table and most of the commentary is fine. I can follow the operation description. Sort of. But I'm trying to

I had been hoping that the reference C code would scratch that itch, but you're probably right. I've added a tiny example and a huge example for each. My mistake. I was thinking of the fact that

On 8/12/20 7:05 PM, Andrew Waterman wrote: Probably so. That's probably OK. It's much less confusing. I wonder if two examples for each (recip and rsqrt) would help. One with a denormal input and

Yeah, but big is OK, I think. I didn't change the rsqrt table at all. Since the subnormal cases are mostly uninteresting, I think the NOTE that positive subnormal and normal inputs always produce

On 8/12/20 4:21 PM, Andrew Waterman wrote: It is pretty big... I'm just looking at the recip at this point. I have a couple of thoughts: In the "Output" column for the 5 new positive and negative

How about this... it's a beast, but I think it works. https://github.com/riscv/riscv-v-spec/blob/vfrecip/v-spec.adoc#149-vector-floating-point-reciprocal-estimate-instruction

On 8/12/20 3:32 PM, Andrew Waterman wrote: I almost suggested expanding the current table. That makes it quite a bit larger. But then, it also means there's no need to clarify the relationship

Yeah, let me play around with the presentation a bit. I'm not sure whether breaking it into two tables or expanding the current table will be clearer, but your suggestion holds either way. Thanks

On 8/11/20 4:11 PM, Andrew Waterman wrote: With that re-orientation to what the instruction means, it looks correct. I have a couple of comments: Just above the table you use the concept of the

Ah, that clarifies your earlier question. Yeah, LMK what you think.

On 8/11/20 3:00 PM, Andrew Waterman wrote: Ah, so you're counting the 7-bit (plus hidden bit) result as the absolutely correct answer. There's no relationship here to the infinite precision

As Cohen responded. The examples provided only work, as you rightly noted, if you have implied guard bits in the system. This is fine, with the caveat that the ISA definition doesn't provision for the

I like the new definition of fixed point. Its quite crisp. Building on the definition we can now argue that any integer number representation is: integer value/2^N With N being a positive

There are no cases where UF should be raised because there are no cases where denormalization causes loss of precision. When the result is subnormal, it is only subnormal by either one or two