Re: float-to-short conversion

Thanks Ron.

I did some more testing, and it appears to indicate that I'm an idiot. I won't go into the sordid details.



Sent from my iPhone

> On Nov 17, 2019, at 6:17 AM, Ron Economos <w6rz@comcast.net> wrote:
>
> It's pretty easy to test for Volk issues. Just edit the ~/.volk/volk_config file and change the volk_32f_s32f_convert_16i line to generic for both alignments.
>
> On my older box, volk_config has u_avx for both alignments (and that works correctly).
>
> Ron
>
>> On 11/16/19 17:55, Marcus D. Leech wrote:
>> Is it possible that at some point the GR3.7 float-to-short convert (which uses Volk, it seems) got busted?
>>
>> I'm seeing values that look like they have been inappropriately byte-swapped.
>>
>> The attached flow-graph produces an output file with the correct value of "7" interpreted as a Short, but when the same is run on
>> a different (still X86) machine (The Atom X5 z8350), as on the Atomic PI SBC, the values are byte-swapped.
>>
>> I've been pulling my hair out for *weeks* on this, and only this evening came to realize that somewhere, those "shorts" are getting
>> byte-swapped, and it looks like *one* of the Volk kernels may be to blame.
>>
>> I would fully-expect there to be "surprises" when exchanging data twixt ARM SBCs and any randomly-chosen X86, because some (not ALL)
>> ARMs use a different byte-ordering, but this is between X86 systems.
>>
>> And on my lappy, which is a core i7 m640, the attached flow-graph produces the correct results in the output file.
>>
>> My lappy is running GR 3.7.13.4 while the packaged GR for Ubuntu 18.04 (on the Atomic PI) is 3.7.11-10.
>>
>>
>>
>