Rockbox mail archiveSubject: Re: Bumping arm and m68k toolchains to gcc 4.9.4
Re: Bumping arm and m68k toolchains to gcc 4.9.4
From: Solomon Peachy via rockbox-dev <rockbox-dev_at_cool.haxx.se>
Date: Fri, 10 Apr 2020 17:50:57 -0400
On Fri, Apr 10, 2020 at 06:01:33PM +0200, Sebastian Leonhardt via rockbox-dev wrote:
> I can test some of the PP targets: Samsung YH820 and YH925 (both
> PP5020), Philips (PP5022 IIRC) and iPod Mini gen1. I also can test
> Creative ZEN, Creative ZEN XFi2 and Fuze+. However time is the limiting
> factor ATM :)
The ZENs are all imx233, right? Any of those (and the Fuze+) would be
useful, though the arm926ejs code in them has been confirmed good on two
other targets (ipod6g and clip+)
I know that mini2g (PP5022, arm7tdmi) appears to go boom in
threading/locking code, but it's not clear where the root cause is, and
doing remote debugging is challenging in the best of circumstances.
I suspect the other PP targets will fare the same but it would be good
to confirm this, and maybe narrow down the scope of where the failure
I can generate builds for any or all of these, though if I had to pick a
minimal useful set I'd go with the Fuze+ and one of the Samsungs. All
would be better, but that's a lot more time..
> Just leave a note on IRC (I always read the logs) or PM me.
Hmm, what's your handle again? (My internal LRU cache sucks...)
> Would it be feasible to compile to Thumb-mode (ARM targets only, of
> course)? This could give even more savings. However it may be neccessary
> to keep computationally intensive code parts like Codecs in ARM mode.
We could turn it on, but it's probably not going to be a net gain except
on very IRAM-contstrained targets where more compact code size is
(Thumb helps a lot with instruction density, but there's definitely a
hit to performance due to fewer addressible GPRs..)
> As a side note, I tried out different optimation settings on a PP5020
> target with my WIP 2600 emulator; -O2 gave the best results, -O3
> resulted in a much bigger binary and was even slightly slower.
> Consequently shrinking code size had positive effekts (even when I
> removed inlining etc.).
Yeah, my thinking is that once we get the major kinks worked out with
the 4.9.4 toolchain bump, we can revisit codec & plugin optimization.
-- Solomon Peachy pizza at shaftnet dot org (email&xmpp) _at_pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode)