Fixed Point (Chapter 13): Clarification Request
CDS <cohen.steed@...>
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.
Fixed Point math, itself, is somewhat niche. It mostly sees use in legacy audio and mixed signal applications. If it needs to be a part of RISCV:


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).


CDS <cohen.steed@...>
Thank you for the response, Andrew.
Given that these operations are intended to be conveniences, in the first place (hence: vector), the addition of a required macro for inclusion could be considered a basic element. Fixed point is almost always going to be used in conjunction with other data formats, and the conversion, as you say, could be two instructions  or it could be one. The confusion my team and I are having with fixed point is not so much with the implementation, but the usecase. If we're going to have fixedpoint in RISCV, how about we look at how it's used and build that? Barring a (possibly necessary) overhaul, making the specification optional *entirely*  separating it out from the rest of vector, may be a compelling option.


Krste Asanovic
 Thank you for the response, Andrew.On Fri, 07 Aug 2020 14:48:34 0700, "CDS" <cohen.steed@...> said:  Given that these operations are intended to be conveniences, in the first place (hence: vector), the  addition of a required macro for inclusion could be considered a basic element. Fixed point is almost  always going to be used in conjunction with other data formats, and the conversion, as you say, could  be two instructions  or it could be one. I disagree with "almost always" unless you refer to mixing integer and fixedpoint. There are certainly many use cases with no floatingpoint.  The confusion my team and I are having with fixed point is not so much with the implementation, but the  usecase. If we're going to have fixedpoint in RISCV, how about we look at how it's used and build  that? Barring a (possibly necessary) overhaul, making the specification optional *entirely*   separating it out from the rest of vector, may be a compelling  option. Fixedpoint is widely used, and if anything, interest is growing in lowprecision fixedpoint. Fixedpoint codecs continue to be widespread also. I'm having trouble understanding your viewpoint here. Krste 


Perhaps, it is important to understand the history of why fixed point is utilized. Historically, fixed point was the alternative for expensive floating point implementations/operations, or was the easy option on top of an integeronly MCU. In today's chips, however, if floating point is available in a processing system, then floating point will be used over fixed point  sometimes because fixed point introduces a lot of signal processing challenges that are not present in floating point; perhaps because most, if not all, signal processing math is designed in, and for, floating point. Conversion to fixed point happens if no other choice is available or to support legacy code bases. With that said, we are not opposed to supporting fixed point. We are questioning having fixed point being mandatory. Fixed point support has a significant impact on compilers and tools (no native data type + no clear definition) and a significant impact on the usage/support model (fixed point ISA section is missing expected fixed point options).


swallach
perhaps i am not upto date on this topic. but addresses are fixed point. (integers). and you need vector support for vector loads using the vector accumulators.(indexs). the math, other than overflow is essentially the same i hope this makes sense On Aug 10, 2020, at 10:52 AM, CDS <cohen.steed@...> wrote:
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received. http://www.bsc.es/disclaimer


Nick Knight
Hi Coheen, Thanks for the discussion on the fixedpoint vector instructions. Most of Chapter 13 predates my involvement with the Task Group, but I think I am able to address one of your comments: On Mon, Aug 10, 2020 at 6:33 AM CDS <cohen.steed@...> wrote: There's no definition of what the fixed point spec is working on, other than the definition of an integer. Here's my proposed change to the preamble to Chapter 13: Nick Knight


CDS <cohen.steed@...>
Nick,
Thank you for your response and proposed clarification. This proposal for how to use the numbers fundamentally realigns our interpretation of how this would be used. This is much closer to the type of ADC work we've seen in the past, as opposed to do a hard "fixed point" format specification. I support the clarification. Perhaps we should see it included in the spec (merged). Thanks, Cohen


Allen Baum
I always understood fixpoint to have an implicit denominator that was restricted to a positive (integer) power of 2 (which could be fixed, or could be configured). Arbitrary denominators mean that multiply has to perform a subsequent divide after the operation, instead of a simple shift. I didn't think anyone was suggesting that.
On Mon, Aug 10, 2020 at 9:49 AM CDS <cohen.steed@...> wrote: Nick,


Mikael <mikael.mortensen@...>
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 integer. N=0 is basically a regular INT, and N>0 is a fixed point number.
If we accept this definition we can ask ourselves how 13.2 and 13.3 fit into our new definition. This as both are built on the assumption that N=1, which goes against our more openended definition.
Arguably, 13.3 is just short hand for a vmul followed by vnclip. Similarly, 13.2 is just short hand for vadd/vsub followed by vssra.
Utilizing this more crisp definition we can now semantically define fixed point math operations as:
#inner loop vmul of SEW*SEW > 2xSEW [N.(SEWN) > 2N.2(SEWN)] vssra of 2xSEW > 2xSEW >> needed guarding for the expected math operation vadd of guarded 2xSEW with guarded running sum vector #roll out vnclip of guarded running sum vector 2xSEW >> SEWguard bits+N to convert back to N.(SEWN) #or if we want to utilize a 2N.2(SEWN) double precision fixed point #note this construct is currently not feasible #vnclip_shift_left guarded 2xSEW << guard bits

