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ö <albin.st...@gmail.com> 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) <muel...@kit.edu> > > 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 > > > > Discuss-gnuradio@gnu.org > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio