The definition  of the numeric range (at the beginning of section 13) matches the definition of an integer, not of a fixed-point 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 fixed-point specification in a manner consistent with other fixed-point operations commercially available. As INTEGER-ONLY operations go, these are likely useful instructions. As a fixed-point 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 RISC-V:

• Could it be a sub-spec, or an optional consideration? The implementation requirements to support these are non-trivial and seem to target a small use-case demand.
• Specify a 1.X format (or some fixed, deterministic point position). The current specification has no definition of a fixed point number format. The number format is implied, as a side effect in some instructions.
• There is a need for a fixed<->float conversion instruction (as used in signal processing applications on mixed fixed/float processing systems, or for conversion of data from e.g. ADCs/DACs).

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 use-case. If we're going to have fixed-point in RISC-V, 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.

On Fri, 07 Aug 2020 14:48:34 -0700, "CDS" <cohen.steed@...> said:

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

I disagree with "almost always" unless you refer to mixing integer and
fixed-point. There are certainly many use cases with no
floating-point.

| The confusion my team and I are having with fixed point is not so much with the implementation, but the
| use-case. If we're going to have fixed-point in RISC-V, 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.

Fixed-point is widely used, and if anything, interest is growing in
low-precision fixed-point. Fixed-point 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 integer-only 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.

Consider:
1. For the vector extension, floating point is mandatory. This could lead to the utilization of fixed point math being low. In this case, it will likely involve conversion in and out of floating point before doing the actual math.

2. Fixed point may be used more frequently if there is a significant benefit over floating point:
- legacy code is less of an issue on our architecture because it's new;
- power/performance - but we're already paying the price for area with floating point!

For the current vector extension definition that would, maybe, be for the 1.7 FP or 8-bit fixed point, where there could be a performance benefit depending on the factual implementation of the vector engine for a given RISCV core.

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

Hence the suggestion for making it optional, and working through some of the use-cases for fixed point to ensure that the fixed point ISA definition is "usable" by the intended target audience/users.

Internally we've worked through a few simple examples, like IIR and FIR filters, and it quickly becomes apparent that when using 1.(SEW-1) [industry standard definition] as a fixed point definition it quickly because "unmanageable" in terms of managing decimal points, overflows and mixed precision. "Unmanageable" here should be read as: requires a lot of additional checks around all math operations to ensure we don’t overflow or mix decimal points.



[Edited Message Follows]

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 integer-only 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.

Consider:
1. For the vector extension, floating point is mandatory. This could lead to the utilization of fixed point math being low. In this case, it will likely involve conversion in and out of floating point before doing the actual math.

2. Fixed point may be used more frequently if there is a significant benefit over floating point:
- legacy code is less of an issue on our architecture because it's new;
- power/performance - but we're already paying the price for area with floating point!

For the current vector extension definition that would, maybe, be for the 1.7 FP or 8-bit fixed point, where there could be a performance benefit depending on the factual implementation of the vector engine for a given RISCV core.

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

Hence the suggestion for making it optional, and working through some of the use-cases for fixed point to ensure that the fixed point ISA definition is "usable" by the intended target audience/users.

Internally we've worked through a few simple examples, like IIR and FIR filters, and it quickly becomes apparent that when using 1.(SEW-1) [industry standard definition] as a fixed point definition it quickly because "unmanageable" in terms of managing decimal points, overflows and mixed precision. "Unmanageable" here should be read as: requires a lot of additional checks around all math operations to ensure we don’t overflow or mix decimal points.

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,

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

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 open-ended 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.(SEW-N) -> 2N.2(SEW-N)]

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 >> SEW-guard bits+N to convert back to N.(SEW-N)

#or if we want to utilize a 2N.2(SEW-N) double precision fixed point

#note this construct is currently not feasible

#vnclip_shift_left guarded 2xSEW << guard bits