[Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain
rgetz at blackfin.uclinux.org
Fri Jun 15 15:11:29 PDT 2007
On Wed 13 Jun 2007 12:37, Michael Shatz pondered:
> Hi Jean-Marc
> I'm trying to integrate your speex codec on our custom Blackfin board. The
> board is not uCLinux compatible and there is no chance that it will ever be.
I never met any hardware that gcc could not run code on. toolchains have
nothing do with embedded OSes.
> I am using ADI-supplied VisualDSP++ IDE and corresponding toolchain. As long
> as I am compiling "C"-only version of the library everything is fine.
> VisualDSP++ produces working library. There is only one not so minor
> problem - the library is slow. However when I'm trying to compiler with
> inline assembler the compilation fails. It looks like ADI Blackfin assembler
> is not compatible with gas.
There are a few things:
- gcc/gas can do some things that VDSP is not capable of
- the syntax is different for inline assembly (constraints are different).
- assembler directives are different
- compiler pragmas are different
- gcc supports an additional ABI.
There are more details at:
(Those are bad page names - it should be _to_gcc). I will update them on the
> Supposedly you are aware of the problem since amongst Blackfin developers
> VisualDSP++ toolchain is the most popular by far.
Actually - I don't think this is true at all. There have been more people who
have downloaded the full blown, free version of gcc, than the crippled, time
limited version of VDSP.
> So developers that integrate speex tend to have plenty of RAM and once one
> has plenty of RAM he could install biggish OS. And between biggish OSes for
> Blackfin the most popular choice is uCLinux. And ucLinux works best with
> gnu tools. Something like that.
Again - gross overstatements. I know people who are using speex without using
any OS - using gcc. I don't know if they were using external ram or not...
> On the other hand, developers that use Blackfin in a manner similar to
> traditional 16-bit DSP usage model, i.e. without external RAM or with
> relatively small internal SRAM normally use no OS at all (like me) or ADI's
> VDK. These people naturally prefer ADI toolchain because it gives you good
> visibility of what's going on within a small "bare metal" target.
Then you just have not used gcc with eclipse or insight, and an in circuit
emulator. It provides an interface that is as good as the ADI toolchain
(IMHO) - and I have used both.
People use uCOS with gcc as well - gcc is not limited to Linux or other
applications, people use it for everything.
> Actually I know noone who use gnu toolchain.
Then you just don't hang around with the right people. :)
I will be the first to say that the GNU toolchain is not for everyone and
there are still a few things that are easier to do with a vendor or
commercially supplied toolchain - and for some specific algorithms - they may
generates better code - but we have narrowed this down to fewer and fewer
things by improving gcc - and we continue to do so.
If you have tried it, and think it sucks - that is OK too - just tell us how
to improve it.
> Could you suggest a solution for my problem?
Oh, yeah - I guess you actually had a problem - and were not just looking to
debate compiler selection. ;)
> : "=m" (res)
> It claims that m is not valid constraint Looking into the manual (including
> gnu manual) I agree with compiler.
Your looking in the wrong place. Have a look at:
scroll down to Blackfin.
look for m - and it is not there (just like it should not be). Therefore it
must be a constraint valid for any architecture, which are defined:
`m' A memory operand is allowed, with any kind of address that the machine
supports in general.
> "libspeex\fixed_bfin.h", line 48: cc1101: error: invalid constraint in asm
> : "%d" (a), "d" (b)
Have a look at:
`%' Declares the instruction to be commutative for this operand and the
following operand. This means that the compiler may interchange the
two operands if that is the cheapest way to make all operands fit
the constraints. GCC can only handle one commutative pair in an asm;
if you use more, the compiler may fail.
Those links should get you started - if you have further issues - the best bet
would be to ask on the Blackfin gcc forums - as this has little to do with
More information about the Speex-dev