On Thu, Dec 23, 2010 at 12:59 PM, Gordan Bobic <gordan(a)bobich.net> wrote:
Peter Robinson wrote:
>> are you sure the fp arg style is a kernel issue?
>> are there system calls that take floats (not in structs or arrays
>> but as a single argument)?
>>From all the documentation about it seems so. You need to remember
> there's a lot of mainline distros (and I'm not talking about small
> embedded ones) looking to move to arm7 + hardfp but none that have yet
> done so. There's lots of notes and people that have done customer
> recompiles etc for testing and eval purposes but none that have
> actually done it yet across the entire mainline distro to run
> everything from apache to gnome.
>> i could be totally wrong. it just seems almost there...
> Its is but that doesn't mean there's still not a lot of work to do.
> The Fedora ARM team has had issues with gcc / glibc etc just trying to
> get Fedora 13 compiled on on arm5tel. I've seen mention in the thread
> "but it works great with ICC" but you have to remember Fedora is an
> open distro so we're not going to be using a closed compiler to fix
> the problem.
ICC is x86 only. I mentioned it to illustrate that there is so much GCC
specific stuff in important core libraries like glibc that it is
unlikely we will get it working with any other compiler any time soon.
There are actually two problems regarding this:
I thought you were referring to ImageCraft C Compiler which arm and others
1) People shouldn't be writing code that isn't portable
I don't disagree.
2) GCC isn't a very good compiler performance-wise - not by a
It doesn't matter, its currently the core compiler that Fedora uses
and hence it what we need to get to work. When upstream Fedora changes
to something else so can we but I don't see that happening in the
short to medium term. In fact I suspect that its more likely to get
upstream gcc integrate some LLVM perf improvements before that
Once the GCC hardfp issue is resolved (I'm not going to hold my
I've moaned in the past about various areas of GCC's uselessness (e.g.
vectorization) and in the past 3 years no meaningful movement has been
achieved to close the <= 800% FPU performance gap with ICC), I suspect
it'll lead to having two ARM distros. armv5tel for ARMs without FPU and
arm7vfp for FPU enabled ARMs. Similar to what we currently have with x86
and x86_64, only if the ABI is different, arm5tel and arm7 will be
pretty much distinct separate architectures in terms of software target.
I think its not far away. Moaning doesn't fix problems but now that
there's a number of mainline distros looking at it and putting $$$ and
human resources into the problems its now moving faster. Both MeeGo
and Ubuntu are pushing these efforts via Linaro in combination with a
number of hardware vendors. MeeGo plans on having support for it for
the MeeGo 1.2 release due in April 2011 and they're "upstream first"
so there's already reasonable movement on that.
As for the two branches of arm for armv5tel and arm7+hardfp that has
already been discussed and is considered worthwhile and when people
get time and the issues with gcc/glibc and other core dependant
libraries are fixed it will happen. Again moaning isn't going to get
that happening. So what you say is nothing new and well discussed.
Most distros are going that way. MeeGo will in the 1.2 release, Ubuntu
is going that way, I know Debian is investigating it as it Fedora.
> At the moment we're concentrating on arm5tel as it works
> and we need to get Fedora 14 and rawhide there and its the combination
> that can support the broadest amount of hardware, one that's on the
> road to completion people can and will start looking at a version
> optimised for newer more power HW. Its only in the last week or so the
> team have managed to get enough of F-13 built to be able to compose a
> rootfs for testing it.
Ooo! Any chance of a link to this rootfs and the F13 arm5tel yum repository?
It was on planet Fedora in the last week or so posted by Paul W (of
Fedora ARM fame @ Seneca college). It might be linked on the Fedora
ARM wiki page too (sorry, don't have my browser history to hand).