Id like to have us look at what we need to do to support both software floating point and hardware floating point support. I had been under the impression that all we would need to do is to build glibc with hardfp support. however that may not be the case. and we may need to build everything with hardfp support.
this is just to get discussion rolling
Dennis
On 10/25/2010 07:31 PM, Dennis Gilmore wrote:
Id like to have us look at what we need to do to support both software floating point and hardware floating point support. I had been under the impression that all we would need to do is to build glibc with hardfp support. however that may not be the case. and we may need to build everything with hardfp support.
this is just to get discussion rolling
See this thread for a little context: http://cygwin.com/ml/libc-ports/2009-04/msg00020.html
Basically, soft floating point on ARM is done with helper functions. By default, these are statically linked in, but they do not need to be. If you dynamically link in the aeabi floating point helper code (basically libgcc) and have a multilib glibc, then there is the ability to have softfp binaries that can take advantage of hardfp when available. These binaries will be slower than real hardfp binaries though. And it is not clear that multilib alone is sufficient, it may be that the new IFUNC stuff is really needed for good performance across different VFP variants.
Adam
On Mon, 2010-10-25 at 21:27 -0400, Adam Goode wrote:
On 10/25/2010 07:31 PM, Dennis Gilmore wrote:
Id like to have00079ca0-0130hat we need to do to support both software floating point and hardware floating point support. I had been under the impression that all we would need to do is to build glibc with hardfp support. however that may not be the case. and we may need to build everything with hardfp support.
this is just to get discussion rolling
See this thread for a little context: http://cygwin.com/ml/libc-ports/2009-04/msg00020.html
Basically, soft floating point on ARM is done with helper functions. By default, these are statically linked in, but they do not need to be. If you dynamically link in the aeabi floating point helper code (basically libgcc) and have a multilib glibc, then there is the ability to have softfp binaries that can take advantage of hardfp when available. These binaries will be slower than real hardfp binaries though. And it is not clear that multilib alone is sufficient, it may be that the new IFUNC stuff is really needed for good performance across different VFP variants.
Adam
Of the devices I've seen so far, the armv5 devices have all been softfp, and the armv7 devices have been hardfp. Are there any widely-used exceptions to this pattern?
-Chris
On 10/25/2010 09:38 PM, Chris Tyler wrote:
Of the devices I've seen so far, the armv5 devices have all been softfp, and the armv7 devices have been hardfp. Are there any widely-used exceptions to this pattern?
My understanding is that there are Marvell parts that are armv5+vfp. Marvell was all armv5 until quite recently, I believe. And I think Fedora ARM typically has been targeting Marvell.
Adam
On Tue, Oct 26, 2010 at 3:02 AM, Adam Goode adam@spicenitz.org wrote:
On 10/25/2010 09:38 PM, Chris Tyler wrote:
Of the devices I've seen so far, the armv5 devices have all been softfp, and the armv7 devices have been hardfp. Are there any widely-used exceptions to this pattern?
My understanding is that there are Marvell parts that are armv5+vfp. Marvell was all armv5 until quite recently, I believe. And I think Fedora ARM typically has been targeting Marvell.
Well I believe that is because the people running the various buildsystems have either had reason to target Marvell or that was the hardware they had vs any actual open discussions as to what people wanted. I personally would like to see a build optimised for A8/A9 devices, which I realised would know a large amount of devices off the supported list that are still shipping in quantity. Would it be hard to support build options for a armv5 + softfp and a armv7 + hardfp within the build infra. Debian have been having a discussion [1] that indicates that there's the possibility of a 20+% speed improvement which on a low power device is significant.
Regards, Peter
[1] http://www.linux-archive.org/debian-dpkg/395698-armelfp-new-architecture-nam...
On Tue, Oct 26, 2010 at 2:38 AM, Chris Tyler chris@tylers.info wrote:
On Mon, 2010-10-25 at 21:27 -0400, Adam Goode wrote:
On 10/25/2010 07:31 PM, Dennis Gilmore wrote:
Id like to have00079ca0-0130hat we need to do to support both software floating point and hardware floating point support. I had been under the impression that all we would need to do is to build glibc with hardfp support. however that may not be the case. and we may need to build everything with hardfp support.
this is just to get discussion rolling
See this thread for a little context: http://cygwin.com/ml/libc-ports/2009-04/msg00020.html
Basically, soft floating point on ARM is done with helper functions. By default, these are statically linked in, but they do not need to be. If you dynamically link in the aeabi floating point helper code (basically libgcc) and have a multilib glibc, then there is the ability to have softfp binaries that can take advantage of hardfp when available. These binaries will be slower than real hardfp binaries though. And it is not clear that multilib alone is sufficient, it may be that the new IFUNC stuff is really needed for good performance across different VFP variants.
Adam
Of the devices I've seen so far, the armv5 devices have all been softfp, and the armv7 devices have been hardfp. Are there any widely-used exceptions to this pattern?
There's discussions on the MeeGo dev list at the moment about moving to it for all supported platforms at the moment.
Peter
-
Adam Goode -
Chris Tyler -
Dennis Gilmore -
Peter Robinson