Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

[Albin Stigö]

Yes, 32i and 16i is probably the best since it avoids a lot of
confusion regarding fixed point. It's very intuitive that a full range
int gets compressed to +-1.0.

Let's see if there's any real world performance gain though, but at
least it's nice and clean using dedicated hardware instructions and
avoids errors using an incorrect scalar.

On a side note I was blown away to see that armv8.3 has dedicated
instructions for complex arithmetic which could potentially give a
substantial performance gain... At least when arm takes over the
laptop market which I predict will happen in a few years.


--Albin

On Fri, May 31, 2019 at 11:52 AM Müller, Marcus (CEL) <address@hidden> wrote:
>
> Ah, I thought  (hurrhurr, a pun) in Q1.15: 15 bits of -0.252525 and
> +0.252525 are the same, just the sign bit flips. If it's really just an
> interpretation of integers: well, call it 16i
> On Fri, 2019-05-31 at 11:45 +0200, Albin Stigö wrote:
> > > two's complement being the standard way of
> > > dealing with numbers
> >
> > Signed numbers at least...
> >
> > Signed Q values are (at least in all cases I've seen) stored in two's
> > complement format. It's just like any other signed integer with an
> > implied comma.
> >
> > The Wikipedia article is fairly good:
> > https://en.wikipedia.org/wiki/Q_(number_format)
> >
> >
> > --Albin
> >
> > On Fri, May 31, 2019 at 11:40 AM Müller, Marcus (CEL) <address@hidden> 
> > wrote:
> > >
> > > Hm, wait, realizing something:
> > > Q1.31 differs from what a x86 CPU can reasonably deal with in that it's
> > > not 2's complement for negative numbers; since I'd guess the same
> > > situation applies to ARM (two's complement being the standard way of
> > > dealing with numbers), maybe we should just have one VOLK kernel /
> > > routine to be used within VOLK kernels
> > >
> > > volk_q1.31_convert_32i
> > >
> > > to get a number format that CPU instructions can actually deal with,
> > > and then implement the rest of fixed point arithmetic with that.
> > > Is that sensible?
> > >
> > > Best regards,
> > > Marcus
> > > On Fri, 2019-05-31 at 11:34 +0200, Albin Stigö wrote:
> > > > What about naming these functions... any ideas? Here are some
> > > > suggestions of the top of my head:
> > > >
> > > > volk_32i_convert_32f
> > > > volk_q1.32_convert_32f
> > > > volk_q1_32_convert_32f
> > > >
> > > >
> > > > --Albin
> > > >
> > > > On Fri, May 31, 2019 at 10:30 AM Albin Stigö <address@hidden> wrote:
> > > > >
> > > > > Thanks for the feedback Marcus!
> > > > >
> > > > > Pretty much all SDRs I've seen use either 8, 16 or 32 bit full range
> > > > > integers (or 24 bits packed in the most significant bits of a 32 bit
> > > > > int so can use same conversion as 32 bit).
> > > > >
> > > > > Yes Q1.15 means 1 sign bit and 15 fractional bits, in practice this
> > > > > just means that a full range int16_t will map to +-1.0. An N-tap FIR
> > > > > filter which has L-bit data values and M-bit coefficients requires L +
> > > > > M + log2(N) bits in the accumulator.
> > > > >
> > > > > A CIC decimator/interpolator might also be interesting, although I'm
> > > > > not sure if there's already an implementation.
> > > > >
> > > > >
> > > > > --Albin
> > > > >
> > > > > On Fri, May 31, 2019 at 10:13 AM Müller, Marcus (CEL) 
> > > > > <address@hidden> wrote:
> > > > > >
> > > > > > Hi Albin,
> > > > > >
> > > > > > I'd love this, especially if we end up with a kernel that we can 
> > > > > > use to
> > > > > > build decimating FIR filters that inherently convert to 
> > > > > > higher-bitwidth
> > > > > > int or floating point.
> > > > > >
> > > > > > I think this could be super useful in hardware flow graphs, where 
> > > > > > one
> > > > > > would get integer numbers from hardware anyway; in a low-SNR 
> > > > > > scenario
> > > > > > only processing gain (e.g. through filtering / correlation) would 
> > > > > > make
> > > > > > it sensible to use a larger integer or floating point's larger 
> > > > > > dynamic
> > > > > > range.
> > > > > >
> > > > > > Not quite sure how that would preferably look like, but I'd imagine
> > > > > > Q1.15 going in, getting weighted internally with Q1.15 (or Q1.31 
> > > > > > with
> > > > > > limited amplitude) coefficients to add Q1.31 numbers to a Q1.31
> > > > > > accumulator. (I'm assuming Q1.15 means 15 fractional binary digits 
> > > > > > and
> > > > > > one sign bit.)
> > > > > >
> > > > > > (Oh, and yes, x86_64 / SIMD extensions have relatively nice 
> > > > > > conversion
> > > > > > instructions.)
> > > > > >
> > > > > > Best regards,
> > > > > > Marcus
> > > > > >
> > > > > > On Fri, 2019-05-31 at 09:50 +0200, Albin Stigö wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Volk has functions for converting between int and float by 
> > > > > > > casting and
> > > > > > > multiplying with a scalar. I'd like to purpose functions for the
> > > > > > > special case where scalar is 1/INT32_MAX (and 1/INT16_MAX etc) as 
> > > > > > > this
> > > > > > > is a very common use case and might be available to an 
> > > > > > > optimization.
> > > > > > > Certain CPUs (armv8 in particular [1], not sure about x86? [2]) 
> > > > > > > has
> > > > > > > hardware instructions for converting fixed point to float and 
> > > > > > > back.
> > > > > > >
> > > > > > > In particular I'm interested in adding the common Q1.31 and Q1.15
> > > > > > > formats (full range signed int32_t and full range int16_t to
> > > > > > > (-1.0)-1.0 float).
> > > > > > >
> > > > > > > Would be grateful for input regarding this and in particular 
> > > > > > > ideas for
> > > > > > > naming the functions.
> > > > > > >
> > > > > > >
> > > > > > > --Albin
> > > > > > >
> > > > > > > [1] 
> > > > > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801h/pge1427897637493.html
> > > > > > > [2] 
> > > > > > > https://software.intel.com/en-us/articles/fast-floating-point-to-integer-conversions
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Discuss-gnuradio mailing list
> > > > > > > address@hidden
> > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio