Memory constraint (GNU gcc blackfin) not recognized by visualdsp compiler...how to fix?

I am trying to build this function in visualdsp but the compiler
doesn't recognize the "m" constraint (only GNU gcc for blackfin does).
I have tried to replace the "m" constraints by other constraints
recognized by the visualdsp compiler, but I always get this message:

gnu asm requires too many ['some letter'] regs

For example: gnu asm requires too many D regs

The function I am trying to build is a function from the speex codec:
filter_mem16

If you want to see what the function looks like, take a look here:

http://svn.xiph.org/trunk/speex/libspeex/filters_bfin.h

On Wed, 03 Aug 2011 10:16:08 -0700, John McDermick wrote:

> I am trying to build this function in visualdsp but the compiler doesn't
> recognize the "m" constraint (only GNU gcc for blackfin does). I have
> tried to replace the "m" constraints by other constraints recognized by
> the visualdsp compiler, but I always get this message:
> 
> gnu asm requires too many ['some letter'] regs
> 
> For example: gnu asm requires too many D regs
> 
> The function I am trying to build is a function from the speex codec:
> filter_mem16
> 
> If you want to see what the function looks like, take a look here:
> 
> http://svn.xiph.org/trunk/speex/libspeex/filters_bfin.h

You have my sympathy, but unless you find someone whose done exactly this 
then you're probably going to have to do this on your own.

The reason I say that is because you need to port the code.  It's clearly 
depending on compiler-specific features, and as such it's going to be 
_work_ to port.  Is there a reason you can't compile it with gcc?

-- 
www.wescottdesign.com

>
> The reason I say that is because you need to port the code.  It's clearly
> depending on compiler-specific features, and as such it's going to be
> _work_ to port.  Is there a reason you can't compile it with gcc?
>

I can compile it with gcc and I have been looking at the asm code that gets
generated. It looks like the GNU gcc compiler operates with a different
ABI than VDSP with respect to how function arguments, local variables etc
are loaded on the stack and into registers ?? If that's the case then I have 
to rewrite the asm
code to comply with VDSP's ABI, right? The reason why I don't want to use
gcc is more of a practical matter.

John McDermick wrote:

> I am trying to build this function in visualdsp but the compiler
> doesn't recognize the "m" constraint (only GNU gcc for blackfin does).
> I have tried to replace the "m" constraints by other constraints
> recognized by the visualdsp compiler, but I always get this message:
> 
> gnu asm requires too many ['some letter'] regs
> 
> For example: gnu asm requires too many D regs
> 
> The function I am trying to build is a function from the speex codec:
> filter_mem16
> 
> If you want to see what the function looks like, take a look here:
> 
> http://svn.xiph.org/trunk/speex/libspeex/filters_bfin.h

What a crap. This is a good example of what free opensource really is 
and how not to write the code.

My dear friend, brace yourself for the complete rewriting of this junk.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Wed, 03 Aug 2011 19:41:28 -0400, John McDermick wrote:


>> The reason I say that is because you need to port the code.  It's
>> clearly depending on compiler-specific features, and as such it's going
>> to be _work_ to port.  Is there a reason you can't compile it with gcc?
>>
>>
> I can compile it with gcc and I have been looking at the asm code that
> gets generated. It looks like the GNU gcc compiler operates with a
> different ABI than VDSP with respect to how function arguments, local
> variables etc are loaded on the stack and into registers ?? If that's
> the case then I have to rewrite the asm
> code to comply with VDSP's ABI, right?

Mostly.  A good asm interface would save off registers that you stomp on 
(I think gnu does this).

I have a very low level of trust for any code that's put in a header file 
and isn't obviously meant to be inlined (which that most certainly 
isn't).  It's a sign that someone really didn't understand what they were 
doing.

I'd rewrite the code either wholly in assembly, or with just function 
shells and assembly innards like they did, only not in a header file for 
crying out loud!

> The reason why I don't want to
> use gcc is more of a practical matter.

That's your cross to bear.

-- 
www.wescottdesign.com