Speaking of gcc and arm, some archs use -Os by default, but arm is
using only -O. Some arm targets (e.g. AMS C200v2) with very little
ram could benefit quite a bit from using -Os and so far it's working fine
for me with rockbox gcc 4.0.3, so I would propose making -Os default
for at least the AMS
On Sat, 29 May 2010 11:30:24 +0200
Tobias Diedrich ranma+rock...@tdiedrich.de wrote:
Speaking of gcc and arm, some archs use -Os by default, but arm is
using only -O. Some arm targets (e.g. AMS C200v2) with very little
ram could benefit quite a bit from using -Os and so far it's working
fine
Am 12.03.2010 09:24, schrieb Jens Arnold:I am definitely for that
switch, but I think the crash bugs
We could go for the
cheap solution and use long enums... opinions?
Regards, Jens
I'm not a huge fan of that idea, but the linux kernel does this as well.
But as it seems now, only doom
On 08.03.2010, Thomas Martitz wrote:
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
On Tue, Mar 09, 2010 at 12:48:00AM +0100, Thomas Martitz wrote:
The AMS Sansas are in a bad situation w.r.t. to test_codec. Their low
memory doesn't permit running test_codec on most test files since test
codec wants the full file in ram (you can basically only test upto
128kbit/s). But
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,
I personally don't use flac so a reduction in flac codec speed is not a
problem for me and anyway, it can probably be improved after some
investigation is done.
But for all the good reasons you mention, I think it's a good thing to
update the toolchain.
Amaury Pouly
snip
Are there any opinions?
I don't use flac very much, so a slow down doesn't bother me if its not
noticeable.
however, one question, what about the irivers, do they free any ram or gain
any binsize?
__ Information from ESET Smart Security, version of virus signature
database
alex wallis wrote:
however, one question, what about the irivers, do they free any ram or
gain any binsize?
Which iRivers?
This is for ARM so it won't affect the H100/H300. The H10 ought to be
affected in a similar way to some of the other PortalPlayer based chips.
On Mon, 8 Mar 2010, Thomas Martitz wrote:
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.
We don't brew our own and we never did. We just use fixed version combos,
and we patch a few problems
An important question - have bootloaders been tested from these compilers?
Am 08.03.2010 21:34, schrieb Daniel Stenberg:
On Mon, 8 Mar 2010, Thomas Martitz wrote:
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.
We don't brew our own and we never did. We just use
On Mon, 8 Mar 2010, Thomas Martitz wrote:
Of course we can also alter our build setup etc to better adjust to such
compiler sets.
I can't follow your last sentence.
Distros will package arm cross-compilers that A) use different version combos
than those we like B) bundle a libc (that we
Am 08.03.2010 21:40, schrieb Paul Louden:
An important question - have bootloaders been tested from these
compilers?
Not all. But we're in the process of doing so. I verified the e200v1
bootloader. mc2739 will test on his e200v2 (the AMS Sansas are AFAIK the
only arm targets where the
Thomas Martitz wrote:
Not all. But we're in the process of doing so. I verified the e200v1
bootloader. mc2739 will test on his e200v2 (the AMS Sansas are AFAIK
the only arm targets where the bootloader (actually, the dualboot code
only) is critical, all other are pretty much unbrickable -
Am 08.03.2010 22:00, schrieb Daniel Stenberg:
Noticable binsize gain on targets that don't really need it sprinkled
with some performance loss. Yeah, I think that qualifies as no strong
reason.
IMO the performance loss is negible, since it a) only hits FLAC which is
fast enough (it runs
Am 08.03.2010 22:07, schrieb Paul Louden:
Thomas Martitz wrote:
Not all. But we're in the process of doing so. I verified the e200v1
bootloader. mc2739 will test on his e200v2 (the AMS Sansas are AFAIK
the only arm targets where the bootloader (actually, the dualboot
code only) is critical,
60K is not even 1 second of compressed audio. So reclaiming that is not
noticeable at all.
On Mar 8, 2010 1:16 PM, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
Am 08.03.2010 22:00, schrieb Daniel Stenberg:
Noticable binsize gain on targets that don't really need it sprinkled
Am 08.03.2010 22:15, schrieb Thomas Martitz:
Sure. I agree.
Verified Samsung YH925 bootloader as well.
On Mon, Mar 8, 2010 at 4:04 PM, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
Am 08.03.2010 22:15, schrieb Thomas Martitz:
Sure. I agree.
Verified Samsung YH925 bootloader as well.
I think that updating to the latest version of GCC would be nice, but I am
curious what the
Am 09.03.2010 00:43, schrieb Karl Kurbjun:
I think that updating to the latest version of GCC would be nice, but
I am curious what the codec performance is on a non-ideal situation.
I noticed that the tests you performed are against a PP target which,
as I understand, still uses long calls.
On Mon, Mar 8, 2010 at 3:15 PM, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
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
Am 09.03.2010 00:48, schrieb Thomas Martitz:
The AMS Sansas are in a bad situation w.r.t. to test_codec. Their low
memory doesn't permit running test_codec on most test files since test
codec wants the full file in ram (you can basically only test upto
128kbit/s). But if someone tested
Am 09.03.2010 01:50, schrieb Nils:
The flac codec is built with the core optimization level (-O1 on arm).
Earlier testing done on the gigabeast with gcc 4.4.2
showed that compiling the flac codec with -O2 with 4.4.2
was the fastest combination of compiler and optimization level.
So assuming
On Tue, Mar 9, 2010 at 2:13 AM, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
Am 09.03.2010 01:50, schrieb Nils:
The flac codec is built with the core optimization level (-O1 on arm).
Earlier testing done on the gigabeast with gcc 4.4.2
showed that compiling the flac codec with
Am 09.03.2010 02:39, schrieb Nils:
On Tue, Mar 9, 2010 at 2:13 AM, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
Am 09.03.2010 01:50, schrieb Nils:
The flac codec is built with the core optimization level (-O1 on arm).
Earlier testing done on the gigabeast with gcc
26 matches
Mail list logo
