Speex dev - Jun 2007 - Blackfin inline assembler and VisualDSP++ toolchain

-----Original Message-----
From: Robin Getz [mailto:rgetz@blackfin.uclinux.org]
Sent: Saturday, June 16, 2007 12:11 AM
To: Michael Shatz
Cc: speex-dev@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

On Tue 19 Jun 2007 13:00, Michael Shatz pondered:
> Robin Getz wrote:
> >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. 
Yes - you would use the JTAG-based GNU Tools that makes life of a developer 
easier.

http://www.section5.ch/icebear
> >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.
It is not just hobbyists - According to some ADI folks I have talked to - 
shipments of Blackfin that run gcc compiled objects are nearly the same as 
with VDSP.
> > 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.
They monitor the speex mailing list - if they want to introduce 
themselves - they will.
> 
> 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.
I personally think it slows things down too much - and prefer just 
command line, UART, Ethernet and blinky lights - but that is just me.
> 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.
I know some who are using it for large C/C++ projects - and it seems to work
well for them. There are also other GUIs - including Insight that work just as 
well in Windows as Linux.

http://sources.redhat.com/insight/screenshots.php
> 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. 
It is a matter of personal opinion, determined by the background
of the developer. I would rather use gcc - you would rather not.
That is OK.
> 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. 
Most things in gcc are independent of architecture. If possible -
only do things once....
> Normally, I strongly prefer separate assemble files over inline 
> asm (except for trivial stuff) so had no opportunity to become an expert.
I think that is what our compiler (gcc) folks thought would be best - but that
is an architecture decision from Jean-Marc. That is how the other architecture 
optimisations are done as well.
> 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.
Maybe you should ask the people at ADI to do it - since they are distributing 
the old/outdated version anyway and should update it (as to avoid this in the 
future).

http://forms.analog.com/Form_Pages/support/dsp/dspSupport.asp

Last time I asked, they said it was not possible, and mumbled something about
gcc accepting illegal operands. (which we are not - gcc just allows more
general purpose register allocation than VDSP does, so the inline puts more
register pressure on the VDSP than on gcc).

-Robin