On 31.12.2012 14:37, Magnus Holmgren wrote: > Based on my experience with the H140, I'd say start looking at what data > is put in IRAM. The external memory bus is pretty slow in comparison to > IRAM, so putting "hot" buffers and tables in IRAM can make a big > difference. The next step would probably be some assembler code, e.g. to > exploit the multiply-and-accumulate unit. If you can get the profiling > code working, that could help locating hotspots.
Okay. A quick grep for iram_ showed that this is not used at all yet. It seems though that the EMAC is already used in the celt-code. One function which could benefit from using the EMAC cannot be made to use it due to GCC issues appearantly: static inline int32_t MAC16_16(int32_t c, int16_t a, int16_t b) { register int32_t cp asm("acc0") = c; int32_t r; asm volatile ("mac.w %[a], %[b], %[c];" "movclr.l %[c], %[r];" : [r] "=r" (r) : [a] "r" (a), [b] "r" (b), [c] "r" (cp) : "cc"); return r; } This won't compile, getting: ~/Builds/rockbox/lib/rbcodec/codecs/libopus/celt/fixed_generic.h:164:22: error: invalid register name for ‘cp’ (I am compiling for iriver target) Note that the accumulator register for m[s]ac.x must be an %accX register, according to the processors user guide… I also was unable to find anything related to the accX-registers for Coldfire in the GCC manuals (checked[1]) after reading up on constraints at [2]. More annoying in this context is, that the SILK-part of opus also requires a really similar function, which thusly cannot be made into EMAC instructions if this issue persists (and is not rooted in my ignorance). I am not sure at all at which places iram_ makes sense. I may have to dig into profiling, although I'm wondering how profiling function calls will help to trace memory use… regards, Jonas [1]: http://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints [2]: http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm