Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Opus codec developments

Re: Opus codec developments

From: Jonas Wielicki <j.wielicki_at_sotecware.net>
Date: Mon, 31 Dec 2012 17:15:45 +0100

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
Received on 2012-12-31


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa