Help - Search - Members - Calendar
Full Version: Gcc 3.4
OESF Forums > Distros, Development, and Model Specific Forums > Everything Development > User Request for Applications
ThC
I've read recently that gcc 3.4 have a lot of extra optimisations for xscale arch (and some kind of enhanced software fpu for it) and even for the new "wireless mmx" enabled xscale cpus and was wondering why wouldn't we use it instead od 3.3.2 toolchain ... btw there might be some excellent reason but whhat are these ??
lardman
Depends who we is; we do use it in OpenEmbedded iirc.


Si
ThC
right , "we" stands for pdaXrom users/developers as it seem to me the toolchain used is 3.3.4 (btw I may be wrong) ... btw I was thinking it was the same thing for other roms ...Maybe I should take a look at recent versions of OE/OZ smile.gif
Vit!
QUOTE(lardman @ Dec 13 2004, 01:33 PM)
Depends who we is; we do use it in OpenEmbedded iirc.


Si
*


but XScale optimizations are disabled by default in OE!

I have feed with Opie build with optimizations inside OE. More info at http://mifki.ru/el-apps
lardman
That's interesting. Presumably it wouldn't be too hard to enable the optimisations for those machines which have XScale processors (a matter of altering the machine's .conf file I assume).

How did you do this exactly? The wireless mmx extensions are for the C3000's processor if I'm not mistaken, these might have been excluded as I don't think any of the main developers/contributors has one of these to test with. I'd be interested to hear more about the c860 as I have a c750.

Have you performed any speed comparisons?


Si
Vit!
Yes, you are right. For example in h3900.conf (I'm not Zaurus owner, I use Linux on Ipaq H3970):

# not using tune-xscale so as to retain backwards compatibility
include conf/machine/tune-strongarm.conf

so here I changed to tune-xscale.conf

I haven't performed any comparisons yet. I simply was very surprised when saw that optimizations are specially disabled and re-enabled them. I'll look into more details about new optimization flags introduced in new gcc versions.
Vit!
also, gcc accepts -mtune= -mcpu= -march= with "iwmmxt" parameter (all gives same internal results)
so you can easily turn on Wireless MMX optimizations by specifiing these parameters in tune-blabla.conf
lardman
Thanks for that, I'll take a look.

I suppose the backwards conpatibility thing is done simply to remove the need for 3 (?) different feeds for the different processor types.


Si
Vit!
maybe.. but imho we must use all advangates of having source codes and one of them is to make highly optimized builds..
lardman
I quite agree.

Next time I'm on IRC I'll ask whether/when the plan is to move over to processor specific builds.


Si
Mickeyl
As you can see in conf/machine/tune-strongarm.conf, we already tune everything for xscale (-mtune=xscale), but we don't allow the gcc to use the few arm5 specific constructs, which would have a bad impact on arm4 performance.

Our gcc experts have found that using march=armv5te wouldn't give much of a benefit - especially not compared to the need of having to build more feeds. So unless someone comes up with some packages / benchmarks which proof something different, it'll stay that way.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.