Hello Philip,

I know NEON has better performances, but it's far more complicated to use.
In a dumb way, basic radix2 butterfly in floating point could look like this:


static void Rank(cpx_float_t *_A, cpx_float_t *_B, floatmix_t *_W,
                 int _nblks, int _bsize) {
  __asm__ ("mov        r0,  %0           \n\t" //  _A
           "mov        r1,  %1           \n\t" //  _B
           "mov        r3,  %3           \n\t" //  blkIdx = _nblks
           "1:                           \n\t" //  for blkIdx
           "mov        r2,  %2           \n\t" //  wtmp = _W
           "mov        r4,  %4           \n\t" //  szIdx = _bsize
           "2:                           \n\t" //  for szIdx
           "vld1.32   {d1}, [r1]         \n\t" //  load _B
           "vld1.32   {d2}, [r2]         \n\t" //  load wtmp
           "add       r2, r2, %3, lsl #3 \n\t" //  wtmp += _nblks*8
           "vmul.f32  d0, d2, d1         \n\t" //  complex mul
           "vrev64.32 d3, d2             \n\t"
           "vmul.f32  d3, d3, d1         \n\t"
           "vneg.f32  s1, s1             \n\t"
           "vtrn.32   d0, d3             \n\t"
           "vadd.f32  d3, d0, d3         \n\t"
           "vld1.32   {d0}, [r0]         \n\t" //  load _A
           "vsub.f32  d1, d0, d3         \n\t" //  _B = _A - _B W
           "vadd.f32  d0, d0, d3         \n\t" //  _A = _A + _B W
           "vst1.64   {d0}, [r0]!        \n\t" //  store _A and update
           "vst1.64   {d1}, [r1]!        \n\t" //  store _B and update
           "subs      r4, r4, #1         \n\t" //  szIdx--
           "bgt 2b                       \n\t" //  branch if > 0
           "add       r0, r0, %4, lsl #3 \n\t" //  _A += _bsize*8
           "add       r1, r1, %4, lsl #3 \n\t" //  _B += _bsize*8
           "subs      r3, r3, #1         \n\t" //  blkIdx--
           "bgt 1b                       \n\t" //  branch if > 0
           :: "r"(_A), "r"(_B), "r"(_W), "r" (_nblks), "r" (_bsize)
           : "d0", "d1", "d2", "d3", "r0", "r1", "r2", "r3", "r4", "memory");
}

and this it's twice slower than the fixed point.

In your knowledge, is it's possible to link the assembly optimised
"omxSP.a" library compiled by RVCT with a "hello FFT world" using gcc?


Cheers,
Michele





> Michele Bavaro wrote:
>> Hello Philip,
>>
>> thank you for coming back on this subject.
>> I modified the library developed by Gregory Heckler, the source code is
>> here:
>>
>> http://github.com/gps-sdr/gps-sdr/tree/6153c01317f34a26b2fb41926505b9d97f764e90/objects
>>
>> To give you an example, the DIT butterfly looks like this:
>>
>>
>> #define BUTTERFLY_FWD(_A, _B, _W)                                    \
>>   __asm__ ("LDR    r0, [%0]            \n\t"                         \
>>         "LDR    r2, [%1]            \n\t"                            \
>>         "MOV    r3, #0              \n\t"                            \
>>         "SHADD16  r0, r0, r3        \n\t"                            \
>>         "SHADD16  r2, r2, r3        \n\t"                            \
>>         "LDR    r3, [%2]            \n\t"                            \
>>         "SMUADX r5, r2, r3          \n\t"                            \
>>         "SMUSD  r4, r2, r3          \n\t"                            \
>>         "ADD    r5, r5, #8192       \n\t"                            \
>>         "ADD    r4, r4, #8192       \n\t"                            \
>>         "ASR    r4, r4, #14         \n\t"                            \
>>         "PKHBT  r3, r4, r5, LSL #2  \n\t"                            \
>>         "QSUB16 r2, r0, r3          \n\t"                            \
>>         "QADD16 r0, r0, r3          \n\t"                            \
>>         "STR    r0, [%0]            \n\t"                            \
>>         "STR    r2, [%1]            \n\t"                            \
>>         ::"r" (_A), "r" (_B), "r" (_W)                               \
>>         :"r0", "r2", "r3", "r4", "r5", "memory")
>>
>>
>>
>> and just uses ARM assembly (NEON is complicated to use with this basic
>> radix2 implementation).
>
> You'll need to use NEON to get performance. I'll try and look over the
> algorithm and see if I can make some suggestions.
>
>>
>> As user space, I am using the Angstrom image v0.92:
>>
>> http://www.gumstix.net/overo-gm-images/v0.92/
>>
>> on my Overo Water. I use the CodeSourcery 2009q1 free toolchain, even
>> though today I've been suggested to try something else by Koen.
>
> Use the toolchains created by OE. A quick way to do that is set your
> path into the oe/tmp/cross/... directory.
>
> Philip
>
>>
>>
>> Regards,
>> Michele
>>
>>
>>
>>
>>> Michele Bavaro wrote:
>>>> Hello everyone,
>>>>
>>>> I'm porting my software GPS receiver on the OMAP, therefore I need
>>>> fast
>>>> signal processing libraries, and in particular FFTs.
>>>>
>>>> I have somehow adapted an open source library to do radix2 butterfly
>>>> using
>>>> ARM assembly. It works, but my 256 points fixed point 16 bit FFT still
>>>> takes about 60us. That's 12 times slower than 4.7us advertised with
>>>> NEON!
>>> What open source FFT library? You could try posting the code and seeing
>>> if anyone has any suggestions. (Post the code the Beagle list also,
>>> there are some good NEON people there)
>>>
>>>> Frustrated, I downloaded and compiled with the evaluation version of
>>>> RVCT
>>>> the openMAX libraries, but I don't manage to link the object file with
>>>> code compiled with the CodeSourcery gnu toolchain.
>>> What user space are you using? Angstrom or something else. You'll need
>>> to use a tool chain that matches your user space.
>>>
>>> Philip
>>>
>>>> I tried to translate the assembly, but unfortunately it's a very
>>>> challenging task for me.
>>>>
>>>> Can someone point me in the right direction on this subject?
>>>> Should I keep working on my fixed point 16 bit FFT? Should I buy the
>>>> ARM
>>>> toolchain and port all the software? Should I just give up and try
>>>> using
>>>> the DSP maybe?
>>>>
>>>> Thank you in advance for any reply, and good luck with the OpenSDR,
>>>> which
>>>> I'm watching very closely.
>>>>
>>>> Cheers,
>>>> Michele
>>>>
>>>>
>>>>
>>
>>
>>
>


Reply via email to