On Wed, Dec 22, 2010 at 5:19 PM, Andrew Burgess <aab(a)cichlid.com> wrote:
On 12/22/2010 08:40:23 AM, Gordan Bobic wrote:
> > It's not a Fedora infrastructure issue
all i meant is that that part is solved, getting the correct shared
loading with the correct executables.
Its not really as x86-64 can happily run i686 binaries with
appropriate libraries etc side by side, that's not the case with
softfp vs hardfp
> , the ABIs are incompatible. I
> > wish you could mix'n'match but that doesn't look possible.
> What about kernel level FPU emulation? Is there such a thing? I could
> have sworn there used to be something that could be used as such. And
> might be possible to make it quite transparent if it isn't required
> you can always have it in the kernel). Have the kernel trap the
> exception on the missing FPU instructions, save state, and then pass
> to an emulation library. When that returns, restore state and resume.
i was only thinking of an arm7 kernel handling arm5 executables so no
emulation should be needed. so like for NEON now, a NEON program wont
work on hardware without NEON.
That is possible if you use arm7 with softfp but then you don't get
much advantage of using that. To get NEON programs to be optimised but
still run on HW without Neon you need multiple code paths and run time
detection. My understanding is the way the application compile FP
support you either get hardfp instructions or softfp but not a means
of detecting and changing on the fly.
i assume the arm5 instruction set is upward compatible so it would
seem even easier than an existing x86_64 kernel running 32bit code
which is not binary compatible.
Its not that the instruction set isn't compatible its how the compiler
optimised the instructions for explicit hardfp or softfp. The
resulting code can't fall back.
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. 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.