On Sun, Mar 6, 2016 at 10:13 PM, West, Nathan <n...@ostatemail.okstate.edu> wrote:
> I think that's a result of those add blocks being used in trellises (could > be wrong on that assumption). > > If we add saturating adds we should follow most architecture conventions > and explicitly call it saturating. > Agreed. We should have both as kernels for people to make their own choices of what behavior they need. Tom > On Sunday, March 6, 2016, Andy Walls <a...@silverblocksystems.net> wrote: > >> On Sun, 2016-03-06 at 16:33 -0500, West, Nathan wrote: >> >> >> >> > By the way, if you choose to do this please don't be afraid to ask >> > questions; this is a pretty well defined problem, but [...] >> >> Hi Nathan, >> >> Since you mentioned it, a question popped to my mind: >> >> The current add_const blocks let integer overflow happen, so that >> integer numbers wrap around. In DSP, saturation math is often what is >> desired, not overflow. We'd rather the numbers clip at the max or min >> value, rather than experience some huge jump. SIMD instruction sets >> provide instructions that perform saturation math, e.g. the MMX >> intrinsic __m64 _m_paddsw(__m64 a, __m64 b) for adding 4 sets of 16 bit >> integers. >> >> Should the new volk routines, meant to speed up the integer version of >> add_const blocks, perform saturation math, or stick with the current >> overflow behavior? >> >> > Cheers, >> > >> > Nathan >> >> Regards, >> Andy >> >> > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
