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

[Jim Crichton]

Jean-Marc,

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

That is my plan.

>> 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?

The macros are the same, but the results are different.  So it is probably a 
change in one of the macro calls.

>> 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).

It already runs fast enough on 55x for my immediate needs, if the simulator 
is telling the truth.  But you make a good point.

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

- Jim Crichton