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

[Michael Shatz]

>-----Original Message-----
>From: Robin Getz [mailto:rgetz at blackfin.uclinux.org]
>Sent: Tuesday, June 19, 2007 9:35 PM
>
>
>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
>

In the next incarnation, may be. 
Right now I am leaving Blackfin for good. If the current 
prototype will ever advance to the phase of actual project then ... it still would
be wiser to stick with current tools.


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

Same here. 
[Un]forunately, it's normally my job to bring the board to the state where it has working
 UART, Ethernet and blinky lights.

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

Thanks. 
As you can conclude from above the last thing I am interested in is yet another GUI.

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

Agreed.

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

Too bad. I guess young folks have to learn on their own mistakes.

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

Not sure that the people at ADI are the best for the job. And not only because of lack 
good will on their part.
Mechanical fix of the syntax is probably far from optimal. You want to test _and profile_ 
asm replacement functions one by one and decide whether they help performance in specific case 
of ADI tools.
It seem probable that in many if not most of the cases it would be better to use ADI built in 
functions or even leave the code in plain "C". For example, intuitively, I'd say that the whole 
content of fixed_bfin.h is better left in "C".
Jean Marc equipped for that job much better than everyone else. Of course, he would have to convince
Analog to sponsor his effort and to give him full version of VisualDSP for free. But since they did it
once they are likely to do it again.

I would very much like to do it myself, but there is zero chance of either Analog or my employer paying
me for such sort of work.