|
Rockbox mail archiveSubject: Proposal to update GCC for ARMProposal to update GCC for ARM
From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Mon, 08 Mar 2010 15:15:15 +0100 Hello, I've uploaded my latest test results with gcc 4.4.3 and the just released binutils 2.20.1 to http://www.rockbox.org/wiki/CodecPerformanceComparison. The new combo does a bit better than the current 4.4.2/2.20 combo (reading the binutils mailing list, 2.20 had quite a few bugs, especially related to ARM). The new toolchain is pretty close now in terms of codecs. The major codecs are the same, or even faster. The only exception is FLAC, which is a good deal slower. BUT I think flac is fast enough anyway, so we shouldn't worry about it too much. In regards to binsize/ram usage, the new version gives us a mostly huge win. Around least ~64k on every PP, almost 60k on ipodnano2g, 50k on mr5000. On targets that already have no long calls (sansa ams, gigabeatfx), binsize is slightly increased (400-500 bytes) but ram usage is decreased more (600-800 bytes). The beast wins 1k bin and 10k ram. I'm proposing the switch since this is the first compiler in a long time which works almost out of the box (it hasn't been tested on all arm targets, but on many and it worked like a charm on all). I may emphasise this reason because it could mean that we might be able to not brew our own toolchain anymore, but instead let people be able to use the one their distro provides soon. It also means a huge or at least decent binsize and ram usage win for all arm targets. The speed is comparable to the current toolchain (with the mentioned exception flac). Another weak reason: We would be more standard conform, since eabi is the standard ARM abi (but that doesn't really matter for our project). The next may be imagination (or ccache influenced) but I feel the compile time has reduced as well. Are there any opinions? Received on 2010-03-08 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |