On Sep 22, 2005, at 7:02 AM, Tiemen Schut wrote:

We are currently trying to develop an arm-mp3 player. (http:// groups.google.com/group/qamp/, not very interesting really)

Problem is, the code size generetad by arm-elf-gcc is about 300k, while all the different object files are about 100k. We already worked around the rq_table.dat using a Taylor approximation. The problem is we only have 128k flash available (we use a real embedded system, not some sort of arm with megs of memory and some weird linux kernel ;))

Is your C library being statically linked into the executable? I don't know anything about your runtime environment. You might be able to get some useful information from nm or objdump (e.g. objdump -x).

If this is the case, and you don't have a dynamic C library otherwise available on the target platform, you'll probably want to look into eliminating decoder.o (which implements the high-level API) and replacing the few remaining C library calls in libmad. There are a couple of {m,c}alloc()/free() calls that can be replaced with static allocation, a sprintf() call that can be eliminated from the timer interface, and some assert() debugging calls that can be avoided. The only other C library calls of concern are memcpy() and memmove() in layer3.c for which you will need to find an alternate implementation, or write one yourself.