From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Tue, 21 Nov 2006 10:12:30 +1100

On 21/11/06, Tim Gilbert <timgilbert_at_gmail.com> wrote:
> Hi...
>
> I'm just starting to poke around in the rockbox code, and I'd like to
> start contributing some features / fixes / etc. Recent messages about
> shaving 300 bytes off of the code size make me kind of nervous, though.
> Can someone provide me with a brief summary of what the code size issues
> are? Is there a lowest-common denominator player whose limits we're
> running up against?
>
> Also, just curious if there's been any attempt to make any of the larger
> chunks of code into compile-time options? (Say, the voice options or
> crossfade? I do realize voice is essential for an important Rockbox
> user base, but for my own personal builds I'd just as soon have other
> features enabled instead of voice, since I don't use it.)
>
> Finally, does anyone have any opinion about whether it would be
> worthwhile to pursue some sort of VM type arrangement where the entire
> firmware wouldn't need to be loaded at once? (Or does Rockbox already
> do this for anything besides plugins?) I'm not nearly familiar enough
> with the code and the various platforms to know whether this would be
> feasible or not, but it does seem like one obvious way to work around
> code-size limitations, and one thing most of the hardware does have in
> spades is storage space.
>
> Thanks
> Tim
>
The problem with compiled binary size is that the archos models only
have 2mb of RAM and ~200kb (or 400kb) of flash which can be used for
rombox (rockbox but it boots from flash instead of the hard disk). as
you can see on the cvs page, 2 targets are already too big for rombox
and ideally we would like it to work.

some code pieces can be #ifdefed out with compiler options, but there
is no plans to make official builds with missing pieces.
Received on 2006-11-21