[Speex-dev] Speex on TI C6x, Problem with TI C5x Patch

[Jean-Marc Valin]

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

> 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

-- 
Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca>
Universite de Sherbrooke