[Speex-dev] Speex on TI C6x, Problem with TI C5x Patch
Jean-Marc.Valin at USherbrooke.ca
Wed May 25 12:46:46 PDT 2005
> I incorporated Stuarts fixed_c55x.h file, and that eliminated the artifacts,
> at the expense of a ~30% increase in MIPs. Now the male.wav file through
> encoder/decoder produces a bit-exact match with the C64x test that I did
> earlier. I will do some more testing to isolate the, but it may be a few
> days before I get to this task. As Jean-Marc says, fixed_generic should
> work, unless the compiler becomes hopelessly confused by something. Maybe
> this is a compiler bug.
It's odd that it "almost" works with the fixed_generic.h. The easiest
thing would be to gradually replace routines and see which one causes
problem. It's most likely (though I'm not 100% sure) that somewhere in
the code, I have a 16-bit value that gets sent to a function/macro that
expects a 32-bit value. In that case, Stuart's fixed_c55x.h file would
work because the inline function would first force the conversion to 32
bits. My initial guess would be with the SH[RL]32 and ADD32 functions.
> I noticed that in Jamey Hicks original 1.1.6 patch, he had test code with
> inline function (and some counters for measuring macro use), but I got the
> same results in this build with the inline functions or the macros. So
> something is different in 1.1.8.
What do you mean here?
> I believe that Code Composer provides very good support for inline assembly,
> although I have not used it myself, and hope not to.
Well, you can always try to do assembly versions of the macros, but I'm
sure you'll have better results by re-writing some of the time-critical
routines directly (see what's been done for ARM in the _arm4.h files).
> Unless there is some reason to do otherwise, it seems like all C55x specific
> options should be turned on by one flag. This can be decided after the
> current issues have been investigated further.
That's already the case, except that this part relies on the configure
script. I realize that not everyone is using configure, so perhaps there
should be another way.
> I think that Stuart is refering to the big jump in MIPs I saw between the
> C54x and C55x DSPs. I have not sorted that out yet. I would like to take a
> look at why Stuart's inline functions change the results, since there is a
> significant performance penalty in using them.
I'm sure you'll still get a low MIPS count after we find the fix to
> Yes, that's right. speex_bits_insert_terminator keeps calling
> speex_pack_bits forever, because bitPtr never reaches 15. Eventually the
> bit buffer runs out of room.
Good, that explains other problems I've seen.
Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca>
Universite de Sherbrooke
More information about the Speex-dev