[Flac-dev] FLAC support for Android?

[Michael Crawford]

On Wed, Feb 25, 2009 at 5:23 AM, Brian Willoughby <brianw at sounds.wa.com> wrote:
> A better suggestion might be to start with libFLAC, optimize as
> needed, and then submit the optimizations back to the FLAC project
> where they will be more widely useful.

I know ARM and Thumb assembly code - Thumb is a compressed subset of
ARM that has greater code density.  Both are very important for
embedded applications.

A while back I did an Advanced Encryption Standard hard disk drive
encryptor that ran entirely on-board the Oxford Semiconductor OXFW911
FireWire/IDE bridge chip.  Unfortunately, the 911's ARM7TDMI CPU only
runs at 50 MHz, and AES requires several rounds of encryption to
process a block, so my first C implementation was as slow as molasses.

I was able to speed it up by a factor of 10 or so by implementing the
encryptor/decryptor in assembly code.

There are several ARM simulators available.  You don't need actual ARM
hardware to test ARM machine code!

A very helpful first cut at optimization is to have the simulator
simply count the number of instructions executes during the run of a
program.

A better runtime profile can be had by writing a memory map for the
simulator to use, that specifies the read and write access times and
bus width of each memory region in the target you're simulating.
Typically RAM is 32-bit and fast, while Flash is 32-bit for higher-end
devices and 16-bit for lower-end devices like the 911, and is
generally slow.

I think there is an ARM simulator that can be integrated into GDB, so
that you can debug your code on the desktop platform of your choice.

What I would suggest you do to start, is get an ARM compiler/simulator
toolchain set up on whatever kind of box you use, and get libflac,
libogg and the flac command line program to build for it.

I'll get back to you with some tips on ARM assembly code, and lots of
links for ARM programming tips.

I recommend the book I used to learn ARM assembly... let's see... ARM
System-on-Chip Architecture 2nd Edition by Steve Furber, published by
Addison-Wesley:

http://www.arm.com/documentation/books/5651.html

Ideally you will want *both* ARM and Thumb implementations.  ARM is
faster if you have a 32-bit bus and lots of Flash, but Thumb is faster
- and will fit at all - if you have only a small amount of 16-bit
Flash.  Besides having higher code density, Thumb machine code
instructions are fixed at 16-bits wide, whereas ARM opcodes are
32-bits wide.

An ARM CPU can execute Thumb code if there is a "T" in its model
number, such as the ARM7TDMI, which is very popular for very
low-power, physically compact applications such as the Oxford 911 -
the whole chip, including an IDE core, a FireWire Link-Layer core, 64
kb of Flash and 1800 bytes of RAM is about the size of a dime!

You can also mix both kinds of code; there are assembly code
instructions to switch back and forth.  That's what I did with my
encryptor; I loaded my machine code into RAM, then used ARM
instructions for the innermost loops.

Hope this helps!

Mike
-- 
Michael David Crawford
mdcrawford at gmail dot com

   GoingWare's Bag of Programming Tricks
      http://www.goingware.com/tips/