|
Rockbox mail archiveSubject: Re: Bumping arm and m68k toolchains to gcc 4.9.4Re: 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 lies. 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 necessary. (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)
Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |