我们使用blackfin 532开发媒体算法，遇到了以下问题：

1. 因为要使用uclinux，是否只能用bfin-uclinux-gcc编译，而不能使用visual dsp++编译了？

2. 在利用编译器的优化能力时，前面有帖子提到visual dsp++的优化效率高于gcc：
“用VISUAL DSP++编译我写的图像处理算法经测试在华恒BF531板子上运算要1.4S,而同样在此板子上UCLINUX下用GCC编译后运算,要6.1S,谁能告诉我什么原因呢,怎么处理呢?GCC里优化参数为-O3,还是一样.”
回帖中也有若干达人指出visual dsp效率比gcc高。
我想请问一下，visual dsp++在release下的优化效率，真的比gcc -O3高么？高多少？如果有benchmark最好。

3. 如果visual dsp++编译效率确实高，但是我们现在的开发平台都是在linux上，用gcc编译的，如何使visual dsp和gcc的汇编到对方那里还能编译呢？
gcc -O3 -S生成.s到visual dsp++下编译不过，visual dsp++生成的.s到gcc下也编译不过。

附：
从以下几个方面比较bfin-uclinux-gcc和visual dsp++
1. 对uclinux的支持
  bfin-uclinux-gcc很好，visual dsp++不能编译uclinux
2. 编译优化效率
  传说visual dsp++ release优于gcc -O3，官方说法是gcc编译出来的代码速度是vdsp的80%??
3. profile能力
  gcc不支持gprofile,支持oprofile还不会用，visual dsp++ profile很方便，在simulation时支持linear profiling除了pc count以外，还可以获得cache miss, read write统计，十分有用，但visual dsp++在emulation时支持statistical profiling，似乎只能得到pc count。

------------------------------------------------------------------------------

问题都是要靠自己解决的

  我做MP4 CIF压缩算法是遇到的情况也一样， 用VDSP++编译， 直接在板上跑， 能跑到35fps。 而同样的程序， 在uClinux下面用GCC编译只能跑到15fps。
  对纯汇编程序，两个编译器出来的程序执行时间是一样的，主要是C程序的编译优化相差太大。
  没办法只能全部算用VDSP++来开发算法程序了。

------------------------------------------------------------------------------

请问jinlt vdsp++与gcc编译选项

“我做MP4 CIF压缩算法是遇到的情况也一样， 用VDSP++编译， 直接在板上跑， 能跑到35fps。 而同样的程序， 在uClinux下面用GCC编译只能跑到15fps”
==
请问，vdsp++跑35fps而bfin-uclinux-gcc跑15fps，当时你的编译选项确实是vdsp++用release而gcc用-O3么？
我原先猜测，两者运行效率不同，一方面两个compiler优化效率的确不同（但也不至于差那么多吧？都是一个公司的人写的）；另外一个原因可能是，vdsp++默认会把stack/heap指定到sram，而gcc默认的stack/heap在sdram里，目前我们正试图在gcc下把stack也指定到sram，然后再来比较两者运行效率。
我昨天去了blackfin.uclinux.org问了同样的问题，他们那边的技术支持说虽然vdsp++略优，但gcc也是"comparable"，我理解为差异不大，奇怪啊

我现在的痛苦是，如果vdsp确实优化很多，但我们的应用程序需要跑在uclinux上，那样我就必须在vdsp上把算法编成汇编，再倒回gcc这里编译，而两者之间的汇编还不一样，痛苦。

------------------------------------------------------------------------------

你用哪个版本的GCC?

印象中似乎从4.x.x才开始能生成并行度较好的可执行代码。

------------------------------------------------------------------------------

都是新版本

  bfin-uclinux-gcc (GCC) 4.1.1 (ADI 06R2)
  VDSP++ 4.5 (Updated November 2006)
  编译选项确实是vdsp++用release而gcc用-O3。

  看VDSP++优化出来的程序， 确实并行度非常高。

------------------------------------------------------------------------------

我们用的gcc版本

bfin-uclinux-gcc 4.1.1(ADI 06R2)

我略微瞄过几行gcc和vdsp生成的汇编，multi issue指令是有的，不过不多，且不如手写的好，vector操作没怎么注意，不知道他们能不能很好的生成。还有vdsp自己生成的汇编似乎仍有interlock，不知他为何不能避免。

目前暂时还没有比较gcc与vdsp++的编译效率，因为如上帖提到的，我们正在尝试把gcc这边的stack指定到sram中去，以期跟vdsp那边一致，有个共同比较的基础。

------------------------------------------------------------------------------

 
 
能给发一份驱动的Makefile吗？谢谢

------------------------------------------------------------------------------

驱动makefile

我们的驱动在uclinux下的，目前没有移植到vdsp下面呢

------------------------------------------------------------------------------

终于找到gcc与vdsp编译效率的官方说法了

http://docs.blackfin.uclinux.org/doku.php?id=visualdsp:faq
Which compiler does better optimization?
Unfortunately the Visual DSP guys have a big time advantage on us, so their compiler generates better code in many cases. The margin here is very roughly about ~80% (as in code generated by GCC will run at about 80% of the speed of the same code compiled by Visual DSP).
When it comes to assembly however, the compiled code will obviously execute at exactly the same speed.
这两天仔细看了docs.blackfin.uclinux.org上的文档，发现自己以前很多问题，包括uclinux到底能不能上vdsp跑等，文档上早就有答案，惭愧惭愧