Re: VFRECIP/VFRSQRT instructions
On 2020-08-14 1:46 a.m., krste@... wrote:
As Andrew says, verification/compliance concerns outweighed allowing more flexible definition.
This is a policy decision ensuring reasonable limits on fragmentation in this space.
To be clear, this was a tactical decision to move forward with the proposal as presented.Also, the fixed 7b implementation was seen as being cheap to provide
The proposal has not been fully vetted.
Further research was and is encouraged.
Improvements on the algorithm are possible and will get consideration but will remain constrained by the above policy decision.
Specifically, Brian, if you have proposal(s) for a preferred algorithm that is equally cheap to provide and verify,
but provides equivalent or better worst case accuracy and provides equivalent or better distribution of error then
experience has demonstrated that this TG has been receptive to consider such improvements.
The greatest benefit that can possibly be achieved by providing this mailing list in-the-open is to garner active participation from the wider community that will contribute;
what might be for each individually a narrow area of interest/expertise, collectively provides a breadth of knowledge and insight that we as a TG do not possess.
To be clear, this is not a justification to limit due diligence of the current proposal.even if more accurate approximations are added later.
Rather it does make clear that iterative improvement is possible and not impeded by adopting this or similar tangible proposals.
Krste On Thu, 13 Aug 2020 17:37:01 -0700, "Andrew Waterman" <andrew@...> said:On Thu, 13 Aug 2020 17:37:01 -0700, "Andrew Waterman" <andrew@...> said: The task group did consider that possibility but concluded that forcing compatibility is more important. As Bill points out, more precise (or flexibly precise) variants can be defined in the future, since there's beaucoup opcode space available for unary operations. On Thu, Aug 13, 2020 at 4:55 PM Brian Grayson <brian.grayson@...> wrote: 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 implementer who would like just a few bits more accuracy and fewer (or none) Newton-Raphson iterations for their specific use-case. (I've seen architectures that state a minimum accuracy, but leave the actual accuracy up to the implementer, which is enough for standard software to do the right thing.) Brian
On Thu, 13 Aug 2020 17:37:01 -0700, "Andrew Waterman" <andrew@...> said: