[Speex-dev] Blackfin port on Visual DSP, Michael Shatz ?

[Jean-Marc Valin]

> Well, actually, I found-out that the stdio lib can access my PC file-system
> through the JTAG interface.
> So I can eventually try this.

Would be a good thing to try if you want to rule out a bug in your code.

>> Hmm... let me investigate a bit further.
>> You mean you disabled blackfin assembly optimisations? Do you 
>> see the same results on a PC. I suspect it could be an 
>> uninitialised memory problem somewhere.
> 
> Yes, I currently have no ASM optimizations, it's the standard FIXED_POINT
> code.
> I didn't test on PC linux/win32, as other users have no trouble on these
> platform.

That could also help identify bugs -- especially if you can run your
code within valgrind.

> I looked at the sources and discovered the different temp-memory allocation
> schemes.
> After compiling with VAR_ARRAYS, it's better with revision 12173.
> -> working for 2-3 VoIP calls (init & destroy for each call)
> -> not working again for next calls

Looks like something is uninitialised.

> With lastest revision from SVN, sometimes it only worked once.
> Now it's not working anymore.
> 
> *** WITH preprocessor initialized and called (but nothing activated in it)
> ***
> -> same as echo-canceller, it's working.

Looks like something is uninitialised.

> So I think you are right on the memory init problem.
> 
> Do you think it comes from my run-time libraries ?
> Or is it a mistake in Speex ?

>From most likely to least likely:
1) An bug in your test code
2) A problem with your run-time
3) A bug in Speex

Note that if you have overridden the speex_alloc() function you MUST
replace it by something that frees the memory (calloc) otherwise Speex
will not work.

>>> - 'dynamic' labels are not available on VDSP (when you use 
>> an inline 
>>> several times, the gcc compiler can do some kind of incrementation)
>> What would you use instead?
> 
> hehe, that's where I have trouble.
> No documentation on how to do this...
> I guess I will have to use PC-relative addressing-mode and compute the
> offset myself.

Yuck! How many functions are affected (maybe they can be disabled or
something?). Also, try and find if there's a way to generate these
dynamic labels. I can't believe they hadn't thought of the problem.

> -> This would compile also on the GCC.

But would be hard to maintain and error prone.

> Alternatively and because only some functions are used several times,
> and AFAIR it's mainly the divisions,
> I can handle this with 3 solutions:
> - just use the standard syntax to let the compiler use its library.
> - use built-in functions (can also do this for MUL/MAC functions)

What do you mean?

> - for bigger functions, just de-inline them !

Not an option, I don't want to have functions that are inline for one
arch and not on other archs. That's a recipe for problems.

	Jean-Marc