[Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain

[Michael Shatz]

-----Original Message-----
From: Robin Getz [mailto:rgetz at blackfin.uclinux.org]
Sent: Saturday, June 16, 2007 12:11 AM
To: Michael Shatz
Cc: speex-dev at xiph.org
Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++
toolchain


>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.
>

That's true. Add some postprocessing, program binary into flash and code would run. 
But you likely would not be able to use non-gnu tools like all VisualDSP++ jtag-based 
stuff that makes the life of developer easier.

>> 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:
>http://docs.blackfin.uclinux.org/doku.php?id=port_assembly_source_code_from_vdsp_to_uclinux
>
>http://docs.blackfin.uclinux.org/doku.php?id=port_c_c_source_code_from_vdsp_to_uclinux
>
>(Those are bad page names - it should be _to_gcc). I will update them on the 
>weekend.

Thanks.

>> 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.

I guess, I didn't count hobbyists. May be, I should.

>> 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...
>

Would like to talk to them.

>> 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 used gcc with Eclipse, not with Blackfin, with Altera Nios2. Hated every 
second. Not because of gcc, which was fine, but because of Eclipse and Altera-provided 
support plug-ins.
On the other hand, co-worker used the same combo for smaller project and feeled o.k.
about it. I guess, Eclipse just not my cup of tea. At least, not for C/C++ development,
heard it's o.k. for Java.

BTW, if I sounded as having something against gcc, that's misunderstanding. I like gcc.
I think compiler and utilities are fantastic, and the progress they made in embedded space 
since my first contact with the tool more than decade ago is also fantastic. 
Still, in specific case of Blackfin, VisualDSP++ is, IMHO, better tool for small projects with
tight developer's time budget and tight DSP resources budget.

>> 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.
>
>http://blackfin.uclinux.org/gf/project/toolchain/forum/?action=ForumBrowse&forum_id=44
>

See above.

>> 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:
>
>http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Machine-Constraints.html#Machine-Constraints
>
>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:
>
>http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Simple-Constraints.html#Simple-Constraints
>
>`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
>> statement
>>
>>      : "%d" (a), "d" (b)
>>
>>        ^
>
>Have a look at:
>
>http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Modifiers.html#Modifiers
>
>`%'  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.
>

Thank you very much. I didn't see the second and the third pages - didn't realize that part of
the syntax is architecture-neutral. Normally, I strongly prefer separate assemble files over inline
asm (except for trivial stuff) so had no opportunity to become an expert.


>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 
>speex.
>
>http://blackfin.uclinux.org/gf/project/toolchain/forum/?action=ForumBrowse&forum_id=44
>
>-Robin

That's assuming that I am going to fix the syntax myself. Still didn't lost the hope that Jean-Marc would
do that instead of me.

Regards,
Michael