search for: _arm4

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

Stuart, Jean-Marc, >> 1) We need our own "fixed_xx.h" header file. I don't know why, and >> haven't >> had time to investigate, but there is a definite improvement when I use >> the >> attached fixed_c55x.h file which has turned all the maths into inline >> functions. > > Did you try with fixed_generic.h or just with fixed_debug.h?

Hi, I can see that there has been some effort to compile the SPEEX codec to operate on the TI c54x and c55x DSPs and I am wondering if anyone would be able to update the mailing list with their current MIPs and Memory resource requirements for their c54x and/or c55x compilation? The only estimate I was able to find in the mailing list archive was 42MIPs but I'm not sure if this is an

...embly, >> 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 d...

...ION16 switch (if it's not done already). This (very) slightly reduces quality, but means you convert a lot of "emulated" 16x32 multiplications into 16x16. There are also several routines that would benefit from platform-specific optimizations. There are already optimizations for ARM (*_arm4.h), Blackfin (*_bfin.h) and SSE (*_sse.h), so you can see what functions are worth optimizing. For a DSP, there are also two specific things I would watch. First, there is at least one CPU-intensive place (inner_prod) where I have to use many shifts in a loop to prevent overflows, but those could...