dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: 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 <>
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
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      _at_pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

Received on 2020-04-10

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy