Re: Fixed Point (Chapter 13): Clarification Request
Andrew Waterman
On Fri, Aug 7, 2020 at 8:49 AM CDS <cohen.steed@...> wrote: The definition of the numeric range (at the beginning of section 13) matches the definition of an integer, not of a fixedpoint number. For example, the range specified is the range of an integer, not a number of 1.X or 2.X format. This doesn't seem to be a fixedpoint specification in a manner consistent with other fixedpoint operations commercially available. As INTEGERONLY operations go, these are likely useful instructions. As a fixedpoint specification, this section seems to raise a lot of concerns. Having implemented these instructions recently, I can say they weren’t unduly onerous to provide, and the HW cost increase wasn’t that great (the rounding and clipping logic are new; the rest reuses the integer datapath). But it’s nonzero cost, so your point holds. I agree that fixedpoint could be broken out into a separate extension so that embedded vector units can exclude it for applications where integeronly or integerandfloatonly would suffice.
I think this can be done in two instructions without additional loss of precision: convert from int to float, then multiply by a floatingpoint scalar to move the binary point (or viceversa).

