[Speex-dev] Speex on TI C6x, Problem with TI C5x Patch
jim.crichton at comcast.net
Wed May 25 13:04:59 PDT 2005
>> I incorporated Stuarts fixed_c55x.h file, and that eliminated the
>> 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.
>> 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
>> 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
>> 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
>> 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
>> 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.
- Jim Crichton
More information about the Speex-dev