[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [VOLK] 16i_max_star_horizontal_16i non-saturating

From: Douglas Geiger
Subject: Re: [Discuss-gnuradio] [VOLK] 16i_max_star_horizontal_16i non-saturating subtraction
Date: Thu, 6 Feb 2014 11:58:39 -0500

On Thu, Feb 6, 2014 at 6:19 AM, Tom Rondeau <address@hidden> wrote:
On Wed, Feb 5, 2014 at 4:04 PM, West, Nathan
<address@hidden> wrote:
> I was doing some work with this kernel and came across an odd result
> that I think is caused by a non-saturating add in the generic
> proto-kernel, that should also be relevant to the 16i_max_star_16i.
> I haven't looked too much in to the SSE versions, but the generic
> versions are doing a comparison by subtracting two values and
> comparing the result to 0. At least in the QA on armhf this is causing
> wrap-around so that the smaller of the two numbers is returned as the
> max.
> Since I'm pretty sure this is part of the max* operator defined by
> Viterbi in his "justification and implementation of a MAP decoder" I
> think this result is incorrect unless I'm misunderstanding part of the
> operator.
> Can somebody with a little more insight in to this kernel ping back if
> this is intended behavior? If not, is there some benefit to doing
> (x-y)>0 vs x>y as the comparison?
> Thanks,
> Nathan

Just from what you've said here, I would agree that (x-y)>0 is a bit
dangerous, and I don't see why we can't use x>y. Does it work for you
if you make that change?


I'll suggest that the generic kernel should be trusted to do the correct thing, or at least have the correct set of intentions, and that if you want to change the behavior of the generic kernel, that you are introducing a change that will break applications depending on this behavior.

I believe the use of casting the subtraction before the comparison (where: ((int16_t) (src0[i] - src0[i + 1]) > 0) ? src0[i] : src0[i+1]; is the full comparison) was intentional to ensure overflow subtraction vs. saturation subtraction.

Doug Geiger

reply via email to

[Prev in Thread] Current Thread [Next in Thread]