discuss-gnuradio
[Top][All Lists]
Advanced

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

RE: [Discuss-gnuradio] Using gnu-radio for project


From: Bob McGwier
Subject: RE: [Discuss-gnuradio] Using gnu-radio for project
Date: Tue, 30 Sep 2008 15:03:46 -0400

I agree with this because of the Beagle board and the efficacy of OMAP
processors for embedded SDR apps.  With TI finally giving us free
development tools for noncommercial activities (not exactly GPL v3) the 6000
DSP part on the OMAP and the Neon are both sources of considerable MIPS at
very low power.

We should think about how to officially support libraries based on open
source we develop but for which there are NO free tools for some of the more
interesting parts coming out way including Cell, OMAP, Tilera Tile64, and
more.  We are doing this now for USRP2.  It is time to make a simple policy
statement that open source, but binary support is accepted and encouraged
given these conditions: A), B), ....



Bob

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow ....  Hurdle the dead"

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Philip Balister
Sent: Tuesday, September 30, 2008 2:03 PM
To: Eric Blossom; Inderaj Bains; address@hidden
Subject: Re: [Discuss-gnuradio] Using gnu-radio for project

On Tue, Sep 30, 2008 at 1:48 PM, Eric Blossom <address@hidden> wrote:
> On Mon, Sep 29, 2008 at 03:13:09PM -0700, Inderaj Bains wrote:
>> Thanks Eric,
>> Yes I want to use SIMD. Since I want to spend most time improving
>> performance, it would be nice if I can start off from something
functioning
>> or put together something quickly.
>> How much effort would it be to get a GSM (other?) all software system
>> together (except A/D I guess). Maybe I could use pre-generated streams on
>> both ends in software.
>>
>> Thanks
>> Inderaj
>
> This is great.  What we've been thinking about is building a library
> of SIMD accelerated primitives, along the lines of Intel's Integrated
> Performance Primitives.  The crucial differences would be: free
> software (GPLv3); support for SSE, SSE2, SSE3, Altivec and Cell SPE
> instruction sets.

Do you mind adding NEON to this list?  NEON is a SIMD unit on ARM
Cortex-A8 processors. Information on NEON instructions is at
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Bcfjicf
j.html.
Sorry it si the superseded link, I'm too lazy to find the current one
:)

> Our working title for this is the "Generic Performance Primtives" (GPP).
>
> One unresolved issue is what code to start with.  We need a framework
> that provides for reference implementations, QA, testing all argument
> alignments, correctness, performance, etc; runtime dispatch based on
> the equivalent of cpuid; can be built as both shared and static
> libraries (need static on the SPE).
>
> The basic idea (for the user visible routines) would be to start with
> the well thought out API described in Volume 1 (Signal Processing) of
> the IPP docs, peforming a s/ipp/gpp/g.
>
>
http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/34649
9.pdf
>
>
http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/34653
2_userguide_win_ia32.pdf
>
>
> Two possible starting points are:
>
>  liboil      http://liboil.sourceforge.net    (currently x86, x86-64 and
PPC)

liboil is used by a number of desktop programs, spending time on this
would be a win for me :)

Philip

>  Framewave   http://framewave.sourceforge.net (x86 and x86-64 only)
>
>  (Framewave is built on top of SSEPlus, a thin wrapper on top of the SSE
>  C/C++ intrinsics.  http://sseplus.sourceforge.net
>  Mostly it appears that they provide emulations for instructions that
>  are missing at a particular level.  E.g., your code could target SSE3,
>  and they'd emulate the missing addsub instruction in terms of SSE.)
>
>
> For starters, it would be great if you could look at these two options
> (and any others that you come across) and let us know how you think
> these would work out as starting points, given the requirements above.
>
> If this seems like more than you want to bite off, I can provide a
> list of high-priority functions and you could start implementing the
> reference version and any of the SSE*, Altivec or SPE versions that
> grab your attention.  We're big on complex arithmetic :-)
>
> Please let me know how this sounds and if you've got any comments or
questions.
>
> Thanks!
> Eric
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio





reply via email to

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