[Tremor] Notes on Implementing Tremor on an ARM7TDMI CPU

Nicholas Vinen hb at x256.org
Sat Dec 6 02:51:26 PST 2008

Having read more information about various ARM implementations, and
thought about optimization more...

Andrew Lentvorski wrote:
> Nicholas Vinen wrote:
> That's going to kill, if true--especially if fetching from flash ties
> things up for 2 cycles and can't interleave with a RAM access. 
> Vorbis, IIRC, assumes pretty good lookup speed in order to access the
> basis vector tables.  You may also find that caching and calculating
> is better than looking stuff up.
Which table(s) are you referring to as the "basis vector tables" - the
MDCT sine table, the windowing tables, etc.?  I can try loading
whichever is going to be most accessed into RAM if I knew which one that
> As a reference, I ported the Tremor library to the 66MHz ARM9 on the
> Nintendo DS.  Once I enabled the assembly language implementation, I
> didn't have any performance issues.
> Now, I don't know how much extra performance room I had left, but it
> was capable of decoding, streaming from Wifi, writing a raster to the
> display, and reading off of a flash device without me having to do
> anything strange to get performance.
> -a
According to WikiPedia, the Nintendo DS has the same ARM7TDMI core as
what I am using. I just overclocked mine to very close to 66MHz and so
far it seems to be working fine. In fact, from what I can tell, aside
from your CPU likely reading code out of RAM rather than flash, they
seem identical. No cache, same core, etc. So, it may be that executing
out of RAM makes all the difference.

So far this CPU seems stable @ 66MHz (w/ flash @ 33MHz). I may be able
to push it more. I'd rather not rely on that if possible, though.

I really think that if it's 75% real time, I can get it to be faster
than real time, but without a better idea of which routines are the most
critical I agree it's going to be tough. I'll try to get profiling
working again.



More information about the Tremor mailing list