On Wed, Dec 22, 2010 at 5:19 PM, Andrew Burgess <aab@xxxxxxxxxxx> 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 > libraries > 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 >> it >> might be possible to make it quite transparent if it isn't required >> (so >> you can always have it in the kernel). Have the kernel trap the >> exception on the missing FPU instructions, save state, and then pass >> the >> 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. Peter _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
